Tester la restauration d’un site avant l’incident

Définir ce qu’il faut pouvoir retrouver

Dressez l’inventaire du code, des contenus, de la base de données, des fichiers envoyés, des médias, des réglages applicatifs et des tâches programmées. Certains éléments vivent chez l’hébergeur, d’autres dans un CMS, un stockage séparé ou un service tiers. Identifiez ceux qui peuvent être reconstruits et ceux dont la perte serait irréversible.

Précisez le point de reprise acceptable pour chaque ensemble : un site vitrine mis à jour une fois par mois et un service qui reçoit des demandes quotidiennes n’ont pas le même besoin. Notez la fréquence des copies, leur emplacement, leur durée de conservation et qui peut déclencher une restauration.

• Inventaire des contenus et données réellement nécessaires.
• Date de reprise acceptable pour chaque ensemble.
• Responsables et emplacements des copies.

Séparer copie, export et restauration

Un export éditorial peut récupérer des textes mais oublier thèmes, réglages, utilisateurs ou médias. Une copie des seuls fichiers peut manquer la base de données. Demandez au fournisseur exactement ce que couvre son service et ce qui reste à votre charge. La documentation WordPress recommande une sauvegarde avant la mise à jour d’extensions ; la méthode précise dépend de l’architecture.

Conservez des copies selon des règles de sécurité adaptées au contexte et limitez les personnes qui peuvent les lire ou les remplacer. Documentez les prérequis de restauration, sans publier d’identifiants, de clés ni d’informations d’accès dans un guide partagé.

Faire un exercice dans un environnement isolé

Choisissez une copie et restaurez-la hors du site public. Chronométrez les étapes sans supposer que la procédure écrite est complète. Vérifiez l’ouverture des pages, les médias, les liens, les permissions utiles, le formulaire dans un mode d’essai et les fonctions qui dépendent d’un service externe.

Comparez les données restaurées à l’inventaire de départ. Notez les éléments absents, la dernière modification présente et les réglages à refaire. Un test réussi doit être reproductible par une autre personne autorisée, dans le temps et les conditions que l’organisation juge acceptables.

• Copie et environnement utilisés.
• Durée observée et étapes manuelles.
• Pages, données et fonctions réellement contrôlées.

Corriger le plan et décider du prochain test

Mettez à jour la procédure après chaque exercice : contacts, ordre des opérations, dépendances et contrôles de sortie. Recommencez après une migration, un changement de fournisseur ou une modification importante de l’application. Le guide de maintenance replace cette vérification dans le suivi régulier du site.

Lors d’un incident réel, conservez les informations utiles au diagnostic et coordonnez la remise en service avec les personnes responsables. Un test de restauration réduit l’incertitude ; il ne garantit pas l’absence de perte ni la disponibilité d’un service tiers.