Le rapport post-incident : tirer les leçons
9 min · Débutant · 7 août 2026
Une chronologie, reconstruite à partir de ce qui a été documenté
Le chapitre précédent insistait sur la documentation en temps réel, précisément parce qu’elle devient ici la matière première : reconstituer après coup une chronologie précise, sans notes prises sur le moment, produit presque toujours une version incomplète ou approximative.
Compromission initiale -> [dwell time] -> Detection -> Confinement -> Eradication -> Retour a la normaleLe dwell time, la durée entre la compromission et sa détection, résume à lui seul une bonne partie de l’efficacité du dispositif de détection mis en place dans les chapitres précédents de ce cours : plus il est long, plus l’attaquant dispose de temps pour progresser avant d’être repéré.
Sans blâme, pas sans conséquence
Astuce
Une culture « sans blâme » ne signifie pas « sans action corrective ». Elle déplace la question de « qui a fait l’erreur » vers « quel facteur systémique a permis cette erreur, et comment le corriger ». Cette reformulation encourage un récit honnête plutôt que défensif, condition d’un rapport réellement exploitable.
Ce qu’un bon rapport post-incident change concrètement
- Cause racine et facteurs contributifs, distingués clairement l’un de l’autre.
- Actions concrètes, avec un responsable et une échéance, pas des intentions vagues.
- Ajustement des règles de détection (chapitre 4) à la lumière de ce qui a réellement fonctionné ou manqué.
- Mise à jour du plan de réaction (chapitre 5) si une étape s’est révélée plus lente ou confuse que prévu en conditions réelles.
Sans cette boucle de retour vers les chapitres précédents, un incident reste un évènement isolé plutôt qu’une amélioration durable du dispositif de détection et de réaction.