Un incident arrive. Vous le résolvez. Et ensuite ? Le post-mortem est l'outil qui transforme un incident en apprentissage. Mais mal fait, il devient un rituel inutile.
Le post-mortem qui ne sert à rien
Le post-mortem typique : un document Word de 3 pages, écrit par le manager, qui dit "l'incident était dû à une erreur humaine. Nous avons rappelé à l'équipe de faire attention." Ce post-mortem ne sert à rien. Il ne prévient pas le prochain incident. Il blame au lieu d'apprendre.
Le post-mortem qui sert
Un bon post-mortem répond à 5 questions :
- Que s'est-il passé ? Timeline factuelle, minute par minute. Pas d'interprétation, juste les faits.
- Pourquoi ça s'est produit ? Analyse des causes profondes (root cause analysis). Pas "erreur humaine" — pourquoi l'humain a fait cette erreur ?
- Comment l'avons-nous détecté ? Par une alerte ? Par un utilisateur ? Par un client ? Le temps de détection est crucial.
- Comment l'avons-nous résolu ? Quelles actions ont été prises ? Dans quel ordre ? Qu'est-ce qui a marché ? Qu'est-ce qui n'a pas marché ?
- Comment éviter que ça se reproduise ? Actions concrètes, avec un responsable et une date. Pas "faire attention" — "ajouter un test automatisé qui vérifie X".
La blameless culture
Le post-mortem doit être blameless. Pas de blame, pas de culpabilisation. Pourquoi ? Pas par gentillesse, mais par efficacité. Si les ingénieurs ont peur d'être blâmés, ils cachent les incidents. Ils ne reportent pas les erreurs. Et les mêmes incidents se reproduisent.
La blameless culture ne signifie pas l'absence de responsabilité. Elle signifie que la responsabilité est collective, pas individuelle. L'ingénieur qui a fait l'erreur n'est pas responsable — le système qui a permis l'erreur est responsable.
Les 5 pourquoi
La technique des 5 pourquoi est simple : posez "pourquoi" 5 fois pour remonter à la cause profonde.
Exemple :
- Pourquoi le service est-il tombé ? → Parce que la base de données était injoignable.
- Pourquoi la base était-elle injoignable ? → Parce que le disque était plein.
- Pourquoi le disque était-il plein ? → Parce que les logs n'étaient pas rotated.
- Pourquoi les logs n'étaient-ils pas rotated ? → Parce que le job de rotation a été désactivé.
- Pourquoi le job a-t-il été désactivé ? → Parce qu'un déploiement a écrasé la configuration sans que personne ne le remarque.
La cause profonde n'est pas "le disque était plein". C'est "le déploiement écrase la configuration sans validation". La solution n'est pas "ajouter un disque". C'est "valider la configuration avant le déploiement".
Le follow-up
Un post-mortem sans follow-up est inutile. Les actions identifiées doivent être suivies. Un tracker doit vérifier que chaque action est implémentée dans les délais. Si 80% des actions ne sont pas implémentées, le post-mortem était du temps perdu.
La règle : moins d'actions, mais implémentées. Mieux vaut 3 actions concrètes et implémentées que 20 actions théoriques et oubliées.
Le post-mortem comme capital d'apprentissage
Les post-mortems accumulés forment une base de connaissance précieuse. Quand un nouvel incident arrive, consultez les post-mortems passés. Souvent, un incident similaire a déjà été analysé. Les solutions sont déjà identifiées. Le temps de résolution est divisé par 2.
Les entreprises qui font de bons post-mortems réduisent leur temps de résolution d'incident de 50% en 2 ans. C'est le ROI du post-mortem : moins d'incidents, plus courts, mieux gérés.
L'art du post-mortem n'est pas dans le document. C'est dans la culture. Une culture qui apprend de ses erreurs au lieu de les cacher. Une culture qui transforme chaque incident en amélioration. C'est ça, la vraie résilience.
Et vous ?
Vos post-mortems ne servent à rien ? Aprilium forme vos équipes à la blameless culture et aux post-mortems qui préviennent les incidents au lieu de les subir.
Former mes équipes