Post-mortem sans blâme : modèle prêt à copier

On a tous déjà vécu ça.

Un incident en prod, un service qui tombe, un client qui s’énerve, et derrière… une réunion un peu tendue où on cherche vite « qui a fait quoi ». C’est humain. Mais c’est aussi exactement ce qui casse la dynamique d’équipe, et ça n’empêche pas le bug de revenir.

Le post-mortem sans blâme, c’est l’inverse de ça. C’est un format simple, presque banal, qui dit : on va comprendre le système, pas juger les personnes. Et on va en sortir avec des actions concrètes.

Je te propose ici un modèle prêt à copier, plus une façon de l’animer sans que ça tourne au tribunal. Tu peux le reprendre tel quel sur ton Notion, Google Docs, Confluence, GitHub, peu importe.

Pourquoi faire un post-mortem « sans blâme »

Parce que les incidents sont rarement causés par une seule action isolée.

Dans la vraie vie, c’est souvent un empilement : une alerte mal réglée, une doc pas à jour, une pression de délai, un test manquant, une dépendance externe qui se comporte bizarrement, une astuce temporaire devenue permanente. Et boum.

Le « sans blâme » sert à créer une sécurité psychologique minimale pour que les gens racontent ce qu’ils ont vu, ce qu’ils ont compris sur le moment, et ce qu’ils ont fait. Sans ça, tu obtiens des demi vérités, des silences, et un rapport qui ne sert à rien.

Et au passage, ça professionnalise ton équipe. Même si tu es solo.

Sur Le Blog Tech Pro de Samyn-Antoy ABASSE (monblog-sa-abasse.blogspot.com), je parle souvent d’outils et de méthodes « qui tiennent dans la durée ». Le post-mortem sans blâme, c’est typiquement ça. Pas sexy, mais puissant.

Les règles du jeu (à afficher en haut du doc)

Avant même le modèle, mets ces 4 règles. Sinon tu te retrouves à faire de la pédagogie en plein incident, mauvais timing.

1. « On critique le système, pas les personnes. »
2. « On part du principe que tout le monde a agi avec les infos et contraintes du moment. »
3. « On recherche des apprentissages et des actions, pas des coupables. »
4. « Le but : réduire la probabilité et l’impact, pas promettre le zéro incident. »

Tu peux aussi ajouter une phrase très terre à terre : « Si on sort d’ici avec 3 actions bien ownership et une meilleure compréhension, c’est gagné. »

Modèle prêt à copier (format post-mortem sans blâme)

Copie colle tout ce bloc dans ton outil, puis remplis.

1) Résumé exécutif (2 minutes)

• Titre : incident du [date] sur [service]
• Statut : résolu / mitigé / en cours
• Impact utilisateur : qui a été touché, comment, combien de temps
• Impact business : ventes, SLA, support, réputation (si connu)
• Gravité : sev1 / sev2 / sev3 (ou ton échelle)
• Détection : alerte / client / monitoring / interne
• Durée : début [heure] fin [heure]
• Résumé en 3 phrases : ce qui s’est passé, pourquoi en gros, ce qu’on a changé

2) Contexte

• Services concernés : API, base, queue, CDN, etc.
• Changements récents : déploiements, migrations, flags, config
• Dépendances externes : provider, API tierce, DNS, paiement
• Contraintes du moment : astreinte, charge, campagne, délais

3) Chronologie factuelle (timeline)

Astuce : note des faits, pas des opinions.

• [heure] : événement observé (alerte X, latency, erreurs 500)
• [heure] : action effectuée (rollback, restart, scale)
• [heure] : résultat observé
• [heure] : nouvelle hypothèse
• [heure] : résolution ou mitigation

4) Symptômes et signaux

• Ce que l'utilisateur voyait :
• Ce que les métriques montraient :
• Ce qui a induit en erreur (si applicable) :
• Ce qui a bien aidé (logs, traces, runbook) :

5) Cause racine (et causes contributives)

Cause racine : une phrase simple, vérifiable.

Causes contributives

• Facteur technique :
• Facteur process :
• Facteur humain (sans jugement) :
• Facteur produit :

Si tu utilises « 5 pourquoi », documente les étapes, sinon ça devient vite une histoire qu'on arrange.

6) Ce qui a bien fonctionné

• :
• :
• :

Oui, même quand ça a brûlé. Il y a toujours un truc qui a aidé.

7) Ce qui a moins bien fonctionné

• :
• :
• :

Reste factuel. Évite « X n'a pas fait attention ». Remplace par « la validation Y n'existait pas » ou « l'alerte Z ne couvrait pas le scénario ».

8) Actions correctives et préventives

Tableau conseillé :

Action	Type (correctif / préventif)	Priorité	Owner	Échéance	Statut	Lien

Rappels utiles :

• une action = un owner, sinon personne.
• limite toi à 5 à 10 actions, pas 40.
• privilégie les actions qui réduisent la fréquence ou l’impact : guardrails, alerting, tests, limites, rollback plus rapide.

9) Validation

• Comment on sait que c’est corrigé :
• Quels tests ou preuves :
• Ce qu’on monitor maintenant :

10) Annexes

• liens vers PR :
• logs :
• dashboards :
• tickets support :
• captures :

Comment l’animer sans que ça parte en vrille

Quelques trucs simples, mais franchement ça change tout :

• commence par relire les règles du jeu. Oui, à voix haute.
• impose le mode « timeline d’abord ». Pas de débat avant les faits.
• si une phrase ressemble à un jugement, reformule en système. Calmement.
• termine par les actions, et fixe une mini revue à J+7 ou J+14.

Et si tu veux aller plus loin, garde un petit historique public interne des post-mortems. Pas pour se flageller, juste pour apprendre. Avec le temps tu vois des patterns : les mêmes alertes manquantes, les mêmes zones grises, les mêmes dépendances fragiles.

Petit bonus : version ultra courte (quand tu n’as pas le temps)

Quand tu es pressé, utilise cette mini structure :

• impact :
• timeline :
• cause :
• 3 actions max :

C’est mieux que rien. Et ça évite le fameux « on verra plus tard » qui devient « jamais ».

Pour finir

Le post-mortem sans blâme, ce n’est pas de la gentillesse. C’est une méthode de fiabilité.

Tu veux des équipes qui remontent les problèmes tôt, qui documentent, qui osent dire « je ne sais pas », et qui améliorent le système au lieu de se protéger. C’est exactement ce format.

Si tu veux d’autres modèles concrets dans le même esprit (checklists, templates IA, process growth et ops), tu peux faire un tour sur Le Blog Tech Pro de Samyn-Antoy ABASSE : https://monblog-sa-abasse.blogspot.com

Questions fréquemment posées

Qu'est-ce qu'un post-mortem sans blâme et pourquoi est-il important ?

Un post-mortem sans blâme est un processus d'analyse d'incidents qui se concentre sur la compréhension du système plutôt que sur la recherche de coupables. Il crée un environnement de sécurité psychologique permettant à l'équipe de partager ouvertement ce qu'elle a observé et fait, favorisant ainsi des apprentissages concrets pour éviter la répétition des erreurs.

Quelles sont les règles fondamentales à suivre lors d'un post-mortem sans blâme ?

Les règles clés sont : 1) Critiquer le système, pas les personnes ; 2) Partir du principe que chacun a agi avec les informations et contraintes du moment ; 3) Rechercher des apprentissages et des actions, pas des coupables ; 4) Viser à réduire la probabilité et l'impact des incidents, sans promettre zéro incident.

Comment structurer efficacement un rapport de post-mortem sans blâme ?

Le rapport doit inclure : 1) Un résumé exécutif avec titre, statut, impact utilisateur et business, gravité, détection, durée et un résumé en trois phrases ; 2) Le contexte détaillant services concernés, changements récents, dépendances externes et contraintes ; 3) Une chronologie factuelle des événements ; 4) Une analyse des symptômes et signaux observés.

Pourquoi éviter de chercher un responsable individuel lors d'un incident en production ?

Chercher un responsable individuel peut casser la dynamique d'équipe, créer une atmosphère de méfiance et empêcher une compréhension complète de l'incident. Les incidents résultent souvent d'une combinaison de facteurs systémiques plutôt que d'une seule erreur humaine.

Quels bénéfices apporte le post-mortem sans blâme à une équipe technique ?

Il favorise la transparence, améliore la communication, encourage le partage d'informations précises, permet d'identifier des actions concrètes pour améliorer les systèmes et contribue à professionnaliser l'équipe en instaurant une culture d'apprentissage continu.

Comment animer une réunion post-mortem sans que cela ne devienne un tribunal ?

Il faut afficher clairement les règles du jeu avant la réunion, insister sur l'importance de critiquer le système et non les personnes, rappeler que tout le monde agit avec les informations disponibles au moment de l'incident, et orienter la discussion vers les apprentissages et les actions concrètes plutôt que vers la recherche de coupables.