Le plan d’urgence que personne n’a répété

7 Min. temps de lecture

De nombreuses entreprises disposent d’un plan de réponse aux incidents. Très peu l’ont jamais testé sous pression. C’est précisément cette différence qui fait la différence en cas d’urgence : les organisations qui testent régulièrement leur plan et disposent d’une équipe rodée subissent des coûts de dommages nettement inférieurs à celles dont le plan reste dans un dossier, selon IBM. Le plan, c’est la théorie ; l’exercice sur table, c’est la répétition générale.

En lien :Security Awareness : le taux de clics mesure l’erreur  /  Sauvegarde contre les ransomwares : 3-2-1-1-0 plutôt que 3-2-1

Qu’est-ce qu’un exercice sur table ? Un exercice sur table est une simulation encadrée où l’équipe de crise joue un scénario d’attaque réaliste autour d’une table, sans toucher aux systèmes réels. Les participants prennent des décisions sous pression, identifient les failles du plan de réponse aux incidents et s’entraînent à collaborer avant que l’urgence ne les y oblige.

Le plan dans le dossier face à 03h40

Sur le papier, un plan de réponse aux incidents semble parfait. Les rôles sont définis, les étapes numérotées, les listes de contacts à jour. Puis le téléphone sonne à 03h40 : la moitié des contacts sont en vacances, personne ne sait si la décision d’arrêter la production revient à l’astreinte ou au RSSI. C’est là que l’on voit si le plan était un outil ou un simple placebo.

La faille ne réside rarement dans le document lui-même, mais dans les hypothèses sur la façon dont les gens agissent sous stress. Un plan suppose des esprits clairs, des interlocuteurs disponibles et des responsabilités précises. La réalité offre l’inverse. Un exercice comble cette faille, car il génère précisément les frictions que le document ignore.

Ce que révèle vraiment l’exercice

Les enseignements les plus précieux d’un exercice sur table ne figurent dans aucun plan. Qui a le droit d’arrêter la production sans attendre trois niveaux d’escalade ? Qui parle à l’autorité de surveillance, qui s’adresse à la presse, et qui les empêche de se croiser ? À partir de quand un incident informatique devient-il un sujet pour la direction ? Ces questions se résolvent en quelques minutes lors d’une simulation, mais elles coûtent des heures en cas d’incident réel, pendant lesquelles les dégâts continuent de s’aggraver.

Un bon exercice réunit en outre les bonnes personnes autour d’une table, qui ne se rencontrent jamais autrement : sécurité informatique, service juridique, communication, ressources humaines et direction générale. En cas d’urgence, ces fonctions doivent collaborer en quelques minutes. Si elles se coordonnent pour la première fois lors de l’exercice, c’est déjà un grand pas de franchi, bien avant qu’un attaquant ne se manifeste sur le réseau.

Les lacunes qui reviennent systématiquement

Au fil de nombreux exercices, les mêmes faiblesses se répètent. Premièrement, l’autorité décisionnelle : personne n’ose prendre seul une décision coûteuse, alors elle remonte la hiérarchie et fait perdre du temps. Deuxièmement, la communication externe, soumise à des délais dans le cadre de NIS2 et pourtant souvent laissée dans le flou. Troisièmement, la dépendance à l’égard de certaines personnes, dont le savoir n’est détenu par personne d’autre.

S’ajoute à cela l’interface avec la reprise d’activité. Une cellule de crise peut communiquer de manière irréprochable et échouer malgré tout si la sauvegarde n’a jamais été testée en conditions réelles de restauration. C’est pourquoi l’exercice sur table et le test de restauration vont de pair : l’un vérifie les décisions, l’autre vérifie si la technique peut réellement les soutenir. Les voies de signalement depuis les équipes doivent également figurer dans le même scénario.

Le facteur DACH : NIS2 accélère le compte à rebours

En Allemagne, la communication de crise est soumise à un délai strict. NIS2 impose aux établissements concernés de déclarer un incident significatif au BSI dans les 24 heures suivant sa détection, suivie d’une déclaration plus détaillée sous 72 heures. Si, durant ce laps de temps, on commence seulement à clarifier qui est autorisé à déclarer et quelles informations doivent figurer dans la déclaration, le délai est généralement déjà dépassé. Un exercice sur table intégrant une horloge de déclaration rend ces 24 heures tangibles.

S’ajoute à cela la cellule de crise en tant qu’instance. Dans de nombreuses entreprises du DACH, elle existe sur le papier, mais ne s’est jamais réunie. La codétermination entre en jeu dès que des données personnelles ou des conséquences en droit du travail sont en jeu. Si l’on réunit ces acteurs pour la première fois en situation réelle, on perd un temps que le délai de déclaration ne permet pas.

Comment réussir le premier exercice dans les 90 prochains jours

Le démarrage ne nécessite pas un environnement de simulation coûteux. Un scénario réaliste suffit, comme une infection par ransomware avec chiffrement des systèmes de production, un animateur et deux heures avec les bonnes fonctions dans la salle : sécurité informatique, service juridique, communication, ressources humaines et un membre de la direction générale. Le scénario est escaladé étape par étape, chaque décision est prise à voix haute et consignée. À la fin, il n’y a pas de note, mais une liste des lacunes que le plan n’a pas couvertes. Cette liste est le véritable résultat. En la traitant et en affinant le processus lors de deux à trois exercices par an, le plan dans le dossier se transforme en une capacité opérationnelle en cas d’urgence.

Foire aux questions

À quelle fréquence faut-il tester un plan de réponse aux incidents ?

En règle générale, deux à trois fois par an, complétés après des changements majeurs dans les systèmes, l’organisation ou la réglementation. Plus importante que la fréquence pure est la finalisation de chaque exercice par une liste de lacunes, et que cette liste soit traitée avant le prochain exercice. Ainsi, l’entraînement devient un cycle d’amélioration continue plutôt qu’une simple formalité.

Qu’est-ce qui distingue un exercice sur table d’un véritable test d’intrusion ?

Un exercice sur table évalue les décisions, les rôles et la communication autour d’une table, sans intervenir dans les systèmes. Un test d’intrusion examine la vulnérabilité technique des systèmes eux-mêmes. Les deux se complètent : le pentest montre comment un attaquant pénètre, tandis que l’exercice sur table révèle si l’organisation maîtrise l’incident par la suite.

Qui doit participer à un exercice sur table ?

Plus que la seule informatique. Outre la sécurité IT, le service juridique, la communication d’entreprise, les ressources humaines et un membre de la direction doivent être présents. C’est précisément à ces interfaces que surviennent, en cas d’urgence, les retards coûteux – et c’est justement cette collaboration qui ne peut s’exercer qu’ensemble.

Quel rôle joue la NIS2 dans l’exercice de réponse aux incidents ?

La NIS2 impose aux établissements concernés de signaler un incident significatif au BSI dans les 24 heures suivant sa détection. Un exercice intégrant une horloge de déclaration garantit qu’en cas d’urgence, il est clair qui déclare, ce qui est déclaré et à quel moment le compte à rebours commence.

Quel est le résultat le plus important d’un exercice ?

La liste des lacunes mises au jour. Un bon sentiment ne constitue pas une préparation. Un exercice qui ne révèle aucune faille était généralement trop simple. La valeur naît seulement lorsque les lacunes sont comblées par la suite et que le prochain exercice aborde un scénario plus exigeant.

Lectures recommandées par la rédaction

• Security Awareness : le taux de clics mesure ce qui est faux
• Sauvegarde contre les ransomwares : 3-2-1-1-0 au lieu de 3-2-1
• Zero Trust chez les fournisseurs d’énergie : ce que les audits NIS2 exigent désormais

Plus d’articles du réseau MBF Media

Image de couverture : générée par IA (juin 2026)

Source de l’image : générée par IA (juin 2026), certificat C2PA intégré à l’image

À propos de l'auteur: Alec Chizhik

Plus d'articles de Alec Chizhik