Agentic Coding : ce que c'est et son vrai coût

Qu'est-ce que l'agentic coding ?

L'agentic coding, c'est quand un assistant IA ne se contente pas de répondre à une question — il planifie et exécute de manière autonome une tâche de développement en plusieurs étapes : lire des fichiers, lancer des commandes, modifier du code, observer les résultats, et recommencer jusqu'à atteindre l'objectif. Vous lui donnez un but ; l'agent fait le reste. Des outils comme Claude Code, le mode agent de Cursor, Codex d'OpenAI, le mode agent de GitHub Copilot, Cline, Aider, Windsurf, Kilo Code, OpenCode, Roo Code et Hermes Agent fonctionnent tous de cette façon.

Le mot « agentic » désigne une chose précise : le modèle a accès à des outils et boucle sur ses propres sorties. Un simple chat ne boucle pas. L'autocomplétion prédit les prochains tokens une seule fois. Un agent agit, vérifie, ajuste, et agit à nouveau — potentiellement des dizaines de fois pour une seule requête.

Cette distinction est cruciale pour les coûts. Chaque action dans la boucle a un prix, et les prix s'accumulent.

En quoi l'agentic coding diffère-t-il de l'autocomplétion ou du chat ?

La différence tient à la présence d'une boucle d'utilisation d'outils où le modèle contrôle ce qu'il lit ensuite.

En mode chat, c'est vous qui décidez ce qui entre dans le prompt. En mode agentic, l'agent décide quels fichiers lire, quelles commandes lancer, quels outils appeler — et il prend ces décisions à chaque tour, en accumulant du contexte au fil du temps. C'est ce qui rend l'agentic coding qualitativement différent d'une autocomplétion plus intelligente : le modèle est aux commandes pour la récupération du contexte, pas seulement pour la génération de code.

C'est aussi pourquoi les outils agentiques paraissent tellement plus capables. Un agent peut analyser un test en échec, remonter la pile d'appels, ouvrir les modules concernés, appliquer un correctif ciblé, relancer les tests et confirmer — sans que vous ayez à lever le petit doigt après la première requête. La contrepartie, c'est que chacune de ces étapes a un coût en tokens.

À quoi ressemble concrètement la boucle agentique ?

La boucle d'agent canonique comporte quatre phases qui se répètent jusqu'à ce que la tâche soit accomplie ou que l'agent abandonne :

1. Planifier. Compte tenu du contexte courant (transcript, observations précédentes, outils disponibles), le modèle décide quoi faire ensuite — « Je devrais lire auth/session.ts pour comprendre le format du token. »
2. Agir. Le modèle appelle un outil : lit un fichier, exécute une commande shell, recherche dans le code, modifie une fonction, appelle un serveur MCP.
3. Observer. La sortie de l'outil — le contenu du fichier, le résultat de la commande, les résultats de recherche — est ajoutée au contexte, que le modèle relit.
4. Recommencer. Le modèle évalue si l'objectif est atteint. Sinon, il planifie l'étape suivante.

La boucle est élégante et efficace. Le problème vient de l'étape 3 : chaque observation devient l'entrée du prochain tour. Et du suivant. Et de chaque tour jusqu'à la fin de la session. Rien ne quitte la context window de lui-même.

Pourquoi l'agentic coding consomme-t-il autant de tokens ?

L'agentic coding brûle des tokens parce que la boucle relit un contexte en constante expansion à chaque tour, et ce coût se cumule à chaque étape de la session.

Prenons un scénario réaliste. Vous demandez à l'agent de corriger un bug. Il :

1. Lit la structure du projet (~3 000 tokens de liste de répertoires)
2. Ouvre trois fichiers candidats (~8 000 tokens de code source)
3. Exécute le test en échec (~4 000 tokens de sortie)
4. Lit deux autres fichiers après avoir remonté la pile (~6 000 tokens)
5. Effectue la modification (quelques centaines de tokens)
6. Relance les tests (~4 000 tokens de sortie)

À l'étape 6, la context window contient environ 25 000 tokens de matériel accumulé — et la totalité est renvoyée au modèle comme entrée pour produire la maigre réponse de l'étape 6. L'agent n'oublie pas ; il relit.

Imaginez maintenant que la correction prenne 12 étapes au lieu de 6, et qu'une d'elles déclenche un npm install verbeux ou un plan Terraform avec 200 lignes de ressources. Ça s'emballe vite.

La partie coûteuse, c'est rarement le code que l'agent écrit. Les tokens en sortie ont un impact, et sur toute la gamme Anthropic actuelle la sortie est facturée cinq fois le prix de l'entrée, palier par palier — Sonnet 5.5 à 2 $ / 10 $ par million de tokens, Opus 5.5 à 4 $ / 20 $, Fable 5.1 à 10 $ / 50 $ (tarifs Anthropic, octobre 2026). En volume, c'est l'inverse : une longue session agentique peut générer 500 tokens en sortie par tour tout en relisant 15 000 tokens en entrée. Le calcul fait de l'entrée le coût dominant, et la majorité de cette entrée, c'est l'agent qui réingère un contexte qu'il a déjà traité. Pour une vue concrète de ce que ces chiffres donnent sur les outils populaires, voir Coûts en tokens des agents de coding IA.

Ce qui fait grimper les coûts — les cinq vrais coupables

Comprendre où vont les tokens est la première étape pour les maîtriser. Cinq patterns représentent la majorité de la facture d'une session type :

1. Lecture de fichiers entiers pour des tâches à fonction unique. L'agent ouvre auth/session.ts parce qu'il a besoin de validateToken. Le fichier fait 450 lignes — environ 5 000 tokens. L'agent avait besoin de peut-être 20 lignes. Il en a lu 450. Et il relit les 450 à chaque tour suivant.

2. Sortie de commandes non filtrée. npm test émet 200 lignes de coches, de données temporelles et d'une stack trace en bas. La stack trace est le signal utile. Les 190 lignes décoratives sont du lest qui rentre dans la boucle verbatim. Un log de build ou un dump kubectl get pods peuvent représenter des dizaines de milliers de tokens — la plupart du standard que l'agent ignore mais paye quand même.

3. Lectures exploratoires de répertoires. Quand l'agent ne sait pas où se trouve quelque chose, il explore. Il liste des répertoires, parcourt des arborescences, ouvre des modules connexes « au cas où ». Fait naïvement, orienter l'agent dans une base de code de taille moyenne peut consommer plus de tokens que le travail lui-même.

4. Un manifeste d'outils surchargé. Les agents qui parlent MCP (Model Context Protocol) chargent les définitions d'outils dans le contexte — et les renvoient à chaque tour. Un agent connecté à dix serveurs MCP peut préfixer des milliers de tokens de schémas d'outils à chaque requête, même s'il n'en appelle aucun dans ce tour. Certains agents atténuent désormais le problème : en octobre 2026, Claude Code diffère par défaut les schémas complets des outils MCP et ne garde en contexte que les noms d'outils et les instructions des serveurs jusqu'à ce qu'un outil serve (documentation MCP de Claude Code). Noms et instructions voyagent malgré tout à chaque tour, et tous les agents ne diffèrent pas.

5. Longues sessions sans compaction. Un agent qui tourne depuis 50 tours paye, à chaque tour, pour le contexte accumulé aux tours 1 à 49. Les lectures antérieures ne rétrécissent pas. Le transcript grossit. Le tour 50 relit tout depuis le début.

Chaque coupable correspond à un levier. Une bonne pratique de context engineering adresse les cinq.

Quels outils d'agentic coding sont disponibles ?

Le secteur a évolué rapidement. En octobre 2026, les outils notables se répartissent en quelques catégories :

Agents orientés terminal qui s'intègrent à votre shell et peuvent lire, modifier, exécuter et interroger l'ensemble de votre projet. Claude Code (Anthropic), la Codex CLI (OpenAI), ainsi qu'Aider et OpenCode (open source) en sont les exemples les plus connus. Ils sont puissants mais offrent l'accès au contexte le plus ouvert, ce qui rend les sessions non guidées coûteuses.

Agents intégrés à l'IDE qui vivent dans votre éditeur et s'intègrent étroitement avec l'arborescence de fichiers et le serveur de langage. Cursor et Windsurf sont les options commerciales les plus populaires ; Cline, Kilo Code et Roo Code sont des extensions open source pour VS Code. Le mode agent de GitHub Copilot fonctionne dans VS Code et JetBrains.

Agents cloud qui s'exécutent dans un environnement isolé avec leur propre infrastructure. Le mode cloud de Codex, le coding agent de GitHub Copilot (vous lui assignez une issue, il ouvre une pull request) et les sessions cloud de Claude Code fonctionnent ainsi — vous déléguez une tâche et ils retournent un diff.

Agents généralistes de longue durée comme Hermes Agent (Nous Research, open source), qui gardent mémoire et skills d'une session à l'autre et se pilotent depuis un terminal, une app desktop ou des messageries. Ils codent, mais le code n'est qu'une de leurs tâches.

Pour une comparaison approfondie des différences de capacités et d'économie entre ces outils, voir Meilleurs outils de coding IA. En résumé : l'outil que vous choisissez importe moins pour les coûts que la façon dont vous configurez son accès au contexte.

Comment garder l'agentic coding abordable ?

Les cinq coupables ci-dessus ont cinq réponses correspondantes :

Remplacer les lectures de fichiers entiers par de la récupération sémantique. Plutôt que d'ouvrir des fichiers pour trouver du code pertinent, utilisez une recherche qui retourne les fonctions ou classes spécifiques par leur sens. Un semantic code search sur « valider le token de connexion » retourne les trois fragments pertinents — pas les trois fichiers qui les entourent. Une tâche qui aurait lu 25 000 tokens de fichiers n'en lit plus que 2 000. C'est le levier le plus puissant pour les sessions à forte navigation.

Filtrer la sortie des commandes avant qu'elle entre dans la boucle. Supprimer les barres de progression, les tableaux décoratifs et les avertissements répétés de la sortie des commandes est sans perte : le modèle voit le résultat, pas le flux brut. Des flags concis aident aussi — git status --porcelain, kubectl get pods -o name, npm test --reporter=min. Un filtrage par format peut réduire un log de build typique de 90 % sans perte de sens.

Lire la structure avant le contenu. Donnez à l'agent les signatures de fonctions et les exports plutôt que les corps de fichiers complets. Une vue squelette d'un module préserve toute la surface publique sur laquelle l'agent raisonne, tout en écartant l'implémentation dont il n'a pas encore besoin. L'agent peut toujours demander le corps d'une fonction spécifique une fois qu'il sait où chercher. C'est une moitié de la context compression.

Charger les outils à la demande. Masquez les serveurs MCP dont le binaire sous-jacent n'est pas installé. Supprimez les définitions d'outils jusqu'à ce que l'agent en ait réellement besoin. Chaque outil retiré du manifeste est une taxe supprimée à chaque tour. Si vous avez connecté une douzaine d'intégrations au fil du temps, les auditer et les élaguer représente des économies immédiates. Dans Claude Code, lancez /context pour voir ce qu'occupent vos serveurs et /mcp pour désactiver ceux qui ne servent pas ; son tool search intégré diffère déjà les schémas complets, sauf si vous passez par un proxy tiers.

Compacter ou redémarrer les longues sessions. Soit vous utilisez la compaction intégrée de l'agent (Claude Code a /compact), soit vous redémarrez avec un résumé plutôt que le transcript complet quand la session devient longue. Les premiers tours portent le contexte le plus obsolète et la moins grande valeur.

L'analyse complète de ces leviers — avec des chiffres — se trouve dans Comment réduire l'utilisation de tokens des agents de coding IA.

Si vous préférez ne pas câbler chaque levier manuellement, Tokenade les applique tous automatiquement — semantic search, compression de sortie, lectures squelette, chargement MCP à la demande — en une seule commande, pour les agents que vous utilisez déjà. Sur le benchmark ouvert THOL, il réduit de 39 % sur les longues sessions par rapport à l'absence d'outil — et c'est le seul des douze outils testés qui fait réellement baisser la facture. Il démarre par un essai gratuit de 7 jours, puis coûte 1 % de ce qu'il économise — sans abonnement, sans plafond.

Ce qui tourne mal — les anti-patterns

Même en connaissant la théorie, quelques patterns reviennent régulièrement dans les sessions coûteuses :

Des objectifs vagues et ouverts. « Améliore le système d'auth » est un chèque en blanc pour l'exploration. L'agent lit largement parce que le but est large. Réduisez la portée : « Le refresh JWT échoue quand le fuseau horaire de l'utilisateur est UTC+14 — tracez ça dans auth/refresh.ts. » La portée est le seul levier qui ne coûte rien et qui multiplie l'effet de tous les autres.

Laisser la sortie brute s'accumuler. Un build en échec ou un test run déversé verbatim dans le contexte est payé à chaque tour suivant. Un log verbeux dans une session de 20 tours signifie que ce log est lu 20 fois. Filtrez avant qu'il arrive, pas après.

Ne jamais redémarrer ni compacter. Une session marathon de 80 tours repaye l'intégralité de son historique à chaque nouvelle requête. Les tours d'il y a 20 minutes portent rarement plus de signal qu'un résumé en un paragraphe. Redémarrez plus agressivement.

Accumuler des intégrations MCP. Chaque outil que vous ajoutez à un serveur MCP est annoncé à l'agent à chaque tour, qu'il soit utilisé ou non. Ajouter des outils paraît anodin ; le coût par tour est invisible. Auditez régulièrement.

Essayer de réduire les coûts en demandant au modèle d'être bref. « Sois concis » réduit la sortie — le côté le moins cher. Le volume de tokens se trouve dans l'entrée. Demander des réponses plus courtes tout en laissant un contexte gonflé inchangé, c'est optimiser dans le mauvais sens.

Foire aux questions

L'agentic coding coûte-t-il toujours plus cher que le chat classique ?

Pour toute tâche comptant plus de deux ou trois étapes, oui — la boucle multiplie le contexte entre les tours d'une façon qu'un seul prompt de chat ne peut pas égaler. Pour des questions simples et autonomes, une boucle agentique ajoute de la surcharge sans bénéfice. Le bon outil pour les questions à un seul tour, c'est un seul tour. Le mode agentic mérite sa place sur les tâches en plusieurs étapes où l'alternative serait une coordination manuelle par copier-coller entre de nombreux prompts.

Combien de tokens une session agentique typique consomme-t-elle ?

Ça varie énormément. Une courte session de correction de bug sur une base de code propre peut se terminer en 10 000–30 000 tokens. Une session de développement de fonctionnalité plus longue avec des lectures exploratoires, des exécutions de tests et des allers-retours sur un grand projet peut facilement atteindre 300 000–500 000 tokens — parfois plus. Le principal facteur est la quantité de contenu de fichiers et de commandes que l'agent ingère, ce qui dépend de la taille de la base de code, de la portée de la tâche et de l'agressivité de son exploration. Les fourchettes ci-dessus sont des ordres de grandeur illustratifs, pas des mesures : c'est votre propre usage qui tranche. La consommation de tokens par type de tâche la détaille tâche par tâche, et mesurer la consommation d'un agent montre comment obtenir votre propre référence plutôt que de croire l'estimation d'un tiers.

Est-il possible de voir combien de tokens chaque étape de l'agent coûte ?

Oui. Dans Claude Code, /usage affiche la consommation de tokens de la session et /context ce qui remplit la fenêtre (documentation coûts de Claude Code, octobre 2026). Cursor et Codex exposent l'utilisation dans leurs propres tableaux de bord. Tokenade inclut un tableau de bord en temps réel qui décompose les dépenses en tokens par type (lectures de fichiers, sorties d'outils, réponse du modèle) afin que vous puissiez voir exactement où va le budget et quel levier activer en premier.

Ces patterns de coûts s'appliquent-ils de la même façon aux agents hébergés (Codex cloud, etc.) ?

Les mêmes mécanismes de boucle s'appliquent, mais la surface de facturation est différente. Les agents cloud peuvent facturer par tâche ou par diff plutôt que par token, ce qui peut masquer le coût sous-jacent. Les stratégies restent pertinentes : un agent cloud qui se termine en moins d'étapes avec moins de contexte s'exécutera plus vite et, sur une tarification par tâche, finira souvent dans un palier d'utilisation plus bas.

Pourquoi l'agent lit-il des fichiers que je ne lui ai pas demandé de lire ?

Parce que le contexte de la tâche est suffisamment ambigu pour que l'agent couvre ses arrières. Quand un objectif a plusieurs chemins plausibles, l'agent lit largement pour réduire sa propre incertitude avant de s'engager dans une approche. C'est un comportement rationnel étant donné ses informations — mais c'est coûteux. Fournir plus de contexte en amont (le fichier concerné, la fonction spécifique, le message d'erreur exact) réduit cette incertitude et la lecture qui s'ensuit.

---

À lire aussi :

• Comment réduire l'utilisation de tokens des agents de coding IA — les six leviers, avec des chiffres.
• Context engineering pour les agents de coding IA — la discipline derrière la gestion de ce que lit la boucle.
• Bonnes pratiques de l'agentic coding — comment bien mener la boucle, pas seulement à moindre coût.
• Agentic engineering — la discipline plus large autour de la boucle.
• Agentic terminal coding — ce qui change quand l'agent vit dans votre shell.
• Sécuriser le budget d'un agent qui tourne la nuit — les garde-fous avant de laisser une boucle sans surveillance.
• Benchmarks de coût de l'agentic coding (2026) — les coûts mesurés par tâche selon les agents.
• Meilleurs outils de coding IA — comparaison d'outils pour les workflows agentiques.
• Coûts en tokens des agents de coding IA — les prix derrière le calcul.
• Context window — ce que l'agent peut voir à chaque tour.
• MCP (Model Context Protocol) — comment fonctionnent les manifestes d'outils.
• Context compression — la technique derrière les lectures structure-first.