Context engineering efficace pour les agents IA

Que signifie réellement un context engineering efficace pour les agents IA ?

Un context engineering efficace consiste à traiter la context window de l'agent comme une ressource rare et coûteuse, et à décider — délibérément, à chaque tour — exactement ce qui y entre, sous quelle forme et dans quel ordre. Ce n'est pas du fignolage de prompt. C'est la discipline qui consiste à gérer l'information qu'un agent lit pendant qu'il travaille, car dans une boucle agentique cette information est relue à chaque étape et vous la payez à chaque fois. J'ai un doctorat en IA et je passe l'essentiel de ma semaine à construire des outils qui réduisent ce que dépensent les agents de code. Le constat le plus constant sur chaque agent que j'ai profilé — Claude Code, Cursor, Codex, Copilot, Windsurf — c'est que la qualité de réponse du modèle est rarement le goulot d'étranglement. C'est le contexte qui l'est. Donnez à un agent les trois fonctions qui comptent et il résout la tâche en une passe. Donnez-lui tout votre dépôt « par sécurité » et il vous rend une moins bonne réponse, plus lentement, pour dix fois le prix. Le context engineering, c'est la façon de rester du bon côté de cette ligne. Cet article est le compagnon pratique de Context Engineering for AI Coding Agents, qui pose le cadre plus large. Ici je veux être concret : le mécanisme qui rend le contexte si coûteux, les quatre techniques qui font vraiment bouger la facture, et les erreurs que je vois commettre chaque semaine.

Pourquoi le contexte est-il si coûteux dans une boucle agentique ?

Le contexte est coûteux parce qu'un agent relit l'intégralité de son contexte à chaque tour, donc tout ce que vous y placez tôt est de nouveau facturé à chaque étape qui suit. C'est le fait mécanique unique qui, une fois intégré, réorganise toute votre façon de penser le coût d'un agent. Une complétion de chat en un seul coup facture l'input une fois. Un agent agentique ne fonctionne pas en un seul coup. Il planifie, appelle un outil, lit le résultat, planifie de nouveau, appelle un autre outil — et à chacune de ces étapes le modèle reçoit l'intégralité de la conversation jusque-là : le system prompt, chaque définition d'outil, chaque fichier qu'il a lu, la sortie de chaque commande, et chaque mot qu'il a déjà prononcé. Un fichier lu de 6 000 tokens au tour 2 est toujours dans le prompt au tour 25. Vous l'avez payé vingt-quatre fois. Les chiffres rendent cela frappant. Au tarif d'input de Claude Opus 4.8 de 5 $ par million de tokens, un contexte gonflé à 150 000 tokens coûte 0,75 $ par tour rien que pour être relu — avant même que le modèle ne génère un seul nouveau token, et l'output est bien plus cher à 25 $ par million. Une session de vingt tours à cette taille, c'est 15 $ rien qu'en relectures. Le prompt caching atténue cela — les cache reads tournent à environ 10 % du prix de l'input — mais le caching récompense les préfixes stables, et un agent qui continue d'ajouter de nouvelles lectures continue d'invalider la fin du cache. Vous ne pouvez pas vous sortir par le caching d'un contexte que vous brassez sans cesse. Voir LLM API token pricing pour les tarifs actuels par modèle. L'objectif du context engineering n'est donc pas « utiliser un modèle plus petit » ni « écrire un prompt plus malin ». C'est : garder le contexte petit, stable et pertinent, tour après tour.

Quelles sont les techniques qui font vraiment bouger la facture ?

Les techniques qui font bouger la facture sont la récupération plutôt que la lecture, l'output filtering, la compression structurelle et l'élagage de la surface d'outils — à peu près dans cet ordre d'impact pour la plupart des sessions de code.

Récupérer, pas lire

Le plus gros levier consiste à arrêter de lire des fichiers entiers quand on a besoin d'une fonction. Le comportement par défaut de l'agent — « lis src/auth/session.ts » — tire 6 000 tokens pour répondre à une question qui tenait dans une fonction de 40 lignes. La solution est de faire d'abord localiser le symbole pertinent par l'agent, puis de ne lire que ce corps-là. La semantic code search fait cela par le sens plutôt que par la chaîne exacte, si bien qu'une requête comme « où validons-nous le refresh token » trouve la fonction même quand aucun de ces mots n'y apparaît. Bien menée, c'est la différence entre une récupération de 2 000 tokens et une de 20 000, et comme cette lecture est refacturée à chaque tour suivant, l'économie se cumule.

Filtrer la sortie d'outil avant qu'elle n'atterrisse

Le deuxième levier est de ne jamais laisser la sortie brute d'une commande arriver directement dans le contexte. Un agent lance npm test, la suite émet 15 000 tokens de coches vertes, de tableaux de timing et de stack traces, et tout cela atterrit dans le transcript. L'agent avait besoin de peut-être 50 tokens : le nom du test en échec et l'assertion cassée. Tout le reste est du bruit qui se refacture désormais à chaque tour. L'output filtering — garder les lignes de signal et jeter le fret — est l'un des gestes les moins chers et les plus rentables disponibles, précisément parce que la sortie d'outil est si fiablement verbeuse.

Compresser la structure, pas le sens

Le troisième levier est la compression structurelle : quand l'agent a réellement besoin de comprendre la forme d'un gros fichier plutôt que son corps complet, donnez-lui un squelette — signatures, types, symboles exportés, le contour de la classe — au lieu de chaque ligne. Le squelette d'un module de 500 lignes peut faire 400 tokens contre 6 000 pour le texte complet, et pour « comment ce module est-il organisé ? » le squelette répond complètement à la question. C'est volontairement avec perte : vous abandonnez les corps d'implémentation que l'agent ne va pas toucher. Voir context compression pour l'idée générale.

Élaguer la surface d'outils

Le quatrième levier est celui qu'on oublie parce qu'il est invisible. Chaque serveur MCP que vous connectez annonce son schéma d'outils complet à chaque tour, utilisé ou non. Cinq serveurs avec dix outils chacun, c'est une taxe fixe payée toute la session, relue à chaque étape comme tout le reste. Chargez les définitions d'outils paresseusement — uniquement quand un outil est sur le point d'être réellement utilisé — et cette surcharge constante disparaît en grande partie. Mes best MCP servers for Claude Code passent en revue ceux qui méritent leur place.

Comment appliquer cela dès aujourd'hui ?

Vous appliquez le context engineering en changeant la façon dont vous instruisez l'agent et en plaçant des outils entre l'agent et ses inputs bruts. Concrètement :

Formulez les tâches comme des récupérations ciblées, pas des visites guidées. « Trouve la fonction qui construit le header d'auth et montre-moi sa signature » vaut mieux que « lis le module d'auth ». Bannissez de vos propres habitudes les formulations de visite de fichiers ouverte — « parcours le codebase », « vérifie tous les fichiers de X » ; ce sont des instructions à gonfler le contexte.
Repartez de zéro par tâche. Ne faites pas une semaine de travaux sans rapport dans une seule session. Une nouvelle tâche dans un contexte propre est moins chère que la même tâche traînée derrière 80 000 tokens d'historique périmé, car cet historique se refacture à chaque tour.
Filtrez à la source. Faites passer les commandes bruyantes par un filtre pour que seules les lignes pertinentes atteignent l'agent. Le log complet reste disponible sur le disque ; le contexte reste léger.
Privilégiez les squelettes avant les lectures complètes quand la question porte sur la structure ou la localisation plutôt que sur une implémentation précise.
Réduisez votre surface MCP. Déconnectez les serveurs que vous n'utilisez pas cette session, et préférez les configurations qui chargent les schémas d'outils à la demande.
Mesurez. Vous ne pouvez pas ingénier ce que vous ne voyez pas. Observez où vont réellement les tokens — c'est généralement les lectures empressées et la sortie non filtrée — et dirigez votre effort là. La ventilation dans AI coding agent token costs est une bonne carte des endroits où l'argent se cache typiquement.

Si vous préférez ne pas tout coder à la main, c'est le vide que comble Tokenade : il se place entre votre agent et ses inputs et fait automatiquement la récupération, l'output filtering, la compression en squelette et le chargement paresseux de MCP, avec un dashboard montrant exactement ce que chaque geste a économisé. Il fonctionne avec Claude Code, Cursor, Codex, Copilot et Windsurf ; la source est disponible sous licence MIT, donc vous pouvez lire précisément ce qu'il fait à votre contexte avant de lui faire confiance. Gratuit jusqu'à ≈10M tokens par mois, puis Pro à 19,90 $/mois (hors taxe), postes illimités. Le playbook spécifique aux agents se trouve dans How to reduce Claude Code token usage.

Ce qui tourne mal (anti-patterns)

Les modes d'échec du context engineering sont presque tous des variations d'une seule erreur : confondre « plus de contexte » avec « meilleur contexte ». Lecture « au cas où ». L'agent — ou l'humain qui le pilote — charge les fichiers dont il pourrait avoir besoin plutôt que ceux dont il a besoin. Chaque lecture spéculative est refacturée pour le reste de la session. Plus de contexte ici signifie pire, pas meilleur : le signal pertinent se dilue dans du code non pertinent, et la qualité de réponse chute souvent alors même que le coût grimpe. Laisser les logs devenir du contexte. Traiter la sortie brute d'outil comme quelque chose que le modèle doit voir en entier. Ce n'est presque jamais le cas. Si vous trouvez un build log de 12 000 tokens dans votre transcript, ce sont douze mille tokens relus à chaque tour suivant pour trois lignes qui comptaient. Le caching comme substitut à la discipline. Le prompt caching est excellent, mais il récompense un préfixe stable. Un agent qui continue d'ajouter de nouvelles lectures continue de casser le cache là où il a ajouté. Le caching est un multiplicateur d'un bon context engineering, pas un remplacement. La session sans fin. Enchaîner tâche après tâche sans rapport dans un seul contexte parce que recommencer semble du gâchis. Ça ne l'est pas — c'est l'historique périmé qui est le gâchis. Le redémarrage propre est le geste le moins cher presque à chaque fois. Optimiser le modèle au lieu de l'input. Se tourner vers un modèle moins cher pour régler un problème de coût qui est en réalité un problème de contexte. Un contexte gonflé sur Haiku 4.5 reste un contexte gonflé ; vous avez juste baissé le tarif par token d'un travail qui ne devrait pas exister. Réglez d'abord l'input. Le choix du modèle est une décision de second ordre. Réglez bien le contexte et l'essentiel du problème de coût des agents s'évapore — non pas parce que vous avez trouvé une remise, mais parce que vous avez cessé de payer, encore et encore, pour de l'information dont l'agent n'a jamais eu besoin.

Voir aussi :