Identifier ce qui fait fonctionner le site
Selon l’architecture, le site dépend de fichiers, d’une base de données, de médias, de configurations et de services externes. Recensez aussi les informations nécessaires pour reconstruire l’environnement : versions, extensions, tâches planifiées et connexions. Les secrets doivent être gérés avec des accès adaptés, pas déposés dans une archive accessible publiquement.
Sur un site éditorial, perdre quelques heures de modification peut être tolérable. Sur une boutique, la perte de commandes est un autre problème. Définissez donc la perte de données acceptable et le délai de remise en service attendu avec le responsable de l’activité.
Organiser des copies indépendantes
Une copie uniquement présente sur le même serveur peut disparaître lors du même incident. Prévoyez une conservation séparée, des accès limités et une politique de rétention. Vérifiez aussi qui peut supprimer les copies : un compte compromis ne doit pas pouvoir effacer facilement toute possibilité de retour.
La fréquence dépend de l’évolution des données, pas seulement de la taille du site. Les médias peuvent changer rarement alors que les commandes évoluent en continu. Un plan de sauvegarde doit reconnaître cette différence et documenter les limites de récupération.
Réaliser un exercice de restauration
Restaurez dans un environnement de test qui ne peut ni envoyer des emails clients ni déclencher des paiements ou des synchronisations réelles. Contrôlez la cohérence des dates entre fichiers et base. Une restauration partielle peut laisser des références à des médias absents ou à des fonctionnalités incompatibles.
Testez les pages, l’administration et les parcours essentiels. Pour une boutique, utilisez des commandes de test dans les conditions prévues. Notez la durée, les erreurs et les actions manuelles nécessaires. L’exercice doit aboutir à une procédure exécutable par une autre personne autorisée.
Préparer le jour de l’incident
Conservez une fiche indiquant les responsables, les accès nécessaires et la manière de décider quelle copie restaurer. Après une intrusion, remettre en ligne une copie sans traiter la cause peut réintroduire le problème. La procédure doit prévoir l’analyse de l’incident et la vérification de l’environnement.
Le retour en production exige aussi un contrôle des données créées depuis la copie retenue. Évitez d’écraser des commandes ou des demandes récentes sans plan de rapprochement. Documentez clairement cette limite dans le contrat de maintenance.
Questions fréquentes
La sauvegarde de l’hébergeur suffit-elle ?
Elle peut contribuer au dispositif. Vérifiez son périmètre, sa rétention, les délais de récupération et la possibilité de restaurer indépendamment.
À quelle fréquence tester une restauration ?
Après un changement important d’architecture et selon la criticité du service. Une procédure jamais rejouée peut devenir inutilisable.
Passer à l’action
Demandez la date du dernier exercice réellement terminé et son compte rendu. IIDI peut vous aider à clarifier votre maintenance.
Référence utile
WordPress — Sauvegardes, pour les sites utilisant ce CMS.
IIDI relie stratégie, design, technologie et acquisition.
Nous transformons ce sujet en feuille de route priorisée, puis en dispositif concret, mesurable et administrable par vos équipes.