Enregistrer vos post-mortems d’incident : transformer les pannes en savoir d’équipe

Toutes les équipes rédigent un document de post-mortem après une panne. Beaucoup moins les lisent. Une chronologie bien écrite, pleine de liens vers des tableaux de bord et d’extraits de logs, demande au lecteur de reconstituer l’incident dans sa tête — et la plupart survolent, acquiescent et passent à autre chose.

Un court enregistrement d’écran change la donne. Plutôt que de décrire à quoi ressemblait la courbe d’erreurs à 02h14, montrez-la. Plutôt que d’expliquer quelle requête a révélé la cause racine, exécutez-la. Dans ce guide, vous verrez comment enregistrer des post-mortems que l’on regarde réellement, et comment les garder utiles des mois plus tard.

Pourquoi enregistrer un post-mortem

• La preuve vaut mieux que la description : courbes, traces et logs sont visuels par nature — une capture perd le mouvement avant/après qui rend un pic évident
• Plus rapide à produire : commenter ce que vous avez déjà sous les yeux prend moins de temps que d’écrire une prose soignée
• Idéal pour les nouveaux arrivants : six minutes de récapitulatif font comprendre les modes de défaillance du système bien plus vite qu’une page de wiki
• Conserve le raisonnement : les documents disent ce qui s’est passé, la vidéo montre pourquoi la personne d’astreinte a pensé cela à chaque étape
• Adapté à l’asynchrone : les équipes distribuées assimilent la revue sans reprogrammer une réunion entre fuseaux horaires

Ce qu’il faut enregistrer — et ce qu’il faut éviter

Un post-mortem filmé n’est pas le rejeu de tout l’incident. Gardez les moments où voir vaut mieux que lire :

À enregistrer :

• L’instant de la détection — l’alerte, le tableau de bord, le premier signalement utilisateur
• Le graphique clé montrant l’impact sur la fenêtre de l’incident
• Les étapes d’investigation qui ont resserré le champ (impasses comprises)
• Le code, la configuration ou la requête exacte à l’origine de la panne
• L’application du correctif et la remontée des métriques

À écarter :

• Les longues attentes de déploiement ou de chargement de données
• Les échanges internes sans rapport avec le diagnostic
• Tout ce qui tient en une phrase de commentaire

Se préparer avant d’appuyer sur Enregistrer

L’outillage d’incident regorge d’éléments à ne pas diffuser. Accordez-vous cinq minutes :

1. Ouvrez tous les onglets à l’avance : tableaux de bord sur la bonne plage horaire, requête de logs, pull request, alerte
2. Figez les plages temporelles : épinglez les tableaux de bord sur la fenêtre de l’incident pour que tous voient la même chose
3. Fermez les surfaces sensibles : fiches clients, tickets internes contenant des données personnelles, messages privés, gestionnaire d’identifiants
4. Coupez les notifications : rien ne décrédibilise autant un post-mortem sérieux qu’un rappel de déjeuner en plein commentaire
5. Écrivez un plan en trois lignes : impact, cause racine, prévention. Tout le reste en découle

Utilisez la capture de fenêtre plutôt que le plein écran quand votre tableau de bord tient dans une seule fenêtre de navigateur : c’est le moyen le plus simple de garantir qu’aucun autre contenu ne fuite à l’image.

Une structure qui fonctionne

Visez entre cinq et dix minutes. Une structure fiable :

1. L’impact d’abord (30 secondes) : qui a été touché, combien de temps et à quel point. Commencez par là, c’est ce que la plupart viennent chercher
2. Déroulé chronologique (2–3 minutes) : détection, escalade, mitigation, résolution, montrés sur le vrai tableau de bord
3. Cause racine (2–3 minutes) : affichez le chemin de code, le changement de configuration ou la requête. Zoomez sur les lignes concernées
4. Ce qui a compliqué les choses (1 minute) : alertes manquantes, logs confus, responsabilités floues — ce que les documents aplatissent d’habitude
5. Actions (1 minute) : énoncez chaque action avec son responsable, puis liez-les dans la description

Rendre la vidéo lisible grâce à l’éditeur

Les rushes d’incident sont denses. L’éditeur de Recorded en fait quelque chose de suivable :

• Effets de zoom : les tableaux de bord et les logs sont petits. Zoomez sur le pic, le message d’erreur, le diff fautif — n’obligez personne à plisser les yeux
• Zones de vitesse : accélérez les pipelines de déploiement et l’exécution des requêtes, revenez à la vitesse normale quand la cause apparaît
• Superpositions de texte : incrustez les horodatages (02h14 UTC — première alerte) pour relier la vidéo au document
• Découpe : supprimez le faux départ où vous découvrez que le tableau de bord affichait la mauvaise plage
• Effets de curseur : mettez les clics en évidence quand vous montrez le chemin de reproduction

Réservez la webcam à l’introduction et à la conclusion. Un visage aide à poser le ton sur l’impact et les actions ; pendant l’analyse des logs, il masque simplement le terminal.

Rester sans blâme devant la caméra

La vidéo transmet le ton bien plus que l’écrit. La même phrase passe pour de l’analyse ou pour une accusation selon la façon de la dire.

• Dites « ce déploiement a introduit » plutôt que de nommer qui l’a livré
• Racontez les décisions dans le contexte de l’époque : « à ce stade, nous n’avions pas encore la métrique de profondeur de file »
• Montrez les impasses sans vous excuser : elles prouvent que le système était difficile à diagnostiquer, ce qui constitue en soi une action
• Refaites l’introduction si votre première prise sonne agacée. Deux minutes suffisent, et cela donne le ton à tous les spectateurs

Associer vidéo et document écrit

L’enregistrement complète le document de post-mortem, il ne le remplace pas. Un document se cherche, se lie et se survole — une vidéo, non.

Une bonne association :

• Le document reste la source de vérité pour la chronologie, les actions et les responsables
• La vidéo est intégrée en haut, avec une ligne résumant ce qu’elle couvre
• Des horodatages de chapitres dans la description permettent d’aller droit à la cause racine
• Les actions vivent dans votre outil de suivi, pas seulement dans la vidéo

Constituer une bibliothèque d’incidents

Un enregistrement isolé est utile. Une collection l’est bien plus.

• Nommez de façon cohérente : 2026-09-28-checkout-latency-postmortem se trie et se recherche proprement
• Étiquetez par système : regroupez par service concerné pour transmettre d’un bloc tout ce qui touche un composant à une nouvelle personne d’astreinte
• Passez-les en revue chaque trimestre : en enchaînant les enregistrements du trimestre, les modes de défaillance récurrents sautent aux yeux
• Servez-vous-en pour l’onboarding : trois ou quatre incidents sélectionnés restent le moyen le plus rapide d’apprendre comment votre système casse réellement

Erreurs fréquentes

• Enregistrer pendant l’incident : concentrez-vous d’abord sur la mitigation. La revue se filme après, au calme
• Partager les rushes : un partage d’écran brut de 40 minutes n’est pas un post-mortem — personne ne le regarde
• Divulguer des données clients : regardez toujours votre vidéo une fois avant de la partager, en traquant les données personnelles dans les logs et tableaux de bord
• Sauter le résumé d’impact : ceux qui ne regardent que la première minute doivent repartir avec l’essentiel
• Laisser la vidéo remplacer le document : dans six mois, quand un incident similaire démarrera, on ne peut pas faire de recherche dans une vidéo

Conclusion

Un post-mortem échoue quand il est écrit pour être classé plutôt que compris. Un enregistrement d’écran ciblé — impact en tête, preuves à l’écran, commentaire sans blâme, actions claires — transforme chaque panne en quelque chose que toute l’équipe peut apprendre en dix minutes.

Enregistrez votre prochain post-mortem au lieu de seulement l’écrire, et observez combien de personnes s’y intéressent enfin.