# Éléments d'action post-mortem : 58 % ne clôturent jamais URL: https://upstreamapi.com/fr/journal/elements-action-post-mortem Type: blog Locale: fr Published: 2026-09-05 Updated: 2026-09-06 --- > Les éléments d'action post-mortem échouent parce qu'ils manquent de responsables nommés, restent dans des docs non relus et n'atteignent jamais le sprint. Votre équipe a mené un post-mortem mardi dernier. Vous avez rédigé six éléments d'action post-mortem. Aujourd'hui, deux ont peut-être un ticket Jira. L'un d'eux a un responsable qui est sur un autre incident. Les trois autres sont dans le Google Doc, sous la rubrique "Follow-ups", intacts. Les éléments d'action, c'est là que le post-mortem tient ses promesses ou les rate. La plupart les ratent. La recherche d'incident.io situe le taux de clôture sous les 50 % pour l'équipe SRE médiane. Cela signifie que le post-mortem moyen produit autant de changements qu'un vote de rétrospective : le processus tourne, la blame reste blameless, et le même mode de défaillance passe en prod six semaines plus tard. La solution n'est pas un meilleur template. C'est une compréhension différente de ce qui rend un élément d'action réel. ## Pourquoi les éléments d'action post-mortem sont structurellement cassés Écrire "améliorer le monitoring" dans un post-mortem donne l'impression d'être productif. Ce n'est pas un élément d'action : c'est une catégorie de travail sans responsable, sans deadline, et sans définition de "terminé". Un élément d'action efficace comporte trois parties irréductibles : ce qui doit être fait (spécifique et mesurable), qui en est responsable (un ingénieur nommé, pas une équipe), et pour quand (une date précise, pas "Q3"). L'absence de l'une de ces trois parties suffit à condamner l'item. Les items fictifs ne sont pas déprioritisés - ils se dissolvent. Personne ne décide activement de ne pas les traiter. Ils ne remontent simplement jamais dans les systèmes où le travail se planifie vraiment. La distinction est nette. "Améliorer le rate limiting" est une fiction. "Ajouter un circuit breaker sur les appels upstream vers l'API search dans le chemin checkout - responsable @anya, cible : mergé avant le 2026-09-19" est un élément d'action. L'un apparaîtra dans un standup. L'autre non. La défaillance structurelle se produit au moment de la rédaction, quand les ingénieurs sont fatigués, la réunion s'éternise, et la pression de conclure est plus forte que la pression d'être précis. C'est exactement là que la précision compte le plus - parce que le contexte se dégrade vite, et le détail que vous sautez à 23h est celui dont @anya aura besoin dans trois semaines. ## Le chiffre qui devrait inquiéter chaque tech lead Plus de 50 % des éléments d'action post-mortem ne sont jamais complétés dans les équipes SRE typiques. Dans les organisations avec une culture d'incident faible, ce chiffre dépasse 70 %. Voici ce que ça signifie à l'échelle. Si vos post-mortems génèrent en moyenne quatre items par incident et que vous gérez dix incidents par trimestre, vous produisez 40 items, vous en complétez moins de 20, et vous accumulez un backlog croissant de modes de défaillance non corrigés. L'incident suivant a statistiquement de bonnes chances d'être une variante de quelque chose que vous avez déjà diagnostiqué. Les recherches DORA montrent régulièrement que les organisations d'ingénierie les plus performantes ont des taux de change failure rate plus faibles non pas parce qu'elles rédigent de meilleurs post-mortems, mais parce qu'elles clôturent leurs items d'action. Le document n'est pas le travail. Le ticket est le travail. Quand les taux de clôture passent sous 50 %, les post-mortems deviennent du théâtre. L'équipe le sait. Les ingénieurs qui écrivent des items soignés regardent leur travail pourrir. Progressivement, la qualité des items rédigés descend pour correspondre au taux de clôture. Pourquoi écrire un item précis si personne ne clôture ceux qui existent déjà ? ## Mitigatifs et préventifs : deux files d'attente distinctes Les éléments d'action post-mortem se divisent en deux catégories, et les traiter de manière identique est une erreur de planification qui s'aggrave dans le temps. Les items mitigatifs réduisent le blast radius de la prochaine occurrence avant d'avoir éliminé la cause racine. Ajouter un fallback. Fixer un timeout. Câbler un circuit breaker. Ces items sont presque toujours urgents et doivent être shippés dans le sprint en cours - idéalement avant que la réunion de post-mortem ne se termine s'ils sont suffisamment petits. Les items préventifs éliminent le mode de défaillance entièrement : refactoring du consumer de queue, refonte de la logique de retry, instrumentation du gap SLO qui a laissé passer l'incident sous votre alerte de burn rate. Ils prennent plus de temps, nécessitent une design review, et entrent en compétition directe avec le travail fonctionnel. Tout mélanger dans un seul label "actions post-mortem" signifie que les items préventifs longs traînent dans la liste assez longtemps pour que l'équipe oublie pourquoi ils ont été rédigés, pendant que les items mitigatifs attendent dans la même file derrière eux. Séparez-les explicitement. Les mitigatifs vont dans le sprint en cours avant que le planning ne ferme. Les préventifs sont dimensionnés et priorisés contre votre roadmap sur leur propre calendrier, traités comme n'importe quel investissement fiabilité, pas comme des post-it attachés à un incident déjà fermé. ![Un tableau kanban sur un moniteur avec des cartes projet en statut de retard surlignées, ingénieur pointant des items à revoir](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/07c92a-inline1.webp) ## Là où les éléments d'action vont mourir Le Google Doc est la morgue la plus répandue. Les équipes rédigent leurs post-mortems dans des documents partagés parce que les docs sont peu contraignants en plein incident. Le problème : le doc n'est pas là où le travail d'ingénierie vit. Jira, oui. Linear, oui. GitHub Issues, oui. Où que votre sprint planning se déroule : c'est là qu'un élément d'action doit atterrir avant que la réunion de post-mortem ne se termine. Le gap d'intégration est le point de défaillance le plus prévisible de tout le workflow. L'incident survient. Le post-mortem tourne. De bons items sont rédigés. Ensuite, quelqu'un doit les copier manuellement dans le système de tickets. Cette étape de copie a un taux de complétion d'environ 40 % dans les équipes qui ne l'automatisent pas ou ne l'imposent pas. La solution n'est pas un nouvel outil : c'est supprimer le gap entre le document de post-mortem et le système de sprint. Plusieurs plateformes de gestion d'incidents créent désormais des tickets Jira ou Linear directement depuis les templates de post-mortem. Les outils de prise de notes qui génèrent des items structurés avec responsables et s'intègrent à votre tracker remplissent la même fonction. Le principe clé : aucun ingénieur ne devrait copier-coller depuis un doc vers un ticket après une réunion de revue de 90 minutes en fin d'astreinte. ## Le problème du responsable : les équipes ne clôturent pas les tâches Assigner un élément d'action à une équipe est l'équivalent organisationnel de l'assigner à personne. Les équipes n'ont pas de rappels calendrier. Elles ne reçoivent pas de notifications Jira. Elles ne remontent pas en standup quand un item est en retard. "La platform team" n'a pas de boîte de réception. @carlos, si. Les responsables nommés comptent, mais les responsables nommés avec contexte comptent davantage. "Corriger le consumer de queue" assigné à @carlos est mieux que rien. "@carlos : ajouter un exponential backoff au consumer SQS dans payments-worker - voir la chronologie de l'incident pour le burst pattern apparu à 14:23 UTC. Cible : mergé avant la clôture du sprint 2026-09-26, Jira : PAY-2891" est quelque chose que @carlos peut exécuter sans une conversation de suivi. Le post-mortem est le moment où le contexte est au plus haut. C'est à ce moment-là que vous rédigez l'item. Le détail se dégrade vite : en 48 heures, la moitié de la salle a oublié le burst pattern spécifique qui a déclenché la défaillance. En deux semaines, l'incident est du bruit de fond. L'item rédigé avec le contexte complet à la fin de la réunion de post-mortem est celui qui se clôture. L'item qui reçoit "on écrira ça proprement plus tard" se retrouve orphelin. ![Une équipe d'ingénierie lors d'une discussion de post-mortem autour d'un tableau blanc avec des diagrammes de chronologie d'incident](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/b55433-inline2.webp) Une fraction significative des éléments d'action concerne les gaps d'observabilité : une métrique non instrumentée, un seuil d'alerte trop lâche, un dashboard existant mais non lié depuis le runbook, une fenêtre SLO trop large pour détecter la dégradation avant que les utilisateurs ne la remarquent. Ces items ont un pattern de défaillance prévisible. Ils nécessitent un accès à votre stack de monitoring et une coordination entre l'équipe produit et l'équipe plateforme - un point de handoff où personne ne possède formellement la clôture. La correction : traiter ces items comme une catégorie de premier ordre avec un responsable direct dans l'équipe plateforme, pas dans l'équipe produit qui a subi l'incident. ## Fermer la boucle de feedback que personne ne ferme Il y a une étape après la complétion que la plupart des équipes sautent entièrement : la reconnaître. Quand un élément d'action du post-mortem #47 évite la récurrence qui aurait donné l'incident #58, cette connexion doit être rendue visible. Écrivez-le dans votre canal incident. Mettez-le dans le prochain update engineering all-hands. Dites à l'ingénieur on-call qui possédait PAY-2891 que son circuit breaker a absorbé un burst jeudi dernier et que rien n'a pagué. Les équipes d'ingénierie clôturent davantage d'éléments d'action quand elles voient leur travail payer. Les équipes qui rédigent des items dans un document que personne ne relit finissent par arrêter de les rédiger sérieusement : la forme reste, mais la qualité descend pour correspondre à l'impact perçu. C'est ainsi qu'une culture blameless peut quand même produire une culture de fiabilité sans mémoire. À 3h du matin, l'ingénieur on-call qui a corrigé un timeout le trimestre dernier parce qu'il possédait un item sait exactement à quoi servait ce travail. Rendez cette connexion explicite pour toute l'équipe, pas seulement pour la personne qui était on-call quand le correctif a prouvé sa valeur. ## À quoi ressemble un élément d'action post-mortem qui fonctionne Voici le format qui clôture de manière consistante : `Item : Ajouter un circuit breaker sur les appels upstream search-service (chemin payments) Responsable : @danielle Type : mitigatif Deadline : 2026-09-12 (avant le prochain déploiement en prod) Ticket : PAY-2891 Contexte : les timeouts search-service ont causé une défaillance en cascade dans checkout à 14:23 UTC ; le circuit breaker limite le blast radius lors de la prochaine occurrence pendant que le refactoring est en cours de cadrage`Sept champs. Le champ "Contexte" n'est pas optionnel. C'est ce qui survit au gap de trois semaines entre le post-mortem et le sprint où @danielle a enfin de la bande passante. Sans lui, l'item est une tâche sans histoire. Avec lui, @danielle peut ouvrir PAY-2891 à froid et savoir exactement ce qu'elle construit et pourquoi ça compte. ![Un développeur devant son laptop avec des indicateurs verts de merge visibles à l'écran, élément d'action post-mortem clôturé](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/899b10-inline3.webp) ## Ce que ça exige du tech lead La clôture des éléments d'action est une métrique de tech lead, pas une métrique d'ingénieur. Les ingénieurs rédigent les items. Le lead est responsable du système qui assure leur clôture. Concrètement, cela implique quatre choses. Premièrement, de la capacité de sprint allouée aux items mitigatifs avant que le planning ne commence - pas après que l'équipe a commis sa vélocité au travail fonctionnel. Si les items mitigatifs doivent se battre pour des restes, ils perdent. Deuxièmement, une revue debout de cinq minutes des items post-mortem ouverts lors du sync hebdomadaire. Pas une cérémonie. Juste un scan : quelque chose de plus de 14 jours qui n'est pas encore dans un ticket, quelque chose en retard qui nécessite une décision. Troisièmement, une déprioritisation explicite quand quelque chose ne peut genuinement pas être fait. "Nous ne faisons pas PAY-2891 ce trimestre parce que le refactoring payments arrive en Q4 et ceci devient redondant" est une décision. "PAY-2891 est dans le backlog depuis trois mois" est un échec de processus. Quatrièmement, suivre le taux de clôture des éléments d'action comme une métrique de santé d'équipe, au même titre que la fréquence de déploiement et le MTTR. Les équipes qui le mesurent constatent une moyenne d'environ 42 % sans processus délibéré. Avec des responsables nommés, une intégration sprint et une revue hebdomadaire, ce chiffre dépasse 75 % en deux trimestres. La différence en termes de fiabilité est à peu près équivalente à prévenir un incident majeur supplémentaire par trimestre pour une équipe qui tourne à dix incidents. Le post-mortem vous a dit ce qui a cassé. L'élément d'action est le contrat pour le corriger. Si ce contrat se clôture ou non, c'est une décision de management, pas un problème de qualité documentaire. Pour aller plus loin, le [SRE Book de Google sur la culture post-mortem](https://sre.google/sre-book/postmortem-culture/) reste la référence blameless la plus documentée du secteur. ## FAQ ### Qu'est-ce qui rend un élément d'action post-mortem efficace ? Un élément d'action efficace comporte trois parties irréductibles : ce qui doit être fait (spécifique et mesurable, pas une catégorie comme «améliorer le monitoring»), qui en est responsable (un ingénieur nommé, pas une équipe), et pour quand (une date précise). L'absence de l'une de ces trois parties condamne l'item. Ajouter un champ «Contexte» qui explique pourquoi l'item compte améliore significativement les taux de clôture quand la bande passante est rare. ### Quelle est la différence entre items mitigatifs et préventifs ? Les items mitigatifs réduisent le blast radius d'une occurrence future avant d'avoir éliminé la cause racine : circuit breakers, timeouts, fallbacks, seuils d'alerte. Ils sont presque toujours urgents et doivent être shippés dans le sprint en cours. Les items préventifs éliminent le mode de défaillance entièrement - refactoring de logique de retry, refonte d'un consumer de queue. Ils prennent plus de temps et doivent être dimensionnés et priorisés sur votre roadmap de fiabilité séparément. ### Pourquoi les éléments d'action post-mortem ne sont-ils pas complétés ? Les causes les plus fréquentes sont les descriptions vagues ("améliorer le monitoring"), la responsabilité assignée à une équipe plutôt qu'à un ingénieur nommé, et les items qui restent dans un document de post-mortem jamais connecté au système de tickets où le travail de sprint se déroule. Le gap d'intégration entre le doc et Jira ou Linear est là où la majorité des items se perdent. ### Quel est un taux de clôture réaliste pour les équipes SRE ? La recherche d'incident.io indique que l'équipe SRE médiane complète moins de 50 % de ses éléments d'action post-mortem. Sans processus délibéré, les taux de clôture tournent autour de 42 %. Les équipes qui ajoutent des responsables nommés, une intégration sprint et une revue hebdomadaire des items ouverts atteignent généralement plus de 75 % en deux trimestres. Les organisations les plus performantes traitent tout ce qui est sous 70 % comme un risque de fiabilité. ### Les éléments d'action post-mortem doivent-ils aller dans le sprint en cours ? Les items mitigatifs - ceux qui réduisent le blast radius avant que le mode de défaillance ne soit éliminé - doivent atterrir dans le sprint en cours avant que le planning ne ferme, idéalement avant la fin de la réunion de post-mortem s'ils sont suffisamment petits. Les items préventifs sont dimensionnés et priorisés contre la roadmap sur un calendrier séparé. Mélanger les deux dans la même file de sprint sans les distinguer est une erreur de planification courante. ### Comment suivre les éléments d'action post-mortem sans alourdir le processus ? L'approche la plus efficace consiste à éliminer le gap entre le document de post-mortem et l'outil de sprint que votre équipe utilise déjà. Les éléments d'action doivent devenir des tickets Jira, Linear ou GitHub Issues avant que la réunion ne se termine - manuellement par le facilitateur ou via intégration. Les équipes qui comptent sur le copier-coller manuel depuis un doc vers un ticket après la réunion perdent environ 60 % des items à cette étape.