Continuité du service

Préparer et tester la restauration d’un site

Vérifier qu’une sauvegarde permet réellement de reprendre les commandes, contenus et demandes après un incident.

Illustration photographique : vérification d’un site sur ordinateur et téléphone

Illustration photographique générée par IA : scène fictive, sans représentation d’un client ou d’une équipe réelle.

La réponse en bref

Une procédure de reprise testée et attribuée.

Une sauvegarde doit couvrir les fichiers, les données et les dépendances nécessaires à la reprise. Testez sa restauration dans un environnement isolé, avec les envois, paiements et intégrations réelles désactivés. Mesurez la durée et les données perdues, puis conservez un compte rendu et un responsable de décision.

Une archive présente sur le serveur peut être incomplète ou inutilisable. Elle peut aussi disparaître avec le serveur. Le plan doit prévoir une copie séparée, une rétention adaptée et un contrôle de lecture.

Les besoins diffèrent : un site vitrine change peu, un commerce en ligne reçoit des commandes et un outil métier enregistre des opérations. Définissez combien de données peuvent être perdues et combien de temps le service peut rester interrompu avant de choisir une fréquence.

Ce guide décrit une préparation à la reprise. En cas d’intrusion, la remise en ligne exige aussi de comprendre l’incident et de corriger sa cause ; restaurer la même faille ne résout pas le problème.

Méthode en 6 étapes

Passer d’une intention générale à des décisions vérifiables.

Chaque étape produit une information qui peut être relue, attribuée et utilisée dans la suivante.

Inventorier

Identifiez fichiers, base, médias, dépendances, versions, tâches planifiées et services externes. Listez les éléments qui ne sont pas inclus dans la copie de l’hébergeur.

Fixer les objectifs

Décidez avec le métier de la durée de reprise et de la perte de données acceptable. Une cible contractuelle doit être distinguée d’un résultat de test.

Préparer les copies

Prévoyez rétention, copie séparée et protection adaptée. Vérifiez les erreurs de sauvegarde et la disponibilité des moyens de restauration sans exposer les accès.

Isoler le test

Bloquez l’indexation, limitez l’accès et désactivez courriels, paiements, notifications et synchronisations de production. Utilisez des données de test quand cela suffit.

Restaurer et essayer

Reconstituez le site puis testez pages, médias, administration et parcours essentiels. Comparez les derniers enregistrements attendus avec ceux réellement retrouvés.

Documenter la reprise

Consignez versions, durée, anomalies, données manquantes et décision. Corrigez puis retestez les écarts bloquants et planifiez la prochaine répétition.

Référentiel opérationnel

Contrôles d’un exercice de restauration.

Utilisez ce tableau comme base d’entretien, de brief ou de revue. Adaptez la fréquence et le niveau de preuve au risque réel du projet.

Contrôles d’un exercice de restauration
Élément	Essai	Preuve attendue
Fichiers	Ouvrir pages et médias	Aucun fichier essentiel absent
Base	Comparer les derniers enregistrements	Date et volume conformes à la copie choisie
Versions	Reconstituer le logiciel et ses dépendances	Versions et procédure documentées
Formulaire	Soumettre vers un transport de test	Confirmation et message dans le bac de test
Commande	Parcourir un paiement en mode test	Aucune transaction réelle ni double synchronisation
Administration	Tester les rôles prévus	Accès conforme et modifications possibles
Services externes	Vérifier les configurations sans solliciter la production	Dépendances recensées et étapes de reconnexion
Reprise	Chronométrer et qualifier les pertes	Durée mesurée, écarts et décision signée

Avant de valider

8 points de contrôle.

Une vérification courte vaut mieux qu’une intention implicite. Conservez une preuve proportionnée : document, capture, résultat de test ou décision datée.

ContrôlerLa copie choisie est datée et lisible.
ContrôlerLes données et fichiers correspondent au même état métier.
ContrôlerUne copie reste disponible hors du serveur principal.
ContrôlerL’environnement d’essai ne peut pas envoyer ni encaisser réellement.
ContrôlerLes parcours essentiels sont testés jusqu’au résultat.
ContrôlerLa durée observée est comparée à l’objectif convenu.
ContrôlerLa cause d’un incident est traitée avant une remise en production.
ContrôlerLe responsable, les critères de reprise et le prochain test sont connus.

Questions fréquentes

Réponses directes avant de décider.

Ces repères restent généraux. Le contexte, les outils, l’organisation et les obligations applicables peuvent modifier la réponse.

La sauvegarde de l’hébergeur suffit-elle ?

Vérifiez le contrat : périmètre, fréquence, rétention et conditions de restauration. Une copie de fichiers peut ne pas inclure la base ni les services externes. Testez le résultat avant de vous y fier.

Quelle fréquence choisir ?

Elle dépend du volume de changements et de la perte acceptable. Définissez la cible avec les responsables métier puis vérifiez que la fréquence et la conservation permettent de l’atteindre.

Pourquoi désactiver les courriels lors du test ?

Une copie peut rejouer des notifications, commandes ou relances anciennes. Un transport de test et des intégrations isolées permettent de vérifier le parcours sans contacter de vraies personnes.

Faut-il retester après une migration ?

Oui : les versions, chemins, services et volumes peuvent changer. Révisez la procédure et répétez les étapes qui dépendent de la nouvelle architecture.

Sources et prolongements

Vérifier le cadre et poursuivre la préparation.

Cybermalveillance : sauvegarder ses données CFSN : recette des parcours