Qu'est-ce que l'agentic terminal coding ?

Qu'est-ce que l'agentic terminal coding ?

L'agentic terminal coding, c'est lorsqu'un agent IA vit dans votre terminal et pilote tout seul une tâche de codage en plusieurs étapes — lire des fichiers, lancer des commandes shell, modifier du code, observer la sortie, et boucler jusqu'à ce que le travail soit terminé. La partie « terminal », c'est l'interface : au lieu d'un panneau de chat greffé sur un éditeur, l'agent s'exécute comme un processus en ligne de commande avec un accès direct à votre shell, à votre système de fichiers, et à tous les outils que vous avez branchés. Claude Code, le Codex CLI d'OpenAI, Aider, OpenCode et Gemini CLI entrent tous dans cette catégorie. J'ai passé beaucoup de temps à regarder ces agents travailler, et le cadrage « terminal » change l'ergonomie plus que ce à quoi on s'attend. Un agent de terminal n'est pas confiné derrière l'API d'un éditeur — il peut faire grep, cat, pytest, git diff, et réinjecter les résultats dans son propre raisonnement. C'est énormément puissant. C'est aussi pourquoi un agent de terminal peut discrètement brûler quelques dollars de tokens avant même que vous ayez fini votre café. Cet article est un satellite de l'explication plus large sur l'agentic coding. Ici, je zoome spécifiquement sur la variante résidente dans le terminal : ce que c'est, en quoi elle diffère d'un assistant d'IDE, et d'où vient réellement le coût.

En quoi le terminal coding diffère-t-il d'un assistant d'IDE ?

La différence, c'est qui possède la boucle et à quel point l'agent touche directement votre machine. Un assistant d'IDE — complétion inline, chat en barre latérale, un bouton « corrige ça » — opère à travers l'éditeur. L'éditeur décide quel contexte transmettre au modèle, le modèle propose une modification, et vous (ou l'éditeur) l'appliquez. Le modèle est un passager. Un agent de terminal est le conducteur. C'est lui qui décide quels fichiers ouvrir, quelles commandes lancer, et quoi faire des résultats, tour après tour. Concrètement : Cette dernière ligne est celle qui compte pour votre facture. Une complétion d'IDE, c'est en gros une requête en entrée, une suggestion en sortie. Un agent de terminal peut prendre vingt tours pour refermer un seul bug, et — c'est la partie qui surprend les gens — il relit l'intégralité de la transcription accumulée à chacun de ces tours.

Que fait réellement l'agent dans le terminal ?

Il exécute une boucle plan-action-observation, la même boucle qu'utilise chaque agent, simplement avec votre shell comme surface d'action. Un cycle normal ressemble à ceci :

1. Plan. En regardant la transcription actuelle et la tâche, le modèle décide d'une prochaine étape — « je dois trouver où le token de session est analysé ».
2. Action. Il appelle un outil. Dans un agent de terminal, c'est souvent une commande shell : rg "parseToken" -l, ou la lecture d'un fichier, ou l'exécution de la suite de tests.
3. Observation. Le stdout et le stderr de la commande sont ajoutés au contexte. Une exécution de tests bruyante ou un log de build verbeux atterrit là en entier.
4. Répétition. Le modèle lit la nouvelle observation et planifie à nouveau.

La boucle est vraiment du bon génie logiciel. Le hic, c'est l'étape 3 : chaque observation reste dans la context window pour le reste de la session. Le listing de répertoire dont vous aviez besoin au tour 2 est encore payé au tour 18. Rien ne s'évince tout seul. C'est aussi là que la variante terminal acquiert son propre mode de défaillance. La sortie du shell n'est pas bornée. Un assistant d'IDE déverse rarement 40 000 lignes de sortie webpack dans le prompt. Un agent de terminal qui lance npm run build et se heurte à un mur d'avertissements ingérera tout cela avec joie — puis le réingérera à chaque tour suivant. C'est le problème de l'output filtering sous sa forme la plus pure.

Pourquoi l'agentic terminal coding brûle-t-il autant de tokens ?

Parce que la boucle relit un contexte qui ne cesse de croître à chaque tour, et que l'habitude du terminal de produire de grandes sorties de commandes brutes fait grossir ce contexte rapidement. Rendons cela concret avec de vrais prix. À la mi-2026, Claude Opus 4.8 est à 5 $ le million de tokens en entrée et 25 $ le million en sortie ; Sonnet 4.6 est à 3 $ / 15 $ ; Haiku 4.5 est à 1 $ / 5 $ ; GPT-5.5 est à 5 $ / 30 $. L'entrée est généralement le poste dominant pour les agents, parce que la transcription-que-vous-renvoyez écrase les quelques centaines de tokens que le modèle réécrit à chaque tour. Déroulons une session de débogage modeste sur Sonnet 4.6 :

• Tour 1 : l'agent lit l'arborescence du projet (≈3 000 input tokens).
• Tour 2 : ouvre deux fichiers (≈9 000 tokens désormais en contexte).
• Tour 3 : lance le test qui échoue, capture la traceback (≈13 000 tokens).
• Tour 4 : lit un autre fichier après avoir suivi la pile (≈17 000 tokens).
• Tour 5 : effectue une modification, relance la suite (≈21 000 tokens).

L'accumulation, c'est le coût. Au tour 5, vous renvoyez ≈21 000 input tokens par tour, même si la véritable information nouvelle de ce tour est de quelques centaines de lignes. Cinq tours à une moyenne de, disons, ≈12 000 input tokens chacun, c'est ≈60 000 input tokens rien que pour corriger un bug — et une vraie session fait rarement cinq tours. Les statistiques sur le coût en tokens le confirment : l'entrée domine, et elle domine à cause du renvoi, pas parce que le modèle lit quoi que ce soit de nouveau. Le prompt caching aide beaucoup ici quand il s'applique — un cache read coûte environ 10 % de l'entrée équivalente — mais il ne couvre que le préfixe stable du contexte. Dès que l'agent ajoute un nouveau dump de commande complet, le préfixe cachable se décale et vous payez plein tarif sur les nouveaux octets. Les agents de terminal, qui génèrent constamment de grandes observations inédites, tirent moins de bénéfice du caching que les gens ne le supposent.

Comment garder les coûts d'un agent de terminal raisonnables ?

Vous réduisez ce qui entre dans la boucle et vous arrêtez de repayer pour ce qui s'y trouve déjà. Il y a quelques leviers concrets :

1. Filtrez la sortie des commandes avant qu'elle n'atteigne le contexte. Ne laissez pas l'agent lire un log de build de 40 000 lignes. Tronquez-le, résumez-le, ou faites-en un tail. C'est le geste à plus fort effet de levier pour les agents de terminal, parce que la sortie du shell est l'endroit d'où vient la croissance non bornée.
2. Lisez la structure, pas les fichiers entiers. Quand l'agent a besoin de comprendre un module, un squelette — signatures, exports, types — suffit souvent, pour une fraction des tokens. N'allez chercher le corps complet que lorsqu'il modifie réellement.
3. Cherchez sémantiquement au lieu de déverser des répertoires. La semantic code search permet à l'agent de sauter directement à la fonction pertinente au lieu de lire l'arborescence du projet et trois fichiers candidats pour la trouver. Voyez semantic search vs grep pour le compromis.
4. Chargez les outils MCP à la demande. Le manifeste d'outils de chaque serveur MCP connecté reste dans le contexte, que l'agent l'utilise ou non. Les charger à la demande maintient le prompt de base petit. Le tour d'horizon des meilleurs serveurs MCP pour Claude Code vaut la lecture si vous en branchez plusieurs.
5. Misez délibérément sur le caching. Gardez stables les parties stables de votre prompt pour que le préfixe du cache survive entre les tours.

Ce sont les mêmes leviers autour desquels j'ai bâti Tokenade. Il se place entre votre agent de terminal et le modèle, applique automatiquement la semantic search, l'output filtering, la skeleton compression et le chargement paresseux des MCP, et vous montre un dashboard d'économies pour que vous voyiez quel levier fait réellement bouger votre facture. Il fonctionne avec Claude Code, Cursor, Codex, Copilot, Windsurf et les autres, le palier gratuit couvre jusqu'à ≈10M de tokens par mois, et il est source-available sous licence MIT, donc vous pouvez lire exactement ce qu'il fait à vos prompts. Si vous voulez d'abord le menu complet des techniques, le guide réduire l'usage de tokens des agents de codage IA les expose toutes avec des chiffres ; si vous êtes décidé, Tokenade Pro est à 19,90 $/mois (hors taxe aux US, TTC en France), postes illimités.

Ce qui tourne mal (anti-patterns)

Quelques modes de défaillance reviennent encore et encore avec les agents de terminal :

• L'avalement de log de build. L'agent lance une commande qui émet des dizaines de milliers de lignes, les ingère toutes, puis les renvoie à chaque tour pour le reste de la session. Surveillez un saut soudain de l'entrée par tour — c'est presque toujours de la sortie brute qui aurait dû être filtrée.
• La spirale de lecture exploratoire. Lorsque la tâche est sous-spécifiée, l'agent se couvre en lisant largement pour réduire sa propre incertitude avant de s'engager. Rationnel, mais coûteux. Le correctif est de votre côté : donnez-lui le fichier pertinent, la fonction exacte, l'erreur précise. Plus vous chargez les choses en amont, moins il fouille.
• L'hypothèse du cache fantôme. Les gens activent le prompt caching et supposent que le problème de coût est résolu. Il ne l'est pas — le caching ne couvre que le préfixe stable, et les agents de terminal l'invalident constamment avec de nouvelles observations. Le caching est nécessaire, pas suffisant.
• La prolifération de manifestes MCP. Six serveurs connectés, deux utilisés un jour, toutes leurs définitions d'outils taxant chaque prompt. Chargez-les à la demande.

Rien de tout cela ne signifie que les agents de terminal sont une mauvaise affaire — c'est la façon la plus capable de coder avec l'IA aujourd'hui. Cela signifie simplement que la boucle a un métabolisme, et que si vous ne gérez pas ce que vous lui donnez à manger, elle dévorera.

---

À voir aussi :

• Agentic coding — le pilier auquel ce satellite appartient.
• Comment réduire l'usage de tokens des agents de codage IA — chaque levier, avec des chiffres.
• Le context engineering pour les agents de codage IA — la discipline derrière la gestion de ce que lit la boucle.
• Output filtering — la technique qui dompte la sortie shell bruyante.