Le Messager des Mauvaises Nouvelles : Rédigez des Mises à Jour Désagréables Sans Perdre la Confiance
Pourquoi ce prompt est important
How a setback is communicated changes customer and employee retention more than the severity of the setback itself. A vague, hedge-filled message about a delay reads as a signal that something worse is being hidden, which is what actually pushes clients to start quietly evaluating alternatives — even when the underlying relationship was healthy going in. Internally, a rambling, defensive layoff or cancellation announcement is the version of the message that gets forwarded, screenshotted, and remembered for years after the actual decision is forgotten.
À quoi nous l'utilisons
You are a product manager who just learned that the client-facing integration promised for Q1 is being pushed to Q3, because the two engineers who were building it got reassigned last week to an urgent security patch. You have to tell the client's VP of Operations today, by email, before she hears about the delay secondhand from your account executive during tomorrow's renewal call.
Prompt
You are a seasoned [SENIOR MANAGER / INTERNAL COMMUNICATIONS LEAD / TEAM LEAD] who has delivered hundreds of difficult updates — project delays, budget cuts, canceled initiatives, negative decisions — without losing the trust of the people receiving them. CONTEXT: - What happened: [DESCRIBE THE SITUATION PLAINLY — what changed, why, what you already tried before it got to this point] - Who is affected: [DESCRIBE THE AUDIENCE, e.g., "my 6-person engineering team," "an enterprise client who pays for priority support," "the whole company, ~200 people"] - Relationship context: [DESCRIBE THE CURRENT STATE OF TRUST, e.g., "generally strong, this is our first real setback together" or "already strained from a missed deadline last quarter"] TASK — complete all three steps, in order, without skipping the self-critique: Step 1 — DRAFT. Write the message delivering this news. Lead with the actual news in the first two sentences — do not bury it under context or preamble. State the concrete impact on the reader before explaining the cause. Include one specific, concrete next step or remedy, even if the remedy is only partial. Step 2 — SELF-CRITIQUE. Now switch roles. Read your own Step 1 draft as the most skeptical, least charitable person who could receive it. List every sentence that could read as evasive, overly corporate, defensive, or like it is minimizing the problem. Flag any place where the lede was buried or excuses were front-loaded before the actual news. Be specific about which words or phrases trigger each flag — do not just say "tone could be better." Step 3 — REVISE. Produce a final version that fixes every issue flagged in Step 2. Do not introduce new hedging while fixing the old hedging. CONSTRAINTS: - No corporate hedge language: ban phrases like "due to unforeseen circumstances," "moving forward," "we take this seriously," "at this time" - Name the actual cause plainly, even if it is an internal mistake - Apologize at most once, and only if someone on our side is actually at fault - Maximum 2 sentences before the core news is stated - Match this tone/formality: [E.G., "casual Slack message to my own team" OR "formal email to an enterprise client's VP"] - Target length: [E.G., "under 150 words" OR "under 300 words"] OUTPUT FORMAT: 1. Draft v1 (the message) 2. Self-Critique (bulleted list, each bullet quoting the exact flawed phrase and naming the specific problem) 3. Final Revised Version (ready to send as-is)
Résultat
Draft v1:
Subject: Integration Delay — Moving From Q1 to Q3
Hi Sarah,
I need to tell you that the client integration we committed to for Q1 is now going to ship in Q3 instead. Due to an unexpected shift in our engineering priorities, the two engineers assigned to your integration were moved onto a critical security patch last week, and we don't expect to have resources back on your project until April.
We understand this is frustrating and we take this delay seriously. We want to assure you that we remain fully committed to delivering a high-quality integration, and we will keep you updated as things progress. Please let us know if you have any questions, and thank you for your continued patience and partnership.
Best,
[Name]
Self-Critique:
- «Due to an unexpected shift in our engineering priorities» — this is a vague corporate hedge. It never names the actual cause (a security patch pulled the engineers away). Reads as evasive.
- «we take this delay seriously» — banned boilerplate phrase. Adds zero information and signals a template response.
- «We want to assure you that we remain fully committed» — generic reassurance with no concrete action attached. Sounds defensive rather than helpful.
- «we will keep you updated as things progress» — no specific date or mechanism given. Reads as a brush-off, not a commitment.
- «thank you for your continued patience and partnership» — the message closes by asking the client for patience instead of ending on a concrete remedy. This minimizes the real inconvenience to her Q1 plans.
- The actual news (Q1 to Q3) is stated but delayed by «I need to tell you that» throat-clearing — tighten the opening.
- No interim remedy is offered anywhere — the message describes the problem but gives Sarah nothing she can use in the meantime.
Final Revised Version:
Subject: Integration Delay — Moving From Q1 to Q3
Hi Sarah,
Your integration is moving from Q1 to Q3. The two engineers assigned to it were pulled last week onto an urgent security patch for existing customers, and that patch takes priority through April.
I know this affects your own Q1 commitments to your team, so here's what we can do in the meantime: I can get you a working sandbox build of the current integration state by January 15, so your team can start testing against it even though the full release waits until Q3. I'll also set up a bi-weekly 15-minute check-in starting next week so you're not waiting until Q3 to hear anything.
I'm sorry for the disruption this causes on your side — happy to get on a call today if that's more useful than email.
[Name]
La plupart des conseils sur l'annonce de mauvaises nouvelles se concentrent sur le ton : soyez empathique, soyez clair, soyez gentil. Ce conseil est juste et pourtant inutile en lui-même, car les personnes qui rédigent ces messages savent déjà qu'elles doivent paraître empathiques et claires. Ce qui fait réellement dérailler un message difficile, c'est un langage précis et identifiable : la formule d'esquive qui se glisse parce qu'elle semble plus sûre, l'excuse placée avant la nouvelle réelle, la promesse vague de « vous tenir informé » qui n'engage à rien. Ce prompt est conçu pour repérer ces défaillances spécifiques plutôt que de donner un conseil générique sur le ton.
Pourquoi l'étape d'autocritique existe
La plupart des prompts d'écriture par IA s'arrêtent après avoir produit un brouillon. Celui-ci impose une seconde passe où le modèle doit lire sa propre production comme le destinataire le plus sceptique possible et nommer, par écrit, chaque phrase qui ferait que ce destinataire fasse moins confiance au message. Cela fonctionne parce qu'un modèle d'IA qui rédige un message et un modèle d'IA qui critique un message appliquent, fonctionnellement, des critères d'évaluation différents — la passe de rédaction optimise pour « paraître professionnel et complet », tandis que la passe de critique optimise pour « un lecteur sceptique croirait-il cela ». Ces deux critères entrent souvent en conflit, et le langage d'esquive institutionnel est précisément ce qui satisfait le premier tout en échouant au second.
Pourquoi les contraintes interdisent des phrases précises plutôt que des conseils généraux
« En raison de circonstances imprévues », « nous prenons cela très au sérieux » et « à l'avenir » sont interdites nommément plutôt que par catégorie, car les modèles (et les humains) se tournent de manière fiable vers ces phrases exactes lorsqu'on leur demande d'écrire quelque chose de difficile — ce sont les clichés fondamentaux des mauvaises nouvelles institutionnelles. Les interdire nommément force le modèle à trouver les mots réels pour ce qui s'est passé, ce qui est généralement à la fois plus honnête et plus précis que l'esquive qu'il remplace.
Pourquoi useCase et whyItMatters restent séparés
Le cas d'usage décrit un scénario unique et concret — un retard précis, une partie prenante précise, une pression de délai précise. L'argument « pourquoi c'est important » porte sur le coût ultérieur de mal gérer cela en général : la confiance endommagée s'accumule silencieusement, et un revers mal géré cause souvent plus d'attrition que le revers lui-même. Garder ces deux éléments séparés est délibéré — un lecteur doit pouvoir reconnaître sa propre situation dans le cas d'usage tout en comprenant l'enjeu grâce au second champ, sans que les deux se répètent.
Comment l'adapter
Les trois champs entre crochets — rôle, contexte et audience — suffisent pour exécuter ce prompt pour presque tout message professionnel difficile : un délai manqué, une coupe budgétaire, un projet annulé, une évaluation de performance négative, même des excuses personnelles qui doivent rester précises plutôt que génériques. La structure (brouillon, puis autocritique sceptique, puis révision) est la partie réutilisable ; le contenu est la chose difficile que vous devez réellement dire cette semaine.