MCP en crise de croissance : Perplexity lâche le protocole

Le 11 mars 2026, Denis Yarats, CTO de Perplexity, annonce à la conférence Ask 2026 que son entreprise se détourne du Model Context Protocol. Quelques jours plus tôt, Garry Tan, CEO de Y Combinator, révélait avoir construit une intégration CLI maison plutôt que d’utiliser MCP. Quand deux acteurs majeurs de l’écosystème IA rejettent publiquement le protocole le plus adopté du marché, la question mérite d’être posée : MCP a-t-il atteint ses limites ?

Les reproches concrets : contexte gaspillé et surcoût en tokens

Les critiques ne sont pas théoriques. Elles s’appuient sur des mesures précises.

Le problème du contexte. Chaque outil exposé via MCP nécessite entre 550 et 1 400 tokens rien que pour sa définition. Multipliez par le nombre d’outils connectés et le budget tokens explose avant même que l’agent traite votre requête. Apideck a documenté un cas concret : trois serveurs MCP consomment 143 000 tokens sur un contexte de 200 000 — soit 72 % du contexte gaspillé avant la moindre interaction utile.

Le surcoût Cloudflare. Cloudflare a poussé l’analyse plus loin en comparant deux approches pour exposer ses 2 500 endpoints API. Via MCP classique : 1,17 million de tokens. Via leur approche Code Mode (deux outils génériques + génération de code) : environ 1 000 tokens. Le ratio est de 244 pour 1. Ce n’est pas une optimisation marginale, c’est un ordre de grandeur qui remet en question l’architecture même du protocole pour les déploiements à grande échelle.

L’authentification chaotique. Chaque serveur MCP gère son propre flux d’authentification. Pour une PME qui connecte cinq ou six outils métier, cela signifie autant de configurations différentes, sans SSO centralisé ni gestion unifiée des accès. En production, c’est un frein réel à l’adoption.

Si vous découvrez MCP, notre guide d’introduction au protocole en explique les fondamentaux et les cas d’usage.

La réponse de l’écosystème : une roadmap qui cible chaque critique

La roadmap 2026 de MCP, publiée le 9 mars — deux jours avant l’annonce de Perplexity — répond point par point aux reproches.

Transport HTTP scalable. Le Streamable HTTP actuel pose problème derrière les load balancers et ne supporte pas bien le scaling horizontal. La prochaine spécification prévoit une gestion des sessions sans état, compatible avec les architectures distribuées. Les spécifications techniques (SEPs) sont en cours de finalisation pour une release prévue en juin 2026.

Server Cards. Un standard pour exposer les métadonnées d’un serveur via une URL .well-known. Les registres et navigateurs pourront découvrir les capacités d’un serveur sans s’y connecter. Cela réduit directement le volume de tokens chargés en contexte.

SSO enterprise. L’authentification évoluera vers des flux intégrés SSO (Cross-App Access), abandonnant les secrets clients statiques. Les équipes IT pourront gérer les accès MCP comme elles gèrent déjà le reste de leur infrastructure.

Audit trails. Visibilité de bout en bout sur les requêtes et actions, dans un format compatible avec les pipelines de conformité existants. Un point directement lié aux exigences de sécurité des intégrations MCP que nous avons détaillées récemment.

Ce que cela signifie pour votre PME

Ces débats entre géants de la tech peuvent sembler éloignés de votre quotidien. Ils ne le sont pas. Si vous utilisez des outils compatibles MCP ou si vous envisagez d’intégrer des agents IA dans vos processus, voici ce qu’il faut retenir.

MCP reste le standard dominant. 97 millions de téléchargements mensuels, 10 000 serveurs actifs, gouvernance Linux Foundation avec Anthropic, OpenAI, Google, Microsoft et AWS. Aucun concurrent ne propose une adoption comparable. Perplexity elle-même maintient un serveur MCP pour la rétrocompatibilité.

Les critiques portent sur l’échelle, pas sur le principe. Le problème du gaspillage de contexte apparaît quand vous connectez des dizaines d’outils simultanément. Pour une PME qui connecte un CRM, un ERP et un outil de communication, l’overhead reste gérable. C’est en production à grande échelle — des centaines d’endpoints API — que MCP montre ses limites actuelles.

Le consensus émerge. L’industrie converge vers une approche hybride : MCP pour les intégrations desktop et IDE où la richesse du contexte compte, APIs directes et CLI pour les agents de production où l’économie de tokens est prioritaire. Vos choix d’architecture doivent refléter cette réalité.

Comment architecturer vos intégrations en 2026

Quatre principes pour tirer parti de MCP sans subir ses limites actuelles.

Limitez le nombre de serveurs MCP actifs. Ne connectez que les outils dont votre agent a réellement besoin dans un contexte donné. Trois serveurs bien configurés valent mieux que dix chargés en permanence.

Privilégiez les outils compatibles OAuth 2.1. La spécification de juin 2025 classe les serveurs MCP comme des Resource Servers OAuth. Exigez cette conformité de vos fournisseurs — c’est le mécanisme d’authentification qui deviendra standard.

Surveillez la release de juin 2026. Les Server Cards et le transport HTTP scalable changeront la donne pour les déploiements multi-serveurs. Planifiez une phase de mise à jour de vos intégrations après cette release.

Documentez vos choix. MCP ou API directe, chaque intégration doit être tracée et justifiée. C’est une bonne pratique technique et une exigence croissante sur le plan réglementaire.

Un protocole en pleine adolescence

MCP traverse exactement le type de crise que traversent les standards qui réussissent. USB a connu USB 1.1, puis 2.0, puis des années de confusion entre connecteurs avant qu’USB-C ne s’impose. HTTP a évolué de 1.0 à 2 puis 3 pour répondre aux exigences de performance.

Les critiques de Perplexity, Cloudflare et Y Combinator accélèrent l’évolution du protocole — elles ne signent pas son arrêt de mort. Pour votre PME, la bonne stratégie est de continuer à investir dans MCP tout en dimensionnant vos intégrations avec pragmatisme. Les fondations sont solides. La prochaine version sera meilleure.