Discussion :

[Stéphane le calme]

Le MCP (Model Context Protocol) d'Anthropic lâché par Perplexity et critiqué par Cloudflare :
Cloudflare prouve que l'appel d'outils MCP classique gaspille jusqu'à 81 % de la fenêtre de contexte des agents IA

En l'espace de quelques jours, deux acteurs majeurs de l'écosystème IA ont ébranlé la confiance dans le Model Context Protocol (MCP) : Denis Yarats, directeur technique de Perplexity, a annoncé publiquement que son entreprise abandonnait le protocole en interne au profit des API REST classiques ; pendant ce temps, Cloudflare publiait une analyse technique cinglante démontrant pourquoi l'architecture MCP traditionnelle est fondamentalement inadaptée aux agents IA à grande échelle. Ces deux coups portés simultanément relancent un débat crucial : le MCP, présenté comme l'USB-C de l'intelligence artificielle, était-il une promesse prématurée ?

Lancé fin 2024 par Anthropic, le Model Context Protocol était censé résoudre un problème structurel : comment permettre à un agent IA de se connecter de façon standardisée à des outils externes (bases de données, API tierces, systèmes de fichiers) sans que chaque intégration nécessite un développement sur mesure ? L'analogie avec l'USB-C était séduisante : un seul protocole pour tout brancher.

L'adoption fut rapide. Claude, Cursor, VS Code, Windsurf et des dizaines d'autres applications IA ajoutèrent le support MCP. Perplexity elle-même livra un serveur MCP en novembre 2025, avec des outils de recherche, de raisonnement et d'analyse approfondie. La communauté des développeurs construisit des milliers de serveurs MCP. Sur le papier, l'écosystème semblait s'installer durablement.

Mais les équipes qui déployaient ces agents en conditions réelles commençaient à heurter des murs. Des murs en tokens.

Le coup de théâtre de la conférence Ask 2026

Le 11 mars 2026, lors de la conférence Ask 2026, Denis Yarats, cofondateur et directeur technique de Perplexity, annonçait publiquement que l'entreprise abandonnait le MCP d'Anthropic en interne, lui préférant des API et des interfaces en ligne de commande (CLI) classiques. Deux raisons techniques majeures justifiaient ce revirement : la consommation excessive de la fenêtre de contexte et les frictions liées à l'authentification.

L'ironie de la situation n'échappa à personne dans la communauté. Perplexity dispose toujours d'un serveur MCP officiel sur son site de documentation, avec installation en un clic pour Cursor, VS Code et Claude Desktop. Le jour même de sa propre conférence développeur, son directeur technique déclarait s'éloigner du MCP en interne.

Les objections de Yarats sont pratiques, non philosophiques. Les définitions d'outils MCP consomment des tokens de fenêtre de contexte : chaque description d'outil, chaque schéma de paramètres, chaque format de réponse grignote la mémoire de travail du modèle. Pour des agents effectuant de nombreux appels d'outils au fil de longues conversations, cette surcharge s'accumule. Le modèle d'authentification, qui exige que chaque serveur MCP gère son propre flux d'authentification, crée des frictions lors de la connexion à plusieurs services.

La position de Yarats est pragmatique, non idéologique. Perplexity maintient son serveur MCP pour les développeurs qui le souhaitent. Mais son produit phare pour les développeurs d'agents est désormais une API traditionnelle qui absorbe la complexité en interne plutôt que de la déléguer au client.

La portée symbolique de l'annonce fut immédiatement relevée par les observateurs de l'écosystème. Le MCP n'a pas été mis à jour depuis novembre 2025, le modèle de sécurité est pratiquement inexistant, et le transport stdio se brise dans tout environnement de production réel. Les API et les CLI ont gagné cette manche parce qu'elles avaient déjà résolu les problèmes que le MCP tente encore de définir : authentification, gestion des versions, limitation du débit, supervision... des mécanismes éprouvés depuis des décennies.

Cloudflare dissèque le problème : trop de tokens pour trop peu de travail

Quelques jours auparavant, Cloudflare avait publié une analyse technique qui constitue le second pan de cette crise de confiance envers le MCP. L'entreprise, qui exploite des milliers de serveurs MCP pour ses propres produits, avait identifié le même problème fondamental, et proposait une solution originale qu'elle nomme le « Code Mode ».

Le problème central est brutal à exprimer en chiffres. La spécification OpenAPI de Cloudflare représente 2 millions de tokens. Même avec des outils MCP natifs utilisant des schémas allégés, on arrive encore à environ 244 000 tokens. Les serveurs MCP traditionnels qui exposent chaque point de terminaison comme un outil distinct injectent la totalité de ce contexte dans l'agent principal. C'est plus que la fenêtre de contexte complète de la plupart des modèles de fondation disponibles aujourd'hui.

Le diagnostic de Cloudflare est limpide : les LLM sont entraînés sur des quantités massives de code réel, mais les formats d'appel d'outils sont des constructions synthétiques qui n'apparaissent presque jamais dans les données d'entraînement. Le modèle est à l'aise en JavaScript mais bégaie en JSON de function-calling. D'où la conclusion provocatrice de l'équipe : les LLM sont meilleurs pour écrire du code qui appelle le MCP que pour appeler le MCP directement.

Le Code Mode : faire écrire du code à l'agent plutôt que d'appeler des outils

La solution proposée par Cloudflare renverse la logique traditionnelle. Le Code Mode consiste à ne pas décrire chaque opération comme un outil distinct, mais à laisser le modèle écrire du code contre un SDK typé, puis à exécuter ce code en toute sécurité dans un environnement isolé appelé Dynamic Worker Loader. Le code agit comme un plan compact : le modèle peut explorer les opérations d'outils, composer plusieurs appels et ne retourner que les données dont il a besoin.

Le serveur MCP de l'API Cloudflare donne accès à l'intégralité de l'API Cloudflare — plus de 2 500 points de terminaison couvrant DNS, Workers, R2, Zero Trust et tous les autres produits — via seulement deux outils : search() et execute(). Cette approche consomme environ 1 000 tokens, quelle que soit la taille de l'API exposée. Soit une réduction de plusieurs ordres de magnitude par rapport à l'approche conventionnelle.

Les gains de performance mesurés sont éloquents. Pour une tâche simple (créer un seul événement de calendrier), le Code Mode consomme 32 % de tokens en moins que l'appel direct d'outils. Pour une tâche complexe — créer un événement pour chacune des 31 semaines de janvier 2026 — le Code Mode consomme 81 % de tokens en moins. Pour des déploiements d'entreprise où des agents résument des milliers de tickets clients tout en appelant Salesforce, Slack et une dizaine d'autres services, cet écart d'efficacité se compose rapidement.

L'architecture du Code Mode est elle aussi notable du point de vue de la sécurité. Le code s'exécute dans des bacs à sable de Workers isolés : chaque exécution obtient sa propre instance Worker. L'accès réseau externe (fetch, connect) est bloqué par défaut au niveau du moteur d'exécution. Une garantie non négligeable quand on sait que l'un des reproches récurrents au MCP concerne précisément l'absence de modèle de sécurité cohérent.

Une convergence indépendante : Anthropic et Cloudflare arrivent à la même conclusion

Ce qui rend cette situation particulièrement intéressante, c'est la convergence parallèle d'Anthropic et de Cloudflare vers le même diagnostic, sans coordination apparente. Cloudflare publiait ses conclusions le 26 septembre 2025 ; Anthropic le 4 novembre 2025. Les deux billets se citent mutuellement, mais il s'agissait clairement de découvertes parallèles, sous la pression des mêmes contraintes : les agents passent à l'échelle, le nombre d'outils explose, et l'ancienne approche se brise à ce niveau.

Le principe du Code Mode peut se résumer ainsi : au lieu d'exposer les outils directement au modèle, une application cliente MCP génère une interface programmatique vers ces mêmes outils (généralement en JavaScript ou TypeScript), fournit un ensemble limité d'outils au modèle (recherche dans les modules disponibles, lecture du code source d'un outil, exécution de code), puis exécute le code généré dans un environnement isolé pour la sécurité. Le modèle peut ainsi découvrir progressivement les outils pertinents, sans que toutes les définitions de serveurs et d'outils occupent la fenêtre de contexte dès le départ.

Ce que cela révèle sur l'état du MCP

La crise actuelle du MCP n'est pas une mort annoncée, mais un signal de maturité. Le protocole a rempli son rôle de démonstration de faisabilité et d'accélérateur d'adoption, mais ses limites structurelles (consommation de contexte, modèle d'authentification hétérogène, transport stdio peu fiable en production) sont désormais documentées par les acteurs qui l'ont le plus sérieusement déployé.

La question de fond est de savoir si la dynamique d'adoption du MCP survit au fur et à mesure que davantage d'entreprises construisent des alternatives API plus faciles à intégrer. Le protocole bénéficie du soutien institutionnel d'Anthropic et d'une large adoption dans les environnements de développement, mais l'outillage pour développeurs tend à converger vers ce qui se déploie le plus vite avec le moins de maux de tête d'intégration. En ce moment, c'est un point de terminaison REST avec un bearer token.

Pour que le Code Mode avec MCP s'impose plus largement, plusieurs conditions sont nécessaires : des environnements d'exécution isolés standardisés, des outils de débogage adaptés au code généré par les LLM, et des offres de sandboxing en tant que service. Autant de chantiers ouverts qui montrent que la maturité de l'écosystème agentique reste encore à construire.

Le parallèle avec d'autres moments charnières de l'histoire de l'infrastructure informatique s'impose : le passage des scripts CGI à FastCGI et WSGI à mesure que le trafic web croissait est une analogie pertinente. Ce n'est pas la fin du MCP, c'est son adolescence.

Sources : Cloudflare, GitHub, Aakash Gupta

Et vous ?

Le MCP peut-il survivre comme standard universel si les entreprises en production lui préfèrent systématiquement des API REST éprouvées ? Ou est-il condamné à rester un outil de prototypage pour développeurs individuels ?

L'approche Code Mode de Cloudflare règle-t-elle réellement le problème de fond, ou déplace-t-elle simplement la complexité du côté de l'exécution de code généré par un LLM avec les risques de sécurité que cela implique ?

La décision de Perplexity, entreprise qui a elle-même construit et promu un serveur MCP officiel, signe-t-elle la fin de la phase d'euphorie autour du MCP, ou n'est-ce qu'un retour à la raison pour les déploiements d'entreprise ?

Si les LLM sont fondamentalement meilleurs pour écrire du code que pour appeler des outils en JSON, cela remet-il en cause l'ensemble du paradigme du function calling sur lequel repose GPT-4, Claude et consorts ?

[Matthieu Vergne]

L'argument du coût de token est friable : le coût est peu eprtinent quand on utilise un modèle local, et l'énormité du contexte consommé peut s'adresser en découpant les fichiers pour ne charge que ce qui est pertinent. C'est ce que fait Claude Code avec ses skills, qui peuvent référencer d'autres fichiers, et c'est ce que font depuis longtemps déjà les chatbots de role play, comme ceux qu'on peut faire tourner sur Silly Tavern, vie un lorebook (un ensemble d'entrées qui ne chargent que celles ayant des mots clés pertinents, pour rester simple).

L'argument sécurité me parle plus, vu que moi-même je n'accepte déjà de n'utiliser que des MCP isolés via Docker. C'est pas forcément idéal, ni clairement suffisant, mais c'est toujours ça.

Pour des cas simples, MCP facilite quand même bien les choses. À voir comment les pratiques évoluent.