Un bon exercice de réponse à incident confronte l’équipe à un scénario plausible, des informations incomplètes et des décisions horodatées. Il teste les dépendances réelles — accès, journaux, contacts, autorités — puis transforme chaque écart en amélioration vérifiable.
année de la nouvelle référence NIST de réponse à incident
La SP 800-61 Rev. 3, publiée en avril 2025, intègre la réponse à incident dans l’ensemble de la gestion du risque CSF 2.0, au lieu de la traiter comme une phase isolée.
NIST — SP 800-61 Rev. 3Définir un objectif testable
Évitez l’objectif vague “tester le plan”. Choisissez une capacité : révoquer un compte compromis, isoler un hôte critique, décider l’arrêt d’un service ou coordonner la notification. Fixez les participants, le périmètre et les conditions d’arrêt de l’exercice.
Le scénario part d’un actif et d’un impact métier. Les détails techniques ne sont utiles que s’ils créent une décision ou révèlent une dépendance.
Écrire les injects comme une chronologie
Chaque inject apporte un signal : alerte EDR, appel utilisateur, connexion cloud, indisponibilité ou demande média. Précisez l’heure simulée, le destinataire, l’information connue et la décision attendue. Ajoutez une contradiction réaliste pour tester la gestion de l’incertitude.
Ne donnez pas immédiatement la solution. Observez où l’équipe cherche l’information, qui possède l’autorité et comment les hypothèses sont consignées.

Mesurer ce qui détermine l’issue
Chronométrez la qualification, l’escalade et le confinement, mais notez aussi la qualité : périmètre explicite, preuves conservées, conséquences évaluées et décision communiquée. Une action rapide mais non traçable peut compliquer la suite.
- Temps jusqu’à la première qualification
- Temps jusqu’au propriétaire de décision
- Accès réellement disponibles
- Précision du périmètre
- Journal des décisions et hypothèses
Fermer les écarts par un nouveau test
Le compte rendu doit distinguer procédure absente, outil indisponible, compétence à renforcer et décision non attribuée. Chaque action reçoit un responsable et une condition de vérification.
Rejouez l’étape concernée après correction. Un document mis à jour ne prouve pas que l’accès fonctionne ou que l’équipe sait exécuter le geste sous contrainte.
Matrice de décision opérationnelle
| Étape | Question à résoudre | Résultat attendu |
|---|---|---|
| Scénario | Fixer objectif, périmètre et injects. | Créer une pression réaliste |
| Décision | Observer rôles, escalade et arbitrages. | Horodater les choix |
| Récupération | Tester dépendances et retour au service. | Valider les priorités |
Mesurer autrement
Le succès n’est pas de finir le scénario : c’est de découvrir les écarts avant un incident réel et de prouver leur correction.
Le bon niveau de contrôle dépend du contexte, des actifs exposés et de l’impact métier : documentez les hypothèses, mesurez le résultat et réévaluez après chaque changement significatif.
Questions fréquentes
Combien de temps dure un exercice ?
Un tabletop ciblé peut durer 60 à 90 minutes ; un exercice technique complet peut s’étendre davantage. L’objectif détermine la durée.
Faut-il prévenir les participants ?
Pour un premier exercice, oui sur le cadre et les règles. La surprise n’est utile que si elle sert explicitement un objectif maîtrisé.
Quel scénario choisir ?
Celui qui menace un service critique et expose une dépendance que l’organisation veut réellement tester.
Sources officielles
Achraf Hachimi
Ingénieur SOC Senior / CSIRT certifié CISSP, spécialisé en Incident Response, Threat Hunting et Detection Engineering. Huit ans d’expérience en environnements critiques avec Splunk ES, Microsoft Defender XDR, SentinelOne et Cybereason.
