Context engineering vs prompt engineering

Quelle est la différence entre context engineering et prompt engineering ?

Le prompt engineering est l'art de bien formuler une instruction unique ; le context engineering est l'art de contrôler l'ensemble du payload que le modèle lit autour de cette instruction — le system prompt, l'historique de conversation, chaque fichier récupéré, toutes les définitions de tools et chaque ligne de sortie de commande. Le premier est une phrase. Le second, c'est tout ce que le modèle voit lorsqu'il traite cette phrase. Pour un chat en one-shot, les deux se confondent presque. Pour un agent de code autonome qui boucle sur des dizaines de tours, ils ne pourraient pas être plus différents, et c'est dans cet écart que naissent l'essentiel de votre facture et l'essentiel de vos mauvaises réponses. Je passe mes journées à construire des outils qui réduisent ce que les agents de code lisent, j'ai donc une opinion bien arrêtée ici, et je la pose d'emblée : le prompt engineering est un problème suffisamment résolu pour le travail de code, et le context engineering est celui qui laisse encore de l'argent et de la précision sur la table. Si vous voulez la discipline complète, j'ai écrit un article plus approfondi sur le context engineering pour les agents de code IA ; cet article-ci est plus ciblé — il explique pourquoi vous devriez cesser de bricoler la formulation et commencer à gérer le payload.

Pourquoi le prompt engineering compte-t-il moins pour les agents de code ?

Le prompt engineering compte moins pour les agents de code parce que l'instruction est rarement ce qui échoue — c'est le contexte qui l'entoure. Quand vous demandez « corrige le bug d'auth », le modèle vous comprend généralement parfaitement. Ce qui détermine sa réussite, c'est de savoir si les trois fonctions pertinentes ont atterri dans la context window et si elles n'ont pas été noyées sous 4 000 lignes de code sans rapport que l'agent a lues « par précaution ». Il y a une seconde raison, et c'est la moins glamour : les modèles modernes sont bons pour suivre les instructions. Le rendement marginal d'une cinquième reformulation de « sois concis s'il te plaît » tend vers zéro. Pendant ce temps, l'agent vient d'ouvrir un fichier de 600 lignes pour utiliser deux fonctions, a renvoyé l'intégralité de votre CLAUDE.md pour le huitième tour d'affilée, et a chargé neuf schémas de tools MCP qu'il n'appellera jamais. Rien de tout cela n'est un problème de prompt. Tout cela est un problème de contexte. Cela ne signifie pas que les prompts ne valent rien. Un system prompt tranchant et un cadrage clair de la tâche aident toujours. Mais une fois que vous avez écrit une instruction correcte, vous atteignez vite des rendements décroissants — et chaque heure passée au-delà de ce point à fignoler la formulation est une heure non consacrée au levier qui fait réellement bouger le coût et la qualité.

Pourquoi le contexte est-il le véritable levier de coût et de précision ?

Le contexte est le véritable levier parce que le coût croît avec le nombre de tokens que vous faites passer dans le modèle, et la précision se dégrade lorsque ces tokens sont majoritairement du bruit. Ces deux effets dépendent du volume et de la forme, pas de l'intelligence de votre formulation. Le coût croît avec le payload, pas avec la formulation. Sur Claude Sonnet 4.6, un million d'input tokens coûte $3 ; sur Claude Opus 4.8, $5 in / $25 out par MTok ; GPT-5.5 se situe à $5 in / $30 out (tarification Anthropic, 2026 ; tarification OpenAI, 2026). Une session d'agent en plusieurs étapes renvoie son transcript grandissant à chaque tour, si bien que le côté input domine la facture. Réduire ce que l'agent lit est la baisse de coût la plus directe disponible — bien plus que n'importe quel ajustement de prompt. J'ai détaillé les mécanismes dans comment réduire la consommation de tokens d'un agent de code IA. La précision se dégrade dans une fenêtre bourrée. Liu et al. (« Lost in the Middle », 2023 — arxiv.org/abs/2307.03172) ont montré que la précision de récupération chute fortement pour les faits placés au milieu d'un long contexte. Ainsi, une fenêtre sur-remplie ne coûte pas seulement plus cher — elle cache activement l'information dont le modèle a besoin. Un prompt parfaitement formulé ne peut pas sauver un payload où la fonction pertinente est enfouie à la position 40 000 sur 90 000 tokens. C'est l'agent qui construit le payload, pas vous, en général. C'est la partie que les gens manquent. Dans un chat, vous contrôlez l'input. Dans une session agentique, l'agent décide quoi lire, quels tools appeler et ce qui reste dans le transcript — et ses réglages par défaut penchent vers la sur-lecture, parce qu'ouvrir un fichier entier semble plus sûr que de n'ouvrir rien. Le prompt engineering ne peut pas atteindre ces décisions. Le context engineering est précisément l'acte de les façonner. Si l'expression « l'agent décide quoi lire » est nouvelle pour vous, mon article sur l'agentic coding explique comment cette boucle fonctionne.

Comment se comparent-ils, côte à côte ?

Voici le contraste en un tableau : La forme en rendements décroissants, c'est toute l'histoire. La qualité du prompt grimpe vite, puis plafonne. La discipline de contexte continue de payer à mesure que les sessions s'allongent et que les dépôts grossissent — soit exactement la direction que prend l'agentic coding. À noter, ce n'est pas un argument contre un prompting soigné dans les chats jetables — là, la formulation est presque tout ce dont vous disposez. C'est un argument sur l'endroit où se situe le levier une fois qu'un agent utilisant des tools assemble son propre contexte sur de nombreux tours.

Comment fait-on du context engineering aujourd'hui ?

Vous faites du context engineering en contrôlant quatre choses que l'agent gonflerait sinon de lui-même. Aucune d'elles ne nécessite une montée de version du modèle ni un prompt astucieux :

1. Récupérer, ne pas déverser. Au lieu de laisser l'agent lire des fichiers entiers pour trouver un symbole, utilisez la semantic code search pour ne faire remonter que les passages pertinents. C'est le plus gros gain unique dans la plupart des codebases — voir semantic search vs grep si vous voulez la comparaison.
2. Filtrer la sortie des tools. Les logs de build, les test runners et les commandes git émettent des milliers de tokens dont une vingtaine importent peut-être. L'output filtering garde le signal et jette le reste avant même qu'il n'atterrisse dans le transcript.
3. Lire la structure avant les corps. La skeleton compression remet au modèle la forme d'un fichier — signatures, classes, exports — au lieu de chaque ligne. L'agent ne lit le corps que lorsqu'il en a réellement besoin, une forme de context compression.
4. Charger les tools paresseusement. Chaque serveur MCP que vous connectez injecte ses schémas de tools dans la fenêtre, à chaque tour, que vous les appeliez ou non. Le chargement MCP paresseux diffère ce coût jusqu'à ce qu'un tool soit réellement invoqué. (Cela vaut la peine d'auditer votre configuration — les meilleurs serveurs MCP pour Claude Code est une liste de départ raisonnable.)

Vous pouvez faire les quatre à la main : dire à l'agent de grep étroitement, ne coller que les lignes de log pertinentes, élaguer votre transcript, déconnecter les serveurs MCP inutilisés. Ça marche, c'est fastidieux, et vous oublierez de le faire à 18h un vendredi. C'est précisément cette corvée qui me pousse à construire Tokenade. Il se place entre votre agent et le modèle et applique automatiquement les quatre leviers — semantic code search, output filtering, skeleton compression, chargement MCP paresseux — puis vous montre les tokens économisés sur un dashboard, pour que l'effet ne soit pas une question de foi. Il fonctionne avec Claude Code, Cursor, Codex, Copilot, Windsurf et les autres. Le palier Gratuit couvre environ 10M tokens par mois ; Pro est à 19,90 $/mois HT (19,90 €/mois TTC en France), postes illimités. C'est source-available sous licence MIT, vous pouvez donc lire exactement ce qu'il fait à votre contexte avant de lui confier le moindre octet. Si vous préférez d'abord voir le terrain, je tiens une liste honnête des meilleurs optimiseurs de tokens pour Claude Code.

Qu'est-ce qui tourne mal (anti-patterns) ?

Les modes d'échec sont prévisibles une fois qu'on a observé assez de sessions :

• Fignoler le prompt en ignorant le payload. Le classique. Vous passez un après-midi à perfectionner votre system prompt, l'agent lit toujours un fichier de 600 lignes pour deux fonctions, et vous vous demandez pourquoi la facture n'a pas bougé. Vous avez optimisé le levier bon marché et laissé intact le levier coûteux.
• Considérer une context window plus grande comme une fonctionnalité. Une fenêtre de 1M tokens est une permission d'être paresseux, pas une raison de la bourrer. Les fenêtres plus grandes aggravent le problème du « lost in the middle », elles ne l'améliorent pas, et vous payez chaque token que le modèle le lise attentivement ou non.
• Supposer que le caching vous sauve par défaut. Le prompt caching aide — les cache reads coûtent environ 10 % du prix de l'input — mais seulement pour le préfixe qui reste octet pour octet identique d'un tour à l'autre. Les transcripts en append-and-grow et le contexte réordonné cassent le cache en permanence. Le caching récompense un contexte stable et bien conçu ; il ne peut pas sauver un contexte chaotique.
• Connecter chaque serveur MCP « au cas où ». Chacun taxe chaque tour. Si vous ne l'appelez pas, c'est du pur overhead. Auditez sans pitié.
• Confondre moins de tokens et de moins bonnes réponses. L'instinct selon lequel « plus de contexte = plus sûr » est faux au-dessus du seuil de pertinence. Retirer le bruit augmente le rapport signal/bruit ; vous obtenez généralement de meilleures réponses et une facture plus petite en même temps.

Si vous ne retenez qu'une chose : cessez de vous noter sur la formulation du prompt et commencez à surveiller ce que votre agent lit réellement. Le prompt, c'est les 20 % faciles. Le contexte, c'est les 80 % encore sur la table.

---

À voir aussi :

• Context engineering pour les agents de code IA — la discipline complète
• Comment réduire la consommation de tokens d'un agent de code IA — les six leviers pratiques
• Réduire la consommation de tokens de Claude Code — appliqué à un seul agent
• Calculateur de coût de tokens LLM — mettez un chiffre sur votre propre contexte