En bref

La qualité d’une réponse LLM dépend moins du modèle choisi que de ce qu’il reçoit en entrée. La position de l’information dans le prompt, sa spécificité, son format et la présence d’exemplaires changent les résultats de 20 à 47 points selon les études. Ce guide traduit les résultats de la recherche récente en recommandations actionnables, organisées par niveau d’usage : opérateur seul face à un LLM, agent unique configuré par un prompt système, et orchestration multi-agent.

Pourquoi le context prompting reste sous-estimé

La plupart des opérateurs LLM investissent dans le choix du modèle ou dans l’ajout d’outils. Peu investissent dans la structure de ce que le modèle reçoit. C’est un angle mort coûteux.

Une étude systématique sur 14 techniques de prompting, 10 tâches d’ingénierie logicielle et 4 LLM montre qu’aucune technique ne domine universellement (Santana Junior et al., 2025). Le choix de la technique compte moins que son adaptation au contexte de la tâche. Autrement dit : il n’existe pas de “meilleur prompt” générique. Il existe un travail d’ingénierie pour chaque situation.

Ce guide est le volet pratique de l’article Context engineering — au-delà du prompt engineering, qui couvre le cadre conceptuel. Ici, on passe à l’application.

Niveau 1 — Opérateur solo

L’opérateur solo tape un prompt dans une interface conversationnelle. Pas de prompt système, pas d’automatisation. C’est le cas d’usage le plus courant et celui où les gains rapides sont les plus accessibles.

Placer les données avant la question

Le principe le plus documenté de la littérature : positionner l’information utile en début de prompt et la question ou l’instruction en fin. Cette disposition améliore significativement la qualité des réponses sur des entrées complexes multi-documents, selon plusieurs sources industrielles. L’effet est confirmé par l’étude “Lost in the Middle” (Liu et al., TACL 2024) : l’information placée au milieu d’un contexte long subit une dégradation de performance suivant une courbe en U — les modèles exploitent mieux le début et la fin (voir section Lost-in-the-Middle).

Recommandation : coller les données, documents ou extraits de code en premier. Poser la question après. Ne pas intercaler de commentaires entre les données et la requête.

Erreur courante : commencer par “J’ai un problème avec…”, puis décrire le contexte, puis coller les données. Inverser : données d’abord, problème ensuite.

Être spécifique plutôt que long

La spécificité du prompt a un impact supérieur à sa longueur. L’étude DETAIL Matters (2024) mesure un gain de +23 points sur GPT-4 et jusqu’à +47 points sur des tâches mathématiques quand le prompt passe de vague à détaillé. Ce n’est pas la quantité de mots qui compte, mais la précision de l’instruction.

Un prompt spécifique se distingue d’un prompt vague par sa mesurabilité : “Résume en 3 points de 20 mots maximum” est spécifique. “Fais un bon résumé” est vague. Les modèles traitent la spécificité comme un signal de perplexité basse — ils ont moins d’interprétations concurrentes à arbitrer.

Recommandation : avant d’envoyer un prompt, vérifier que chaque instruction pourrait être évaluée objectivement par un tiers. Si une instruction est ambiguë, la reformuler avec des critères mesurables.

Adapter le format au modèle

La variation de performance selon le format du prompt atteint 40 % selon les mesures de He et al. (soumis NAACL 2025). Claude est entraîné avec des balises XML — il les traite nativement comme des délimiteurs structurels. GPT-4 performe mieux avec du Markdown. Les résultats ne sont pas transférables d’une famille de modèles à l’autre (IoU inter-séries < 0.2).

Recommandation : utiliser XML (<context>, <task>) pour Claude, Markdown pour GPT-4, et tester empiriquement pour les autres modèles. Ne pas transposer un prompt optimisé pour un modèle vers un autre sans vérification.

Utiliser le Chain-of-Thought de manière sélective

Le Chain-of-Thought (CoT) — demander au modèle de raisonner étape par étape — est souvent présenté comme universellement bénéfique. La réalité est plus nuancée.

Une méta-analyse sur 100 articles, 14 modèles et 20 jeux de données (Sprague et al., ICLR 2025) conclut que le CoT n’aide significativement que sur les tâches mathématiques et de raisonnement symbolique. Sur d’autres types de tâches, le gain est marginal ou nul. Plus préoccupant : une étude de Princeton et NYU (Liu et al., ICML 2025) montre que le CoT peut dégrader la performance de jusqu’à 36 points sur les tâches d’apprentissage implicite de patterns — exactement les tâches où le raisonnement conscient gêne aussi les humains.

Recommandation : réserver le CoT aux tâches analytiques (calculs, logique, décomposition multi-étapes). Pour la classification, l’extraction d’information ou la rédaction, ne pas forcer le raisonnement explicite — il rallonge la réponse sans l’améliorer.

Erreur courante : ajouter “Réfléchis étape par étape” à tous les prompts par défaut. Ce réflexe peut dégrader les résultats sur les tâches non analytiques.

Niveau 2 — Agent unique

L’agent unique est un LLM configuré par un prompt système persistant. Il reçoit des instructions permanentes, éventuellement des exemplaires et un contexte enrichi. C’est le cas des assistants personnalisés, des bots de support ou des agents de traitement automatisé.

Stabiliser le format avec un seul exemplaire

La sensibilité des LLM au format du prompt est documentée avec précision. L’étude POSIX (Chatterjee et al., EMNLP 2024 Findings) mesure qu’un seul exemplaire de sortie attendue réduit la sensibilité au template de 54 % (score de sensibilité passant de 1.12 à 0.513 sur Llama-2-7b). Les rendements sont décroissants au-delà de deux exemplaires.

Cependant, une nuance s’impose sur les modèles récents. Cheng et al. (2025) montrent que le zero-shot CoT égale ou surpasse le few-shot CoT sur Qwen2.5. L’explication probable : les modèles récents, massivement entraînés par instruction tuning, intègrent déjà les patterns que les exemplaires enseignaient aux modèles antérieurs. Les exemplaires restent utiles pour la consistance du format de sortie, mais n’améliorent plus nécessairement le raisonnement brut sur les modèles de dernière génération.

Recommandation : inclure 1 exemplaire dans le prompt système pour stabiliser le format de sortie. Ne pas en ajouter plus de 2 — le gain marginal est faible et le coût en tokens est réel.

Erreur courante : empiler 5 à 10 exemplaires “au cas où”. Au-delà de 2, l’exemplaire supplémentaire consomme de la fenêtre sans bénéfice mesurable.

Contrôler le budget de tokens

La verbosité des LLM n’est pas un défaut esthétique — c’est un coût direct en tokens et en temps. L’étude TALE (Han et al., ACL Findings 2025) montre qu’une instruction explicite de type “utilise moins de N tokens” réduit les tokens de raisonnement de 68 % avec une perte de performance inférieure à 5 %.

Attention au piège inverse : un budget trop restrictif déclenche l’effet “Token Elasticity” — le modèle compense en devenant plus dense mais moins structuré, ce qui peut dégrader la qualité.

Recommandation : ajouter une limite de tokens explicite dans le prompt système des agents verbeux. Calibrer empiriquement : commencer large et réduire par paliers de 20 % jusqu’à observer une dégradation.

Marquer la provenance des données

Quand un agent ingère des données externes (pages web, documents utilisateur, résultats d’API), le risque d’injection indirecte est réel. La technique du “spotlighting” (Microsoft Research, 2024) réduit le taux de succès des injections indirectes de plus de 50 % à moins de 2 % en ajoutant des délimiteurs explicites autour des données non fiables.

Recommandation : encadrer systématiquement les données externes par des marqueurs de provenance ([SOURCE EXTERNE - NON VÉRIFIÉE]). Instruire le modèle dans le prompt système que ces sections sont des données, pas des instructions.

Respecter la fenêtre effective

Les benchmarks BABILong (NeurIPS 2024) et RULER (NVIDIA, COLM 2024) convergent sur un constat : les LLM n’utilisent effectivement que 5 à 25 % de leur fenêtre de contexte déclarée. Yi-34B-200K reste stable uniquement jusqu’à 64K tokens. RULER estime la fenêtre effective de GPT-4 à 64K sur 128K déclarés.

Recommandation : concevoir les prompts pour la fenêtre effective, pas la fenêtre déclarée. Pour un modèle annonçant 128K tokens, viser un prompt total inférieur à 30K tokens pour maintenir une qualité fiable.

Gérer l’instruction tuning comme un facteur de fragilité

L’instruction tuning — le fine-tuning sur des paires instruction/réponse — améliore la robustesse face aux attaques adversariales (PromptRobust, Zhu et al., 2023 : T5 et UL2 deviennent plus résistants après fine-tuning adversarial). Mais l’étude POSIX (EMNLP 2024 Findings) révèle l’envers : les modèles instruct sont 2 à 4 fois plus sensibles aux reformulations non vues que les modèles de base. Ce sont deux dimensions distinctes de robustesse.

Implication pratique : un prompt optimisé pour un modèle instruct peut perdre en performance après une mise à jour du modèle si le fine-tuning a changé. Prévoir des tests de régression sur les prompts critiques lors des montées de version.

Niveau 3 — Multi-agent

L’orchestration multi-agent utilise plusieurs LLM coordonnés, chacun recevant un prompt distinct. C’est le cas des pipelines de traitement, des systèmes de recherche automatisée ou des workflows complexes. Les enjeux de context prompting changent d’échelle.

Optimiser les prompts individuels avant de multiplier les agents

Une étude Google et Cambridge (Zhou et al., MASS, 2025) démontre que l’optimisation du prompt d’un seul agent surpasse le scaling horizontal — ajouter des agents avec des prompts médiocres. Le gain mesuré est de +8.5 points par rapport aux meilleures baselines à coût comparable.

Recommandation : avant d’augmenter le nombre d’agents, auditer et optimiser les prompts existants. Un seul agent bien prompté vaut souvent mieux que trois agents mal configurés.

Isoler les instructions partagées

Quand plusieurs agents partagent un contexte commun (règles métier, contraintes de format, conventions), trois sources industrielles convergent : Microsoft (Azure Architecture Center), Anthropic et les surveys multi-agent recommandent d’isoler ce contexte partagé plutôt que de le dupliquer dans chaque prompt. Anthropic formule : “décider quel contexte l’agent suivant nécessite pour être efficace. Si l’agent peut travailler sans contexte accumulé et ne nécessite qu’un nouveau jeu d’instructions, adopter cette approche.”

La question de la flexibilité de ces instructions reste ouverte. Anthropic recommande d’injecter des heuristiques plutôt que des règles rigides pour les tâches de recherche ouverte (“instill heuristics over rules”). À l’opposé, l’approche KtR (Know-the-Rules, 2025) préconise des contrats typés JSON pour les problèmes algorithmiques. Les deux approches sont complémentaires : heuristiques pour les tâches ouvertes, contrats stricts pour les tâches fermées. Il n’existe pas de configuration universelle.

Recommandation : pour les tâches exploratoires (recherche, analyse), formuler les instructions comme des principes directeurs. Pour les tâches de production (extraction, formatage, validation), spécifier des contrats de sortie explicites.

Structurer pour le prompt caching

Le prompt caching d’Anthropic offre 90 % d’économie sur les tokens en cache (lecture cache = 0.1× du prix input standard). La condition : correspondance exacte du préfixe. Chaque caractère modifié invalide le cache.

Recommandation : placer les instructions stables et partagées en début de prompt (elles forment le préfixe commun cacheable). Placer les variables spécifiques à chaque appel en fin. Cette structure maximise le taux de cache hit en multi-agent.

Ne pas compter sur la hiérarchie system/user

L’étude “Control Illusion” (Xue et al., 2025, 1200 cas test, 6 modèles) mesure que l’obéissance au prompt système s’effondre de 74-90 % à 9.6-45.8 % en situation de conflit avec le prompt utilisateur. Même GPT-4o plafonne à 47 %. La taille du modèle n’améliore pas la situation — Llama-70B performe de manière comparable à Llama-8B sur cette dimension.

En multi-agent, où les instructions traversent plusieurs couches (orchestrateur → agent → sous-agent), la fiabilité de la hiérarchie d’instructions est encore moins garantie. Le marquage explicite des contraintes critiques (+79.7 % d’obéissance dans certaines configurations) est plus fiable que la position dans la hiérarchie.

Recommandation : ne pas compter sur la distinction system/user pour résoudre les conflits d’instructions. Marquer explicitement les contraintes non négociables dans le corps du prompt, indépendamment de leur position hiérarchique.

Les pièges documentés

Le mirage de la fenêtre longue

Les LLM n’exploitent que 5 à 25 % de leur fenêtre déclarée (BABILong, NeurIPS 2024 ; RULER, COLM 2024). Un prompt qui “rentre” dans la fenêtre n’est pas un prompt que le modèle traite effectivement. La dégradation est progressive et silencieuse — le modèle ne signale pas qu’il ignore une partie du contexte.

La charge cognitive extrinsèque

L’analogie avec la théorie de la charge cognitive (Cognitive Load Theory) s’applique fonctionnellement aux LLM. Une étude (Adapala, 2025) mesure sur Gemini-2.0-Flash une chute de performance de 0.85 à 0.72 quand 80 % du contenu est extrinsèque (non pertinent pour la tâche), à longueur totale contrôlée. Le contenu non pertinent n’est pas neutre — il dégrade activement la performance, indépendamment de la longueur du prompt.

Implication : chaque token ajouté au prompt doit justifier sa présence. Un prompt plus court mais plus pertinent surpassera un prompt long et exhaustif.

Lost-in-the-Middle

La courbe en U documentée par Liu et al. (TACL 2024) signifie que l’information placée au milieu d’un contexte long est la moins bien exploitée. Ce biais interagit avec la longueur : au-delà de 50 % de remplissage de la fenêtre, le biais de récence domine (Serial Position Effects, 2024 ; Positional Biases, COLM 2025).

Implication : pour les prompts longs, placer les informations critiques en tout début et les instructions finales en toute fin. Le milieu est la zone morte.

La dégradation silencieuse du constrained decoding

Forcer un format de sortie strict (JSON mode) dégrade le raisonnement de 26 à 42 points (Tam et al., 2024). Le modèle alloue de l’attention au respect du schéma au détriment du raisonnement. Le pattern alternatif : demander le raisonnement en texte libre, puis le résultat dans le format contraint.

Ce qu’il faut retenir

  • La position de l’information dans le prompt améliore significativement les résultats — placer les données avant la question est le gain le plus simple à capturer.
  • La spécificité surpasse la longueur : un prompt précis et mesurable vaut mieux qu’un prompt exhaustif et vague (+23 à +47 points mesurés).
  • Le Chain-of-Thought est tâche-dépendant — il aide sur le raisonnement structuré mais peut dégrader la performance sur les tâches de reconnaissance de patterns.
  • En multi-agent, optimiser les prompts individuels avant d’ajouter des agents. Le scaling horizontal avec des prompts médiocres est contre-productif.
  • Les fenêtres de contexte déclarées sont trompeuses : concevoir pour 5 à 25 % de la fenêtre annoncée.

Sources