partage tentant de résumer les propos et donc mentionnant des personnes de la communauté Dev with IA (https://www.devw.ai/). Pour des raisons de publications, les noms de familles ont été enlevés.
Trois actes, trois interfaces
Les interfaces IA ont évolué vite. Très vite.
2022-2023 : le browser. ChatGPT, Claude, Gemini. L'IA dans un onglet. Puissante en génération, mais coupée de votre environnement de travail. Aucune interaction avec les fichiers, les outils, les systèmes.
2024-2025 : l'IDE + MCP. Les IA entrent dans l'IDE : Copilot, Cursor, Continue.dev. Mais l'IDE est un silo. Pour en sortir, Anthropic lance le Model Context Protocol fin 2024 : un standard ouvert pour connecter les agents aux APIs, bases de données, GitHub, Slack — via une interface typée. OpenAI l'adopte officiellement. En décembre 2025, Anthropic cède MCP à la Linux Foundation. L'écosystème explose.
2025-2026 : les agents CLI. Claude Code, Kilocode, OpenCode, Gemini CLI, GitHub Copilot CLI, Codex CLI. Tous les acteurs majeurs ont maintenant un agent terminal. L'IA ne se contente plus de lire et répondre — elle exécute des commandes, lit et écrit des fichiers, appelle des APIs. Sans couche intermédiaire. Et de manière déterministe.
En plus les outils gh, kubectl, psql, aws que vous avez déjà sont immédiatement utilisables par l'agent.
L'argument n°1
L'argument principal du CLI-first, c'était le coût token : chaque serveur MCP injectait des centaines de tokens dans le contexte avant la première commande utile. Connectez 5 serveurs, et 15-20% de votre fenêtre de contexte est consommée avant d'avoir fait quoi que ce soit.
Sauf que.
Antoine l'a repéré il y a quelques jours : Les dernières mises à jours des outils (claude code) font les MCP non utilisés dans la session courante injectent désormais 0 tokens. Vérifiable avec un /context dans une session quasi vierge. L'argument n°1 du CLI-first vient de tomber.
Le coût contexte reste réel pour les serveurs activement sollicités — mais la pénalité "à blanc" a disparu.
Le choix dépend du modèle
C'était un angle manquant dans les articles comparatifs alors qu'il est pourtant très structurant.
Antoine encore : "Claude Opus/Sonnet 4.6 sont assez forts pour driver une CLI (ex: aws-cli) → le MCP (ex: aws-labs) est superflu. Un Qwen 3.5-30b local sera bien moins agile à driver aws-cli. Le MCP d'aws-labs sera alors bien plus adapté."
Dit autrement : un frontier model — les gros modèles comme Claude Opus, Sonnet 4.6, GPT-4o — sait lire un --help, comprendre les flags, enchaîner les commandes shell sans aide structurée. Le MCP ne lui apporte rien. A l'inverse, un modèle plus petit, typiquement ceux qu'on fait tourner en local (Qwen, Llama, Mistral), a besoin de l'interface structurée du MCP comme guide. Les descriptions typées des outils, les schémas de paramètres — c'est exactement ce qui aide un modèle moins capable à s'y retrouver.
Le choix MCP vs CLI n'est pas une question de préférence mais une question de capacité du modèle qui l'utilise.
L'heuristique du terrain
Joan a une règle simple : "Je préfère CLI pour les actions déterministes. Pour GitLab, j'utilise glab CLI encapsulé dans un CLI maison. Utilisable par les humains ET par l'IA. Pareil pour Slack. Pas encore fait pour Jira où j'utilise MCP."
Déterministe, répétable, bien documenté → CLI.
Exploratoire, mal structuré, API inconnue → MCP.
Et Maxime ajoute un avantage concret : "Un CLI + skill dans ~/.agents/skills/, c'est dispo pour tous tes projets et tous les agents. Pas besoin de configurer le MCP partout." La portabilité cross-projet, un argument qu'on sous-estime.
L'industrialisation : pas si simple
Arnaud a résumé le piège en une phrase : "Je voulais faire un truc comme mcp2cli mais ça me faisait bizarre d'avoir API → MCP → CLI, c'est un peu contre-productif."
Le bon chemin, c'est API → CLI directement. Construire une bonne CLI sur des APIs solides, c'est un investissement qui sert à tout le monde — humains, scripts CI/CD, et agents IA. Passer par MCP pour ensuite re-wrapper en CLI, c'est ajouter une couche d'indirection sans valeur.
Une piste à surveiller si l'outil n'a pas de CLI : CLI-Anything permet de générer automatiquement une CLI depuis le code source d'un logiciel (open source évidemment). L'approche est intéressante et pose la question de l'effort de créer un MCP vs CLI quand vous avez les sources de votre outil.
L'argument enterprise
Thomas travaille avec une équipe sur l'industrialisation des accès MCP remote. Deux arguments forts que la CLI ne couvre pas :
Le maintien à jour centralisé. Distribuer et maintenir des CLIs sur les postes de chaque dev, c'est la galère. Même avec brew ou scoop. L'intérêt d'un MCP serveur remote, c'est un seul point de mise à jour.
L'observabilité des usages. Un enjeu pour les DSI et responsables qui investissent dans l'outillage IA. En CLI sur le poste du dev, c'est capot — ou trop complexe à instrumenter. Avec un MCP serveur remote, l'observabilité devient native.
Ces arguments restent importants pour l'entreprise qui déploie des agents à l'échelle.
Ce débat ne se pose que quand on a le choix
Et c'est peut-être le point le plus important.
MCP vs CLI, c'est un arbitrage qui n'existe que dans un contexte où on a le choix — concrètement, un dev avec un terminal et la maîtrise de son environnement.
Un agent-as-a-service, une plateforme interne, un utilisateur non-tech qui veut juste connecter Slack ou GitHub à son assistant — aucun des ces cas n'utilisera une CLI.
Prenez Cowork (Anthropic) : les connecteurs sont des MCP. Vous avez certes des outils CLI, mais embarqués dans la VM, mais transparents pour l'utilisateur. C'est la skill qui installe les tools nécessaires, rendus invisibles à l'utilisateur.
Cédric : "Même en interne, on a mis de côté des use cases MCP au profit de skills+CLI."
Damien : "Une bonne pratique est d'utiliser des CLI plutôt que les MCP quand tu as l'opportunité. Ça consomme beaucoup moins de tokens et c'est souvent plus efficace."
Mais "quand tu as l'opportunité" est la clé de la phrase. Beaucoup de contextes ne l'offrent pas.
Les deux vont coexister. Et c'est normal.
La vraie question
Le débat MCP vs CLI est secondaire. Ce qui compte, c'est ce qu'il y a en dessous : la qualité du contrat API. Une API bien conçue — stable, documentée, prévisible — se consomme en CLI, en MCP, ou directement par un agent. Une API bancale restera bancale quelle que soit la couche d'abstraction au-dessus.
Pour le reste, la stratégie dépend de plusieurs facteurs concrets : ce qui existe déjà dans votre stack (une bonne CLI disponible ? un MCP communautaire maintenu ?), la capacité du modèle que vous utilisez (frontier ou local ?), le contexte de déploiement (dev solo ou plateforme distribuée ?), et honnêtement — ce sur quoi votre équipe est à l'aise. Un MCP que personne ne sait déboguer, c'est pire qu'une CLI rustique bien maîtrisée.
Construisez de bonnes APIs. L'IA s'en servira — en CLI ou en MCP. Et vous aussi.
Vous aussi vous avez basculé 100% CLI ? Et surtout — est-ce que vous avez vraiment eu le choix ?
Top comments (0)