Ressources · 08

Exercice de crise cyber : tester les décisions avant l’incident

Construire un scénario réaliste qui éprouve coordination, continuité, preuves, communication et retour au service sans interrompre la production.

Mis à jour le 27 octobre 2026 · 7 min

Illustration · scène fictive

Ce que ce guide permet

Clarifier qui décide sous pression
Tester les canaux de secours
Valider l’ordre réel de reprise
Transformer les écarts en actions vérifiables

Contrôle express

Le scénario vise-t-il une capacité précise ?
Les coordonnées de crise existent-elles hors ligne ?
Qui peut isoler un système ?
Quel service doit revenir en premier ?
Qui informe clients, autorités et partenaires ?

Méthode pas à pas

01
Définir l’objectif
Choisissez deux ou trois capacités à tester : qualification, décision, confinement, continuité, notification ou restauration. Fixez ce qui reste hors périmètre.
Livrable : mandat et critères de réussite.
02
Construire un scénario plausible
Partez des actifs et dépendances réels. Ajoutez progressivement indisponibilité, information contradictoire, pression externe et contrainte métier sans chercher le spectaculaire.
Livrable : scénario maître confidentiel.
03
Préparer rôles et injects
Désignez direction d’exercice, observateurs et participants. Chaque inject doit provoquer une décision observable, pas seulement transmettre une nouvelle.
Livrable : chronologie et fiches d’inject.
04
Jouer sans piéger
Annoncez les règles, distinguez clairement simulation et incident réel, protégez la production et laissez les équipes utiliser leurs procédures habituelles.
Livrable : journal des décisions et communications.
05
Débriefer à chaud et à froid
Recueillez d’abord les faits observés, puis analysez causes, arbitrages et dépendances. Séparez défaut documentaire, manque d’autorité et problème technique.
Livrable : constats sourcés et enseignements.
06
Fermer les écarts
Donnez à chaque action un responsable, une date et une preuve. Rejouez les étapes critiques ou testez la restauration au lieu de clore sur déclaration.
Livrable : plan d’amélioration et test de confirmation.

Exemple d’application

Situation illustrative

Un exercice simule l’indisponibilité de l’outil de support pendant un incident. Les participants doivent qualifier le signal, joindre les décideurs hors de cet outil et choisir quand informer les personnes concernées.

Décision et preuve attendue

Le compte rendu conserve les décisions, leurs heures, les informations manquantes et trois corrections assignées avec date de nouveau test.

Indicateurs de pilotage

Indicateur	Ce qu’il mesure	Première action
Temps de mobilisation	Délai pour réunir les rôles indispensables	Corriger annuaire et suppléances
Temps de décision	Délai entre signal qualifié et décision explicite	Clarifier seuils et autorités
Ordre de reprise	Services restaurés selon la priorité métier validée	Aligner dépendances techniques et besoins
Actions closes	Écarts corrigés avec une preuve vérifiée	Rejouer les points les plus risqués

Erreurs fréquentes

Écrire un scénario trop complexe
Évaluer les personnes au lieu du dispositif
Oublier clients, fournisseurs et autorités
Produire un rapport sans test de clôture

Questions fréquentes

Un exercice doit-il couper des systèmes ?

Non. Un exercice sur table teste les décisions sans action technique réelle. Les tests de restauration ou de bascule doivent suivre un périmètre séparé et sécurisé.

Qui doit participer ?

Les rôles qui prennent une décision ou exécutent une action critique, avec leurs suppléants lorsque la continuité dépend d’eux.

Combien de temps faut-il prévoir ?

Deux à quatre heures suffisent souvent pour un objectif ciblé, auxquelles s’ajoutent préparation, débrief et suivi des actions.

Incident, vulnérabilité ou fuite : choisir le bon interlocuteur

Un CSIRT accompagne un périmètre défini, appelé constituency : une organisation, un secteur ou un public. Son pays et son adhésion à FIRST ne suffisent pas à établir votre éligibilité, sa disponibilité ou les services proposés. Vérifiez ces trois points sur son site officiel.

Qualifier les faits
Vérifier le périmètre
Confirmer le canal officiel

Incident sur votre système

Contactez l’équipe interne ou le prestataire désigné dans votre plan de réponse. Cherchez un CSIRT couvrant votre organisation si une coordination externe est nécessaire.

Vérifiez le public accompagné, les modalités de signalement et les horaires ; un formulaire public ne garantit pas une réponse immédiate.

Chercher un CSIRT

Faille dans un produit tiers

Consultez la politique de divulgation de l’éditeur ou son équipe de sécurité produit (PSIRT). Le fichier /.well-known/security.txt peut indiquer le contact, la politique et le chiffrement.

Contrôlez le domaine, le champ Expires et le périmètre de la politique. security.txt n’autorise aucun test ; convenez du canal avant de transmettre une preuve sensible.

Comprendre la divulgation

Données personnelles concernées

Associez le responsable du traitement et le délégué à la protection des données, s’il existe, à l’équipe de réponse technique.

L’assistance technique et une éventuelle notification réglementaire sont des démarches distinctes. Faites déterminer l’autorité compétente, les conditions et les délais applicables à votre situation.

Consulter le dossier données

Préparer un premier contact utileChronologie avec fuseau horaire, service concerné et faits observés, séparés des hypothèses.Périmètre et impact connus, mesures déjà prises et personne habilitée à échanger.Résumé expurgé et canal de partage validé ; aucun mot de passe, jeton ou journal complet dans un formulaire public.

Cette liste prépare l’échange ; elle ne mesure ni la gravité ni la résolution de l’incident. Les choix restent dans cette page et ne sont pas envoyés.

Repères : FIRST, RFC 9116 et CNIL (cadre français). FIRST · CSIRT Services Framework 2.1 RFC 9116 · security.txt CNIL · Violations de données personnelles

Exercer les décisions de reprise

Six injects pour éprouver les décisions de reprise

Exercice sur table fictif : un prestataire héberge un service de traitement de demandes. Les horaires T+ sont choisis pour l’animation et ne fixent aucun délai réglementaire ou niveau de service. Chaque carte propose une observation et une décision à expliquer ; aucune action technique ni communication réelle ne doit être exécutée depuis cette page.

T+0 · Signal fournisseur incertain

Le fournisseur annonce une anomalie ; un utilisateur rapporte une indisponibilité, sans diagnostic confirmé.

Rôles à mobiliser: Coordination incident, responsable du service, relation fournisseur.
Décision à rendre explicite: Qui vérifie la source, qualifie l’impact et décide d’activer le plan ?
Preuve attendue: Signal initial, canal de confirmation, propriétaire du dossier et prochain point de situation.
Point à débriefer: Confondre une déclaration du fournisseur avec une cause établie.

T+12 · Sauvegarde au vert

Un tableau de bord affiche une copie terminée, mais aucun contrôle du candidat n’est fourni.

Rôles à mobiliser: Équipe sauvegarde, réponse à incident, responsable de reprise.
Décision à rendre explicite: Quelles preuves sont nécessaires avant d’autoriser l’usage de cette copie ?
Preuve attendue: Résultats de vérification du candidat, origine et décision d’acceptation ou de refus.
Point à débriefer: Assimiler succès du travail et intégrité du moyen de restauration.

T+25 · Heures contradictoires

Deux journaux présentent des heures différentes ; l’un ne précise pas son fuseau.

Rôles à mobiliser: Analyste, exploitant du fournisseur, personne tenant le journal.
Décision à rendre explicite: Comment conserver les deux observations sans reconstruire une fausse chronologie ?
Preuve attendue: Heures originales, fuseaux connus ou inconnus, heure de collecte et rapprochement documenté.
Point à débriefer: Corriger silencieusement l’heure source ou effacer la contradiction.

T+40 · Candidat rejeté

Un contrôle révèle une anomalie d’intégrité sur le candidat prévu. Une copie plus ancienne existe.

Rôles à mobiliser: Responsable de reprise, propriétaire des données, coordination incident.
Décision à rendre explicite: Qui décide d’un autre point de restauration et accepte les conséquences sur les données ?
Preuve attendue: Rejet motivé, nouveau candidat, contrôles et impact attendu sur le service et les données.
Point à débriefer: Sacrifier un contrôle d’intégrité pour tenir un horaire de démonstration.

T+60 · Écran revenu, parcours en échec

La connexion fonctionne, mais une demande ne peut pas être enregistrée dans un système dépendant.

Rôles à mobiliser: Propriétaire métier, exploitation, responsable de la dépendance.
Décision à rendre explicite: Le service est-il utilisable, dégradé ou encore indisponible au regard des critères convenus ?
Preuve attendue: Test du parcours complet, dépendance bloquante, décision métier et limites communiquées.
Point à débriefer: Déclarer une reprise complète à partir d’un seul écran accessible.

T+85 · Pression de communication

Une demande publique réclame une heure de retour certaine alors que la validation n’est pas terminée.

Rôles à mobiliser: Communication, coordination incident, direction et fournisseur critique.
Décision à rendre explicite: Quel message approuvé dit les faits confirmés, les limites et le prochain point sans promettre un délai non établi ?
Preuve attendue: Version du message, approbateur, destinataires prévus et trace de coordination fournisseur.
Point à débriefer: Présenter une estimation provisoire comme un engagement vérifié.

Quatre questions pour fermer une observation d’exercice

Quatre questions pour fermer une observation d’exercice
Question	Preuve de progression	Limite
L’autorité était-elle connue ?	Décision effectivement prise par la fonction prévue, avec suppléance testée.	La présence d’un organigramme ne prouve pas que la personne est joignable.
Le contrôle a-t-il été exécuté ?	Pièce du test et résultat relu dans son périmètre.	Une procédure seule ne vaut pas preuve d’exécution.
L’écart a-t-il un propriétaire ?	Action attribuée, échéance locale et critère de vérification.	Un pourcentage global de réussite ne décrit pas le risque résiduel.
La correction a-t-elle été rejouée ?	Même situation reprise après correction, avec résultat comparable.	La clôture documentaire ne remplace pas une vérification utile.

Explorer les repères NIST et la chronologie →

Références primaires et limites

Les identifiants et le sens des résultats proviennent du CSF 2.0 ; les recommandations de réponse et de reprise sont précisées dans SP 800-61r3. Les tableaux de preuves, horaires et scénarios sont pédagogiques, sans résultat client, certification ou notification réelle.

NIST · SP 800-61 Rev. 3 · Final · 2025-04-03
Community Profile CSF 2.0 ; remplace / supersedes Rev. 2
NIST · SP 800-61r3 — recommandations détaillées / detailed recommendations · April 2025
Pages imprimées / printed pages 27–29, 34–35 : RS.MA, RS.AN, RC.RP, RC.CO
NIST · Cybersecurity Framework 2.0 · 2024-02-26 · NIST CSWP 29
Appendix A, printed pages 22–23 : official outcome identifiers
NIST · SP 800-184 — Guide for Cybersecurity Event Recovery · Final · 2016-12-22
Recovery planning, playbooks, testing and improvement

Références relues le 2026-10-22

OSINT : preuves et conservation

Éprouver le dossier de conservation pendant l’exercice

Introduisez une copie à l’empreinte différente, une réception manquante et une heure sans fuseau. L’objectif est de constater les limites de la preuve et de choisir la prochaine vérification.

Tester qu’un dérivé expurgé garde sa filiation sans remplacer l’objet de référence.
Vérifier qui peut modifier ensemble l’objet, son empreinte et le journal.
Faire apparaître les lacunes dans le compte rendu au lieu de les combler par hypothèse.

Voir la filiation des copies et les huit cas de conservation →

Sources vérifiées le 2026-10-22 · NIST · Digital Evidence Preservation · NIST IR 8387 · Full report · NIST · SP 800-86 · NIST SP 800-86 · Full report · NIST · FIPS 180-4 · Secure Hash Standard

Explorer les résultats du NIST CSF 2.0

Évaluer une préparation, puis la faire évoluer

Un exercice ne remplace pas la gestion du risque. Il permet d’observer des décisions, des dépendances et des lacunes qui alimentent la préparation.

ID.IM-02 : identifier des améliorations à partir des tests et exercices.
RS.MA : qualifier, prioriser et coordonner la gestion d’incident.
RC.RP : examiner l’intégrité et le fonctionnement du service rétabli.
Attribuer les actions de suite et vérifier leur effet, sans présenter un scénario fictif comme un incident réel.

Explorer les résultats et les preuves à examiner →

NIST CSWP 29 · CSF 2.0 · 2024-02-26 · 2026-10-22

Références officielles

Date de consultation des références : 22/10/2026. La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.