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 5, un million d'input tokens coûte $2 ; 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 :

Dimension	Prompt engineering	Context engineering
Portée	Une instruction	Tout le payload, à chaque tour
Ce qu'il change	La formulation	Quels fichiers, tools, historique sont présents
Impact sur le coût	Marginal	Direct — croît avec le volume de tokens
Impact sur la précision	Aide une fois, puis plat	Retire le bruit qui masque le signal
Qui a le contrôle	Vous (un chat) ; l'agent (une session)	Vous, si vous façonnez les réglages par défaut de l'agent
Plafond	Atteint rapidement	Le principal levier restant

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 :

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.
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.
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.
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 à 24,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.

Foire aux questions

Qu'est-ce que le prompt engineering ?

Le prompt engineering est la pratique consistant à écrire et affiner l'instruction donnée à un modèle — formulation, structure, exemples, format de sortie — pour qu'il réponde comme vous l'entendez. Il opère sur un seul message : ce que vous tapez, plus le système prompt au-dessus. C'est une vraie compétence, et pour du travail en un tour — une réponse de chat, une classification, un texte — c'est l'essentiel du travail. Là où il cesse de payer, c'est dans la boucle agentique : l'instruction y devient une fraction faible et décroissante de ce que le modèle lit réellement.

Qu'est-ce que le context engineering ?

Le context engineering est la pratique consistant à contrôler tout ce que le modèle lit à un tour donné : l'instruction, mais aussi les fichiers, les sorties d'outils, l'historique de conversation et les schémas d'outils renvoyés avec elle. Il traite la fenêtre de contexte comme un budget à dépenser délibérément plutôt qu'à remplir par défaut. La distinction porte sur la portée, pas sur la qualité. Le prompt engineering demande « que dois-je dire ? ». Le context engineering demande « que doit voir le modèle ? » — et dans un agent de code, la réponse à la seconde question est des milliers de fois plus volumineuse que la première.

Le prompt engineering est-il mort ?

Non — il est rétrogradé, pas supprimé. Une instruction mal formulée produit toujours un mauvais résultat, et aucune hygiène de contexte ne sauve une demande ambiguë. Ce qui a changé, c'est le ratio : dans un chat en un tour, votre prompt représente l'essentiel de la charge utile ; dans une session d'agent de vingt tours, c'est une erreur d'arrondi face aux fichiers et aux logs relus à chaque tour. Traitez le prompt engineering comme un prérequis qu'on règle une fois, puis déplacez votre attention vers la partie qui grandit avec la longueur de session.

Lequel apprendre en premier ?

Le prompt engineering d'abord : il est plus petit, il se transpose partout, et on ne peut pas le sauter. Une instruction précise est la fondation ; le context engineering est ce qu'on bâtit dessus une fois qu'on pilote des agents au lieu de discuter. L'ordre pratique : écrivez une instruction claire, puis regardez ce que votre agent a lu pour y répondre. C'est à la seconde étape que se trouvent les surprises, et mesurer la consommation d'un agent est la façon de les voir.

Le context engineering s'applique-t-il hors du code ?

Oui, partout où un modèle travaille sur un corpus qu'il n'a pas mémorisé — questions-réponses sur documents, agents de support, assistants de recherche. Les leviers changent : la recherche sémantique et la lecture structure-d'abord ont ici une saveur code, mais récupérer plutôt que déverser, filtrer les sorties bavardes et élaguer l'historique périmé valent pour tout ce qui a une fenêtre de contexte et une facture au bout.

Réduire le contexte dégrade-t-il les réponses ?

En général c'est l'inverse, au-dessus du seuil de pertinence. Les modèles prêtent le moins d'attention à ce qui est enfoui dans une fenêtre saturée : retirer les corps de fichiers hors sujet et le bruit des logs élève le rapport signal/bruit. Le seul cas où ça nuit, c'est de compresser un élément porteur — d'où des lectures structure-d'abord qui conservent toutes les signatures, et des filtres de sortie qui conservent l'erreur réelle.

À voir aussi :