Qu'est-ce que l'agentic engineering ?
L'agentic engineering est la discipline qui consiste à concevoir délibérément la boucle dans laquelle tourne un agent de codage IA autonome — ce qu'il lit, les outils qu'il peut appeler, ce qu'il conserve dans sa context window, et ce qu'il fait des résultats — afin que l'agent reste précis tout en dépensant beaucoup moins de tokens. Cela se situe un cran au-dessus du prompting et un cran en dessous de « on espère juste que le modèle s'en sortira ». J'ai passé les deux dernières années à construire des outils qui s'insèrent dans cette boucle, et le moyen le plus fiable de rendre un agent à la fois moins coûteux et meilleur est d'ingénierer la boucle elle-même plutôt que de harceler le modèle avec un system prompt plus long. Si c'est désormais une discipline à part entière, et non une note de bas de page dans un guide de prompting, c'est parce que les agents ont cessé d'être one-shot. Un agent de codage moderne lit des fichiers, lance votre suite de tests, fait des grep sur le dépôt, appelle une base de données, boucle sur la sortie et réessaie. Chacune de ces étapes renvoie au modèle une charge utile grandissante de code, d'historique, de schémas d'outils et de logs de commandes. Le prompt engineering optimise un message. L'agentic engineering optimise toute la boucle de feedback dans laquelle ce message vit. Si vous voulez la liste concrète des leviers plutôt que la philosophie, commencez par comment réduire la consommation de tokens d'un agent de codage IA ; cet article-ci porte sur la discipline qui relie ces leviers entre eux.En quoi l'agentic engineering diffère-t-il du prompt engineering et du vibe coding ?
L'agentic engineering agit sur la boucle ; le prompt engineering agit sur une seule instruction ; le vibe coding agit sur le feeling. Ce ne sont pas tant des concurrents que trois altitudes différentes. Le prompt engineering demande : « quelle formulation donne la meilleure réponse unique ? » Cela comptait énormément à l'ère du chat et compte encore à la marge. Mais dans une session agentique, la formulation de votre instruction est une erreur d'arrondi face aux centaines de milliers de tokens que l'agent assemble de lui-même au fil d'une douzaine de tours. Le vibe coding ne demande rien — vous décrivez ce que vous voulez, vous laissez l'agent tourner, et vous acceptez ce qui en sort. C'est réellement utile pour des prototypes jetables, et je le fais plus souvent que je ne l'avouerais en entretien d'embauche. Le problème, c'est que les réglages par défaut de l'agent sont calibrés pour « ne jamais rater de contexte », et non pour « dépenser intelligemment » ; une session de vibe coding lit donc en silence des fichiers entiers, charge tous les outils MCP et déverse la sortie brute des commandes dans la window. Amusant jusqu'à l'arrivée de la facture. L'agentic engineering, c'est la version adulte du vibe coding. Vous gardez la rapidité, mais vous concevez la boucle pour que les réglages par défaut de l'agent cessent de jouer contre vous. Concrètement, cela recoupe largement le context engineering — le context engineering est la partie de l'agentic engineering qui régit ce qui entre dans la window. L'agentic engineering est plus large : il couvre aussi quels outils existent, comment l'agent décide d'agir, quand il s'arrête, et comment sa sortie est mise en forme avant de reboucler. Voyez le context engineering comme la gestion de charge, et l'agentic engineering comme la conception de toute la machine.Pourquoi la boucle de l'agent coûte-t-elle tellement plus cher qu'un simple prompt ?
La boucle de l'agent coûte plus cher parce que l'input est renvoyé à chaque tour, et que l'input représente l'essentiel de la facture. C'est le fait qui recadre tout le reste. Quand vous envoyez un message à un modèle, vous payez ce message une fois. Quand un agent lance une session de 15 tours, le system prompt, l'historique de la conversation, chaque fichier qu'il a lu et chaque schéma d'outil qu'il a chargé sont re-soumis en input à chaque tour suivant. L'output — les tokens que le modèle génère réellement — n'est qu'une fraction faible et à croissance lente. L'input est la partie grasse, et elle s'accumule. La tarification rend cela concret. Sur Claude Sonnet 4.6, l'input coûte environ 3 $ par million de tokens et l'output 15 $ ; sur Opus 4.8, c'est 5 $ d'input et 25 $ d'output ; sur GPT-5.5, 5 $ d'input et 30 $ d'output (tarification Anthropic ; tarification OpenAI, 2026). Comme l'input domine une session d'agent, c'est le prix de l'input qui décide de votre facture. Il existe une grande échappatoire : le prompt caching. Un cache read coûte environ 10 % du prix normal d'input, donc un contexte avec un préfixe stable que le modèle a déjà traité dans cette session est peu coûteux à renvoyer. C'est précisément pourquoi l'agentic engineering et le caching se renforcent mutuellement — une boucle conçue pour garder les parties stables en haut de la window est aussi celle qui se met le mieux en cache. Il y a un second coût, moins évident : l'attention. Liu et al. (« Lost in the Middle », 2023 — arxiv.org/abs/2307.03172) ont montré que les modèles retrouvent bien moins fiablement les faits placés au milieu d'un long contexte que ceux situés aux extrémités. Une boucle gonflée ne coûte pas seulement de l'argent ; elle enterre l'information même dont l'agent a besoin. Ingénierer la boucle paie donc deux fois : une facture plus légère et un agent plus affûté.À quoi ressemble concrètement une boucle d'agent bien ingénierée ?
Une boucle bien ingénierée contrôle quatre surfaces — la récupération, les outils, la sortie et l'historique — au lieu de laisser les réglages par défaut de l'agent s'emballer sur chacune. Voici ce que chaque surface vous coûte quand on l'ignore, et le levier qui la corrige.| Surface | Mode d'échec par défaut | Le levier |
|---|---|---|
| Récupération | Lit des fichiers entiers « au cas où » | Semantic code search + lectures skeleton-first |
| Outils | Charge tous les schémas MCP d'emblée | Chargement paresseux des outils MCP |
| Sortie | Déverse les logs bruts dans la window | Output filtering |
| Historique | Croît sans limite à chaque tour | Compression de contexte |
Comment appliquer l'agentic engineering dès aujourd'hui ?
Commencez par mesurer, puis tirez les quatre leviers par ordre de rentabilité. Concrètement :- Mesurez avant d'optimiser. Vous ne pouvez pas ingénierer une boucle que vous ne voyez pas. Obtenez une ventilation des tokens par tour pour savoir si c'est la récupération, les outils, la sortie ou l'historique qui constitue la partie grasse. Notre calculateur de coût en tokens LLM transforme un nombre de tokens en montant en euros, et le compteur de tokens vous dit quelle taille fait réellement un blob donné.
- Tuez d'abord le bruit de sortie. C'est le gain le moins coûteux et généralement le plus important. Filtrez les logs de commandes et la sortie des tests pour ne garder que les lignes qui changent une décision.
- Passez les lectures de l'ingestion à la récupération. Par défaut, optez pour les skeletons et la semantic search ; ne laissez l'agent monter à une lecture complète que lorsque c'est justifié.
- Élaguez vos outils. Auditez les serveurs MCP que vous avez chargés — voyez les meilleurs serveurs MCP pour Claude Code — et chargez les schémas paresseusement.
- Ensuite, et seulement ensuite, ajustez le prompt. Une fois la boucle épurée, la formulation des instructions se remet à compter, parce qu'elle n'est plus noyée sous le bruit.
Ce qui dérape (anti-patterns)
Les modes d'échec sont ici prévisibles, et c'est la bonne nouvelle — vous pouvez les repérer avant qu'ils ne vous coûtent. Optimiser le prompt pendant que la boucle saigne. Passer un après-midi à peaufiner votre system prompt pendant que l'agent relit un fichier de 2 000 lignes à chaque tour, c'est déplacer les transats sur le pont. Corrigez d'abord la boucle. Couper du contexte porteur. L'erreur inverse : élaguer si agressivement que vous retirez le signal. La règle est de couper le contenu à faible valeur — logs boilerplate, fichiers hors sujet, schémas d'outils inutilisés — jamais les signatures et messages d'erreur sur lesquels le modèle raisonne. Les lectures structure-first fonctionnent justement parce qu'elles conservent chaque signature publique. Traiter le caching comme un substitut à la conception de boucle. Le prompt caching rend un contexte bruyant moins coûteux à renvoyer ; il ne le rend pas moins bruyant. Une boucle parfaitement mise en cache mais pleine de fichiers hors sujet nourrit toujours le modèle de déchets, à 10 % du prix. Mettez en cache et ingénierez. Supposer que des context windows plus grandes règlent le problème. Une window plus grande ne fait que relever le plafond de ce que vous pouvez gaspiller, et l'effet « lost in the middle » signifie que vous obtiendrez une moins bonne récupération en prime. La capacité n'est pas une stratégie. Le fil conducteur : l'agentic engineering, c'est ce que vous faites au lieu d'espérer que le modèle et votre portefeuille s'arrangent entre eux. Concevez la boucle, mesurez le résultat, et l'agent moins coûteux et l'agent plus intelligent se révèlent être le même agent.À voir aussi :
- Comment réduire la consommation de tokens d'un agent de codage IA — les six leviers concrets, chiffres à l'appui.
- Le context engineering pour les agents de codage IA — la partie de l'agentic engineering qui régit la context window.
- Agentic coding — comment l'autonomie change ce qu'un agent assemble à chaque tour.
- Vibe coding — l'extrémité sans discipline du spectre, et les cas où c'est très bien ainsi.
- Les meilleurs optimiseurs de tokens pour Claude Code — les outils qui implémentent ces leviers pour vous.
Classé n°1 au Token-Harness Optimizer Leaderboard.
Tokenade est classé n°1 au Token-Harness Optimizer Leaderboard — un benchmark de bout en bout des optimiseurs de tokens, mesuré sur de vraies sessions de code. Installez-le une fois, il agit sur chaque prompt. Compatible avec Claude Code, Cursor, Codex, Copilot et plus.