Ingénierie des prompts contre ingénierie du contexte : pas un rebranding, un changement de ce que l'on optimise

L'ingénierie des prompts, c'est bien formuler une instruction. L'ingénierie du contexte, c'est décider de ce que le modèle voit tout court. Le terme a été popularisé en juin 2025 par Tobi Lutke de Shopify et amplifié par Andrej Karpathy, qui l'a décrit comme l'art de remplir la fenêtre de contexte avec juste la bonne information pour l'étape suivante. La distinction la plus nette vient de Philipp Schmid : le contexte est tout ce que le modèle voit avant de générer une réponse, et c'est un système, pas une chaîne.

Les deux ne sont pas rivaux ; l'ingénierie des prompts est un sous-ensemble. Quand vous écrivez un bon prompt système, c'est de l'ingénierie des prompts. Quand vous décidez quels trois documents récupérer, quels outils exposer, combien d'historique garder, quoi résumer pour l'écarter et quel schéma de sortie exiger, le tout sous un budget de tokens, c'est de l'ingénierie du contexte. Les recommandations d'Anthropic la présentent comme la gestion de tout l'état du contexte à travers les tours, et sa phrase la plus tranchante vaut d'être retenue : le contexte est une ressource finie à rendements marginaux décroissants.

La raison pour laquelle l'ingénierie du contexte est devenue une discipline nommée est que l'hypothèse facile a cassé sous la mesure. L'hypothèse était que les modèles à long contexte permettent de bourrer la fenêtre et d'arrêter de réfléchir. L'étude Context Rot de Chroma a testé 18 modèles de pointe en juillet 2025 et a trouvé que chacun se dégrade à mesure que l'entrée grandit, souvent de façon non uniforme : le modèle ne traite pas le dix-millième token aussi fiablement que le centième. La constatation plus ancienne du « perdu au milieu » pointait dans le même sens.

Deux forces ont fait de la charge, et non du prompt, l'objet à ingénierer. D'abord, les agents, l'usage d'outils, la récupération et la mémoire font que le contexte est assemblé sur de nombreux tours par un système, pas écrit à la main une fois. Ensuite, l'économie : en production chez Manus, le ratio tokens d'entrée sur sortie tourne autour de 100 pour 1, et réutiliser le cache clé-valeur crée une grande différence de coût, si bien que ce que vous mettez dans la fenêtre est une décision de coût autant que de qualité. Plus de contexte n'est pas mieux ; un contexte budgété et pertinent l'est. C'est l'ossature empirique sous notre présentation antérieure de l'ingénierie du contexte et de pourquoi elle compte.

Dépouillée de l'étiquette, l'ingénierie du contexte est un ensemble de pratiques testables, pas du chuchotement de prompts. Les techniques nommées reviennent chez Anthropic, LangChain et le retour de production de Manus :

• Récupération. Tirer les quelques documents pertinents au moment où ils sont nécessaires, plutôt que de tout coller. C'est la discipline derrière la génération augmentée par récupération.
• Compaction et résumé. Compresser les anciens tours en un résumé courant pour que le budget serve à ce qui est vivant, pas à la transcription.
• Mémoire et prise de notes. Décharger l'état vers des notes ou fichiers externes que l'agent peut relire, au lieu de le porter dans la fenêtre.
• Curation des outils. Garder trois à cinq outils clés chargés et tirer le reste juste à temps. Charger tous les outils dilue le signal et casse le cache.
• Sorties structurées. Exiger un schéma pour que le modèle dépense des tokens sur la réponse, pas sur la mise en forme en prose.
• Isolation. Répartir le travail entre sous-agents pour que chacun ne voie que le contexte dont il a besoin.

LangChain présente le même ensemble comme écrire, sélectionner, compresser et isoler. Le point est que chacun de ceux-ci est mesurable : vous pouvez comparer en A/B un récupérateur, un seuil de compaction ou une composition d'outils, ce qui est précisément ce qui en fait de l'ingénierie plutôt que de la formulation.

En partie, et c'est bien. Oui, les bons ingénieurs curaient déjà ce que le modèle voit ; la valeur du nom est qu'il oriente l'optimisation vers la charge et le système, pas vers la phrase, là où vivent réellement la fiabilité et le coût. Le débat vivant est plus utile que la querelle terminologique. En juin 2025, Cognition a plaidé contre les systèmes multi-agents, au motif que partager proprement le contexte entre agents est difficile, et a recommandé de garder le travail mono-agent et de partager des traces complètes. La même semaine, Anthropic a décrit un système de recherche multi-agents qui dépend d'une isolation de contexte disciplinée. Même discipline, conclusion architecturale opposée.

Pour une équipe qui construit avec des LLM, les enseignements sont clairs. Budgétez les tokens comme vous budgétez le calcul, car plus n'est pas gratuit et pas toujours mieux. Traitez le travail comme de la plomberie (qualité de récupération, compaction, mémoire, curation des outils, sorties structurées), pas comme de la formulation. Et choisissez votre architecture selon la fiabilité avec laquelle vous pouvez partager le contexte, plutôt que selon l'approche qui sonne le plus avancée. Le nom continuera de muter, certains appellent déjà la couche suivante ingénierie du harnais, mais l'objet est stable : le système qui décide de ce que le modèle a le droit de voir.