Un post-mortem d’incident sert à deux choses : éviter que l’incident se reproduise, et pouvoir expliquer à un client ou à une autorité ce qui s’est passé. Les deux échouent pour la même raison. La chronologie est reconstituée de mémoire, en réunion, plusieurs jours après les faits. Ce guide décrit l’autre méthode : partir des traces que vos outils ont déjà produites.
Pourquoi la chronologie reconstituée de mémoire ne tient pas ?
Parce que la mémoire de l’astreinte compresse, réordonne et arrondit les heures. Elle ne le fait pas par négligence : pendant un incident, personne ne regarde l’horloge. Après coup, chacun se souvient de sa propre séquence, pas de celle des autres.
Les conséquences se voient dans le document final. Les heures finissent en « vers 14 h ». Le délai entre l’alerte et la prise en charge disparaît, parce que personne ne l’a vécu. Le changement déployé la veille n’apparaît pas, parce que l’équipe qui l’a fait n’était pas dans la réunion.
Une chronologie défendable ne se raconte pas. Elle se compile.
Où trouver les traces d’un incident ?
Dans quatre familles d’outils, qui horodatent chacune une partie des faits au moment où ils se produisent.
| Source | Exemples d’outils | Ce qu’elle horodate |
|---|---|---|
| Supervision | Grafana, Zabbix, Prometheus Alertmanager | Première alerte, changements d’état, retour au vert |
| Astreinte | PagerDuty, Opsgenie | Déclenchement, escalades, acquittement, prise en charge |
| Tickets | Jira Service Management, ServiceNow | Création, changements de statut et de priorité, réaffectations, clôture |
| Changements | Outil de déploiement, gestionnaire de versions, tickets de changement | Déploiements, modifications de configuration, retours arrière |
S’y ajoute la messagerie d’astreinte (canal d’incident, conférence téléphonique). Elle contient les décisions et les hypothèses, rarement ailleurs. Exportez le fil du canal d’incident dès la clôture, avant qu’il ne soit noyé.
La méthode tient en trois étapes : extraire les événements de chaque source sur la fenêtre de l’incident, les fusionner dans une seule liste triée par heure, puis annoter. L’annotation est le seul travail humain : dire quels événements comptent et ce qu’on savait à chaque instant.
Un prérequis technique : toutes ces sources doivent partager la même référence de temps et le même fuseau. Un écart de quelques minutes entre la supervision et les tickets suffit à inverser l’ordre apparent de deux événements.
Que faut-il horodater automatiquement ?
Tout ce qui sert à mesurer un délai ou à fixer une échéance. Concrètement :
- la détection : première alerte de supervision, ou premier signalement d’un utilisateur ;
- la prise en charge : acquittement de l’astreinte ;
- la qualification : passage à la gravité retenue, et décision de notifier ou non si une obligation réglementaire s’applique ;
- chaque changement appliqué pendant l’incident, y compris les retours arrière ;
- le rétablissement : retour au vert de la supervision sur le service, pas sur un serveur ;
- la clôture du ticket.
Ce sont aussi les bornes qui permettent de mesurer un MTTR qu’on peut défendre. Si l’un de ces points n’est horodaté que de mémoire, écrivez-le dans le post-mortem : « heure estimée ». Un chiffre signalé comme estimé reste utilisable. Un chiffre faux présenté comme exact ne l’est plus.
À quoi ressemble un post-mortem sans recherche de coupable ?
À un document qui décrit des causes, pas des fautes. Le chapitre « Postmortem Culture » du livre SRE de Google le formule ainsi : identifier les causes sans mettre en cause une personne ou une équipe. Il part du principe que chacun a agi de bonne foi. En français, la méthode reste peu documentée : sur « post mortem incident », sept des huit premiers résultats sont en anglais (notre relevé des pages de résultats).
Ce n’est pas une politesse. Quand l’erreur individuelle est sanctionnée, les faits qui la concernent sortent du récit, et la chronologie se troue. Écrivez « la commande a été lancée sur le mauvais équipement ; rien dans l’interface ne distinguait les deux » plutôt que « l’opérateur s’est trompé ».
Un gabarit qui tient sur deux pages :
| Rubrique | Contenu | Source |
|---|---|---|
| Résumé | Trois phrases : quoi, combien de temps, qui a été touché | Rédaction |
| Impact | Services et clients touchés, durée, données perdues ou non | Inventaire, tickets |
| Chronologie | Liste horodatée, chaque ligne avec sa source | Export des outils, annoté |
| Causes | Cause déclenchante et causes contributives | Analyse |
| Détection | Comment l’incident a été découvert, et avec quel délai | Supervision |
| Ce qui a fonctionné | Ce qu’il faut garder | Équipe |
| Actions correctives | Action, propriétaire, échéance, numéro de ticket | Outil de suivi |
| Communication | Ce qui a été dit aux clients, quand, par qui | Messagerie, tickets |
La colonne « Source » est la différence avec un compte rendu de réunion. Chaque ligne de la chronologie renvoie à l’alerte, au ticket ou au message qui la prouve.
Le gabarit est disponible en PDF, à imprimer ou à remplir, sans inscription : modèle de post-mortem d’incident.
Qui écrit, qui relit, qui signe, et dans quel délai ?
Une personne écrit, un groupe relit, un responsable signe. Répartissez ces rôles par écrit avant le prochain incident :
- qui écrit : la personne qui a coordonné l’incident, ou un rédacteur désigné qui l’interroge ; pas un comité ;
- qui relit : les intervenants, pour la chronologie, puis des ingénieurs expérimentés, pour la profondeur des causes et la pertinence des actions (c’est la pratique décrite dans le chapitre de Google) ;
- qui signe : le responsable du service touché, qui s’engage sur les actions et leurs échéances.
La relecture n’est pas une formalité. Le chapitre de Google l’écrit sans détour : « un post-mortem qui n’a pas été relu aurait aussi bien pu ne jamais exister » (traduit de l’anglais).
Fixez un délai pour le brouillon, un autre pour la signature, et tenez-les. Un post-mortem qui arrive après le suivant ne sert plus à rien.
Comment suivre les actions correctives jusqu’à la clôture ?
En les traitant comme du travail, pas comme des recommandations. Chaque action devient un ticket dans l’outil où l’équipe travaille déjà, avec un propriétaire nommé et une échéance. Le post-mortem référence ces tickets ; il n’en est pas la copie.
Le post-mortem ne se clôt que quand ses actions le sont, ou quand leur abandon est décidé et écrit. Une revue mensuelle des actions ouvertes suffit à voir celles qui dérivent. Une action sans propriétaire, c’est une action abandonnée.
Quel lien avec la notification aux clients ?
Le post-mortem est la matière première de toute notification. Les clients touchés attendent une explication, et certaines organisations doivent aussi rendre compte à une autorité dans des délais fixés. Le guide sur la notification d’incident détaille ce cas.
Écrivez donc un seul document, puis dérivez-en les versions : technique pour l’équipe, synthétique pour les clients, réglementaire si une autorité doit être informée. Trois rédactions séparées, ce sont trois chronologies qui finiront par diverger.
En résumé
Un post-mortem utile repose sur quatre choses : une chronologie extraite des outils, un format qui décrit des causes et non des fautes, des rôles écrits pour rédiger, relire et signer, des actions suivies comme des tickets.
Reconstituer la chronologie à partir des alertes, des tickets et des journaux de changements est un travail répétitif, et un script en fait l’essentiel. Inscrire ces circuits dans les outils est ce que Hopwise Labs construit : des horodatages produits par les outils et un rapport tiré des traces.
Questions fréquentes
Quelle différence entre un post-mortem et un retour d’expérience ?
Aucune sur le fond. Post-mortem, revue post-incident et retour d’expérience désignent le même exercice : établir ce qui s’est passé, pourquoi, et ce qui change. Le nom importe peu. Ce qui compte, c’est un format fixe, une chronologie sourcée et des actions suivies.
Faut-il un post-mortem pour chaque incident ?
Non. Fixez des critères écrits à l’avance : impact visible pour les utilisateurs au-delà d’un seuil, perte de données, intervention manuelle de l’astreinte, durée de résolution au-delà d’un seuil, incident découvert sans alerte. Toute personne concernée doit pouvoir en demander un en dehors de ces critères.
Que veut dire « sans recherche de coupable » ?
Le document cherche les causes qui ont rendu l’erreur possible, pas la personne qui l’a commise. On part du principe que chacun a agi de bonne foi avec l’information dont il disposait. Sinon, les faits gênants disparaissent du récit et la chronologie devient fausse.
Combien de temps après l’incident faut-il l’écrire ?
Fixez un délai interne court, par exemple quelques jours ouvrés pour le brouillon, et tenez-le. Si une obligation de notification s’applique à votre organisation, calez la signature sur son échéance.
Qui doit signer le post-mortem ?
Le responsable du service touché, qui s’engage sur les actions correctives et leurs échéances. La signature ne valide pas un récit, elle valide un plan. Sans propriétaire nommé pour chaque action, le document reste une lecture.