Analyser un incident à partir d’une réunion enregistrée : modèle de post-mortem
Préparez un post-mortem après une panne : chronologie, impact, causes confirmées et mesures. Avec exemple et modèle sans recherche de coupable.
Reconstituez d’abord les événements
Après une panne, chacun se rappelle des moments différents : l’erreur, un message ultérieur ou le début de la correction. Un récit convaincant peut inverser des faits. Commencez par une chronologie vérifiable.
Faites le post-mortem après le rétablissement initial. L’enregistrement contient les explications. Vérifiez les heures dans les messages, journaux et autres sources. Gardez les données internes hors du rapport public.
Construisez l’analyse en quatre parties
Décrivez l’impact
Indiquez la fonction indisponible, les personnes touchées et la période. Distinguez impact confirmé et possible. Si le nombre d’utilisateurs touchés est inconnu, signalez-le.
Construisez la chronologie
Rassemblez début, détection, signalement, premières actions et rétablissement. Indiquez le fuseau horaire. Si seul un souvenir atteste un événement, conservez la source et le degré de certitude. Marquez les heures approximatives.
Vérifiez les explications
Distinguez le déclencheur des conditions qui ont permis ou prolongé la panne. Demandez ce que la personne savait au moment de décider. Reliez chaque hypothèse aux preuves et indiquez ce qui la réfuterait.
Prévoyez des mesures vérifiables
Choisissez des actions qui réduisent un risque ou accélèrent la détection ou le rétablissement. Donnez à chacune un responsable, un résultat et un contrôle. « Être plus attentif » ne décrit aucun changement vérifiable.
Les notifications de nouvelles demandes cessent d’arriver
Cet exemple est fictif. Les noms, conditions et résultats servent à expliquer la méthode.
Les demandes étaient enregistrées, mais les notifications n’arrivaient plus. Un gestionnaire nous l’a signalé. Nous avons vérifié la liste, puis l’avons consultée manuellement pendant un temps.
Les demandes restaient accessibles. La distribution des notifications était en panne. Cette distinction détermine l’impact et les mesures.
La chronologie est illustrative. Elle montre l’écart entre le début et la détection. La cause technique reste à établir.
| Observation | Hypothèse | Prochaine vérification |
|---|---|---|
| Les demandes sont présentes, les notifications n’arrivent pas | Panne à la livraison | Vérifier le journal d’envoi |
| Signalement d’un gestionnaire | Aucune alerte adaptée | Vérifier la surveillance de la livraison |
| Le contrôle manuel a aidé | Une solution temporaire existe | Définir quand l’utiliser |
Modèle de post-mortem
Gardez les causes possibles au statut d’hypothèses jusqu’à leur vérification.
Incident, période et fuseau horaire : Impact confirmé : Chronologie : heure / événement / source : Déclencheur : Conditions contributives : Ce qui a aidé au rétablissement : Ce qui reste inconnu : Mesure / responsable / délai / contrôle : Quand vérifier la réalisation :
Vérifiez que l’analyse aide à éviter une récidive
- L’impact est décrit plus précisément que « tout est tombé en panne ».
- L’heure des faits se distingue de celle des échanges.
- Les causes confirmées sont distinctes des hypothèses.
- Chaque mesure correspond à un problème observable et à un contrôle.
Dans le détail
Un post-mortem et une rétrospective sont-ils identiques ?
Le post-mortem porte sur un incident précis et ses effets. La rétrospective peut couvrir toute une période, y compris les pratiques réussies et les expériences.
Que faire si la cause reste inconnue ?
Partagez en interne les éléments confirmés et les contrôles ouverts. Laissez la cause en suspens en attendant les preuves.