La plupart des postmortems sont de l'archéologie : un compte rendu exact de quelque chose que personne ne changera. Un postmortem utile produit un petit nombre de choses qui se font réellement.
L'objet d'un postmortem n'est pas de documenter ce qui s'est passé. C'est de rendre l'incident suivant moins probable ou moins dommageable. Tout ce que contient le document doit servir cela ; le reste est de la cérémonie.
Sans blâme est un mécanisme, pas une politesse
On explique souvent les postmortems sans blâme comme une forme de gentillesse. C'est les sous-vendre. Ils existent parce que les gens qui s'attendent à être blâmés retiennent de l'information — et l'information retenue est précisément celle qui aurait évité la récidive.
Une structure qui marche
- Résumé — trois phrases : ce qui a cassé, pendant combien de temps, qui a été affecté. La plupart des lecteurs s'arrêtent là, il doit donc tenir seul.
- Impact — durée, utilisateurs affectés, conséquences sur le revenu ou les données, en chiffres si possible
- Chronologie — des faits horodatés, du premier symptôme à la résolution, y compris le moment où des humains ont su
- Facteurs contributifs — au pluriel, et honnêtes sur ceux de process, pas seulement sur le déclencheur technique
- Ce qui a bien marché — réellement utile pour renforcer la détection ou la réponse qui a fonctionné
- Actions — chacune avec un responsable et une date
La cause racine est généralement une histoire, pas une ligne
« Le déploiement a causé la panne » est l'endroit où l'analyse s'arrête quand la réunion est pressée. Les vrais facteurs contributifs ressemblent plutôt à ceci :
| Couche | Exemple de constat |
|---|---|
| Déclencheur | Un changement de configuration a été déployé |
| Pourquoi ça a cassé | Le changement était syntaxiquement valide mais sémantiquement faux |
| Pourquoi rien ne l'a attrapé | Aucun environnement de staging ne reflétait la config de production |
| Pourquoi 40 minutes pour s'en apercevoir | Les alertes surveillaient le CPU, pas le taux de succès du paiement |
| Pourquoi la reprise fut lente | Le rollback n'avait jamais été testé pour des changements de config seuls |
Quatre de ces cinq points sont des problèmes de process. Ne corrigez que le déclencheur et la même classe d'incident reviendra habillée différemment.
Les actions : la partie qui décide si tout cela a compté
- Trois à cinq éléments maximum — une liste de vingt est une liste de zéro
- Chacun avec un responsable nommé, pas une équipe
- Chacun avec une date, suivi dans le même système que le travail normal
- Préférez les éléments qui suppriment une classe de défaillance (un garde-fou) à ceux qui corrigent une occurrence
- Revoyez-les au postmortem suivant — les éléments inachevés de la fois d'avant sont le point d'ordre du jour le plus important
Un postmortem sans action terminée avant l'incident suivant n'est pas un processus. C'est une habitude de classement.
Timing et audience
- Rédigez sous 48 heures — l'exactitude se dégrade vite
- Réunissez-vous 30 à 45 minutes, pas plus ; le document fait l'essentiel du travail
- Incluez tous ceux qui étaient impliqués, plus une personne qui ne l'était pas (elle pose les questions évidentes que les initiés sautent)
- Partagez-le largement — la transparence interne sur l'échec est la façon dont une organisation s'améliore
Rendre les actions préventives vérifiables
Un postmortem doit modifier un contrôle ou une décision. Définir une preuve d'achèvement pour chaque action.
- Distinguer faits, hypothèses et facteurs contributifs.
- Relier chaque action au mécanisme de défaillance visé.
- Vérifier par test, exercice d'alerte ou restauration.
Questions fréquentes
Combien de temps après un incident faut-il faire le postmortem ?
Rédigez sous 48 heures et réunissez-vous dans la semaine. Le souvenir de la séquence exacte et du raisonnement se dégrade vite, et les détails les plus importants — ce que quelqu'un croyait à ce moment-là et pourquoi — sont les premiers à disparaître.
Qu'est-ce qui rend un postmortem sans blâme en pratique ?
Demander comment le système a permis la défaillance plutôt que qui l'a causée. Concrètement : pas de noms attachés aux erreurs dans le document, des questions formulées sur les mécanismes plutôt que sur les décisions, et des actions qui ajoutent des garde-fous au lieu de demander aux gens d'être plus prudents.
Combien d'actions un postmortem doit-il produire ?
Trois à cinq, chacune avec un responsable nommé et une date. Des listes plus longues sont un signe fiable que rien ne sera fait — et les éléments inachevés doivent être le premier point de l'ordre du jour de la revue suivante.
Quand une action de postmortem est-elle terminée ?
Lorsque le résultat convenu est fourni et vérifié. Fermer un ticket ou mettre un document à jour ne prouve pas toujours un changement de comportement.
Vos incidents se répètent ?
C'est un problème de process, pas de malchance. Nous auditons la livraison et la pratique d'incident, et nous réparons le mécanisme.
Pour aller plus loin
Gérer une panne de production : un playbook pour petites équipes
Lors d'une panne, le problème technique est rarement le plus dur. La coordination l'est. Voici la séquence qui empêche une petite équipe d'aggraver les choses.
Audit des processus d'ingénierie : ce que nous regardons et pourquoi
Quand une équipe livre lentement, la cause n'est presque jamais les ingénieurs. Ce sont généralement quatre ou cinq frictions précises que personne n'a mesurées.