Stress-tester un plan
La pré-mortem appliquée à un plan technique : on est six mois plus tard, ça a échoué, pourquoi.
« Tu vois des risques dans ce plan ? » Le modèle t'en listera cinq, génériques, polis, et aucun ne t'apprendra quoi que ce soit. La question autorise une réponse rassurante, donc elle en obtient une.
La pré-mortem inverse le cadrage. On ne demande pas ce qui pourrait mal tourner : on pose comme acquis que ça a mal tourné, et on demande pourquoi. Le passé étant un fait et non une hypothèse, il ne se nuance pas.
La technique vient de Gary Klein, qui l'a décrite dans la Harvard Business Review en septembre 2007. Elle s'appuie sur un travail de recherche de 1989 (Deborah J. Mitchell, Jay Russo et Nancy Pennington) : l'hindsight prospectif, imaginer qu'un événement a déjà eu lieu, augmente d'environ 30 % la capacité à identifier correctement les raisons d'un résultat futur.
Avant de commencer
- Un plan écrit, pas une intention
- Une échéance et un critère de réussite
- Vingt minutes, avant d'écrire la première ligne de code
1Donner le plan, en entier
Une pré-mortem sur un plan vague produit des échecs vagues. Il faut le plan réel : les étapes, l'échéance, qui fait quoi, et ce qui compte comme réussite.
Voici le plan.
Objectif : [ce qui doit etre vrai a la fin, mesurable].
Echeance : [date].
Etapes : [liste ordonnee].
Qui : [personnes, disponibilite reelle].
Ce qui existe deja : [systemes, donnees, contrats concernes].
Critere de reussite : [comment on saura que c'est reussi].
Ne commente pas encore. Dis-moi seulement ce qui manque dans cette description
pour que quelqu'un d'exterieur puisse l'evaluer.
2Poser l'échec comme un fait
Le prompt central. Trois éléments comptent : la date au passé, l'interdiction de nuancer, et le nombre imposé de causes.
On est [date de l'echeance + 6 mois]. Ce plan a echoue. Ce n'est pas une
hypothese : c'est acte, tout le monde le sait, et on fait le post-mortem.
Ecris dix causes plausibles de cet echec. Pour chacune :
- ce qui s'est passe concretement, en une phrase au passe ;
- a quel moment du plan ca a commence ;
- pourquoi personne ne l'a vu venir a l'epoque.
Contraintes : pas de conditionnel, pas de « il aurait pu ». Pas de causes
generiques du type « mauvaise communication » : nomme ce qui a ete dit ou pas
dit, par qui, a quel moment.
Dix, c'est volontaire. Les trois premières sont les évidences que tu connais déjà. Ce sont les causes six à dix qui sortent des angles morts, parce que le modèle a épuisé les réponses faciles.
Pourquoi le passé fonctionne mieux
« Ça pourrait échouer » invite à évaluer une probabilité, donc à la trouver faible. « Ça a échoué » invite à expliquer, donc à chercher des mécanismes. Ce sont deux tâches cognitives différentes, et la seconde produit des causes spécifiques là où la première produit des catégories.
3Trier par ce qu'on peut détecter tôt
La liste brute ne sert à rien. Ce qui sert, c'est ce que tu peux voir venir.
Pour chacune des dix causes, donne :
- le signal le plus precoce qui l'aurait revelee ;
- quand ce signal serait apparu, en semaines apres le debut ;
- ce qu'il en aurait coute de le surveiller.
Classe ensuite les causes en trois groupes : detectable en semaine 1,
detectable en cours de route, invisible jusqu'a l'echec.
Le troisième groupe est celui qui compte. Une cause qu'aucun signal ne révèle avant l'échec n'est pas gérable par la vigilance : elle se traite en changeant le plan, ou en acceptant explicitement le risque.
4Convertir en changements de plan
Une pré-mortem qui finit en liste de risques n'a rien produit. Elle doit finir en modifications.
Prends les trois causes les plus probables et les deux plus coûteuses.
Pour chacune, propose UNE modification concrete du plan : une etape ajoutee,
supprimee, reordonnee, ou une decision avancee.
Pour chaque modification, dis ce qu'elle coute en temps et ce qu'elle
n'empeche pas.
La dernière phrase évite le piège classique : une mesure de mitigation qui donne un sentiment de sécurité sans traiter la cause.
5Poser un point de sortie
C'est l'étape que personne ne fait, et c'est elle qui sauve les projets.
Ecris le critere d'abandon de ce plan : qu'est-ce qui, si on l'observe a
[date intermediaire], doit nous faire arreter plutot que continuer ?
Formule-le comme une condition verifiable, pas comme une impression.
Un critère d'abandon écrit avant de commencer est une décision. Le même critère discuté au moment où il se réalise est une négociation, et elle est toujours perdue par celui qui propose d'arrêter.
Les erreurs qui vident l'exercice
- Demander « quels sont les risques ». Retour à la case départ : la question autorise une réponse rassurante.
- Accepter les causes génériques. « Sous-estimation de la complexité » n'est pas une cause, c'est une étiquette. Redemande : quelle partie, sous-estimée de combien, par qui.
- S'arrêter à la liste. Sans modification du plan, tu as produit un document d'archive.
- Faire la pré-mortem trop tard. Une fois le code écrit, la liste devient une justification a posteriori.
- Ne la faire qu'une fois. Sur un projet long, refaire l'exercice à mi-parcours, avec ce qu'on sait maintenant, produit une liste différente.
Le modèle ne connaît pas ton équipe
Les causes liées aux personnes, aux disponibilités réelles, aux tensions internes et à l'historique du projet ne sortiront pas seules : le modèle ne les a pas. Elles sortent si tu les mets dans le cadre de l'étape 1. Sans ça, tu n'auras que des causes techniques, alors que ce sont rarement elles qui tuent un plan.
Quelques prompts pour aller plus loin
| Objectif | Prompt à adapter |
|---|---|
| Lancer la pré-mortem | On est [date + 6 mois]. Ce plan a echoue. Ecris dix causes plausibles, au passe, sans conditionnel, chacune avec le moment ou elle a commence. |
| Refuser le générique | Cette cause est trop generique. Reecris-la en nommant ce qui a concretement ete fait ou pas fait, par qui, a quel moment. |
| Trouver les signaux | Pour chaque cause, donne le signal le plus precoce qui l'aurait revelee et a quelle semaine il serait apparu. |
| Transformer en actions | Prends les trois causes les plus probables. Une modification concrete du plan par cause, avec son cout et ce qu'elle n'empeche pas. |
| Écrire la sortie | Ecris le critere d'abandon de ce plan sous forme de condition verifiable a [date intermediaire]. |
| Chercher l'angle mort | Quelle categorie de cause n'apparait dans aucune de tes dix reponses ? Pourquoi ? |
Tu as d’autres ressources comme ça ?
Ce que tu viens de lire est entièrement gratuit. Une nouvelle ressource part chaque semaine dans la newsletter : guides, modèles à copier et liens triés, sans compte à créer.
Me contacter
Une question, un projet, une envie de collaborer ? Écris-moi.
Cette page est en accès libre, n’hésite pas à la partager.