À une époque où l’intelligence artificielle (IA) transforme nos interactions avec la technologie, le Model Context Protocol (MCP) s’impose comme une référence essentielle pour l’intégration d’outils dans ce domaine. Ce protocole est souvent considéré comme une solution à la complexité croissante des environnements d’IA, cherchant à faciliter les interactions entre différents agents et ensembles d’outils. Cependant, cette apparente simplicité dissimule des défis significatifs qui méritent une attention particulière.
Effectivement, alors que le MCP promet une standardisation des processus, il soulève également des interrogations sur la viabilité de cette approche. La progression rapide de ce protocole rappelle d’autres innovations technologiques qui, bien qu’initialement adoptées avec enthousiasme, ont rapidement montré leurs limites après une large utilisation. Par exemple, les plateformes de médias sociaux ont révolutionné la communication, mais sont aujourd’hui critiquées pour leurs effets sur la vie privée et la désinformation. De manière similaire, le MCP, malgré ses atouts, pourrait rencontrer des réalités plus nuancées.
L’engouement pour le MCP est également nourri par des facteurs externes, comme la pression des entreprises à adopter des standards ouverts et innovants. Ce phénomène est semblable à celui observé dans le secteur technologique, où les entreprises se précipitent pour démontrer leur compatibilité avec des protocoles émergents afin d’améliorer leur crédibilité et d’attirer des clients. Toutefois, cette quête de l’adoption peut parfois masquer des problèmes fondamentaux risquant de compromettre l’efficacité et la sécurité des systèmes d’IA.
Dans ce contexte, il est essentiel d’explorer non seulement les promesses offertes par le MCP, mais aussi les défis qu’il engendre. En analysant attentivement les implications de son utilisation, il sera possible de déterminer si cette solution répond réellement aux besoins d’un écosystème d’IA en constante évolution ou si elle représente un recul face à des alternatives plus efficaces. Ce parcours à travers les complexités du MCP permettra d’éclairer les enjeux de l’intégration des outils d’IA et de mieux comprendre l’avenir de cette technologie fascinante.
Aperçu Le MCP a gagné en notoriété en tant que protocole de référence pour l’intégration d’outils d’IA. Cependant, cette montée en popularité pourrait être passagère, en raison de certaines idées reçues entourant ses capacités réelles. En effet, l’ajout d’un serveur MCP est souvent perçu comme un moyen simple d’attirer l’attention sur un projet, incitant de nombreux développeurs à intégrer ce protocole.
Le Model Context Protocol (MCP) s’est imposé comme une plateforme standardisée pour les intégrations d’intelligence artificielle. Néanmoins, bien que sa popularité soit indéniable, il est crucial d’examiner sa pérennité. Cet article explore les défis posés par le MCP, ses implications et les alternatives qui pourraient le supplanter.
Qu’est-ce que le MCP ?
Le MCP se présente comme une solution au “problème NXM”, où un nombre d’agents (n) doit interagir avec plusieurs ensembles d’outils (m). Sans cette approche, les utilisateurs feraient face à la nécessité de créer de nombreux connecteurs spécifiques.
Le problème NXM
Une idée reçue commune est que le MCP est indispensable pour effectuer des appels de fonction, alors que ce n’est pas nécessairement le cas. Avec les modèles d’appel d’outils, une liste d’outils disponibles est fournie au modèle de langage avec chaque requête. Si le modèle souhaite appeler un outil, il retourne des paramètres au format JSON. Toutefois, l’application reste responsable de la fourniture des schémas d’outils, de l’analyse des paramètres et de l’exécution des appels. Le véritable défi se présente lorsque les utilisateurs cherchent à réutiliser des ensembles d’outils entre différents agents, chacun ayant des API légèrement différentes.
Comment le MCP répond à ce problème
Le MCP gère l’exposition et l’invocation des outils à travers des processus séparés. Une configuration au format JSON détermine quels serveurs MCP doivent être démarrés. Chaque serveur fonctionne dans son propre processus, gérant séparément les invocations d’outils. Bien que cela simplifie la gestion des schémas et des invocations, cela entraîne des coûts: la logique des outils s’exécute dans un processus distinct, rendant la gestion des ressources opaque et limitant le contrôle de l’application sur les instructions des outils, la journalisation et le traitement des erreurs.
Portée: Les outils dominent
Le MCP définit également des primitives pour les invites et les ressources, mais leur adoption reste bien inférieure à celle des outils. Cet article se concentrera principalement sur les appels d’outils, qui constituent le principal cas d’utilisation du MCP.
Problèmes associés au MCP
La commodité qu’offre le MCP s’accompagne de défis, principalement dus à deux attributs architecturaux d’une application basée sur le MCP.
Boîte à outils incohérente
Les agents perdent souvent en efficacité à mesure que le nombre d’outils augmente. Un ensemble d’outils bien organisé permet aux agents de fonctionner de manière optimale, tandis qu’un ensemble désorganisé complique leur tâche. Il est conseillé de limiter le nombre d’outils à moins de 20, mais de nombreux serveurs MCP dépassent ce seuil. Ce phénomène soulève des questions sur la pertinence des outils: un agent, par exemple, doit décider d’envoyer une notification après avoir effectué une tâche. L’adéquation d’un outil à une tâche dépend non seulement de celle-ci, mais aussi des autres options disponibles. Si les outils sont livrés isolément, leurs instructions ne peuvent indiquer quand les utiliser par rapport à d’autres. Cette problématique pourrait être atténuée si les auteurs des outils ajoutaient des indications pour clarifier leur utilisation.
Runtimes séparés
Chaque serveur MCP démarre dans un processus distinct qui persiste durant la session de l’agent. Même dans un état normal, cela engendre un ensemble de processus majoritairement inactifs, à l’exception de quelques requêtes de l’agent. En cas d’erreur, des problèmes tels que des sous-processus en attente, des fuites de mémoire et des conflits de ressources peuvent survenir. De nombreux utilisateurs rencontrent des difficultés à lancer ces serveurs, et les plaintes les plus fréquentes dans les canaux de support concernent l’incapacité à les faire fonctionner. De plus, le MCP n’offre aucune méthode permettant aux serveurs de déclarer leurs besoins en matière d’exécution et de dépendances. Certains auteurs tentent de contourner ce problème en intégrant l’installation dans la commande de lancement, une approche qui ne réussit que si l’utilisateur possède déjà les outils requis.
Problèmes de sécurité
Le MCP pousse les utilisateurs à installer des serveurs à partir de sources telles que npm, pip ou GitHub, ce qui introduit des risques liés à la chaîne d’approvisionnement, sans même les protections minimales que ces écosystèmes pourraient offrir. Il n’existe pas de vérification d’authentification standardisée, laissant les décisions de sécurité à la discrétion des auteurs de serveurs. Le résultat est préoccupant: de nombreux serveurs MCP fonctionnent sans authentification client ni cryptage des données. Les incidents de sécurité, tels que les fuites de données, soulignent la vulnérabilité de ce protocole. Un agent peut être manipulé par injection de prompt pour appeler des outils de manière imprévue, exposant ainsi des données sensibles.
Le rapport coût-bénéfice ne s’additionne pas
Ces problèmes pourraient être justifiés si les avantages étaient significatifs, mais une comparaison entre les appels d’outils avec et sans MCP révèle que le MCP gère très peu. Fondamentalement, il ne se charge que de la sérialisation des schémas d’appels de fonction et des réponses. Les outils que les développeurs pensent économiser en utilisant le MCP sont souvent de simples wrappers autour de clients d’API, laissant aux utilisateurs la responsabilité d’obtenir des clés API et des comptes de facturation.
Pourquoi le MCP a-t-il pris de l’ampleur ?
Face à ces défis, il est légitime de s’interroger sur les raisons de la popularité du MCP. Plusieurs facteurs expliquent cette adoption.
Auteurs d’outils: Un canal marketing à faible coût
Il est relativement simple de publier un serveur MCP, permettant aux auteurs de promouvoir leurs projets d’IA sans avoir à passer par des plateformes comme npm ou pip. Un ajout d’annotation dans le dépôt, accompagné d’un manifeste JSON, suffit pour attirer l’attention.
Entreprises: Crédibilité en matière d’IA
Au cours des dernières années, de nombreuses entreprises ont réorienté leur image vers l’intelligence artificielle. Le soutien au MCP leur a permis de se positionner comme des acteurs de l’innovation technologique, renforçant ainsi leur crédibilité.
Anthropique: Crédibilité open source
La reconnaissance du MCP comme standard ouvert a également bénéficié à Anthropique, rassurant les investisseurs sur la durabilité de l’adoption de cette norme par les entreprises.
Alternatives au MCP
Différentes catégories d’utilisateurs interagissent avec le MCP, notamment :
Qui bénéficie du MCP ?
Utilisateurs techniques: Création et partage d’outils entre différents agents. Utilisateurs non techniques: Utilisation d’outils via des agents, bien que cette catégorie soit encore théorique. Développeurs d’applications internes: Gestion d’applications IA en production. Développeurs d’agents: Création d’agents permettant aux utilisateurs de changer d’outils facilement. Auteurs d’outils: Partage de leur travail avec les utilisateurs de différents agents.
Scripts locaux avec un exécuteur de commandes
Pour les utilisateurs techniques, permettre à un agent d’invoquer des scripts directement s’avère extrêmement efficace. Des scripts de 50 à 100 lignes sont faciles à écrire, et des outils comme des exécuteurs de commandes offrent des spécifications claires tout en maintenant la sécurité.
Outils de première partie
Pour une application autonome, il n’est pas nécessaire de séparer le code des outils du reste de l’application. Les outils peuvent être exposés dynamiquement en fonction du contexte de l’application.
OpenAPI / REST
Les spécifications OpenAPI sont suffisamment auto-descriptives pour que les agents les comprennent aisément. La liaison entre un point de terminaison OpenAPI et un agent nécessite les mêmes ajustements que ceux requis par le MCP, sans apporter de bénéfices significatifs en matière de description des outils.
Prévisions
Il est prévisible que la popularité du MCP soit de courte durée. Le rapport coût-bénéfice ne s’additionne pas, et des alternatives plus efficaces émergent. Des solutions comme Claude Skills et l’adoption rapide par OpenAI suggèrent que même les fournisseurs de modèles commencent à reconnaître les limites du MCP. Ces solutions réorganisent les commandes dans des fichiers markdown, permettant une meilleure organisation et un accès plus facile à la documentation, tout en répondant aux besoins des utilisateurs. Les techniques et outils de collaboration traditionnels continueront de prévaloir face aux méthodes centrées sur l’IA qui tentent de réinventer la roue.
L’émergence du Model Context Protocol (MCP) met en lumière les défis et les opportunités associés à l’intégration des outils d’intelligence artificielle. Bien que ce protocole se positionne comme une solution face à la complexité croissante des interactions entre agents et ensembles d’outils, il révèle également des lacunes qui nécessitent une attention particulière. Les préoccupations liées à la sécurité, à l’efficacité et à la gestion des ressources sont au cœur des enjeux, tout comme l’incohérence qui peut découler d’un trop grand nombre d’outils.
La dynamique actuelle entourant le MCP rappelle d’autres évolutions technologiques, où un engouement initial est souvent suivi d’une phase de remise en question. En effet, cette quête de standardisation peut parfois occulter les véritables besoins des utilisateurs. Par ailleurs, la pression exercée par les entreprises pour adopter des normes ouvertes soulève des questions sur les motivations réelles derrière cette adoption.
À une époque où l’innovation technologique façonne les interactions humaines, il est crucial d’examiner de manière critique les outils et protocoles que nous choisissons d’adopter. La réflexion sur le MCP ouvre la voie à des discussions plus larges concernant l’avenir de l’intelligence artificielle et la manière de garantir que ces technologies répondent effectivement aux besoins sociétaux tout en minimisant les risques potentiels. Cette exploration appelle à une vigilance accrue et à une recherche continue d’alternatives susceptibles d’offrir de meilleures solutions, tout en favorisant une compréhension approfondie des enjeux en jeu.
Aller plus loin
Pour vous faire une idée rapide de ce que MCP apporte vraiment (et de ce qu’il n’apporte pas), le plus efficace est de partir de la doc officielle et d’un exemple complet de serveur. Le tutoriel Build an MCP server montre comment exposer des outils et des ressources à un client, puis comment valider que l’intégration fonctionne en conditions réelles. Cette lecture met aussi en évidence la frontière entre “standard d’intégration” et “logique métier” : MCP simplifie le branchement, mais ne remplace ni la modélisation des permissions ni l’observabilité.
Pour aller au-delà des démos et discuter sur du concret, la référence structurante reste la spécification. La page Model Context Protocol – Specification (2025-06-18) détaille les messages, les contrats attendus et les exigences de compatibilité, ce qui permet de juger la maturité d’un écosystème sans se fier aux annonces. Elle aide aussi à comprendre pourquoi MCP ressemble davantage à un “bus” de capacités qu’à une simple liste d’APIs, et où se situent les risques d’interprétation divergente entre clients et serveurs.
Si l’article questionne le caractère “éphémère” d’une tendance, la gouvernance est un bon indicateur de survie à moyen terme. Le communiqué Linux Foundation – Agentic AI Foundation (AAIF) éclaire le choix de placer MCP dans une structure de standardisation plus neutre, avec un cadre de contributions et une trajectoire communautaire. Cela ne garantit pas l’adoption, mais rend plus lisible la capacité du protocole à dépasser un seul éditeur et à stabiliser ses versions.
Pour évaluer l’écosystème côté implémentations, rien ne vaut un SDK concret qui suit les versions de spec et la compatibilité ascendante. Le dépôt mcp-go illustre comment un client ou un serveur MCP est réellement câblé dans une stack applicative, avec des choix pragmatiques sur le transport et la sérialisation. C’est une bonne façon de voir si MCP accélère votre delivery ou s’il introduit une couche de complexité supplémentaire à maintenir.
Pour remettre MCP à sa juste place, il est utile de comparer avec les standards qui règlent déjà une partie du problème d’intégration depuis des années. La spécification OpenAPI reste une base solide quand votre besoin est de décrire proprement des APIs HTTP, générer des clients et industrialiser des contrats stables. Et la spécification JSON-RPC 2.0 permet de comprendre la brique de base sur laquelle reposent de nombreux échanges de type “appel de méthode”, avec des implications directes sur l’observabilité, la gestion d’erreurs et la sécurité applicative.
Enfin, si MCP sert à exposer des outils à des agents, la discussion “ça durera ou pas” se joue aussi sur la sécurité et la confiance opérationnelle. Le référentiel OWASP Top 10 for LLM Applications 2025 aide à cadrer les risques typiques dès qu’un modèle déclenche des actions (injection, sorties non sûres, supply chain, déni de service). Pour une lecture française orientée architecture, les recommandations ANSSI pour un système d’IA générative donnent des repères concrets sur le cloisonnement, les secrets, les journaux et le contrôle d’accès, qui deviennent critiques dès qu’un protocole facilite la connexion à des systèmes réels.