Modèle de post-mortem de projet

Analysez tout projet ou incident, capturez les leçons apprises

Essayez ce concert rétrospectif

Vue d'ensemble du projet, objectifs et périmètre

Que visait le projet, et pour quelle date ?

L'objectif était de migrer toute la facturation client vers la nouvelle plateforme avant la fin du T3, sans aucune interruption pour les comptes entreprise.
Nous avons livré le portail client trois semaines après la date initiale, avec deux des cinq fonctionnalités prévues abandonnées.
Les critères de succès n'ont jamais été écrits quelque part où j'aurais pu les trouver, donc j'avais ma propre version en tête.
Ce qui a bien marché

Quels succès et processus méritent d'être répétés ?

Des points quotidiens de quinze minutes pendant la période de rush ont maintenu tout le monde aligné sans alourdir la charge de réunions.
Notre runbook d'astreinte était exact, ce qui a permis d'appliquer le correctif en quelques minutes plutôt qu'en quelques heures.
Faire travailler les nouveaux développeurs en binôme avec des relecteurs très tôt les a rendus productifs plus vite que je ne l'imaginais.
Ce qui n'a pas bien marché

Où avons-nous bloqué, cassé ou manqué nos objectifs ?

Les exigences n'arrêtaient pas de changer et personne n'était clairement responsable de décider quand elles étaient figées.
Les tests ont été comprimés sur les derniers jours, ce qui explique pourquoi deux défauts sont arrivés chez les clients.
Notre supervision ne couvrait pas la profondeur de la file d'attente, nous étions donc aveugles jusqu'à ce que tout soit déjà engorgé.
Analyse des causes racines

Pourquoi cela a-t-il échoué, pas seulement que cela a échoué ?

La cause racine était un changement de configuration déployé directement en production parce que notre pipeline n'avait pas d'étape de relecture obligatoire.
Nous avons sous-estimé parce que l'estimation a été faite avant le spike technique puis traitée comme un engagement.
Personne ne portait l'intégration entre les deux équipes, donc l'écart est resté invisible jusqu'à la semaine d'intégration.
Leçons apprises

Quels enseignements clés emportons-nous ?

Faire le spike technique avant de nous engager sur des dates, puis re-estimer ouvertement.
Écrire les critères de succès au lancement. Si nous ne parvenons pas à nous entendre dessus, nous ne sommes pas prêts à démarrer.
Les changements de périmètre doivent passer par un point de contrôle écrit plutôt que d'être discrètement absorbés par l'équipe.
Actions, responsables et échéances

Qui fait quoi, et pour quand ?

Ajouter une étape de relecture obligatoire au pipeline de déploiement en production. Responsable : Priya. Échéance : fin du prochain sprint.
Rédiger une charte de projet d'une page avec des critères de succès. Responsable : Sam. Échéance : le 15.
Ajouter des alertes sur la profondeur de file et le taux d'erreur, routées vers l'astreinte. Responsable : Dev. Échéance : cette semaine.
Reconnaissance et félicitations à l'équipe

Qui mérite d'être reconnu avant de clôturer ?

Merci à Priya d'être restée calme pendant la cellule de crise et d'avoir gardé tout le monde concentré sur le correctif.
Bravo à l'équipe support qui a absorbé les contacts clients presque sans préavis.
Grande reconnaissance pour Sam, qui a écrit discrètement le runbook que personne n'avait demandé et qui nous a ensuite sauvés avec.

Qu'est-ce qu'une rétrospective post-mortem ?

Un post-mortem, c'est la conversation que votre équipe a après la fin de quelque chose. Parfois, ce quelque chose est un incident : un système est tombé, une mise en production a déraillé, un client en a subi les conséquences. Tout aussi souvent, il s'agit d'un projet ordinaire qui vient simplement de se terminer, et vous voulez un modèle de post-mortem clair pour animer la réunion de revue sans avoir à inventer un ordre du jour de toutes pièces. Ce format couvre les deux cas. Vous posez le cadre avec les objectifs et le périmètre du projet, vous passez en revue ce qui a bien marché et ce qui n'a pas marché, vous creusez les causes racines là où c'est utile, et vous transformez les constats honnêtes en leçons apprises que votre organisation pourra réellement réutiliser. Voici comment cela fonctionne dans TeamRetro. Chacun ajoute d'abord ses propres observations en privé, pour que la voix la plus forte de la salle ne fixe pas le récit avant que les personnes plus discrètes n'aient rien écrit. Les idées sont ensuite regroupées, discutées et votées, ce qui vous permet de prioriser la poignée de thèmes qui compte vraiment plutôt que de mâcher quarante commentaires dans un ordre aléatoire. C'est là toute la différence avec un modèle de post-mortem statique que vous remplissez seul : il s'agit d'un débriefing d'équipe vivant que tout votre groupe mène ensemble, et il se termine par des responsables et des échéances associés à de vraies actions, plutôt que par un document que personne ne rouvrira. Utilisez-le comme revue de projet par défaut à la clôture d'une livraison, d'une campagne, d'une migration ou d'un trimestre, et comme revue d'incident quand quelque chose s'est mal passé et que vous avez besoin d'un compte rendu sans reproche de la chronologie et de ses causes. Le dernier sujet laisse la place aux félicitations, car reconnaître les personnes qui ont porté le travail fait partie d'une clôture bien menée. Dans tous les cas, l'objectif est le même. Vous voulez que l'équipe reparte en sachant quoi répéter, quoi arrêter, et qui fait quoi ensuite. Votre rapport est exporté automatiquement, de sorte que les leçons apprises restent consultables pour la prochaine équipe qui se retrouvera dans la même situation.

Format de la rétrospective post-mortem

Vue d'ensemble du projet, objectifs et périmètre

Que visait le projet, et pour quelle date ?

Ce sujet pose le cadre avant que quiconque ne juge quoi que ce soit. Demandez l'objectif initial, le périmètre convenu, le calendrier et les critères de succès, ainsi que ce qui a réellement été livré par rapport à cela. Pour une revue d'incident, utilisez-le plutôt pour les faits chronologiques : ce qui est tombé, quand cela a été détecté, qui était impliqué et comment cela a été résolu. Gardez l'interprétation hors de cette colonne et réservez les opinions aux sujets suivants. Si les gens ne sont pas d'accord sur ce qu'étaient les objectifs ou les critères de succès, ce désaccord est en lui-même un constat à consigner.

Ce qui a bien marché

Quels succès et processus méritent d'être répétés ?

Les équipes passent trop vite sur ce sujet, surtout après un projet difficile ou un incident stressant, alors protégez ce temps. Vous cherchez des pratiques reproductibles, pas des compliments, et les félicitations ont leur propre sujet plus loin. Quand quelqu'un poste un éloge, demandez ce qui, concrètement, a fait que cela a fonctionné, afin que la réponse puisse être réutilisée. Attention aux succès qui reposent sur l'héroïsme individuel : nommez-les comme des risques plutôt que comme des réussites.

Ce qui n'a pas bien marché

Où avons-nous bloqué, cassé ou manqué nos objectifs ?

C'est ici que se trouve la vraie valeur, alors énoncez à voix haute la règle du sans-reproche avant de commencer : vous examinez des systèmes et des décisions, pas des personnes. Encouragez les faits précis plutôt que les plaintes vagues, car « la communication était mauvaise » n'est pas actionnable alors que « nous avons appris le changement de deadline dans une conversation de couloir » l'est. Utilisez le vote ici pour éviter que la discussion ne s'éparpille sur toutes les irritations des trois derniers mois.

Analyse des causes racines

Pourquoi cela a-t-il échoué, pas seulement que cela a échoué ?

Optionnel pour une simple revue de projet, essentiel pour un incident. Prenez les problèmes les plus votés du sujet précédent et continuez à demander pourquoi jusqu'à atteindre une condition plutôt qu'une personne : un garde-fou manquant, un responsable flou, une pression de calendrier, une hypothèse que personne n'a testée. La méthode des Cinq Pourquoi fonctionne bien ici, tout comme la question de savoir ce qui a fait paraître raisonnable la mauvaise décision sur le moment. Arrêtez-vous quand vous atteignez quelque chose que vous pouvez réellement changer, et notez les facteurs contributifs séparément du déclencheur.

Leçons apprises

Quels enseignements clés emportons-nous ?

C'est le « et alors ? » qui transforme les observations en connaissances réutilisables. Poussez chaque idée jusqu'à ce qu'elle nomme un comportement, un déclencheur ou un garde-fou, afin qu'elle survive au contact du prochain projet. Distinguez ce que cette équipe peut changer elle-même de ce qui doit remonter à un manager ou à un autre groupe, et soyez honnête sur la seconde catégorie. Formulez les enseignements de sorte qu'une personne extérieure à la salle puisse les lire dans le rapport exporté et les comprendre sans que vous soyez là pour les expliquer.

Actions, responsables et échéances

Qui fait quoi, et pour quand ?

Un post-mortem sans actions assignées ne compte pas, alors réservez-y du vrai temps plutôt que de le caser dans les deux dernières minutes. Convertissez les leçons les plus votées en un petit nombre d'actions précises, chacune avec un responsable nommé et une échéance enregistrée dans TeamRetro pour qu'elles réapparaissent à votre prochaine session. Deux ou trois actions bien portées valent mieux que dix vœux pieux. Si une action revient à quelqu'un d'extérieur à la salle, décidez qui la lui transmettra et pour quand.

Reconnaissance et félicitations à l'équipe

Qui mérite d'être reconnu avant de clôturer ?

Terminez sur les personnes, pas sur les problèmes. Invitez chacun à nommer une personne précise et une chose précise qu'elle a faite, ce qui est bien plus significatif que des remerciements généraux et fonctionne bien même après un projet difficile. Cela compte d'autant plus quand la revue a été éprouvante, car cela rappelle à l'équipe qu'examiner un échec n'est pas la même chose que se blâmer mutuellement. Faites court, lisez-en quelques-uns à voix haute et laissez le rapport exporté porter le reste.

Dans quels cas recourir à cette étude rétrospective ?

  • Un projet, une livraison, une migration ou une campagne vient de se terminer et vous voulez une revue de projet structurée plutôt qu'une discussion informelle qui s'évapore.
  • Un incident, une panne ou une mise en production ratée nécessite un post-mortem sans reproche couvrant la chronologie, les causes racines et les actions préventives.
  • Un programme au long cours a terminé une phase et vous voulez capturer les leçons apprises tant que les détails sont encore frais.
  • Un groupe transverse se dissout, et c'est votre dernière occasion de mener un débriefing d'équipe et de reconnaître les contributeurs avant que chacun ne parte vers de nouveaux travaux.
  • Quelque chose s'est déroulé étonnamment bien et vous voulez comprendre pourquoi, afin que la pratique puisse être répétée plutôt que considérée comme un coup de chance.

Exemples de questions pour brise-glace

  • En un mot, quel ressenti aviez-vous au milieu de ce projet ou de cet incident ?
  • Si vous pouviez renvoyer une phrase de conseil à vous-même au premier jour, que dirait-elle ?

Vous souhaitez un exercice d'échauffement que votre équipe puisse pratiquer, et pas seulement répondre à voix haute ? Découvrez des brise-glaces gratuits →

Idées et conseils pour votre réunion de rétrospective

  • Menez-la dans la semaine ou les deux semaines suivant la clôture du projet ou la résolution de l'incident. Les souvenirs s'estompent vite et les détails utiles avec eux.
  • Énoncez la règle du sans-reproche au début. Vous examinez des décisions, des systèmes et des pressions, vous ne cherchez pas un coupable.
  • Consacrez quelques minutes à valider la vue d'ensemble du projet avant que les opinions ne s'expriment. Un cadre partagé évite que la session ne devienne un débat sur ce qu'était l'objectif.
  • Passez ou raccourcissez l'analyse des causes racines pour une revue de projet sans encombre, et appuyez dessus pour les incidents où la prévention est l'enjeu.
  • Priorisez par le vote, puis ne laissez pas la réunion se terminer sans responsables et échéances sur les principales actions, sinon vos leçons apprises resteront théoriques.
  • Amenez les actions du post-mortem précédent dans la salle et passez-les en revue en premier. Rien n'améliore le suivi comme savoir qu'il sera vérifié.

Foire aux questions

Qu'est-ce qu'un post-mortem de projet ?
Un post-mortem de projet est une revue structurée que votre équipe mène une fois un travail terminé, qu'il s'agisse du lancement d'un produit, d'une migration, d'une campagne ou d'une livraison client. Vous examinez les objectifs et le périmètre initiaux, ce qui a bien marché, ce qui n'a pas marché, et les leçons apprises qui valent la peine d'être conservées. Contrairement à un post-mortem d'incident, rien n'a nécessairement mal tourné. Le déclencheur est simplement que le travail est terminé et qu'il y a des connaissances à conserver.
En quoi un post-mortem de projet diffère-t-il d'un post-mortem d'incident ?
Le format est similaire mais le focus diffère. Un post-mortem d'incident est déclenché par une défaillance, il s'appuie donc largement sur la reconstruction de la chronologie, la détection, la réponse et l'analyse des causes racines, avec la prévention pour objectif. Un post-mortem de projet est déclenché par l'achèvement, il couvre donc les objectifs, l'estimation, le périmètre, la collaboration, le transfert et la livraison, avec l'amélioration du prochain projet pour objectif. Les deux doivent être sans reproche et les deux doivent se terminer par des actions portées par quelqu'un.
Que faut-il inclure dans un post-mortem de projet ?
Commencez par la vue d'ensemble du projet : objectifs, périmètre, calendrier, critères de succès et ce qui a réellement été livré. Puis abordez ce qui a bien marché, ce qui n'a pas marché, et les causes racines des problèmes qui comptent le plus. Terminez par les leçons apprises, les actions avec responsables et échéances, et un tour de félicitations à l'équipe. Les sept sujets tiennent dans une seule session TeamRetro, et le vote vous aide à prioriser au lieu de repartir avec quarante observations non classées.
Suis-je obligé d'utiliser le sujet analyse des causes racines ?
Non, il est optionnel. Il prend tout son sens dans les revues d'incidents et de pannes, où comprendre pourquoi quelque chose a échoué est l'objectif même, ainsi que dans les projets qui ont manqué des cibles importantes. Pour une livraison sans heurts, vous pouvez le sauter, ou simplement prendre les deux problèmes les plus votés et demander pourquoi quelques fois avant de passer aux leçons apprises.
Combien de temps dure un post-mortem ?
Prévoyez soixante à quatre-vingt-dix minutes pour la plupart des projets et incidents. Les incidents circonscrits ou les petits projets peuvent être revus en quarante-cinq minutes si vous sautez l'analyse des causes racines. Les grands programmes nécessitent souvent deux heures ou deux sessions, une pour la vue d'ensemble factuelle et les causes, une pour les améliorations et les actions. Comme tout le monde réfléchit en parallèle dans TeamRetro, la phase de collecte reste courte.
Qui devrait participer à un post-mortem ?
Incluez les personnes qui ont fait le travail et celles qui en ont subi les effets : l'équipe de livraison, le responsable produit ou projet, et des représentants du support, du design ou des opérations qui ont hérité du résultat. Pour un incident, incluez les intervenants, les personnes d'astreinte et toute personne ayant géré la communication client. Gardez le groupe assez petit pour une conversation honnête, et briefez les participants seniors pour qu'ils écoutent plutôt que de défendre leurs décisions.

Modèles associés

Rétrospective de Lancement de Nouvelle Année

Réfléchir aux succès et défis des fêtes

Bilan des Objectifs Semestriels

Évaluer les progrès, réaligner les priorités et planifier le succès.

Planification de Lancement de Projet

Aligner l'équipe sur les objectifs et planifier l'exécution.

Rétrospective Post-Lancement

Analyser les succès, défis et améliorations après les lancements.

Êtes-vous prêt à mener cette rétrospective ?Essayez ce concert rétrospectif