Qu'est-ce que le context engineering pour les agents de coding IA ?
Le context engineering est la pratique qui consiste à contrôler délibérément quelles informations un agent de coding IA lit dans son context window — ce qui y figure, comment c'est structuré et dans quel ordre — afin que le modèle produise de meilleures réponses en consommant moins de tokens. Pour un développeur solo qui utilise Claude Code, Cursor ou Cline toute la journée, cette discipline fait la différence entre un assistant qui trouve instantanément les trois fonctions pertinentes et un autre qui ingère l'intégralité du dépôt « par précaution » et vous facture en conséquence. Le concept a pris de l'ampleur à mesure que les agents de coding sont devenus plus autonomes. Dès qu'un agent peut appeler des outils, lire des fichiers, exécuter des commandes shell et boucler sur plusieurs tours, le contexte qu'il assemble à chaque étape ne se réduit plus à votre prompt — c'est un payload croissant de code, d'historique, de définitions d'outils et de sorties de commandes que le modèle relit en intégralité à chaque tour. Le context engineering est la façon de garder ce payload concis, pertinent et bien structuré. Si vous voulez le guide pratique complet — les six leviers, les chiffres, les victoires rapides — commencez par Comment réduire l'usage de tokens d'un agent de coding IA. Cet article approfondit la discipline elle-même.Pourquoi le context engineering compte-t-il plus que le prompt engineering ?
Le context engineering offre un levier bien supérieur au prompt engineering, car c'est dans le context window — et non dans la formulation des instructions — que résident la plupart des échecs des modèles modernes et l'essentiel du coût. Le prompt engineering ajuste une seule instruction. Le context engineering gère l'intégralité du payload que le modèle lit : le system prompt, l'historique complet de la conversation, chaque fichier récupéré, toutes les définitions d'outils chargées, chaque sortie de commande et tout matériau de référence — et ce à chaque tour d'une session agentique. Trois forces font de cette surface le levier le plus puissant : Le coût croît avec la taille du contexte, pas avec l'ingéniosité des instructions. Sur Claude Sonnet 4.6, un million de tokens en entrée coûte environ 3 $ ; sur Claude Opus 4.7, environ 15 $ (tarifs Anthropic, 2026). Une session agent multi-étapes peut faire transiter des centaines de milliers de tokens, et la grande majorité est une entrée que l'agent renvoie continuellement, pas une sortie qu'il génère. Réduire l'entrée, c'est réduire la facture directement. Les modèles prêtent moins attention au contenu situé au milieu d'une longue fenêtre. Des recherches de Liu et al. (« Lost in the Middle », 2023 — arxiv.org/abs/2307.03172) ont montré que la précision de récupération chute nettement pour les faits placés au milieu d'un contexte long. Un context window surchargé ne coûte pas seulement plus cher ; il dissimule des informations au modèle qui en a besoin. Élaguer le bruit améliore le rapport signal/bruit sans supprimer aucun signal. Les agents assemblent eux-mêmes leur contexte. Contrairement à un chat en un seul tour, un agent décide au fil de l'eau ce qu'il lit, quels outils il invoque et ce qu'il conserve dans la transcription. Si vous ne façonnez pas ses comportements par défaut, il sur-lit — car ouvrir un fichier entier est plus sûr que n'en ouvrir aucun, et ajouter un outil est gratuit jusqu'à ce que vous regardiez la facture. La conclusion : vous pouvez passer des heures à perfectionner votre prompt et regarder malgré tout l'agent brûler des tokens sur un fichier de 600 lignes dont il n'avait besoin que de deux fonctions. Renversez la priorité et ingénérez le contexte — même un prompt ordinaire produit alors des résultats précis et efficaces.Que contient le context window d'un agent — et quelles parties coûtent le plus ?
Le contexte d'un agent regroupe tout ce que le modèle lit lors d'un tour donné, assemblé à partir de plusieurs sources. Chacune est un levier que vous pouvez actionner :| Source | Taille typique | Renvoyé à chaque tour ? |
|---|---|---|
| System prompt et règles du projet | 500–5 000 tokens | Oui |
| Historique de conversation | Croissance non bornée | Oui |
| Code et fichiers récupérés | 2 000–30 000+ tokens | Oui (jusqu'à compaction) |
| Définitions d'outils (manifeste MCP) | 1 000–8 000 tokens | Oui |
| Sorties de commandes et d'outils | 500–50 000 tokens | Oui |
| Matériau de référence / docs | 1 000–10 000 tokens | Parfois |
Quelles sont les techniques concrètes de context engineering ?
Le context engineering se résume à six actions que vous pouvez appliquer à n'importe quel agent de coding :1. Récupérer par le sens, pas par déversement
Remplacez « lire ces fichiers » par une semantic code search qui ne retourne que les fonctions ou fragments pertinents pour la tâche. Une demande telle que « où est validé le token de connexion ? » doit donner à l'agent cette fonction précise — pas chaque fichier qui mentionne « token ». Bien exécutée, une tâche de navigation qui aurait lu 25 000 tokens de fichiers n'en lit que 2 000. Une bonne récupération sémantique est consciente du code : elle classe la définition d'un symbole avant ses usages, et le code source avant les fixtures de test, de sorte que le modèle voit la vérité de terrain en premier. L'article reduce-ai-coding-agent-token-usage contient un exemple complet et détaillé.2. Lire la structure avant le contenu
Quand l'agent a besoin de comprendre un module, donnez-lui le skeleton en premier : signatures, exports et déclarations de premier niveau plutôt que chaque ligne. Une vue axée sur la structure préserve toute la surface publique dont le modèle a besoin pour raisonner, tout en supprimant les corps de fonctions qu'il n'a pas demandés — réduisant typiquement la lecture d'un fichier de plus de moitié. L'agent peut toujours demander un corps spécifique une fois qu'il sait où chercher. C'est l'un des aspects de la context compression.3. Compresser les sorties de commandes et d'outils
Filtrez les sorties shell pour n'en garder que le signal avant qu'elles n'entrent dans la fenêtre. La plupart du bruit de CLI est prévisible et peut être supprimé sans risque : barres de progression, lignes de fichiers inchangés, avertissements répétés, tableaux décoratifs. Unnpm test en échec peut émettre 12 000 tokens de traces de pile et coches de tests réussis ; l'agent n'a besoin que d'environ 30 tokens — le nom du test et l'assertion cassée. L'output filtering lui transmet ces 30 tokens. Des options concises aident aussi : git status --porcelain et kubectl get -o name transmettent les mêmes faits en une fraction des tokens.
4. Charger les outils MCP en différé
Cessez d'annoncer chaque outil à chaque tour. Les agents qui utilisent MCP (Model Context Protocol) envoient souvent des dizaines de définitions d'outils dans le manifeste de contexte, renvoyées en intégralité que l'outil soit appelé ou non. Masquer les outils dont le binaire sous-jacent n'est pas installé, et charger le reste à la demande, supprime une taxe récurrente par tour qui croît avec le nombre d'intégrations connectées. Si vous avez accumulé plusieurs serveurs MCP au fil du temps, cela seul peut récupérer une part significative de chaque tour — voir Les meilleurs serveurs MCP pour Claude Code pour une liste sélectionnée qui vaut la peine d'être conservée.5. Mettre en cache le préfixe stable
Gardez les parties immuables de votre contexte dans une forme que le prompt cache du fournisseur peut servir à faible coût. Sur Claude, un token d'entrée mis en cache coûte environ 10 % d'un token neuf (docs prompt caching, 2026). Les system prompts, les conventions du projet et les docs de référence qui ne changent pas au cours d'une session doivent toucher ce cache à chaque tour après le premier. Cela ne réduira pas une seule requête, mais sur une longue session, l'effet se compose fortement — plus vous prenez de tours, plus l'économie de 90 % s'accumule.6. Ordonner le contenu par poids d'attention
Placez le matériau le plus décisif là où le modèle prête le plus attention : près du début de l'instruction de tâche ou du system prompt, et non enfoui au milieu d'une longue fenêtre. L'effet « lost in the middle » est réel et pratiquement significatif — si vos règles de projet sont coincées entre une longue lecture de fichier et un historique de conversation encore plus long, le modèle peut se comporter comme s'il ne les avait jamais lues. Mettez le signal en avant.Comment l'ordre du context window influe-t-il sur la qualité de l'agent ?
L'ordre est la technique de context engineering la plus sous-estimée, car elle est gratuite — elle ne nécessite aucune infrastructure — mais son effet sur la qualité des sorties peut être aussi important que l'ajout ou la suppression de milliers de tokens de contexte. Le principe d'ordre pratique est le suivant : placer d'abord le contenu stable et de haute autorité (system prompt, conventions, définition de la tâche), puis le matériau récupéré dynamiquement, et les sorties de commandes en dernier. Quand un contexte long est inévitable, répétez la contrainte la plus critique au début et à la fin, là où l'attention est la plus élevée. Évitez de sandwicher l'instruction entre deux larges blobs récupérés. Pour les sessions agentiques en particulier : la description de tâche propre à l'agent doit être la première chose dans son prompt de sous-tour, pas une réflexion après coup ajoutée après le fichier qu'il vient de lire. C'est particulièrement pertinent pour les patterns d'agentic coding où l'agent compose son contexte dynamiquement — un scaffolding d'agent bien conçu place l'objectif avant les preuves, à chaque fois.Comment mesurer si votre context engineering fonctionne ?
On n'améliore que ce qu'on mesure. Trois métriques comptent : Volume de tokens par session — le nombre brut de tokens d'entrée facturés sur tous les tours. Utilisez-le comme référence, puis appliquez une technique et comparez. La plupart des fournisseurs exposent cela dans leurs réponses d'API ou leurs tableaux de bord d'utilisation. Ratio contexte/sortie utile — en gros, combien de tokens d'entrée le modèle a-t-il lus par ligne de sortie significative produite ? Un ratio élevé (par ex. 200:1) signale que la plupart de ce que l'agent lit n'influence pas ses réponses. Un ratio qui baisse après application du filtrage indique que le filtrage fonctionne. Précision de la tâche en fonction de la taille du contexte — pour des tâches de benchmark répétées (corriger ce test, implémenter cette fonction), la qualité des réponses reste-t-elle stable ou s'améliore-t-elle lorsque le contexte rétrécit ? Si la qualité chute quand vous supprimez une source spécifique, cette source était indispensable ; si elle se maintient ou s'améliore, vous envoyiez du bruit. Le propre benchmark de Tokenade a montré jusqu'à ~88 % de tokens en moins sur un mix de sessions équilibré avec une qualité de sortie maintenue. Un point de départ simple : activez la journalisation d'utilisation de votre agent, exécutez la même tâche deux fois — une fois avec des lectures brutes et une fois avec une récupération structurée — et comparez les totaux de tokens. L'écart est généralement saisissant.Quels sont les anti-patterns courants du context engineering ?
Les anti-patterns sont des comportements qui semblent corrects mais nuisent activement à la qualité ou au coût : « Plus de contexte = de meilleures réponses. » C'est le modèle mental le plus néfaste dans le développement agentique. Au-delà d'un certain point, un contexte supplémentaire dégrade la qualité en enfouissant le signal dont le modèle a besoin. L'agent qui lit 40 fichiers au lieu de 4 ne produit pas une sortie 10× meilleure — il produit une sortie moins bonne à 10× le prix. Optimiser la sortie au lieu de l'entrée. Demander au modèle « d'être concis » réduit la partie bon marché. La sortie est générée une fois ; l'entrée est relue à chaque tour. Avec la sortie tarifée à environ 5× l'entrée par token, il faut supprimer beaucoup de caractères en sortie pour compenser la suppression de n'importe quelle lecture en entrée. Corrigez la source. Laisser l'historique croître sans limite. Les longues sessions repaient chaque sur-lecture initiale à chaque tour suivant. Résumez les anciens tours, compactez agressivement ou découpez les longues sessions en tâches plus courtes et ciblées. Le coût de ne pas le faire est linéaire en longueur de session. Accumuler des intégrations MCP. Chaque serveur connecté que vous n'appelez jamais gonfle tout de même le manifeste par tour. Élaguez jusqu'aux outils que vous utilisez réellement, et chargez le reste à la demande. Commencer par l'incertitude. Démarrer une tâche en lisant l'intégralité du codebase « pour s'orienter » est l'équivalent agentique de lire un livre entier avant d'écrire un résumé d'une page. Commencez par la récupération spécifique qu'exige la tâche ; élargissez seulement si l'agent est véritablement bloqué. Confondre précision de récupération et portée. « Chercher tout ce qui est lié à l'auth » n'est pas une récupération précise — c'est un déversement avec des étapes supplémentaires. Un bon prompt de context engineering nomme le comportement ou le symbole spécifique, pas le domaine.Tokenade peut-il appliquer le context engineering automatiquement ?
Oui — c'est exactement ce que fait Tokenade. Il se place entre votre agent de coding IA et les outils qu'il appelle, et applique les techniques ci-dessus sans aucune configuration par prompt :- La semantic code search remplace les déversements de fichiers par une récupération basée sur le sens.
- L'output filtering compresse les logs de build, les sorties de tests et les commandes shell jusqu'à leur signal avant qu'ils n'atteignent le modèle.
- Les lectures structure-first donnent à l'agent des skeletons avant les corps complets de fichiers.
- Le chargement différé des outils MCP masque les outils inutilisés et charge le reste à la demande.
Foire aux questions
Le context engineering est-il la même chose que le RAG ?
Ils se recoupent mais ne sont pas identiques. La génération augmentée par récupération (RAG) est une technique parmi d'autres au sein du context engineering — spécifiquement, l'étape de récupération qui décide quels fragments de connaissance entrent dans la fenêtre. Le context engineering est la discipline plus large : il englobe aussi la façon dont le contenu récupéré est compressé et ordonné, ce qui figure dans le system prompt, quels outils sont chargés, comment les sorties de commandes sont filtrées et comment l'historique est géré. Pensez au RAG comme à un levier ; le context engineering est l'ensemble des leviers.Le context engineering nécessite-t-il de modifier le code de mon agent ?
Pas si vous utilisez un outil en couche proxy. Le context engineering peut être appliqué au niveau de l'infrastructure — entre l'agent et les outils qu'il appelle — sans modifier le code source de l'agent lui-même. C'est le pattern proxy : l'agent appelle les outils normalement, et le proxy façonne ce que chaque outil retourne avant que cela n'atteigne le modèle. Vous obtenez les bénéfices sans toucher aux entrailles de l'agent.Réduire le contexte va-t-il nuire à la précision de mon agent ?
Bien fait, réduire le contexte améliore la précision. Les leviers ici suppriment le contenu de faible valeur — logs standard, fichiers non pertinents, définitions d'outils inutilisés — pas le signal sur lequel le modèle raisonne. Parce que l'effet d'attention « lost in the middle » est réel, une fenêtre plus légère signifie souvent que le contenu important se retrouve là où le modèle prête le plus attention. On perd en précision seulement quand on supprime quelque chose d'indispensable — c'est pourquoi les lectures structure-first conservent toutes les signatures publiques et les output filters gardent le message d'erreur réel.En quoi le context engineering diffère-t-il du prompt caching ?
Le prompt caching est une optimisation de facturation : il permet aux fournisseurs de facturer moins cher un contexte que le modèle a déjà traité au cours de cette session. Le context engineering est une discipline d'architecture de l'information : il décide ce qui entre dans le contexte en premier lieu. Les deux fonctionnent ensemble — un contexte bien conçu qui garde le préfixe stable en haut est aussi le plus favorable au cache. Mais on peut avoir un contexte parfaitement mis en cache qui reste plein de bruit ; le caching ne guérit pas la sur-lecture.Cela s'applique-t-il aux agents non liés au code ?
Oui, mais les techniques spécifiques varient. L'output filtering et l'élagage des outils MCP s'appliquent à tout agent qui appelle des outils externes ou exécute des commandes shell. La récupération sémantique s'applique partout où il existe un large corpus à explorer (une base de connaissances, un entrepôt documentaire, un codebase). Les lectures structure-first sont spécifiques au code. Les principes d'ordre et d'attention sont universels. La plupart de ce qui est écrit ici se transpose directement aux agents manipulant beaucoup de documents ou de données ; les exemples concrets proviennent simplement du contexte du coding parce que c'est là que les coûts sont les plus visibles.À lire aussi :
- Comment réduire l'usage de tokens d'un agent de coding IA — les six leviers pratiques, avec les chiffres.
- Réduire l'usage de tokens de Claude Code — les mêmes techniques appliquées spécifiquement à Claude Code.
- Agentic coding — comment l'autonomie change le contexte qu'un agent assemble.
- Les meilleurs serveurs MCP pour Claude Code — quelles intégrations valent la peine d'être chargées (et lesquelles élaguer).
- Coûts en tokens des agents de coding IA — les prix qui justifient de faire du context engineering.
Up to 88% fewer tokens. Zero config.
Tokenade is the simplest way to cut what your coding agent sends to the model — set it up once, save on every prompt. Works with Claude Code, Cursor, Codex, Copilot & more.