Et si l’outil le plus puissant pour vos agents IA n’était pas une interface sophistiquée, mais une simple ligne de commande héritée des années 70 ?
Alors que le MCP semblait s’imposer comme le standard universel, une tendance silencieuse bouleverse les développeurs : le retour aux CLI, ces outils en ligne de commande qui consomment moins, exécutent plus vite, et résistent à l’épreuve du temps.
Le MCP a longtemps été considéré comme l’interface universelle de l’Agent, la norme permettant de connecter tous les outils.
Mais récemment, de plus en plus de développeurs de haut niveau ont commencé à l’abandonner discrètement, préférant recourir à une méthode plus rudimentaire pour résoudre leurs problèmes : l’appel direct de programmes en ligne de commande.
- Par exemple, pour convertir un format vidéo, il suffit d’une ligne de commande ffmpeg.
- Pour rechercher un fichier, une ligne de commande grep.
- Pour redimensionner une image, une ligne de commande ImageMagick.
Ces commandes ont un point commun : elles s’exécutent généralement dans une interface en ligne de commande. En anglais, on parle de Command Line Interface, ou CLI. C’est pourquoi on appelle ces outils des outils CLI.
En effet, les exemples précédents avec ffmpeg, grep et ImageMagick sont tous des outils CLI. Attention, il ne s’agit pas d’une mode réservée à une poignée de geeks. En mars dernier, le directeur technique de Perplexity a annoncé publiquement lors d’une conférence de développeurs que son entreprise était en train de passer entièrement aux API et aux outils CLI, abandonnant le MCP. Le PDG de Y Combinator a également choisi d’utiliser la CLI plutôt que le MCP.
Quant à OpenClaw, qui a récemment connu un succès fulgurant, il utilise presque exclusivement des outils internes et des commandes CLI pour exécuter ses tâches, et l’on ne voit pratiquement jamais MCP à l’œuvre. Mais une question se pose : MCP est clairement une norme d’interface d’outils spécialement conçue pour les grands modèles, alors pourquoi se fait-elle aujourd’hui supplanter par les anciens outils CLI ?
Le grand retour des outils que l’on croyait obsolètes
Puisque les outils CLI gagnent de plus en plus de popularité, ils doivent nécessairement présenter des avantages très évidents.
J’ai fait le point et je pense que les avantages des outils CLI se résument principalement à deux points : une faible consommation de jetons et une grande efficacité d’exécution.
Faible consommation de tokens
Commençons par le premier point. Les outils CLI consomment peu de tokens.
En fait, vu sous un autre angle, cela signifie que les outils MCP consomment beaucoup de tokens. Oui, c’est exact, en particulier les métadonnées du MCP, notamment le nom, la description, le format des paramètres d’entrée, etc. Toutes ces informations sont transmises au contexte du grand modèle, ce qui entraîne une consommation importante de tokens.
Prenons un exemple concret. Supposons que nous souhaitions connaître les bugs récents d’OpenClaw afin de les corriger et de nous offrir ainsi une occasion de nous exercer. Nous pouvons alors interroger le grand modèle en lui demandant quels sont les trois derniers tickets de ce dépôt GitHub OpenClaw. Notez bien que ce ne sont pas seulement les questions des utilisateurs qui sont transmises au grand modèle, mais également la liste des outils MCP disponibles.
Par exemple, « list issues » sert à consulter la liste des tickets, « create branch » à créer une branche Git, etc. C’est ainsi que le grand modèle peut sélectionner l’outil MCP le plus pertinent par rapport au problème de l’utilisateur et l’appeler. Bien sûr, cette liste d’outils n’est pas envoyée par l’utilisateur, mais par des programmes tels que Claude Code et Codex.
Mais voilà où réside le problème. La liste d’outils que nous envoyons au grand modèle ne se limite pas simplement aux noms des outils. En réalité, nous lui transmettons également les informations détaillées de chaque outil.
- Par exemple, comment s’appelle l’outil,
- ce qu’il permet de faire,
- quels paramètres il faut lui passer lors de son appel,
- quel est le format de chaque paramètre, etc.
Ces métadonnées sur les outils occupent un nombre considérable de tokens.
Prenons l’exemple de l’outil « list issues » pour voir combien d’informations il contient. Voici sa description : elle compte au total 67 lignes. Vous vous dites peut-être que 67 lignes, ce n’est pas tant que ça, que ça devrait aller. Mais le problème, c’est que nous n’envoyons pas qu’un seul outil. En général, nous envoyons au modèle la liste de tous les outils disponibles.
Utilisons le serveur MCP de GitHub. Combien d’outils ce serveur MCP contient-il ? 44. Quelle est la quantité d’informations pour ces 44 outils réunis ? Je n’arrive même pas à tout parcourir. Voyons voir : il y a au total 1 683 lignes. Quant au nombre de caractères, il est d’environ 63 703.
Que représentent ces 63 703 caractères ? Calculons le nombre de tokens. Au total, cela représente 14 268 tokens. J’ai fait le calcul en me basant sur le prix du modèle Claude Sonnet : un tel nombre de tokens coûte environ 0,30 centimes.
Ne pensez pas que 3 centimes, ce n’est pas grand-chose : nous ne prenons ici en compte qu’un seul serveur MCP sur GitHub. Si vous installez plusieurs serveurs MCP similaires en même temps, rien que pour la documentation des outils, cela peut vous coûter plusieurs euros. Et nous n’avons même pas encore pris en compte le coût de la sortie du modèle. Vu sous cet angle, ce n’est effectivement pas très rentable.
Et si la solution était plus simple qu’il n’y paraît ?
Tout d’abord, le processus est fondamentalement le même, la seule différence étant que nous n’avons pas besoin d’envoyer 44 descriptions d’outils. Nous n’en avons besoin que d’une seule, celle de l’outil bash.
bash est un programme très courant permettant d’exécuter des commandes CLI. Je pense que toute personne ayant déjà écrit un peu de code le connaît. La description de cet outil est également très simple, elle ne fait qu’une dizaine de lignes.
Le cœur de cette documentation tient en une seule phrase : passer un paramètre appelé « command », dont la valeur correspond à la commande que vous souhaitez exécuter. Cette commande sera générée par le grand modèle au moment venu.
Pour le problème de l’utilisateur dont il est question ici, la commande générée par le grand modèle pourrait ressembler à ceci. Cette commande utilise en fait le programme CLI « gh » pour récupérer la liste des tickets.
Nous n’allons pas nous attarder sur les détails, ce n’est pas important. Il suffit d’en avoir une idée générale. Comme vous pouvez le voir dans ce processus CLI, il suffit de passer un outil bash au grand modèle. Et la documentation de cet outil ne compte qu’une dizaine de lignes. Comparé à la documentation de l’outil MCP de plusieurs dizaines de milliers de lignes que nous avons vue précédemment, la consommation de jetons est pratiquement négligeable.
Comment le grand modèle connaît-il des commandes comme gh, git ou grep sans qu’on les lui ait explicitement apprises ?
En réalité, c’est très simple. Pour les programmes CLI courants comme gh, git et grep, le grand modèle a déjà été exposé à de nombreux cas d’utilisation lors de la phase d’entraînement. Il sait donc naturellement comment s’en servir. C’est comme si vous demandiez à un programmeur expérimenté comment utiliser git : il n’irait pas consulter la documentation, mais vous donnerait directement la commande. Mais que faire s’il s’agit d’un outil CLI très peu courant, voire que vous avez écrit vous-même ? C’est tout aussi simple : il suffit de fournir au grand modèle la documentation correspondante. Dans la pratique, cela se fait généralement via une « Agent Skill ». Une Agent Skill est, par essence, un document de référence destiné au modèle.
En résumé, voici la stratégie d’utilisation des programmes CLI par les grands modèles : les programmes courants sont déjà bien intégrés, ils peuvent donc être utilisés directement. Quant aux programmes peu courants, il suffit de fournir un document de référence. Vous comprenez désormais pourquoi nous affirmons que la consommation de jetons de la CLI est nettement inférieure à celle du MCP.
Quand la simplicité devient une arme redoutable
Maintenant que vous avez compris ce point, passons au deuxième. Examinons un scénario concret.
Imaginons que vous soyez photographe et que vous veniez de prendre une série de clichés. Votre dossier contient 10 photos prises avec un reflex. Votre tâche consiste maintenant à repérer toutes les photos au format horizontal, c’est-à-dire celles dont la largeur est supérieure à la hauteur. Une fois ces photos identifiées, vous devez y ajouter votre filigrane personnel. Enfin, vous devez les télécharger sur votre serveur pour les afficher sur votre site web. Cela semble être une tâche courante, n’est-ce pas ?
CLI vs MCP : le duel des outils IA
Quelle solution pour vos agents intelligents en 2026 ?
CLI
MCP
En résumé
CLI pour la rapidité et la flexibilité au quotidien.
MCP pour la sécurité et la stabilité en environnement partagé.
Le choix n’est pas binaire : combinez-les selon vos besoins.
Infographie interactive — Des Geeks et des Lettres
Voyons d’abord ce qui se passe en mode MCP.
Le grand modèle réfléchit d’abord et se rend compte que la première étape consiste à connaître le contenu du dossier. Il fait donc appel à un outil de lecture de répertoire et obtient la liste des noms de fichiers des 10 photos.
Une fois cette liste en main, le grand modèle réfléchit à nouveau et se rend compte que les noms de fichiers ne suffisent pas : il doit également savoir si chaque photo est au format paysage ou portrait. Il fait donc appel à un outil de lecture des informations d’image et obtient les données de largeur et de hauteur de chaque image.
Une fois les dimensions en main, le grand modèle réfléchit à nouveau, filtre les photos au format paysage, puis fait appel à l’outil de traitement d’images pour ajouter le filigrane et obtient le résultat du traitement. Il réfléchit ensuite un peu plus et se rend compte que la prochaine étape consiste à télécharger les fichiers. Il fait donc appel à l’outil de téléchargement pour transférer les photos traitées vers le serveur et obtient le résultat du téléchargement.
Enfin, le grand modèle réfléchit une dernière fois et constate que toutes les tâches sont terminées. Il vous donne alors la réponse finale pour vous indiquer que la tâche est terminée.
Je mets à jour ou crée vos articles personnellement, assisté par l'IA, avec optimisation SEO incluse.
| 📝 Mise à jour | 14 € |
| ✨ Création | 49 € |
Comme vous pouvez le constater, tout au long du processus, le grand modèle est chargé de deux tâches. La première consiste à réfléchir en permanence afin de déterminer si la prochaine étape consiste à appeler un outil ou à fournir la réponse finale. S’il s’agit d’appeler un outil, il doit également décider quel outil utiliser et quels paramètres définir.
La seconde consiste à recevoir en continu les résultats d’exécution des outils. Une fois que chaque outil a traité les données, il doit d’abord revenir vers le grand modèle, qui, après les avoir examinés, peut alors décider de la prochaine étape.
On voit donc que le grand modèle est le centre de coordination de l’ensemble de la chaîne. Toutes les opérations doivent passer par lui, sans exception. Cela signifie qu’à chaque étape du processus, il faut attendre une réponse du grand modèle. C’est naturellement là que réside le goulot d’étranglement en termes d’efficacité globale.
Bon, voyons maintenant comment cela se passe en mode CLI.
C’est toujours le grand modèle qui réfléchit en premier. Mais après avoir réfléchi, il n’appelle qu’un seul outil : bash.
Il transmet à cet outil bash une commande qui se compose globalement de trois parties.
- La première partie, exiftool, est chargée de scanner toutes les photos du dossier et de filtrer celles qui sont au format paysage (largeur supérieure à la hauteur).
- La deuxième partie, ImageMagick, reçoit les noms de fichiers, applique un filigrane à chacune d’entre elles, puis enregistre le résultat dans le dossier output.
- La troisième partie, scp, transfère en masse les photos traitées du dossier « output » vers le serveur.
Une fois la commande envoyée, ces trois étapes s’exécutent automatiquement en local, sans intervention du grand modèle. Ce n’est qu’une fois toutes les opérations terminées que le résultat revient au grand modèle. Après une brève réflexion, le grand modèle constate que le travail est terminé et vous donne la réponse finale : « C’est fait ».
On constate ainsi que la chaîne CLI est bien plus courte que celle de MCP. L’efficacité est donc naturellement bien supérieure.
Pourquoi la CLI permet-elle une exécution plus fluide que le MCP ?
Parce que les programmes CLI peuvent être combinés à volonté. Revenons à cette ligne de commande. Elle contient deux symboles très importants. Le premier est la barre verticale, qui transmet le résultat de la commande précédente à la commande suivante. Le second est le double signe « AND », qui signifie que si la commande précédente s’est terminée avec succès, la commande suivante est alors exécutée. Ce sont ces symboles en apparence insignifiants qui relient des outils initialement indépendants pour former un processus complet. Les tâches qu’ils permettent d’accomplir dépassent largement votre imagination. Derrière cela se cache en réalité une philosophie de conception établie depuis des décennies par le système UNIX : chaque outil ne fait qu’une seule chose, mais la fait à la perfection. Les outils peuvent être combinés librement entre eux, comme des blocs de construction, pour former des processus aussi complexes que souhaité.
exiftool se charge uniquement de lire les métadonnées, ImageMagick de traiter les images et scp de transférer les fichiers. Ils n’interfèrent pas les uns avec les autres, mais collaborent de manière transparente.
C’est précisément cette philosophie qui permet de réaliser un processus automatisé complet en quelques lignes de commande, sans pratiquement aucune limite.
En y repensant, il est difficile d’atteindre ce niveau d’efficacité avec un MCP.
Vous pourriez vous dire : « Pourquoi ne pas regrouper les outils de lecture de répertoires, de lecture des informations d’image, d’ajout de filigrane et de téléchargement en un seul outil MCP ? Cela permettrait de tout faire d’un seul coup. Il suffirait alors d’appeler l’outil MCP une seule fois pour exécuter l’ensemble du processus. Ne permettrait-on pas ainsi d’obtenir le même résultat qu’avec des outils CLI ?
En théorie, c’est tout à fait possible. Mais le problème, c’est qu’il suffit d’un léger changement dans les exigences pour que cet outil ne soit plus suffisant.
Par exemple, vous pourriez vouloir filtrer les photos en résolution 4K, ou convertir toutes les images au format PNG, etc. À chaque modification, il faudrait redévelopper l’outil. Alors que la CLI est intrinsèquement modulable. Il suffit d’ajuster quelques paramètres en fonction des nouvelles exigences, de réassembler le tout, et c’est réglé en quelques secondes. Cette flexibilité est difficile à reproduire avec les outils MCP.
Les atouts cachés du MCP : quand la contrainte devient une force
Après avoir tant vanté les mérites des outils CLI, vous pensez peut-être que les outils MCP ne servent à rien. Ne tirez pas de conclusions hâtives. Si les outils MCP sont devenus la norme dans le secteur, c’est qu’ils possèdent forcément des avantages irremplaçables. J’ai résumé leurs avantages en deux points principaux :
- d’une part, une meilleure contrôlabilité,
- et d’autre part, une plus grande sécurité.
Examinons d’abord le premier point : la meilleure contrôlabilité.
En clair, cela signifie que les outils MCP sont moins sujets aux erreurs. Vous vous souvenez de la commande CLI mentionnée tout à l’heure ? Revenons-y un instant. Elle semble parfaite, n’est-ce pas ? Mais cette commande présente en réalité un problème très grave. Examinons de plus près sa deuxième partie.
Imaginez maintenant qu’un fichier photo horizontal contienne justement un guillemet simple dans son nom, par exemple mark(s) photo.png. Cette commande générerait alors directement une erreur.
En effet, le guillemet simple dans le nom du fichier perturberait la structure des guillemets de la commande elle-même. Ce type de problème est en réalité assez courant dans la CLI. Même si j’ai dit plus tôt que les grands modèles sont très doués pour générer des commandes CLI, la réalité est que plus une commande est complexe, plus le risque d’erreur est élevé. De plus, ce genre d’erreurs est souvent très subtil, et difficile à repérer d’un seul coup d’œil lors d’une vérification humaine.
Mais qu’en est-il si l’on utilise l’outil MCP ?
Pour la même étape d’ajout de filigrane, l’appel de l’outil MCP ressemblerait à peu près à ceci. Comme vous pouvez le voir, le nom du fichier se trouve simplement dans un champ JSON. Qu’il contienne des guillemets simples, des guillemets doubles ou des espaces, cela n’affectera pas l’exécution normale de l’outil. En effet, le JSON possède ses propres règles d’échappement et les limites des paramètres sont clairement définies. Il n’y a donc pas de conflit avec la syntaxe de la commande elle-même, contrairement à la CLI.
Par conséquent, les résultats d’exécution de l’outil MCP sont plus contrôlables et le risque d’erreur est plus faible.
MCP est plus contrôlable. Passons maintenant au deuxième point : les outils MCP sont plus sûrs.
La flexibilité des commandes CLI est une arme à double tranchant. Elle permet de tout faire, ce qui signifie aussi qu’elle peut tout gâcher. Si la commande générée par le grand modèle contenait par exemple une opération de type rm (ou rf), des fichiers locaux risqueraient d’être supprimés par erreur.
Il est possible que le grand modèle ait de bonnes intentions et qu’il veuille simplement supprimer des fichiers temporaires. Mais nous ne pouvons pas éviter qu’il commette des erreurs. Et vous ne vous en rendrez peut-être compte qu’après l’exécution, mais à ce moment-là, il sera déjà trop tard.
Dans un environnement local, ce risque est peut-être acceptable. Au pire, vous en assumez vous-même les conséquences. Mais qu’en est-il dans un environnement cloud ?
De nombreux services d’automatisation cloud, comme Make, vous permettent d’intégrer des services MCP dans votre workflow. Mais ils ne vous laisseront jamais exécuter directement une commande bash. La raison est simple : il s’agit d’un environnement partagé. Chaque opération que vous effectuez peut avoir un impact sur les autres utilisateurs.
Une fois les autorisations CLI accordées, une commande incontrôlée peut potentiellement mettre hors service l’ensemble du serveur, voire tout le cluster. Bien sûr, certains produits cloud prennent désormais en charge la CLI. Mais en y regardant de plus près, on constate qu’ils imposent en réalité des restrictions strictes.
Fondamentalement, ils utilisent des bacs à sable et des contrôles d’accès pour confiner les risques dans une zone maîtrisée. Le coût de cette approche est très élevé. De plus, il est difficile d’atteindre le même niveau de sécurité qu’avec MCP. C’est pourquoi, dans les scénarios où les exigences de sécurité sont très élevées, la conception restreinte de l’outil MCP devient en fait un avantage. Il ne peut faire que ce que ses concepteurs lui permettent de faire, ni plus, ni moins.
Quelle stratégie adopter pour vos projets ?
Vous voyez donc que le MCP n’est pas sans intérêt. En termes de contrôlabilité et de sécurité, il est en effet plus performant que la CLI. C’est pourquoi, dans les scénarios où ces deux aspects sont primordiaux, le MCP reste une fonctionnalité indispensable.
Après avoir passé en revue les avantages et les inconvénients des deux approches, nous allons enfin répondre à cette question centrale.
Mon pronostic est que la part des outils CLI va augmenter, tandis que celle du MCP va progressivement diminuer.
La raison est simple : comme nous l’avons déjà analysé, la CLI consomme moins de jetons et offre une meilleure efficacité d’exécution. Pour une tâche que le modèle peut accomplir en une seule ligne de commande, le MCP nécessite plusieurs allers-retours. Pour la plupart des cas de figure et de la plupart des utilisateurs, la CLI est tout simplement un choix plus rapide, moins coûteux et plus direct.
C’est précisément pour cette raison que la CLI se prête naturellement davantage à une utilisation légère et personnalisée. Et le MCP ? Son utilisation va progressivement diminuer, mais il ne disparaîtra pas.
Comme le MCP est plus sûr et plus contrôlable, il finira par se cantonner aux scénarios exigeant un niveau élevé de sécurité et de stabilité. Par exemple, dans les entreprises ou dans le cloud. Dans ces contextes, il est impossible de laisser un grand modèle exécuter librement des commandes en ligne de commande. Le mode d’appel structuré et contrôlé qu’offre le MCP reste irremplaçable.
Le paysage final est donc très clair :
- la CLI s’orientera de plus en plus vers les particuliers,
- tandis que le MCP restera dans les entreprises et le cloud.
Voilà, cet article s’achève ici. Si ces réflexions vous ont été utiles, n’hésitez pas à partager vos retours ou à explorer d’autres comparaisons techniques sur le blog.
Pour aller plus loin, vous pouvez tester vous-même la différence entre une approche MCP et une approche CLI sur vos propres workflows. Commencez par identifier les tâches répétitives que vous confiez à vos agents IA, puis expérimentez avec des commandes bash simples avant de migrer vers des solutions plus structurées. Cette méthode progressive vous permettra de mesurer concrètement les gains en performance et en coût, tout en conservant la flexibilité dont vous avez besoin au quotidien.
Enfin, gardez à l’esprit que le choix entre CLI et MCP n’est pas binaire : les deux approches peuvent coexister dans votre stack technique. L’important est de comprendre leurs forces respectives pour les déployer au bon endroit, au bon moment. C’est cette agilité stratégique qui fera la différence dans vos projets d’automatisation intelligents.
A lire aussi sur Des Geeks et des lettres ⇒ MCP HubSpot Claude : test honnête 2026 du connecteur
Pourquoi dit-on que les outils MCP sont plus sûrs que les commandes CLI ?
La flexibilité des commandes CLI est une arme à double tranchant : elle permet de tout faire, mais peut aussi tout gâcher. Dans un environnement cloud partagé, une commande incontrôlée peut impacter d’autres utilisateurs ou même mettre hors service un serveur entier. MCP, en revanche, impose des limites claires : l’outil ne peut exécuter que ce que son concepteur a prévu, avec des paramètres validés et des frontières bien définies. Cette contrainte devient un atout dans les contextes où la sécurité et la stabilité sont prioritaires, comme en entreprise ou sur des infrastructures mutualisées.
