Prompts Gestion de projet

Rédige la note de cadrage du projet [nom du projet] pour [entreprise]. Objectif du projet : [objectif]. Commanditaire : [commanditaire]. Équipe : [composition]. Budget : [budget]. Échéance visée : [échéance]. Ce qui a déclenché le projet : [contexte].

Structure : contexte et problème à résoudre (3 lignes), objectif formulé de façon mesurable, périmètre inclus, périmètre explicitement EXCLU (aussi détaillé que l'inclus, c'est lui qui évite les dérives), livrables avec critères d'acceptation, jalons datés, rôles et responsabilités (qui décide, qui fait, qui est consulté, qui est informé), risques identifiés avec parade pour chacun ([risques déjà pressentis]), hypothèses et dépendances.

Formule chaque section pour qu'un désaccord éventuel apparaisse MAINTENANT, à la relecture, plutôt qu'au milieu du projet. Termine par les 3 questions à trancher en comité avant le lancement.

Transforme mes notes brutes de réunion en compte rendu structuré. Réunion : [objet de la réunion] du [date], participants : [participants]. Voici mes notes : [notes brutes, même désordonnées].

Format de sortie : décisions prises (formulées sans ambiguïté, avec qui a décidé), actions (tableau : action, responsable, échéance ; si l'un des trois manque dans mes notes, marque-le « À PRÉCISER » plutôt que d'inventer), points discutés sans décision (2 lignes max chacun), points reportés avec la date de la prochaine discussion.

Règles : maximum une page, aucune reformulation qui change le sens de ce qui a été dit, pas de tournures diplomatiques qui diluent les décisions (« il a été convenu d'avancer sur le sujet » est interdit). Termine par la liste des « À PRÉCISER » à renvoyer aux participants pour validation.

Découpe le projet suivant en lots et construis son planning. Projet : [description du projet et livrable final]. Échéance : [date]. Équipe disponible : [personnes et disponibilité, ex. 2 personnes à mi-temps]. Contraintes connues : [contraintes : validation client, dépendance fournisseur, période de congés].

Procède ainsi : découpe en lots de travail dont chacun produit un livrable vérifiable (pas de lot « coordination »), décompose chaque lot en tâches de 0,5 à 3 jours, identifie les dépendances entre tâches et le chemin critique, place une marge explicite sur les tâches incertaines plutôt qu'une marge cachée partout.

Livre : la liste structurée lots → tâches avec estimations, le planning par semaine avec les jalons de validation, le chemin critique mis en évidence, et les 3 tâches à démarrer immédiatement parce qu'elles conditionnent le reste. Signale si l'échéance [date] est intenable avec l'équipe décrite, chiffres à l'appui, plutôt que de compresser silencieusement les estimations.

Rédige le flash report hebdomadaire du projet [nom du projet] à destination de [destinataires, ex. comité de pilotage]. Données de la semaine : avancement [ce qui a été fait vs prévu], difficultés [problèmes rencontrés], risques qui évoluent [risques], budget consommé [consommé vs prévu], décisions attendues [décisions bloquantes en attente et depuis quand].

Format strict d'une page : météo du projet (vert/orange/rouge) avec LA phrase qui justifie la couleur, 3 faits marquants de la semaine, avancement vs plan (en une ligne par lot actif), risques et points durs (uniquement ce qui a changé depuis la semaine dernière), décisions attendues avec le nom du décideur et l'impact du retard, priorités de la semaine suivante.

Règles : un projet ne repasse jamais au vert sans expliquer ce qui a réglé le problème ; un point orange deux semaines de suite devient rouge ; les décisions en attente citent la date de la demande initiale.

Prépare l'animation d'une rétrospective pour le projet [nom du projet], qui vient de se terminer [issue : dans les temps, en retard de X, abandonné]. Participants : [participants et rôles]. Durée : [durée, ex. 1h30]. Faits saillants du projet : [ce qui s'est bien ou mal passé, tensions éventuelles].

Livre : le déroulé minuté (ouverture qui pose la règle « on cherche les causes, pas les coupables », recueil individuel avant discussion collective pour éviter l'effet de conformité, discussion des points majeurs, décisions), les questions exactes à poser pour dépasser les généralités (« à quel moment précis a-t-on su que le délai glissait ? qu'est-ce qui nous a empêchés de le dire ? »), et la technique pour faire parler sur [sujet sensible éventuel] sans que ça tourne au procès.

Format de sortie des enseignements : chaque apprentissage devient une règle actionnable pour le prochain projet (« désormais nous… »), avec un responsable de sa mise en œuvre. Maximum 5 règles : au-delà, rien ne sera appliqué.

Tu es un directeur de projet expérimenté. Aide-moi à construire l'étude d'opportunité du projet [nom du projet] envisagé par [entreprise]. Problème ou opportunité à l'origine : [contexte]. Bénéfices attendus : [bénéfices espérés]. Budget maximal envisageable : [montant]. Alternatives connues : [alternatives, y compris ne rien faire].

Structure le dossier en 6 parties : problème à résoudre et coût de l'inaction, options possibles (dont le statu quo) avec avantages et inconvénients, estimation grossière des coûts et délais par option en fourchette large, bénéfices attendus reliés à des indicateurs mesurables, risques majeurs de chaque option, recommandation argumentée.

Contraintes : chaque bénéfice doit être rattaché à un indicateur vérifiable, sinon le classer en « pari non mesurable ». Formule 5 critères de décision go/no-go que le comité pourra cocher. Termine par la liste des informations manquantes qui fragilisent l'étude et qui doit les fournir.

Rédige une charte projet d'une page pour un petit projet qui ne justifie pas une note de cadrage complète. Projet : [description en 2 phrases]. Demandeur : [demandeur]. Personnes impliquées : [personnes et temps disponible]. Échéance souhaitée : [date]. Budget éventuel : [montant ou aucun].

Format imposé, une page maximum : objectif en une phrase mesurable, livrable final et à quoi on reconnaît qu'il est terminé, ce qui est exclu du périmètre (3 lignes minimum, c'est la section la plus utile), qui décide en cas d'arbitrage, jalons (3 maximum), le risque principal et sa parade.

Contraintes : aucun jargon de gestion de projet, des phrases qu'un non-initié comprend à la première lecture. Si mes informations d'entrée ne permettent pas de remplir une rubrique, écris « À CLARIFIER avec [personne] » plutôt que d'inventer. Termine par les 2 questions à poser au demandeur avant de démarrer.

Je démarre le projet [nom du projet] pour [entreprise] et je dois recueillir les besoins avant de figer le périmètre. Personnes à interroger : [liste des profils, ex. direction, utilisateurs terrain, support, IT]. Ce que le projet doit produire : [livrable pressenti]. Durée disponible par entretien : [durée].

Prépare pour chaque profil un guide d'entretien adapté : 8 à 10 questions ouvertes classées de la plus large à la plus précise, en distinguant les questions sur le fonctionnement actuel (irritants, contournements, volumes) des questions sur le besoin futur. Ajoute pour chaque profil les 2 questions pièges qui font émerger les besoins non exprimés, par exemple « que faites-vous quand l'outil actuel ne suffit pas ? ».

Contraintes : bannir les questions qui suggèrent la réponse et celles auxquelles on répond par oui ou non. Fournis aussi la trame de synthèse pour consolider les entretiens : besoins exprimés, besoins déduits, contradictions entre profils à arbitrer, et verbatims marquants.

Transforme ces besoins bruts en user stories exploitables par une équipe de réalisation. Projet : [nom et description courte]. Utilisateurs concernés : [profils d'utilisateurs]. Besoins exprimés : [liste des besoins, même vagues].

Pour chaque besoin, produis : la user story au format « En tant que [profil], je veux [action] afin de [bénéfice] », 3 à 5 critères d'acceptation formulés de façon binaire (vérifiable par oui ou non, pas de « rapide » ou « ergonomique » sans seuil), et les questions à poser au demandeur si le besoin est trop vague pour être découpé.

Contraintes : une story doit être réalisable en quelques jours, sinon propose son découpage en stories plus petites. Signale les besoins qui n'en sont pas (solutions déguisées en besoins) et reformule-les en vrai besoin. Présente le résultat en tableau : story, critères d'acceptation, taille estimée (S/M/L), questions ouvertes. Termine par la liste des dépendances entre stories.

Aide-moi à prioriser le backlog du projet [nom du projet]. Éléments en attente : [liste des demandes avec une phrase de description chacune]. Capacité de l'équipe : [capacité, ex. 15 jours-homme par mois]. Objectif prioritaire du trimestre : [objectif]. Demandeurs qui poussent le plus fort : [contexte politique éventuel].

Évalue chaque élément sur deux axes : valeur (contribution à l'objectif du trimestre, nombre d'utilisateurs concernés, coût du problème non résolu) et effort estimé en taille relative. Classe ensuite en 4 catégories : à faire maintenant (forte valeur, faible effort), à planifier (forte valeur, fort effort), à regrouper en remplissage (faible valeur, faible effort), à refuser ou reporter explicitement (faible valeur, fort effort).

Contraintes : la pression du demandeur n'est pas un critère de valeur, mais liste à part les refus qui demanderont un message d'explication. Produis le classement en tableau avec la justification en une phrase par ligne, puis rédige les 3 messages de refus les plus délicats, courts et factuels.

Construis la roadmap des 2 prochains trimestres pour [produit ou projet] de [entreprise]. Objectifs de l'année : [objectifs]. Chantiers candidats : [liste des chantiers envisagés]. Capacité de l'équipe : [taille et disponibilité]. Engagements déjà pris : [engagements clients ou internes non négociables].

Organise la roadmap par trimestre en formulant chaque ligne comme un résultat attendu, pas comme une fonctionnalité (« réduire le délai de traitement des demandes » plutôt que « développer le module X »). Pour chaque trimestre : 2 ou 3 chantiers maximum, le résultat visé, l'indicateur qui dira si c'est réussi, les dépendances.

Contraintes : garde 20 % de capacité non allouée pour les imprévus et dis-le explicitement dans la roadmap. Liste ce qui est volontairement absent et pourquoi, pour couper court aux « et pourquoi pas X ? ». Fournis deux versions : une version détaillée pour l'équipe et une version en 5 lignes pour la direction. Signale les chantiers candidats dont la valeur est trop floue pour être placés.

Aide-moi à estimer les charges du projet [nom du projet]. Contenu : [liste des lots ou tâches identifiés]. Équipe : [profils et expérience]. Historique disponible : [projets comparables déjà réalisés et leur durée réelle, si connus].

Pour chaque lot : une estimation en fourchette (optimiste, probable, pessimiste) plutôt qu'un chiffre unique, les hypothèses qui sous-tendent l'estimation (ce qui doit être vrai pour qu'elle tienne), et le facteur qui ferait basculer vers le scénario pessimiste.

Contraintes : quand un historique de projets comparables existe, confronte l'estimation à la durée réelle constatée et explique l'écart. Ajoute systématiquement les charges oubliées dans la plupart des estimations : reprises après recette, coordination, montée en compétence, absences prévisibles sur la période. Présente le total en 3 scénarios avec l'écart en pourcentage entre optimiste et pessimiste. Si l'écart dépasse le double, dis quelles informations réduiraient l'incertitude avant de s'engager sur un chiffre.

Construis le budget complet du projet [nom du projet] de [entreprise]. Charges internes prévues : [jours-homme par profil et coût journalier si connu]. Achats et prestations externes : [liste]. Durée : [durée]. Enveloppe validée : [montant].

Produis d'abord le budget par poste : charges internes valorisées, prestations externes, licences et outils, frais annexes, et une provision pour aléas dont tu justifies le pourcentage selon le niveau d'incertitude du projet. Vérifie la cohérence avec l'enveloppe validée et signale tout dépassement dès la construction plutôt que de le découvrir en cours de route.

Construis ensuite le dispositif de suivi mensuel : tableau consommé vs budget par poste, reste à faire réestimé (pas seulement le reste à dépenser), projection de fin de projet, et 2 seuils d'alerte chiffrés qui déclenchent une information du sponsor. Termine par les 3 dérives budgétaires les plus fréquentes sur ce type de projet et comment les repérer tôt.

Établis le registre des risques du projet [nom du projet]. Contexte : [description du projet, échéance, enjeux]. Risques déjà pressentis : [risques identifiés]. Dépendances externes : [fournisseurs, autres équipes, validations attendues].

Complète ma liste avec les risques typiques de ce genre de projet que je n'ai pas cités, en cherchant dans 4 familles : humains (départ, surcharge, compétence manquante), techniques, organisationnels (arbitrages qui traînent, périmètre qui gonfle), externes. Pour chaque risque : description concrète de ce qui se passerait, probabilité (faible/moyenne/forte), impact (faible/moyen/fort), criticité résultante, signal avant-coureur observable, parade de prévention, plan de repli si le risque se réalise, responsable de la surveillance.

Contraintes : formuler chaque risque comme un événement (« le prestataire livre avec un mois de retard »), jamais comme un thème vague (« délais »). Classe par criticité décroissante et limite le registre aux 10 risques qui méritent vraiment un suivi. Précise le rituel de revue : fréquence et questions à se poser.

Cartographie les parties prenantes du projet [nom du projet] chez [entreprise]. Acteurs identifiés : [liste des personnes ou entités avec leur rôle]. Ce que le projet va changer pour chacun : [impacts pressentis]. Soutiens et résistances déjà perçus : [contexte].

Positionne chaque acteur sur deux axes : influence sur le projet (peut le bloquer, l'accélérer ou ni l'un ni l'autre) et adhésion actuelle (soutien, neutre, réticent). Pour chaque acteur influent : ce qu'il a à gagner ou à perdre avec le projet, son objection probable formulée avec ses mots, et l'action d'engagement adaptée (implication dans les décisions, information régulière, entretien individuel avant les annonces).

Contraintes : ne pas confondre l'organigramme et l'influence réelle, signale les acteurs sans titre mais dont l'avis pèse. Produis le plan d'engagement en tableau : acteur, position actuelle, position nécessaire pour que le projet réussisse, actions, porteur, échéance. Termine par les 2 acteurs à voir en priorité cette semaine et pourquoi.

Bâtis le plan de communication du projet [nom du projet]. Publics concernés : [publics, ex. sponsor, équipe, utilisateurs impactés, autres services]. Durée du projet : [durée]. Moments clés déjà connus : [jalons, bascules, annonces]. Canaux disponibles : [canaux : réunion, email, intranet, affichage].

Pour chaque public, définis : ce qu'il a besoin de savoir (et seulement cela), la fréquence adaptée, le canal, le format (2 lignes, une page, réunion), et qui produit le message. Distingue la communication récurrente (avancement) de la communication événementielle (lancement, bascule, incident, fin de projet).

Contraintes : chaque communication doit répondre à la question du destinataire « qu'est-ce que ça change pour moi ? », sinon la supprimer du plan. Prévois le message de lancement et le message de bascule en version rédigée. Présente le plan en tableau synthétique, puis liste les 3 erreurs de communication les plus fréquentes sur ce type de projet et comment ce plan les évite.

Construis la matrice RACI du projet [nom du projet]. Activités principales : [liste des grandes activités ou livrables]. Acteurs : [personnes ou fonctions impliquées]. Tensions ou flous déjà constatés : [contexte, ex. deux personnes pensent décider du même sujet].

Pour chaque activité, attribue les rôles : R (réalise), A (assume la décision et rend des comptes, un seul par ligne), C (consulté avant), I (informé après). Explique en une ligne chaque attribution non évidente.

Contraintes de qualité à vérifier toi-même avant de livrer : jamais deux A sur une ligne, aucune ligne sans R, signaler les acteurs C sur presque toutes les lignes (goulot d'étranglement de consultation) et les acteurs sans aucun rôle (à retirer du projet ou à repositionner). Présente la matrice en tableau, puis liste les 3 lignes les plus susceptibles de créer un conflit en cours de projet avec ta recommandation pour les sécuriser, et les questions à trancher en réunion d'équipe avant de diffuser la matrice.

Prépare la réunion de lancement du projet [nom du projet]. Participants : [participants et rôles]. Durée : [durée, ex. 1 h]. État du cadrage : [note de cadrage validée ou en cours]. Points sensibles : [tensions, scepticisme, historique de projets ratés sur le sujet].

Livre : le déroulé minuté (pourquoi ce projet et pourquoi maintenant, le résultat final concret, ce qui est hors périmètre, qui fait quoi, les jalons, les règles de fonctionnement de l'équipe, les questions), les 3 messages que chaque participant doit retenir en sortant, et la façon de traiter [point sensible] sans le laisser plomber la réunion ni l'esquiver.

Contraintes : le kick-off n'est pas une réunion d'information descendante, prévois 2 moments où les participants produisent quelque chose (identification des risques à chaud, tour de table des contraintes de chacun). Fournis aussi le message d'invitation avec l'ordre du jour et ce que chacun doit préparer, et la liste de ce qui doit être validé AVANT le kick-off pour ne pas lancer un projet flou.

Prépare le prochain comité de pilotage du projet [nom du projet]. Participants : [membres du COPIL]. Durée : [durée]. Situation du projet : [avancement, difficultés, budget]. Décisions dont j'ai besoin : [décisions attendues avec leurs options]. Sujets qui risquent de monopoliser la discussion : [sujets sensibles].

Construis l'ordre du jour en partant des décisions à obtenir, pas de l'avancement : chaque décision attendue devient un point avec le temps alloué, les options préparées (2 ou 3, avec avantages, inconvénients et recommandation), et ce qui se passe si la décision est encore reportée. L'avancement se traite en 10 minutes maximum sur la base d'un document envoyé avant.

Fournis : l'ordre du jour minuté, la formulation exacte de chaque demande de décision, la technique pour couper courtoisement les digressions sur [sujet sensible], et le modèle de relevé de décisions à envoyer dans les 24 h. Termine par la liste de ce que je dois envoyer aux participants 48 h avant.

Structure le support de présentation du comité de pilotage du projet [nom du projet]. Données du mois : avancement [réalisé vs prévu], budget [consommé vs budget], risques [évolution des risques], décisions attendues [liste], faits marquants [événements du mois].

Produis la trame slide par slide, 10 slides maximum : synthèse en une slide (météo, message principal, décisions attendues), avancement par lot avec écart vs plan, trajectoire budget, risques dont la cotation a changé, zoom sur le point dur du mois avec options et recommandation, décisions demandées (une slide par décision), prochaines étapes.

Pour chaque slide : le titre formulé comme un message (« Le lot 2 rattrape son retard », pas « Avancement lot 2 »), le contenu en 5 puces maximum, et ce qu'il faut dire à l'oral qui ne figure pas sur la slide. Contraintes : aucune slide de rappel du contexte que le COPIL connaît déjà, les chiffres arrondis et comparés (vs plan, vs mois dernier), le détail en annexe. Termine par le test : si le COPIL ne lit que la slide 1, a-t-il l'essentiel ?

Mets en place le circuit de gestion des demandes de changement du projet [nom du projet]. Contexte : [origine des demandes, ex. le client ajoute des demandes au fil de l'eau, la direction change d'avis]. Instances existantes : [réunions et comités en place]. Marge disponible : [marge de délai et de budget restante].

Définis : le formulaire minimal de demande (description, demandeur, justification, urgence réelle), les 4 questions d'instruction systématiques (impact délai, impact budget, impact sur les autres lots, que se passe-t-il si on ne le fait pas), qui décide selon la taille de l'impact (seuils chiffrés à proposer), et comment tracer les décisions dans un registre des changements.

Rédige aussi les 3 réponses types : demande acceptée avec impact annoncé, demande reportée en version ultérieure, demande refusée avec justification. Contraintes : le circuit doit tenir en une demi-page sinon personne ne l'appliquera, et aucune demande ne doit être acceptée oralement sans passer par le registre. Termine par la façon de présenter ce circuit au demandeur le plus insistant sans le braquer.

Aide-moi à préparer la renégociation d'un délai intenable. Projet : [nom du projet]. Échéance demandée : [date]. Ma conviction : il faut [durée réaliste] parce que [raisons : charge estimée, dépendances, équipe disponible]. Sponsor : [profil du sponsor et ce qui compte pour lui]. Enjeu derrière la date : [pourquoi cette date, si je le sais].

Construis : la démonstration factuelle de l'écart (charge vs capacité, en chiffres simples et vérifiables), puis 3 options honnêtes à présenter : tenir la date en réduisant le périmètre (dire précisément ce qui saute), tenir le périmètre en décalant la date, ajouter des moyens avec le coût et les limites de cette option (une personne qui arrive ne produit pas dès la première semaine).

Contraintes : jamais « c'est impossible » sans alternative, jamais accepter en réunion un compromis non chiffré. Prépare la réponse aux 3 objections probables du sponsor, dont « débrouillez-vous » et « on verra bien ». Format : une page d'argumentaire plus le tableau des 3 options avec conséquences comparées.

Construis le plan de rattrapage du projet [nom du projet], en retard de [durée du retard] sur une échéance au [date]. Causes identifiées : [causes du retard]. Reste à faire : [lots ou tâches restants avec estimations]. Équipe : [composition et disponibilité]. Marges de manœuvre : [budget additionnel possible, périmètre négociable ou non].

Commence par vérifier le diagnostic : le retard vient-il d'estimations trop basses, d'un périmètre qui a gonflé, de ressources détournées ou de blocages externes ? La réponse change le plan. Ensuite, construis le rattrapage à partir des seuls leviers réels : réduction de périmètre, réordonnancement pour paralléliser, suppression des tâches devenues inutiles, renfort ciblé sur le chemin critique uniquement.

Contraintes : interdit de rattraper en « compressant » les estimations restantes sans justification, interdit de supprimer les temps de recette. Livre : le nouveau planning avec la nouvelle date fiable, ce qui a été sacrifié pour l'obtenir, les 2 conditions pour que ce plan tienne, et le message d'annonce au sponsor qui assume le retard sans le noyer.

Prépare l'escalade d'un blocage sur le projet [nom du projet]. Blocage : [description du blocage, ex. décision en attente, ressource non allouée, arbitrage entre deux services]. Depuis : [date]. Ce que j'ai déjà tenté : [relances et démarches faites]. Destinataire de l'escalade : [personne et son niveau]. Personnes impliquées dans le blocage : [acteurs, avec les susceptibilités éventuelles].

Rédige le message d'escalade : rappel du blocage en 3 lignes factuelles et datées, conséquences concrètes du statu quo chiffrées quand c'est possible (jours perdus, coût, jalons menacés), les 2 ou 3 options de déblocage avec ma recommandation, la décision demandée et pour quand.

Contraintes : aucune mise en cause personnelle, les faits et les dates portent le message à ta place ; le destinataire doit pouvoir décider en lisant uniquement ce message, sans réunion. Prévois aussi la version courte orale de 60 secondes si je le croise, et le message d'information aux personnes concernées par l'escalade pour qu'elles ne la découvrent pas par ricochet.

Organise le suivi des actions du projet [nom du projet] entre les réunions. Situation actuelle : [problème constaté, ex. les actions décidées en réunion ne sont faites qu'à moitié, les relances passent pour du flicage]. Rythme des réunions : [fréquence]. Outils disponibles : [outils : tableur, outil de tickets, messagerie].

Propose un système complet : le format du registre d'actions (action formulée avec un verbe et un livrable vérifiable, responsable unique, échéance, statut), le rituel de mise à jour (qui met à jour, quand, en combien de temps), et la mécanique de relance graduée : rappel automatique à J-2, message individuel factuel à l'échéance, mention en réunion seulement au deuxième dépassement.

Rédige les modèles de messages de relance aux 3 niveaux, courts et sans reproche. Contraintes : une action sans échéance ou sans responsable unique est refusée à la source, à reformuler en réunion ; le registre ne doit pas dépasser ce que l'équipe peut réellement absorber, propose une règle de limitation. Termine par la manière de présenter le système à l'équipe pour qu'il soit perçu comme une aide.

Conçois le tableau de bord du projet [nom du projet]. Nature du projet : [type et livrable]. Durée : [durée]. Points sensibles à surveiller : [enjeux, ex. délai serré, budget contraint, qualité critique]. Données disponibles : [sources : outil de tickets, feuilles de temps, budget].

Sélectionne 6 à 8 indicateurs maximum, répartis en 3 blocs : avancement (réalisé vs prévu en livrables terminés, pas en pourcentage d'avancement déclaré des tâches en cours), santé (actions en retard, décisions en attente et leur ancienneté, risques dont la cotation monte), ressources (consommé vs budget, charge de l'équipe).

Pour chaque indicateur : définition précise, source, fréquence de mise à jour, seuil d'alerte justifié. Contraintes : bannir les indicateurs déclaratifs invérifiables (« avancement 80 % ») au profit du binaire terminé/pas terminé ; chaque indicateur doit déclencher une action possible quand il passe au rouge, sinon le retirer. Décris la lecture hebdomadaire en 15 minutes : ordre de lecture, questions à se poser, et quand alerter au-delà de l'équipe.

Rédige le rapport d'avancement mensuel du projet [nom du projet] pour [destinataires, ex. comité de direction]. Données du mois : réalisations [ce qui a été livré], écarts [retards ou dépassements], budget [consommé vs prévu], risques [évolutions], décisions prises [liste], alertes [points durs].

Format imposé, une page : trajectoire globale en 2 phrases (le projet atterrira-t-il à la date et au budget prévus, oui ou non, et qu'est-ce qui a changé ce mois-ci), réalisations du mois en 3 puces reliées aux jalons, écarts avec leur cause et leur traitement (pas d'écart orphelin sans plan), budget en une ligne avec projection de fin, alertes nécessitant la direction avec la demande explicite associée.

Contraintes : la direction lit 20 rapports comme celui-ci, aucune phrase d'autopromotion ni de remplissage ; chaque alerte débouche sur une demande précise (arbitrage, moyen, décision) sinon c'est une information à garder pour le rapport d'équipe. Écarts et mauvaises nouvelles en premier, pas enterrés en fin de page.

Aide-moi à arbitrer les ressources entre plusieurs projets concurrents. Projets en cours : [liste des projets avec leur échéance, leur enjeu et leur avancement]. Ressources partagées : [personnes travaillant sur plusieurs projets et leur répartition actuelle]. Conflit actuel : [description du conflit de ressources]. Qui tranche en dernier ressort : [instance ou personne].

Construis d'abord la photographie honnête : qui travaille sur quoi, en pourcentage réel et pas théorique, et où sont les personnes sollicitées à plus de 100 %. Ensuite, propose une grille d'arbitrage sur des critères explicites : enjeu pour l'entreprise, coût du retard de chaque projet, irréversibilité (fenêtre de tir qui se ferme), engagement externe pris.

Applique la grille au conflit actuel et produis 2 scénarios d'allocation avec, pour chacun, ce que chaque projet gagne et perd en clair, et la date de fin qui en découle. Contraintes : interdit de résoudre le conflit en surchargeant les personnes ou en promettant du mi-temps sur 3 projets ; le scénario retenu doit être annonçable aux chefs de projet perdants avec une justification qui tient.

Prépare la planification du prochain sprint de l'équipe [équipe] sur le projet [nom du projet]. Durée du sprint : [durée]. Capacité : [personnes présentes, absences prévues, temps récurrent hors sprint : support, réunions]. Backlog priorisé : [éléments candidats avec leur taille estimée]. Reste du sprint précédent : [éléments non terminés].

Structure la séance : calcul de la capacité réelle (temps disponible moins récurrent moins imprévus, avec une règle simple et affichée), formulation de l'objectif de sprint en une phrase qui dit le résultat obtenu à la fin (pas une liste de tickets), sélection des éléments dans la limite de la capacité en commençant par les restes du sprint précédent, vérification collective que chaque élément est compris et suffisamment défini pour être commencé.

Contraintes : refuser les éléments sans critères d'acceptation ; si le demandeur pousse plus que la capacité, la réponse est un choix entre éléments, jamais un dépassement accepté en silence. Livre le déroulé minuté de la séance, la formulation de l'objectif de sprint, et les 3 signes en cours de sprint qui montrent que l'engagement ne sera pas tenu.

Prépare l'animation de la rétrospective de sprint de l'équipe [équipe]. Durée : [durée, ex. 45 min]. Ambiance actuelle : [contexte, ex. rituel usé où plus personne ne dit rien, tension récente, équipe nouvelle]. Sujets du moment : [événements du sprint écoulé]. Actions des rétros précédentes : [actions décidées et leur état réel].

Livre : le déroulé minuté commençant par le bilan des actions de la rétro précédente (une rétro dont les actions ne sont jamais faites meurt en 3 itérations), un format d'animation adapté à [ambiance actuelle] avec les consignes exactes à donner, les questions de relance quand l'équipe reste en surface, et la méthode de sélection : maximum 2 actions d'amélioration, choisies par l'équipe, chacune avec un responsable et une échéance dans le sprint suivant.

Contraintes : aucune action du type « mieux communiquer », chaque action décrit un changement observable ; les sujets qui dépassent l'équipe (organisation, hiérarchie) sont notés à part avec un canal d'escalade, pas ruminés en boucle. Propose aussi 2 formats alternatifs pour faire tourner le rituel sur les prochaines rétros.

Cadre le point quotidien de l'équipe [équipe] sur le projet [nom du projet]. Situation actuelle : [problème constaté, ex. le daily dure 30 minutes, tourne au rapport d'activité au chef, certains décrochent]. Taille de l'équipe : [nombre]. Mode de travail : [présentiel, distanciel, mixte].

Propose le format cible : durée maximale, heure fixe, et le contenu recentré sur la coordination : ce qui est terminé depuis hier, ce qui bloque ou risque de bloquer, ce dont j'ai besoin des autres. Ce qui ne relève pas de la coordination (débats techniques, résolution de problème) est noté et traité juste après avec les seuls concernés.

Donne : les règles d'animation qui empêchent la dérive en rapport au chef (l'équipe se parle entre elle, rotation de l'animation), la phrase pour couper une digression sans vexer, les adaptations pour [mode de travail], et les 3 signaux qu'un daily ne sert plus à rien avec le correctif pour chacun. Termine par le message d'annonce du nouveau format à l'équipe, qui explique le pourquoi sans désavouer l'ancien fonctionnement.

Aide l'équipe [équipe] à définir sa definition of done pour le projet [nom du projet]. Type de livrables : [nature des livrables, ex. fonctionnalités logicielles, supports de formation, dossiers d'études]. Problèmes constatés : [symptômes, ex. livrables déclarés finis puis rouverts, qualité inégale selon les personnes, recette qui découvre des trous].

Construis la definition of done en 3 niveaux : ce qui rend un élément « terminé » (critères vérifiables : relu par un pair, testé, documenté, validé par qui), ce qui est explicitement exclu de la définition pour rester réaliste, et les exceptions admises avec la règle pour les tracer plutôt que les cacher.

Contraintes : 8 critères maximum, tous vérifiables par oui ou non, aucun critère que l'équipe ne peut pas satisfaire avec ses moyens actuels (sinon la définition sera ignorée dès la première urgence). Livre aussi : la méthode pour la faire adopter en atelier d'équipe plutôt que l'imposer, la règle d'application aux travaux déjà en cours, et le rituel de révision après quelques semaines d'usage.

Organise la recette utilisateur du projet [nom du projet]. Livrable à recetter : [description]. Testeurs disponibles : [profils et disponibilité]. Durée prévue : [durée]. Critères d'acceptation existants : [critères définis en amont, ou aucun].

Construis : le plan de recette avec les cas de test organisés par parcours utilisateur réel (pas par écran ou par fonction), chaque cas décrit en donnée d'entrée, action, résultat attendu ; la priorisation des cas (bloquant pour la mise en service, important, confort) ; la règle de classement des anomalies avec des exemples concrets de chaque niveau pour éviter les débats sans fin ; le circuit de correction et de re-test.

Livre aussi la trame du procès-verbal de recette : ce qui a été testé, anomalies par niveau, décision (acceptation, acceptation avec réserves listées et datées, refus) et signataires. Contraintes : une recette sans données réalistes ne prouve rien, précise comment préparer le jeu de données ; les réserves acceptées doivent avoir un responsable et une échéance de levée, sinon elles deviennent définitives.

Prépare le plan de mise en production de [livrable ou système] pour le projet [nom du projet]. Date visée : [date]. Utilisateurs impactés : [qui et combien]. Fenêtre d'intervention possible : [créneau, ex. week-end, nuit, heures ouvrées]. Acteurs de la bascule : [personnes et rôles]. Retour arrière possible : [oui/non/partiel, et comment].

Construis : la checklist d'avant bascule (prérequis techniques, validations obtenues, communication faite, sauvegardes vérifiées, disponibilité des acteurs clés confirmée), le déroulé de la bascule heure par heure avec le responsable de chaque étape et le critère de réussite observable de chaque étape, les points de décision go/no-go avec qui décide et sur quels critères, le plan de retour arrière déclenché par quels signaux et exécuté comment, et la surveillance des premières heures et premiers jours.

Contraintes : chaque étape a un critère de réussite vérifiable, pas de « ça devrait aller » ; le retour arrière doit être décrit avec le même niveau de détail que la bascule, c'est lui qu'on exécute sous stress. Termine par le message d'annonce aux utilisateurs avant et après la bascule.

Organise la continuité d'activité pendant la migration de [ancien système ou processus] vers [nouveau système ou processus] chez [entreprise]. Durée de transition prévue : [durée]. Activités qui ne peuvent pas s'arrêter : [activités critiques]. Équipes concernées : [équipes]. Période à risque connue : [contraintes de calendrier, ex. clôture comptable, pic d'activité saisonnier].

Traite les questions qui font échouer les transitions : pendant la coexistence, quel système fait foi pour chaque type de donnée ou d'opération (règle claire par cas, affichée), comment éviter la double saisie ou l'organiser proprement si elle est inévitable, qui traite les opérations à cheval commencées dans l'ancien et finies dans le nouveau, et comment on gèle ou synchronise les données au moment du basculement final.

Livre : le tableau des activités critiques avec leur mode de fonctionnement pendant la transition, les règles de « qui fait foi » par cas, le dispositif de support renforcé des premières semaines, et les 3 scénarios d'incident les plus probables avec la conduite à tenir pour chacun.

Prépare la clôture du projet [nom du projet], dont le livrable a été accepté le [date]. Éléments du projet : [prestataires impliqués, budget, documentation produite, équipe]. Réserves restantes : [réserves de recette éventuelles].

Construis la checklist de clôture complète : volet contractuel (solde des prestataires, levée ou traitement des réserves, fin des accès accordés aux externes), volet financier (arrêt des imputations, bilan consommé vs budget avec explication des écarts, clôture des lignes budgétaires), volet documentaire (où archiver quoi, ce qui doit rester retrouvable dans 2 ans et par qui), volet humain (réaffectation de l'équipe annoncée proprement, remerciements nominatifs au bon niveau), volet transfert (qui devient responsable du livrable en exploitation, avec quel support).

Contraintes : distingue ce qui bloque la clôture de ce qui peut se finir après ; un projet « fini à 98 % » qui traîne 6 mois coûte cher, fixe une date de clôture ferme. Livre aussi la trame du bilan de projet en une page : chiffres clés, réussites, écarts, et où sont archivés les enseignements.

Organise la passation du projet [nom du projet] entre [chef de projet sortant] et [chef de projet entrant]. Contexte du départ : [raison et préavis disponible]. État du projet : [avancement, points chauds, jalons à venir]. Temps de tuilage possible : [durée de recouvrement, ou aucun].

Construis le dossier de passation en priorisant ce qui ne figure dans aucun document : l'historique des décisions et leurs raisons, les engagements oraux pris avec le client ou le sponsor, les sujets sensibles et les susceptibilités des acteurs, les risques que le sortant surveille sans les avoir formalisés, l'état réel de chaque lot au-delà du reporting officiel.

Organise le tuilage : les réunions où le sortant introduit l'entrant en personne (sponsor, client, équipe), l'ordre des sujets à transmettre selon leur urgence, et le message d'annonce du changement qui rassure sans surjouer la continuité. Contraintes : la passation se vérifie, prévois une liste de questions que l'entrant doit savoir traiter seul à la fin du tuilage ; ce qui n'a pas pu être transmis est listé explicitement avec un contact de secours.

Prépare l'intégration de [nouvel arrivant, profil] qui rejoint l'équipe du projet [nom du projet] le [date], en cours de projet. État du projet : [avancement et contexte]. Rôle attendu : [missions confiées]. Temps disponible de l'équipe pour l'accompagner : [contrainte réelle].

Construis le parcours des 2 premières semaines : le kit de lecture du premier jour limité à l'essentiel (note de cadrage, dernier flash report, registre des risques, glossaire du projet), les 4 entretiens à programmer avec les bonnes personnes et l'objectif de chacun, une première contribution utile et bien délimitée dès la première semaine (choisir quoi selon [rôle attendu]), et un référent désigné avec un point quotidien de 10 minutes.

Contraintes : interdire le tour de 15 réunions passives, l'arrivant apprend en produisant ; expliciter ce que personne ne dit jamais à un arrivant : les susceptibilités entre acteurs, les sujets qui fâchent, les circuits de décision réels. Livre le planning des 2 semaines, la liste de lecture ordonnée, et les questions auxquelles l'arrivant doit savoir répondre à J+15 pour valider son intégration.

Aide-moi à gérer un conflit dans mon équipe projet. Contexte : [description factuelle du conflit entre les deux personnes, sans jugement], sur le projet [nom du projet]. Impact constaté : [effets sur le projet : rétention d'information, réunions tendues, retards]. Mon rôle : [chef de projet, sans lien hiérarchique / avec lien hiérarchique]. Historique : [ancienneté du conflit, tentatives déjà faites].

Propose une démarche en 3 temps : entretiens individuels d'abord (les questions à poser pour comprendre la version de chacun sans valider ni trahir, les pièges à éviter dont celui de jouer les arbitres sur le fond), entretien commun ensuite (le cadre à poser en ouverture, comment ramener aux faits quand ça repart sur les personnes, comment obtenir un accord sur 2 ou 3 règles de fonctionnement concrètes), suivi enfin (comment vérifier que l'accord tient sans surveiller ostensiblement).

Contraintes : rester dans le rôle de chef de projet, les sujets relevant du management hiérarchique ou des RH sont identifiés et transmis, pas traités ; aucune des deux personnes ne doit sortir de la démarche désignée comme fautive devant l'équipe. Indique aussi les signaux qui imposent d'escalader sans attendre.

Aide-moi à recadrer un prestataire qui dérape sur le projet [nom du projet]. Prestataire : [société et prestation]. Dérives constatées : [faits datés : retards, qualité insuffisante, interlocuteur changé, promesses non tenues]. Cadre contractuel : [ce que prévoit le contrat : livrables, délais, pénalités éventuelles]. Dépendance : [à quel point ce prestataire est remplaçable].

Construis la gradation : d'abord le point de recadrage (le dossier factuel des écarts entre l'engagement et le constaté, daté et sourcé ; le déroulé de la réunion qui exige un plan de redressement daté plutôt que des excuses), puis le suivi rapproché (jalons courts, critères de sortie de crise explicites, compte rendu écrit après chaque point), enfin la préparation de l'alternative si le redressement échoue (à lancer discrètement dès maintenant si la dépendance est forte).

Contraintes : tout se formalise par écrit après chaque échange oral, c'est le dossier qui protège en cas de litige ; rester factuel et contractuel, aucune menace qu'on ne peut pas exécuter. Livre : le dossier d'écarts en tableau, le courriel de convocation au point de recadrage, la trame de la réunion, et les critères objectifs qui déclencheraient la sortie.

Rédige le cahier des charges pour consulter des prestataires sur [objet de la consultation, ex. refonte d'un site, déploiement d'un outil, prestation récurrente] pour [entreprise]. Besoin : [description du besoin et du problème à résoudre]. Contexte technique et organisationnel : [existant, contraintes]. Budget indicatif : [fourchette, ou volontairement non communiqué]. Calendrier : [échéances].

Structure : présentation de l'entreprise et du contexte en une demi-page, le problème à résoudre et les objectifs formulés en résultats attendus (décrire le besoin, pas la solution, sauf contrainte réelle à justifier), le périmètre et ses exclusions, les contraintes non négociables (techniques, réglementaires, calendaires), les livrables attendus, les critères de sélection annoncés avec leur pondération, le déroulé de la consultation (questions, date de remise, soutenances éventuelles), et le format de réponse imposé pour pouvoir comparer les offres.

Contraintes : chaque exigence est testable à la livraison, sinon la reformuler ; distinguer exigences impératives et souhaits, tout classer en impératif tue la comparaison. Termine par les 5 questions à poser en soutenance qui révèlent les prestataires qui ont vraiment compris le besoin.

Construis la grille de comparaison des offres reçues pour [objet de la consultation]. Offres : [nombre d'offres et résumé de chacune : prix, délai, approche, points saillants]. Critères qui comptent pour nous : [priorités, ex. tenue des délais, accompagnement, coût complet, pérennité du prestataire]. Signaux perçus : [impressions à vérifier, ex. offre très en dessous des autres, réponse générique].

Construis la grille : critères regroupés en familles (compréhension du besoin, approche proposée, équipe réellement affectée, prix complet sur la durée y compris ce qui n'est pas dans le devis initial, références comparables vérifiables, conditions contractuelles), pondération justifiée par mes priorités, échelle de notation avec un descriptif par niveau pour limiter la subjectivité.

Applique la grille aux offres décrites et signale : les écarts de prix inexpliqués (une offre très basse cache souvent un périmètre réduit, liste les questions pour le vérifier), les moyens présentés en soutenance qui ne seront pas ceux du projet, les coûts cachés récurrents. Livre le tableau comparatif rempli, les questions de clarification à envoyer par offre, et la recommandation argumentée en 5 lignes.

Construis le plan de conduite du changement pour [projet, ex. déploiement d'un nouvel outil, réorganisation d'un processus] chez [entreprise]. Populations impactées : [groupes concernés avec leur effectif et ce qui change pour chacun]. Craintes exprimées ou pressenties : [résistances anticipées]. Calendrier de déploiement : [dates clés]. Moyens disponibles : [temps, budget, relais possibles].

Pour chaque population : ce qui change concrètement dans son quotidien (gains ET pertes, les pertes tues se paient plus tard), le niveau d'accompagnement nécessaire (information, formation, assistance rapprochée), et le message clé formulé de son point de vue.

Structure le plan dans le temps : avant (annonce, réseau de relais internes choisis pour leur crédibilité auprès des collègues et non pour leur disponibilité, formation), pendant (assistance renforcée, remontée organisée des irritants, correction visible et annoncée des problèmes signalés), après (mesure de l'usage réel plutôt que du taux de formation, traitement des poches de résistance restantes).

Contraintes : aucun plan fondé sur « communiquer plus » sans dire quoi à qui ; chaque action a un porteur et une date. Livre le plan en tableau par population et le calendrier consolidé.

Conçois le plan de formation des utilisateurs finaux pour le déploiement de [outil ou processus] chez [entreprise]. Utilisateurs : [profils, effectifs, niveau d'aisance, répartition géographique]. Ce que chaque profil devra savoir faire : [tâches par profil]. Contraintes : [disponibilité des équipes, budget, échéance de bascule].

Construis un dispositif par profil plutôt qu'une formation unique : pour chacun, les 5 à 10 gestes à maîtriser tirés de ses cas d'usage réels (pas le tour exhaustif des fonctionnalités), le format adapté (session courte en groupe, tutoriel, prise en main accompagnée au poste), la durée, et le support de référence à laisser (fiches par tâche, une page chacune, plutôt qu'un manuel).

Planifie les sessions au plus près de la bascule : une formation suivie 6 semaines avant l'usage est oubliée. Prévois le dispositif de rattrapage pour les absents et le relais de proximité par site ou par équipe.

Contraintes : mesurer la réussite sur l'usage réel après bascule (capacité à réaliser les gestes clés, volume de sollicitations du support) et non sur le taux de participation. Livre le plan en tableau par profil et la liste des supports à produire, priorisée.

Un incident majeur touche le projet [nom du projet] : [nature de l'incident, ex. bascule échouée, perte de données, arrêt d'un service utilisé par les clients, dérive grave découverte]. Impacts constatés : [qui est touché et comment]. État de la résolution : [ce qu'on sait, ce qu'on ignore encore]. Publics à informer : [direction, équipes internes, clients, partenaires].

Rédige la séquence de communication : le premier message envoyé vite, qui dit ce qu'on sait, ce qu'on ignore, ce qu'on fait et quand on redonnera des nouvelles (s'engager sur l'heure du prochain point, pas sur l'heure de résolution qu'on ne connaît pas), les points d'étape au rythme annoncé même sans nouveauté, et le message de résolution avec les mesures prises pour éviter la répétition.

Décline chaque message par public : la direction veut l'impact et les décisions à prendre, les utilisateurs veulent savoir comment travailler en attendant, les clients veulent savoir s'ils sont touchés et protégés. Contraintes : aucune spéculation sur la cause tant qu'elle n'est pas établie, aucune désignation de coupable, aucune promesse de délai non tenue une seule fois : c'est la crédibilité de toute la suite. Livre les messages prêts à adapter et la règle de qui parle à qui.

Aide l'équipe [équipe] de [entreprise] à rédiger ses OKR du trimestre [trimestre]. Priorités de l'entreprise sur la période : [priorités]. Missions récurrentes de l'équipe : [activités permanentes]. Chantiers envisagés : [projets et idées en discussion]. Effectif : [taille de l'équipe].

Produis 2 ou 3 objectifs maximum : chacun formulé comme un changement d'état inspirant mais concret (pas une liste de tâches), rattaché explicitement à une priorité de l'entreprise. Pour chaque objectif, 2 à 4 résultats clés : mesurables avec une valeur de départ et une valeur cible, mesurant un résultat obtenu et non une activité réalisée (« réduire le délai de traitement de X à Y » et non « déployer l'outil Z »).

Contraintes : le run quotidien ne se transforme pas en OKR, il se pilote à part ; un résultat clé dont on ne sait pas dire aujourd'hui comment on le mesurera est reformulé ou abandonné ; signale les objectifs que l'équipe ne contrôle pas assez pour s'engager. Livre les OKR proposés, les questions à trancher en atelier d'équipe, et le rituel de suivi : fréquence, format 15 minutes, et ce qu'on fait quand un résultat clé décroche.

Prépare la revue de fin de trimestre des OKR de l'équipe [équipe]. OKR du trimestre écoulé : [objectifs et résultats clés avec leur niveau d'atteinte]. Événements marquants du trimestre : [contexte : imprévus, changements de priorité, départs]. Participants à la revue : [participants]. Durée : [durée].

Structure la revue en 3 temps : notation honnête de chaque résultat clé sur les chiffres réels (un résultat non mesuré est un résultat non atteint, pas un « à peu près fait »), analyse des écarts en séparant ce qui relève de l'exécution, de l'ambition mal calibrée ou d'événements extérieurs (la réponse diffère pour chaque cause), décisions pour le trimestre suivant (ce qu'on reconduit, ce qu'on abandonne explicitement, ce qu'on recalibre).

Contraintes : la revue n'est pas un exercice de justification, interdis les slides de contexte et va directement aux chiffres ; un objectif atteint à 100 % dès le premier trimestre interroge l'ambition autant qu'un objectif à 20 % interroge l'exécution. Livre : le déroulé minuté, la grille de notation, les questions d'analyse par résultat clé, et la trame du message de synthèse à diffuser après la revue.

Prépare le post-mortem de l'incident [description de l'incident] survenu le [date] sur le projet [nom du projet]. Chronologie connue : [déroulé des événements avec les heures si disponibles]. Personnes impliquées : [acteurs]. Climat : [contexte, ex. une personne se sent visée, la direction cherche un responsable].

Structure le document et la réunion : chronologie factuelle reconstituée collectivement (heure par heure, sans interprétation), analyse des causes en remontant au-delà de l'erreur individuelle (une erreur humaine possible est un symptôme : qu'est-ce qui a permis qu'elle se produise, qu'est-ce qui aurait dû la rattraper avant l'impact), ce qui a bien fonctionné dans la détection et la réaction, et les actions de prévention.

Règles d'animation à poser en ouverture : on cherche comment le système a laissé passer l'incident, pas qui a fait l'erreur ; celui qui dit « j'ai fait une erreur » rend service à tous et ne doit jamais le regretter. Contraintes : 5 actions maximum, chacune avec un responsable et une échéance, en privilégiant celles qui suppriment la possibilité de l'erreur plutôt que celles qui demandent d'être plus vigilant. Livre la trame du document et le déroulé de la réunion.

Aide-moi à transformer les retours d'expérience accumulés par [équipe ou entreprise] en standards de fonctionnement. Matière disponible : [sources : comptes rendus de rétrospectives, bilans de projets, post-mortems, remarques récurrentes]. Problème actuel : [symptôme, ex. les mêmes erreurs se répètent d'un projet à l'autre, les bilans sont écrits puis jamais relus].

Procède ainsi : regroupe les enseignements par thème et repère ceux qui reviennent plusieurs fois (la récurrence désigne les standards prioritaires), transforme chaque enseignement retenu en règle actionnable formulée en une phrase avec son déclencheur (« à chaque démarrage de projet, nous faisons X »), et définis où vivent ces règles pour être vues au bon moment : intégrées dans les modèles de documents et les checklists existants plutôt que dans un document de sagesse que personne n'ouvre.

Contraintes : 10 règles maximum au total, chaque règle a un propriétaire qui la fait vivre ; prévois la revue semestrielle qui supprime les règles devenues inutiles, un référentiel qui ne fait que grossir meurt. Livre : les règles proposées classées par moment d'usage, leur support d'intégration, et le message d'annonce à l'équipe.

Prépare le projet [nom du projet] à un audit ou une revue qualité menée par [auditeur : audit interne, client, certificateur, direction] le [date]. Périmètre annoncé de la revue : [ce qui sera examiné]. État réel du projet : [forces et faiblesses connues, documents à jour ou non]. Enjeu : [ce qui se joue : poursuite du financement, confiance client, certification].

Organise la préparation : le dossier de référence à constituer (cadrage, décisions, suivi des risques, comptes rendus, éléments budgétaires) avec la liste de ce qui est probablement manquant ou obsolète à remettre à niveau en priorité, les questions que l'auditeur posera très probablement sur ce type de projet, et pour chaque point faible connu la position honnête à tenir : le reconnaître, montrer qu'il est identifié et piloté, présenter le plan d'action daté.

Contraintes : ne jamais maquiller un document ni antidater quoi que ce soit, un point faible assumé avec un plan crédible passe mieux qu'une façade qui craque en entretien ; briefer les personnes qui seront interrogées sur les faits, pas sur des éléments de langage. Livre : la checklist du dossier, les questions probables avec les réponses préparées, et le planning de préparation à rebours.