Il y a un an à peine, évoquer le Model Context Protocol (MCP) revenait à entrer dans une conversation confidentielle entre ingénieurs d’agents IA. Aujourd’hui, la spécification lancée par Anthropic en novembre 2024 est en passe de devenir ce que le TCP/IP fut pour Internet : une couche fondatrice qui décide qui peut parler à qui, et comment. Et comme toute couche fondatrice, elle concentre désormais autant d’espoirs que de controverses.
En quelques mois, OpenAI, Google, Microsoft et Anthropic ont tous rallié le standard. Les marketplaces de serveurs MCP explosent, les SDK se multiplient, et les entreprises commencent à brancher ChatGPT, Claude ou Copilot directement sur leurs systèmes internes. Pourtant, derrière cette adoption fulgurante, une question taraude l’écosystème : MCP est-il prêt à supporter la charge d’une infrastructure critique, ou sommes-nous en train de répéter les erreurs de sécurité des débuts du web ?
Rappel : qu’est-ce que le Model Context Protocol exactement
Le MCP est un protocole ouvert publié par Anthropic qui normalise la façon dont les modèles d’IA se connectent aux outils, aux sources de données et aux systèmes externes. Plutôt que de coder une intégration ad hoc pour chaque assistant et chaque service, les développeurs exposent un serveur MCP qui décrit ses ressources, ses outils et ses prompts selon un format commun. Du côté du modèle, un client MCP consomme cette interface sans se préoccuper de son implémentation sous-jacente.
Techniquement, l’architecture repose sur JSON-RPC 2.0, avec deux transports principaux : STDIO pour les serveurs locaux et HTTP + Server-Sent Events pour les serveurs distants. La spécification couvre trois primitives fondamentales — resources (données), tools (actions) et prompts (gabarits réutilisables) — auxquelles s’ajoutent les mécanismes d’authentification, d’échantillonnage et de notification. En clair, MCP fournit un langage universel pour qu’un agent IA puisse, sans intégration dédiée, lire un dépôt Git, interroger une base de données, envoyer un email ou piloter un outil métier.
Pourquoi MCP est devenu un test de maturité pour toute l’industrie
La véritable nouveauté de 2026 n’est pas le protocole lui-même, mais ce qu’il révèle du niveau de préparation du secteur. Pendant dix ans, l’IA a surtout produit des démos. Avec MCP, les agents IA quittent le terrain du POC pour toucher à la production : ils exécutent du code, modifient des fichiers, orchestrent des API payantes, manipulent des données personnelles. Chaque décision de conception du protocole a donc un coût réel en dollars, en confiance et parfois en conformité réglementaire.
Le test de maturité est triple. Premièrement, la gouvernance : qui arbitre les évolutions de la spec quand elle concerne désormais des milliards d’utilisateurs potentiels ? Deuxièmement, la sécurité par défaut : une norme aussi puissante peut-elle se permettre de laisser les garde-fous à la discrétion de chaque implémenteur ? Troisièmement, l’interopérabilité réelle : derrière les annonces marketing, les clients MCP d’OpenAI, Google et Microsoft parlent-ils vraiment le même dialecte, ou sommes-nous déjà en train de voir apparaître des divergences silencieuses ?
L’adoption par les géants : OpenAI, Google, Microsoft et Anthropic alignés
L’évènement le plus frappant des derniers mois est la convergence des grands acteurs. OpenAI a intégré le support MCP dans son Agents SDK et dans ChatGPT Desktop, permettant à n’importe quel serveur conforme d’être branché au modèle. Google a annoncé la compatibilité MCP dans Gemini et dans la plateforme Agent Builder de Vertex AI. Microsoft, pour sa part, l’a adopté dans Copilot Studio, dans Windows via l’écosystème Copilot+ et dans GitHub Copilot avec une bibliothèque officielle de serveurs. Quant à Anthropic, instigateur du standard, il le place au cœur de Claude Desktop et de son offre entreprise.
Cet alignement est rare dans l’histoire récente des standards technologiques. Il rappelle davantage l’adoption de HTTP dans les années 90 que les guerres de formats qui ont ponctué l’ère mobile. Le déploiement massif de GPU chez des acteurs comme CoreWeave vient alimenter encore la demande en infrastructures capables d’héberger ces agents à grande échelle. Pour autant, l’alignement ne garantit rien : l’histoire du web est aussi jalonnée d’extensions propriétaires qui ont fini par fragmenter les implémentations. Le risque d’embrace, extend, extinguish appliqué à MCP n’est pas théorique, surtout quand chaque éditeur a intérêt à différencier ses agents par des capacités exclusives.
Défis techniques et sécurité : la face sombre d’un protocole puissant
La puissance de MCP est aussi sa principale vulnérabilité. En exposant des outils capables d’exécuter des commandes, de lire des fichiers ou de déclencher des appels API payants, le protocole devient une surface d’attaque privilégiée. Les rapports d’OX Security publiés fin 2025 ont recensé plus de trente divulgations responsables et une dizaine de CVE critiques liées à des implémentations officielles ou dérivées.
Prompt injection : l’ennemi invisible des agents
Le risque le plus documenté reste la prompt injection indirecte. Un document Word malveillant, une page web piégée ou un ticket Jira manipulé peuvent glisser des instructions dans le contexte d’un agent, qui les exécutera via un tool MCP sans toujours distinguer l’intention de l’utilisateur de celle de l’attaquant. Les patterns de défense existent — sandboxing, validation humaine, liste blanche d’outils — mais leur application reste à la charge de chaque intégrateur.
Gouvernance des serveurs et marketplaces
Avec plus de 200 000 serveurs MCP estimés en circulation, la question de la confiance devient centrale. Comment vérifier qu’un serveur communautaire ne se transforme pas en cheval de Troie ? Les marketplaces officielles commencent à proposer du scanning automatique et de la signature cryptographique, mais le ratio signal/bruit reste préoccupant, d’autant que certains serveurs tiers reprennent la logique STDIO du SDK officiel sans appliquer les mêmes garde-fous.
Identités et privilèges à l’échelle de l’agent
Troisième défi : la gestion des identités. Un agent IA qui opère au nom d’un utilisateur doit assumer ses privilèges sans pouvoir les étendre. En pratique, les implémentations actuelles ont tendance à cumuler les tokens OAuth, les clés API et les identifiants système dans un contexte partagé, facilitant les élévations de privilèges involontaires. La norme OAuth 2.1 intégrée récemment à la spec MCP constitue un début de réponse, mais la granularité reste souvent trop grossière pour des usages entreprise.
MCP face à ses alternatives : OpenAPI, REST et GraphQL pour agents
MCP n’est pas arrivé dans un vide technologique. OpenAPI décrit depuis longtemps des API REST de manière standardisée, et des projets comme les GPT Actions d’OpenAI ou les fonctions Gemini montraient déjà qu’on pouvait exposer des endpoints à un modèle. GraphQL offre de son côté une granularité de requête particulièrement séduisante pour des agents qui souhaitent cibler exactement les champs dont ils ont besoin. Pourtant, ces alternatives couvrent mal les besoins spécifiques du raisonnement agentique.
La différence fondamentale tient à la sémantique. OpenAPI décrit des endpoints, pas des intentions. GraphQL décrit un graphe de données, pas un contexte conversationnel. MCP, lui, modélise explicitement la notion de ressources consultables, d’outils activables et de prompts réutilisables, avec des mécanismes bidirectionnels (le serveur peut solliciter le modèle via sampling). C’est cette vision centrée sur l’agent — plutôt que sur l’API — qui explique son adoption rapide malgré la maturité supérieure des alternatives.
Implications pour les développeurs et les entreprises
Pour les développeurs, MCP change la façon de penser les intégrations. Construire un serveur MCP n’est plus un exercice isolé : il s’agit d’exposer une capacité qui pourra être consommée par n’importe quel modèle compatible. Cette neutralité par rapport au fournisseur libère des écosystèmes propriétaires, mais impose aussi une rigueur accrue sur la documentation, le versioning et la gestion des erreurs.
Côté entreprises, l’enjeu est plus stratégique. Déployer MCP en interne signifie offrir à ses équipes — voire à ses modèles externes — un accès contrôlé à ses systèmes métier. Les DSI commencent à mettre en place des passerelles MCP centrales, équivalents des API gateways des années 2010, qui agrègent les serveurs internes, imposent des politiques d’accès uniformes et journalisent toutes les interactions. C’est probablement la forme la plus mature que prendra l’adoption en 2026.
Perspectives : convergence vers un standard unique ?
Une question reste ouverte : MCP restera-t-il un standard véritablement unique, ou verrons-nous émerger des concurrents ? Plusieurs pistes circulent. Le W3C a ouvert une discussion sur la normalisation d’une couche d’interopérabilité pour agents. L’IETF observe de près les aspects transport et sécurité. Et certains acteurs de l’open source plaident pour un fork gouverné par une fondation neutre, à l’image de ce que la Cloud Native Computing Foundation a fait pour Kubernetes.
Le scénario le plus probable reste une convergence progressive autour de MCP, accompagnée d’une gouvernance multi-acteurs qui échapperait à Anthropic seul. Ce mouvement a déjà commencé : le comité de pilotage du protocole intègre désormais des représentants d’OpenAI, de Microsoft et de plusieurs éditeurs indépendants. Reste à voir si cette ouverture suffira à rassurer les entreprises régulées — secteur financier, santé, administration — qui attendent des garanties fortes avant d’intégrer l’IA agissante dans leurs processus critiques.
Questions fréquentes sur le Model Context Protocol
MCP remplace-t-il les API REST traditionnelles ?
Non. MCP se superpose aux API existantes : un serveur MCP appelle souvent lui-même une API REST ou GraphQL en coulisses. La valeur ajoutée est d’exposer ces API de façon exploitable par un agent IA, avec une sémantique pensée pour le raisonnement plutôt que pour l’intégration logicielle classique.
Quels sont les risques principaux d’un serveur MCP mal configuré ?
L’exécution de commandes non contrôlées, la fuite de données via des outils trop permissifs, et l’exposition à la prompt injection. Les bonnes pratiques imposent le sandboxing, la liste blanche d’outils, la validation humaine sur les actions sensibles et une rotation rigoureuse des secrets.
MCP est-il adapté aux entreprises régulées ?
Pas sans précautions. La majorité des déploiements enterprise passent aujourd’hui par une passerelle MCP centrale qui impose audit, chiffrement et politiques d’accès. Les secteurs financiers ou de santé attendent encore la maturité d’un socle de gouvernance officiel avant d’aller plus loin.
Qui gouverne réellement le protocole MCP ?
Anthropic reste le principal mainteneur de la spécification, mais un comité de pilotage associe progressivement OpenAI, Microsoft, Google et des contributeurs open source. L’objectif affiché est de faire évoluer MCP vers une gouvernance plus neutre, probablement sous l’égide d’une fondation.
Peut-on développer son propre serveur MCP facilement ?
Oui. Des SDK officiels existent en Python, TypeScript, Java, C# et Go. Un serveur minimal se développe en quelques dizaines de lignes de code. La complexité réelle arrive au moment d’industrialiser : authentification, observabilité, limitation de débit et compatibilité avec les clients réels.
