Le post-mortem sans blâme

Mode de lecture

IngénieurDécideur

Un incident coûte de toute façon. La seule question est de savoir si l’organisation en retire quelque chose. Le post-mortem sans blâme est le rituel qui transforme un incident en apprentissage : il cherche ce qui a rendu l’erreur possible plutôt que la personne qui l’a commise, puis il produit un petit nombre d’actions suivies jusqu’au bout.

La leçon 5 du parcours DSI pose quatre règles de culture. Cet article est le guide d’animation : quand déclencher, comment dérouler la séance, quel gabarit utiliser, comment suivre les actions et quoi mesurer.

Pourquoi « sans blâme »

L’argument est pratique avant d’être moral. Si une personne risque une sanction en racontant ce qu’elle a fait, elle racontera moins, ou autrement. L’analyse s’arrête alors à « erreur humaine » et la condition qui a rendu l’erreur possible reste en place pour la personne suivante. John Allspaw a formulé cette idée pour Etsy dans un texte devenu une référence (Blameless PostMortems and a Just Culture) et le chapitre Postmortem Culture du livre Site Reliability Engineering la reprend.

Sans blâme ne veut pas dire sans responsabilité. Les actions ont des porteurs et des dates. Ce qui disparaît, c’est la recherche d’un coupable.

Quand déclencher un post-mortem

Un post-mortem coûte quelques heures de travail à plusieurs personnes. Il faut donc des critères écrits, connus avant l’incident, pour qu’il ne dépende ni de l’humeur ni de la gravité perçue. Le chapitre de Google cité plus haut propose des déclencheurs que je reprends comme base :

• une indisponibilité ou une dégradation visible des utilisateurs au-delà d’un seuil fixé à l’avance ;
• une perte de données, quelle qu’en soit l’ampleur ;
• une intervention manuelle de l’astreinte pour rétablir (retour arrière, bascule de trafic) ;
• une durée de rétablissement au-delà d’un seuil ;
• un incident découvert autrement que par la supervision, ce qui signale un trou d’observabilité.

Le même chapitre précise que toute partie prenante peut demander un post-mortem, même hors critères. J’ajoute une recommandation : un incident qui consomme une part importante du budget d’erreur d’un SLO, part que vous fixez, déclenche un post-mortem même si personne ne s’est plaint.

Le déroulé

Étape	Quand	Qui	Ce qui est produit
Désignation	à la clôture de l’incident	le responsable d’incident	un rédacteur et un animateur, si possible non impliqués dans la réponse
Collecte	dans les jours qui suivent	le rédacteur	chronologie horodatée, captures de tableaux de bord, extraits de canal d’incident
Brouillon	avant la séance	le rédacteur, relu par les intervenants	le document selon le gabarit, sections actions vides
Séance	une heure environ	intervenants, équipe propriétaire, métier concerné	causes et facteurs validés, actions décidées et attribuées
Publication	après la séance	le rédacteur	document diffusé en interne, actions saisies dans le backlog
Suivi	jusqu’à clôture	les porteurs d’action, revu chaque mois	actions fermées ou explicitement abandonnées

Je recommande de fixer un délai cible entre la clôture de l’incident et la séance, assez court pour que les mémoires soient fraîches. Le bon délai dépend de votre rythme ; l’important est qu’il soit écrit et mesuré.

Le rôle de l’animateur. Il protège la règle. Il reformule les « il aurait dû » en « qu’est-ce qui rendait cette action raisonnable à ce moment-là ? ». Il ramène la discussion vers les conditions (outil, procédure, signal manquant, pression de temps) quand elle glisse vers les personnes. Il veille à ce que les intervenants les moins gradés parlent en premier.

La chronologie d’abord. Je recommande de consacrer le premier tiers de la séance à valider la chronologie. Les désaccords sur les causes viennent souvent de désaccords non dits sur les faits.

Le gabarit

Un gabarit court est utilisé ; un gabarit long est contourné. Celui-ci tient sur deux pages.

# Post-mortem : <titre factuel, sans nom de personne>

Statut : brouillon | relu | publié
Date de l'incident : AAAA-MM-JJ   Durée : de HH:MM à HH:MM
Rédacteur :            Animateur :
Services touchés :     SLO concernés :

## Résumé
Trois phrases : ce qui s'est passé, l'impact, comment on a rétabli.

## Impact
- Utilisateurs ou clients touchés, sur quelle période
- Budget d'erreur consommé
- Impact métier établi avec le métier concerné (commandes, délais, image)

## Chronologie
HH:MM  événement (source : alerte, canal, tableau de bord)
Détection, premier diagnostic, décisions, rétablissement.

## Détection
Comment l'incident a été détecté. Combien de temps après son début.
La supervision l'a-t-elle vu ? Sinon, quel signal aurait suffi ?

## Causes et facteurs contributifs
Ce qui a déclenché l'incident. Ce qui l'a rendu possible.
Ce qui l'a aggravé ou prolongé.

## Ce qui a bien fonctionné
## Où nous avons eu de la chance

## Actions
| Action | Type (prévenir, détecter, atténuer) | Porteur | Échéance | Critère de fin |

## Enseignements
Ce que les autres équipes devraient savoir.

Deux sections méritent une attention particulière. Détection relie le post-mortem à l’observabilité : un incident détecté par un client plutôt que par une alerte est une action d’instrumentation en soi. Où nous avons eu de la chance fait apparaître les risques qui ne se sont pas réalisés cette fois-ci, souvent les plus instructifs.

Les actions, là où tout se joue

Un post-mortem dont les actions ne sont jamais réalisées est pire qu’un post-mortem absent : il apprend aux équipes que le rituel ne sert à rien.

Je recommande quatre règles :

1. Peu d’actions, choisies. Mieux vaut trois actions réalisées que douze en attente. Les idées non retenues vont dans une section « pistes » sans porteur.
2. Une action, un porteur, une date, un critère de fin. « Améliorer la supervision » n’est pas une action. « Ajouter une alerte sur le taux d’erreur du service de paiement, liée à son SLO » en est une.
3. Les actions vivent dans le backlog de l’équipe, pas dans le document. Elles sont priorisées comme le reste du travail, avec une étiquette qui permet de les retrouver.
4. Une revue mensuelle des actions ouvertes, courte, qui ferme, relance ou abandonne explicitement. Un abandon décidé et motivé vaut mieux qu’une action qui pourrit.

Le chapitre Postmortem Culture du Site Reliability Workbook compare un post-mortem jugé faible et sa version améliorée. Je recommande sa lecture à toute personne qui animera des séances.

Ce qu’on mesure

Ces indicateurs disent si le rituel fonctionne. Ils ne servent pas à classer les équipes : un nombre élevé de post-mortems peut signaler une bonne culture de déclaration plutôt qu’un système fragile.

Indicateur	Ce qu’il révèle
Part des incidents éligibles ayant un post-mortem publié	si les critères de déclenchement sont appliqués
Délai entre la clôture de l’incident et la publication	si le rituel est tenu ou repoussé
Taux de clôture des actions à leur échéance	si le post-mortem change réellement le système
Âge des actions ouvertes	l’accumulation de dette d’apprentissage
Incidents récurrents (même cause qu’un incident déjà analysé)	si les actions traitaient la bonne cause
Part des incidents détectés par la supervision plutôt que par un utilisateur	ce que le post-mortem apporte à l’observabilité
Nombre de lectures ou de partages des post-mortems publiés	si l’apprentissage dépasse l’équipe concernée

Les incidents récurrents et la part détectée par la supervision peuvent alimenter le tableau de bord de direction : ils traduisent l’apprentissage en indicateurs qu’un comité comprend.

Les pièges courants

• Le post-mortem tribunal. Un responsable hiérarchique qui demande « qui a fait ça ? » en séance annule la règle pour longtemps. L’animateur doit pouvoir l’arrêter.
• La cause racine unique. Les incidents de systèmes distribués ont rarement une seule cause. Je recommande de parler de facteurs contributifs.
• L’erreur humaine comme conclusion. C’est un point de départ : qu’est-ce qui rendait l’erreur facile et sa détection difficile ?
• Le document que personne ne lit. Une diffusion interne large et un résumé de trois phrases font plus qu’un document exhaustif rangé dans un dossier.

Liste de contrôle

• Les critères de déclenchement sont écrits et connus avant l’incident
• L’animateur n’a pas participé à la réponse à l’incident
• La chronologie est validée avant toute discussion de causes
• Le titre et le document ne nomment pas de coupable
• La section Détection dit si la supervision a vu l’incident
• Chaque action a un porteur, une échéance et un critère de fin
• Les actions sont dans le backlog de l’équipe
• Les actions ouvertes sont revues chaque mois
• Le métier concerné est invité quand l’incident l’a touché

Pour aller plus loin

• Les post-mortems se nourrissent d’une astreinte soutenable : une équipe épuisée n’a plus l’énergie d’analyser.
• Le business case du MTTR relie le temps de détection et de rétablissement au coût d’un incident.
• Le parcours DSI, leçon 5 propose un exercice de post-mortem rejoué pour mesurer la maturité culturelle.

Sources

• Beyer, Jones, Petoff et Murphy (dir.), Site Reliability Engineering, O’Reilly, 2016 : chapitre 15, Postmortem Culture: Learning from Failure.
• Beyer, Murphy, Rensin, Kawahara et Thorne (dir.), The Site Reliability Workbook, O’Reilly, 2018 : chapitre 10, Postmortem Culture: Learning from Failure.
• John Allspaw, Blameless PostMortems and a Just Culture, Code as Craft, Etsy, 2012.
• Exemples publics de déroulés et de gabarits : le guide post-mortem de PagerDuty et le manuel de gestion des incidents d’Atlassian.

PasserellesCe que cette page change au-delà de l'équipe technique.

BusinessValeur, coût, risque

Le post-mortem est le moment où le coût réel d'un incident est établi avec les métiers. Sans lui, le business case de l'observabilité repose sur des estimations ; avec lui, il repose sur des faits.

OrganisationQui décide, qui possède

Un déclenchement écrit, un animateur qui n'est pas partie prenante et des actions suivies comme le reste du backlog : trois règles d'organisation qui décident si le rituel survit au premier trimestre.

HumainÉquipes, astreinte, compétences

Une personne qui ne craint pas la sanction raconte ce qu'elle a vraiment vu et fait. C'est la condition pour que l'analyse touche la cause plutôt que la surface.

MétiersProduit, finance, risque, relation client

Inviter le métier concerné au post-mortem lui fait comprendre le système et donne à l'équipe technique la mesure de ce que l'incident a coûté, en clients, en chiffre d'affaires ou en image.

Pourquoi des passerelles →