Prompts qui fonctionnent.

Le prompt comme spécification

Quand un informaticien écrit une fonction, il définit la signature (paramètres d'entrée, type de retour), le comportement attendu, les cas limites. Un prompt fonctionne pareil. Vous spécifiez à un système non-déterministe ce qu'il doit faire, ce qu'il doit éviter, et la forme de la sortie. Plus la spécification est précise, plus la variabilité d'une exécution à l'autre diminue.

Ce changement de regard explique pourquoi les prompts courts (« écris-moi un mail à mon chef ») donnent des résultats médiocres et pourquoi les prompts structurés donnent des résultats utilisables au premier essai.

La structure de base, cinq éléments

Le squelette qui couvre 90 % des cas, dans l'ordre :

1. Rôle. Le persona du modèle, qui calibre le ton, le vocabulaire, le niveau de profondeur. « Tu es un relecteur scientifique d'une revue en sciences de l'éducation. »
2. Contexte. Ce que le modèle ne peut pas deviner : qui vous êtes, à quoi sert la sortie, qui la lira. « Je rédige une note d'orientation pour un comité de direction non spécialiste. »
3. Tâche. Le verbe d'action et son objet. « Reformule le résumé suivant pour le rendre accessible à un lecteur non technique sans en diluer le contenu. »
4. Contraintes. Limites de longueur, ton à éviter, vocabulaire interdit, sources autorisées. « Pas plus de 200 mots, pas de jargon technique, garde les chiffres tels quels, n'invente aucune donnée. »
5. Format de sortie. La forme attendue : paragraphe, liste, tableau Markdown, JSON, code source. « Réponds en deux paragraphes, le premier descriptif, le second justifiant la méthode. »

Few-shot, montrer plutôt que dire

Les modèles apprennent en contexte. Si vous voulez une sortie avec un style très particulier (format de table, ton spécifique, niveau de détail), donner deux ou trois exemples est souvent plus efficace que dix phrases de consignes. C'est ce qu'on appelle le few-shot prompting.

Voici trois exemples du format que j'attends.

Entrée : « Le pain est trop dur. »
Sortie : { "categorie": "qualite_produit", "urgence": 2 }

Entrée : « Vous m'avez livré la mauvaise commande. »
Sortie : { "categorie": "erreur_livraison", "urgence": 4 }

Entrée : « Bonjour, pouvez-vous me confirmer mon RDV ? »
Sortie : { "categorie": "demande_info", "urgence": 1 }

Maintenant, classifie cette entrée :
Entrée : « Mon paquet n'est jamais arrivé et c'est urgent. »
Sortie :

Le modèle infère le format JSON, l'échelle d'urgence et les catégories possibles à partir des exemples. Aucune consigne explicite n'a été nécessaire.

Chain-of-thought, forcer le raisonnement explicite

Pour les tâches qui demandent du raisonnement (problèmes de logique, calcul, analyse en plusieurs étapes), demander explicitement au modèle de raisonner étape par étape avant de conclure améliore drastiquement la qualité de la réponse finale. Les modèles modernes le font spontanément, mais on peut renforcer :

Avant de répondre, déroule ton raisonnement explicitement,
en numérotant chaque étape. À la fin seulement, donne ta
réponse précédée du marqueur « RÉPONSE : ».

Les modèles dits « de raisonnement » (Claude Opus avec extended thinking, GPT-5 avec mode reasoning) font cette étape en interne avant d'écrire leur réponse. Pour les modèles plus légers, le prompt explicite reste un levier réel.

Auto-critique, faire relire la sortie

Un modèle est souvent capable de détecter ce qui ne va pas dans sa propre sortie, à condition qu'on le lui demande explicitement. Pattern en deux temps :

1. Demander la production normale.
2. Demander une auto-critique structurée : « Relis ta réponse. Liste trois points qui peuvent être améliorés, expliqués brièvement. Puis réécris la version finale en intégrant ces corrections. »

Le gain de qualité est mesurable, sans changement de modèle. Particulièrement efficace pour la rédaction longue et la revue de code.

Itérer sans repartir de zéro

La première réponse est rarement la bonne. Plutôt que de relancer le prompt entier, on continue la conversation par instructions ciblées. Trois mouvements utiles :

• Préciser un point : « Le paragraphe 2 est trop générique, ajoute deux exemples concrets tirés du milieu hospitalier. »
• Resserrer : « Coupe de moitié. Garde seulement ce qui apporte une information factuelle. »
• Challenger : « Critique ta propre proposition. Quels sont ses trois angles morts ? »

Si après trois itérations vous n'êtes pas satisfait, recommencer une session fraîche avec un prompt revu est plus efficace que de continuer à corriger : le contexte s'est alourdi de tentatives ratées qui parasitent le modèle.

Anti-patterns fréquents

• « Sois créatif. » Vide de sens. Préciser quelle dimension de la création vous voulez : original, décalé, humoristique, métaphorique, structurel.
• « Fais-moi quelque chose de bien. » Sans critère explicite, le modèle livre la moyenne statistique de son entraînement, c'est-à-dire du générique.
• Demander la perfection en un coup. Plus rentable : demander une version brute, puis itérer.
• Empiler les consignes contradictoires (« soit bref mais détaillé, sérieux mais amusant »). Le modèle moyenne, donc rate les deux. Hiérarchiser.
• Demander des sources et accepter ce qui sort. Les références produites sans recherche en ligne sont très souvent inventées. Vérifier systématiquement.
• Continuer une session qui dérive. Quand le modèle commence à répéter ou à se contredire, ouvrir une nouvelle conversation.

Bibliothèque de prompts validés

Dix prompts utilisés et améliorés en pratique, classés par usage. Cliquer pour afficher.

Tu es éditeur dans une revue à comité de lecture en [DISCIPLINE].
Voici un article (collé ci-dessous, avec son abstract et son texte intégral).

Produis une synthèse opérationnelle en quatre paragraphes :
1. Question de recherche et cadre théorique en deux phrases.
2. Méthode : population, design, mesures principales.
3. Résultats : ce qui est démontré, en citant les statistiques clés.
4. Limites mentionnées par les auteurs et angles morts que tu identifies.

Contraintes :
- 350 mots maximum.
- Pas de jargon évitable pour un lecteur d'une discipline voisine.
- Tu ne dois rien inventer. Si un élément n'apparaît pas dans le texte,
  écris « non précisé dans l'article ».
- Cite les passages exacts (entre guillemets) pour les conclusions
  principales.

[ARTICLE]

Tu es un médiateur scientifique habitué à parler à des étudiants de
licence sans prérequis dans ta discipline.

Reformule le texte ci-dessous pour qu'il soit compris sans diplôme
préalable, en gardant l'exactitude technique. Évite les analogies
décoratives qui dégradent la précision. Quand un concept ne peut pas
être simplifié sans le trahir, garde-le tel quel et explique-le en
une phrase entre parenthèses.

Sortie en trois paragraphes maximum. Pas de listes. Pas de questions
rhétoriques.

[TEXTE]

Tu es chargé de mission, expert en synthèse de réunion.

Voici la transcription brute d'une réunion (collée ci-dessous).
Produis un compte-rendu structuré :

## Décisions actées
Liste à puces, une ligne par décision.

## Actions à mener
Tableau Markdown : | Action | Responsable | Échéance |

## Points en suspens
Liste à puces, ce qui doit revenir à la prochaine réunion.

## Citations marquantes
Deux ou trois citations exactes utiles pour la mémoire collective,
attribuées à leur auteur.

Contraintes :
- Reste neutre, pas d'opinion.
- Ne reformule pas les citations.
- Si une action n'a pas de responsable identifié, écris « à
  attribuer » plutôt que d'inventer.

[TRANSCRIPTION]

Tu es un développeur senior chargé d'une revue de code stricte.

Voici une fonction (langage : [LANGAGE]). Analyse-la sous quatre angles :

1. Correction : la fonction fait-elle ce que son nom et sa
   documentation suggèrent ? Cas limites manqués ?
2. Sécurité : entrées non validées, injections possibles, secrets
   en clair ?
3. Lisibilité : noms ambigus, complexité excessive, commentaires
   manquants ou redondants ?
4. Performance : appels coûteux dans une boucle, allocations
   inutiles, complexité algorithmique disproportionnée ?

Pour chaque angle, donne un verdict (OK / À améliorer / Critique)
suivi des points précis. Termine par une version corrigée, en
diff Markdown.

[CODE]

Tu es enseignant en [DISCIPLINE], formé à la
pédagogie active.

Conçois un plan de cours sur le sujet : [SUJET], pour deux séances
de deux heures, devant un groupe de [NIVEAU].

Pour chaque séance, fournis :
- Objectifs d'apprentissage opérationnels (verbes d'action).
- Plan détaillé minute par minute.
- Une activité interactive (jeu de rôle, étude de cas, débat
  encadré, exercice collaboratif), pas seulement de l'exposé magistral.
- Une question d'évaluation formative en fin de séance.
- Une lecture obligatoire pour la séance suivante.

Si une activité ne peut pas être réalisée dans le temps imparti,
indique-le et propose une variante plus courte.

Tu es consultant senior chargé d'un audit critique.

Voici un projet que j'envisage : [DESCRIPTION].

Imagine qu'on est dans douze mois et que le projet a échoué.
Décris les cinq causes les plus probables de cet échec, classées
par probabilité, en distinguant :
- causes externes (marché, contexte, partenaires)
- causes internes (équipe, ressources, décisions clés)
- causes méthodologiques (cadrage, mesure, itération)

Pour chaque cause, propose une mesure de mitigation concrète à
mettre en place avant le démarrage.

Sois impitoyable. Le but est de blinder le projet, pas de me
rassurer.

Tu es chef de service expérimenté en communication interne.

Contexte : [DÉCRIRE LA SITUATION DÉLICATE, par exemple : annonce
d'une réorganisation, refus d'une demande, recadrage d'un
collaborateur].

Rédige un email :
- Ton : professionnel, respectueux, ferme sans agressivité.
- Structure : reconnaissance du contexte / décision claire en deux
  phrases / justification factuelle / ouverture (suite, recours,
  contact).
- Pas de formules creuses (« suite à », « par la présente »).
- Pas de paragraphe « bouche-trou » qui dilue le message.
- Longueur : 180 mots maximum.

Termine par une signature neutre [PRÉNOM NOM, FONCTION].

Tu es analyste documentaire. Voici un document long (rapport,
note interne, transcription). Extrais les informations dans le
format JSON suivant :

{
  "titre": "...",
  "date": "AAAA-MM-JJ",
  "auteurs": ["..."],
  "resume_30_mots": "...",
  "decisions": ["...", "..."],
  "chiffres_cles": [{"valeur": "...", "contexte": "..."}],
  "personnes_citees": ["..."],
  "actions_a_suivre": [{"action": "...", "responsable": "...", "echeance": "..."}],
  "points_d_attention": ["..."]
}

Si un champ n'apparaît pas dans le document, mets une chaîne
vide. N'invente jamais.

[DOCUMENT]

Tu es éducateur spécialisé, formé à la communication adaptée
pour des enfants présentant un trouble du spectre de l'autisme,
des troubles dys, ou des troubles du langage.

Reformule l'explication suivante pour un enfant de [ÂGE]
présentant [PROFIL].

Contraintes opérationnelles :
- Phrases courtes (10 à 12 mots maximum).
- Une idée par phrase.
- Pas de figure de style, pas d'ironie, pas de double sens.
- Vocabulaire concret. Si un mot abstrait est nécessaire,
  remplacer par sa contrepartie concrète.
- Si possible, proposer une représentation visuelle simple
  (« on dessine un… »).

[EXPLICATION INITIALE]

Tu es rédacteur technique habitué aux rapports institutionnels.

Réécris le texte ci-dessous en respectant les standards d'un
rapport institutionnel :
- Voix passive et tournures impersonnelles uniquement quand elles
  sont justifiées ; voix active sinon.
- Une idée par paragraphe.
- Définition des sigles à la première occurrence.
- Conditionnel pour les hypothèses, indicatif pour les faits.
- Pas d'adjectifs évaluatifs sans donnée d'appui.
- Bibliographie en fin de paragraphe quand une affirmation
  factuelle est avancée.

[TEXTE]

Mesurer si un prompt fonctionne

Pour les usages récurrents, un prompt « qui marche bien » n'est pas une intuition, c'est une mesure. Trois manières simples :

• Banc de test maison. Cinq à dix entrées types avec leur sortie idéale écrite à la main. Lancer le prompt sur les cinq, comparer manuellement.
• Notation entre deux versions. Quand on modifie un prompt, lancer l'ancienne et la nouvelle version sur les mêmes entrées, comparer. Garder la meilleure.
• Évaluation par un autre modèle. Demander à un second modèle « voici une consigne et deux sorties, laquelle répond le mieux à la consigne et pourquoi ? ». Utile à l'échelle, à condition de croiser avec un avis humain régulier.