Un plan de reprise devient crédible lorsqu’un service utilisable peut être restauré.
Un plan de reprise devient crédible lorsqu’un service utilisable peut être restauré. Le RTO exprime le temps cible de remise en service ; le RPO exprime la fenêtre de perte de données tolérée. Définissez-les à partir des conséquences métier et testez l’application complète.
Définir le service à restaurer
Listez parcours, bases, identité, DNS, certificats et dépendances externes. Précisez le mode dégradé acceptable et l’accès aux moyens de secours si les systèmes habituels sont indisponibles. Un objectif de base de données ne suffit pas si l’application ne peut pas se reconnecter ensuite.
Préparer un exercice isolé
Utilisez un jeu autorisé, protégé ou synthétique et bloquez les effets réels involontaires : messages, paiements et appels fournisseurs. Notez point de sauvegarde, début et étapes de restauration. Choisissez un scénario explicite, comme la perte d’une base, et ses hypothèses. Mesurez jusqu’à la validation métier plutôt qu’à la fin de l’import.
Prouver temps et perte observés
Comparez les données restaurées à des repères connus et identifiez la dernière opération récupérable. Vérifiez droits, tâches et montants ou compteurs importants. Notez les étapes manuelles et dépendances qui empêchent l’objectif. Corrigez puis rejouez le chemin concerné. Un exercice réussi vaut pour le scénario et l’état testés, pas pour toutes les catastrophes possibles.
Un exemple à vérifier
Restaurez une copie de test avec sorties externes bloquées. Une connexion réussie ne suffit pas : vérifiez une commande connue, ses droits et sa tâche de fond au point de sauvegarde. Mesurez également préparation, accès aux clés et validation métier. Une configuration historique absente reste une lacune malgré un import réussi. Le compte rendu doit distinguer cette dépendance de la perte de données et lui attribuer une correction.
- Service associé
- Un runbook de production utilisable par une petite équipe
- Organiser l’astreinte sans équipe SRE dédiée
Questions fréquentes
Quelle différence entre RTO et RPO ?
Temps de restauration contre fenêtre de perte de données acceptable.
Une sauvegarde réussie prouve-t-elle la reprise ?
Non. Restauration, dépendances et validation doivent fonctionner aussi.
Peut-on utiliser des données de production ?
Uniquement avec autorisation et protection ; un jeu synthétique peut convenir davantage.
À quelle fréquence tester ?
Selon risque et changements, notamment après modification importante de l’architecture.
Que faire si la cible est manquée ?
Documenter résultat et cause, puis modifier le système ou revoir explicitement l’exigence.
Transformons votre besoin en périmètre réalisable
Partagez le parcours utilisateur, les intégrations et les contraintes de lancement. Nous pouvons préparer une estimation avec hypothèses et exclusions.
Pour aller plus loin
Un runbook de production utilisable par une petite équipe
Un runbook aide à passer d’un symptôme précis à une décision sûre.
Organiser l’astreinte sans équipe SRE dédiée
Une petite équipe peut assurer une astreinte utile si ses engagements correspondent à ses moyens.
Niveaux de gravité des incidents : une matrice d’escalade
La gravité décrit l’impact métier actuel ou crédible, pas le ton d’un message de journal.