Bien rédiger un prompt : le guide complet du débutant à l'expert

Quand la réponse d'un modèle déçoit, le premier réflexe est d'accuser le modèle. C'est presque toujours une erreur de diagnostic. Dans la grande majorité des cas, la requête ne contenait tout simplement pas assez d'information pour que la réponse attendue soit la plus probable.

Ce guide part des bases et va jusqu'aux techniques documentées par la recherche. Il contient aussi un avertissement : le conseil le plus répandu sur le prompt engineering, celui qu'on retrouve dans à peu près tous les articles francophones sur le sujet, est en train de devenir faux. Nous y venons.

Ce que « prompter » veut dire réellement

Un modèle de langage ne reçoit pas votre requête comme un ordre. Il la reçoit comme un début de texte, et il produit la suite la plus vraisemblable compte tenu de ce début.

Cette nuance change tout. Vous ne commandez pas une machine, vous installez un contexte. Un prompt qui commence par « Rédige-moi un truc sur la cybersécurité » ouvre un espace de suites possibles immense, dont la plupart sont médiocres. Un prompt qui pose un métier, une situation, une contrainte et un format réduit cet espace à une zone où presque toutes les suites sont correctes.

D'où la règle qui sous-tend tout le reste : votre travail n'est pas de demander, mais de restreindre.

Le socle : cinq éléments, dans le bon ordre

La structure ci-dessous n'a rien de magique, mais elle a le mérite de couvrir ce qu'un modèle ne peut pas deviner.

1. Le rôle — la posture à adopter. « Tu es auditeur en sécurité applicative, habitué aux audits ISO 27001. »
2. Le contexte — la situation et l'enjeu. « Nous sommes une PME de 40 personnes, nous lançons une application bancaire en SaaS, l'audit est prévu dans six semaines. »
3. L'objectif — la tâche exacte. « Liste les vulnérabilités à contrôler en priorité. »
4. Le format — la forme attendue. « Un tableau : risque, impact métier, mesure corrective, effort estimé. »
5. Les contraintes — ce qui doit être évité. « Reste sur des mesures applicables sans recruter. Pas de généralités. »

Comparez avec la version courte, « Donne-moi les failles de sécurité à surveiller ». Les deux requêtes portent sur le même sujet. Une seule permet au modèle de savoir ce qui compte pour vous.

Un détail qui a son importance : le contexte est ce que les utilisateurs omettent le plus souvent, alors que c'est presque toujours l'élément le plus rentable. Le modèle ignore tout de votre secteur, de votre niveau, de votre lecteur final et de vos contraintes. Rien de tout cela n'est déductible de la question.

Les exemples : la technique la plus sous-estimée

Montrer vaut mieux que décrire. Plutôt que d'expliquer le ton que vous voulez, donnez une à trois paires entrée/sortie. C'est ce qu'on appelle le few-shot prompting, une capacité mise en évidence dès la publication de GPT-3 en 2020.

Reformule les messages d'erreur techniques pour un utilisateur non technique.

Entrée : "Erreur 404 sur la route /api/users"
Sortie : La page demandée est introuvable. Vérifiez l'adresse saisie.

Entrée : "Connection timeout after 30s on db-primary"
Sortie : Le service met trop de temps à répondre. Réessayez dans un instant.

Entrée : "TLS handshake failed: certificate expired"
Sortie :

Deux exemples suffisent souvent à transmettre un registre de langue, une longueur cible et un niveau de détail qu'un paragraphe d'instructions ne rendrait qu'imparfaitement.

Attention toutefois à un piège rarement mentionné. Une étude primée à la conférence ACL 2022 a montré que la simple permutation de l'ordre des exemples peut faire varier la performance de près de 30 points de pourcentage sur certaines tâches de classification. Le même prompt, les mêmes exemples, un ordre différent : d'un résultat proche de l'état de l'art à un résultat proche du hasard.

En pratique, cela donne deux réflexes utiles. Ne groupez pas vos exemples par catégorie (tous les cas positifs puis tous les négatifs), alternez-les. Et si un prompt few-shot donne des résultats instables, testez un autre ordre avant de conclure que la technique ne fonctionne pas.

Le raisonnement pas-à-pas, et pourquoi ce conseil vieillit mal

Voici le point où la plupart des guides sont restés bloqués en 2023.

En 2022, deux publications ont marqué le domaine. Wei et ses coauteurs, chez Google, ont montré qu'en glissant des exemples de raisonnement détaillé dans le prompt, le taux de résolution de PaLM 540B sur le jeu de problèmes mathématiques GSM8K passait de 18 % à 57 %. La même année, Kojima et ses coauteurs découvraient qu'une seule phrase ajoutée à la requête, « Réfléchissons étape par étape », faisait bondir InstructGPT de 10,4 % à 40,7 % sur ce même jeu de données, sans le moindre exemple.

Ces chiffres sont spectaculaires, et ils expliquent pourquoi « demande au modèle de raisonner étape par étape » est devenu le conseil universel.

Sauf que ces résultats ont été obtenus sur des modèles qui ne raisonnaient pas d'eux-mêmes. Depuis, une nouvelle génération est apparue : les modèles dits de raisonnement, qui produisent une chaîne de réflexion interne avant de répondre. Leur demander de réfléchir étape par étape revient à leur demander de faire ce qu'ils font déjà.

Le Wharton Generative AI Labs a mesuré l'effet sur GPQA Diamond, un jeu de 198 questions de niveau doctorat en biologie, physique et chimie. Sur les modèles classiques, le gain reste réel : environ 13,5 % pour Gemini Flash 2.0 et 11,7 % pour Sonnet 3.5. Sur les modèles de raisonnement, il s'effondre : 2,9 % pour o3-mini, 3,1 % pour o4-mini, et une dégradation de 3,3 % pour Gemini Flash 2.5. Le tout en allongeant les temps de réponse de 20 à 80 %.

La règle pratique tient en une phrase : demandez le raisonnement explicite aux modèles classiques, donnez seulement l'objectif final aux modèles de raisonnement. Sur ces derniers, empiler les instructions de méthode nuit plus qu'elle n'aide.

Structurer les prompts longs

Dès qu'un prompt dépasse une dizaine de lignes et mélange consignes, données et exemples, la frontière entre ces blocs devient floue pour le modèle. Il arrive alors qu'il traite une partie de vos données comme une instruction, ou l'inverse.

La parade recommandée par Anthropic dans sa documentation consiste à baliser explicitement les sections :

<contexte>
Rapport financier du T3 2026, périmètre France.
</contexte>

<donnees>
[le tableau à analyser]
</donnees>

<consignes>
Identifie les trois écarts les plus significatifs par rapport au T2.
Chiffre chaque écart en pourcentage.
</consignes>

<format>
Trois puces, une phrase par puce, ton factuel.
</format>

Les noms de balises n'ont aucune importance particulière : aucun n'est privilégié à l'entraînement. Ce qui compte, c'est la cohérence, et le fait de pouvoir renvoyer à une section par son nom dans la suite du prompt.

Reste la question de la position. Liu et ses coauteurs ont mis en évidence un phénomène qu'ils ont baptisé lost in the middle : la performance d'un modèle suit une courbe en U selon l'endroit où se trouve l'information utile dans un long contexte. Elle est bonne au début, bonne à la fin, et se dégrade nettement au milieu. Le constat vaut y compris pour les modèles explicitement conçus pour les longs contextes, et il s'aggrave à mesure que le contexte s'allonge.

Conséquence directe pour vous : ne noyez pas votre consigne principale au centre d'un long document. Placez-la en tête, et redonnez la contrainte la plus critique en toute fin de prompt. Cette répétition apparente n'est pas une maladresse de rédaction, c'est une compensation d'un biais mesuré.

Les erreurs qui coûtent le plus cher

La consigne négative. Écrire « ne parle pas de tarifs » place le mot « tarifs » au cœur du contexte. Les modèles gèrent mal la négation isolée, et la consigne se retourne parfois contre vous. Préférez systématiquement la formulation positive : « limite-toi aux aspects fonctionnels ».

Le flou quantitatif. « Fais un résumé court » n'engage à rien. « Résume en 80 mots maximum, en trois phrases » donne une cible vérifiable. Le corollaire : si vous ne pouvez pas vérifier objectivement que la consigne a été suivie, elle est probablement trop vague pour être suivie.

L'empilement de contraintes contradictoires. « Sois exhaustif mais concis, technique mais accessible » ne produit pas un compromis intelligent, mais un texte mou. Choisissez, ou hiérarchisez explicitement : « privilégie la concision, quitte à omettre les cas particuliers ».

Le contexte implicite. Votre interlocuteur ne connaît ni votre entreprise, ni la conversation d'hier, ni le document que vous avez sous les yeux. Tout ce qui n'est pas dans le prompt n'existe pas.

Le prompt à rallonge. Ajouter des instructions ne compense pas un objectif mal défini. Au-delà d'un certain point, chaque consigne supplémentaire dilue les précédentes. Quand un prompt gonfle sans s'améliorer, c'est en général qu'il faut le réécrire, pas l'allonger.

Itérer comme un ingénieur

C'est ici que se joue la différence entre l'amateur et le professionnel, et elle n'a rien à voir avec la connaissance des techniques.

Ne changez qu'une variable à la fois. Modifier simultanément le rôle, le format et deux contraintes, puis constater que « c'est mieux », n'apprend rien de réutilisable.

Constituez un mini jeu de test. Cinq à dix cas représentatifs, dont deux ou trois cas difficiles, suffisent. Repassez-les à chaque révision du prompt. Sans cela, vous optimisez sur le dernier exemple que vous avez sous les yeux, et vous régressez sans le voir.

Versionnez vos prompts. Un prompt qui fonctionne est un actif. Gardez-le dans un fichier, avec une note sur ce qu'il produit et sur le modèle pour lequel il a été calibré. Un prompt ajusté pour un modèle donné ne se transpose pas mécaniquement à un autre.

Testez la variabilité. Relancez deux fois la même requête. Si les deux réponses divergent fortement, le prompt laisse trop de latitude : il manque une contrainte de format ou de périmètre.

Un prompt complet, commenté

Voici à quoi ressemble une requête aboutie, sur une tâche courante.

Tu es responsable éditorial d'un média spécialisé en cybersécurité,
habitué à vulgariser pour des dirigeants non techniques.

<contexte>
Notre lectorat est composé de dirigeants de PME françaises.
Ils connaissent l'existence du phishing mais pas ses variantes.
Article destiné à la newsletter hebdomadaire.
</contexte>

<tache>
Rédige l'introduction d'un article sur le spear phishing.
</tache>

<format>
- 120 à 150 mots
- Ouvre sur une situation concrète, pas sur une définition
- Une seule notion technique introduite, expliquée en passant
- Termine par la question à laquelle l'article répondra
</format>

<contraintes>
Vocabulaire accessible sans être condescendant.
Aucune statistique chiffrée : nous ne les avons pas encore validées.
</contraintes>

Chaque bloc y neutralise une source d'ambiguïté : le registre, le niveau du lecteur, la longueur, la structure d'attaque, et une interdiction précise qui évitera de devoir tout reprendre. La dernière contrainte mérite d'être soulignée : interdire au modèle d'inventer des chiffres est probablement la consigne la plus rentable qui soit en contexte éditorial.

Ce qui change, et ce qui restera

Une partie des techniques présentées ici a une durée de vie limitée. Le pas-à-pas explicite en est l'illustration : indispensable en 2022, contre-productif aujourd'hui sur les modèles de raisonnement. D'autres astuces disparaîtront à mesure que les modèles deviendront moins sensibles à la formulation.

Ce qui ne changera pas, c'est le fond du problème. Un modèle ne peut pas produire une réponse pertinente pour un contexte qu'il ignore, ni respecter un critère de qualité que personne n'a formulé. Cette part du travail ne s'automatisera pas, parce qu'elle consiste précisément à savoir ce que l'on veut.

Le meilleur exercice reste d'ailleurs le plus simple : avant d'écrire quoi que ce soit, essayez de formuler en une phrase à quoi ressemblerait une réponse parfaite. Si vous n'y arrivez pas, aucun prompt ne vous sauvera.

---

Sources

• Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, NeurIPS 2022 — arxiv.org/abs/2201.11903
• Kojima et al., Large Language Models are Zero-Shot Reasoners, NeurIPS 2022 — arxiv.org/abs/2205.11916
• Lu et al., Fantastically Ordered Prompts and Where to Find Them, ACL 2022 — aclanthology.org/2022.acl-long.556
• Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2023 — arxiv.org/abs/2307.03172
• Wharton Generative AI Labs, The Decreasing Value of Chain of Thought in Prompting — gail.wharton.upenn.edu
• Anthropic, Use XML tags to structure your prompts — docs.anthropic.com