Modèle de post-mortem de projet Template (Free)

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

Qu'est-ce que le projet devait accomplir, et pour quand ?

L'objectif était de migrer toute la facturation client vers la nouvelle plateforme d'ici la fin du T3, sans aucune interruption pour les comptes grands clients.

Nous avons livré le portail client trois semaines après la date initiale, avec deux des cinq fonctionnalités prévues supprimées.

Les critères de réussite n'ont jamais été écrits nulle part, du moins pas à ma connaissance, donc j'avais ma propre version en tête.

Ce qui a bien fonctionné

Quels succès et quelles pratiques valent la peine d'être reproduits ?

Les points quotidiens de quinze minutes pendant la période de rush ont gardé tout le monde aligné sans alourdir l'agenda.

Notre runbook d'astreinte était à jour, ce qui a permis d'appliquer le correctif en quelques minutes plutôt qu'en plusieurs heures.

Associer tôt les nouveaux développeurs à des relecteurs les a rendus productifs plus vite que je ne l'imaginais.

Ce qui n'a pas bien fonctionné

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

Les exigences changeaient sans cesse et personne n'était clairement chargé de décider quand elles étaient figées.

Les tests ont été comprimés dans les derniers jours, et c'est pour ça que deux anomalies sont arrivées jusqu'aux clients.

Notre supervision ne couvrait pas la profondeur de la file d'attente, donc nous étions aveugles jusqu'à ce que tout soit déjà engorgé.

Analyse des causes racines

Pourquoi cela a-t-il mal tourné, au-delà du simple constat ?

La cause racine était un changement de configuration déployé directement en production, parce que notre pipeline n'avait aucune étape de revue obligatoire.

Nous avons sous-estimé parce que l'estimation a été faite avant le spike technique, puis traitée comme un engagement.

Personne n'était responsable de l'intégration entre les deux équipes, donc le trou est resté invisible jusqu'à la semaine d'intégration.

Leçons apprises

Quelles leçons emportons-nous pour la suite ?

Faire le spike technique avant de nous engager sur des dates, puis réestimer de manière transparente.

Écrire les critères de réussite dès le lancement. Si nous n'arrivons pas à nous mettre d'accord dessus, c'est que nous ne sommes pas prêts à démarrer.

Les changements de périmètre doivent passer par un point de validation écrit au lieu d'être absorbés en silence par l'équipe.

Actions, responsables et échéances

Qui fait quoi, et pour quand ?

Ajouter une étape de revue obligatoire au pipeline de déploiement en production. Responsable : Priya. Échéance : fin du prochain sprint.

Rédiger un modèle de charte projet d'une page incluant les critères de réussite. Responsable : Sam. Échéance : le 15.

Ajouter des alertes sur la profondeur de file et le taux d'erreur, envoyées à l'équipe d'astreinte. Responsable : Dev. Échéance : cette semaine.

Reconnaissance et remerciements

Qui mérite d'être remercié 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 quasiment sans préavis.

Un grand merci à Sam, qui a discrètement écrit le runbook que personne n'avait demandé, et qui nous a ensuite sauvés grâce à lui.

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

Un post-mortem, c'est la discussion que votre équipe a une fois que quelque chose est terminé. Parfois, ce quelque chose est un incident : un système est tombé, une mise en production a dérapé, un client en a subi les conséquences. Tout aussi souvent, il s'agit d'un projet ordinaire qui vient de se terminer, et vous voulez un ordre du jour clair pour le bilan plutôt que d'en inventer un de toutes pièces. Ce modèle 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 fonctionné et ce qui a coincé, 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éutiliser. Voici comment cela fonctionne dans TeamRetro. Chacun commence par ajouter ses propres observations en privé, pour que la voix la plus forte de la salle n'impose pas son récit avant que les plus discrets aient eu le temps d'écrire quoi que ce soit. Les idées sont ensuite regroupées, discutées et soumises au vote, ce qui vous permet de vous concentrer sur les quelques thèmes qui comptent vraiment au lieu de parcourir quarante commentaires sans ordre précis. C'est ce qui distingue cette approche d'un document que l'on remplit seul : il s'agit d'un débriefing en direct que toute l'équipe mène ensemble, et qui se conclut par de vraies actions avec des responsables et des échéances, pas par un rapport que personne ne rouvrira. Utilisez-le comme bilan de projet par défaut à la fin 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 qu'il vous faut un récit sans recherche de coupable de la chronologie et de ses causes. Le dernier sujet laisse de la place aux remerciements, car reconnaître les personnes qui ont porté le travail fait partie d'une clôture réussie. Dans tous les cas, l'équipe doit repartir en sachant quoi reproduire, quoi arrêter et qui fait quoi ensuite. Exportez le rapport à la fin, pour que les leçons restent faciles à retrouver pour la prochaine équipe confrontée à la même situation.

Format de rétrospective post-mortem

Vue d'ensemble, objectifs et périmètre Qu'est-ce que le projet devait accomplir, et pour quand ?: Ce sujet pose le cadre avant que quiconque ne porte de jugement. Demandez l'objectif initial, le périmètre convenu, le calendrier et les critères de réussite, ainsi que ce qui a réellement été livré par rapport à ces éléments. Pour une revue d'incident, utilisez-le plutôt pour la chronologie : ce qui a cassé, quand cela a été détecté, qui était impliqué et comment cela a été résolu. Gardez les interprétations hors de cette colonne et réservez les opinions aux sujets suivants. Si les participants ne s'accordent même pas sur les objectifs ou les critères de réussite, ce désaccord est en soi un constat à consigner.
Ce qui a bien fonctionné Quels succès et quelles pratiques valent la peine d'être reproduits ?: Les équipes ont tendance à expédier ce sujet, surtout après un projet difficile ou un incident stressant, alors protégez le temps qui lui est consacré. Vous cherchez des pratiques à reproduire, pas des compliments ; les remerciements ont leur propre sujet plus loin. Quand quelqu'un publie un éloge, demandez ce qui a précisément fait que ça a marché, pour que la réponse puisse être réutilisée. Repérez les succès qui reposent sur des exploits individuels et signalez-les comme des risques.
Ce qui n'a pas bien fonctionné Où avons-nous bloqué, cassé ou manqué nos objectifs ?: C'est ici que se trouve l'essentiel des apprentissages, alors énoncez clairement la règle de non-culpabilisation avant de commencer : vous examinez des systèmes et des décisions, pas des personnes. Demandez des faits précis plutôt que des plaintes vagues. « La communication était mauvaise » ne mène à aucune action, alors que « nous avons appris le changement d'échéance au détour d'une conversation dans un couloir » le permet. Utilisez le vote pour que la discussion ne s'éparpille pas sur chaque agacement des trois derniers mois.
Analyse des causes racines Pourquoi cela a-t-il mal tourné, au-delà du simple constat ?: Facultatif pour un bilan de projet sans accroc, indispensable pour un incident. Reprenez les problèmes les plus votés du sujet précédent et continuez à demander pourquoi jusqu'à atteindre une condition, pas une personne : un garde-fou manquant, un responsable mal identifié, une pression sur le calendrier, une hypothèse que personne n'a vérifiée. La méthode des 5 pourquoi fonctionne bien ici, tout comme le fait de se demander ce qui rendait la mauvaise action raisonnable sur le moment. Arrêtez-vous quand vous arrivez à quelque chose que vous pouvez réellement changer, et notez les facteurs contributifs séparément de l'élément déclencheur.
Leçons apprises Quelles leçons emportons-nous pour la suite ?: C'est le « et alors ? » qui transforme les observations en connaissances réutilisables. Poussez chaque idée jusqu'à ce qu'elle désigne un comportement, un déclencheur ou un garde-fou qui aura encore du sens sur le prochain projet. Distinguez ce que l'équipe peut changer elle-même de ce qui doit remonter à un manager ou à un autre groupe, et soyez honnête sur cette seconde liste. Rédigez chaque leçon de façon à ce qu'une personne extérieure puisse la lire dans le rapport exporté et la comprendre sans que vous soyez là pour l'expliquer.
Actions, responsables et échéances Qui fait quoi, et pour quand ?: Un post-mortem sans actions attribuées ne compte pas, alors réservez-y un vrai temps au lieu de le caser dans les deux dernières minutes. Transformez 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ées dans TeamRetro, pour qu'elles ressortent lors de votre prochaine session. Deux ou trois actions bien portées valent mieux que dix vœux pieux. Si une action relève de quelqu'un qui n'est pas dans la salle, convenez de qui la lui transmettra et pour quand.
Reconnaissance et remerciements Qui mérite d'être remercié avant de clôturer ?: Terminez sur les personnes, pas sur les problèmes. Demandez à chacun de citer une personne précise et une chose précise qu'elle a faite ; cela a bien plus de valeur que des remerciements généraux et fonctionne même après un projet difficile. C'est d'autant plus important que le bilan a été éprouvant, car cela rappelle à l'équipe qu'examiner un échec ne revient pas à se rejeter la faute. Restez bref, lisez-en quelques-uns à voix haute et laissez le rapport exporté conserver 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 un bilan structuré, pas une discussion informelle qui tombe dans l'oubli
Un incident, une panne ou une mise en production ratée nécessite un post-mortem sans recherche de coupable, couvrant la chronologie, les causes racines et les actions préventives
Un programme de longue durée vient de terminer une phase et vous voulez consigner les leçons apprises tant que les détails sont encore frais
Un groupe transverse est sur le point d'être dissous, et c'est votre dernière occasion de faire le bilan et de saluer les contributeurs avant que chacun passe à autre chose
Quelque chose s'est étonnamment bien passé et vous voulez comprendre pourquoi, pour pouvoir le reproduire au lieu de l'attribuer à la chance

Exemples de questions pour brise-glace

En un mot, comment avez-vous vécu ce projet ou cet incident pendant que vous étiez en plein dedans ?
Si vous pouviez vous envoyer une seule phrase de conseil le 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

Organisez-le dans la semaine ou les deux semaines qui suivent la clôture du projet ou la résolution de l'incident. Les souvenirs s'effacent vite, et les détails utiles avec eux
Énoncez la règle de non-culpabilisation dès le début. Vous examinez des décisions, des systèmes et des contraintes, vous ne cherchez pas un responsable à accuser
Prenez quelques minutes pour vous accorder sur la vue d'ensemble du projet avant que les opinions n'arrivent. Un cadre commun évite que la session tourne au débat sur ce qu'était vraiment l'objectif
Sautez ou raccourcissez l'analyse des causes racines pour un bilan de projet sans accroc, et consacrez-y plus de temps 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 ni échéances sur les actions principales, sinon vos leçons apprises resteront théoriques
Apportez les actions du post-mortem précédent et passez-les en revue en premier. Rien n'améliore autant le suivi que de savoir qu'il sera vérifié

Foire aux questions

Qu'est-ce qu'un post-mortem de projet ?

C'est un bilan structuré que votre équipe mène une fois un travail terminé, comme le lancement d'un produit, une migration, une campagne ou une livraison client. Vous examinez les objectifs et le périmètre initiaux, ce qui a bien fonctionné, ce qui n'a pas marché et les leçons à retenir pour la suite. Contrairement à un post-mortem d'incident, rien n'a besoin d'avoir mal tourné : le travail est simplement terminé et il y a des connaissances à conserver.

Quelle est la différence entre un post-mortem de projet et un post-mortem d'incident ?

Un post-mortem d'incident est déclenché par une défaillance : il s'appuie donc sur la chronologie, la détection, la réponse et la cause racine, avec la prévention pour objectif. Un post-mortem de projet est déclenché par la fin du travail et porte sur les objectifs, les estimations, le périmètre, la collaboration et la passation, avec un meilleur projet suivant pour objectif. Les deux doivent se faire sans recherche de coupable et se conclure par des actions avec des responsables.

Que doit contenir un post-mortem de projet ?

Commencez par la vue d'ensemble du projet : objectifs, périmètre, calendrier, critères de réussite et ce qui a réellement été livré. Abordez ensuite ce qui a bien fonctionné, ce qui n'a pas marché et les causes racines des principaux problèmes. Terminez par les leçons apprises, les actions avec responsables et échéances, et un tour de remerciements ; les sept sujets tiennent dans une seule session TeamRetro.

Dois-je obligatoirement utiliser le sujet d'analyse des causes racines ?

Non, il est facultatif. Il trouve toute sa place dans les revues d'incident et dans les projets qui ont manqué des objectifs importants. Pour une livraison sans accroc, sautez-le ou prenez les deux problèmes les plus votés et demandez pourquoi plusieurs fois avant de passer aux leçons apprises.

Combien de temps dure un post-mortem ?

Prévoyez 60 à 90 minutes pour la plupart des projets et incidents, ou environ 45 minutes pour un petit projet si vous sautez l'analyse des causes racines. Les grands programmes nécessitent souvent deux sessions, l'une pour les faits et les causes, l'autre pour les améliorations et les actions.

Qui doit participer à un post-mortem ?

Les personnes qui ont fait le travail et celles qui en ont subi les effets : l'équipe de réalisation, le chef de projet et ceux qui ont hérité du résultat au support, au design ou aux opérations. Pour un incident, ajoutez les intervenants et toute personne ayant géré la communication client. Gardez un groupe assez restreint pour permettre une discussion honnête, et demandez aux participants les plus haut placés d'écouter plutôt que de défendre leurs décisions.