Source: https://aiprimetech.io/fr/blog/claude-code-cli-guide/ Juin 19, 2026 · 6 min · Outils # Claude Code et la nouvelle vague d’outils de programmation IA dans le terminal A Par [AI Prime Tech](https://aiprimetech.io/fr/) · Avec l’aide de l’IA À 2:13 heures du matin, j’ai vu un agent de programmation dans le terminal consommer 1.8 millions de tokens d’entrée en essayant de « simplement corriger le test en échec ». Le véritable bug était une incompatibilité de schéma sur trois lignes. L’agent n’était pas stupide ; il était mal encadré. Il n’arrêtait pas de relire le dépôt, de relancer des commandes de test très larges, de renvoyer d’immenses traces de pile au modèle et de demander des réécritures de fichiers entiers alors qu’un diff ciblé aurait suffi. Cet incident a changé ma façon d’utiliser les agents de programmation en CLI. Des outils comme Claude Code, Aider, Cline et OpenCode ne sont pas simplement des chatbots dotés d’un bouton git diff . Ce sont des boucles de contrôle pilotées par API qui s’articulent autour de votre shell, de votre éditeur, de votre système de fichiers et parfois de votre navigateur. Ils peuvent être extrêmement productifs, surtout avec des modèles performants comme Claude Opus 4.8, Sonnet 4.6, GPT-5.5, Gemini 3 et des systèmes à contexte long comme Fable 5. Ils peuvent aussi consommer discrètement des tokens à un rythme qui surprend les équipes habituées aux appels API à un seul tour. Cet article aborde le sujet de façon pratique : ce que font réellement les agents de programmation dans le terminal, comment ils utilisent les API des modèles, pourquoi les boucles agentiques changent l’économie des tokens et comment je les configure pour qu’une longue session reste utile au lieu de devenir une mise en scène coûteuse. ## Ce que sont réellement les agents de programmation en CLI Un agent de programmation dans le terminal est généralement un assemblage de cinq éléments : - Une boucle de conversation avec un modèle de pointe ou ouvert - Un indexeur de dépôt ou une couche de découverte des fichiers - Une couche d’exécution d’outils pour les commandes shell et les modifications de fichiers - Un mécanisme d’application de correctifs - Une couche de persistance pour l’historique des conversations et l’état de la session La différence essentielle avec l’autocomplétion est la capacité d’agir. L’autocomplétion prédit le code à l’emplacement du curseur. Un agent peut décider d’examiner des fichiers, d’exécuter des tests, de modifier du code, d’analyser les échecs et d’itérer. Une boucle typique ressemble à ceci : ``` User task ↓ Agent builds prompt from instructions + repo context + prior messages ↓ Model proposes actions: read file, edit file, run command ↓ CLI executes allowed actions ↓ Results are added back into context ↓ Model plans next step ↓ Repeat until done or stopped ``` C’est cette boucle qui donne à ces outils leur puissance apparente. C’est aussi pourquoi le coût et la latence se comportent différemment d’une utilisation classique de l’API où l’on « pose une question et obtient une réponse ». En pratique, la plupart des surprises liées aux coûts viennent de la boucle de rétroaction : les sorties des commandes, le contenu des fichiers, les messages précédents et les diffs sont inclus à plusieurs reprises dans les tours suivants. ## Claude Code, Aider, Cline et OpenCode : différentes formes d’un même schéma Les outils proposent différents styles d’interaction, mais leur architecture fondamentale est similaire. | Outil | Interface principale | Point fort habituel | Risque de coût courant | Claude Code | Agent natif du terminal | Flux de travail étroitement intégré au shell et au dépôt, boucle de planification et de modification performante | Longues sessions autonomes accumulant du contexte | Aider | Assistant de programmation en binôme en CLI intégrant Git | Modifications centrées sur les diffs, ciblage explicite des fichiers | Ajout d’un trop grand nombre de fichiers au contexte | Cline | Agent centré sur l’éditeur | Intégration à VS Code, utilisation des outils visible | Sorties volumineuses du terminal ou du navigateur intégrées au contexte | OpenCode | Flux de travail agentique dans le terminal et l’éditeur | Souplesse dans le choix des modèles et contrôle du flux de travail local | Fournisseurs mal configurés ou analyses trop larges du dépôt La distinction importante n’est pas de savoir « lequel est le plus intelligent ». Elle tient à la quantité de contexte envoyée par l’outil, à sa façon de sélectionner les fichiers et de résumer l’historique, ainsi qu’au contrôle dont vous disposez sur l’exécution des commandes shell. Aider, par exemple, fonctionne généralement bien lorsque vous ajoutez délibérément les fichiers pertinents. Claude Code est plus agentique et peut donner l’impression d’un ingénieur expérimenté qui parcourt le dépôt, mais cette autonomie exige de bien définir les permissions et le périmètre. Cline est pratique dans l’éditeur, surtout lorsque vous voulez observer les actions, mais cette facilité d’utilisation peut vous amener à approuver trop d’étapes coûteuses. Les flux de travail de type OpenCode séduisent les équipes qui souhaitent pouvoir choisir librement leurs fournisseurs : Claude pour les travaux d’architecture difficiles, GPT pour l’implémentation, Gemini pour l’examen de contextes volumineux, ou des modèles ouverts comme Qwen, DeepSeek, Kimi, MiniMax et Llama pour des passes moins coûteuses en local ou en auto-hébergement. ## Comment ces agents utilisent l’API Une seule demande « corrige ce bug » peut se transformer en des dizaines d’appels API. Voici à quoi ressemble un corps de requête simplifié pour une étape de l’agent : ``` { "model": "claude-sonnet-4.6", "messages": [ { "role": "system", "content": "You are a coding agent. Follow repo instructions. Use tools safely." }, { "role": "user", "content": "Fix the failing invoice total test." }, { "role": "assistant", "content": "I will inspect the test and related invoice code." }, { "role": "tool", "name": "read_file", "content": "tests/test_invoice_totals.py contents..." } ], "tools": [ { "name": "read_file" }, { "name": "apply_patch" }, { "name": "run_shell" } ] } ``` Les implémentations réelles varient, mais le schéma reste le même : - La CLI rassemble le contexte. - Le modèle décide de l’opération suivante. - La CLI exécute l’opération. - Le résultat est renvoyé au modèle. - Le modèle poursuit son travail. Les outils sont généralement exposés de deux façons. ### Protocoles d’outils textuels Certains agents demandent au modèle de produire du texte structuré : ``` RUN: pytest tests/test_invoice_totals.py -q ``` La CLI l’analyse et l’exécute. Cette approche est simple et portable, mais fragile. Si le modèle formate la commande de manière inhabituelle, le système d’exécution a besoin de garde-fous. ### Appel natif de fonctions D’autres agents utilisent les appels d’outils ou de fonctions de l’API du modèle. Le modèle renvoie un appel d’outil structuré : ``` { "tool_name": "run_shell", "arguments": { "command": "pytest tests/test_invoice_totals.py -q", "timeout_seconds": 60 } } ``` Cette approche est plus facile à valider. L’agent peut rejeter les commandes correspondant à des motifs dangereux, exiger une approbation pour l’accès réseau ou limiter les écritures à l’espace de travail. Dans les deux cas, ce qui coûte cher n’est pas la commande shell. C’est le prompt qui s’allonge autour de cette commande. ## Pourquoi les boucles agentiques changent l’économie des tokens Une intégration API classique peut envoyer 2,000 tokens d’entrée et recevoir 500 tokens de sortie. Une session de programmation agentique peut se dérouler ainsi : | Étape | Déroulement | Profil des tokens d’entrée | Profil des tokens de sortie | 1 | L’utilisateur demande une correction | Faible | Plan | 2 | L’agent lit des fichiers | Moyen | Demande d’appel d’outil | 3 | L’agent modifie le code | Moyen à élevé | Correctif | 4 | Un test échoue | Élevé si les journaux complets sont inclus | Diagnostic | 5 | L’agent lit davantage de fichiers | Plus élevé en raison de l’historique | Demande d’appel d’outil | 6 | L’agent réessaie | Encore plus élevé | Correctif | 7 | L’exécution de la suite complète de tests échoue ailleurs | Très élevé si la sortie est collée telle quelle | Synthèse/triage Le piège : les tokens d’entrée représentent souvent la majeure partie du volume. Chaque boucle peut renvoyer les instructions système, l’historique de la conversation, les fichiers sélectionnés, les sorties des outils et les synthèses. Même avec la mise en cache ou la compression du contexte, les longues sessions autonomes peuvent devenir coûteuses, car le modèle a besoin de suffisamment d’informations sur l’état du travail pour éviter d’agir à l’aveugle. Quatre facteurs multiplient couramment le nombre de tokens : - Contexte comprenant des fichiers entiers : envoyer des fichiers de 900 lignes alors que seules deux fonctions comptent. - Sorties de tests verbeuses : inclure les avertissements des dépendances, les barres de progression et les échecs sans rapport avec la tâche. - Analyses répétées du dépôt : exécuter find, tree, ou rg sur un périmètre large et réinjecter la sortie. - Historique de conversation illimité : conserver chaque tentative infructueuse au lieu de résumer les décisions. Dans une session désordonnée, ce qui se passe réellement n’est pas que « l’agent réfléchit davantage ». Il reçoit souvent simplement davantage de contexte obsolète. Un volume accru de tokens peut rendre le modèle plus lent et moins précis si les informations pertinentes sont noyées dans le reste. ## Le modèle mental : un budget par boucle, pas par prompt Quand j’estime les dépenses, je raisonne en boucles. Une petite tâche ciblée pourrait se présenter ainsi : ``` 8 turns × 12k input tokens average = 96k input tokens 8 turns × 1.5k output tokens average = 12k output tokens ``` Une tâche qui s’éparpille pourrait se présenter ainsi : ``` 35 turns × 55k input tokens average = 1.9M input tokens 35 turns × 3k output tokens average = 105k output tokens ``` Le même prompt utilisateur. Des coûts très différents. Vous n’avez pas besoin de connaître les tarifs exacts pour comprendre les contours du problème. Le coût des sessions agentiques augmente avec : ``` total cost ≈ Σ(input_tokens_per_step × input_price) + Σ(output_tokens_per_step × output_price) + tool/runtime overhead ``` Les tokens de sortie sont visibles, car vous voyez l’agent écrire. Les tokens d’entrée sont invisibles, car ils sont assemblés par la CLI. C’est sur cette partie cachée que la discipline budgétaire compte. ## Choisir les modèles pour le travail des agents J’utilise rarement un seul modèle pour tout. Pour les agents en terminal, le choix du modèle doit correspondre à la phase : | Phase | Type de modèle le plus adapté | Pourquoi | Exploration du dépôt | Modèle à contexte long ou modèle performant moins coûteux | Nécessite une lecture étendue, pas des modifications parfaites | Décision d’architecture | Modèle doté de solides capacités de raisonnement | Nécessite d’évaluer les compromis | Génération de correctifs | Modèle performant en programmation | Nécessite des diffs précis | Triage des échecs de tests | Modèle rapide de milieu de gamme | Repose souvent sur la reconnaissance de motifs | Refactorisations mécaniques | Modèle peu coûteux ou ouvert, avec des garde-fous | Travail répétitif et vérifiable Une configuration pratique pourrait utiliser des modèles de la classe Sonnet pour la plupart des tâches de programmation, des modèles de la classe Opus/GPT-5.5 pour le débogage difficile ou la conception, des modèles à contexte long de type Gemini/Fable pour les analyses de grande ampleur, et des modèles ouverts pour les refactorisations locales de type lint. Les noms exacts changeront ; le principe reste valable. Une erreur courante consiste à utiliser le modèle le plus coûteux pendant toute la boucle. Ce modèle consomme alors des tokens au tarif fort pour lire node_moduleset le bruit connexe, les avertissements des tests et les fichiers générés. Réservez le modèle le plus puissant aux décisions qui en ont réellement besoin. ## Conseils de configuration qui comptent La meilleure configuration n’est pas « une autonomie maximale ». C’est « un retour rapide avec des permissions restreintes ». ### 1. Ignorez les fichiers générés et ceux des dépendances tierces Chaque agent de programmation devrait disposer d’une liste d’exclusion. Commencez par les mêmes éléments que vous excluez des recherches et des revues : ``` node_modules/ dist/ build/ coverage/ .venv/ __pycache__/ target/ vendor/ *.lock *.min.js *.map ``` En général, je n’exclus pas globalement les fichiers de verrouillage si la tâche concerne la résolution des dépendances, mais je les exclus du contexte par défaut. Un fichier de verrouillage peut être inclus explicitement au besoin. ### 2. Utilisez des commandes de test ciblées Ne laissez pas l’agent exécuter par défaut toute la suite à chaque itération. Donnez-lui une progression de commandes : ``` # First loop: fastest relevant test pytest tests/billing/test_invoice_totals.py -q # Second loop: nearby package pytest tests/billing -q # Final confidence check pytest -q ``` Pour JavaScript ou TypeScript : ``` pnpm test invoice-total.test.ts -- --runInBand pnpm lint src/billing pnpm test ``` L’enjeu ne se limite pas au temps d’exécution. Des sorties plus courtes signifient des prompts plus courts à la boucle suivante. ### 3. Limitez la sortie des commandes Si votre agent permet de limiter la sortie, utilisez cette fonctionnalité. Sinon, encapsulez vous-même les commandes : ``` pytest tests/billing -q 2>&1 | tail -120 ``` Ou pour les compilations qui produisent beaucoup de sortie : ``` pnpm test 2>&1 | grep -E "FAIL|Error|Expected|Received|at " | head -200 ``` Attention : le filtrage peut masquer du contexte utile. Je l’utilise après le premier échec, pas avant. Observez d’abord la nature de l’échec, puis limitez les sorties des exécutions répétées. ### 4. Demandez des diffs, pas des réécritures Pour les fichiers volumineux, dites explicitement à l’agent : ``` Make the smallest safe patch. Do not rewrite unrelated functions. Show a concise diff summary before running tests. ``` Cela réduit les risques et, généralement, le nombre de tokens de sortie. Surtout, cela permet de garder la revue de code gérable. ### 5. Séparer la planification de l’exécution Pour les modifications complexes, je commence souvent par ceci : ``` Inspect the relevant files and propose a plan. Do not edit yet. Limit repo inspection to payment, invoice, and tax modules unless needed. ``` Ensuite, j’approuve le plan et je laisse l’agent le mettre en œuvre. Cela évite le scénario où « l’agent modifie le code avant de le comprendre ». ## Maîtriser les dépenses pendant les longues sessions Les longues sessions sont celles où les agents CLI excellent, mais aussi celles où ils deviennent dangereux. Voici la liste de contrôle que j’utilise en pratique pour maîtriser les dépenses : - Définir un objectif de session : « Faire réussir test_invoice_rounding », et non « corriger la facturation ». - Fixer les fichiers à utiliser lorsque c’est possible : fournir les chemins exacts au lieu de demander à l’agent de tout découvrir. - Réinitialiser le contexte après un changement de direction : démarrer une nouvelle session avec un résumé lorsque la tâche change. - Résumer les échecs manuellement : coller les 30 lignes importantes, et non un journal de 3,000 lignes. - Passer à un modèle plus puissant de façon réfléchie : utiliser un modèle plus puissant uniquement après avoir rencontré un blocage clairement identifié. - S’arrêter après plusieurs boucles répétitives : si l’agent échoue deux fois de la même manière, intervenir. Une bonne consigne de réinitialisation ressemble à ceci : ``` We are fixing invoice rounding. Known facts: - Failure is in tests/billing/test_invoice_totals.py::test_round_half_even - Expected 10.24, actual 10.25 - Decimal quantization happens in src/billing/money.py - Tax calculation calls round_money() from src/billing/tax.py Continue from this summary. Inspect only those files first. ``` Cette consigne peut être moins coûteuse et plus claire que de conserver toute une conversation infructueuse. ## Clés API, fournisseurs et routage La plupart des agents CLI peuvent communiquer directement avec l’API d’un fournisseur de modèles, ou passer par une passerelle compatible. Les principaux enjeux techniques sont les suivants : - Authentification : où les clés API sont stockées et si elles risquent de se retrouver dans l’historique du shell ou les journaux. - Routage des modèles : quel modèle prend en charge quelle phase. - Limites de débit : les boucles des agents peuvent générer rapidement des rafales de requêtes. - Observabilité : suivi des tokens et des coûts par session. - Périmètre des données : si le code peut être envoyé à des API externes. Une configuration minimale de l’environnement ressemble souvent à ceci : ``` export ANTHROPIC_API_KEY="..." export OPENAI_API_KEY="..." export GEMINI_API_KEY="..." ``` Pour les équipes, je préfère un script intermédiaire qui sélectionne les modèles et consigne l’utilisation : ``` #!/usr/bin/env bash set -euo pipefail export AGENT_MODEL="${AGENT_MODEL:-sonnet}" export AGENT_MAX_OUTPUT_TOKENS="${AGENT_MAX_OUTPUT_TOKENS:-4096}" export AGENT_SESSION_BUDGET_USD="${AGENT_SESSION_BUDGET_USD:-10}" coding-agent "$@" ``` Si vous utilisez une passerelle multimodèle, elle peut être utile ici pour acheminer le trafic de Claude, GPT, Gemini ou de modèles ouverts derrière une interface unique. L’essentiel n’est pas la liste des logos, mais la fiabilité du suivi de l’utilisation et la disponibilité de contrôles au niveau de chaque modèle. ## Ce que j’inclus dans les instructions du dépôt La plupart des agents respectent une forme de fichier d’instructions du dépôt. Je garde le mien court et pratique : ``` ## Agent Instructions - Prefer minimal diffs over rewrites. - Do not run full test suites until targeted tests pass. - Never edit generated files in `dist/`, `build/`, or `coverage/`. - Use `rg` for search. - Before large refactors, propose a plan and wait. - If a command emits more than 200 lines, rerun with a narrower command. ``` Ce n’est pas une question de politesse. Ces instructions structurent la boucle. L’agent fera encore des erreurs, mais de bonnes instructions réduisent les gaspillages répétés. Un piège courant : les fichiers d’instructions trop longs deviennent du bruit de fond. Si vos instructions pour l’agent contiennent 300 lignes de philosophie stylistique, le modèle risque de manquer les trois contraintes opérationnelles essentielles. Placez les règles les plus utiles en premier. ## La latence : l’autre coût Même lorsque les dépenses en tokens sont acceptables, la latence peut casser le rythme de travail. La latence des agents provient de : - La durée d’inférence du modèle - La durée d’exécution des outils - La durée d’indexation des fichiers - La durée d’exécution des tests - Les pauses pour obtenir une approbation humaine Pour les boucles courtes, j’optimise le « délai avant la prochaine observation utile ». Un test ciblé de 15 secondes vaut mieux qu’une simulation complète de CI de 6 minutes. Un modèle plus petit qui identifie correctement une erreur de syntaxe en 4 secondes vaut mieux qu’un modèle haut de gamme qui passe 45 secondes à produire une belle explication. Les meilleures sessions ressemblent à de la programmation en binôme : ``` inspect → patch → targeted test → inspect failure → patch → targeted test → final suite ``` Les pires sessions ressemblent à une parodie de CI : ``` scan repo → edit many files → run everything → drown in logs → repeat ``` ## Limites et modes de défaillance Les agents de terminal sont utiles, pas magiques. Ils rencontrent des difficultés lorsque : - Le dépôt comporte des dépendances d’exécution cachées qui ne sont pas couvertes par les tests. - La tâche exige un jugement sur le produit plutôt qu’une transformation du code. - L’erreur dépend de services externes ou d’un état instable. - La base de code comporte des abstractions trompeuses ou une documentation obsolète. - L’agent ne peut pas exécuter la commande de validation pertinente. Ils peuvent aussi produire des corrections plausibles, mais erronées. C’est particulièrement fréquent lorsque les tests sont insuffisants. Si l’agent ne peut pas vérifier le comportement, traitez son résultat comme le correctif non relu d’un ingénieur débutant : potentiellement utile, mais jamais digne de confiance par défaut. La sécurité compte aussi. Ne donnez pas à un agent un accès illimité au shell dans un dépôt sensible sans comprendre le modèle d’approbation de l’outil. « Exécuter des commandes » inclut la possibilité d’afficher les variables d’environnement, de modifier des fichiers, d’installer des paquets ou d’accéder au réseau, sauf si des restrictions sont en place. ## Conseils pratiques - Traitez les outils de programmation CLI comme des boucles de contrôle pilotées par API, et non comme de simples consignes isolées. - Optimisez les coûts en réduisant le nombre de boucles et la taille du contexte, en particulier la sortie des commandes. - Utilisez des modèles puissants pour les raisonnements difficiles, pas pour chaque étape mécanique. - Gardez les instructions du dépôt courtes, pratiques et centrées sur le comportement de l’agent. - Privilégiez d’abord les tests ciblés, puis une validation plus large à la fin. - Réinitialisez les longues sessions avec des résumés concis au lieu de conserver un historique obsolète. - Surveillez les tokens d’entrée : ils constituent le poste de coût caché de la programmation agentique. - Arrêtez-vous et intervenez lorsque l’agent répète la même stratégie infructueuse. Claude Code, Aider, Cline et OpenCode s’inscrivent dans une véritable évolution : l’assistance à la programmation passe de moteurs de suggestions à des collaborateurs conçus pour le terminal. Les équipes qui en tireront le plus de bénéfices ne seront pas celles qui se contentent d’« activer les agents ». Ce seront celles qui conçoivent la boucle : un contexte restreint, des outils sûrs, des dépenses observables et une vérification à chaque étape. [Développement](/fr/blog/tag/coding/)[Claude](/fr/blog/tag/claude/)[Agents](/fr/blog/tag/agents/) A [AI Prime Tech](https://aiprimetech.io/fr/) Ce blog est publié par AI Prime Tech. Les articles sont rédigés avec l’aide de l’IA ; vérifiez les détails propres à chaque version, tels que les identifiants de modèles, les prix et les limites, dans la documentation officielle avant de vous y fier. Accédez à l’API Claude à moindre coût Une seule clé API pour Claude Opus 5.5, Sonnet 5, Haiku 4.5 et Fable 5.1, ainsi que GPT-6 modèles. Paiement à l’usage, sans abonnement. [Obtenir votre clé API →](/register) AI Prime Tech est une passerelle API tierce indépendante. Claude™ et Anthropic® sont des marques d’Anthropic, PBC. Aucune affiliation ni approbation n’est sous-entendue.