La plupart des équipes qui construisent des workflows propulsés par l’IA se heurtent au même mur vers la troisième semaine. Elles disposent d’un LLM opérationnel. Elles ont des données dans un CRM, un entrepôt de données, peut-être un système de fichiers. Et elles accumulent une couche grandissante de code personnalisé reliant les deux : une intégration sur mesure par source de données, chacune légèrement différente, chacune dépendant de la personne qui l’a écrite, chacune représentant un risque de maintenance discret que personne n’a encore pleinement pris en compte.
C’est précisément le problème que le Model Context Protocol a été conçu pour résoudre. Ce n’est ni un produit ni une plateforme : c’est un standard ouvert qui transforme la couche d’intégration elle-même. Comprendre ce qu’est réellement MCP, comment son architecture fonctionne et quelles sont ses véritables limites prend environ vingt minutes. Se remettre d’une mauvaise décision d’adoption prise sans cette compréhension prend nettement plus longtemps.
Ce que la plupart des équipes découvrent après s’être déjà engagées
- MCP est un standard ouvert, pas un produit : il standardise la manière dont les LLM se connectent aux outils et aux données, pas le contenu de ces outils.
- Le problème M×N est réel : N sources de données multipliées par M applications d’IA créent rapidement une dette d’intégration personnalisée intenable.
- MCP ne remplace pas les API, ne gère pas les contrôles d’accès et ne conçoit pas votre stratégie de récupération : ces sujets restent à votre charge.
- OpenAI et Google DeepMind l’ont déjà adopté, ce qui réduit le risque d’infrastructure lié au fait de miser sur ce standard.
Qu’est-ce que le Model Context Protocol (MCP) ?
Le Model Context Protocol est un protocole ouvert introduit par Anthropic fin 2024 qui standardise la manière dont les applications d’IA se connectent à des outils externes, des sources de données et des informations contextuelles. Si vous avez entendu la comparaison avec « l’USB-C pour l’IA » et l’avez écartée comme un raccourci marketing, elle est en réalité plus juste qu’elle n’en a l’air — et comprendre pourquoi est le moyen le plus rapide de comprendre MCP.
Avant l’USB-C, chaque fabricant d’appareils disposait de son propre connecteur. Le chargeur de votre ordinateur portable ne convenait pas à votre téléphone. Le câble de votre téléphone ne convenait pas à votre appareil photo. Chaque nouvel appareil impliquait un nouveau câble, une nouvelle incompatibilité, un nouvel objet à perdre dans un tiroir. L’USB-C n’a pas remplacé l’électricité. Il a standardisé l’interface afin qu’une prise puisse fonctionner avec de nombreux appareils.
MCP fait la même chose au niveau de l’intégration avec les LLM. Avant MCP, chaque application d’IA ayant besoin d’accéder à une source de données externe nécessitait une intégration personnalisée : un connecteur conçu sur mesure, sa propre logique d’authentification, ses propres conventions de transmission du contexte et sa propre surface de maintenance. MCP est un protocole ouvert qui remplace ces connecteurs ponctuels par une interface standard unique.
Le socle technique est concret. MCP repose sur JSON-RPC 2.0 et définit des connexions avec état entre les applications d’IA et les systèmes auxquels elles se connectent. La spécification MCP couvre l’accès standardisé aux fichiers, aux fonctions et aux prompts contextuels — trois types de capacités qui couvrent ensemble l’essentiel de ce dont un agent LLM a réellement besoin auprès d’un système externe.
MCP est un protocole ouvert, ce qui signifie qu’il n’est pas propriétaire de Claude d’Anthropic. Toute application d’IA peut implémenter le standard et se connecter à tout serveur compatible MCP. C’est la couche protocolaire standard qui rend cette interopérabilité possible. Et l’adoption précoce par l’écosystème — Block et Apollo figuraient parmi les premiers intégrateurs cités dans l’annonce d’Anthropic — a rendu cet écosystème suffisamment solide pour y miser.
Une précision importante avant d’aller plus loin : MCP n’est pas un produit que vous achetez ni une plateforme à laquelle vous vous connectez. Vous l’implémentez. Cette distinction est importante pour savoir comment l’évaluer.
Le problème que MCP résout réellement : les intégrations M×N
Imaginez une équipe d’ingénierie de taille moyenne qui construit trois applications d’IA internes : un assistant de code, un agent de support client et un outil d’analyse de données. Chacune de ces applications doit accéder à quatre sources de données : GitHub, Jira, leur entrepôt de données et leur CRM.
Cela représente 3 applications multipliées par 4 sources de données, soit 12 intégrations personnalisées. Chacune exige une logique d’authentification, des conventions de transmission du contexte, une gestion des erreurs et une maintenance continue. Lorsque le CRM met à jour son API, quatre de ces douze intégrations doivent être corrigées. Lorsqu’une nouvelle application d’IA est ajoutée, quatre connecteurs personnalisés supplémentaires doivent être construits de zéro.
C’est le problème d’intégration M×N — M applications d’IA multipliées par N sources de données — et c’est exactement ce que MCP résout. Au lieu de M×N connecteurs sur mesure, les équipes créent N serveurs MCP, un par source de données, et M clients MCP, un par application d’IA. Le protocole gère l’interface entre eux. Ajoutez une application d’IA et elle se connecte aux serveurs MCP existants sans nécessiter de nouveaux connecteurs. Ajoutez une source de données et les applications d’IA existantes peuvent y accéder immédiatement.
La dette d’ingénierie qui s’accumule est bien réelle. Chaque intégration personnalisée représente une surface de maintenance. Modifiez le nom d’un champ dans le CRM, et l’intégration qui ne suivait pas de standard se casse d’une façon difficile à retracer. Ajoutez une limitation de débit à une API, et chaque connecteur sur mesure la gère différemment — ou ne la gère pas du tout, ce qui est le moment où les défaillances silencieuses commencent. Je vois ce schéma revenir régulièrement : les équipes ne remarquent pas que l’intégration est cassée parce que l’application d’IA continue de fonctionner, le tableau de bord reste au vert et les données obsolètes s’accumulent silencieusement en aval.
Il y a également un aspect lié aux hallucinations qui n’est pas suffisamment abordé. Lorsque les LLM reçoivent un contexte incohérent, incomplet ou obsolète parce que chaque intégration a été construite différemment et maintenue selon des standards différents, le modèle comble les lacunes par des inventions plausibles. Un problème de qualité d’intégration devient un problème de qualité des réponses. MCP réduit cette surface en standardisant la manière dont le contexte est transmis, afin qu’au moins le mécanisme de livraison soit cohérent — même si la qualité des données reste votre responsabilité.
Pourquoi les intégrations personnalisées échouent avec les workflows d’IA agentique
Les workflows d’IA en une seule étape sont tolérants. Vous appelez une API, vous obtenez du contexte, le modèle répond et l’interaction se termine. Mais les systèmes d’IA agentique — ceux qui prennent une suite de décisions, invoquent plusieurs outils et opèrent de manière autonome dans le temps — constituent une situation très différente.
Dans un workflow agentique, les connexions aux sources de données sont appelées de manière répétée, dans des combinaisons que le développeur initial n’avait pas totalement anticipées, par un modèle susceptible d’enchaîner les appels d’outils dans des séquences inattendues. Un connecteur ponctuel fragile qui fonctionnait parfaitement lors des tests en une étape échoue sous cette charge de façons réellement difficiles à diagnostiquer. Le comportement des appels d’outils est incohérent d’un connecteur à l’autre, car chacun a été construit par une personne différente avec des hypothèses différentes. La surface de maintenance augmente à chaque nouvel outil auquel l’agent doit accéder.
MCP répond à ce problème en donnant aux systèmes agentiques un contrat d’interface prévisible. L’agent n’a pas besoin de savoir comment fonctionne l’intégration personnalisée de chaque outil : il utilise le même modèle de protocole pour chaque connexion. Cette cohérence est précisément ce dont les systèmes agentiques dépendent.
Comment MCP établit une interface unique entre outils et sources de données
Concrètement, MCP standardise la conversation entre une application d’IA et les systèmes auxquels elle doit accéder. Il existe une manière définie de découvrir les capacités disponibles, une manière définie de les demander et une manière définie de recevoir les résultats, quel que soit le système situé de l’autre côté de la connexion.
C’est ce que signifie en pratique « standard pour connecter l’IA aux outils et aux données ». Un modèle se connectant à un serveur MCP GitHub utilise le même modèle de protocole que pour un serveur MCP Jira. Les API sous-jacentes sont différentes. L’interface MCP est identique. MCP standardise cette couche d’interface, et non les systèmes qui se trouvent derrière.
Pour les équipes qui construisent des workflows d’IA utilisant plusieurs outils, la conséquence est concrète : le travail nécessaire pour ajouter une source de données passe de « construire une intégration personnalisée, gérer l’authentification, définir les conventions de transmission du contexte, mettre en place la gestion des erreurs » à « se connecter au serveur MCP de cette source ». Le standard s’occupe du reste.
Architecture MCP : fonctionnement du modèle client-serveur
L’architecture devient plus simple à comprendre dès que vous cessez de considérer MCP comme un service et commencez à le voir comme un protocole : un ensemble de règles qui définissent la manière dont deux parties à une conversation doivent se comporter.
Une interaction MCP implique trois rôles : l’hôte, le client et le serveur.
L’hôte est l’application qui contient le LLM. Claude Desktop en est un exemple. Un assistant de programmation en est un autre. C’est l’environnement dans lequel l’IA s’exécute, et il est responsable de la gestion des connexions client MCP qui s’y trouvent.
Le client MCP est le composant situé dans l’hôte qui parle le protocole. Il maintient une connexion avec un ou plusieurs serveurs MCP, négocie les capacités et traduit les requêtes du modèle en appels MCP. Un hôte peut gérer plusieurs clients, ce qui signifie qu’une seule application d’IA peut communiquer simultanément avec de nombreux systèmes différents.
Le serveur MCP se place devant une source de données, une base de données, un système de fichiers ou une API externe. Il expose des capacités dans un format standardisé et répond aux requêtes des clients MCP. Le serveur ne sait pas et ne se soucie pas de savoir quel hôte se trouve à l’autre extrémité : il parle simplement le protocole.
Clients MCP, serveurs MCP et rôle réel de chacun
Le client MCP est l’application ou l’environnement d’IA qui initie les demandes de capacités. Lorsqu’un modèle de langage doit lire un fichier, interroger une base de données ou invoquer une fonction externe, la requête passe par le client MCP. Le client gère la négociation du protocole et maintient la connexion avec les serveurs MCP disponibles.
Le serveur MCP est le composant qui expose les capacités réelles. Vous construisez ou déployez un serveur MCP devant un système — GitHub, un CRM, un stockage de fichiers — et ce serveur rend les fonctionnalités du système disponibles pour les clients MCP de manière standardisée. L’hôte MCP gère l’authentification et le cycle de vie des connexions ouvertes. Différents serveurs MCP disponibles peuvent exposer des capacités qui se chevauchent ou se complètent, et le client les découvre à l’exécution.
Un point mérite d’être explicite : les serveurs MCP se placent devant des systèmes existants. Ils ne remplacent pas les API, les bases de données ou les services externes qui se trouvent en dessous. Un serveur MCP GitHub continue d’appeler l’API GitHub en arrière-plan. Un serveur MCP qui expose les données de votre CRM reste connecté à votre CRM. MCP est une infrastructure orientée modèle qui standardise la manière dont les applications d’IA atteignent ces systèmes sous-jacents, et non un remplacement de ces systèmes.
Outils, ressources et prompts : les trois éléments qu’expose un serveur MCP
Une idée reçue persistante veut que MCP soit simplement une meilleure manière de faire des appels de fonctions : exposer des outils que les LLM peuvent invoquer, point final. En réalité, le serveur expose trois types de capacités distincts, et les confondre conduit à sous-construire.
Les outils sont des fonctions exécutables. Le modèle peut les invoquer pour réaliser des actions : exécuter une requête, créer un enregistrement, envoyer un message, vérifier un statut. Ce sont les capacités auxquelles la plupart des personnes pensent immédiatement lorsqu’elles entendent parler d’« implémentations de serveurs MCP ».
Les ressources sont des données. Des fichiers, des lignes de base de données, du contenu structuré, de la documentation. Le modèle peut les lire pour alimenter son contexte. Les serveurs MCP peuvent également exposer des ressources qui évoluent au fil du temps, afin que le modèle reçoive un contexte actualisé plutôt que des instantanés obsolètes.
Les prompts sont des modèles contextuels : des structures de prompt prédéfinies que les serveurs MCP fournissent pour aider les modèles à interagir plus efficacement avec un système. Ils sont souvent négligés, mais c’est ainsi que les équipes encodent le contexte spécifique à un domaine dans la couche protocolaire, afin que le modèle n’ait pas à le redécouvrir à chaque session.
Ces trois éléments réunis font de MCP bien plus qu’un wrapper d’appel de fonctions. Le protocole est conçu pour fournir du contexte, et pas seulement pour exécuter des actions.
Comment fonctionnent les interactions MCP : JSON-RPC 2.0 et découverte dynamique
MCP fonctionne avec JSON-RPC 2.0, un protocole léger d’appel de procédure à distance qui utilise JSON pour l’encodage des messages. Chaque interaction MCP consiste en une requête et une réponse structurées, avec état tout au long d’une session, et une négociation des capacités au moment de la connexion.
La découverte dynamique est ce qui rend la métaphore de l’« USB-C » exacte au niveau architectural. Lorsqu’un client MCP se connecte à un serveur, il demande quelles capacités sont disponibles. Le serveur répond avec son ensemble de capacités actuel. Le modèle peut alors utiliser ces capacités sans avoir besoin de connaissances codées en dur sur ce que le serveur expose. Ajoutez un nouvel outil au serveur et le client le découvre lors de la prochaine connexion, sans mise à jour d’intégration nécessaire.
📊 En pratique :
Le mécanisme de découverte dynamique est la raison pour laquelle un seul client MCP peut se connecter simultanément à plusieurs serveurs et invoquer des capacités sur l’ensemble d’entre eux au cours d’une même session, sans nouvelle intégration personnalisée pour chacun. Un agent d’IA qui interroge GitHub, Jira et un CRM dans un workflow peut le faire via trois connexions à des serveurs MCP, toutes utilisant le même modèle de protocole. Le modèle ne gère pas trois interfaces. Il en utilise une seule.
MCP vs API : où se situe réellement la frontière
C’est la question que je vois revenir le plus souvent après que les équipes ont lu leur premier article explicatif sur MCP, et l’idée reçue est toujours la même : les gens supposent que MCP remplace les API. Ce n’est pas le cas. Il se place au-dessus d’elles.
Une API définit la manière dont un système spécifique reçoit des requêtes et renvoie des réponses. Elle est propre au système : l’API Salesforce est différente de l’API Stripe, elle-même différente de l’API GitHub, et elle est conçue pour des appelants déterministes qui savent exactement ce qu’ils demandent. Les API constituent la bonne abstraction pour faire communiquer des systèmes logiciels entre eux.
Le problème est que les agents LLM non déterministes ne fonctionnent pas comme des systèmes logiciels conventionnels. Ils ne savent pas toujours à l’avance de quelles capacités ils auront besoin. Ils prennent des décisions pendant l’exécution. Ils composent des appels d’outils dans des séquences qui n’étaient pas entièrement anticipées. L’intégration native API, qui suppose un appelant prévisible, devient rapidement fragile lorsque l’appelant est un modèle qui suit une chaîne de raisonnement en plusieurs étapes.
MCP complète cette couche API sous-jacente en se plaçant au-dessus d’elle, côté modèle. Un serveur MCP appelle l’API Salesforce en interne. Mais l’application d’IA accède à Salesforce via l’interface MCP, et non via une intégration API directe. MCP fournit une abstraction cohérente afin que le modèle n’ait pas besoin de connaître les spécificités de chaque API qu’il utilise : il se contente d’utiliser le protocole.
L’implication pratique est la suivante : l’intégration MCP ne remplace ni vos identifiants API, ni votre logique d’authentification, ni les contrôles d’accès à vos sources de données. Elle les abstrait du point de vue du modèle. L’API est toujours présente. La couche MCP est l’interface orientée modèle placée devant elle.
Ce que MCP permet que les appels de fonctions seuls ne peuvent pas faire
Les appels de fonctions permettent à un modèle d’invoquer une capacité spécifique dans un outil spécifique. C’est puissant pour les interactions avec un seul outil. En revanche, cela gère mal le contexte multi-systèmes : les situations où le modèle a besoin de contexte pertinent provenant d’une source, exécute une action sur une autre et utilise un modèle de prompt provenant d’une troisième, le tout au cours de la même session.
MCP propose un protocole unifié pour ces trois interactions simultanément. Il standardise non seulement l’invocation des outils, mais aussi l’accès aux ressources — des données actuelles issues de systèmes connectés — et les modèles de prompt — des structures contextuelles qui aident le modèle à raisonner correctement dans un domaine donné. Cette combinaison rend MCP adapté aux workflows d’IA sensibles au contexte qui couvrent plusieurs systèmes, contrairement aux appels de fonctions mono-outil qui s’arrêtent à la frontière d’une seule API.
MCP peut également compléter les appels de fonctions : les équipes utilisent déjà les deux conjointement, MCP gérant l’orchestration multi-systèmes et les appels de fonctions gérant des interactions spécifiques avec un seul système lorsqu’un appel API direct est plus adapté. Ils ne s’excluent pas mutuellement. La frontière du service externe est l’endroit où vous déterminez quelle abstraction convient le mieux.
MCP vs RAG : deux problèmes différents, souvent confondus
Je vois ces deux approches comparées comme si elles étaient concurrentes pour résoudre le même problème. Ce n’est pas le cas. Elles résolvent des problèmes différents à des niveaux différents, ce qui signifie que vous devez presque toujours réfléchir aux deux.
Le RAG, ou génération augmentée par récupération, est une stratégie au moment de l’inférence. Lorsqu’un modèle doit répondre à une question, un système RAG récupère les documents pertinents depuis une base de connaissances et les injecte dans la fenêtre de contexte avant que le modèle ne génère une réponse. Il s’agit d’apporter la bonne information dans le contexte du modèle au moment où il doit raisonner. La récupération s’effectue au moment de l’inférence, les documents sont injectés et le modèle les utilise.
MCP est un protocole. Il opère au niveau de la couche d’intégration, en standardisant la manière dont les systèmes d’IA se connectent aux outils, aux sources de données et au contexte, quelle que soit la stratégie de récupération utilisée en interne par ces connexions. Un serveur MCP qui expose un stockage de documents peut utiliser le RAG en interne pour fournir les segments pertinents. Il peut aussi ne pas l’utiliser. Le protocole s’en moque dans les deux cas.
MCP sert d’interface par laquelle un système d’IA accède à des ressources externes. Le RAG est une stratégie pour déterminer ce qui se produit lorsque vous accédez à une collection de documents. Les systèmes d’IA générative qui nécessitent à la fois un accès structuré aux outils et une récupération de documents utiliseront souvent MCP et RAG ensemble : MCP comme couche de connexion, RAG comme logique de récupération dans un ou plusieurs systèmes connectés.
L’assistant d’IA conversationnelle qui répond aux questions concernant votre base de connaissances interne illustre bien la collaboration entre les deux : MCP gère la connexion au stockage de documents, RAG gère ce qui en revient, et le modèle raisonne à partir du contexte qui arrive dans la fenêtre.
Confondre les deux conduit à sous-construire. Les équipes qui pensent « nous avons du RAG, donc nous n’avons pas besoin de MCP » se retrouvent avec une bonne récupération et des connexions fragiles. Les équipes qui pensent « nous avons MCP, donc nous n’avons pas besoin de concevoir une stratégie de récupération » se retrouvent avec des interfaces propres et une mauvaise qualité de contexte.
Cas d’usage MCP : où les équipes le déploient réellement
Comprendre MCP de façon abstraite est utile. Comprendre où les équipes le déploient réellement et pourquoi apporte autre chose : cela vous indique s’il convient au problème que vous examinez actuellement.
Je vois quatre modèles de déploiement récurrents dans l’écosystème actuel, chacun correspondant directement à une décision concrète d’équipe.
Environnements de développement propulsés par l’IA et agents de code
L’utilisation du Model Context Protocol dans les outils destinés aux développeurs est actuellement le cas d’usage le plus visible de l’écosystème. Des assistants de code IA comme Claude Desktop et Cursor utilisent MCP pour connecter les modèles aux référentiels, à la documentation, aux outils de suivi des incidents et au statut des pipelines CI/CD, simultanément et via une interface cohérente.
L’effet pratique est le suivant : un développeur qui demande à un assistant d’IA « qu’est-ce qui est cassé dans le dernier build et qu’est-ce qui a changé dans le fichier concerné ? » obtient une réponse provenant simultanément du système CI/CD et de l’historique des versions, sans que l’assistant ait besoin d’intégrations distinctes codées en dur pour chacun. L’assistant de programmation envoie la requête via le client MCP, les serveurs MCP disponibles répondent avec des données actuelles et le modèle raisonne à partir de celles-ci.
Les équipes qui construisent des agents d’IA pour les workflows de développement utilisent de plus en plus MCP comme couche de connectivité, précisément parce que la surface d’outils dans un environnement de développement est vaste : accès aux référentiels, lanceurs de tests, systèmes de documentation, outils de suivi des incidents — et que le problème M×N s’aggrave rapidement. MCP crée une base stable sous cette complexité afin que la logique de l’agent reste propre même lorsque les systèmes connectés se multiplient.
Agents d’IA d’entreprise connectés aux CRM, ERP et systèmes métiers
Pour les équipes d’entreprise qui construisent des agents d’IA devant interagir avec des systèmes opérationnels — CRM, ERP, plateformes RH, outils d’analyse — l’intégration MCP modifie considérablement le modèle de construction. Au lieu d’un connecteur sur mesure par système et par agent, l’équipe construit une fois un serveur MCP devant chaque système. Chaque agent d’IA qui a besoin d’accéder à ce système se connecte ensuite via le même serveur.
La valeur pour l’entreprise réside dans ce « une fois ». Permettez à des agents d’IA d’accéder à Salesforce via un serveur MCP, et chaque agent ultérieur ayant besoin de données Salesforce utilise la même connexion. Connectez des systèmes d’IA à SAP via un serveur MCP, et le travail d’intégration est réalisé au niveau du protocole, plutôt que séparément pour chaque nouvelle application d’IA.
J’ai vu des équipes opérationnelles décrire cela comme l’obtention, pour la première fois, d’une couche d’intégration partagée : une infrastructure qu’elles n’auraient pas pu justifier de construire sur mesure, mais que le modèle MCP rend accessible parce que le travail s’accumule dans le bon sens : chaque serveur créé est réutilisé, et non reconstruit.
Workflows de données et d’analytique avec accès gouverné aux serveurs MCP
Le cas d’usage de l’assistant analytique est celui où les implications de MCP en matière de contrôle d’accès deviennent les plus visibles. Une équipe souhaite permettre à un LLM d’interroger un entrepôt de données ou une plateforme d’analyse, mais elle ne veut pas d’un accès sans restriction ni que le modèle explore librement des données sensibles.
Un serveur MCP placé devant la source de données définit exactement quel contexte est exposé. Le serveur contrôle quelles requêtes peuvent être exécutées, quelles tables sont accessibles et quelle forme de réponse le modèle reçoit. Le workflow se connecte à cette surface définie, et non directement au stockage de données sous-jacent.
Le contrôle d’accès se situe au niveau de la couche serveur MCP. Il s’agit d’une décision de conception, et non d’une fonctionnalité produit incluse gratuitement — un point sur lequel je reviendrai dans la section consacrée à l’écosystème. Mais cette architecture rend l’accès gouverné aux données réalisable d’une manière que les connexions directes entre LLM et base de données ne permettent pas.
Le MCP Server Builder de Latenode est la composante de la plateforme vers laquelle j’oriente les équipes lorsque ce besoin se présente : créer un serveur MCP contrôlé qui définit ce que le modèle peut voir, sans nécessiter d’infrastructure personnalisée. L’approche qui consiste à définir d’abord une interface d’outils propre — déterminer ce que l’agent peut utiliser avant de le connecter à un environnement actif — est l’erreur de configuration que la plupart des équipes commettent, et c’est celle qui crée le ticket de support trois semaines plus tard.
Ce n’est pas hypothétique. C’est généralement là que le ticket commence.
L’écosystème MCP : adoption, frameworks et ce qui manque encore
La dynamique de l’écosystème autour de MCP est l’élément qui modifie l’évaluation des risques pour les équipes envisageant son adoption. OpenAI et Google DeepMind ont tous deux adopté le protocole aux côtés d’Anthropic, ce qui signifie que MCP n’est plus un standard à fournisseur unique : il devient une infrastructure fondamentale pour le développement de l’IA agentique dans les principaux laboratoires.
Des frameworks d’IA comme LangChain, LangGraph et LlamaIndex interagissent avec les serveurs MCP, ce qui signifie que la chaîne d’outils de construction des systèmes agentiques converge de plus en plus vers MCP comme couche de connexion. Des serveurs MCP préconfigurés pour des systèmes courants — GitHub, Slack, bases de données, systèmes de fichiers — s’accumulent dans les référentiels publics, réduisant le coût de construction des intégrations fréquentes.
Cela dit, l’écosystème présente de véritables lacunes que l’enthousiasme autour de l’adoption tend à masquer. Les comprendre avant de vous engager mérite les cinq minutes nécessaires.
Principaux adopteurs et importance de la dynamique de l’écosystème pour l’IA agentique
Lorsqu’un nouveau protocole n’est adopté que par son créateur, les équipes font face à un vrai risque d’infrastructure : que se passe-t-il si le créateur change de direction, si le standard se fragmente ou si la communauté ne se développe pas ? Ce risque est plus faible avec MCP qu’il ne l’était il y a douze mois.
L’adoption de MCP par OpenAI et Google DeepMind indique que le standard a franchi un seuil important : ce n’est plus seulement le protocole d’Anthropic. Lorsque plusieurs laboratoires d’IA s’engagent sur une interface partagée, les investissements de l’écosystème qui l’entoure — outils, documentation, serveurs préconfigurés, prise en charge par les frameworks — progressent de manière à bénéficier à toutes les personnes qui construisent sur ce standard.
Pour les équipes qui développent des systèmes d’IA agentique, cela a une importance pratique : MCP aide les agents d’IA à se connecter aux outils et aux données sans être lié à un fournisseur de modèles unique. Un agent construit aujourd’hui sur Claude peut accéder aux mêmes serveurs MCP qu’un agent construit demain sur GPT. Rendre les workflows d’IA portables entre les modèles devient un véritable objectif d’ingénierie à mesure que les préférences de modèles évoluent, et MCP soutient davantage cet objectif qu’une approche à fournisseur unique. Plusieurs agents d’IA au sein d’une même organisation peuvent partager l’infrastructure de serveurs MCP, ce qui fait fructifier l’investissement de construction au lieu de le multiplier.
Ce que MCP ne gère toujours pas : stratégie de récupération et contrôles d’accès
Voici ce que les explications bien intentionnées sur MCP minimisent souvent : le protocole standardise l’interface. Il ne conçoit pas ce qui se trouve derrière.
MCP ne prend pas les décisions de stratégie de récupération à votre place. Si votre serveur MCP expose une base de connaissances documentaire, quelqu’un doit toujours décider comment cette base est organisée, quelle stratégie de découpage elle utilise, comment son actualisation est maintenue et à quel moment les données obsolètes sont retirées. Les interactions MCP suivent un protocole défini. La qualité du contexte renvoyé par ces interactions dépend entièrement du travail de conception que vous avez réalisé côté serveur.
Les contrôles d’accès suivent la même logique. Un serveur MCP constitue un point potentiel d’exposition des données. Les données qu’il expose, les clients auxquels elles sont accessibles, les conditions applicables et la piste d’audit associée relèvent de la conception d’un système d’IA, et MCP n’apporte pas de réponse à ces questions. Le système externe sous-jacent peut disposer de ses propres contrôles d’accès. La couche serveur MCP peut en ajouter d’autres. Mais « j’ai un serveur MCP » n’est pas synonyme de « j’ai une couche d’accès aux données gouvernée ». Le travail de gouvernance reste à réaliser.
Un assistant d’IA se connectant à un serveur MCP qui expose un large stockage de données interne sans restrictions d’accès soigneusement conçues constitue une surface de sécurité, et pas seulement une surface d’intégration. Cela mérite d’être dit clairement avant la décision de construction, et non après la gestion d’un incident.
🤔 La question inconfortable :
Les équipes adoptent MCP pour réduire la complexité des intégrations. C’est réel. Mais chaque serveur MCP que vous connectez crée une nouvelle surface d’exposition des données qui passe désormais par des requêtes de protocole plutôt que par des intégrations examinées manuellement. La surface totale de gouvernance augmente en proportion directe du nombre de serveurs que vous connectez, et le protocole ne s’audite pas lui-même. Des connexions plus simples ne signifient pas moins de décisions de sécurité. Cela signifie que ces décisions doivent être prises quelque part de manière plus délibérée que dans le code d’intégration qu’elles ont remplacé.
