CLI d'agent IA : exécuter et piloter des agents de support depuis le terminal

Ce qu'une CLI d'agent IA signifie vraiment

Une fois le battage médiatique écarté, un « agent IA » est une boucle : un modèle lit une entrée, décide d'une action, appelle un outil, lit le résultat, et recommence jusqu'à ce que ce soit terminé. Une CLI, une interface en ligne de commande, n'est qu'un moyen de piloter cette boucle depuis une fenêtre de terminal plutôt que depuis une application graphique.

Combinez les deux et une CLI d'agent IA devient une surface de contrôle textuelle pour un agent. Vous tapez une commande pour le démarrer, lui confiez une tâche, le pointez vers des outils et des fichiers, regardez défiler ce qu'il fait, et scriptez le tout pour qu'il fonctionne sans que vous ayez à rester assis là. C'est le même instinct qui fait que les développeurs préfèrent git en ligne de commande à une appli Git à clics : c'est plus rapide, c'est reproductible, et ça s'intègre directement dans d'autres scripts.

Si ce schéma a explosé, c'est parce que le terminal s'avère être un excellent foyer pour un agent autonome. Il peut déjà exécuter des commandes, lire et écrire des fichiers, et faire passer la sortie à l'outil suivant. Donnez cet environnement à un modèle capable, et vous obtenez un agent qui peut vraiment accomplir du travail, ce qui est exactement ce que les CLI de codage ont fait en premier.

Pourquoi exécuter un agent IA depuis la ligne de commande

Un tableau de bord est plus accueillant pour un premier regard. Une ligne de commande l'emporte dès l'instant où vous voulez refaire la même chose plus d'une fois. L'attrait tient généralement à l'un de ces points :

• Reproductibilité. Une commande que vous pouvez enregistrer est une commande que vous pouvez réexécuter à l'identique, glisser dans un script, ou transmettre à un coéquipier. Cliquer dans une interface ne permet ni l'un ni l'autre.
• Automatisation. Les CLI s'intègrent dans des tâches cron, des pipelines CI et des webhooks. C'est ainsi qu'un agent passe de « je l'ai exécuté » à « il tourne tout seul chaque nuit à 2 h du matin ».
• Rapidité et concentration. Pas de changement de contexte vers un onglet de navigateur, pas d'attente qu'une page charge. Pour ceux qui vivent déjà dans le terminal, c'est simplement moins de friction.
• Contrôle de version. Une configuration sous forme de fichiers texte signifie que la configuration de votre agent vit dans Git à côté de votre code, avec historique et revue, plutôt que sous forme de clics que personne ne pourra auditer plus tard.

Rien de tout cela n'est spécifique au support, ce qui est déjà un premier indice sur l'origine de tout ceci. Les outils qui ont fait de « CLI d'agent IA » une expression courante ont été construits pour des ingénieurs qui écrivent du logiciel, et cela se voit dans ce en quoi ils excellent.

Les outils de CLI d'agent IA en 2026

Il y a trois couches qu'il vaut la peine de séparer, car on les confond souvent, pour ensuite se demander pourquoi les pièces ne s'emboîtent pas.

Les CLI des fournisseurs de modèles sont la tête d'affiche. Ce sont des agents de terminal publiés par les laboratoires de modèles eux-mêmes. Claude Code est celui d'Anthropic, conçu pour un travail approfondi sur plusieurs fichiers et natif du MCP. Codex CLI est l'agent de terminal open source d'OpenAI, écrit en Rust et sous licence Apache-2.0. Le Gemini CLI de Google est lui aussi open source sous licence Apache-2.0, avec une grande fenêtre de contexte. Ils sont excellents, et carrément destinés à l'ingénierie logicielle.

Les CLI de frameworks sont la couche « construisez le vôtre ». Les frameworks d'agents fournissent des outils en ligne de commande pour échafauder, exécuter et tester des agents que vous définissez en code. C'est là qu'atterrit généralement une équipe qui veut un agent de support sur mesure : vous écrivez la boucle, câblez les outils, et la CLI l'exécute. Contrôle total, et responsabilité totale de tout ce que vous construisez.

Le MCP est la norme de câblage sous-jacente aux deux. Le Model Context Protocol est une norme ouverte introduite par Anthropic fin 2024 pour connecter un agent à des outils et des données externes. Plutôt que de construire à la main une intégration pour chaque application d'IA, vous exposez votre système une seule fois en tant que serveur MCP, et tout agent compatible MCP peut l'utiliser. Une CLI est la façon dont vous pilotez l'agent ; le MCP est la façon dont l'agent atteint votre helpdesk, votre documentation et votre système de commandes.

Voici comment les trois se comparent pour quelqu'un qui envisage un cas d'usage support :

Le tableau rend l'écart évident. Chaque CLI des trois premières lignes est un moyen de construire et d'exécuter un agent. Aucune d'elles n'est un agent de support. Cette distinction résume à elle seule tout le sujet.

Ce que doit couvrir la surface de contrôle d'un agent de support

Supposons que vous ignoriez l'avertissement et décidiez malgré tout d'exécuter un agent de support depuis un terminal. Que doit réellement couvrir la surface de contrôle ? Quatre missions, et une CLI de codage n'aide que pour les deux premières.

Invoquer, c'est exécuter l'agent contre un ticket ou un lot de tickets. Configurer, c'est définir ses instructions, ses outils, et les règles indiquant quand il est autorisé à répondre plutôt qu'à transférer. Observer, c'est lire les journaux et les rapports pour savoir ce qu'il a fait et si c'était juste. Automatiser, c'est la planification, le webhook, le déclencheur qui l'active à chaque nouveau ticket sans humain dans la boucle.

Ce qui est intéressant, c'est que la « ligne de commande » n'est pas le seul moyen de couvrir ces quatre missions. Le coéquipier d'eesel, par exemple, se configure en langage simple et se pilote de façon conversationnelle, si bien que vous mettez à jour son comportement en décrivant le changement plutôt qu'en modifiant un fichier de configuration.

Remarquez l'appel d'outil dans la barre latérale. Sous la couche de langage simple, il y a toujours un véritable outil nommé qui fait le travail, le même primitif qu'une CLI appellerait, sauf que vous n'écrivez pas l'invocation à la main. Pour la mission Automatiser, les exécutions planifiées sont un écran de paramètres, pas un fichier cron qu'il faut surveiller.

Le propos n'est pas que les lignes de commande sont mauvaises. C'est que, pour le support, les quatre missions comptent plus que l'interface, et la plupart d'entre elles concernent vos tickets et vos règles, pas la frappe au clavier.

Le piège : la CLI, ce sont les 10 % faciles

Voici la partie sur laquelle je veux être honnête, car je construis les intégrations d'eesel et je vois où les équipes se retrouvent coincées. Mettre en place un modèle dans un terminal qui répond à une question est vraiment un projet de week-end. On a l'impression d'y être presque. Ce n'est pas le cas, et l'écart est trompeur.

La CLI et le modèle forment le sommet de la pile. La base, la partie qui détermine si l'agent est vraiment bon, c'est tout le reste : ingérer votre centre d'aide, vos tickets passés et vos macros pour qu'il réponde avec votre ton ; se connecter à votre helpdesk et à votre système de commandes pour réellement rechercher des informations et agir ; des règles de confiance pour qu'il ne réponde automatiquement que lorsqu'il le doit et laisse le reste tranquille ; et un moyen de tester tout cela avant qu'un client ne soit de l'autre côté. Ce sont les 90 %, et une CLI de codage ne vous en donne aucun.

La plus grande objection que j'entends de la part des responsables support porte sur ce dernier point : le contrôle. Comme l'a formulé l'un d'eux :

"The AI will never be able to answer 100% of the questions... I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

a DTC supplements CX lead, from an eesel sales call

Construire vous-même ce routage basé sur la confiance, par-dessus une CLI brute, représente un vrai travail. Et cela ne s'arrête jamais : le modèle change, votre produit change, votre documentation change, et le pipeline que vous avez assemblé a besoin de quelqu'un pour continuer à le recoller.

Le construire soi-même ou embaucher un coéquipier déjà prêt

La vraie décision n'est donc pas « quelle CLI d'agent IA ». C'est de savoir si vous construisez tout le pipeline de support vous-même ou si vous embauchez un coéquipier déjà prêt, livré terminé.

Le construire soi-même est le bon choix lorsque la logique de l'agent est votre véritable produit, ou lorsque vous avez des ingénieurs qui veulent posséder chaque couche et continuer à la posséder. Certaines équipes techniques suivent effectivement cette voie, et quelques-unes abandonnent même les outils gérés pour construire directement sur l'API Claude. C'est un choix légitime, et je ne prétendrais pas le contraire.

Mais la plupart des équipes de support ne veulent pas exploiter une application LLM ; elles veulent que leurs tickets obtiennent une réponse. Un client d'eesel, un responsable ingénierie dans une entreprise de distributeurs automatiques de bitcoins et de matériel crypto gérant une base de connaissances de plus de 300 articles, a résumé ce compromis sans détour :

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Karel, GENERAL BYTES

C'est là le facteur décisif : qui l'entretient, pour toujours. Une CLI que vous construisez est un système que vous maintenez en vie. Un coéquipier géré est un système que quelqu'un d'autre maintient en vie, et vous vous contentez de le pointer vers votre helpdesk.

Essayez eesel

Si la mission est un agent de support et non un copilote de codage, eesel est le raccourci qui saute les 90 %. C'est un coéquipier de helpdesk IA qui s'installe dans le helpdesk que vous utilisez déjà, Zendesk, Freshdesk, Gorgias, Slack et bien d'autres, s'entraîne sur vos tickets et votre documentation passés, et rejoint la file d'attente en quelques minutes plutôt qu'après un cycle de développement.

Ce qui fait la différence, c'est la partie qu'une CLI ne peut pas vous offrir : vous simulez l'agent sur votre historique réel de tickets avant la mise en production, vous voyez exactement où il est solide et où il a des lacunes, et vous n'activez l'autonomie que sur les tickets qu'il gère bien. Un client, Gridwise, l'a vu résoudre 73 % des demandes de niveau 1 dès le premier mois. Et lorsque vous voulez vraiment un contrôle programmatique, l'API et l'accès aux outils de type MCP sont là, si bien que vous obtenez les avantages de script d'une CLI sans posséder le pipeline qui se trouve derrière. La tarification est basée sur l'usage, environ 40 centimes de dollar par ticket résolu sans frais par siège, de sorte que le coût correspond au travail effectué. Vous pouvez l'essayer gratuitement sans appel commercial.