C'est quoi un CLI ? La machine à café sans boutons que votre agent IA adore

Un écran noir, un curseur qui clignote, et des lignes de texte qui défilent. Dans les films, c’est l’écran du hacker. Dans la vraie vie, c’est simplement un terminal. Il fait peur au commun des mortels, mais pourtant, il n’a rien d’insurmontable. Au lieu d’avoir des boutons et des menus, on a seulement du texte.

Moi, j’y passe pas mal de temps. En tant que développeur, j’ai utilisé un tas d’outils en ligne de commande. Quand on administre un serveur, par exemple, il n’y a souvent aucune interface graphique : on s’y connecte à distance (en ssh, je glisse un petit mot au passage pour la culture), et tout se fait en tapant des commandes.

Cet écran qui intimide tant est devenu le terrain de jeu préféré des agents IA. Dans l’article sur les MCP, je disais d’ailleurs que je passe désormais surtout par des CLI. Il est temps d’expliquer ce que c’est.

Pourquoi connecter son agent, déjà ?

Petit rappel, si vous arrivez directement ici.

Un agent IA repose sur un modèle qui a appris énormément de choses sur le monde. Mais il ne sait rien de vous : ni vos mails, ni votre agenda, ni vos projets. En le branchant à vos outils, il travaille avec vos vraies données, et il peut agir à votre place.

C’est le sujet de l’article qui ouvre cette série, si vous voulez creuser.

Une machine à café sans boutons

CLI veut dire Command Line Interface, interface en ligne de commande en français. C’est une façon d’utiliser un programme en lui écrivant des ordres, plutôt qu’en cliquant sur des boutons.

Pour l’imaginer, prenez une machine à café multifonction, celle du bureau. Elle a un bel écran tactile, des boutons, des images de cappuccino, allongé, latte, déca, etc. C’est pensé pour des humains : on regarde, on appuie, on boit et on discute avec les collègues du dernier bug en prod.

Maintenant, retirez l’écran et les boutons. Il ne reste qu’une fente, dans laquelle on glisse un ticket. Sur ce ticket, on écrit ce qu’on veut :

café faire --taille grand --sucre 1

La machine lit le ticket, prépare le café, et ressort un petit ticket de réponse : « Grand café, 1 sucre. Bonne journée. »

On peut aussi lui glisser café lister, et elle imprime la liste de toutes les boissons qu’elle sait faire. Ou café --help, et elle imprime sa notice : toutes les commandes possibles, avec leurs options.

Un CLI, c’est cette fente à tickets. Le terminal, c’est la fenêtre dans laquelle on écrit les tickets (le fameux écran noir). Et chaque service peut avoir sa propre machine : un CLI pour GitHub, un pour Google Workspace, etc.

Une vraie commande ressemble à ça :

gh pr list

gh, c’est le CLI de GitHub (le service où les développeurs versionnent leur code). pr list lui demande la liste des demandes de revue en cours sur un projet. Il répond par quelques lignes de texte, une par demande.

Pour un humain, la machine sans boutons est clairement moins pratique. Il faut connaître les commandes, les écrire sans faute, et c’est moins joli. Mais pour un agent ?

Pourquoi les agents adorent ça

Écrire un ticket, c’est exactement ce qu’il sait faire. Un modèle de langage lit et écrit du texte. Lui faire appuyer sur des boutons dans une interface, c’est possible, mais c’est lent et laborieux. Lui faire écrire une commande, c’est naturel. Et la réponse revient en texte, qu’il lit sans effort.

Il connaît déjà la machine. Les CLI répandus existent souvent depuis des années, bien avant les agents. gh en est un bon exemple. Leurs commandes apparaissent dans des tonnes de documentations, de tutoriels et de forums, donc dans ce que les modèles ont ingéré pendant leur entraînement. Pas besoin de tout leur expliquer : ils savent déjà s’en servir.

La notice ne se lit qu’au besoin. Avec un MCP, l’agent reçoit souvent dès le début de la conversation la description de tous les outils disponibles. C’est comme si chaque machine vous imprimait sa carte complète au moment où vous entrez dans la pièce. Avec un CLI, l’agent ne demande --help que lorsqu’il en a besoin, et seulement pour la machine qui l’intéresse. Résultat : beaucoup moins de tokens consommés, une mémoire de travail moins encombrée. Les comparaisons qu’on trouve en ligne vont dans ce sens, même si l’écart varie beaucoup d’un test à l’autre.

Les erreurs aussi sont des tickets. Une commande mal écrite ? La machine ressort un ticket : « option inconnue », « projet introuvable ». L’agent le lit, corrige, et réessaie. Pas besoin d’interpréter une fenêtre d’erreur rouge.

Dans mon cas

Mes agents utilisent déjà mon terminal en permanence, pour des choses très basiques : chercher des fichiers, gérer l’historique d’un projet avec git, lancer un petit programme Python, vérifier la qualité du code. Ce sont des commandes que j’utilise moi-même depuis longtemps.

Et j’ai installé d’autres CLI exprès pour eux. gh, par exemple. Avec lui, mon agent peut créer une demande de modification sur GitHub, la surveiller, voir les erreurs quand les vérifications automatiques échouent, et réagir pour les corriger.

Petit bonus : ce sont des outils que je sais utiliser aussi. L’agent et moi parlons la même langue, avec les mêmes commandes.

Comment on en ajoute un

Il faut un agent qui a accès à un terminal. C’est le point de départ. Les agents qui travaillent sur votre machine, comme Claude Code ou Codex, en ont un. Le chat web de Claude ou ChatGPT, non. (Petit clin d’œil au passage : Claude Code et Codex sont eux-mêmes des CLI.)

On installe le CLI. En général, une commande copiée depuis la documentation du service. Ou, plus simple : on demande à son agent. « Installe le CLI de GitHub », et il s’en occupe.

On se connecte. Le CLI doit savoir pour qui il travaille. Souvent, une commande ouvre votre navigateur, vous vous connectez à votre compte, et c’est réglé. Parfois, il réclame une clé d’API, le fameux badge d’hôtel de l’article précédent.

L’agent s’en sert. S’il connaît déjà le CLI, rien à faire. Sinon, il lit la notice. Certains CLI récents sont même pensés pour les agents dès le départ : ils peuvent être livrés avec des skills, des petits modes d’emploi prêts à donner à votre agent.

Les limites

Pas de terminal, pas de CLI. Si vous utilisez l’IA depuis le chat web ou l’application mobile, cette voie vous est fermée. Les connecteurs ou les MCP distants restent alors la solution alternative.

C’est souvent très permissif. Un CLI fait en général tout ce que votre compte permet de faire. Lire, oui, mais aussi supprimer, publier, modifier des réglages. Et l’agent l’utilise avec vos droits. La plupart des agents demandent votre accord avant de lancer une commande, au moins au début : prenez le temps de lire ce que vous validez. Et quand le service le permet, limitez les droits de la connexion ou de la clé.

Tous les services n’en ont pas. Les outils de développeurs en ont presque tous. Pour d’autres services plus grand public, c’est moins systématique.

Attention à ce que vous installez. Un CLI tourne sur votre machine, avec vos droits. Même réflexe que pour les skills et les MCP : on préfère l’outil officiel du service, et on vérifie la source avant d’installer quoi que ce soit. L’avantage ici, c’est que la plupart des CLI existent depuis assez longtemps pour avoir été éprouvés et audités, bien avant l’arrivée de l’IA.

CLI ou MCP ?

Pour le moment, quand j’ai le choix, je prends le CLI. Il existait souvent avant, il a fait ses preuves, l’agent sait déjà s’en servir, c’est rapide et ça consomme beaucoup moins de tokens.

Mais je ne les oppose pas. Rien n’oblige à n’utiliser que l’un ou l’autre, et chacun a ses bonnes raisons d’exister :

• certains services n’ont qu’un MCP ;
• on n’a pas forcément envie de donner à un agent l’accès à un terminal ;
• le web et l’app mobile ne permettent pas d’utiliser des CLI ;
• un MCP peut volontairement ne proposer que quelques actions, là où un CLI ouvre souvent tout.

Ce dernier point, je l’ai vécu. Dans l’article sur les MCP, je racontais ce petit MCP que j’avais fait pour un agent de mon homelab : trois actions git, pas une de plus, et pas de terminal. Avec le CLI git, il aurait pu tout faire, y compris des bêtises. Là, il ne pouvait littéralement pas.

Pas besoin d’aimer l’écran noir

Un CLI, c’est une machine sans boutons, qu’on pilote en lui glissant des tickets. Peu engageant pour nous, parfait pour un agent qui ne fait qu’écrire et lire du texte. Et vous n’avez même pas besoin d’écrire les tickets vous-même : c’est son travail.

Jusqu’ici, dans cette série, c’est toujours l’agent qui va chercher l’information ou qui agit quand on le lui demande. Il est à l’initiative de la demande, en début de chaîne. Mais si c’était au service de le prévenir quand il se passe quelque chose ? Un mail qui arrive, un paiement reçu, un formulaire rempli. C’est le rôle du webhook, et ce sera le prochain article.

Connecter un agent IA à d’autres services :

• Comment connecter son agent IA à ses outils (Gmail, Notion, Google Agenda…) ?
• C’est quoi un connecteur IA ? Relier Claude ou ChatGPT à vos outils en quelques clics
• C’est quoi un MCP ? Le port USB-C qui branche votre agent IA à vos outils
• C’est quoi une clé d’API ? Le badge d’hôtel qui ouvre vos outils à votre agent IA
• C’est quoi un CLI ? La machine à café sans boutons que votre agent IA adore
• C’est quoi un webhook ?

Hors-série complémentaire :

• C’est quoi une API (Application Programming Interface) ?