Template de post-mortem startup
Un post-mortem n'a qu'un seul objectif : transformer un échec (ou un incident, ou un lancement raté) en apprentissage que l'entreprise n'oubliera pas. La plupart des post-mortems échouent sur la deuxième partie : le document est écrit, classé, et plus jamais relu.
Ce template est volontairement court. Un post-mortem d'une page que l'équipe remplit vraiment vaut mieux qu'un rituel de dix sections abandonné au deuxième incident.
Le template
Copiez le bloc ci-dessous dans votre outil (la version duplicable Notion / Google Docs est disponible en bas de page).
En-tête
| Champ | Contenu |
|---|---|
| Titre | Un nom clair : « Lancement de X », « Incident du 12 mars »… |
| Date de l'événement | Quand c'est arrivé |
| Date du post-mortem | Idéalement moins d'une semaine après |
| Participants | Qui était impliqué, qui rédige |
| Gravité | Mineur · Significatif · Critique |
1. Ce qui devait se passer
Deux ou trois phrases : le plan initial, l'attente, l'hypothèse de départ. Sans cette ligne de base, impossible de mesurer l'écart.
2. Ce qui s'est réellement passé
Les faits, dans l'ordre, avec les dates. Pas d'interprétation à ce stade : une chronologie. C'est la partie qu'on regrette de ne pas avoir quand on relit six mois plus tard.
3. Pourquoi (les causes, pas les coupables)
La règle d'or : sans blâme. On cherche les causes structurelles, pas les fautifs. Technique simple : demander « pourquoi ? » plusieurs fois jusqu'à toucher une cause sur laquelle on peut agir.
4. Ce qu'on savait et qu'on a ignoré
La question la plus inconfortable et la plus rentable du template. Dans presque tous les échecs, des signaux existaient avant : un retour client, un doute exprimé, un chiffre étrange. Les lister noir sur blanc apprend à l'équipe à les écouter la prochaine fois.
5. Les apprentissages
Deux ou trois maximum, formulés comme des règles réutilisables : pas « le lancement a raté », mais « ne plus lancer sans avoir testé le parcours d'inscription sur mobile ». Un apprentissage qui ne change aucun comportement futur n'en est pas un.
6. Les actions
| Action | Responsable | Échéance |
|---|---|---|
| ... | ... | ... |
Trois actions maximum. Au-delà, rien ne sera fait.
La partie que tout le monde rate : la relecture
Le post-mortem rempli, il reste le vrai problème : faire revivre ces apprentissages au moment utile. Un doc rangé dans un dossier « Post-mortems » ne préviendra personne, six mois plus tard, que l'équipe est en train de refaire exactement la même erreur.
Deux pratiques qui changent tout :
- Relire les apprentissages des post-mortems passés avant chaque décision du même type (avant un lancement, relire les post-mortems de lancements).
- Garder les apprentissages dans une mémoire commune, pas dans des documents séparés — c'est précisément le travail d'une mémoire d'entreprise comme Verbasil : l'apprentissage y est relié à la décision d'origine et à ses preuves, et re-surgit quand le sujet revient.
FAQ
Quand faut-il faire un post-mortem ?
Dans la semaine qui suit l'événement, pendant que les faits et les ressentis sont frais. Au-delà, la chronologie se reconstruit de mémoire et perd sa fiabilité. Un post-mortem se justifie pour tout échec ou incident dont l'entreprise veut tirer une leçon durable, pas seulement pour les crises majeures.
Un post-mortem doit-il désigner des responsables ?
Non. La règle « sans blâme » n'est pas de la bienveillance décorative : si les participants craignent d'être pointés du doigt, ils cachent les informations dont l'analyse a besoin. On cherche les causes structurelles (process, signaux ignorés, hypothèses fausses), qui sont les seules sur lesquelles on peut agir.
Comment faire vivre les apprentissages d'un post-mortem ?
En les sortant du document. Formulez chaque apprentissage comme une règle actionnable, ajoutez-le à la mémoire commune de l'équipe, et relisez les apprentissages pertinents avant chaque décision du même type. Le post-mortem qui dort dans un dossier n'a servi qu'à la catharsis du moment.