Postmortems sans recherche de coupable : consigner le déroulé, les causes et les actions

Objectif

Tirer d'un incident un enseignement qui change le système, et pas seulement la vigilance des personnes impliquées, et rendre cet enseignement accessible au-delà de l'équipe.

Prérequis

Le chapitre « Postmortem Culture » du livre Google SRE cite les déclencheurs habituels : panne visible par les utilisateurs ou dégradation au-delà d'un seuil, perte de données de toute nature, intervention de l'astreinte (rollback, redirection du trafic), un temps de résolution au-delà d'une limite, une défaillance de la surveillance. Il décrit l'absence de recherche de coupable comme un principe de la culture SRE : le document nomme les causes contributives sans reprocher à une personne ou à une équipe un comportement inapproprié. Sont nécessaires la chronologie tirée des alertes, des journaux et de l'historique de chat, ainsi qu'une personne rédactrice qui n'est pas seulement la personne d'astreinte.

Étapes

1. Vérifier le seuil : l'incident remplit-il l'un des déclencheurs convenus ? Si non, un ticket suffit ; des postmortems pour des broutilles dévalorisent le format.
2. Reconstruire la chronologie, avec des horodatages et formulée en observations (« Alerte X à 02 h 14 », « Rollback démarré à 02 h 31 »), pas en interprétations.
3. Décrire l'impact en termes d'utilisateurs et en chiffres : quelle fonctionnalité, pendant combien de temps, combien de requêtes, d'enregistrements ou de personnes clientes.
4. Recueillir les causes contributives, le plus souvent plusieurs. La question directrice est « Qu'est-ce qui a rendu cela possible ? », pas « Qui a fait cela ? » ; une personne qui a pu exécuter une commande qui n'aurait pas dû être possible ainsi constitue un constat sur le système.
5. Consigner ce qui s'est bien passé, ce qui s'est mal passé, et où la chance est intervenue — le quasi-incident d'aujourd'hui est la panne de demain.
6. Formuler des actions concrètes, attribuées à une personne et datées : une alerte manquante, un test manquant, une section de runbook, un verrou dans le déploiement. Les actions qui suppriment le mode de défaillance priment sur celles qui appellent à plus de prudence.
7. Faire relire le brouillon par l'équipe, le publier, suivre les actions jusqu'à leur clôture.

Résultat attendu

Un document à partir duquel une nouvelle recrue comprend la panne et sa résolution ; des actions menées à terme ; un climat dans lequel les quasi-incidents sont signalés.

Limites et base de vérification

Sans recherche de coupable ne signifie pas sans conséquence : les actions ont des responsables. Un postmortem dont les actions restent en souffrance apprend à l'équipe que signaler ne sert à rien. La structure et les déclencheurs suivent le chapitre cité ; aucune mesure de l'effet sur la propension à signaler n'est ici revendiquée.