Le prompting précis est une spécification du contexte
20 juin 2026 · 10 min de lecture
Résumé
Il existe une checklist bien connue pour débuter en prompting : définir la tâche, le public, le ton, le rôle, le contexte, les contraintes, les exemples et le format de sortie. Elle est utile. Mais elle ne suffit pas.
Mon hypothèse est la suivante : le prompting précis consiste de moins en moins à remplir une checklist universelle, et de plus en plus à choisir les détails qui comptent réellement pour un modèle, une tâche, un workflow, un niveau de risque et une méthode d'évaluation donnés. Autrement dit, la précision d'un prompt n'est pas sa longueur. C'est son adéquation.
Cet article passe en revue des guides pratiques d'OpenAI, Anthropic et Microsoft, ainsi que des travaux académiques sur les taxonomies de prompting, les prompt patterns, l'optimisation automatique des prompts, les tâches de génie logiciel et le context engineering. Les sources pointent dans la même direction : les détails utiles dans un prompt varient fortement selon le contexte. Un prompt pour extraire du JSON structuré n'a pas besoin des mêmes éléments qu'un prompt pour une synthèse juridique, une interface frontend, du tutorat, un agent avec outils ou une correction de code.
La thèse reste une hypothèse de travail. Mais elle est déjà très pratique.
Le problème de la checklist de prompting
La plupart des personnes qui utilisent des LLMs depuis plus de quelques semaines connaissent les conseils de base.
Dites au modèle ce que vous voulez. Donnez-lui un rôle. Précisez le public. Définissez le ton. Ajoutez des exemples. Indiquez le format de sortie. Ajoutez éventuellement des contraintes.
Ce n'est pas faux. C'est un bon point de départ. Mais quand j'ai commencé à utiliser des LLMs pour m'aider à écrire des prompts plus détaillés, j'ai remarqué quelque chose d'un peu agaçant et assez intéressant : la liste des détails utiles changeait sans cesse.
Pour une revue de littérature, les détails décisifs étaient la hiérarchie des sources, le style de citation, le langage de l'incertitude et la séparation entre preuve et interprétation.
Pour une tâche frontend, les détails décisifs étaient le comportement responsive, le design system existant, les états d'interaction, l'accessibilité et les assets visuels.
Pour un workflow agentique, les détails décisifs étaient les permissions d'outils, les limites d'approbation, les critères d'arrêt, les étapes de vérification et l'état à préserver.
Même mot : "prompt". Objet d'ingénierie très différent.
Le problème n'est donc pas de savoir si un prompt doit contenir "plus de détails". La question est trop grossière. La meilleure question est :
Quels détails sont opérationnellement pertinents pour cette tâche ?
J'appellerais opérationnellement pertinent un détail dont l'ajout change la probabilité que le modèle produise un résultat acceptable.
C'est un peu formel, mais important. Un long prompt peut rester vague. Un prompt court peut être précis. La différence est de savoir si le prompt nomme les variables qui orientent réellement le modèle.
Comment j'ai regardé les sources
Il s'agit d'une revue narrative, pas d'une étude benchmark. J'ai cherché des sources couvrant cinq angles :
| Type de source | Exemples | Pourquoi c'est utile |
|---|---|---|
| Documentation des fournisseurs | OpenAI, Anthropic, Microsoft | Montre comment les conseils changent selon le modèle, le workflow et le format attendu |
| Taxonomies de prompting | The Prompt Report et surveys associés | Montre que le prompting est un grand espace de conception |
| Prompt patterns | White et al. | Traite les prompts comme des patterns réutilisables, mais à adapter |
| Optimisation et études empiriques | APE, études sur le code | Montre que les détails peuvent être testés et améliorés contre des résultats |
| Context engineering | Surveys récents | Déplace le sujet de la formulation vers tout le contexte fourni |
L'objectif n'était pas de prouver que tous les prompts doivent être complexes. Au contraire. La proposition utile est plus étroite : les bons détails dépendent du travail que le prompt doit faire.
Ce que la documentation des fournisseurs implique déjà
Les guides actuels d'OpenAI sur le prompt engineering et la génération de prompts montrent bien les deux côtés du problème. Il existe des conseils généraux, mais les recommandations deviennent vite spécifiques au type de sortie. Le guide de génération de prompts traite par exemple le type de sortie, les schémas, les exemples, l'ordre raisonnement-conclusion, les constantes et la complexité de la tâche comme des variables à examiner, pas comme un modèle fixe [1][2].
Anthropic insiste encore plus clairement sur les critères de succès. Sa vue d'ensemble du prompt engineering indique qu'avant d'améliorer un prompt, il faut définir les critères de réussite, avoir un moyen de tester ces critères et disposer d'un premier brouillon de prompt [3]. C'est discret, mais important. Le prompting devient une itération vers une cible, pas une formule magique.
Les bonnes pratiques d'Anthropic distinguent ensuite de nombreuses situations : exemples, structure XML, rôles, long contexte, format de sortie, outils, thinking, systèmes agentiques, frontend, migration entre versions de modèles, etc. [4]. Cela ressemble moins à une formule unique qu'à une carte de surfaces de contrôle différentes selon la tâche.
La documentation Microsoft Azure OpenAI ajoute une mise en garde utile : la construction de prompts est davantage un art qu'une science, et les modèles se comportent différemment [5]. Je ne le vois pas comme une excuse pour être approximatif. Je le vois comme une raison de tester les prompts au lieu de les sacraliser.
| Signal | Ce qu'il suggère |
|---|---|
| OpenAI sépare tâche, sortie, schéma et exemples | Les détails doivent être choisis selon le résultat attendu |
| Anthropic commence par des critères de succès et des tests | Un prompt est une hypothèse sur ce dont le modèle a besoin |
| Anthropic traite séparément long contexte, outils, agents et frontend | Le "bon prompting" dépend du workflow |
| Microsoft rappelle que les modèles diffèrent | La précision dépend aussi du modèle |
La littérature rend visible l'espace de conception
Le soutien académique le plus fort vient de l'ampleur même du champ.
The Prompt Report recense 58 techniques de prompting pour les LLMs et 40 techniques pour d'autres modalités [6]. Ce n'est pas une fiche de conseils pour débutants. C'est le signe que le mot "prompting" couvre de nombreux problèmes différents.
Le catalogue de prompt patterns de White et al. est utile pour une autre raison [7]. Il traite les prompts comme des patterns logiciels : des solutions réutilisables à des problèmes récurrents dans un contexte particulier. Cette dernière précision est essentielle. Un pattern est réutilisable, mais il n'est pas hors contexte.
Automatic Prompt Engineer va encore plus loin. Zhou et al. traitent les instructions comme des candidats qui peuvent être générés, scorés et sélectionnés selon la performance sur une tâche [8]. C'est un modèle mental très différent de "bien écrire un prompt". La qualité dépend de la tâche, de la fonction de score et de l'espace de recherche.
L'étude de Shin et al. sur le génie logiciel va dans le même sens. Elle compare prompting simple, in-context learning et prompting spécifique à la tâche pour la génération, le résumé et la traduction de code. Le prompt engineering ne domine pas toujours le fine-tuning, et le prompting conversationnel s'améliore lorsque des humains ajoutent contexte, feedback et instructions spécifiques [9].
C'est aussi ce que l'on observe en pratique. On découvre ce qui manque au prompt en regardant le modèle échouer.
Les détails changent avec la tâche
Voici la version pratique de l'argument.
| Contexte de tâche | Détails souvent importants |
|---|---|
| Synthèse de documents longs | Hiérarchie des sources, règles de citation, métadonnées, conflits, politique de citation |
| Génération de code | Conventions du repo, fichiers cibles, tests, architecture, dépendances, contraintes de sécurité |
| Frontend | Design system, responsive, états d'interaction, accessibilité, assets visuels |
| Analyse juridique ou policy | Juridiction, date, niveau d'autorité, incertitude, qualité des sources, limites d'escalade |
| Extraction structurée | Schéma, valeurs autorisées, règles pour null, validation, cas limites |
| Tutorat | Niveau de l'apprenant, erreurs probables, rythme, style de feedback, moments pour questionner |
| Agents avec outils | Permissions, règles d'approbation, critères d'arrêt, commandes de vérification, audit |
| Travail créatif | Genre, public, voix, exemples négatifs, contraintes, critères de nouveauté |
Une checklist générique dirait : "ajoutez du contexte". D'accord. Mais dans un codebase, le contexte peut être l'architecture locale et la commande de test. Dans une synthèse juridique, il peut s'agir de la juridiction et de la date du texte. Dans une extraction, il peut s'agir du schéma et du traitement des champs absents.
Le mot est le même. Le tableau de détails ne l'est pas.
La précision n'est pas la verbosité
C'est là que beaucoup de discussions sur le prompting dérapent un peu.
On entend "soyez précis" et on traduit par "ajoutez plus d'instructions". Parfois cela aide. Souvent, cela produit surtout un prompt plus long, avec plus de risques de contradictions.
La meilleure définition est :
Le prompting précis consiste à choisir le contexte, les contraintes, les exemples et les critères d'évaluation pertinents pour la tâche, ceux qui modifient réellement le comportement du modèle.
Cette définition sépare précision et longueur.
Un prompt qui dit "écris avec un ton professionnel pour un public général" n'est pas précis si le vrai problème est la fidélité des citations. Un prompt qui dit "extrais les claims en JSON avec claim, source_quote, confidence et needs_verification; utilise null si la source ne dit rien" peut être précis, même s'il est court.
Le premier est poli. Le second change le comportement.
Le context engineering comme cadre plus large
La littérature récente sur le context engineering formule le même point à plus grande échelle. Mei et al. décrivent le context engineering comme l'optimisation du paquet d'information fourni à un LLM : retrieval, traitement du contexte, mémoire, outils, RAG, raisonnement avec outils et systèmes multi-agents [10].
Le terme peut devenir flou s'il est trop à la mode. Mais l'idée centrale est utile : le prompt visible de l'utilisateur n'est qu'une partie de la fenêtre de contexte.
Dans une application LLM sérieuse, le modèle peut aussi recevoir :
- instructions système
- instructions développeur
- documents récupérés
- mémoire
- définitions d'outils
- règles de politique
- préférences utilisateur
- exemples
- schémas
- sorties précédentes
- grilles d'évaluation
Vu sous cet angle, l'ancienne checklist paraît trop petite. Le travail n'est pas seulement de formuler la demande. Il consiste à assembler l'environnement d'information dans lequel le modèle peut réussir.
Un petit modèle de prompting précis
Les sources suggèrent un modèle de travail simple. Je n'appellerais pas encore cela une théorie. Plutôt un échafaudage pratique.
| Couche | Question | Exemple |
|---|---|---|
| Alignement tâche | Qu'est-ce qui rend la sortie correcte ou utile ? | Citer des sources primaires |
| Alignement modèle | De quoi ce modèle a-t-il besoin ? | Demander explicitement les détails frontend |
| Alignement workflow | Quels outils, fichiers ou états sont en jeu ? | Lire les fichiers, demander avant d'écrire |
| Alignement risque | Que se passe-t-il si le modèle agit avec trop d'assurance ? | Marquer l'incertitude juridique |
| Alignement évaluation | Comment vérifier le succès ? | JSON valide, tests réussis, citations vérifiées |
Cela explique aussi pourquoi les LLMs peuvent aider à écrire des prompts. Lorsqu'on leur demande d'améliorer un prompt, ils font souvent remonter des catégories oubliées : cas limites, critères d'évaluation, politique de sources, exemples négatifs, modes d'échec, permissions d'outils.
Mais ces propositions ne sont pas automatiquement justes. Ce sont des détails candidats. Il faut les tester.
Conséquences pratiques
Si vous maintenez une bibliothèque de prompts, ne sauvegardez pas seulement le prompt final. Sauvegardez le type de tâche, le modèle, les critères de succès, les échecs connus et la raison pour laquelle certains détails ont été inclus.
Si vous demandez à un LLM d'améliorer un prompt, ne demandez pas seulement "un meilleur prompt". Demandez-lui d'identifier les catégories de détails susceptibles d'influencer le résultat.
Si un prompt échoue, ne le rendez pas immédiatement plus long. Demandez quel type de contexte manquait.
Certains prompts ont besoin d'exemples. Certains d'un schéma. Certains d'une hiérarchie de sources. Certains d'une politique d'outils. Certains d'une définition de réussite plus nette. Certains ont besoin de moins d'instructions, parce que le modèle se crispe sur vos contraintes.
C'est la partie un peu inconfortable : le bon prompting n'est pas une seule compétence. C'est une famille de petites compétences diagnostiques.
Limites
Cet article est spéculatif au bon sens du terme : il part d'une observation pratique et vérifie si la littérature va dans la même direction. C'est le cas, mais ce n'est pas une expérience contrôlée.
La prochaine étape utile serait d'opérationnaliser les "détails" et de les tester par familles de tâches. Une politique de citation améliore-t-elle davantage une revue de littérature qu'une consigne de ton ? Le détail du schéma compte-t-il plus que les exemples pour l'extraction ? Quels détails se transfèrent entre familles de modèles ?
Ce serait un bon benchmark. Et sûrement un benchmark désordonné, car les vrais prompts combinent beaucoup de détails qui interagissent.
Conclusion
La littérature soutient l'hypothèse : le prompting passe d'une checklist universelle à une spécification contextuelle.
La checklist de départ reste utile. Tâche, public, ton, exemples et format sont de bons défauts. Mais le prompting avancé commence lorsque l'on cesse de demander "de quoi tout prompt a-t-il besoin ?" pour demander "que doit savoir, contraindre, utiliser, éviter et prouver le modèle pour cette tâche ?"
C'est le déplacement important.
Le prompting précis ne consiste pas à ajouter des détails partout. Il consiste à trouver les détails qui changent le résultat.
Références
[1] OpenAI, Prompt engineering, OpenAI API documentation.
[2] OpenAI, Prompt generation, OpenAI API documentation.
[3] Anthropic, Prompt engineering overview, Claude API documentation.
[4] Anthropic, Prompting best practices, Claude API documentation.
[5] Microsoft, Prompt engineering techniques, Microsoft Learn.
[6] S. Schulhoff et al., The Prompt Report: A Systematic Survey of Prompting Techniques, arXiv:2406.06608, 2024.
[7] J. White et al., A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT, arXiv:2302.11382, 2023.
[8] Y. Zhou et al., Large Language Models Are Human-Level Prompt Engineers, arXiv:2211.01910, 2022.
[9] J. Shin et al., Prompt Engineering or Fine Tuning: An Empirical Assessment of Large Language Models in Automated Software Engineering Tasks, arXiv:2310.10508, 2023.
[10] L. Mei et al., A Survey of Context Engineering for Large Language Models, arXiv:2507.13334, 2025.