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.