Ce qui différencie un agent CLI de code d’un autre
Demandez à un agent CLI de code de corriger un test qui échoue, et il ne répondra pas par une suggestion. Il lit la sortie du test, ouvre le fichier, modifie une ligne, relance le test, et revient vers vous une fois qu’il passe. Cette boucle, c’est le produit, pas la fenêtre de chat.
Le modèle à l’intérieur de la boucle capte la majeure partie de l’attention, et c’est aussi la partie qui change le plus vite : les éditeurs en changent tous les quelques mois, et plusieurs agents vous laissent choisir. Ce qui reste en place, c’est le harnais qui entoure le modèle — quels outils il peut atteindre, comment il gère le contexte, ce qu’il peut exécuter sans demander, et où ces commandes s’exécutent. Deux agents qui tournent avec le même modèle peuvent se comporter très différemment à cause de ça. Le harnais, c’est ce que vous choisissez réellement.
Comment fonctionne la boucle agentique
Enlevez le branding, et chaque agent CLI de code tourne sur le même cycle :
- Le modèle reçoit votre demande plus tout le contexte que le harnais a assemblé : fichiers ouverts, sortie shell récente, instructions du projet.
- Au lieu de se contenter d’écrire du texte, le modèle peut émettre un appel d’outil : « exécute cette commande shell », « écris ces octets dans ce fichier », « cherche ce motif ».
- Le harnais exécute réellement cet appel, sur votre vrai système de fichiers ou votre vrai shell, et renvoie le résultat dans le contexte du modèle.
- Le modèle lit le résultat et décide quoi faire ensuite : appeler un autre outil, ou vous répondre.
Cela se répète jusqu’à ce que le modèle décide que la tâche est terminée. Il n’a pas besoin d’un plan complet avant d’agir. Il exécute une commande, lit ce qui s’est passé, et s’ajuste, ce qui explique aussi pourquoi un agent peut enchaîner des dizaines d’appels d’outils sur une tâche qui s’avère finalement simple.
Rien ici n’exige une nouvelle architecture de modèle. Il faut un modèle doué pour choisir quel outil appeler et quand s’arrêter, et un harnais qui lui donne des outils qui valent la peine d’être appelés.
Quels outils un agent de code obtient réellement
La liste d’outils intégrés est courte et sans surprise : lire un fichier, écrire ou modifier un fichier, exécuter une commande shell, chercher dans le code par nom de fichier ou par contenu, et dans beaucoup d’agents, récupérer une URL ou piloter un navigateur. Refactoriser, déboguer, écrire des tests, lire une stack trace : tout ça, c’est le modèle qui combine ces primitives, pas une fonctionnalité séparée que l’éditeur aurait construite.
Les décisions de conception qui comptent se logent dans les détails. Est-ce que « modifier un fichier » exige une correspondance exacte de chaîne avec le contenu actuel, ce qui est plus sûr et plus facile à relire, ou le modèle peut-il réécrire le fichier entier, ce qui est plus rapide et plus facile à rater ? Est-ce que « exécuter une commande shell » s’exécute directement, ou dans un sandbox qui bloque l’accès réseau et les écritures en dehors du projet ? Mettez le même modèle derrière des réponses différentes à ces deux questions, et vous obtenez des agents qui ne se ressemblent en rien.
Comment les agents de code gèrent un contexte plus grand que la fenêtre
Une vraie base de code ne tient pas dans une fenêtre de contexte, et une session longue produit bien plus de sortie d’outils que ce que quiconque collerait dans un prompt. Les agents combinent plusieurs techniques pour s’en sortir :
- Lecture sélective. L’agent cherche le fichier ou la fonction pertinente au lieu de charger tout le repo, le même réflexe que vous avez quand vous faites un
grepavant uncat. - Compaction. Quand la conversation dépasse un seuil de taille, le harnais résume les tours précédents en une forme plus courte et continue de travailler à partir de là, en échangeant du détail contre de la place.
- Subagents. Une grosse tâche est découpée en tâches plus petites, chacune envoyée à un appel de modèle neuf avec seulement le contexte dont elle a besoin. Seul le résultat revient dans la conversation principale.
- Retrieval. Certains agents indexent la base de code et utilisent le même schéma de retrieval que derrière le RAG pour ne remonter que les morceaux pertinents pour la question en cours. D’autres se passent de l’index et s’appuient uniquement sur la recherche.
La compaction est celle qui mord. Un détail du début de la session, comme un flag que vous avez mentionné une fois, peut disparaître du résumé. Si un agent se met à ignorer quelque chose que vous lui avez dit une heure plus tôt, c’est en général la cause, et une session neuve avec les faits clés reformulés règle ça.
Ce qu’un agent de code peut exécuter sans demander
C’est le harnais qui décide jusqu’où l’agent va avant de s’arrêter et de demander. À une extrémité, chaque modification de fichier et chaque commande shell attend votre approbation. Sûr, et lent : l’agent vous interrompt sans cesse. À l’autre extrémité, l’agent tourne dans un environnement sandboxé sans personne pour surveiller, ce qui convient à du travail en arrière-plan comme corriger un test instable et ouvrir une pull request pendant que vous faites autre chose.
L’usage quotidien se situe surtout entre les deux. Les actions en lecture seule, comme chercher et ouvrir des fichiers, se font automatiquement. Tout ce qui est destructeur ou orienté vers l’extérieur, comme supprimer un fichier ou pousser vers un remote, attend un oui.
C’est une politique appliquée par le harnais, pas une propriété du modèle. Le même modèle se montre prudent ou téméraire selon ce qu’on l’autorise à faire sans supervision.
Comment MCP donne de nouveaux outils à un agent de code
Les outils intégrés couvrent le système de fichiers et le shell, mais le vrai travail a souvent besoin de plus : interroger une base de données interne, ou ouvrir un ticket dans votre outil de suivi. Le Model Context Protocol (MCP) est le standard ouvert qui fournit cela sans que chaque éditeur d’agent écrive une intégration sur mesure pour chaque service.
Un serveur MCP décrit les outils qu’il propose et comment les appeler. N’importe quel agent compatible MCP peut se connecter, lister ces outils, et les appeler exactement comme ses outils intégrés. L’agent n’a besoin d’aucun code spécifique au service : il lit les descriptions des outils et décide quand ils sont utiles, de la même façon qu’il décide quand lancer grep.
Le coût, c’est le contexte. Dans beaucoup d’agents, les descriptions d’outils de chaque serveur connecté prennent de la place dans la fenêtre à chaque tour, donc une dizaine de serveurs que vous utilisez rarement alourdissent chaque requête. Ne connectez que ceux dont le projet a besoin.
À quoi servent les fichiers AGENTS.md et CLAUDE.md
Presque tous les agents cherchent un fichier d’instructions markdown à la racine de votre repo et le lisent avant de faire quoi que ce soit. AGENTS.md est la convention neutre, indépendante de tout éditeur ; certains outils utilisent leur propre nom, comme CLAUDE.md. C’est là que vous écrivez ce que le modèle ne peut pas deviner à partir du code : quelle commande lance les tests, et quels dossiers sont générés et ne doivent jamais être modifiés à la main. Tout ce que l’agent devrait sinon deviner, et deviner mal, va ici.
Beaucoup d’agents lisent aussi des fichiers d’instructions dans les sous-dossiers, donc un monorepo peut avoir un fichier racine plus un fichier plus spécifique par package. Le fait qu’un fichier plus profond remplace ou complète le fichier racine varie selon l’outil, donc vérifiez la doc de celui que vous utilisez.
Dix lignes dans ce fichier évitent à l’agent de redécouvrir votre commande de test à chaque session.
Comment comparer les agents CLI de code
Quand la boucle et la liste d’outils sont partout les mêmes, les listes de fonctionnalités n’apprennent plus grand-chose. Ces quatre questions séparent les outils sur des points qui changent votre quotidien :
| Question | Ce que ça change pour vous |
|---|---|
| Où tourne-t-il : terminal, IDE, ou arrière-plan ? | Un agent terminal vit dans votre shell et fonctionne à côté de n’importe quel éditeur. Un agent IDE se branche sur la vue diff et l’historique d’annulation de votre éditeur. Un agent en arrière-plan travaille sans surveillance à partir d’une description de tâche et vous rend une pull request, ce qui convient mieux à du travail de backlog bien cadré qu’à du débogage interactif. |
| Le harnais est-il open source ou propriétaire ? | Un harnais ouvert comme OpenCode ou Aider peut être pointé vers n’importe quel modèle auquel vous avez un accès API, y compris un modèle que vous faites tourner en local avec Ollama, et vous pouvez lire exactement ce qu’il fait. Un harnais propriétaire est généralement optimisé pour les propres modèles de son éditeur et demande moins de configuration. |
| Comment payez-vous : API au token ou abonnement ? | La facturation au token suit l’usage, donc les longues sessions autonomes coûtent le plus. Un abonnement plafonne la dépense mais ajoute des limites d’usage et vous lie aux modèles d’un seul éditeur. |
| Quelle est la profondeur du sandbox ? | Certains agents exécutent les commandes directement sur votre machine ; d’autres s’exécutent toujours dans un conteneur ou une VM, le même genre d’isolation qu’offrent les conteneurs Docker. L’exécution directe ne demande aucune configuration et c’est le choix le plus risqué pour tout ce qui tourne sans surveillance. |
Classez selon le mode, pas la marque. Un même éditeur propose souvent un outil terminal, une extension d’éditeur, et un mode cloud qui ouvre des pull requests ; Claude Code et OpenAI Codex fonctionnent tous les deux ainsi. Les réglages par défaut de permissions et de sandbox diffèrent entre ces modes, donc jugez celui que vous utiliserez réellement.
Comment choisir un agent CLI de code pour votre workflow
Ignorez les classements. Les scores de benchmark bougent toutes les quelques semaines et en disent peu sur votre repo. Répondez plutôt à deux questions : voulez-vous l’agent dans votre terminal ou dans votre éditeur, et voulez-vous qu’il travaille sans surveillance en arrière-plan ou en boucle avec vous approuvant chaque étape. Ces réponses réduisent le champ à deux ou trois candidats.
Écrivez ensuite un AGENTS.md pour votre projet, donnez à chaque candidat la même vraie tâche tirée de votre backlog, et gardez celui dont vous fusionneriez le diff avec le moins de retouches.