Supersocks@iamsupersocks
Pourquoi les meilleurs agents IA reviennent au terminal (et pourquoi j'adore ça).
MCP vs Unix.
Ce qui me rend zinzin avec l’IA (et ouvre un champ de possibilités immense), c’est ce renversement d’interface. Jusqu’ici, on adaptait le code pour qu’il soit lisible par l’humain. Certains langages plus que d’autres, et des carrières entières se sont construites là-dessus.
COBOL est un modèle intéressant à analyser dans ce sens. Le langage des années 60, toujours au cœur transactionnel des banques mondiales. Comptes, paiements, crédits, cartes, batchs. Une partie du système financier tourne encore sur du code écrit il y a 30 à 50 ans.
Aujourd'hui une banque c'est littéralement :
mobile app -> microservices -> APIs -> COBOL -> mainframe.
Le legacy n'a pas disparu, il est encapsulé sous des couches modernes.
Pendant 50 ans, la rareté des développeurs COBOL a rendu ces systèmes quasi intouchables. Des profils proches de la retraite étaient rappelés en urgence et payés très cher, car ils étaient parfois les seuls capables de réparer une machine installée 40 ans plus tôt. Non pas par difficulté technique, mais par manque de personnel qualifié sur des infrastructures aussi sensibles.
L'IA moderne descend maintenant dans ces couches les plus anciennes.
Pourquoi ? Parce qu'un LLM est capable de lire du code, comprendre le contexte métier, et souvent coder mieux qu'un humain sur ce type de tâches.
Le COBOL en soi est simple. Le COBOL bancaire, c'est une cathédrale où seuls les initiés savaient circuler : lire d'énormes codebases, comprendre la logique métier, mapper les dépendances, documenter.
Des tâches qui prenaient des mois. L'IA s'attaque directement au cœur logiciel le plus ancien, le plus critique et le plus verrouillé du monde.
Sur cette interface sensible, faut voir ce que ça donne en conditions réelles. Mais j'ai aucun doute que ça va permettre de mieux s'adapter.
On a passé 60 ans à construire des couches d'abstraction, des frameworks, des UI/UX tout ça pour rendre la machine compréhensible par nous.
L'IA redéfinit cette équation. Un LLM n'a pas besoin d'UI/UX. Au contraire, c'est contre-productif : ça bouffe des tokens, ça complexifie sa tâche, ça consomme sa mémoire de travail pour de la décoration. L'IA permet de raviver d'anciens langages et de les exploiter à leur plus haut potentiel, à une vitesse d'exécution qui s'est rarement vue. Bash date de 1989. Les pipes Unix de 1978. Et ce sont peut-être les meilleures interfaces pour les agents IA en 2026.
C'est une évidence : il faut rendre vos SaaS, vos interfaces, facilement lisibles par les machines. Le .md en est un bon exemple ; sur mon site en bio j'ai intégré ça pour le AI Signal et d'autres fonctionnalités, et je vous conseille de faire de même. Pour moi, pour vous et surtout pour nos agents.
De l'autre côté, j'ai voulu pousser l'analyse et comprendre le MCP (Model Context Protocol) en profondeur. Et ce que j'ai trouvé m'a convaincu que le débat est en train de basculer.
Peter Steinberger, créateur d'OpenClaw (190 000 étoiles GitHub, recruté par Sam Altman), a posté six mots en février 2026 :
"MCP were a mistake. Bash is better."
Quand le dev open source le plus prolifique de l'année balance ça, et qu'OpenAI l'embauche dans la foulée pour diriger leur division agents personnels, c'est pas du bruit. C'est un signal.
Dans l'interview Lex Fridman, Steinberger enfonce le clou : "MCP is a crutch. The best thing that came out of MCP is it made companies rethink to open up more APIs." Et : "Every MCP would be better as a CLI. And now this stuff doesn't even have MCP support, and nobody's complaining."
OpenClaw n'utilise pas MCP dans son cœur. 190 000 étoiles. Peu de gens l'ont réclamé. Son système d'extension repose sur des fichiers SKILL.md du markdown que l'agent lit, interprète et exécute. Pas de protocole, pas de SDK. Un fichier texte. Le support MCP existe via plugins, mais le cœur tourne sans. La preuve que l'interface la plus puissante entre un humain et un agent, c'est peut-être un fichier .md.
Pour situer le bonhomme : Steinberger a passé 13 ans à construire PSPDFKit, un framework de rendu PDF tournant sur plus d'un milliard d'appareils. Exit à 100M$. Trois ans de retraite à Madrid. Puis il revient pour jouer avec l'IA. Il enchaîne les projets. Le 44ème, c'est OpenClaw. Un monstre d'éxecution. Il explose en 3 mois. 6 600 commits en janvier 2026. Seul.
Et Steinberger n'est plus seul. Le 11 mars 2026, Denis Yarats, CTO de Perplexity, annonce à Ask 2026 que son équipe abandonne le MCP en interne. Cloudflare démontre que le MCP classique gaspille jusqu'à 81% du budget tokens. Anthropic lui-même reconnaît le problème. NVIDIA mise sur OpenClaw au GTC 2026.
DHH (une voix très écoutée dans la communauté dev) teste OpenClaw sans aucun MCP, sans CLI, sans API -> juste un navigateur. Son agent s'inscrit sur un site, crée un email, remplit des formulaires.
Sa conclusion : "All the agent accommodations, like MCPs/CLIs/APIs, probably still have a place for a bit longer. But I bet this is just a temporary crutch."
Trois approches différentes, même constat : on a empilé trop de couches entre les agents IA et le monde réel.
Le MCP est-il mort ? Non.
Mais son rôle change radicalement. Et ça rejoint exactement mon intuition de départ : on a passé des décennies à adapter les machines aux humains.
Maintenant il faut adapter les interfaces aux machines.
1/ Le contexte des LLM: c'est la RAM de l'IA
La fenêtre de contexte d'un LLM, c'est sa mémoire de travail. Chaque token consommé par de la plomberie protocolaire, c'est un token en moins pour réfléchir. Des benchmarks montrent que la qualité d'attention chute dans la partie finale de la fenêtre. Quand tu as consommé 60-70% avant de commencer, tu forces le modèle à raisonner dans sa zone la moins performante.
Le MCP charge TOUTES les définitions d'outils au démarrage : nom, description, paramètres, types, contraintes. Avant même que tu aies tapé un mot.
Concrètement : chaque outil MCP doit se présenter au modèle avec sa carte d'identité complète : son nom, ce qu'il fait, quels paramètres il accepte, quel format il renvoie. Rien que pour un seul outil "récupérer un document Google Drive", ça fait déjà plusieurs lignes de description technique. Et un serveur MCP en expose des dizaines.
Multiplie ça par 93 pour le serveur GitHub. Par 58 pour un setup modeste. Les schémas JSON sont verbeux par nature -> chaque définition de paramètre, chaque contrainte de type, chaque description consomme des tokens que le modèle doit ingérer et garder en mémoire.
Les chiffres sont brutaux.
→ Le serveur MCP GitHub seul : 93 outils, ~55 000 tokens. Avant ta première question.
→ Un setup entreprise de 5 serveurs / 58 outils : ~55 000 tokens. Ajoute Jira (~17 000 seul) : tu approches 100 000+.
→ Anthropic a mesuré des configs à 134 000 tokens de définitions. La moitié de la fenêtre de Claude, en fumée (bon on a 1M maintenant merci Bobo)
→ L'API Cloudflare : 2 500 endpoints. En MCP classique : 1,17 million de tokens. Plus que la fenêtre des meilleurs modèles.
C'est pas qu'un coût financier, c'est un coût cognitif.
Comme dit Perplexity : des fenêtres plus grandes n'éliminent pas le gaspillage, elles permettent d'être négligent plus longtemps. Les tokens ne sont pas qu'une métrique de coût : c'est directement la capacité de raisonnement disponible pour le vrai problème.
Il y a aussi la duplication des résultats intermédiaires. Ton agent récupère un transcript de 8 000 tokens depuis Google Drive pour l'attacher dans Salesforce. En MCP classique, tout passe par le contexte du modèle -> tu paies un modèle IA coûteux pour du copier-coller.
Un papier arXiv de février 2026 ("MCP Tool Descriptions Are Smelly!") confirme : enrichir les descriptions d'outils MCP améliore le taux de réussite de 5,85 points mais augmente les étapes d'exécution de 67,46% et régresse la performance dans 16,67% des cas. Le gain se paie en efficacité, et les compromis ne sont même pas prévisibles.
2/ L'approche Unix et le "language arbitrage"
Doug McIlroy, inventeur des pipes Unix (1978) : "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
Cinquante ans plus tard, les LLMs font un choix quasi identique : tout est tokens. Tout est texte. Unix communique via des pipes textuels, des petits outils composés via "|", des programmes qui se décrivent avec --help. Les LLMs ont été entraînés sur des milliards de lignes d'interactions terminal. Quand tu demandes à Claude d'utiliser git, docker ou kubectl, tu tapes dans des patterns profondément appris. Le modèle n'a pas besoin d'un schéma pour savoir que git log --oneline -10 affiche les 10 derniers commits. Les serveurs MCP, eux, sont des schémas custom découverts au runtime.
Steinberger a appliqué cette philosophie dans OpenClaw :
→ Des CLIs simples au lieu de serveurs MCP (gh, aws, gcloud + builds custom comme imsg pour iMessage)
→ Doc --help excellente, flags --json, commandes cohérentes, erreurs claires
→ Des fichiers SKILL.md pour guider l'agent même concept que CLAUDE.md dans Claude Code
→ Container Docker. Sécurité par isolation, pas par restriction.
Le mantra de Steinberger est radical : "Don't waste time on RAG, sub-agents, Agents 2.0, or other things that are mostly just for show. Just talk to it directly." Pas de planning mode (un palliatif pour les vieux modèles selon lui). Pas d'orchestrateur ou de sous-agents juste plusieurs fenêtres de terminal.
L'architecture la plus simple qui puisse marcher.
L'approche CLI-first va au-delà du tooling. En vacances au Maroc, quelqu'un envoie à Steinberger un screenshot d'un bug sur Twitter. Trop flemme d'ouvrir son laptop. Il envoie le screenshot à OpenClaw. L'agent lit le screenshot, comprend le bug, vérifie le dépôt Git, corrige le code, soumet un commit, et va sur Twitter répondre : "Hey, it's fixed!" Steinberger a juste bougé ses doigts sur son téléphone. L'agent a fait le reste via des commandes CLI standard.
Cloudflare a identifié la raison profonde. Un appel de fonction (tool call) utilise des tokens spéciaux sans équivalent textuel : des constructions que les LLMs n'ont quasi jamais vues dans leurs données d'entraînement. Entraînés dessus avec des données synthétiques, ils ne sont pas toujours bons. Avec trop d'outils ou des outils complexes, le modèle galère.
À l'inverse, les LLMs écrivent très bien du code. Des milliards de lignes dans les données d'entraînement. Chaque fichier package.json, chaque README avec des exemples d'API, chaque réponse Stack Overflow avec du curl : le modèle sait déjà comment ça marche.
Cloudflare appelle ça un "language arbitrage" : l'agent échange un langage à faible ressource (MCP avec ses tokens spéciaux) contre un langage à haute ressource (TypeScript, bash).
C'est une forme d'arbitrage linguistique : le LLM performe beaucoup mieux dans le langage qu'il maîtrise.
L'analogie de Kenton Varda : demander à un LLM de maîtriser les tool calls, c'est comme demander à Shakespeare d'écrire en mandarin après un cours accéléré. Le résultat serait bon -> c'est Shakespeare -> mais pas son meilleur travail.
Et quelque chose de cool se passe quand tu passes en mode code : le LLM peut aussi écrire des boucles, des conditionnels, du chaînage d'appels, du traitement de données : des choses qui nécessiteraient des dizaines d'allers-retours en tool calling classique.
L'agent tient une logique complexe en une seule exécution au lieu de la fragmenter en appels séquentiels.
Block (projet Goose) confirme : "LLMs are better at writing code to call MCP, than at calling MCP directly."
Ce n'est pas une opinion. C'est un constat empirique.
Les résultats mesurés sur un test réel :
-> MCP : raisonnement qui s'effondre après 3-4 appels. Le contexte accumulé pousse l'agent dans la zone de faible attention. Il faut découper en sessions multiples.
-> CLI : 95% du contexte disponible. Pipeline complète en un shot. Réduction de 35x en tokens.
Un benchmark communautaire confirme : CLI atteint un score de complétion 28% supérieur, Token Efficiency Score 202 vs 152 (+33%). Le CLI complète des tâches que le MCP ne peut structurellement pas gérer comme le profilage mémoire, parce qu'il a accès au filtrage sélectif et aux sorties ciblées plutôt qu'au dump complet de structures de données.
L'exploration progressive est clé. Un CLI bien conçu permet à l'agent de commencer large et de zoomer progressivement. À chaque étape, l'agent reçoit du feedback et décide où creuser.
> L'outil ne force pas un chemin, il répond aux choix.
C'est exactement le mode d'interaction où les modèles sont les plus performants. Daniel Demmel appelle ça "progressively explorable" dans son analyse des feedback loops de Steinberger.
En CLI, c'est une pipeline. En MCP, 3-4 appels séparés avec schémas et résultats intermédiaires. L'agent pense en flux de données — bash le laisse travailler comme ça.
3/ La sécurité : nouvelles surfaces d'attaque
Un papier arXiv de janvier 2026 ("Breaking the Protocol") : première analyse de sécurité rigoureuse du MCP. Trois vulnérabilités fondamentales au niveau du protocole : absence d'attestation de capacité, sampling bidirectionnel sans authentification d'origine, propagation implicite de confiance en multi-serveurs. Sur 847 scénarios, le MCP amplifie les taux de réussite des attaques de 23 à 41% vs des intégrations sans MCP.
Les incidents réels :
→ GitHub : un issue public malveillant détourne un assistant IA pour extraire des données de dépôts privés via le serveur MCP. Cause : PATs trop larges.
→ WhatsApp : exfiltration silencieuse de l'historique complet via "tool poisoning" combiné à un serveur légitime.
→ Email : un faux "Postmark MCP Server" injecte des BCC de toutes les communications vers un serveur attaquant.
→ mcp-remote : CVE-2025-6514, injection de commandes OS dans un proxy OAuth populaire.
→ Smithery : GitGuardian a trouvé un path traversal permettant d'exfiltrer les credentials du builder.
→ Asana : un bug permettait aux données d'une organisation d'être vues par d'autres organisations.
Palo Alto (Unit 42) a identifié trois vecteurs critiques via le sampling MCP :
> vol de ressources,
> détournement de conversation (injection d'instructions persistantes, manipulation des réponses, exfiltration de données),
> invocation cachée d'outils sans connaissance de l'utilisateur.
Le modèle d'auth MCP est un problème structurel.
Chaque serveur gère son propre flux. L'OAuth est souvent absent. Des centaines de serveurs exposés sur 0.0.0.0 ont été documentés.
La spec MCP est figée depuis novembre 2025. Le projet avance (Working Groups, SDKs, roadmap 2026) mais le protocole lui-même n'a pas bougé.
En production, les limites sont concrètes : scalabilité horizontale, gestion de sessions, comportement derrière des load balancers -> des problèmes que les API et les CLI ont réglés il y a des décennies.
Côté CLI, auth par variables d'env, OAuth, AWS credential chains -> problèmes résolus depuis des décennies avec des outils éprouvés (1Password CLI, Vault, AWS Secrets Manager) -> je vous le conseil grandement pour vos setup Openclaw au passage.
L'approche CLI n'est pas sans risques (un shell complet = clés du royaume, problème soulevé par l'agence de cybersécurité chinoise). Mais les mécanismes de sandboxing sont matures.
Les failles MCP sont architecturales, comprendre plus dures à résoudre.
L'écosystème OpenClaw n'est pas non plus un modèle de sécurité. Moltbook, le "réseau social pour agents IA", a été démonté par Wiz : enregistrement massif sans limitation, humains déguisés en agents, aucune vérification. Cisco et Snyk ont trouvé des skills ClawHub avec du prompt injection, du malware, du vol de credentials. OpenClaw a mis en place un scan VirusTotal, un pas, mais le problème de confiance reste entier des deux côtés.
4/ Ce que le MCP fait bien
Steinberger dit que "le meilleur truc sorti du MCP, c'est qu'il a poussé les entreprises à ouvrir leurs API." Exact.
La démocratisation. C'est le point qu'un abonné (Manu, big up à toi) à soulevé dans nos échanges : pour des utilisateurs non-techniques, le MCP est plus simple qu'un stack CLI + Docker. ClawHub : 13 700+ skills communautaires. "Pour démocratiser des outils IA, c'est plus simple à expliquer le MCP", comme dit Manu. "Et ça demande moins d'accès."
La découvrabilité et portabilité. Le MCP fournit une façon uniforme de se connecter à un service et d'apprendre ce qu'il propose. Un agent peut utiliser un serveur MCP même si les développeurs de l'agent n'ont jamais entendu parler de ce serveur, et vice versa. C'est rarement le cas avec les APIs traditionnelles.
Standard ouvert, SDKs pour tous les langages, adopté par Anthropic, OpenAI, Microsoft, Google, Amazon. Un outil construit pour un agent MCP-compatible peut être réutilisé par n'importe quel autre système qui parle le protocole.
Les environnements enterprise. Validation stricte, OAuth, pistes d'audit, gateways zero-trust. Docker MCP Gateway : OAuth scoped, révocation instantanée, rotation automatique, container isolé. C'est du MCP bien fait.
L'isolation de sécurité est un vrai avantage quand c'est bien implémenté. Contrairement à l'approche OpenClaw où l'agent hérite de tes permissions système, le MCP offre une couche de médiation -> l'agent ne touche jamais directement le service.
Et la facilité de dev d'un serveur MCP "donne plein d'idées" : exposer n'importe quel service à un agent en quelques heures avec un SDK, c'est un multiplicateur d'adoption. Manu a raison là-dessus : "quand on voit la simplicité de développement d'un serveur MCP ça donne plein d'idées."
5/ Le Code Mode : la troisième voie
Un post "MCP is dead. Long live the CLI" a atteint le top de Hacker News début 2026.
La thèse : après avoir livré des systèmes réels avec MCP, des devs expérimentés revenaient silencieusement aux API directes et au CLI. Pas parce que le MCP est mal conçu, mais parce que les primitives Unix sont déjà excellentes pour composer des workflows IA.
Le débat "MCP vs CLI" cache pourtant une troisième voie. Au lieu d'un menu massif d'outils individuels, tu donnes au modèle un seul outil : écrire et exécuter du code.
Cloudflare : pour 2 500+ endpoints, 2 outils -> search() et execute(). ~1 000 tokens. Vs 1,17M en MCP classique : réduction de 99,9%.
Cloudflare a fait une démo en direct (MCP Night, décembre 2025). La tâche : créer 31 événements calendrier, un par semaine de janvier, chacun avec un thème IA. L'agent MCP classique a lancé 30+ appels de fonctions un par un un aller-retour par événement.
L'agent en Code Mode a écrit une boucle qui fait tout d'un coup. Les deux ont créé les 31 événements. Mais le Code Mode a consommé 81% de tokens en moins. À l'échelle d'une entreprise qui traite des milliers de tickets par jour sur une douzaine de services, cet écart devient massif.
StackOne a mesuré sur un workflow réel : un workflow MCP génère 55 780 caractères de JSON brut dans une sandbox (~14 000 tokens). Ce qui revient au contexte du LLM : un résumé de 500 tokens. Réduction de 96%.
Les données brutes ne sortent jamais de la sandbox → l'agent voit un résumé propre, le contexte reste léger.
Anthropic dans Claude Code (mars 2026) : → Tool Search : outils découverts dynamiquement (defer_loading: true).
Réduction de 85%. Accuracy : Opus 4 passe de 49% à 74%, Opus 4.5 de 79,5% à 88,1%. Claude Code a documenté une réduction de 46,9% en tokens totaux sur des usages réels avec la commande /context qui montre maintenant ce que consomme chaque outil et propose des optimisations.
→ Programmatic Tool Calling : l'agent écrit du code pour appeler les outils. Claude pour Excel manipule des milliers de lignes sans exploser le contexte.
→ Fenêtre 1M tokens. Plus de marge, mais ne résout pas le fond.
→ MCP Elicitation (v2.1.76, mars 2026) : les serveurs MCP peuvent demander des entrées structurées pendant l'exécution et afficher un formulaire interactif ou ouvrir une URL pour collecter des données sans interrompre le workflow.
→ Block (Goose) : Code Mode comme extension MCP qui enveloppe les autres et expose 3 outils au lieu de 80. MCP reste le protocole, Code Mode est le pattern architectural dessus.
Point crucial : le Code Mode ne remplace pas le MCP. Il l'utilise sous le capot. Adoption incrémentale possible.
Partie 6 : L'architecture hybride et la vision long terme
Le pattern qui émerge en production :
Couche 1 : CLI pour les devs. Le modèle sait déjà utiliser git, docker, kubectl. Zéro token de schéma. Exploration via --help. Composabilité via pipes. C'est l'approche Steinberger et ce que Claude Code fait sous le capot.
Couche 2 : MCP amélioré pour l'intégration. Pour les non-techniques, les marketplaces de skills, la gouvernance enterprise. Mais avec Code Mode : outils à la demande, résultats via sandbox, composition via code. Comme le note Manu : "la limite c'est que plus on multiplie les MCP, plus ça remplit le contexte." Et sa solution intuitive ("n'activer que ceux dont on a besoin à l'instant T") est exactement ce que Tool Search et Code Mode automatisent. Le problème que Manu identifie en tant qu'utilisateur avancé, l'industrie est en train de le résoudre par l'architecture.
Mais Manu ajoute aussi : "parfois on aimerait juste laisser le modèle se débrouiller." C'est exactement la vision DHH et c'est peut-être l'horizon à 2-3 ans.
Couche 3 : API directes pour les systèmes critiques. CRM, facturation, docs privées, latence minimale, contrôle total. Auth, versioning, rate limiting éprouvés depuis des décennies. C'est ce que Perplexity construit avec son Agent API : une plateforme qui route vers les modèles de différents fournisseurs (OpenAI, Anthropic, Google, xAI, NVIDIA), le tout derrière un seul endpoint avec une seule clé API. La complexité absorbée en interne plutôt que déléguée au client.
L'architecture hybride ajoute une couche de politique qui décide ce que l'agent peut toucher, et un store mémoire séparé qui garde les résultats d'outils hors du contexte sauf quand nécessaire. Ce n'est pas élégant. Mais ça survit au contact avec la production.
DHH pousse plus loin : toutes ces accommodations sont peut-être temporaires. Comme les voitures autonomes n'ont pas eu besoin du LIDAR, les agents n'auront peut-être pas besoin de protocoles spéciaux. Les interfaces humaines suffiront. Il a testé sur Opus 4.5 puis sur le modèle chinois open-weight Kimi K2.5 : les deux réussissent. Un papier arXiv de janvier 2026 ("From Everything is a File to Files Are All You Need") formalise cette intuition : quand tout ressemble à du code dans un filesystem, les mêmes bénéfices de composabilité que Unix suivent.
C'est une vision de long terme, aujourd'hui, naviguer via browser est lent et cher en tokens. Mais la trajectoire pointe là.
Conclusion : les primitives survivent aux protocoles
Le MCP passe de "l'interface principale entre les agents et le monde" à "une couche d'intégration standardisée, avec une mécanique repensée (Code Mode, Tool Search, chargement à la demande)."
Pour les devs qui construisent des agents qui doivent faire du vrai travail : le CLI gagne. Les données sont sans appel. Quand tu contrôles l'environnement et que tu veux maximiser le raisonnement de ton agent, tu ne brûles pas la moitié du budget cognitif en schémas JSON.
Pour démocratiser l'accès, le MCP amélioré reste un bon véhicule. Simplicité, portabilité, standard ouvert. ClawHub et ses 13 700 skills, c'est un écosystème.
Pour la production : l'hybride gagne. Chaque couche optimisée pour son cas d'usage.
"Tout ça c'est vrai aujourd'hui mais ça bouge à une telle vitesse que demain ça sera peut être faux", comme dit Manu.
Il a raison. Mais le principe Unix n'a pas bougé depuis 1978. Doug McIlroy avait formulé les règles il y a presque 50 ans : des programmes qui font une chose bien, qui travaillent ensemble, qui communiquent via des flux textuels. Les LLMs, 50 ans plus tard, ont convergé sur exactement le même modèle d'interface.
C'est peut-être la leçon la plus importante de tout ce débat : les primitives qui marchent survivent aux protocoles qui les remplacent. Les outils changent. La philosophie reste.
