Dans un CLI agentique : boucles, contexte et permissions

Le modèle, c'est la partie facile. C'est en tout cas la thèse, et après avoir vu une douzaine de CLI de codage agentiques naître, se scinder et trébucher ces dernières années, je pense qu'elle est juste : un CLI de codage agentique réussit ou échoue grâce à son harnais, pas à son modèle. La sortie d'OpenCode 2.0, un agent de codage open source en terminal qui a pris beaucoup d'ampleur cette semaine, est une bonne occasion de le dire tout haut. Ce qu'il y a d'intéressant dans cette version, ce ne sont pas de nouvelles intégrations de modèles. Ce sont une séparation client/serveur, des plugins rechargés à chaud, des tâches exécutables en arrière-plan et une boucle d'agent réarchitecturée. De la tuyauterie, en somme. La tuyauterie, c'est le produit.

Ancien ingénieur en ML, cette conclusion m'a agacé. Je voulais que la qualité du modèle soit le facteur différenciant. Mais quand je regarde pourquoi je garde ou j'abandonne ces outils, la réponse n'est jamais « le modèle est devenu plus intelligent ». C'est plutôt « l'outil a arrêté de me demander d'approuver chaque commande », ou « il recharge enfin ma configuration sans redémarrer », ou « je peux attacher une interface graphique à une session qui tourne sur une machine distante ». Décortiquons les trois sous-systèmes qui déterminent réellement l'utilité d'un agent de codage : la boucle d'appels d'outils, la gestion du contexte et le modèle de permissions. Ensuite, je reconnaîtrai où la thèse à contre-courant montre ses limites.

La boucle d'appels d'outils est un système distribué

Enlevez le marketing et tous les agents de codage sont le même programme : appeler le modèle avec un prompt et une liste d'outils, recevoir soit du texte, soit un appel d'outil, exécuter l'outil, ajouter le résultat, recommencer. Cette boucle paraît triviale. Elle ne l'est pas, et les outils qui la traitent comme telle semblent bancals au bout de cinq minutes d'utilisation réelle.

Pensez à ce que la boucle doit réellement gérer. Les exécutions d'outils échouent : le compilateur plante, la suite de tests reste bloquée, le fichier n'existe pas à ce chemin parce que le modèle l'a halluciné. Le modèle produit du JSON malformé pour les arguments de ses outils. Un appel d'outil prend quarante secondes et l'utilisateur appuie sur Échap en pleine exécution. Deux appels d'outils arrivent dans le même tour, et l'un ne doit pas s'exécuter si l'autre échoue. La fenêtre de contexte se remplit au milieu de la tâche et quelque chose doit céder. Chacun de ces cas est un problème de concurrence et de gestion des pannes, pas un problème d'intelligence. J'ai déjà soutenu que les agents LLM sont simplement des systèmes distribués, et le CLI de codage en est l'exemple le plus pur : un composant distant peu fiable et non déterministe (le modèle) se coordonne avec des composants locaux à effets de bord (shell, système de fichiers, LSP), et la boucle est le protocole de consensus entre eux.

C'est pour cela qu'il est important qu'OpenCode 2.0 ait, selon les informations, reconstruit sa boucle autour d'Effect, un framework TypeScript pour la concurrence structurée et les erreurs typées. Ce choix indique que l'équipe a cessé de voir la boucle comme « une boucle while avec un fetch dedans » et l'a traitée pour ce qu'elle est : un système d'effets interruptibles, composables et réessayables, avec des canaux d'erreur explicites. Quand votre boucle d'agent dispose de vraies sémantiques d'annulation, « l'utilisateur appuie sur Échap » devient un événement de premier plan au lieu d'un état corrompu. Quand les résultats d'outils sont typés, vous pouvez valider la sortie du modèle avant de l'exécuter, ce qui se marie bien avec des techniques comme le décodage contraint, où l'on restreint l'espace de sortie du modèle pour que les appels d'outils malformés deviennent impossibles plutôt que simplement détectés.

Le client/serveur est la fonctionnalité dont personne ne fait la promotion

L'une des décisions de conception les plus lourdes de conséquences pour un CLI de codage est de savoir si l'agent est un processus ou un service. La conception naïve, un processus et un terminal, où la session meurt quand le terminal se ferme, est celle par laquelle la plupart de ces outils ont commencé, et c'est un plafond. Le modèle client/serveur d'OpenCode, où un serveur de longue durée possède les sessions et où un nombre quelconque de clients (TUI, application de bureau, interface web) s'y rattachent, lève ce plafond. Concrètement : votre session survit à la fermeture de votre terminal, vous pouvez faire tourner l'agent sur une machine de développement distante et le piloter depuis une application native sur votre portable, et plusieurs interfaces peuvent observer la même session.

Si vous avez déjà essayé de faire tourner un agent sur une VM en SSH et que la session a été écrasée par une reconnexion, vous savez que ce n'est pas un simple confort. C'est la différence entre un jouet et une infrastructure. Les agents de longue durée appartiennent à la même catégorie que les builds et les suites de tests : on les lance, on s'en éloigne, et on vérifie plus tard. Les tâches exécutables en arrière-plan d'OpenCode 2.0 vont dans le même sens : l'agent cesse d'être une conversation synchrone et devient un exécuteur de tâches doté d'une interface de chat.

Maintenant, la mise en garde, car je tiens cette position de manière constante : une architecture serveur ne signifie pas un démon permanent. Plusieurs commentateurs ont noté avec méfiance que chaque harnais d'agent veut soudain un processus persistant en arrière-plan sur leur machine. Cette méfiance est justifiée. J'ai déjà écrit que les outils en ligne de commande ne devraient pas installer de démons en arrière-plan par défaut, et je le maintiens. Il existe un juste milieu : démarrer le serveur à la demande, limité au répertoire du projet, et l'arrêter quand le dernier client se déconnecte. On obtient la persistance de session et le rattachement multi-clients sans un processus toujours actif qui remonte des informations depuis votre machine. Le fait qu'OpenCode charge la configuration depuis le dossier de la session plutôt que depuis le répertoire de travail du serveur, une autre nouveauté de la 2.0, suggère qu'ils ont compris que le serveur doit suivre le projet, et non l'inverse.

La gestion du contexte, c'est là que se joue la qualité

Demandez à n'importe quel praticien pourquoi un agent « est devenu bête » après une heure de travail, et la réponse n'est presque jamais une régression du modèle. C'est la pourriture du contexte. La fenêtre s'est remplie de sorties d'outils périmées, d'impasses et du texte intégral de fichiers pertinents quarante tours plus tôt. Le modèle prend maintenant ses décisions au milieu d'une botte de foin, et sa capacité à retrouver l'aiguille se dégrade bien avant d'atteindre la limite nominale de tokens.

Un bon harnais traite le contexte comme un budget avec une politique d'allocation, et non comme un tuyau. Concrètement, cela implique plusieurs mécanismes qui travaillent ensemble :

• Troncature des sorties d'outils avec échappatoires de récupération. Un journal de test de 5 000 lignes devrait entrer dans le contexte sous la forme de ses quarante lignes en échec, accompagnées d'une note indiquant que le journal complet se trouve à un chemin que le modèle peut relire. Le harnais décide de ce qui est saillant ; le modèle décide quand il a besoin de plus.
• Sous-sessions et sous-agents. « Va explorer comment fonctionne l'authentification dans ce dépôt et fais-moi un rapport » devrait s'exécuter dans un contexte isolé qui renvoie une synthèse, et non la transcription complète de l'exploration. L'amélioration de la communication entre sous-sessions dans OpenCode 2.0 correspond exactement à cette idée.
• Compactage qui préserve l'intention. Quand la fenêtre se remplit, il faut bien résumer la conversation jusque-là. Un harnais qui résume naïvement perd les contraintes de l'utilisateur (« ne touche pas au module de facturation ») en même temps que le bruit. Un bon compactage conserve mot pour mot les décisions et les contraintes, et ne compresse que le récit.
• Configuration et compétences comme contexte, pas comme code. Les instructions au niveau du projet, les outils définis par des plugins et les fichiers de compétences consomment tous de la fenêtre. Les recharger à chaud, une autre correction de la 2.0, compte, car modifier le contexte de votre agent sans redémarrer sa session est la manière d'itérer sur le comportement de l'agent lui-même.

Rien de tout cela ne relève de l'intelligence du modèle. Tout cela détermine pourtant à quel point le modèle semble intelligent. Un modèle de pointe doté d'une politique de contexte bâclée perdra face à un modèle moins cher derrière un harnais rigoureux, sur toute tâche de plus de vingt minutes.

Modèles de permissions : la fonctionnalité ennuyeuse qui décide de l'adoption

Voici une question issue de la discussion sur HN que je considère comme la plus importante de cet espace : existe-t-il quelque chose entre « approuver chaque commande » et le mode « yolo » ? L'auto-approbation totale est vraiment dangereuse : un agent de codage disposant d'un accès shell peut lancer rm -rf, git push --force et exfiltrer vos variables d'environnement en un seul tour. L'approbation manuelle totale est vraiment inutilisable : approuver quatre-vingts commandes par heure, ce n'est pas superviser l'agent, c'est être un clavier humain lent qui interrompt. L'outil qui trouve le juste milieu séduit les pragmatiques.

Le juste milieu est un modèle de permissions gradué, dont l'espace de conception est mieux compris qu'on ne le pense :

• Lecture seule, écriture, exécution. Les lectures sont presque gratuites ; les écritures devraient être limitées à l'arborescence du projet ; l'exécution est là où la politique compte le plus.
• Listes d'autorisation sensibles aux arguments. git status s'approuve automatiquement ; git push demande confirmation. Les outils naïfs comparent le nom du binaire ; les bons comparent le verbe et les options, car npm test et npm publish sont le même binaire avec des rayons d'impact radicalement différents.
• Autorisations limitées à la session. « Toujours autoriser cette commande dans cette session » est la fonctionnalité de permission la plus précieuse qui soit. Elle transforme soixante-dix demandes en une seule.
• Confinement de l'irréversible. L'accès réseau, tout ce qui se trouve hors du répertoire du projet et tout ce qui touche aux identifiants devraient être restreints structurellement, et non simplement soumis à une demande de confirmation.

Ce dernier point est celui que la plupart des harnais sous-investissent, parce que demander est facile et confiner est difficile. Mais une invite est une question que le modèle espère que vous saurez bien répondre à 18 h un vendredi. Isoler l'arborescence des processus de l'agent, avec un réseau restreint et des montages du système de fichiers limités, rend des classes entières de pannes impossibles, quoi que fassent le modèle ou l'utilisateur. J'ai détaillé ce compromis dans confinement contre surveillance pour les agents IA ; ma version courte : les invites relèvent de la surveillance, le bac à sable relève du confinement, et il faut du confinement pour tout ce qui est irréversible. L'écosystème des CLI apprend lentement cette leçon. Ceux qui l'apprendront le plus vite gagneront la confiance qui permet aux utilisateurs d'activer réellement l'auto-approbation pour les 90 % routiniers.

Extensibilité et le problème des modèles auto-hébergés

Deux leçons plus modestes issues de la discussion autour de la 2.0 méritent attention. D'abord : « tout est un plugin » est en train de gagner. Les utilisateurs construisent des compétences, des éditeurs de configuration et des hooks de workflow par-dessus ces harnais, et le harnais qui fait des plugins des citoyens de première classe, rechargés à chaud, capables d'observer les sessions et de modifier le comportement, multiplie l'effort de la communauté au lieu de le combattre. Le signe qu'OpenCode prend cela au sérieux : leur propre application GitHub trie les rapports de bugs en reproduisant le problème et en commentant les conclusions, en utilisant essentiellement l'agent pour maintenir l'agent. C'est cette « conscience de soi » saluée par les utilisateurs, et c'est un résultat de l'architecture à plugins, pas du modèle.

Ensuite : être agnostique vis-à-vis du modèle est plus difficile qu'il n'y paraît, et c'est un problème de format de contexte. Un utilisateur a essayé un excellent modèle local entraîné à émettre des commandes en bash, alors que le harnais attendait obstinément des appels d'outils de type JavaScript, et les deux ne pouvaient tout simplement pas interopérer. C'est le couplage caché de tout harnais d'agent : le format des appels d'outils, les hypothèses du prompt système et la distribution d'entraînement du modèle doivent être alignés. Un harnais qui code en dur les conventions d'une seule famille de modèles n'est pas agnostique, il est tout au plus tolérant. Si les modèles locaux doivent compter pour les agents de codage, et pour des raisons de coût et de confidentialité ils devraient, les harnais ont besoin de dialectes d'appels d'outils enfichables, et pas seulement de points d'accès API enfichables.

Là où la thèse à contre-courant montre ses limites

J'ai dit que le modèle est la partie facile. Il est temps de concéder les marges. La thèse tient pour la conception du harnais (boucles, contexte, permissions), mais il existe des endroits où le modèle est réellement le goulot d'étranglement. La fiabilité de l'usage d'outils est elle-même entraînée dans le modèle ; un modèle incapable d'émettre de façon constante des appels de fonction valides fait paraître tout harnais défaillant, et aucune concurrence structurée à base d'Effect ne corrigera un modèle qui se dispute avec son propre schéma. La planification multi-étapes sur de longs horizons distingue encore les niveaux de modèles d'une manière que l'on ressent dans une seule session. Et l'opposition harnais/modèle a une durée de vie limitée : à mesure que les modèles absorbent le comportement agentique dans leur entraînement (usage natif des outils, planification native sur de longs horizons), les capacités migrent du harnais vers les poids, et la fonctionnalité astucieuse d'aujourd'hui devient l'effort gaspillé de demain. Les équipes qui construisent des harnais doivent supposer qu'elles construisent un échafaudage que les modèles finiront par rendre obsolète, ce qui, honnêtement, est un argument en faveur des harnais open source à écosystème de plugins, car ceux-ci survivent grâce à la communauté plutôt que grâce à un écart de capacité temporaire.

Il existe aussi un plancher d'UX qu'aucune architecture ne justifie. Certains utilisateurs ont essayé OpenCode 2.0 et l'ont trouvé maladroit ; d'autres se sont plaints d'un démarrage lent et d'une base d'historique de discussions mortes qui ne cesse de grossir. Ce ne sont pas des problèmes profonds, mais ce sont ceux qui font fuir les gens dans les dix premières minutes, avant même que l'élégante boucle d'agent ait l'occasion de briller. La finition est aussi une fonctionnalité, et c'est celle que les projets open source sous-financent le plus souvent.

Le modèle écrit le code, mais le harnais décide si vous lui faites assez confiance pour le laisser agir.

Mon conseil pragmatique, en tant que personne qui a vu cette catégorie se renouveler sans cesse : choisissez votre agent de codage comme vous choisiriez une base de données, pas comme le vainqueur d'un benchmark de modèles. Regardez la gestion des pannes de la boucle, la politique de contexte, la granularité des permissions, et si les sessions survivent à la fermeture de votre terminal. Ce sont les éléments qui compteront encore après la prochaine sortie de modèle, qui rendra tout le monde également intelligent.