Prompt engineering pour agents IA

Qu'est-ce que le prompt engineering pour agents IA ?

Le prompt engineering pour agents désigne la discipline d'ingénierie qui permet à un agent IA d'adopter de manière cohérente le comportement souhaité sur plusieurs tours d'inférence. Alors que le prompt engineering classique (2022–2023) consistait à rédiger une seule chaîne d'instructions astucieuse, chez un agent la fenêtre de contexte n'est plus un texte statique, mais un état système composé dynamiquement : prompt système, définitions d'outils, résultats d'outils, historique de conversation, chunks RAG récupérés, notes de scratchpad et état structuré.

Andrej Karpathy a décrit ce glissement le 25 juin 2025 comme du context engineering, « the delicate art and science of filling the context window with just the right information for the next step », à peine une semaine après que le PDG de Shopify, Tobi Lütke, eut popularisé le terme. Anthropic l'a formalisé le 29 septembre 2025 dans « Effective context engineering for AI agents » comme « l'évolution naturelle du prompt engineering ». Un point important pour bien situer les choses : le context engineering englobe le prompt engineering, il ne le remplace pas. Un bon prompt système reste une condition nécessaire ; il n'est simplement plus suffisant.

Cette page pilier donne une vue d'ensemble des cinq briques essentielles : prompts système, descriptions d'outils, boucles de planification (ReAct), gestion de la fenêtre de contexte et évaluation.

Architecture du prompt système

Le prompt système est le seul élément de contexte que l'agent voit à chaque tour ; c'est du code : versionné, relisible, comparable par diff. En 2026, les prompts système en production se structurent de manière constante en quatre couches :

Anthropic recommande de séparer ces sections par des balises XML ou des titres Markdown ; le modèle analyse les prompts structurés de manière plus fiable. La bonne longueur, Anthropic l'appelle « the right altitude » : les retours de praticiens convergent vers 500–3 000 tokens pour le noyau (hors schémas d'outils). Les deux extrêmes nuisent : avec des prompts trop longs comptant 47 règles numérotées, le modèle applique moins souvent les dernières règles (Lost-in-the-Middle dans son propre prompt système) ; des prompts trop vagues (« Tu es un assistant utile ») laissent trop de place à l'inférence du modèle.

Un changement majeur concerne les règles absolues : les recommandations d'OpenAI pour GPT-5 (2026) préconisent explicitement de réserver ALWAYS/NEVER aux vrais invariants ; « for judgment calls, such as when to search, ask for clarification, use a tool, or keep iterating, prefer decision rules instead ». Les équipes de la zone DACH (Allemagne, Autriche, Suisse) doivent en plus toujours définir explicitement la langue de réponse (sinon, les modèles frontier basculent par défaut vers l'anglais sur du contenu technique) et fixer explicitement la forme d'adresse (Sie/Du) pour éviter une dérive de style dans la boucle.

Descriptions d'outils : là où les agents échouent vraiment

Quand un agent en production agit de travers, la cause, d'après l'expérience d'ingénierie d'Anthropic elle-même, ne se trouve « dans la plupart des cas » pas dans le modèle, mais dans la définition de l'outil. La question directrice : « If a human engineer can't definitively say which tool should be used in a given situation, an AI agent can't be expected to do better. »

Point décisif : les descriptions d'outils font partie du budget du prompt. Chaque outil ajoute 100–300 tokens « always-on » ; un catalogue de 10 outils coûte 1 000–3 000 tokens par appel. Le composant le plus efficace, et le plus souvent oublié, est la clause « quand ne pas l'utiliser » : si search_web et query_internal_db coexistent, c'est cette clause qui décide du choix de l'outil. Le chevauchement d'outils, c'est-à-dire deux outils capables de répondre de façon plausible à la même requête, est le seul problème qu'aucun prompt, aussi bon soit-il, ne résout.

Les données empiriques sont nettes. Avec l'outil tool_search d'Anthropic et defer_loading: true pour les outils rarement utilisés, la précision de sélection des outils dans des évals MCP internes est passée sur Opus 4 de 49 % à 74 % et sur Opus 4.5 de 79,5 % à 88,1 % (Anthropic, novembre 2025), avec environ 85 % de tokens économisés. À partir d'environ 10 outils actifs, une dégradation mesurable apparaît. Le pattern de production est donc 3–7 outils toujours chargés plus Tool Search pour le reste. L'exécution de code avec MCP emprunte une autre voie : l'agent s'adresse aux serveurs MCP via du code et ne charge les définitions d'outils qu'en cas de besoin.

Autres conventions éprouvées : des noms verbe-nom (get_user, send_email), des descriptions au niveau des champs avec leur sémantique, des formats de retour et des modes d'échec documentés, des outils orientés recherche plutôt que des outils qui listent tout, ainsi que des limites strictes de tokens en réponse (valeur indicative d'Anthropic : ~25 000 tokens par retour d'outil). Pratique courante dans la zone DACH : noms d'outils et paramètres en anglais (interopérabilité), descriptions dans la langue d'exécution de l'agent.

Boucles de planification : ReAct et ses successeurs

La planification est la structure de la boucle de décision d'un agent. Quatre patterns dominent en 2026, avec des compromis clairs :

ReAct entrelace raisonnement et action (Thought → Action → Observation) et constitue le choix par défaut fiable pour les modèles sans raisonnement. Avec les modèles de raisonnement, la donne change : l'Interleaved Thinking (Anthropic Claude avec Extended Thinking, série o d'OpenAI/GPT-5) permet au modèle de replanifier entre les appels d'outils et réduit ainsi de nombreuses implémentations classiques de « ReAct-in-a-loop » à un seul appel d'API. En pratique, les agents en production utilisent des hybrides : une boucle ReAct avec une étape de planification explicite au départ et une vérification avant les actions irréversibles.

Une terminaison disciplinée est la protection la plus importante ; les boucles infinies ont été la catégorie de bugs de production la plus fréquente en 2025–2026. Les boucles fiables combinent un nombre maximal d'itérations (plafond strict, typiquement 10–30 en général, 50–100 pour le code), un critère de succès (par ex. un outil submit_final_answer), des plafonds de coûts, une détection des états répétés contre le tool thrashing et une voie d'escalade vers un humain.

Gestion de la fenêtre de contexte

En 2026, de longues fenêtres de contexte sont disponibles (Claude Opus et Gemini, chacun jusqu'à 1M de tokens), mais elles ne sont pas exploitables de manière uniforme. L'étude « Context Rot » de Chroma (juillet 2025, 18 modèles frontier) le montre : tous les modèles se dégradent à mesure que la longueur de l'entrée augmente. Trois mécanismes se renforcent : le Lost-in-the-Middle (Liu et al., Stanford/TACL 2024 ; les modèles prêtent attention au début et à la fin, mal au milieu), la dilution de l'attention et l'interférence des distracteurs. Comme heuristique, la capacité effective se situe à 30–50 % de la capacité nominale pour les tâches axées sur le raisonnement et à 60–80 % pour les tâches axées sur la récupération. Si tu remplis entièrement une fenêtre de 1M, tu gaspilles des tokens et tu dégrades la qualité.

Lance Martin (LangChain) a forgé pour cela la taxonomie canonique en quatre piliers, reprise par Anthropic et Manus :

• Write : stocker l'information hors de la fenêtre (scratchpads, todo.md, mémoire persistante)
• Select : faire entrer les bons tokens à chaque étape (RAG, filtrage des outils, délégation à des sous-agents)
• Compress : ne garder que les tokens pertinents pour la tâche (résumés, Context Editing d'Anthropic)
• Isolate : répartir le contexte entre sous-agents et champs de schéma

Trois leviers dominent l'économie. Le Prompt Caching est le plus important : chez Anthropic, les lectures en cache coûtent 10 % du tarif d'entrée standard, et moins pour certains modèles récents (état octobre 2026 : 5 % pour Opus 5.5 et Sonnet 5.5, 2,5 % pour Fable 5.1 et Mythos 5.1). OpenAI facture également 10 % pour la famille GPT-5, 25 % pour GPT-4.1 et 50 % pour GPT-4o. Une étude arXiv (février 2026, « Don't Break the Cache ») mesure sur des workloads agentiques des coûts d'API inférieurs de 41 à 80 % et un time-to-first-token réduit de 13 à 31 % grâce à un contrôle stratégique des blocs de cache. Le pruning supprime les anciens tours et les résultats d'outils périmés. La compaction compresse le contexte à 70–85 % de la capacité, dans Claude Code par exemple via /compact. Selon Anthropic, elle conserve les « architectural decisions, unresolved bugs, and implementation details » et écarte les sorties d'outils redondantes. La délégation à des sous-agents agit comme une primitive de compaction : un sous-agent explore dans sa propre fenêtre et ne renvoie qu'un résumé de 1 000 à 2 000 tokens.

Évaluation : si tu ne mesures pas, tu n'as rien fait

Le constat le plus brutal pour les tech leads : les modifications de context engineering se valident par des évals, pas à l'intuition. Le conseil le plus cité de Hamel Husain, « Look at your data », signifie concrètement : lire 50 à 100 traces réelles de production, étiqueter librement les échecs, les regrouper dans une taxonomie, écrire pour chaque mode fréquent une éval par code ou une éval LLM-as-Judge, puis intégrer ces évals dans la CI et le monitoring.

Husain met toutefois en garde contre un développement purement eval-first : « Write evaluators for errors you discover, not errors you imagine. » La voie médiane praticable commence par une petite éval de bout en bout (10–50 tâches représentatives), itère et construit des sous-évals spécifiques pour les modes d'échec réels. Un constat qui refroidit, établi empiriquement : de nombreux conseils de prompting populaires (« Tu es un expert », « Think step by step », « I'll tip you $200 ») n'apportent qu'une amélioration minime, voire nulle, dans des évals rigoureuses ; sur les modèles de raisonnement, « think step by step » est déjà le comportement par défaut et souvent contre-productif quand on l'ajoute à la main.

La maturité de production, c'est ceci : les évals tournent automatiquement à chaque modification du contexte, des outils ou du retrieval ; l'éval de PR (20–50 tâches) bloque le merge, l'éval pré-déploiement (200–2 000 tâches) bloque le déploiement, l'éval post-déploiement sur les traces de production assure la détection de dérive. L'application stricte des sorties structurées boucle la boucle : OpenAI Structured Outputs en mode strict (en disponibilité générale depuis août 2024) et les Structured Outputs d'Anthropic avec utilisation stricte des outils (depuis novembre 2025) imposent la conformité au schéma par décodage contraint et remplacent l'ancien « parser le JSON et croiser les doigts ». La documentation d'Anthropic cite expressément des exceptions : les refus, les interruptions à la limite de tokens et, occasionnellement, une casse divergente pour les valeurs enum et const.

Spécificités DACH et conformité

Pour les équipes de la zone DACH, trois contraintes d'ingénierie strictes s'ajoutent. Premièrement, la tokenisation de l'allemand : les noms composés et la flexion génèrent 30 à 50 % de tokens en plus que l'anglais pour un contenu équivalent. Une fenêtre de 200K ne contient donc qu'autant de contenu allemand que ce qui tiendrait en anglais dans environ 130–150K tokens. Cela signifie des coûts plus élevés, mais aussi un meilleur ROI du caching, puisque la remise sur le cache s'applique à un plus grand nombre de tokens.

Deuxièmement, la discipline RGPD dans la fenêtre de contexte : les données personnelles n'y ont pas leur place sans filtrage. Les patterns sont la pseudonymisation avant l'injection dans le contexte (ne résoudre les noms réels que dans la couche outils), une couche de masquage des PII avant l'injection RAG et une réinitialisation auditable de l'état de session. Troisièmement, la journalisation imposée par l'art. 12 du règlement sur l'IA pour les systèmes à haut risque : avec l'omnibus IA (règlement (UE) 2026/1744), elle s'applique aux systèmes de l'annexe III à partir du 2 décembre 2027 et aux produits de l'annexe I à partir du 2 août 2028. Pour les équipes suisses, le RGPD et le règlement sur l'IA ne s'appliquent qu'en cas de lien avec l'UE. Le RGPD s'applique, selon l'art. 3, paragraphe 2, lorsque l'équipe propose des biens ou des services à des personnes dans l'UE ou observe leur comportement. Le règlement sur l'IA s'applique, selon l'art. 2, lorsque l'équipe met des systèmes d'IA sur le marché de l'UE ou que leurs résultats sont utilisés dans l'UE. Au niveau national, la nouvelle loi fédérale sur la protection des données (nLPD) est en vigueur depuis le 1er septembre 2023. Cette présentation est fournie à titre informatif et ne constitue pas un conseil juridique. Côté ingénierie, l'obligation de journalisation signifie que la version du prompt système, la version du catalogue d'outils, les documents récupérés (ou leurs ID + hashes), l'entrée utilisateur, les appels d'outils, les résultats d'outils et la sortie finale doivent être persistés de manière auditable tout en restant effaçables au sens du RGPD, idéalement par appel d'outil avec un ID de corrélation d'exécution.

Perspectives et conseil pratique

En 2026, le prompt engineering pour agents n'est ni du folklore ni un simple changement de nom, mais la réponse au passage des appels one-shot à des boucles agentiques en plusieurs étapes. Si tu construis un agent pour la production, tu pratiques cette discipline ; la seule question est de savoir si tu le fais de manière consciente et reproductible ou inconsciente et fragile. Plusieurs domaines restent en mouvement et doivent être lus comme un « instantané actuel » : les conventions des modèles de raisonnement, l'heuristique multi-agents vs agent unique (le parallèle orienté lecture fonctionne, l'orienté écriture non) ainsi que les frameworks d'optimisation de prompts comme DSPy, utiles pour des sous-tâches bien délimitées, mais qui ne constituent pas encore un standard de production pour des boucles d'agent complètes.

Le point de départ pratique n'a rien de spectaculaire et il est bien documenté : récupérer le prompt système dans le playground du fournisseur et le versionner dans Git, valider le schéma de chaque sortie, activer le Prompt Caching sur les parties stables, fixer des plafonds de coûts stricts et lire chaque semaine 20 traces réelles. Le principe directeur d'Anthropic résume l'objectif global plus précisément que n'importe quel débat sur l'outillage : « Find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome. » C'est ça, l'ingénierie. Et ensuite : look at your data.