- Description
- Un grand voilier à quatre mâts échoué au large d'une plage, avec quelques promeneurs sur le sable.
- Source
- Fred Kruger · page d’origine
- Licence
- PD Domaine public
Le pré-mortem
Plutôt que de demander « qu'est-ce qui pourrait mal tourner ? », on annonce que cela a mal tourné et l'on cherche les causes. La question change, et les réponses aussi.
En bref
- Quoi : une réunion d'environ une heure, avant le lancement, où l'équipe suppose que le projet a échoué et écrit, chacun pour soi, les raisons de l'échec.
- Pourquoi ça marche : présenter l'échec comme acquis (et non comme une éventualité) fait produire davantage de causes concrètes, et il devient permis, voire attendu, d'exprimer ses doutes.
- Livrable : une liste de risques classée, des actions préventives, des signaux d'alerte à surveiller et, parfois, un plan modifié.
- À retenir : c'est une méthode de plan, pas de pilotage ; elle réduit l'excès de confiance, elle ne le supprime pas.
Définition#
Illustration fictive
Illustration inspirée de la personneLe pré-mortem (premortem) est une technique de revue de projet proposée par le psychologue Gary Klein. Elle est présentée au grand public dans l'article « Performing a Project Premortem », publié dans la Harvard Business Review de septembre 2007. Son nom est un jeu de mots avec l'autopsie (post-mortem) : on ne cherche pas pourquoi un projet est mort, on le fait avant qu'il naisse.
La consigne est simple. L'équipe a un plan, il est jugé prêt. Le facilitateur dit : « Nous sommes dans un an. Le projet a échoué, et de façon totale et humiliante. Écrivez les raisons de cet échec. » Chacun rédige en silence, puis les causes sont partagées et traitées.
Le fondement scientifique que Klein invoque est une étude de Deborah Mitchell, Jay Russo et Nancy Pennington (1989) sur la prospective hindsight, la « rétrospection prospective » : se placer mentalement dans l'avenir en considérant qu'un événement s'est déjà produit.
Le principe : pourquoi ça marche#
Un projet qui vient d'être décidé est entouré de trois forces qui étouffent le doute :
- L'optimisme : on planifie comme si tout devait bien se passer (voir l'optimisme irréaliste et l'erreur de planification).
- La pression du groupe : une fois la décision prise, exprimer un doute passe pour de la défaite ou de la déloyauté (voir la pensée de groupe et le biais d'autorité).
- L'engagement : plus on a investi, plus on défend le plan (voir les coûts irrécupérables).
Le pré-mortem retourne ces trois forces. En posant l'échec comme un fait, il change la tâche mentale : il ne s'agit plus de défendre le plan ni de deviner si un risque est « probable », mais d'expliquer un événement, ce que le cerveau fait bien et avec plus de détails concrets. Et parce que l'exercice est demandé par le chef de projet, signaler une faiblesse devient une contribution et non plus une critique.
Mitchell, Russo et Pennington (Journal of Behavioral Decision Making, 1989) ont comparé des participants à qui l'on demandait d'expliquer un résultat comme déjà survenu et d'autres à qui on le présentait comme possible. Les premiers ont produit environ 30 % de raisons en plus, et des raisons plus spécifiques. Précision importante : le gain porte sur la quantité et la précision des raisons avancées, pas sur leur justesse. L'étude n'a pas mesuré la qualité des causes, ni l'effet sur la réussite d'un projet réel.
Daniel Kahneman a repris l'idée dans Thinking, Fast and Slow (2011) : il y voit un moyen de contenir l'excès de confiance et la pensée de groupe, sans prétendre qu'il les supprime.
Comment faire : la procédure pas à pas#
Durée : de 45 à 90 minutes selon la taille du projet. Participants : l'équipe du projet, plus deux ou trois personnes qui ne l'ont pas conçu (exploitation, support, un client interne, quelqu'un d'un autre service). Moment : quand le plan est assez précis pour être critiqué, mais avant les engagements irréversibles (contrat signé, équipe constituée, jalons promis).
- Préparer. Un participant résume le plan en dix minutes : objectif, périmètre, planning, budget, hypothèses. Le facilitateur ne doit pas être le sponsor, ni celui qui a rédigé le plan.
- Poser la consigne. « Nous sommes à la date de fin prévue (ou un an après). Le projet a échoué, de façon claire. Vous le savez. » Il faut dire « a échoué », pas « pourrait échouer ». Insister sur le fait qu'il n'y a pas à débattre de la probabilité.
- Écrire seul, en silence. Chacun note, pendant 5 à 10 minutes, toutes les raisons qui lui viennent, y compris les plus improbables ou les plus gênantes (le sponsor, le client, la technologie, le planning, soi-même). Le silence évite que le premier qui parle ne cadre les autres (voir le biais d'autorité).
- Partager en tour de table. Chacun donne une raison à la fois, jusqu'à épuisement des listes ; le facilitateur note sans commenter ni défendre. On cherche la diversité, pas le consensus. On ne discute pas encore.
- Regrouper et noter. Les causes sont regroupées par thème, puis chacun vote, par exemple avec trois gommettes, pour celles qu'il juge les plus graves et les plus plausibles.
- Traiter les premières. Pour les cinq à dix causes retenues : quelle action prévient la cause ? quel signal permettrait de la repérer tôt ? qui s'en charge, pour quand ? Certaines modifient le plan (jalon ajouté, essai préalable, critère d'arrêt), d'autres relèvent d'une surveillance.
- Conserver et rouvrir. La liste est archivée avec le plan. On la relit à chaque revue de jalon : une cause qui se réalise sans avoir été surveillée est un défaut de suivi, pas une surprise.
Livrables : la liste des causes classées, les actions avec un responsable et une date, les signaux d'alerte, la décision éventuelle de modifier le plan ou de ne pas le lancer.
Exemples#
La rétrospection prospective, en laboratoire 1989#
Mécanisme en jeu : explication d'un événement tenu pour acquis.
Ce qui s'est passé. Dans le travail de Mitchell, Russo et Pennington, des participants devaient expliquer le résultat d'un événement (par exemple, l'issue d'une situation décrite par l'expérimentateur). Selon les conditions, le résultat était présenté comme possible ou comme déjà arrivé. La seconde condition a donné des explications plus nombreuses et plus spécifiques : environ 30 % de raisons en plus.
Gary Klein s'en sert comme du principal appui expérimental de la méthode, dans son article de 2007. Il décrit ensuite l'exercice tel qu'il l'a pratiqué en entreprise : une consigne unique, un temps d'écriture, un tour de table, et un point final où le chef de projet revoit son plan.
Ce que cela illustre
L'appui expérimental est indirect : l'étude de 1989 porte sur la production d'explications, pas sur la réussite de projets. À ce jour, les preuves directes d'un meilleur taux de réussite des projets grâce au pré-mortem restent rares. La méthode se recommande surtout par son coût très faible (une heure) et par la plausibilité de son mécanisme, et il faut la présenter ainsi.
Remplacer le système de facturation : un pré-mortem type Exemple illustratif#
Biais en jeu : optimisme irréaliste, pensée de groupe. Scénario inventé pour illustrer, pas un cas réel.
Situation. Une équipe de huit personnes prépare le remplacement d'un système de facturation vieux de quinze ans. Le plan prévoit douze mois, avec une bascule unique un week-end de fin d'année. Le sponsor est enthousiaste, l'équipe aussi.
Le pré-mortem. « Nous sommes en janvier de l'an prochain, la bascule a échoué. » Les causes écrites en silence sont, par exemple : les règles de gestion non documentées du vieux système n'ont pas été retrouvées ; les données historiques ne se chargent pas dans le nouveau schéma ; le seul développeur qui connaît l'ancien système a quitté l'entreprise ; la recette n'a été faite que sur des jeux de données propres ; la bascule dépend de trois prestataires disponibles le même week-end ; le service comptabilité n'a pas été formé.
Actions décidées. Une phase d'extraction des règles à partir des factures réelles ; une répétition générale de la bascule trois mois avant ; un transfert de connaissance planifié avec le développeur clé ; un critère d'arrêt écrit (« si la répétition échoue deux fois, la bascule est repoussée »).
Ce que cela illustre
Aucune des causes n'était inconnue de quelqu'un dans la salle. Ce qui manquait, c'était l'occasion de les dire sans passer pour un opposant. Le pré-mortem fournit cette occasion, et laisse une trace : une cause qui se réalise plus tard était écrite, donc surveillable.
Quand l'utiliser, quand l'éviter#
À utiliser#
- Avant le lancement d'un projet, d'une migration, d'une refonte, d'une mise en production majeure.
- Avant un engagement ferme : contrat, budget, date promise à un client.
- Quand le plan semble « évident » ou fait l'unanimité : c'est souvent le signe que personne n'ose dire ses doutes.
- Pour une décision difficile à défaire (choix d'architecture, de prestataire).
À éviter ou à adapter#
- Trop tôt : sans plan précis, les causes restent vagues (« manque de moyens »). Mieux vaut attendre une première version.
- Trop tard : quand tout est déjà engagé et que rien ne peut changer, l'exercice devient une plainte.
- Si le chef ou le sponsor ne joue pas le jeu : s'il réagit à chaque cause par une justification, les participants se taisent. Le chef doit écouter et noter.
- Pour une tâche courante et réversible : la méthode est disproportionnée.
- Si l'on cherche à estimer un chiffre (durée, budget) : préférer l'estimation par classe de référence ; le pré-mortem trouve des causes, il ne donne pas de chiffre.
Limites et critiques#
- Peu de preuves directes. Le gain en quantité de raisons est établi en laboratoire ; l'effet sur la réussite des projets réels est surtout rapporté par des praticiens, sans essai comparatif solide.
- Effet de liste. On produit beaucoup de causes, mais rien n'oblige à agir. Sans responsable ni date, la liste finit dans un tiroir.
- Imagination limitée à l'expérience du groupe. Les causes qu'aucun participant ne connaît ne sortiront pas : d'où l'intérêt d'inviter des personnes extérieures au projet.
- Découragement. Un pré-mortem mal mené peut abattre l'équipe ou donner prétexte à l'inaction. Il faut finir sur des actions, pas sur la peur.
- Cause « à la mode ». Les raisons citées reflètent aussi les échecs récents que chacun a en tête (voir le biais de disponibilité).
- Ne remplace pas l'avis extérieur. Il complète l'avocat du diable et la vue extérieure, il ne les remplace pas.
Avec l'IA#
L'IA connaît des milliers de scénarios d'échec de projets et ne craint pas de déplaire au sponsor. Elle élargit la liste. Mais elle ne connaît ni votre organisation ni vos personnes, et ses listes sont génériques : elle complète l'exercice d'équipe, elle ne le remplace pas.
Détecter#
- Relire un plan et signaler les hypothèses non vérifiées et les dépendances sans responsable.
- Repérer, dans les comptes rendus d'un projet en cours, les signaux d'alerte prévus lors du pré-mortem.
Remédier#
- Proposer des causes d'échec supplémentaires après le tour de table, pour combler les angles morts.
- Regrouper les causes, proposer des actions préventives et des indicateurs.
Atténuer#
- Faire écrire d'abord les causes par les humains, puis seulement comparer avec la liste de l'IA.
- Faire rédiger une synthèse neutre de la réunion, avec les responsables et les dates.
Prompts à utiliser#
1. Compléter la liste des causes d'échec. À lancer APRÈS le tour de table, pas avant : sinon l'IA oriente les participants.
Voici le plan d'un projet : [objectif, périmètre, planning, budget, équipe, dépendances, hypothèses].
Nous sommes à la date de fin prévue, et le projet a échoué de manière claire.
Voici déjà la liste des causes trouvées par l'équipe : [liste].
1. Propose les causes d'échec que l'équipe n'a PAS citées, en les classant : technique, organisation, client ou sponsor, données, prestataires, calendrier, personnes.
2. Pour chaque cause, indique quel élément du plan la rend plausible, en le citant.
3. Signale les hypothèses du plan qui n'ont aucune vérification prévue.
N'invente aucun fait sur l'entreprise : si une information manque, pose la question.2. Transformer les causes en plan d'action. Pour la fin de la réunion, à partir des causes votées.
Voici les causes d'échec retenues par l'équipe, par ordre de priorité : [liste].
Pour chacune, propose : une action préventive concrète, un signal d'alerte observable tôt, la personne ou le rôle qui doit en répondre, et un critère qui dirait « il faut s'arrêter ou corriger ».
Termine par un tableau (cause, action, signal, responsable, échéance à fixer) et signale les causes qui n'ont pas d'action réaliste.Précautions#
- Ne soumettez jamais le plan avant l'écriture individuelle : vous ancreriez l'équipe sur les causes de l'outil.
- Les listes générées sont plausibles par construction : elles ne prouvent pas que les risques existent chez vous. Triez avec ceux qui connaissent le terrain.
- Ne collez pas de plan confidentiel, de données de clients ou de personnes dans un outil non autorisé.
Sources et vérification#
- Klein, G. (2007), « Performing a Project Premortem », Harvard Business Review, septembre 2007 — la méthode.
- Mitchell, D. J., Russo, J. E. & Pennington, N. (1989), « Back to the future: Temporal perspective in the explanation of events », Journal of Behavioral Decision Making, 2(1), 25-38 — la rétrospection prospective.
- Kahneman, D. (2011), Thinking, Fast and Slow, Farrar, Straus and Giroux — le pré-mortem présenté comme parade à l'excès de confiance (chapitre « The Engine of Capitalism »).
- Klein, G. (2003), The Power of Intuition, Currency/Doubleday — présentation de l'approche de Klein.
