Scénarisation et critères d'évaluation
Écrire des scénarios d'exercice crédibles et définir des critères de réussite mesurables avant de les jouer.
À retenir
- Un scénario crédible s'appuie sur des incidents réels documentés et une structure contexte/déclencheur/injects.
- Les injects testent la capacité d'adaptation au-delà du simple respect du plan écrit.
- Les critères de réussite (RTO, RPO, intégrité, communication) doivent être définis avant l'exercice, pas après.
- Un observateur indépendant garantit une évaluation objective et une collecte de preuves fiable.
Un bon scénario ressemble à un incident réel
Un scénario d'exercice doit être suffisamment détaillé pour forcer les participants à prendre de vraies décisions, mais rester réaliste par rapport aux menaces documentées pour l'organisation. S'inspirer des post-mortems publics (Uptime Institute, retours d'expérience ANSSI) permet d'ancrer le scénario dans des causes réelles : perte de site, corruption silencieuse de données, ransomware chiffrant les sauvegardes en ligne, erreur humaine sur une commande destructive.
Structure type d'un scénario
- Contexte : date, heure, système impacté, contrainte (ex. « lundi 3h du matin, hors astreinte renforcée »).
- Déclencheur : événement initial (alerte, appel client, détection SOC).
- Injects : événements complémentaires introduits en cours d'exercice pour complexifier ou orienter le scénario (ex. « le site de secours signale à son tour une lenteur réseau »).
- Contraintes réalistes : indisponibilité d'une personne clé, documentation partiellement obsolète, fenêtre de communication limitée.
- Fin de partie : condition d'arrêt claire (service rétabli, décision de bascule prise, délai maximal atteint).
Point clé
les injects sont l'outil principal pour tester la capacité d'adaptation de l'équipe, au-delà du simple déroulé du plan écrit.
Définir des critères de réussite avant de jouer
| Critère | Exemple de mesure | Source de vérité |
|---|---|---|
| RTO respecté | Temps entre déclenchement et service restauré | Horodatage des tickets/monitoring |
| RPO respecté | Volume de données perdu vs seuil accepté | Comparaison horodatage sauvegarde/incident |
| Intégrité de la restauration | Checksum, tests fonctionnels post-restauration | Rapport de validation applicative |
| Communication de crise | Délai de première notification aux parties prenantes | Journal de cellule de crise |
| Suivi de procédure | Écarts entre plan écrit et actions réalisées | Observateur dédié pendant l'exercice |
Attention
évaluer uniquement le respect du RTO sans vérifier l'intégrité des données restaurées donne une fausse impression de succès ; une restauration rapide mais corrompue est un échec du critère RPO/intégrité, pas une réussite.
Le rôle de l'observateur indépendant
Un exercice crédible désigne un ou plusieurs observateurs qui ne participent pas à la résolution mais chronomètrent, notent les écarts et collectent les preuves (captures d'écran, horodatages). Cette séparation des rôles évite que les acteurs de l'exercice évaluent eux-mêmes leur propre performance.
Sur le terrain
dans les exercices menés sur des infrastructures de colocation ou de cloud partagé, prévenir formellement les équipes voisines et le NOC évite qu'une alerte simulée ne déclenche une véritable escalade multi-équipes, un classique des faux positifs coûteux en temps.
Astuce
rédigez les critères de réussite en une phrase testable (« la base de données est restaurée à moins de 15 minutes de données perdues en moins de 4 heures ») plutôt qu'en objectif vague (« la reprise doit être rapide »).