Un agent qui déraille souffre rarement d’un mauvais modèle. Il souffre d’un mauvais contexte : trop de tokens, mal choisis, qui noient l’instruction utile sous le bruit. Le context engineering est la discipline qui corrige ça. Plutôt que de courir après un modèle plus puissant, on apprend à curer précisément ce que l’agent garde sous les yeux à chaque étape.
La promesse est simple à formuler, exigeante à tenir : un agent fiable n’est pas celui qui voit le plus de choses, c’est celui qui voit les bonnes.
context engineering : la discipline qui prolonge le prompt engineering
Le prompt engineering consistait à bien tourner une instruction unique. Le context engineering élargit le cadre : il s’occupe de l’ensemble des tokens présents dans la fenêtre de contexte au moment où le modèle décide de sa prochaine action. Anthropic en propose une définition de référence dans sa page d’ingénierie « Effective context engineering for AI agents » : il s’agit de la curation et de la maintenance de l’ensemble optimal de tokens pendant l’inférence.
La nuance compte. Sur un agent, le prompt initial ne représente qu’une fraction de ce que le modèle lit vraiment. À chaque tour, viennent s’ajouter les résultats d’outils, les documents récupérés, l’historique de la conversation, les notes de mémoire. C’est cet agrégat mouvant qu’il faut gouverner. En 2026, plusieurs guides (Sourcegraph, Towards Data Science) qualifient cette compétence de socle de l’ingénierie IA, et la distinguent nettement du prompt engineering classique.
ce que contient vraiment le contexte d’un agent
Avant de cadrer, il faut savoir ce qu’on cadre. Le contexte d’un agent se décompose en quelques couches, et chacune pèse dans la balance des tokens :
- Le prompt système : le rôle, les règles, le ton, les garde-fous. Il fixe le comportement de fond.
- La définition des outils : chaque outil exposé à l’agent occupe de l’espace, via son nom, sa description et son schéma de paramètres.
- L’historique : les tours précédents, les actions déjà tentées, les réponses déjà données.
- Le retrieval : les extraits de documents injectés à la volée, souvent par recherche vectorielle (RAG).
- La mémoire : les faits durables qu’on réinjecte d’une session à l’autre.
Le piège classique consiste à empiler ces couches par prudence, comme si plus de contexte garantissait plus de justesse. C’est l’inverse qui se produit.
le vrai problème : plus le contexte grossit, plus l’agent perd le fil
Un modèle dispose d’un budget d’attention fini. Au-delà d’un certain volume, sa capacité à relier l’instruction de départ à la masse de tokens accumulés se dégrade. On observe deux symptômes récurrents.
D’abord, la dilution : une consigne précise posée au début se noie sous des milliers de tokens d’historique et de résultats d’outils. L’agent finit par l’ignorer, non par désobéissance, mais parce qu’elle ne pèse plus assez. Ensuite, la contamination : une erreur, une hallucination ou un faux départ reste dans l’historique et oriente toutes les décisions suivantes. L’agent persévère dans une mauvaise piste parce qu’elle est sous ses yeux.
Allonger la fenêtre de contexte ne résout pas ces problèmes, ça les déplace. Un million de tokens disponibles n’est pas une invitation à tout y verser. La fiabilité ne se gagne pas en remplissant le contexte, elle se gagne en le sculptant.
quatre leviers pour cadrer le contexte
La littérature 2026 converge sur quatre piliers, indépendants de tout outil. On peut les voir comme quatre gestes à exercer en continu sur la fenêtre de contexte.
Sélectionner (retrieval). Ne fournir que les informations pertinentes pour l’étape en cours. Cela suppose un retrieval ciblé : des extraits courts et précis, pas des documents entiers « au cas où ». Un bon retrieval répond à une question, il n’inonde pas.
Compacter (reduction). Résumer ou condenser ce qui peut l’être. Un long échange d’il y a vingt tours n’a pas besoin d’être présent mot pour mot : un résumé de trois lignes suffit souvent. La compaction libère du budget pour ce qui compte maintenant. Les principaux harnais l’ont déjà intégrée : l’Agents SDK d’OpenAI mise sur le trimming et la compression de l’historique, et Claude Code déclenche une compaction automatique quand la fenêtre se remplit.
Isoler. Découper une tâche complexe en sous-agents ou en étapes au contexte cloisonné. Chaque sous-tâche reçoit son propre contexte, cloisonné, sans traîner l’historique des autres. C’est ce qui empêche une erreur locale de polluer tout le reste.
Externaliser (offloading). Sortir de la fenêtre ce qui n’a pas besoin d’y vivre en permanence. Un fichier, une note, une base : l’agent y accède quand il en a besoin, plutôt que de tout porter dans son contexte actif. La mémoire de travail reste légère.
RAG et mémoire : quand récupérer, quand oublier
Le retrieval et la mémoire sont les deux couches les plus mal réglées en pratique, parce qu’elles donnent l’illusion qu’« en mettre plus » aide toujours.
Pour le RAG, la qualité prime sur la quantité. Cinq extraits parfaitement pertinents valent mieux que trente extraits approximatifs : ces derniers diluent l’attention et augmentent le risque que le modèle s’appuie sur un passage hors sujet. Mieux vaut un retrieval qui sait dire « rien de pertinent » qu’un retrieval qui remplit le quota coûte que coûte.
Pour la mémoire, la question décisive est : ce fait mérite-t-il de revenir à chaque session ? Une préférence stable de l’utilisateur, oui. Un détail de conversation d’hier, rarement. Une mémoire qui ne fait que grossir devient un dépotoir : elle ralentit, elle contredit, elle confond. Savoir oublier est un acte d’ingénierie, pas un oubli.
mesurer si votre cadrage tient
Un cadrage de contexte ne se valide pas au ressenti. Il se mesure sur des tâches réelles, répétées, représentatives de l’usage. Le score d’un benchmark générique vous dira que le modèle est capable ; il ne vous dira pas que votre agent, avec vos outils et vos données, est fiable.
Quelques repères concrets à suivre dans le temps : le taux de réussite de bout en bout sur un jeu de tâches fixe, le nombre moyen de tours pour aboutir (un agent qui tourne en rond consomme du contexte pour rien), et la dérive entre le début et la fin d’une session longue. Si la qualité s’effondre après dix tours, le problème est presque toujours un contexte qui enfle, pas un modèle qui faiblit.
la checklist à appliquer sur n’importe quel agent
Ces principes ne dépendent ni d’un fournisseur ni d’une version. Voici la grille à passer sur n’importe quel agent, aujourd’hui comme dans un an :
- Le prompt système tient-il en quelques règles claires, sans paragraphe mort que le modèle ignorera ?
- Chaque outil exposé est-il réellement utile à cet agent, ou encombre-t-il le contexte pour rien ?
- Le retrieval renvoie-t-il des extraits courts et ciblés, avec la possibilité de ne rien renvoyer ?
- L’historique est-il compacté au-delà d’un certain volume, plutôt que conservé brut ?
- Les sous-tâches complexes sont-elles isolées dans des contextes distincts ?
- Ce qui peut vivre hors de la fenêtre y est-il externalisé, et rappelé seulement au besoin ?
- La mémoire ne retient-elle que ce qui mérite de revenir à chaque session ?
Si une seule de ces réponses est « non », vous tenez probablement votre prochain point de fiabilité à gagner, sans changer une ligne de modèle.
Le réflexe naturel, face à un agent décevant, reste de réclamer plus gros : plus de fenêtre, plus de modèle, plus de données. Le context engineering propose le geste inverse, et c’est sa force durable. La vraie compétence des prochaines années ne sera pas de tout mettre dans le contexte, mais de décider, à chaque tour, ce qui mérite d’y être.
Questions frequentes
Quelle différence entre context engineering et prompt engineering ?
Le prompt engineering optimise une instruction unique. Le context engineering gouverne l’ensemble des tokens présents dans la fenêtre à chaque étape d’un agent : prompt système, outils, historique, retrieval et mémoire.
Quels sont les piliers du context engineering ?
Quatre leviers reviennent dans les guides 2026 : sélectionner via un retrieval ciblé, compacter l’historique, isoler les sous-tâches dans des contextes distincts, et externaliser hors de la fenêtre ce qui n’a pas besoin d’y vivre en permanence.
Pourquoi une fenêtre de contexte plus grande ne suffit-elle pas ?
Le budget d’attention d’un modèle reste fini. Au-delà d’un certain volume, l’instruction utile se dilue et les erreurs passées contaminent les décisions suivantes. Agrandir la fenêtre déplace le problème au lieu de le résoudre.
Comment savoir si le cadrage du contexte est efficace ?
En mesurant sur des tâches réelles et répétées : taux de réussite de bout en bout, nombre de tours pour aboutir, et dégradation de la qualité au fil d’une session longue. Un benchmark générique ne reflète pas la fiabilité d’un agent précis.
Le context engineering est-il lié à un outil particulier ?
Non. Ses principes sont tool-agnostiques et s’appliquent à n’importe quel framework d’agents. La checklist sur le prompt système, les outils, le retrieval, l’historique et la mémoire reste valable quel que soit le modèle utilisé.
