Un postmortem d’incident est une courte analyse écrite d’une panne : ce qui s’est passé, l’impact sur les utilisateurs, pourquoi c’est arrivé et ce que vous allez changer pour que cela ne se reproduise pas. Un postmortem sans reproche (blameless) se concentre sur les systèmes et les processus plutôt que sur la personne qui a commis une erreur. Le modèle de base comporte six parties : résumé, impact, chronologie, cause racine, ce qui a bien ou mal fonctionné, et actions avec responsables et échéances.
Vous trouverez ci-dessous quand en rédiger un, les principes qui le rendent utile, un modèle complet à copier, un exemple rempli et la façon d’en tirer un résumé destiné aux clients.
Quand rédiger un postmortem
Chaque petit accroc ne mérite pas un document. Fixez des déclencheurs clairs pour ne pas avoir à décider sous pression. Les plus courants :
Les clients n’ont pas pu utiliser une fonction essentielle, comme le paiement, la connexion ou l’API, pendant plus de quelques minutes.
Des données ont été perdues, corrompues ou exposées.
L’incident a consommé une grande partie de votre budget d’erreur mensuel.
Des clients ou un client ont signalé le problème avant la surveillance.
Le même type d’incident s’est déjà produit.
Rédigez-le dans les jours ouvrés qui suivent, tant que les souvenirs et les logs sont frais. Un postmortem écrit trois semaines plus tard relève surtout de la conjecture.
Les principes du postmortem sans reproche
Un postmortem sans reproche part du principe que chacun a agi raisonnablement avec les informations dont il disposait à ce moment-là. Si une personne a pu faire tomber le site avec une seule commande, le problème, c’est qu’une seule commande pouvait faire tomber le site. Les reproches poussent les gens à cacher des détails, et ce sont justement ces détails dont vous avez besoin.
Décrivez des actions, pas des personnes. « La tâche d’import a été lancée aux heures de pointe » plutôt que « Anna a lancé l’import au mauvais moment ».
Demandez « comment », pas « qui ». Comment le système a-t-il permis cela ? Comment l’avons-nous découvert ? Comment aurions-nous pu le découvrir plus tôt ?
Cherchez plusieurs causes. Un incident a rarement une seule cause racine. En général, un déclencheur rencontre une faiblesse qu’aucun garde-fou n’a interceptée.
Appuyez-vous sur des faits et des horodatages. Les données de surveillance, les logs et l’historique des discussions valent mieux que la mémoire.
Gardez une liste d’actions courte. Deux ou trois changements réalisés valent mieux que dix qui ne le sont pas.
Le modèle de postmortem
Copiez-le dans votre wiki, votre dépôt ou votre outil de documentation. Chaque titre indique ce qu’il faut y mettre.
# Postmortem : [titre court]
Date de l’incident : [AAAA-MM-JJ]
Auteur(s) : [noms]
Statut : [brouillon / en relecture / final]
Gravité : [p. ex. SEV1 / SEV2 / SEV3]
## Résumé
[Deux ou trois phrases : ce qui est tombé en panne, pendant combien de temps, et comment cela a été corrigé.]
## Impact
– Services et composants touchés :
– Durée (du début au rétablissement) :
– Utilisateurs ou clients touchés :
– Impact business (commandes, inscriptions, SLA) :
– Communication client (page de statut, e-mails, tickets) :
## Détection
– Comment l’incident a-t-il été détecté ? (moniteur, client, membre de l’équipe)
– Délai entre le début et l’alerte :
– Délai entre l’alerte et la prise en charge :
## Chronologie
[Toutes les heures dans un seul fuseau horaire. Une ligne par événement.]
HH:MM événement
HH:MM événement
## Cause racine et facteurs contributifs
– Déclencheur :
– Cause sous-jacente :
– Pourquoi les garde-fous ne l’ont pas intercepté :
## Résolution
[Ce qui a été fait pour rétablir le service, et par qui (le rôle, pas un reproche).]
## Ce qui a bien fonctionné
–
## Ce qui a mal fonctionné
–
## Là où nous avons eu de la chance
–
## Actions
| Action | Type (prévenir / détecter / réagir) | Responsable | Échéance | Ticket |
|——–|————————————-|————-|———-|——–|
| | | | | |
## Résumé pour les clients
[Version courte pour la page de statut ou l’e-mail aux clients.]
La section « Là où nous avons eu de la chance » est facile à sauter et souvent la plus précieuse. Elle recense les incidents évités de justesse : la panne a eu lieu la nuit, la sauvegarde avait tourné une heure plus tôt, la seule personne qui connaissait le système était par hasard réveillée.
Un exemple rempli
Voici le modèle appliqué à un incident fictif sur une boutique en ligne, northwind.shop. Les détails sont inventés pour l’illustration, mais la structure est celle d’un vrai postmortem.
Résumé
De 03:12 à 03:19 CET, le paiement sur northwind.shop a renvoyé 503 Service Unavailable. Un import de produits nocturne a occupé tous les workers PHP-FPM, si bien que les requêtes de paiement ont été rejetées. Le développeur d’astreinte a arrêté l’import et redémarré PHP-FPM. Durée totale de l’indisponibilité : 7 minutes.
Impact
Le paiement et le panier ont été indisponibles pendant 7 minutes. Les pages produits étaient servies depuis le cache et sont restées en ligne.
Les logs du serveur montrent 23 requêtes de paiement échouées sur cette période (chiffre d’exemple).
La page de statut a affiché « Paiement : panne majeure » à partir de 03:13. Aucun ticket de support n’a été reçu.
Chronologie
03:00 L’import de produits nocturne démarre.
03:12 La vérification de disponibilité de northwind.shop/checkout renvoie 503.
03:13 Une seconde vérification confirme l’échec. Un incident s’ouvre, le développeur d’astreinte est alerté sur Telegram et les détails sont publiés dans le canal Slack de l’équipe. La page de statut indique que le paiement est en panne.
03:15 L’astreinte prend en charge l’alerte dans Slack et ouvre le tableau de bord du serveur. La mémoire et le CPU sont élevés sur web-01.
03:17 Le statut de PHP-FPM montre tous les workers occupés par des requêtes d’import. La tâche d’import est arrêtée.
03:18 PHP-FPM est redémarré.
03:19 Les vérifications passent de nouveau. Une notification de rétablissement part avec une durée d’indisponibilité totale de 7 minutes.
Cause racine et facteurs contributifs
Déclencheur : le flux du fournisseur était trois fois plus volumineux que d’habitude après une mise à jour du catalogue.
Cause sous-jacente : l’import passe par le même pool PHP-FPM que la boutique. Un gros import peut occuper tous les workers.
Garde-fou manquant : l’import n’a aucune limite de requêtes simultanées, et aucune alerte n’existait sur la saturation des workers.
Pour comprendre pourquoi des workers épuisés se traduisent par cette erreur précise, consultez notre guide sur l’erreur 503 Service Unavailable.
Ce qui a bien fonctionné, mal fonctionné, et la part de chance
Bien : la détection a pris une minute et la prise en charge deux. La page de statut s’est mise à jour sans intervention manuelle.
Mal : il a fallu quatre minutes pour trouver la cause, car rien ne reliait la tâche d’import aux serveurs web.
Chance : c’est arrivé à 03:12, pas pendant le pic du soir.
Actions
ActionTypeResponsableÉchéanceExécuter l’import dans un pool de workers séparé avec une limite de simultanéitéPrévenirLead backendSous 2 semainesAlerter lorsque la mémoire de web-01 reste au-dessus de 85 %DétecterOpsCette semaineAjouter un heartbeat qui signale la fin de l’importDétecterLead backendCette semaineAjouter le runbook « 503 sur le paiement » au moniteurRéagirRotation d’astreinteCette semaine
Publier un résumé pour les clients
Le postmortem interne est destiné à l’équipe. Les clients ont besoin d’une version plus courte, sans noms de serveurs : ce qui s’est passé, pendant combien de temps, si leurs données sont en sécurité et ce que vous changez. Publiez-la sur votre page de statut et mettez-y un lien depuis chaque e-mail d’incident ou point d’information client. Dans Uptimecheck, vous rédigez l’analyse d’incident directement sur l’incident, à côté de sa chronologie, et pouvez choisir de l’afficher sous l’incident sur votre page de statut.
Paiement indisponible, de 03:12 à 03:19 CET
Entre 03:12 et 03:19 CET, les clients n’ont pas pu finaliser leurs achats
sur northwind.shop. La navigation dans les produits n’a pas été affectée,
et aucune commande ni donnée de paiement n’a été perdue.
La cause était une mise à jour planifiée des produits qui a utilisé plus
de capacité serveur que prévu. Nous l’avons arrêtée, et le paiement a été
rétabli à 03:19.
Nous déplaçons ces mises à jour vers une capacité séparée pour qu’elles ne
puissent plus affecter le paiement, et avons ajouté des avertissements plus
précoces pour ce type de charge.
Gardez un ton factuel et des engagements concrets. « Nous prenons la fiabilité très au sérieux » ne dit rien ; « les imports tournent désormais sur une capacité séparée » dit quelque chose. Notre guide pour créer une page de statut détaille la formulation des mises à jour d’incident.
Il est aussi utile de savoir combien de personnes ont remarqué la panne. Uptimecheck inclut des statistiques de page de statut avec chaque page de statut : visites par jour et par pays, source et appareil sur les 30 derniers jours. Vous pouvez ainsi ajouter au postmortem combien de personnes ont consulté la page le jour de l’incident. Combiné à la chronologie de l’incident, cela vous donne le début, l’alerte, la prise en charge, le rétablissement et la portée sans fouiller dans les logs. Les incidents de site web incluent aussi la réponse en échec, avec une capture d’écran ou un traceroute, un bon point de départ pour les sections détection et cause racine.
Suivre les actions
Un postmortem dont les actions ne sont pas terminées est un récit, pas une correction. Traitez les actions comme n’importe quel autre travail :
Créez un ticket pour chaque action dans l’outil de suivi que l’équipe utilise déjà, et liez-le depuis le postmortem.
Attribuez à chacune un seul responsable et une échéance.
Classez les actions par type : prévenir, détecter ou réagir. Si chaque action se résume à « être plus prudent », l’analyse n’est pas terminée.
Passez en revue les actions de postmortem ouvertes lors d’une réunion régulière, par exemple toutes les deux semaines.
Ne marquez le postmortem comme final que lorsque toutes les actions sont terminées ou explicitement abandonnées avec une raison.
Avec le temps, les postmortems deviennent eux-mêmes des données. Comptez combien d’incidents ont été repérés par la surveillance plutôt que par les clients, et suivez les délais de détection et de réaction d’un incident à l’autre. Notre article sur le MTTR, le MTTA et le MTBF explique comment les calculer.
Animer la réunion d’analyse
Pour les incidents importants, une réunion de 30 à 45 minutes est utile. Partagez le brouillon à l’avance, laissez la personne qui a mené la réponse dérouler la chronologie, et consacrez l’essentiel du temps aux facteurs contributifs et aux actions. Un animateur neutre qui n’a pas travaillé sur l’incident garde la discussion sans reproche et dans les temps. Terminez en confirmant les responsables et les échéances de chaque action.
Obtenez automatiquement les horodatages de votre prochain postmortem. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.