🔎 Le postmortem blameless : transformer une panne en apprentissage

📚 Introduction

Une panne arrive toujours au mauvais moment. Et dans la demi-heure qui suit, une question se pose, explicitement ou non : « qui a cassé la prod ? » C’est le réflexe le plus naturel, et le plus toxique. Parce que la personne visée — ou celles qui regardent — en retiendront une leçon simple : la prochaine fois, ne rien dire, minimiser, effacer les traces.

Le postmortem blameless (sans blâme) part de l’idée inverse. Formalisée chez Etsy par John Allspaw en 2012, puis codifiée par Google dans le livre SRE, cette pratique déplace la question de « qui ? » vers « quoi et comment ? ». C’est un pur sujet de culture DevOps — le prolongement du temps de rétablissement des métriques DORA et de la gestion des incidents dans un budget d’error budget : une fois la panne réparée, reste à en tirer quelque chose.

🔎 C’est quoi, un postmortem blameless ?

C’est le compte rendu écrit d’un incident, rédigé à froid, qui répond à trois questions : que s’est-il passé, pourquoi, et comment éviter que ça recommence. Le mot important est blameless : l’analyse se concentre sur le système et les processus, jamais sur la culpabilité d’un individu.

Le postulat de base : personne ne casse la prod par malveillance. Chacun a agi de façon raisonnable compte tenu de ce qu’il savait et voyait à ce moment-là. Si un rm -rf sur le mauvais serveur a été possible, ou qu’un déploiement sans garde-fou a suffi à tout faire tomber, le vrai problème n’est pas la personne : c’est le système qui a rendu l’erreur si facile et ses conséquences si graves.

🧱 L’anatomie d’un postmortem

Un bon postmortem est structuré et factuel. On y retrouve, dans l’ordre :

• Résumé — une ou deux phrases : ce qui s’est passé, quand, quel impact.
• Impact — chiffré : durée, utilisateurs touchés, requêtes perdues, budget d’erreur consommé.
• Timeline — la chronologie horodatée, de la première alerte au retour à la normale.
• Causes et facteurs contributifs — ce qui a déclenché l’incident, mais aussi ce qui l’a aggravé ou ralenti la détection.
• Résolution — comment on a rétabli le service.
• Actions correctives — la partie qui compte : des tâches concrètes, chacune avec un propriétaire et une échéance.
• Leçons — ce que l’équipe a appris, y compris ce qui a bien fonctionné.

🎯 Pourquoi « sans blâme » ?

Parce que blâmer coûte cher et ne rapporte rien. Dans une équipe où l’on cherche un coupable, les gens apprennent à se protéger : ils partagent moins, documentent moins, préviennent moins. L’information dont tu as besoin pour comprendre l’incident — celle qui n’est que dans la tête de la personne aux commandes ce jour-là — disparaît. Résultat : tu ne corriges rien en profondeur, et la panne revient sous une autre forme.

À l’inverse, la sécurité psychologique délie les langues. Quand raconter honnêtement une erreur n’expose à aucune sanction, on obtient le récit complet, on remonte aux vraies causes, et on répare le système pour que la prochaine personne ne puisse plus tomber dans le même trou. C’est ça, l’objectif : rendre l’erreur impossible, pas punir celui qui l’a trouvée en premier.

⚠️ Quelques précautions

• Blameless n’est pas laxiste. L’idée n’est pas de balayer les conséquences, mais de ne pas punir une erreur honnête. Les actions correctives, elles, engagent l’équipe.
• Ne t’arrête pas à « erreur humaine ». C’est une conclusion paresseuse. Continue de creuser : pourquoi l’erreur était-elle possible ? pourquoi n’a-t-elle pas été rattrapée ? Un facteur humain cache toujours un facteur système.
• Un postmortem sans actions suivies est du théâtre. Sans propriétaire ni échéance, les « leçons » ne changent rien. Le postmortem se juge à ce qu’il fait bouger.
• Fais-en aussi pour les incidents évités de justesse. On apprend autant d’un quasi-accident que d’une panne réelle, pour bien moins cher.

🎉 Conclusion

Le postmortem blameless, c’est le choix de traiter chaque panne comme une information gratuite plutôt que comme une faute à sanctionner. Il demande une vraie discipline — écrire à froid, creuser au-delà de l’erreur humaine, suivre les actions — mais il transforme la culture d’une équipe : on cesse d’avoir peur des incidents pour commencer à en apprendre. Et une équipe qui apprend de ses pannes finit, mécaniquement, par en avoir moins.

🔗 Liens utiles

• Google SRE — Postmortem Culture: Learning from Failure
• PagerDuty — The Blameless Postmortem
• John Allspaw — Blameless PostMortems and a Just Culture (Etsy, 2012)