Choisir entre CLI et MCP, ce qui compte vraiment

Les agents IA n’ont plus seulement besoin d’exécuter des tâches: ils doivent collaborer, changer de machine et respecter des permissions qui varient à chaque projet. Face à cette réalité, le choix entre une commande CLI et un serveur MCP dépasse la question d’interface. Il révèle comment vous déléguez votre confiance et votre contrôle.

Le critère que personne ne regarde, la délégation de permission

Un outil CLI, c’est un couteau suisse. Vous le donnez à votre agent, et il peut tout faire. Ouvrir des fichiers, lancer des scripts, modifier des configurations, supprimer des données.

La seule limite, c’est l’utilisateur système sous lequel tourne la commande. En local, sur un poste de développeur, c’est souvent l’utilisateur principal. Celui qui a accès à tout.

Un serveur MCP arrive avec un périmètre. Chaque outil expose des paramètres typés, des contraintes de format, parfois des règles de validation. Ce n’est pas une contrainte technique.

C’est une décision d’architecture. Vous ne donnez pas à l’agent « la machine », vous lui donnez « trois actions précises sur ce service précis ».

• Une CLI donne un accès système complet, limité seulement par l’utilisateur qui l’exécute.
• Un serveur MCP expose des outils typés, avec des paramètres et des contraintes de format.
• La différence n’est pas technique, elle est dans le périmètre que vous acceptez d’ouvrir.

J’ai vu des collègues brancher un agent sur un serveur de production avec un accès CLI complet. 3 jours plus tard, un script de nettoyage mal généré avait supprimé des logs qu’il ne fallait pas toucher. Pas de drame.

Mais une sueur froide. Avec MCP, ce scénario est structurellement plus difficile à produire.

Ce principe de délégation limitée structure depuis des décennies la gestion des annuaires d’entreprise. Dans Active Directory, les bonnes pratiques déconseillent d’attribuer des permissions directement sur un utilisateur. On crée des groupes, on délègue des tâches précises (réinitialiser un mot de passe, modifier un numéro de téléphone) sans jamais donner les clés du domaine.

La délégation de pouvoir en droit français obéit à la même logique : pour être valable, elle doit être précise, limitée, et accordée à une personne identifiée. Ce qui vaut pour un administrateur humain vaut pour un agent IA. La question n’est pas de savoir si vous faites confiance à la machine, mais si le périmètre de cette confiance est explicite ou implicite.

Le piège du benchmark, mesurer ce qui n’est pas mesurable

14 268 tokens pour la doc GitHub MCP, 0,30 centime par appel, 55 000 tokens injectés avant la moindre action utile. Ces données sont réelles, vérifiées, et elles donnent l’impression d’un verdict scientifique. Mais elles mesurent une seule chose : le coût d’entrée.

Elles ne mesurent pas le coût de sortie. Le temps passé à déboguer une commande shell qui échoue silencieusement. Le risque d’une variable d’environnement mal interprétée. Le coût humain d’une revue de code qui doit vérifier chaque ligne générée par l’agent.

Un benchmark vous dira que la CLI est plus rapide. Il ne vous dira pas que cette rapidité suppose un opérateur qui comprend ce que fait chaque commande. Si vous déléguez à un agent sans garde-fou, la rapidité multiplie les erreurs. Aucun outil de mesure ne le capture.

Ce biais a un nom dans la littérature : la conception de benchmarks fonctionne comme un engagement théorique. Des hypothèses contestées ou étroites se normalisent au sein d’une discipline, jusqu’à être traitées comme des faits objectifs concernant la capacité mesurée. C’est ce qui se passe dans le débat MCP versus CLI : on mesure les tokens parce que c’est mesurable, et on en conclut que la CLI est supérieure.

Mais comme le rappelle Vincent Bouton, ce qui ne se mesure pas compte. Ressentir n’est pas être irrationnel : c’est capter des signaux que les chiffres ne voient pas toujours, l’ambiance d’une équipe, la relation de confiance avec un outil, l’émotion d’un débogage à 2 heures du matin. Ce n’est pas l’ennemi de la mesure, c’est son complément.

Dans le quantique comme dans l’IA, celui qui écrit le benchmark écrit le récit. Les classements de modèles façonnent la perception de ce qui est « bon » ou « mauvais », souvent au détriment de critères plus difficiles à quantifier : la maintenabilité, la robustesse aux cas limites, la capacité à échouer proprement. Ce sont pourtant ces critères qui déterminent si un outil survivra à son premier incident de production.

Ce que le retour de la CLI dit vraiment du marché

Quand le directeur technique de Perplexity annonce publiquement un passage aux API et aux CLI, c’est un signal. Les entreprises qui construisent des agents IA à grande échelle découvrent que la standardisation a un coût, et que ce coût se paie en tokens, en latence, et en complexité de débogage.

Le retour aux outils CLI n’est pas un rejet du MCP. C’est une réaction à la sur-ingénierie. On a voulu tout standardiser, tout encapsuler, tout sécuriser par le protocole. Résultat : des contextes gonflés de métadonnées que le modèle ne lit qu’à moitié, des allers-retours qui ralentissent chaque décision, et une dépendance à des serveurs qui tombent en panne au pire moment.

Les chiffres récents donnent raison à ce mouvement, avec une nuance. Une étude Microsoft de 2026 a mesuré une augmentation de 24 % des pull requests fusionnées chez les adopteurs d’agents CLI. Le gain est réel, mais conditionnel : il suppose des équipes qui savent déjà ce qu’elles font.

Pour une PME qui découvre l’automatisation, ce même gain peut se transformer en dette technique si personne ne comprend ce que l’agent exécute. La CLI n’est pas une baguette magique, c’est un amplificateur de compétence. Source : slavadubrov.com

Le facteur dont on ne parle jamais, la maintenance dans le temps

Un outil CLI écrit en bash ou en Python dure. Grep existe depuis 1973, ffmpeg depuis 2000, ImageMagick depuis 1990. Ces programmes traversent les modes.

Ils font une chose. Ils ne dépendent pas d’un écosystème qui change tous les 6 mois.

Un serveur MCP dépend d’un protocole jeune, de SDK qui évoluent, de versions de spécification qui cassent la compatibilité. Ce n’est pas un défaut. C’est le prix de l’innovation.

Mais pour un outil qui doit durer 5 ans, la question se pose autrement. Allez-vous maintenir un serveur MCP pendant 5 ans, ou une commande CLI qui ne bouge plus depuis 10 ans ?

J’ai vu trop de projets abandonnés parce que la dépendance au framework pesait plus lourd que le service rendu. La CLI ne fait pas ce coup-là. Elle est là, brute, sans couche d’abstraction. Elle fonctionne encore quand tout le reste a changé.

Le facteur temps ne sonne jamais 2 fois, comme le dit Étienne Klein. En maintenance prédictive, le temps est la variable clé : une panne détectée tard coûte plus cher qu’une panne anticipée. Il en va de même pour les outils logiciels. Une commande CLI qui existe depuis 30 ans a traversé assez de pannes, de migrations et de changements de contexte pour qu’on estime son coût de maintenance futur.

Un serveur MCP qui a 6 mois d’existence est une promesse : il peut devenir un pilier comme disparaître à la prochaine version majeure du protocole. La maintenance n’est pas qu’une question de correctifs, c’est une question de prévisibilité. Sur ce terrain, l’ancienneté est un actif que les benchmarks ne valorisent pas.

La grille de décision que j’utilise

Quand je dois choisir pour un projet, je ne regarde ni les tokens ni la mode. Je me pose trois questions, dans l’ordre.

Première question : qui subit les conséquences d’une erreur

Si c’est moi seul, la CLI est acceptable. Si c’est une équipe, un client, ou un serveur partagé, je pars sur MCP.

Deuxième question : l’outil doit-il être composé avec d’autres ? Si oui, la CLI et les pipes Unix sont imbattables. Si l’outil est une brique isolée avec des paramètres stricts, MCP suffit.

Troisième question : quelle est la durée de vie prévue

Pour un prototype ou un usage personnel, la CLI. Pour une intégration durable dans un produit, MCP apporte la stabilité contractuelle qui manque aux commandes libres.

Ces trois questions éliminent 80 % des débats. Le reste, c’est du style.

J’ajoute parfois une quatrième question, héritée des bonnes pratiques de gestion des permissions dans les systèmes d’entreprise :

• Le périmètre d’action est-il stable ou évolue-t-il selon les projets ?
• Les personnes qui utiliseront l’outil ont-elles le même niveau de compétence ?
• Existe-t-il un mécanisme de révocation si l’outil est compromis ?

Ces questions ne sont pas glamour. Elles transforment un choix d’interface en choix de gouvernance. C’est ce dont il s’agit quand on branche un agent sur des systèmes réels.

L’angle que les comparatifs n’abordent pas, l’auditabilité

Les benchmarks ne mesurent jamais votre capacité à comprendre ce que l’agent a fait après coup. Avec une commande CLI, vous avez la commande exacte, dans les logs, réexécutable à l’identique. Vous pouvez la relire, la tester, la corriger. C’est un artefact d’audit parfait.

Avec MCP, vous avez un appel JSON structuré, plus propre, mais qui ne dit pas toujours pourquoi l’agent a choisi cet outil plutôt qu’un autre. La traçabilité est meilleure sur le format. Moins bonne sur l’intention.

L’auditabilité se définit comme la qualité de ce qui peut faire l’objet d’un audit, d’une vérification ou d’un contrôle. Un système est auditable lorsqu’on peut reconstituer son fonctionnement après coup, sans ambiguïté. Sur ce critère, la CLI a un avantage structurel : la commande exécutée est l’action elle-même, pas une représentation intermédiaire.

Mais il ne faut pas confondre traçabilité technique et compréhension réelle. La trace d’interprétation vise une auditabilité externe, pas une introspection complète : ce qui compte n’est pas de savoir quels octets ont transité, mais de pouvoir répondre à la question « pourquoi cette action a-t-elle été choisie, et était-ce la bonne ? ».

Le mouvement en faveur de l’audit, dans les comptes publics comme dans l’industrie logicielle, s’explique par un mécanisme simple : lorsqu’un système devient trop complexe pour être compris directement, on exige qu’il soit auditable. C’est une compensation. Mais l’audit a un coût, rarement pris en compte dans les comparatifs d’outils. Une commande CLI s’audite en la relisant.

Un serveur MCP s’audite en reconstituant une chaîne de décisions. Le premier prend 5 minutes, le second peut prendre une journée. Si vous n’avez jamais fait un post-mortem d’incident, cette différence vous paraîtra abstraite. Le jour où vous en ferez un, elle deviendra concrète.

La vraie ligne de partage, qui garde la main sur le raisonnement

Au fond, le débat MCP contre CLI masque une question plus ancienne : jusqu’où déléguez-vous le contrôle ? La CLI donne à l’agent une liberté presque totale, et vous fait confiance pour poser les garde-fous vous-même. Le MCP déplace une partie de cette responsabilité dans le protocole, et vous fait confiance pour choisir les bons outils.

Ce ne sont pas deux interfaces concurrentes. Ce sont deux philosophies de délégation. L’une suppose un opérateur compétent, l’autre un système contraint.

Selon les projets, vous serez l’un ou l’autre. Parfois les deux dans la même journée.

J’ai passé assez d’années dans des environnements où une erreur de manipulation avait des conséquences réelles pour comprendre que la contrainte n’est pas un ennemi. Mais j’ai aussi vu assez de projets étouffés par des couches d’abstraction inutiles pour savoir que la liberté n’est pas un luxe.

Cette tension n’est pas propre à l’IA. Elle traverse l’histoire de l’ingénierie logicielle. Les mêmes débats ont eu lieu sur les ORM face au SQL brut, sur les frameworks face aux bibliothèques légères, sur les microservices face au monolithe.

À chaque fois, la réponse n’est pas dans le choix binaire, mais dans la capacité à varier le niveau de contrainte selon le contexte. Une équipe mature n’est pas celle qui a choisi le bon camp. C’est celle qui sait passer de l’un à l’autre sans drame, et qui documente les raisons de chaque bascule.

Si vous devez retenir une chose de ce débat, c’est celle-ci : le meilleur outil est celui dont vous comprenez les limites. La CLI vous expose à vos propres erreurs, le MCP vous protège des siennes. À vous de choisir laquelle de ces deux peurs vous préférez gérer.

Quand l’outil devient plus important que la question

En 2010, je me suis formé au SEO avec des outils qui ressemblaient à des boîtes noires : Article Marketing Robot, Scrapebox, The Best Spinner. On achetait, on cliquait, on espérait. Personne ne se demandait ce que ces logiciels faisaient réellement sous le capot.

Quand j’ai commencé à automatiser mes pipelines de refonte d’articles avec Python et l’API DeepSeek, j’ai compris quelque chose d’essentiel. La CLI me force à découper chaque étape, à savoir exactement ce que je transmets et ce que je récupère. Le MCP, lui, promet de fluidifier tout ça. Mais fluidifier, c’est souvent masquer.

Grégory Hénique