Post-mortem d'incident : que mettre dedans (avec modèle)

L'incident est clos, le service répond de nouveau, tout le monde souffle. C'est précisément le moment où la plupart des équipes laissent filer ce que la panne pouvait leur apprendre. Trois jours plus tard, plus personne ne sait exactement à quelle heure est tombée la première alerte, quelle commande a tout débloqué ni pourquoi il a fallu quarante minutes pour comprendre. Le post-mortem sert à fixer ces éléments par écrit, puis à transformer le constat en actions concrètes.

Cet article passe en revue ce qu'un bon post-mortem contient, section par section, avec un modèle à copier, des exemples de formulations à éviter et la manière d'en tirer une version publique pour votre page de statut.

Une culture sans reproche, ou rien

Un post-mortem ne sert à rien si les personnes impliquées ont peur d'y raconter ce qui s'est réellement passé. Le principe dit « sans reproche » (blameless) part d'un constat simple : chacun a agi de façon raisonnable avec les informations dont il disposait à ce moment-là. Si une seule commande a suffi à mettre la production à terre, la vraie question n'est pas « qui l'a lancée ? » mais « pourquoi le système a-t-il permis qu'elle ait cet effet ? ».

Le chapitre consacré à la culture du post-mortem dans le livre SRE de Google développe bien cette idée et reste la référence sur le sujet. Retenez surtout ceci : sans reproche ne veut pas dire sans responsabilité. Chaque action corrective a un responsable nommé et une échéance. On ne cherche pas de coupable, on cherche des améliorations, et quelqu'un doit les porter.

Quand rédiger un post-mortem

Tous les incidents ne méritent pas un document de trois pages. Fixez des critères à l'avance, pour que la décision ne dépende pas de l'humeur du moment. Un post-mortem s'impose généralement quand :

• le service a été indisponible ou fortement dégradé pour les utilisateurs au-delà d'une durée que vous avez définie, par exemple quinze minutes ;
• des données ont été perdues ou corrompues, même partiellement ;
• il a fallu une intervention manuelle d'urgence : retour arrière, restauration, bascule ;
• un client vous a signalé la panne avant vos propres alertes ;
• l'incident a consommé une part importante de votre budget d'erreur (voir notre guide sur les SLA, SLO et SLI) ;
• l'équipe est passée tout près d'une panne grave, même sans impact visible.

Côté calendrier, visez un premier jet dans les 48 heures, tant que les souvenirs sont frais, puis une relecture en équipe dans la semaine. La rédaction revient en général à la personne qui a piloté l'incident, pas forcément à celle qui l'a déclenché.

Les sections d'un post-mortem complet

Résumé

Trois à cinq phrases lisibles par quelqu'un qui n'a rien suivi : ce qui est tombé, pendant combien de temps, pour qui, pourquoi en une ligne, et si le problème est corrigé. Beaucoup de lecteurs s'arrêteront là.

Impact, chiffré

Remplacez « certains utilisateurs » par des nombres : durée de l'indisponibilité, part des requêtes en erreur, nombre de commandes ou de connexions échouées, régions touchées, tickets de support reçus. Si vous ne connaissez qu'une estimation, dites-le et donnez la fourchette. Précisez aussi ce qui n'a pas été touché : c'est souvent aussi utile que le reste.

Chronologie, en UTC et en heure locale

Notez chaque événement horodaté : premier symptôme, alerte, prise en charge, hypothèses testées, correctif, retour à la normale. Écrivez les heures en UTC, avec l'heure locale entre parenthèses si votre équipe ou vos clients raisonnent en heure de Paris. C'est précieux le jour où un incident chevauche un changement d'heure.

Détection : comment et en combien de temps

Qui ou quoi a repéré le problème en premier : une alerte de surveillance, un client, un collègue par hasard ? Mesurez trois délais : entre le début réel et la détection, entre la détection et la prise en charge, entre la prise en charge et la résolution. Le premier est souvent le plus instructif : une détection lente révèle un trou dans la surveillance, pas un manque de réactivité.

Cause racine et facteurs contributifs

Les incidents ont rarement une cause unique. Décrivez le déclencheur, puis les conditions qui lui ont permis de faire des dégâts : une limite mal dimensionnée, une alerte absente, une procédure de déploiement sans vérification, une documentation périmée. La technique des « cinq pourquoi » aide à remonter la chaîne, à condition de s'arrêter sur des causes que vous pouvez réellement corriger.

Ce qui a bien marché, ce qui a moins bien marché

Notez ce qui a fonctionné (le retour arrière a pris deux minutes, l'alerte est arrivée sur la bonne personne) pour le préserver, et ce qui a coincé (accès manquant, tableau de bord introuvable, message client trop tardif).

Actions, avec un responsable et une date

Chaque action est formulée comme une tâche vérifiable, avec un responsable nommé, une échéance et un lien vers le ticket correspondant. Classez-les : ce qui empêche la récidive, ce qui accélère la détection, ce qui réduit l'impact la prochaine fois. Mieux vaut quatre actions réalisées que quinze vœux pieux.

Le modèle à copier

Voici un modèle en Markdown, rempli avec un exemple fictif pour montrer le niveau de détail attendu.

# Post-mortem : paiements indisponibles après un déploiement

Statut : relu le 26/09 · Rédaction : pilote de l'incident · Version interne

## Résumé
Le 23/09, de 14:02 à 14:49 UTC (16:02 à 16:49 heure de Paris), le paiement
a échoué pour tous les clients. Un changement de configuration a réduit le pool
de connexions à la base de données. Retour arrière effectué, cause corrigée.

## Impact
- Durée : 47 minutes d'indisponibilité du paiement
- Requêtes en erreur sur /checkout : 100 % pendant 47 min
- Commandes échouées : 312 (estimation à partir des paniers abandonnés)
- Non touché : navigation, compte client, back-office
- Tickets de support : 41

## Chronologie (UTC, heure de Paris entre parenthèses)
- 13:58 (15:58) Déploiement de la version 4.12
- 14:02 (16:02) Premières erreurs 500 sur /checkout
- 14:04 (16:04) Panne confirmée par la surveillance, alerte envoyée
- 14:09 (16:09) Alerte prise en charge par l'astreinte
- 14:31 (16:31) Pool de connexions identifié comme cause probable
- 14:44 (16:44) Retour arrière vers la version 4.11
- 14:49 (16:49) Taux d'erreur revenu à la normale

## Détection
- Détecté par : surveillance externe (contrôle par mot-clé sur /checkout)
- Délai de détection : 2 min · prise en charge : 5 min · résolution : 40 min

## Cause racine et facteurs contributifs
- Déclencheur : valeur du pool passée de 50 à 5 dans un fichier partagé
- Facteur : la revue de code ne couvrait pas les fichiers de configuration
- Facteur : aucun test de charge sur l'environnement de préproduction
- Facteur : pas de métrique sur l'occupation du pool de connexions

## Ce qui a bien marché / moins bien marché
+ Alerte reçue en 2 minutes, retour arrière en 5 minutes
- 22 minutes perdues à chercher côté prestataire de paiement
- Message sur la page de statut publié seulement à 14:35

## Actions
| Action                                         | Responsable | Échéance | Ticket |
|------------------------------------------------|-------------|----------|--------|
| Ajouter la config à la revue obligatoire       | Équipe A    | 30/09    | OPS-81 |
| Alerte sur l'occupation du pool (> 80 %)       | Équipe B    | 03/10    | OPS-82 |
| Test de charge avant chaque mise en production | Équipe A    | 15/10    | OPS-83 |
| Message de statut dans les 10 min (procédure)  | Support     | 30/09    | OPS-84 |

Bonnes et mauvaises formulations

Le vocabulaire fait beaucoup pour l'esprit sans reproche et pour l'utilité du document. Quelques exemples :

La règle générale : des faits mesurables, des mécanismes plutôt que des personnes, des actions vérifiables plutôt que des intentions.

Version interne, version publique

Le document interne contient tout : noms de serveurs, extraits de journaux, hypothèses écartées, échanges avec les prestataires. Vos clients, eux, ont besoin d'autre chose. La version publique, celle que vous publiez sur votre page de statut ou envoyez à vos clients, tient en quelques paragraphes :

• ce qui s'est passé, en langage courant ;
• quand, avec les heures de début et de fin et le fuseau horaire ;
• qui a été touché et comment : quelles fonctionnalités, quelles régions ;
• ce que vous avez fait pour rétablir le service ;
• ce que vous changez pour éviter que cela se reproduise.

Une page de statut qui affiche l'historique des incidents avec ces explications rassure davantage qu'une page toujours verte.

Suivre les actions jusqu'au bout

Un post-mortem dont les actions restent ouvertes six mois n'a servi qu'à se donner bonne conscience. Quelques habitudes simples :

• reportez chaque action dans votre outil de tickets habituel, pas seulement dans le document ;
• passez les actions ouvertes en revue lors d'un point régulier, chaque semaine ou chaque quinzaine ;
• ne marquez le post-mortem comme clos que lorsque toutes les actions sont faites ou explicitement abandonnées, avec la raison ;
• relisez ensemble les post-mortems des derniers mois : les causes qui reviennent méritent un chantier dédié.

Ce que LucidStack apporte au post-mortem

La partie la plus pénible d'un post-mortem, c'est de reconstituer la chronologie. Dans LucidStack, chaque incident garde sa chronologie d'événements : contrôles en échec, régions touchées, confirmation de la panne, accusé de réception par la personne d'astreinte, rétablissement. Vous disposez donc des délais de détection et de prise en charge sans fouiller dans vos messages.

L'incident comporte un champ dédié au post-mortem, et vous pouvez exporter l'incident en PDF avec toute sa chronologie, pratique pour l'archiver ou le transmettre à un client. Si vous le souhaitez, l'analyse d'incident par IA rédige un premier jet structuré (faits, chronologie, impact, cause, actions) ainsi qu'un message public pour votre page de statut, à partir des données de surveillance. C'est un brouillon : relisez-le, corrigez-le et complétez-le avec ce que la surveillance ne peut pas savoir, comme le contexte du déploiement ou les échanges avec vos clients. L'IA peut d'ailleurs être désactivée pour toute l'organisation.

Un bon post-mortem ne demande pas d'outil particulier, seulement de la rigueur. Avoir la chronologie et un brouillon déjà prêts vous laisse du temps pour l'essentiel : comprendre et corriger.