MCP est-il mort-né ? Le débat fait rage sur internet depuis que Denis Yarats, CTO de Perplexity, a déclaré que la société abandonnait MCP au profit des API et des CLIGarry Tan, président de Y Combinator, a fait écho à ces propos dans un tweet récent. Désormais, les développeurs prennent parti : MCP est-il surdimensionné ou indispensable pour déployer des agents IA dans les équipes enterprise ?

Les critiques ont du fond ; quelque chose est cassé en ce moment. La surcharge de contexte et les frictions liées à l’authentification sont de vrais problèmes pour les devs, mais la cause profonde se trouve dans l’outillage et l’implémentation. Les détracteurs de MCP diront le contraire, mais beaucoup évaluent ce standard à l’aune de la qualité des serveurs open source disponibles aujourd’hui (des serveurs qui n’ont pas encore rattrapé l’état actuel de MCP).

Regardez de plus près l’adoption du protocole, la qualité des contributeurs et la dynamique de l’écosystème : les données racontent une autre histoire. MCP a déjà gagné.

Le bon problème, mais la mauvaise cible

La frustration des devs est réelle. Des définitions d’outils vagues, des schémas manquants, une gestion des erreurs défaillante. La plupart des serveurs MCP sont de minces wrappers d’API qui déversent des réponses brutes dans la fenêtre de contexte, peu importe ce dont l’agent a réellement besoin… ce sont des symptômes qui mènent à de très mauvaises expériences. Mais ce sont des mises en cause d’implémentations spécifiques.

C’est en partie parce que les critiques les plus virulentes visent des versions de MCP qui n’existent plus. Le protocole a considérablement évolué, et dans un domaine qui avance aussi vite, la spec de l’an dernier est déjà obsolète. La cible a bougé.

Juger MCP sur la base de mauvaises expériences avec des serveurs open source, c’est comme juger l’USB-C par le câble tiers le moins cher d’Amazon. Le protocole fixe le standard, l’écosystème décide de la qualité d’exécution. L’écosystème retarde toujours sur le protocole : c’est la norme pour toute courbe d’adoption de standards.

Oui, MCP est plus lourd que nécessaire par endroits, gère certaines choses bien et d’autres moins élégamment. La qualité des serveurs open source est inégale, et beaucoup de clients MCP rattrapent encore leur retard. Mais ce sont des problèmes d’ingénierie à résoudre. Si l’outillage s’améliore, la surcharge disparaîtra.

Ce que les données montrent vraiment

Anthropic a récemment fait don de MCP à l’Agentic AI Foundation(sous l’égide de la Linux Foundation), un signal délibéré sur ce qu’est MCP et ce qu’il n’est pas. Le protocole a été conçu comme un standard neutre, pas comme un pari propriétaire, et il est ouvert à toute la communauté dev. Des plateformes majeures comme Figma et Linear livrent déjà des serveurs MCP first-party de haute qualité. Ces entreprises facilitent le travail des agents IA avec leurs plateformes : aucune permission spéciale requise, aucun cerceau propriétaire à franchir. Stripe est allé encore plus loin. Le mois dernier, la société a lancé le Machines Payments Protocol, un nouveau standard ouvert qui permet aux agents IA de réaliser des transactions de façon autonome. MCP n’est qu’un des nombreux endpoints avec lesquels le protocole de Stripe peut fonctionner, et la façon dont ces nouveaux standards open source coexistent nous indique où l’industrie se dirige.

Je parle avec des dizaines d’entreprises chaque mois, et les conversations récentes convergent toutes vers le même pari sur MCP. Lors d’un récent événement pour DSI, je n’ai rencontré aucune entreprise qui s’en éloignait. Personne ne débat de la nécessité d’un standard de connectivité. Le débat est passé depuis longtemps au-delà du choix du protocole. Ce que les équipes sécurité et plateforme en entreprise cherchent à résoudre aujourd’hui, c’est l’opérationnalisation : comment imposer le moindre privilège sur des centaines de connexions agent-système, comment maintenir des pistes d’audit qui satisfont les équipes conformité, et tout faire sans reconstruire l’infrastructure d’authentification de zéro pour chaque nouvel outil. La question du protocole est réglée. La question de l’implémentation, elle, est grand ouverte. C’est exactement ce gouffre qui nous a poussés à créer Arcade.dev.

Tout le monde ne voit pas ça comme une opportunité. Les réfractaires à MCP contribuent eux aussi à raconter l’histoire. Des entreprises comme Slack (Salesforce), des plateformes RH comme Workday et LinkedIn, ou des géants des réseaux sociaux comme Meta et Discord rendent plus difficile (parfois délibérément !) le travail des agents IA avec leurs plateformes. J’ai récemment parlé avec Laura Bratton de The Information de pourquoi ces entreprises résistent aux agents IA de leurs clients. Elles invoquent la sécurité et la vie privée, mais l’éléphant dans la pièce, c’est que des agents ouverts pourraient nuire à la capacité des éditeurs SaaS à garder leurs utilisateurs captifs et à les faire payer pour leurs fonctionnalités propriétaires.

Mais la résistance des acteurs en place n’est pas la preuve d’une faiblesse du protocole. C’est la preuve de sa puissance. Difficile d’imaginer que les chouchous du SaaS réagiraient ainsi à un protocole en train de perdre. Les standards ne gagnent pas grâce à une perfection technique immédiate. TCP/IP n’était pas parfait, HTTP non plus. Ils ont gagné parce qu’ils ont franchi le seuil où les coûts de migration dépassaient les bénéfices de toute alternative. C’est exactement ainsi que MCP creuse l’écart. D’autres standards, comme l’A2A de Google en compétition directe, ont eu du mal à gagner du terrain alors que la spec de MCP s’est étendue pour couvrir une grande partie du même terrain. À ce jour, aucun challenger crédible n’a émergé avec un usage réel, des contributeurs de poids et une dynamique d’écosystème comparable à MCP.

Le protocole n’est pas l’implémentation

Le débat sur la pertinence de MCP comme standard passe à côté de l’essentiel. La friction qui alimente la conversation vient du fait que la plupart des implémentations MCP ne sont tout simplement pas très bonnes (encore).

Le nouveau benchmark MCP d’Arcade.dev, ToolBench, le montre clairement. Il évalue les serveurs MCP sur la définition, la conformité au protocole et le support en conditions réelles, et les écarts que ToolBench met en évidence sont énormes. Beaucoup de serveurs open source ne tournent pas sur l’état actuel du protocole. Ajoutez à ce retard le faible support MCP open source des outils enterprise populaires, et vous comprenez pourquoi les critiques de MCP se font plus nombreuses. Leur vrai grief, pourtant, vise les builders qui n’ont pas encore bien implémenté MCP.

Une confusion similaire surgit dans la façon dont on parle des standards concurrents. Agent Skills et MCP résolvent des problèmes différents et fonctionnent mieux ensemble que séparément. MCP, c’est comment un agent se connecte à Gmail ; les skills sont la couche de connaissance qui indique à l’agent comment rédiger l’e-mail une fois qu’il y est. Ils sont orthogonaux et se combinent bien, c’est pourquoi les confondre mène exactement aux mauvaises décisions architecturales qui font sous-performer les implémentations MCP médiocres.

Fixer le niveau

De nouveaux standards continueront d’émerger, mais ils résoudront des problèmes différents. Même les retours vers le CLI, défendus par Perplexity et Garry Tan, ont leur logique. Les développeurs veulent taper une commande, mais cette commande doit au final atteindre Salesforce, GitHub ou un système de santé, où quelque chose doit gérer l’authentification, les permissions de scope et journaliser l’action.

D’ailleurs, notre Responsable Ingénierie, Evan Tahler, s’est lassé exactement de ce type de problème et a créé MCPX, curl pour MCP. Avec MCPX, le développeur tape une commande et l’infrastructure s’occupe du reste. Des outils comme celui-ci prouvent que les agents long-running, capables d’appeler des outils et d’agir sur des systèmes métier, tournent aujourd’hui sur MCP. Aucun autre standard ne peut faire ça pour l’instant.

Si vous voulez voir à quoi ressemble un MCP production-ready en pratique, c’est pour ça que nous avons créé Arcade.dev. Venez construire dessus.