Le MCP ignore les précieuses leçons tirées de 40 ans de systèmes distribués

• MCP (Model Context Protocol) se présente comme un standard de normalisation de l’intégration d’outils IA, mais présente un problème en ignorant les meilleures pratiques RPC et systèmes distribués accumulées en 40 ans
• De ce fait, dans les environnements d’entreprise, des fonctions essentielles comme la fiabilité opérationnelle, la sûreté de type, la sécurité, l’observabilité et la gestion des coûts sont absentes
• MCP ne propose pas ces fonctionnalités clés en propre et dépend de bibliothèques externes, ce qui engendre une fragmentation du protocole, une complexité d’intégration accrue ainsi qu’une surcharge liée à l’audit et à la sécurité
• Des besoins opérationnels clés comme le traçage distribué, la gestion de version de schéma, la découverte de services, l’optimisation des performances restent encore insuffisants
• Une adoption précoce de MCP, portée par la vague IA, peut conduire à des incidents graves en entreprise, à des risques opérationnels, à de la redondance de développement et à des coûts inutiles

---

Les risques d’une trop grande simplicité du MCP

MCP (Model Context Protocol) se présente comme l’« USB-C des outils IA » en mettant en avant une simplicité qui réduit la barrière d’entrée. Mais cette simplicité revient à ignorer les leçons accumulées en quarante ans de systèmes distribués, ce qui provoque des lacunes fonctionnelles critiques en production. Les entreprises qui déploient MCP aujourd’hui construisent en fait leurs systèmes sur une base dépourvue de fonctions RPC essentielles.

Un écart dangereux entre la réalité et les attentes

Les défenseurs du MCP le présentent comme une infrastructure prête pour la production, mais sa philosophie de conception favorise la commodité de développement au détriment de la robustesse opérationnelle. On peut connecter des outils IA en quelques semaines, mais dès que la charge monte à des centaines de milliers de requêtes dans le monde réel, des fragilités majeures apparaissent. Sous la pression de l’excès d’attentes liées à l’IA, l’adoption progresse sans maturité architecturale suffisante, ce qui augmente fortement le risque d’échec opérationnel.

Des erreurs qui se répètent sur quarante ans

• UNIX RPC (1982) a introduit XDR (External Data Representation) et IDL (Interface Definition Language) pour garantir la compatibilité de données entre systèmes hétérogènes, comme les entiers 32 bits, en détectant les incohérences de types à la compilation MCP ignore cette expérience et n’offre qu’un JSON sans schéma avec des indices non contraignants. Des erreurs de type apparaissent à l’exécution, l’IA peut produire une mauvaise date, ce qui peut entraîner des erreurs de conversion de données et de qualité potentiellement critiques en finance, santé, fabrication ou autres usages opérationnels

• CORBA (1991) utilisait OMG IDL pour garantir une interface cohérente entre langages. Avec MCP, chaque langage est implémenté séparément, sans cohérence de sérialisation, de gestion des erreurs, etc., entre langages et bibliothèques, ce qui provoque un cauchemar d’intégration

• REST (2000) a assuré une extensibilité massive et une fiabilité grâce à une architecture sans état, une sémantique claire fondée sur les verbes et des en-têtes de cache MCP maintient une distinction floue entre stateful et stateless, et ne supporte ni cache, ni sémantique standard des requêtes, ni idempotence. La mise à l’échelle des serveurs, la stratégie de retry et l’équilibrage de charge deviennent ainsi extrêmement difficiles

• SOAP/WSDL disposait d’un contrat lisible par machine robuste, d’une forte capacité d’automatisation et d’une extensibilité de sécurité MCP ne fournit qu’un simple schéma JSON et lui manque contrats lisibles par machine, génération automatique, sûreté de type, audit de sécurité. OAuth 2.1 n’y est ajouté que tardivement et uniquement pour le transport HTTP, tandis que stdio dépend des variables d’environnement, ce qui rend la gouvernance de la sécurité incomplète

• gRPC (2016) intègre nativement observabilité, traçage distribué, streaming bidirectionnel, deadlines et codes d’erreur structurés MCP ne supporte que le streaming unidirectionnel de type événementiel, ce qui est inefficace pour des interactions complexes. Les éléments essentiels comme le contexte de traçage, les deadlines et la classification des erreurs y sont absents

Le risque de « utilisez uniquement cette bibliothèque »

À chaque défaut critique relevé dans MCP, la réponse consiste souvent à ajouter une bibliothèque tierce (par ex. mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator). Pourtant, cela illustre l’échec fondamental du protocole. Plus les fonctions clés sont externalisées, plus s’aggravent la fragmentation, l’incohérence, la dilution des responsabilités de maintenance, de sécurité et d’intégration. Dans un cadre entreprise, la standardisation, les audits et les intégrations prennent en charge des mois, tandis que la formation des développeurs et la dépendance externe montent de manière anormale.

Des correctifs provisoires empilés sans cesse

La version MCP du 26/03/2025 ressemble à des notes de correctifs ajoutées après coup pour des défauts découverts en production. OAuth, gestion de session, attributs d’outils (annotation), notifications de progression ne sont que des ajouts tardifs de fonctionnalités qui auraient dû être présentes dès l’origine. La distinction des attributs d’outils était absente au départ, et l’authentification de sécurité était également considérée comme non prioritaire à ce stade. Cela témoigne d’un manque fondamental de compréhension des exigences entreprises.

Un cauchemar de débogage et une traçabilité opératoire quasi impossible

en environnement gRPC, le traçage distribué avec un trace ID permet un débogage rapide et cohérent À l’inverse, MCP n’a pas d’ID de corrélation entre requêtes, des formats de logs incohérents et des besoins d’implémentations spécifiques entraînent un débogage et une traçabilité d’erreurs qui peuvent prendre plusieurs jours. Du point de vue opérationnel et business, la répartition des coûts et la gestion d’usage (en-têtes, comptage de tokens, quotas, etc.) sont impossibles. Dans un environnement cloud, les fonctionnalités de base sont simplement absentes de MCP, rendant le suivi des coûts IA et des responsabilités quasiment impossible.

Principaux problèmes opérationnels qui persistent

• Absence de découverte de services : empêche la disponibilité, l’extension multi-régions et les mises à jour sans interruption
• Absence de gestion de version des schémas par outil : risque permanent que la mise à jour d’un outil casse toute la base de clients sans avertissement
• Limites de performance : surcharge JSON, absence de pool de connexions, manque de protocoles binaires, de compression et communication au niveau des processus, reproduisant des schémas dépassés

Risques graves lors d’une adoption en entreprise

À mesure que l’IA entre dans des zones où les entreprises portent la responsabilité du chiffre d’affaires, de la sécurité et de la qualité (finance, santé, fabrication, support client, etc.), les risques liés à MCP s’amplifient. Abandonner des décennies de patterns d’intégration robustes au profit d’une solution MCP revient à tenter de combler ensuite, de manière ad hoc, la sécurité, l’audit, la sûreté de type et la stabilité opérationnelle. La stratégie du « fast and break » acceptable pour des prototypes pilotes devient catastrophique pour des services critiques.

Pistes d’amélioration et exigences à long terme

• Court terme : type safety intégrée au protocole, traçage distribué (ID de corrélation), autorisation, format d’audit standardisé, gestion de version indépendante des schémas par outil
• Opérationnel : découverte de services, pool de connexions, transport binaire, deadlines, politiques standardisées d’erreur et de retry
• Long terme : streaming bidirectionnel, gestion de quotas et de coûts intégrée, SLA enforcement, orchestration de workflows, et autres fonctions de niveau entreprise

Conclusion

L’orientation vers la simplicité de MCP peut convenir à des intégrations d’outils IA expérimentales et à court terme, mais elle se traduit dans les environnements de production d’entreprise par des risques opérationnels et des coûts d’exploitation critiques. Pousser l’adoption en surfant sur la ruée de l’IA conduit à des comportements répétitifs où la sécurité, l’observabilité et la stabilité opérationnelle sont ajoutées a posteriori sous forme de correctifs. In fine, la fragmentation et la duplication de développement que le protocole prétendait prévenir risquent d’être reproduites précisément sur MCP. L’industrie IA se trouve face à un choix : revivre des problèmes déjà résolus en ignorant quarante ans d’évolution des systèmes distribués, ou apprendre de cette histoire. Si cela continue ainsi, les déploiements échoués, vulnérabilités de sécurité et cauchemars opérationnels se répéteront, et les coûts en rejailliront entièrement sur les entreprises.

[GN⁺]

Opinion de Hacker News

• Au début je me suis dit, en ne voyant que le titre de cet article, que c’était l’histoire classique d’un “security theater”. En le lisant, j’ai pourtant eu l’impression d’y trouver de réelles intuitions. Un passage m’a particulièrement marqué : MCP ignore ce type de leçon en utilisant des indices non contraignants sur du JSON sans schéma, avec une validation de type faite au runtime ou parfois absente. Par exemple, si un outil IA attend un timestamp ISO-8601 et reçoit une valeur d’époque Unix, le modèle peut ne pas échouer proprement et produire n’importe quelle date. Dans la finance, cela peut amener une IA de trading à interpréter mal les nombres et exécuter des transactions avec une précision décimale incorrecte ; en santé, une mauvaise conversion de type des données patient peut recommander un dosage médicamenteux erroné ; dans l’industrie, la perte de précision lors de la sérialisation JSON des données capteurs peut provoquer des problèmes de contrôle qualité. Quand on manipule des LLM au quotidien, ce genre de problème est effectivement fréquent. On peut imaginer qu’un jour, dans un système avec MCP, un grave incident se produira : le serveur MCP émet des données étranges, le LLM les ingère, génère une sortie hallucinée incohérente, et cela enchaîne vers des incidents de plus en plus graves. Avec l’erreur humaine, la nature sans gestion d’exceptions des LLM (hallucinations) et la culture des startups qui déploient des services trop vite, de nouveaux types de bugs sont inévitables. Et quand ça éclatera, les users Twitter parleront sans fin d’une AGI qui hacke des codes de lancement de missiles, ce sera sans doute assez fascinant à observer.
  • Pour être honnête, avant 2023 je pensais que les pannes et bugs techniques à la Star Trek étaient trop fictifs pour arriver vraiment. Depuis l’arrivée des LLM, j’ai le sentiment que ça se produira vraiment. Je ne comprends de moins en moins quel lien il reste entre intégration LLM et ingénierie, et je m’interroge sur le bien-fondé de confier tout le contrôle de l’infra d’une boîte à une entité externe. Sans compter que, vu le problème de reproductibilité, une situation où “ça passe à peu près” ne peut pas vraiment être appelée ingénierie.
  • Je ne saisis pas bien la critique de l’auteur. MCP supporte JSON Schema, donc la réponse du serveur doit obligatoirement respecter ce schéma. Si un schéma requiert ISO-8601 et que le serveur envoie une époque Unix, c’est une violation nette du protocole. Mais l’auteur dit que MCP supporte JSON Schema tout en affirmant qu’on ne peut pas générer de client type-safe ; or il existe déjà une multitude de générateurs de code JSON Schema, donc ce point me semble inexact.
  • Le PEBKAC (erreur utilisateur) existait déjà ; le LLM ne fait qu’automatiser ça à grande échelle.
  • Sur le risque en santé d’un mauvais format de type entraînant une mauvaise dose médicamenteuse, j’ai bien senti à quel point parser correctement les timestamps est crucial en télémétrie médicale. C’est probablement aussi pour cela que j’ai commencé à écrire des tests unitaires à l’origine. Même sans NTP, nous recalculions parfois les timestamps d’en-tête pour les recaler. Ces mesures répondaient à des enjeux de revue d’incident et de responsabilité médicale. Par exemple, l’écart entre l’instant où un patient en arrêt cardiaque reçoit un médicament et celui juste après peut faire basculer le pronostic vital. Comme dans le cas récent de Royal Mail au Royaume-Uni, une erreur de donnée peut détruire une vie ; dans les données de santé, une minute peut changer le monde.
  • MCP a pour but le transport et la gestion du contexte. En clair, la mise en place d’interfaces “raisonnables”, incluant définition et validation de schémas, reste à la charge de l’utilisateur. C’est comparable à la critique “HTTP ne valide pas le JSON” — c’est une évidence.
• MCP prétend devenir l’“USB-C du monde IA”, mais ironie du sort, cet exemple montre davantage les défauts de l’USB-C que les réussites de MCP. L’USB-C permet de connecter presque tout, mais la conformité au standard est catastrophique, semblable à un parsing JSON incohérent ou à des non-conformités de protocole MCP. Comme la réalité des câbles USB-C, derrière l’universalité apparente se cache une grande complexité. Je pense qu’il vaudrait mieux avoir des API ou protocoles plus clairement distincts.
  • Le cas le plus extrême de l’échec de l’USB-C est, je pense, le retrait des ports USB-A du tout dernier M4 Mac mini d’Apple. Un port visuellement identique peut avoir des performances totalement différentes, et l’utilisateur ne le découvre que tardivement. Avant, sur les desktops et laptops Apple Silicon, on pouvait généralement attendre du Thunderbolt 40 Gbps sur USB-C, mais certains ne sont maintenant qu’en USB3 10 Gbps. Il faut lire la fiche technique ou observer de petites icônes pour savoir lequel fait quoi. Garder quelques USB-A aurait plutôt montré clairement la limite à 10 Gbps, au lieu de diluer encore la valeur perçue de l’USB-C. Finalement, la plupart des appareils USB-C finissent quand même via des adaptateurs USB-A, et la version USB-C est plus chère, moins courante et parfois de moindre qualité. Mais dans notre monde, le hype et le fandom surpassent l’utilité et la praticité.
  • Honnêtement, cette ligne (universalité affichée de l’USB-C mais opacité réelle) m’a vraiment beaucoup fait rire. Mission accomplie, en quelque sorte.
• Pour SOAP, on entend parfois “il est verbeux mais MCP a saisi quelque chose de qu’SOAP ne sais pas”. En pratique, je doute que SOAP ait été véritablement compris. En maintenant des systèmes SOAP hérités, je n’ai rien de positif à dire sur lui. Je ne vois pas comment il pourrait servir de modèle.
  • En réalité SOAP fut une catastrophe énorme. C’est frappant de voir comment un concept qu’on pourrait garder simple devient aussi complexe. XML était complexe, ainsi que les définitions ambiguës sur WSDL ou les multipartes HTTP, sans garanties d’interopérabilité entre langages (ex. mon expérience SOAP avec serveur .NET et client Java), etc. Quand une mode est passée, les gens retiennent surtout les bons aspects ; pour ma part, j’aurais plutôt choisi de travailler 50 ans avec des APIs JSON sans schéma que de passer un mois avec SOAP. Personnellement, je pense que protobuf et capnp sont bien meilleurs.
  • REST (ou plutôt JSON-RPC) et GraphQL semblent encore tenter de couvrir les fonctionnalités que SOAP et SOA offraient déjà.
  • Les protocoles qui contiennent le mot “Simple” ne sont jamais vraiment simples. Je parierais qu’on verra bientôt un protocole de type SMCP.
  • Je partage un lien très drôle et très juste qui explique SOAP : https://harmful.cat-v.org/software/xml/soap/simple. J’aime les technologies basées sur XML, et je trouve que la combinaison des types et de la validation de XML Schema y reste vraiment inégalée. Mais SOAP donne l’impression d’un monstre inutile. Il fallait seulement une spécification pour un appel distant simple ; elle est devenue une spécification qui tente de définir absolument tout, sans bien traiter quoi que ce soit. SOAP prétend supporter de nombreux protocoles de transport (même SOAP over email), différents types de RPC, UDDI, des RPC auto-décrits, etc., mais en réalité l’implémentation de l’authentification, du caching, des codes de réponse HTTP, etc. reste aux utilisateurs.
  • Ce qui m’a définitivement fait rejeter SOAP, c’est cette présentation SOAP de l’époque. Ça marchait à peu près entre un même langage, mais devenait catastrophique dès qu’il y avait plusieurs langages. Je pense que c’est aussi pour cela que Microsoft adorait SOAP.
• CORBA est né en 1991 avec l’intuition qu’on ne peut pas se contenter d’implémenter un protocole par langage dans un environnement hétérogène, et il est vrai que l’OMG IDL générait des bindings homogènes sur plusieurs langages, évitant ainsi des problèmes d’interface et de sérialisation. Mais je me demande s’il a vraiment été un succès.
  • L’écosystème API centré sur le JSON d’aujourd’hui est plutôt une réaction aux échecs de CORBA et SOAP, pas un oubli des leçons apprises.
  • J’ai travaillé dans des endroits où CORBA était très bien utilisé. J’imagine que la raison du succès, le cas échéant, tenait au fait qu’il y avait des ingénieurs seniors expérimentés en CORBA dans l’équipe.
  • J’ai postulé chez AT&T en 1998 pour un poste avec CORBA, ce qui a été ma dernière expérience dans ce domaine (après, je ne l’ai plus revu que comme ce qui ralentissait le téléchargement du JDK). L’intervieweur n’a pas aimé mon code concurrentiel, et je n’ai pas réussi à faire valoir la présence d’une condition de concurrence. Par la suite, il est apparu que mon idée était la bonne du point de vue du Java Memory Model.
  • CORBA a bien fait pas mal de choses, mais c’est un produit de la fin des années 80, du réseau télécom traditionnel et de la vague OOP. Il partait du principe d’un réseau transparent, fiable et symétrique. Or la réalité inclut des timeouts, retry, congestion réseau, crashs systèmes, etc. Le binding CORBA C++ était particulièrement terrible avant l’arrivée de la STL, parfois les autres langages faisaient mieux.
  • Sur le plan technique il faut reconnaître qu’il avait de la valeur, même si commercialement le projet a finalement échoué.
• Ce qu’on rate dans la discussion sur MCP, la “vraie leçon apprise”, c’est que les fonctionnalités avancées apportent de la complexité et poussent la plupart des implémentations terrain à choisir le simple. C’est pour cela que JSON over HTTP est devenu majoritaire. Même chez les grandes entreprises, migrer vers des protocoles de sérialisation plus sophistiqués comme gRPC prend des années et peut échouer plusieurs fois. Je pense que le vrai rôle de MCP est de standardiser des contrats d’API JSON simples pour faciliter la génération de tokens et de styles d’appels d’outils orientés LLM.
  • Je suis curieux de comprendre ce que sont les HTTP blobs. J’ai l’impression que le propos visait à expliquer pourquoi JSON a fini par l’emporter sur XML.
• MCP n’est pas parfait, mais il a retenu au moins la leçon de décennies d’histoire des RPC : la complexité est le principal frein à l’adoption et à l’exploitation (à l’instar de l’ascension de JSON face à XML). SOAP a été trop complexe pour l’interopérabilité, et XML plus les schémas étaient trop verbeux. CORBA était trop complexe à cause de ses libs et frameworks, si bien qu’à l’époque les langages les plus récents le fuyaient. gRPC est rapide mais moins lisible et demande du mapping. Aujourd’hui l’ossature RPC, c’est REST et JSON. Les standards cités ci-dessus sont en recul, et gRPC reste cantonné aux cas à exigences de performance extrême. Le succès de REST et JSON vient de cette victoire de la simplicité, et MCP en est une déclinaison.
• Beaucoup de bons points en tout cas. Je pense qu’on comprend mal MCP. Le vrai sujet plus important est de clarifier ce qu’est un agent et où il va. Beaucoup de plateformes web pensent que les agents doivent être ancrés dans une infrastructure réseau distribuée, avec l’objectif de faire en sorte que tous les agents d’un conteneur se branchent à MCP via un service mesh. De mon point de vue, dire que des “agents web natifs” et des SDK/frameworks doivent être déployés comme des applications serveur est une erreur ; ces composants ne sont pas des agents, et même à ce stade de l’évolution ils ne correspondent pas à leurs formes initiales. Les vrais harness d’agent seront probablement produits uniquement par quelques fournisseurs, comme Frontier Labs, et cela ira de plus en plus vers la personnalisation (ex. un seul serveur MCP pour Claude Desktop sur mon poste). Les serveurs MCP sont à l’origine faits pour ce type d’instance unique et de harness.
  • Le problème de MCP n’est pas un manque d’adaptation à l’entreprise, c’est surtout une mauvaise utilisation des LLM. Si une IA financière exécute une transaction avec une erreur de précision décimale, ce n’est pas un défaut du protocole : c’est le fait d’avoir confié le trading à un LLM sans contraintes. De la même manière, si un LLM interprète mal un format de date et sort une hallucination, c’est encore le problème d’avoir mis un LLM dans un contexte critique.
• J’aimerais que quelqu’un explique clairement pourquoi MCP est nécessaire, au lieu de Swagger ou de proto.
  • OpenAPI (Swagger) et Proto (protobuf) ne couvrent pas à eux seuls tous les rôles de MCP. En théorie, on pourrait empiler MCP par-dessus, mais pour les cas d’usage locaux, les hypothèses de communication d’OpenAPI ne collent pas ; protobuf ne définit pas de protocole de communication, donc il faut une couche supplémentaire de conception. Même en remplaçant JSON-RPC, il faudrait conserver quasi intégralement la spécification MCP, ce qui ne ferait qu’augmenter la complexité.
  • MCP est une technologie nouvelle.
  • MCP supporte les réponses en streaming. Le polling ou la gestion d’état de session peuvent s’en approcher, mais ce sont des rustines inefficaces.
• Quand OpenAI dit avoir été facturée de 50 000 $ d’usage API le mois dernier, il est parfois impossible de savoir quel outil MCP du service a été responsable de cette facture, quelle invocation, quel utilisateur ou quel cas d’usage en est à l’origine. Dans la plupart des technologies IA, on court souvent derrière les problèmes. Mais, comme pour les frameworks web ou la blockchain, quand une technologie devient trop grande, il est normal de ne pas tout connaître au départ. L’écart se comble progressivement. Même en IA, je suis d’accord sur le fait de continuer à partager idées et vigilance. C’est vraiment une période passionnante.
• Quand il faut choisir entre une meilleure solution et une solution “suffisamment bonne”, c’est presque toujours cette dernière qui l’emporte. C’est la même histoire avec Multics vs Unix, SOAP/XML vs REST/JSON, l’échec de xhtml, JavaScript lui-même, etc. L’humain finit toujours par réimplémenter “assez bon”, en faisant des rustines de façon itérative quand les problèmes surgissent.
  • C’est une répétition bien connue du phénomène Worse is Better (https://en.m.wikipedia.org/wiki/Worse_is_better). Il a été confirmé à maintes reprises avec le temps. Je suis souvent attiré par des solutions “meilleures”, mais la réalité n’est pas toujours de cet ordre.
  • Une minute de silence serait méritée pour xforms 2.0. Le monde où nous aurions pu vivre : une validation correcte des formulaires web, de microdonnées...