Post-mortem sans blâme à la manière SRE
Conduire un post-mortem factuel et sans blâme qui produit des actions correctives réellement suivies.
À retenir
- Un post-mortem sans blâme cherche des défaillances systémiques, pas des coupables individuels.
- Nommer une personne dans un post-mortem décourage le signalement futur des erreurs.
- Les actions correctives doivent être datées, assignées à une fonction et suivies jusqu'à clôture réelle.
- Le registre d'erreurs connues capitalise les causes non totalement corrigées avec un contournement documenté.
Le principe du « blameless postmortem »
L'approche popularisée par les équipes Site Reliability Engineering part d'un constat : si les personnes craignent d'être blâmées, elles cachent des informations, ce qui empêche de trouver la vraie cause racine. Un post-mortem sans blâme cherche des défaillances systémiques, pas des coupables.
Point clé
« sans blâme » ne signifie pas « sans responsabilité ». Cela signifie qu'on analyse pourquoi une erreur humaine a été possible dans le système, plutôt que de s'arrêter à « untel a fait une erreur ».
Structure recommandée d'un document de post-mortem
| Section | Contenu |
|---|---|
| Résumé exécutif | Impact, durée, gravité, en 3 phrases maximum |
| Chronologie factuelle | Horodatage précis de chaque événement et décision |
| Cause racine | Résultat de l'analyse (5 pourquoi, Ishikawa, arbre des causes) |
| Ce qui a bien fonctionné | Détection, escalade, communication réussies |
| Ce qui peut être amélioré | Sans nommer de personne, uniquement des processus ou outils |
| Actions correctives | Datées, assignées à une fonction (pas à une personne isolée), suivies jusqu'à clôture |
Formulations à éviter et à privilégier
| À éviter | À privilégier |
|---|---|
| « Le technicien a oublié de vérifier le filtre » | « La procédure ne prévoyait pas de rappel automatique de vérification du filtre » |
| « Erreur humaine » | « Le processus permettait une erreur humaine sans garde-fou de détection » |
| « Manque de rigueur de l'équipe » | « L'outil de planning ne signale pas les tâches en retard » |
Attention
un post-mortem qui nomme une personne comme cause de l'incident décourage durablement le signalement spontané des erreurs futures, ce qui dégrade la fiabilité globale à long terme.
Animer la réunion de post-mortem
- Rappeler en ouverture la règle : on analyse le système, pas les personnes.
- Dérouler la chronologie collectivement, en corrigeant les imprécisions sans jugement.
- Faire émerger la cause racine avec la méthode adaptée.
- Définir des actions correctives réalistes, avec responsable et échéance.
- Planifier une revue de clôture des actions, pas seulement leur création.
Sur le terrain
la plupart des post-mortems échouent non pas à l'analyse, mais au suivi : les actions correctives sont créées puis jamais vérifiées. Un registre d'actions avec relance automatique est indispensable.
Lien avec le registre d'erreurs connues
Chaque cause racine confirmée et non totalement corrigée doit être consignée dans un registre d'erreurs connues (known error database), avec un contournement documenté pour accélérer le traitement d'un futur incident similaire avant que la correction définitive soit déployée.
Astuce
partagez une synthèse anonymisée des enseignements de chaque post-mortem à l'ensemble de l'équipe astreinte, pas seulement aux personnes directement impliquées ; cela diffuse la connaissance sans exposer les individus.