Trois façons pour un agent d'accéder au monde extérieur — et un débat mal posé presque partout. Une grille de lecture honnête, exemples à l'appui.
On oppose souvent MCP et CLI comme s'ils étaient deux options interchangeables. Ce sont en fait quatre niveaux d'abstraction au-dessus du même substrat : HTTP.
curl ou écrit un script Python avec httpx. Le LLM lit la doc OpenAPI et tape l'endpoint directement.gh, glab, kubectl, aws. Pagination résolue, auth cachée, endpoints composites, output ergonomique. C'est là que la vraie valeur s'ajoute.Ces quatre niveaux tapent le même backend HTTP. La question n'est pas « lequel est le bon », mais « où la complexité est déjà absorbée ? ».
Tâche concrète : lister les issues GitHub ouvertes assignées à l'utilisateur. Voilà ce que ça donne, du plus brut au plus structuré.
Le verdict est net : la CLI hand-crafted l'emporte largement sur ce geste, parce que gh a déjà absorbé l'auth, la pagination et le formatage. Au passage, c'est aussi ce que le LLM connaît le mieux — il a vu gh des millions de fois dans son entraînement.
Plusieurs benchmarks publiés début 2026 ont quantifié l'écart de manière brutale :
L'explication est mécanique : chaque tool MCP charge son schéma JSON dans le contexte du modèle, plus sa description, plus celle de ses arguments. Avec une dizaine de tools, on a déjà mangé plusieurs milliers de tokens avant même d'avoir commencé à travailler. Et chaque schéma supplémentaire élargit la surface de décision : le modèle hésite entre plus d'options, donc raisonne moins bien.
À l'inverse, une CLI mobilise des patterns que le modèle a vus des millions de fois pendant son entraînement (Stack Overflow, GitHub, docs). Le coût cognitif est quasi nul.
L'erreur du débat actuel, c'est de comparer MCP et CLI sur le terrain où CLI est de toute façon supérieure : dev local, mono-utilisateur, shell disponible. Mais MCP n'est pas un format alternatif à CLI — c'est un protocole pour des situations où CLI ne peut pas aller. Quatre cas structurels :
fork/exec local. Il faut un shell, un binaire installé, le bon OS. Dès que l'agent tourne dans un sandbox web, une app mobile, ou un service SaaS distant — la CLI n'existe plus.
Exemple : Claude Desktop, Cursor, Zed, Continue peuvent tous consommer le même serveur MCP sans installation locale. Avec CLI, chaque utilisateur de chaque éditeur doit installer chaque outil.
gh auth login résout l'auth du user de la machine. Pour un produit qui fait agir un agent on-behalf-of N utilisateurs distincts, chacun avec ses permissions, la CLI ne tient plus la route.
Exemple : un SaaS qui automatise des workflows GitHub pour 5000 clients. MCP standardise OAuth 2.1 + Dynamic Client Registration depuis 2025. Avec CLI, il faudrait provisionner 5000 contextes d'auth — non scalable.
cat, mais tu perds la sémantique « ceci est du contexte de référence, pas un résultat d'action ».
À noter : aucun de ces quatre points ne se règle en « standardisant » la CLI. C'est le modèle d'exécution qui diverge. Le seul moyen de faire une CLI remote, multi-tenant, bi-directionnelle, avec des Resources… c'est de réinventer MCP.
Une seule question tranche presque tout, formulée par Scalekit dans leur benchmark :
Le point d'inflexion, c'est quand l'agent arrête d'agir pour son utilisateur et commence à agir au nom d'autres personnes.
Automatiser son propre workflow → CLI. Un produit qui automatise des workflows pour des clients distincts, dans leurs organisations, avec leurs droits → MCP. Le surcoût en tokens est le prix d'admission de la gouvernance.
Le piège dans l'autre sens existe aussi : coller du MCP partout « parce que c'est le standard », y compris sur du dev local mono-utilisateur, c'est payer le surcoût sans bénéficier de la gouvernance. C'est ce qui produit la fatigue MCP qu'on lit en ce moment.
Les équipes les plus matures en 2026 ne choisissent plus un camp. Elles utilisent :
git, kubectl, jq, curl, ffmpeg…).Le fait que Google ait shippé en parallèle gws CLI et des serveurs MCP Workspace est le signal le plus clair : ce n'est pas une bataille, ce sont deux outils complémentaires pour deux périmètres différents.
CLI quand l'agent agit pour son utilisateur, MCP quand il agit pour quelqu'un d'autre, API directe quand il n'y a ni l'un ni l'autre — et un agent moderne sait jongler entre les trois.