IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

101PARTAGES

8  0 
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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 16/03/2026 à 13:50
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.
1  0