Des post-mortems qu’on lit vraiment
La plupart des post-mortems finissent dans un dossier que personne n’ouvre. Quelques changements de structure en font le document le plus utile de votre équipe.
Demandez à une équipe où vivent ses post-mortems : on vous enverra un lien vers un dossier. Demandez quand quelqu’un a ouvert pour la dernière fois un post-mortem qui n’était pas le sien : silence.
C’est du gâchis. Un bon post-mortem est le support de formation le moins cher qui existe : une vraie panne, dans votre vrai système, avec la vraie séquence de décisions qui y a mené. Les équipes en écrivent. Mais elles les écrivent pour fermer un ticket, pas pour qu’on les lise.
Écrire pour l’ingénieur qui arrivera l’an prochain
Le lecteur à garder en tête n’est pas l’incident commander. C’est l’ingénieur qui arrivera dans douze mois, sera appelé sur le même service, et cherchera du contexte à 2h du matin.
Ce lecteur a besoin de :
- Un résumé lisible en trente secondes. Ce qui a cassé, qui a été touché, combien de temps, et ce qui a réparé.
- Une chronologie des décisions, pas seulement des événements. « 14h12 : rollback du déploiement » est un événement. « 14h12 : rollback parce que le taux d’erreur collait à la fenêtre de déploiement ; la base n’avait pas encore été vérifiée » est une décision. C’est de ça qu’on apprend.
- Ce qui a rendu la chose difficile. Dashboards manquants, alertes trompeuses, responsabilités floues. C’est là que se cachent les vrais constats.
« Sans blâme », c’est une structure, pas un ton
« Sans blâme » ne veut pas dire poli. Ça veut dire que le document est construit pour qu’une personne ne soit jamais la cause racine.
Un test simple : si une phrase commence par « X a oublié de… », réécrivez-la en « le process permettait de… ». La checklist de déploiement n’imposait pas de dry-run de migration : ça, on peut le corriger. Alex a oublié le dry-run : ça, on peut seulement s’en vouloir.
Les gens qui s’attendent à être blâmés cachent des détails. Les autres les partagent. La qualité de vos post-mortems est plafonnée par le niveau de sécurité qu’il y a à y être honnête.
Des actions qui se ferment
L’échec le plus courant qu’on observe n’est pas la rédaction. Ce sont les actions : dix, vagues, sans responsable, rangées dans un backlog trié une fois par trimestre.
On pousse les équipes vers quelques règles simples :
- Peu nombreuses. Trois à cinq actions. Si tout est prioritaire, rien ne l’est.
- Attribuées. Un responsable nommé par action. Une personne, pas une équipe.
- Datées. Une échéance décidée pendant la revue, pas assignée après.
- Typées. Chaque action porte une étiquette : détecter plus vite, mitiger plus vite, ou prévenir. Si tout est « prévenir », vous ratez probablement des gains faciles côté détection.
- Suivies en public. Une vue unique de toutes les actions ouvertes, revue lors d’un point récurrent. Une action qui glisse se discute ; elle ne se déplace pas en silence.
Une revue qui vaut le déplacement
La revue, c’est le moment où un post-mortem devient un savoir partagé. Courte et structurée :
| Bloc | Durée | Objectif |
|---|---|---|
| Résumé | 5 min | Tout le monde part de la même image. |
| Chronologie | 15 min | Se concentrer sur les points de décision et sur ce qu’on savait à ce moment-là. |
| Ce qui a été difficile | 10 min | Trous d’outillage, d’alerting, de process. |
| Actions | 10 min | Responsables et échéances décidés en séance. |
Invitez des personnes extérieures à l’équipe qui a géré l’incident. Le support, notamment, sait souvent des choses sur l’impact client qui ne remontent jamais côté engineering.
Publier, puis y renvoyer
Enfin : rendez les post-mortems trouvables. Liez-les depuis le runbook du service concerné. Mentionnez-les dans les passations d’astreinte. Partagez un court digest mensuel des incidents avec toute l’équipe.
Un post-mortem lu trois fois est déjà rentabilisé. Un post-mortem qui dort dans un dossier, c’est de la paperasse. Votre équipe en a déjà assez.