Post-mortem d'incident

Guide une équipe pour rédiger un post-mortem structuré et sans culpabilisation après un incident en production. Le résultat est un document qui construit une compréhension partagée, identifie les causes racines sans blâmer, et produit des actions concrètes pour prévenir la récurrence.

Principe sans culpabilisation

Les systèmes défaillent, pas les gens. L'objectif est de comprendre COMMENT l'incident s'est produit — non QUI l'a causé. Évite le langage du type « X a oublié de », « Y aurait dû savoir ». Utilise plutôt « le système n'a pas », « le processus manquait de », « l'alerte n'a pas déclenché ».

Quand l'utiliser

• Une panne en production ou une dégradation de service a été résolue
• Un presque-incident significatif s'est produit (aurait été un incident s'il avait été détecté plus tard)
• Des erreurs visibles pour l'utilisateur, une perte de données ou une violation de SLA se sont produites
• L'équipe veut capturer les apprentissages avant que le contexte s'efface

Non pour : Les bugs mineurs détectés en staging, les fenêtres de maintenance planifiées ou les incidents sans valeur d'apprentissage.

Exigences en entrée

Rassemble ces détails avant de rédiger le post-mortem. Demande tout ce qui manque :

Métadonnées de l'incident

• Titre de l'incident (court, descriptif)
• Date et heure de détection (avec fuseau horaire)
• Date et heure de résolution
• Niveau de gravité / impact (P1–P4 ou équivalent)
• Commandant d'incident / responsable d'astreinte

Impact

• Services et systèmes affectés
• Impact visible pour l'utilisateur (erreurs, lenteur, panne totale)
• Nombre estimé d'utilisateurs affectés
• Perte ou corruption de données (oui/non, périmètre)
• Violation de SLA/SLO (oui/non, de combien)

Événements de la timeline

Moments clés à reconstituer :

• Premier symptôme observé
• Alerte déclenchée (ou détectée manuellement)
• Astreinte appelée / incident déclaré
• Enquête commencée
• Cause racine identifiée
• Mitigation appliquée
• Résolution complète confirmée
• Communication client envoyée (le cas échéant)

Facteurs contribuants

Demande à l'équipe : « Qu'est-ce qui a aggravé les choses ? » — non « qui a échoué ». Exemples :

• Seuil d'alerte trop élevé / alerte n'a pas déclenché
• Runbook manquant ou obsolète
• Deploy manquait un feature flag pour rollback
• Monitoring ne couvrait pas ce mode de défaillance
• Handoff d'astreinte a manqué du contexte

Processus

Étape 1 — Rassembler les métadonnées

Si l'utilisateur n'a pas fourni les détails d'incident complets, demande-les section par section. Ne procède pas à la rédaction avant d'avoir : le titre, les heures, la gravité, les services affectés et au moins une timeline approximative.

Étape 2 — Reconstituer la timeline

Travaille avec l'utilisateur pour construire une timeline chronologique précise. Pour chaque événement :

• Heure exacte (UTC préféré)
• Ce qui s'est passé (événement système ou action humaine)
• Qui l'a observé ou a pris l'action
• Lien vers log / alerte / message Slack si disponible

Signale les lacunes : « On ne sait pas ce qui s'est passé entre 14:32 et 14:47 — vaut le coup de vérifier les logs. »

Étape 3 — Analyse de la cause racine

Utilise les 5 Pourquoi de manière itérative :

Pourquoi les utilisateurs ont vu des erreurs 500 ?
→ Les pods API avaient un crash-loop.

Pourquoi avaient-ils un crash-loop ?
→ La limite de mémoire a été dépassée.

Pourquoi la limite a été dépassée ?
→ Une nouvelle requête chargeait les jeux de résultats complets en mémoire.

Pourquoi n'a-t-on pas détecté ça avant le deploy ?
→ Les tests de charge couvrait seulement le cas p50, pas les comptes à haute cardinalité.

Pourquoi les tests de charge couvrait seulement p50 ?
→ On n'avait pas de fixtures de test pour les gros comptes.

Arrête-toi quand tu atteins une lacune système/processus que tu peux corriger. Le dernier « pourquoi » doit pointer vers un action item.

Distingue :

• Cause racine — la lacune systémique la plus profonde (une ou deux)
• Facteurs contribuants — conditions qui ont aggravé les choses mais ne sont pas la cause racine

Étape 4 — Quantification de l'impact

Aide l'utilisateur à être précis :

• Durée : détection à résolution (non début du symptôme à résolution — sépare-les)
• Taux d'erreur au pic vs. baseline normal
• Pourcentage du trafic affecté
• Impact sur le chiffre d'affaires / métier si connu

Étape 5 — Action items

Pour chaque cause racine et facteur contribuant, génère au moins un action item :

Les action items doivent avoir un propriétaire (une personne, pas une équipe) et une date d'échéance. Les actions vagues comme « améliorer le monitoring » sont inacceptables — décompose-les en livrables spécifiques.

Étape 6 — Rédiger le document

Produis le post-mortem complet en utilisant le template ci-dessous. Enregistre sous docs/postmortems/YYYY-MM-DD-<slug>.md.

Template de sortie

# Post-mortem : [Titre de l'incident]

**Date :** YYYY-MM-DD  
**Gravité :** P[1-4]  
**Durée :** X heures Y minutes (HH:MM UTC – HH:MM UTC)  
**Commandant d'incident :** @name  
**Statut :** Résolu

---

## Résumé

[2–3 phrases. Ce qui s'est passé, quel était l'impact utilisateur, comment a-t-il été résolu. Rédigé pour quelqu'un qui n'a pas participé.]

## Impact

| Dimension | Valeur |
|-----------|--------|
| Services affectés | [liste] |
| Impact visible pour l'utilisateur | [erreurs / dégradé / panne totale] |
| Utilisateurs affectés | [nombre estimé ou %] |
| Taux d'erreur au pic | [X% vs Y% baseline] |
| Perte de données | [aucune / décrire le périmètre] |
| Violation de SLA | [oui/non — de combien] |

## Timeline

Tous les horaires en UTC.

| Heure | Événement |
|-------|-----------|
| HH:MM | [Premier symptôme / alerte déclenchée] |
| HH:MM | [Astreinte appelée] |
| HH:MM | [Incident déclaré] |
| HH:MM | [Cause racine identifiée] |
| HH:MM | [Mitigation appliquée] |
| HH:MM | [Résolution complète confirmée] |
| HH:MM | [Communication client envoyée] |

## Cause racine

[1–2 paragraphes. La lacune systémique la plus profonde qui, si elle était corrigée, aurait prévenu l'incident. Rédigé en langage sans culpabilisation. Référence la chaîne des 5 Pourquoi si utile.]

## Facteurs contribuants

- [Facteur 1 — condition qui a aggravé l'incident]
- [Facteur 2]
- [Facteur 3]

## Ce qui a bien fonctionné

- [Chose qui a marché — bonne alerte, réaction rapide, runbook clair]
- [Un autre point positif]

## Ce qui aurait pu mieux se passer

- [Lacune en processus, outillage ou couverture — pas de langage de culpabilisation]
- [Une autre lacune]

## Action items

| # | Action | Propriétaire | Date d'échéance | Priorité |
|---|--------|--------------|-----------------|----------|
| 1 | [Livrable spécifique] | @person | YYYY-MM-DD | Haute/Moyen/Basse |
| 2 | | | | |

## Leçons apprises

[Optionnel. 2–4 points clés capturant des insights non-évidents qui valent la peine d'être partagés avec l'équipe plus large.]

Erreurs courantes