Une restauration de fichier réussie est une information utile. Elle ne répond pas à toutes les questions de reprise : l’application démarre-t-elle, les personnes autorisées peuvent-elles travailler, et les données sont-elles cohérentes ? Voici un exercice de travail pour relier la sauvegarde à l’activité.
En résumé
- La reprise se vérifie sur un service et un parcours métier définis.
- L’annuaire, le réseau, les certificats, les secrets et les dépendances externes peuvent conditionner le redémarrage.
- Un exercice doit préciser le point de restauration retenu, l’ordre de reprise et les critères d’acceptation.
- Les durées observées doivent être distinguées des objectifs et des engagements contractuels.
- Le bilan de l’exercice produit des actions attribuées et une date de nouvelle vérification.
Choisir une activité assez précise pour être testée
« Restaurer le système d’information » est trop vaste pour un premier exercice. Choisissez un service : consulter un dossier, enregistrer une commande fictive ou produire un document de test. Définissez qui doit pouvoir réaliser ce parcours et comment en constater le résultat.
Exemple fictif : une application de gestion redémarre et affiche sa page d’accueil. Pourtant, les utilisateurs ne peuvent pas se connecter parce que l’annuaire nécessaire n’a pas été repris. Le test technique du serveur a réussi ; le parcours métier reste indisponible.
Préparer les dépendances avant de démarrer
- Identités : comptes, droits, mécanismes d’authentification et accès de secours autorisés.
- Infrastructure : réseau, résolution de noms, certificats et stockage.
- Données : point de restauration, dépendances entre bases et fichiers, critères de cohérence.
- Applications : versions, configurations, secrets et ordre de démarrage.
- Tiers : services externes, contacts et solutions de continuité prévues.
Cette cartographie n’a pas besoin d’être parfaite pour commencer, mais les inconnues doivent rester visibles. Une dépendance découverte pendant l’exercice est un résultat à traiter, pas une raison de masquer le test.
Écrire un protocole de reprise
Le protocole indique le périmètre, les participants, les actions autorisées et les conditions d’arrêt. Utilisez un environnement isolé adapté, des comptes de test et des données synthétiques ou autorisées. Évitez qu’une restauration de démonstration envoie de vrais emails ou déclenche des transactions réelles.
Définissez avant le départ ce qui sera mesuré : moment de lancement, disponibilité technique, puis validation métier. Notez les pauses et les interventions manuelles. Une durée annoncée sans périmètre ni conditions d’essai se réutilise mal pour planifier une crise.
Vérifier la qualité de la reprise
Faites exécuter le parcours convenu par son propriétaire métier. Vérifiez la cohérence des données, les autorisations et les échanges nécessaires. Contrôlez également la supervision et la sauvegarde du service repris : redémarrer un système sans suivi ni nouvelle protection crée un état temporaire qu’il faut maîtriser.
Une reprise après incident nécessite aussi de traiter la cause et le risque de réintroduction. Le point de restauration acceptable dépend de l’investigation ; ce choix ne doit pas être déduit automatiquement de la sauvegarde la plus récente.
Transformer le test en amélioration
Terminez par trois listes : ce qui a fonctionné, ce qui a nécessité une improvisation et ce qui n’a pas été vérifié. Chaque écart devient une action avec un responsable et une prochaine date d’essai. Les objectifs de délai et de perte de données se discutent avec les métiers à partir des besoins et des résultats observés.
La préparation collective peut commencer par notre exercice de crise de 45 minutes. Il travaille les décisions et les responsabilités ; il ne remplace pas un test technique de restauration. Le guide ANSSI sur les exercices apporte une méthode pour concevoir un entraînement adapté.