Réaliser un pré-mortem de projet

Auteur: AILesson7 min de préparationTesté avec:ChatGPTRévisé: 2026-08-28

Réponse rapide

Imaginer l'échec du projet pour faire ressortir les causes plausibles, les signaux faibles, les tests et les actions préventives. Fournir: Projet et date de constat de l'échec, Éléments probants et hypothèses, Participants et pouvoir d'action. Résultat attendu: Une cartographie hiérarchisée des scénarios d'échec, avec éléments probants, indicateurs, responsables et expérimentations immédiates.

1

Ajouter votre contexte

Votre texte reste dans ce navigateur. AILesson Prompts ne l’envoie ni à un modèle ni à un serveur.

2

Votre prompt

Les champs non remplis restent visibles sous forme d’espaces réservés, afin que vous puissiez quand même copier et modifier le prompt.

Réalisez un pré-mortem du projet à partir du contexte fourni.

Projet, utilisateurs, plan, objectif et définition concrète de l'échec :
[project]

Contraintes, dépendances, incidents, estimations, désaccords et inconnues :
[assumptions]

Points de vue des participants, pouvoirs, moyens de réduction des risques et calendrier de réexamen :
[participants]

Supposez que le projet a échoué à la date future indiquée, puis formulez des explications distinctes et plausibles concernant la valeur pour les utilisateurs, le périmètre, la livraison, la qualité, les opérations, les personnes, les fournisseurs, la gouvernance, la sécurité, l'accessibilité, les données et le contexte externe, uniquement lorsque ces dimensions sont pertinentes. Distinguez les préoccupations étayées par des faits des hypothèses. Évitez les catastrophes génériques, les reproches et les certitudes rétrospectives. Regroupez les causes en chaînes causales, repérez les premiers indicateurs observables et classez les scénarios selon leur plausibilité et leurs dommages en explicitant le raisonnement, sans inventer de précision. Pour les principaux scénarios, indiquez un test peu coûteux, une mesure de prévention, un déclencheur du plan de secours, une réponse, un responsable explicite ou « Non attribué », ainsi qu'une échéance de décision. Incluez des scénarios à contre-courant et les atouts qui réduisent le risque.
Essayer dans le Playground
Privé par défautL’assemblage du prompt se fait localement dans votre navigateur. Évitez de placer des informations confidentielles dans un service d’IA, sauf si votre organisation l’autorise.

De l'entrée au résultat

Un exemple détaillé

Voyez comment un contexte concret transforme cette recette en résultat utilisable.

Entrée réelle

Projet et date de constat de l'échec
En mars, une association caritative régionale lance un portail en ligne de planification des permanences pour 600 bénévoles et 40 coordinateurs. Au 30 juin, le projet est considéré comme un échec si les coordinateurs tiennent toujours des feuilles de calcul en parallèle, si plus de 10 % des permanences planifiées sont contestées ou si moins de 50 % des bénévoles actifs utilisent le portail chaque mois. Un projet pilote commence avec deux équipes en février.
Éléments probants et hypothèses
De nombreux bénévoles utilisent leur téléphone ; 18 % des dossiers actuels ne comportent pas d'adresse électronique unique. Les coordinateurs nomment les permanences différemment. Le fournisseur affirme que l'importation CSV est prise en charge, mais n'a pas testé notre fichier. Le budget de formation couvre deux séances en direct. Un coordinateur craint que les bénévoles ne voient pas les avis d'annulation. L'authentification utilise des liens envoyés par courriel. Aucun test d'accessibilité, aucun roulement d'assistance et aucune règle d'abandon des feuilles de calcul n'existent encore.
Participants et pouvoir d'action
L'atelier réunit un coordinateur des bénévoles, un représentant des bénévoles, le responsable des opérations habilité à autoriser le lancement, la responsable des données, la responsable de la communication et un spécialiste du fournisseur. Il reste deux semaines-personnes pour réduire les risques. Les décisions seront réexaminées mardi prochain.

Exemple de sortie

Scénario d'échec A — identités fragmentées et importation défaillante : les 18 % de dossiers sans adresse électronique unique, ajoutés à une importation CSV non testée, créent des comptes manquants ou en double ; les bénévoles ne peuvent pas s'authentifier ; les coordinateurs conservent leurs feuilles de calcul ; les contestations augmentent. Scénario étayé par des faits. Premiers indicateurs : taux d'exceptions à l'importation, comptes en double, échecs de connexion. Test peu coûteux : importer un fichier représentatif désidentifié et tenter de se connecter par téléphone avec des dossiers dont l'adresse électronique manque ou est dupliquée. Prévention : définir le traitement des identités et rapprocher les effectifs avant le projet pilote. Responsable : responsable des données pour le test ; responsable de la politique d'identité non attribué. Décision d'ici mardi prochain.

B — définitions incohérentes des permanences : des noms différents sont mal associés, ce qui crée des plannings contestés et des dossiers parallèles. Scénario étayé par des faits. Tester une nomenclature commune avec les deux équipes pilotes et rapprocher chaque permanence importée. C — échec opérationnel des annulations : les utilisateurs de liens envoyés par courriel risquent de manquer les avis ; il n'existe ni roulement d'assistance ni règle d'accusé de réception. La préoccupation est explicite, mais le mécanisme menant à l'échec reste en partie hypothétique. Tester la réception et l'ouverture ainsi que cinq parcours de tâche avec des bénévoles ; définir une solution de secours urgente et son responsable. D — l'adoption semble satisfaisante alors que les coordinateurs conservent des feuilles parallèles ; échec de gouvernance à contre-courant. Indicateur : les modifications continuent après la transition. Définir avant le lancement un critère d'abandon et un registre des exceptions.

Autres hypothèses : l'accessibilité sur mobile empêche de mener les tâches à bien ; deux séances ne couvrent pas les personnes travaillant en horaires décalés ; les défauts du fournisseur dépassent les deux semaines-personnes disponibles. Atouts : projet pilote progressif avec deux équipes, pouvoir de lancement clairement attribué, point de vue des bénévoles et seuils d'échec mesurables. Donner la priorité à A et B avant le projet pilote, car ils reposent sur la même base de données, mais exigent des contrôles d'acceptation distincts.

Pourquoi cela fonctionne

  1. 1

    Le recul prospectif aide les équipes à nommer les causes d'échec que les plans optimistes tendent à passer sous silence.

  2. 2

    Les indicateurs et les tests peu coûteux transforment un échec imaginé en éléments probants susceptibles de modifier le plan.

Vérifier le résultat

  • Les scénarios sont-ils propres à ce projet et reliés aux éléments fournis, ou clairement signalés comme des hypothèses ?

  • Les principaux scénarios comportent-ils des indicateurs précoces, des tests peu coûteux, des déclencheurs et des réponses concrètes ?

  • Le résultat évite-t-il les reproches, les probabilités infondées et la répétition d'une même chaîne causale sous des formulations différentes ?

Utilisez-la en toute confiance

Questions fréquentes

Des réponses pratiques sur le bon moment pour utiliser cette recette, ce qu’il faut fournir et les cas où une vérification humaine reste nécessaire.

Que dois-je préparer avant d'utiliser « Réaliser un pré-mortem de projet » ?

Pour utiliser « Réaliser un pré-mortem de projet », préparez le projet et la date de constat de l'échec, les éléments probants et les hypothèses, ainsi que les participants et leur pouvoir d'action. Ne remplacez les espaces réservés que par des informations que vous pouvez vérifier. Si un élément est inconnu, indiquez-le explicitement au lieu de demander au modèle de le déduire.

Dans quels cas le résultat de « Réaliser un pré-mortem de projet » n'est-il pas prêt à l'emploi ?

Le résultat n'est pas prêt s'il ne permet pas encore, à partir des éléments fournis, d'atteindre le résultat annoncé — une cartographie hiérarchisée des scénarios d'échec, avec éléments probants, indicateurs, responsables et expérimentations immédiates — ou s'il repose sur des hypothèses non résolues, des validations manquantes ou des détails inventés. Utilisez les vérifications comme critères de publication : révisez les données sources ou confiez l'évaluation à une personne nommément désignée et autorisée, au lieu de peaufiner un résultat sans fondement.

Pour quels outils d'IA existe-t-il des tests consignés de « Réaliser un pré-mortem de projet » ?

Le registre de tests publié pour « Réaliser un pré-mortem de projet » mentionne ChatGPT au 2026-08-28. Cela confirme l'existence d'essais consignés, mais ne garantit ni la compatibilité ni des résultats identiques dans les versions ultérieures du produit. Avec un autre outil ou une autre version, gardez toutes les contraintes visibles et répétez les vérifications du résultat avant utilisation.

Plus de façons d'explorer

Où se situe cette recette

Faites avancer votre travail