- Le protocole MCP (Model Context Protocol) est un standard ouvert publié par Anthropic en novembre 2024 pour relier les modèles et les agents IA à vos outils, vos données et vos services.
- Son principe : un outil expose ses fonctions une seule fois via un serveur MCP, et tout agent compatible peut s’y brancher. C’est une brique naturelle d’un projet d’automatisation IA.
- Ce n’est pas un sujet d’outil, mais un sujet d’architecture : un serveur mal maîtrisé devient une porte d’entrée sur votre système d’information.
- Avant d’ouvrir vos outils internes à un serveur MCP, passez une grille de vérification : sécurité, authentification, RGPD, maturité.
- Chez IA Agency, nous accompagnons cette évaluation, du diagnostic de faisabilité à l’intégration gouvernée.
Un connecteur entre une IA et vos logiciels, ce n’est plus un développement sur mesure à refaire pour chaque outil. Depuis fin 2024, un standard unique suffit à exposer les fonctions d’un système, et tout agent compatible vient s’y brancher.
Prenons un dirigeant de PME qui veut relier son assistant IA à son CRM, à son ERP et à sa base clients interne. Hier, chaque liaison réclamait un projet distinct, un développement propre à chaque couple assistant et outil. Le résultat était lourd, coûteux, et fragile au premier changement de modèle.
Le protocole MCP change cette donne. Il standardise la façon dont un agent IA accède à un outil, et il réduit la dette d’intégration qui freinait les projets d’automatisation IA. Mais cette facilité déplace le risque : un serveur MCP ouvert sans contrôle devient un point d’accès sur des données sensibles. La bonne question n’est donc pas « faut-il l’adopter », mais « à quelles conditions le faire sans exposer votre système d’information ». Cet article pose la grille de vérification à passer avant toute mise en production.
Le protocole MCP, c'est quoi exactement ?
Le protocole MCP, ou Model Context Protocol, est un standard ouvert qui décrit comment un modèle ou un agent IA se relie à des outils, des données et des services externes via une interface structurée. Il a été introduit par Anthropic en novembre 2024, en open source, puis adopté par d’autres éditeurs. Son ambition est simple : donner aux agents un moyen unique et prévisible d’agir sur le monde réel, au lieu d’un empilement d’intégrations propriétaires.
L’image la plus parlante est celle de l’USB-C de l’IA. Un port unique supprime la collection de câbles spécifiques à chaque appareil. De la même manière, un outil expose ses fonctions une fois via le protocole MCP, et n’importe quel agent compatible peut les utiliser sans réécriture. C’est précisément ce que met en place une agence IA lorsqu’elle outille un assistant pour qu’il agisse dans vos processus, plutôt que de se contenter de répondre en texte.
Un serveur MCP peut exposer plusieurs types de capacités. Voici ce qu’il donne à un agent :
- l’accès à des sources de données internes (une base clients, un catalogue produits, un espace documentaire) ;
- des actions sur des systèmes métier (créer une fiche dans un CRM, lancer une recherche dans un ERP, envoyer une requête à une API) ;
- des ressources partagées entre plusieurs agents, comme des gabarits d’instructions réutilisables.
Ce niveau d’accès est aussi le cœur du sujet de sécurité : donner à une IA le droit d’agir dans vos outils est une décision d’architecture, pas un réglage. La brique existe pour rendre vos agents IA réellement utiles au sein de l’entreprise, à condition d’en encadrer le périmètre.
Prenons un dirigeant qui veut brancher son assistant IA sur son CRM, son ERP et sa base clients interne. Hier, chaque liaison réclamait un projet distinct, un développement propre à chaque couple assistant et outil. Le protocole MCP change cette donne : chaque outil expose ses fonctions une seule fois, et l'assistant s'y branche sans réécriture. La dette d'intégration qui bloquait le passage en production fond, à condition d'ouvrir chaque serveur sous contrôle et en commençant par la lecture seule.
Comment fonctionne le protocole MCP ?
Le protocole MCP repose sur une architecture à trois rôles : le client, le serveur et le host. Chacun a une responsabilité précise, et les distinguer est la clé pour comprendre où se situe le risque.
Client, serveur, host : qui fait quoi ?
- Le client MCP vit dans l’assistant IA lui-même (un logiciel de bureau, un assistant conversationnel, un environnement de développement). Il émet les demandes de l’agent.
- Le serveur MCP expose les fonctions d’un système externe : il traduit les demandes de l’agent en opérations réelles sur un outil, une base de données ou une API.
- Le host est l’application qui orchestre l’ensemble, relie le client au bon serveur et applique les règles d’accès de l’utilisateur.
La communication entre ces rôles s’appuie sur le format JSON-RPC, un échange structuré de messages. Deux modes de transport coexistent selon le contexte : STDIO, pour un serveur qui tourne en local sur la même machine que l’agent, et HTTP avec SSE, pour un serveur accessible à travers le réseau. Le second mode ouvre davantage de possibilités, mais élargit aussi la surface exposée : un serveur atteignable sur le réseau doit être authentifié.
Le protocole définit trois primitives, c’est-à-dire les briques que chaque serveur peut proposer :
- Les tools : des opérations que l’agent peut appeler pour agir (interroger, écrire, déclencher un traitement).
- Les resources : l’accès aux données, souvent en lecture seule au départ, pour nourrir le contexte du modèle.
- Les prompts : des gabarits d’instructions partagés, réutilisables d’un agent à l’autre.
À lire également : Qu’est-ce qu’un agent IA ?
« La vraie question n'est pas de savoir si le protocole MCP convient à votre entreprise, mais de savoir qui contrôle ce que chaque serveur a le droit de faire une fois branché sur votre système. Un serveur sans périmètre défini, c'est une porte ouverte que personne ne surveille. »
Quand on audite un projet MCP, on trouve presque toujours un serveur tiers installé sans vérification, ou un serveur d'écriture branché sur un outil sensible sans journalisation. Le réflexe qui protège n'est pas technique, il est méthodique : traiter chaque sortie de serveur comme non fiable, n'ouvrir que ce qui sert un cas d'usage réel, et garder une trace de tout. C'est peu spectaculaire, mais c'est ce qui évite les mauvaises surprises.
Ce que le protocole MCP change par rapport aux intégrations sur mesure
Avant le protocole MCP, chaque liaison entre un assistant et un outil demandait son propre connecteur. Dix assistants et dix outils pouvaient exiger jusqu’à cent développements distincts, chacun à entretenir. Cette dette d’intégration expliquait pourquoi tant de projets IA restaient au stade de la démonstration : le coût de mise en production dépassait la valeur perçue.
Avec le protocole MCP, l’outil est exposé une seule fois. Le modèle et l’intégration sont découplés : changer d’assistant IA ne demande plus de réécrire les connecteurs, puisque le serveur reste le même. La gouvernance, dispersée hier chez chaque fournisseur, peut se centraliser à travers une passerelle unique. Les plateformes d’orchestration d’outils jouent d’ailleurs bien avec cette logique : un projet monté sur une agence Make ou un environnement équivalent trouve dans le protocole un langage commun pour ses connexions.
Le tableau ci-dessous résume ce déplacement.
| Critère | Intégrations sur mesure (avant) | Avec le protocole MCP |
|---|---|---|
| Connecteurs | 1 par couple assistant et outil | 1 serveur exposé, réutilisé par tout agent compatible |
| Changer de modèle IA | Réécrire les connecteurs | Découplage modèle et intégration |
| Gouvernance | Dispersée par fournisseur | Centralisable via une passerelle MCP |
| Dette d’entretien | Élevée | Mutualisée |
Une précision utile : le protocole MCP ne prend pas la place des API classiques. Il les standardise pour les agents IA, en posant une couche commune au-dessus de systèmes qui gardent leurs propres interfaces. Vos API restent la source de vérité ; le protocole leur donne un point d’entrée uniforme pour les agents.
Le plus grand risque n'est pas le protocole lui-même, mais la précipitation. Un serveur d'écriture branché sur un outil critique sans validation humaine, sans journalisation et sans limite de débit peut agir en masse avant qu'une alerte ne remonte. Traitez chaque ouverture d'action comme une décision d'architecture, pas comme un réglage rapide.
Qui utilise déjà le protocole MCP ?
L’adoption s’est étendue rapidement au cours de 2025 et 2026. Le protocole a quitté le statut de proposition d’un seul éditeur pour devenir un point de convergence entre plusieurs acteurs majeurs. Voici les principaux environnements qui le prennent en charge :
- Anthropic et son assistant Claude, avec un support natif dès l’origine ;
- OpenAI côté ChatGPT, qui a intégré le protocole dans son écosystème ;
- Google côté Gemini, dans la même logique d’interopérabilité ;
- de nombreux environnements de développement, où les serveurs MCP donnent aux agents l’accès aux dépôts et aux outils projet ;
- le gouvernement français, qui a adopté le protocole pour brancher des assistants IA sur des bases et des outils administratifs, selon les communications publiques sur le sujet.
Cette convergence est réelle, mais un chiffre doit être manié avec prudence. Selon un rapport d’analyste, le protocole atteindrait 78 % d’adoption en entreprise. Cette donnée provient d’une source unique et ne doit pas être présentée comme un fait établi : elle indique une tendance forte, pas une mesure consolidée. Côté usage grand public, les assistants et les chatbot IA sur mesure déployés en support client s’appuient de plus en plus sur ce type de connexion pour aller chercher une information dans un outil métier au moment de répondre.
« L'erreur des équipes pressées, c'est d'ouvrir l'écriture avant d'avoir gouverné la lecture. On commence en lecture seule, on journalise tout, et on n'accorde le droit d'agir qu'une fois la surveillance en place. Cet ordre n'est pas négociable. »
Obtenez votre devis personnalisé
La grille de vérification avant d'adopter le protocole MCP
C’est ici que se joue la valeur d’un projet. Le protocole MCP est un standard sérieux, mais sa sécurité dépend de la rigueur de son intégration. Une nouvelle spécification publiée fin juin 2026 déplace d’ailleurs une part de la responsabilité de sécurité vers les équipes qui implémentent : autrement dit, le cadre vous outille, mais il ne décide pas à votre place. Voici les cinq dimensions à instruire avant toute mise en production.
Sécurité et surface d’attaque des serveurs MCP
Chaque serveur MCP ajouté agrandit la surface exposée. Les incidents documentés le confirment. La faille CVE-2025-6514, notée 9,6 sur l’échelle CVSS, permettait une injection de commandes via un composant de connexion distant très diffusé, téléchargé environ 437 000 fois. La faille CVE-2025-52882, notée 8,8, visait des extensions d’agents de code exposant des serveurs WebSocket sans authentification. Un serveur ajouté à la légère devient une entrée dans votre système.
Authentification et contrôle d’accès
Une couche d’autorisation de type OAuth 2.1 a été ajoutée au protocole en juin 2025. Elle doit être la règle : tout serveur MCP en production s’authentifie, et les autorisations suivent le principe du moindre privilège. Un agent qui a besoin de lire une donnée n’a pas à disposer d’un droit d’écriture. Le contrôle d’accès par rôle, appliqué côté système d’information, complète ce garde-fou.
Injection d’instructions et tool poisoning
Une menace propre aux agents mérite l’attention : le tool poisoning. Une instruction malveillante peut être glissée dans la description d’un outil ou dans une donnée renvoyée par un serveur, puis exécutée par le modèle comme si elle venait de vous. La règle de défense est claire : toute sortie d’un serveur MCP doit être traitée comme non fiable par défaut, et validée avant d’entrer dans le contexte du modèle.
Chaîne d’approvisionnement des serveurs
Les serveurs MCP sont souvent des paquets tiers. L’incident du paquet npm postmark-mcp, compromis pour détourner des e-mails, illustre le risque : une dépendance non vérifiée installée en production peut agir contre vous. Les serveurs et les paquets doivent être audités, signés, et suivis dans le temps.
Gouvernance des données et RGPD
Dès qu’un serveur donne accès à des données clients ou salariés, le RGPD s’applique. Il faut cartographier les données personnelles qui transitent, journaliser les accès, et vérifier le lieu d’hébergement, idéalement dans l’Union européenne. Une étude portant sur 2 614 implémentations MCP a relevé qu’environ 82 % présentaient des vulnérabilités d’opérations sur fichiers, et que 38 à 41 % fonctionnaient sans authentification. Ce constat, à considérer avec le recul d’usage propre à ce type d’étude, montre l’écart entre le potentiel du standard et la réalité des déploiements. C’est le point où un audit de gouvernance des données doit précéder toute ouverture, et où l’accompagnement d’une agence spécialisée fait la différence.
Maturité et dépendance
Enfin, la maturité. Un serveur reste-t-il portable entre plusieurs assistants IA, ou dépend-il d’une extension propriétaire non documentée ? La réponse détermine votre exposition au verrouillage fournisseur. Un standard ouvert protège de ce risque, à condition de choisir des implémentations qui en respectent l’esprit.
Voici la grille de questions à instruire, dans l’ordre, avant d’ouvrir un serveur MCP à vos outils :
- Quel serveur MCP, exposant quelles fonctions, sur quel outil, et pour répondre à quel besoin précis ?
- Le serveur est-il authentifié (OAuth 2.1 ou SSO) et atteignable uniquement par les agents autorisés ?
- Les autorisations suivent-elles le moindre privilège, en commençant par la lecture seule ?
- Les sorties du serveur sont-elles validées avant d’entrer dans le contexte du modèle ?
- Le paquet ou le serveur est-il audité, signé et suivi dans le temps ?
- Sait-on quelles données personnelles transitent, où elles sont hébergées, et sont-elles journalisées ?
- Le serveur reste-t-il portable entre plusieurs assistants, sans dépendance propriétaire ?
Le second tableau met en regard chaque dimension avec la question à poser et le signal qui doit vous alerter.
| Dimension | Question à poser | Signal d’alerte |
|---|---|---|
| Authentification | Chaque serveur en production est-il authentifié (OAuth 2.1 / SSO) ? | Serveur ouvert sans authentification |
| Accès aux données | Les autorisations suivent-elles le moindre privilège ? | Portée d’accès trop large pour une simple lecture |
| Injection d’instructions | Les sorties d’outils sont-elles validées avant d’entrer dans le contexte du modèle ? | Sortie de serveur traitée comme fiable par défaut |
| Chaîne d’approvisionnement | Les serveurs et paquets MCP sont-ils audités et signés ? | Dépendance non vérifiée installée en production |
| RGPD et gouvernance | Sait-on quelles données personnelles transitent, et sont-elles journalisées ? | Aucune cartographie des flux de données |
| Maturité et dépendance | Le serveur reste-t-il portable entre plusieurs assistants IA ? | Dépendance à une extension propriétaire non documentée |
Pour en savoir plus : Vos agents IA dépendent-ils trop d’un seul fournisseur d’IA ?
Comment déployer le protocole MCP sans vous exposer ?
La bonne approche est progressive. Elle consiste à ouvrir le moins possible au départ, puis à élargir seulement une fois la surveillance en place. Voici les étapes à suivre, dans l’ordre :
- Auditer les cas d’usage : identifier les besoins où un accès aux données apporte une valeur mesurable, et écarter les autres.
- Ouvrir un premier serveur en lecture seule, authentifié, sur un périmètre étroit et bien délimité.
- Centraliser via une passerelle MCP : un point de passage unique qui applique l’authentification, la journalisation et le contrôle de débit.
- Ouvrir des actions en écriture avec validation humaine, une fois la surveillance éprouvée, et seulement là où le bénéfice le justifie.
Cette montée en charge est aussi une montée en compétence. Chaque étape valide un garde-fou avant de passer à la suivante. Une alternative d’orchestration comme une agence n8n peut servir de passerelle intermédiaire pour journaliser et filtrer les appels avant qu’ils n’atteignent vos systèmes critiques.
À découvrir absolument : Gouvernance des agents IA : par où commencer pour garder le contrôle en entreprise ?
Pourquoi confier votre projet MCP à IA Agency ?
IA Agency accompagne les entreprises françaises dans l’évaluation et l’intégration du protocole MCP. Notre rôle n’est pas de vous vendre un outil, mais d’objectiver une décision d’architecture : audit de faisabilité, choix des serveurs, cadre d’authentification, gouvernance des données et RGPD. Nous partons de vos cas d’usage réels et de votre système d’information existant, pas d’une démonstration séduisante.
Notre méthode reprend la grille présentée ici, appliquée à votre contexte : premier serveur en lecture seule, passerelle centralisée, ouverture des actions en écriture sous validation humaine. L’objectif est d’obtenir des agents utiles, branchés sur vos outils, sans transformer cette connexion en risque pour votre système.
Conclusion
Le protocole MCP est un vrai standard d’architecture, pas un effet de mode. Il réduit la dette d’intégration qui bloquait les projets IA et rend vos agents capables d’agir dans vos outils. Mais sa valeur dépend entièrement de la rigueur de son intégration : un serveur mal maîtrisé devient une porte ouverte, un serveur bien gouverné devient un levier.
La question à trancher n’est donc pas « faut-il l’adopter », mais « à quelles conditions ». Passez la grille de vérification, commencez en lecture seule, gouvernez avant d’ouvrir. Demandez votre audit IA gratuit pour objectiver ce que le protocole MCP peut apporter à votre entreprise, et à quelles conditions le faire en sécurité.
Qu'est-ce que le protocole MCP (Model Context Protocol) ?
Le protocole MCP, ou Model Context Protocol, est un standard ouvert qui décrit comment un agent IA se relie à des outils, des données et des services externes. Publié par Anthropic en novembre 2024, il permet à un outil d’exposer ses fonctions une seule fois pour que tout agent compatible puisse les utiliser, sans développement propre à chaque liaison.
Qui a créé le protocole MCP et quand ?
Le protocole MCP a été créé par Anthropic, l’éditeur de l’assistant Claude, et publié en novembre 2024 en open source. Il a ensuite été adopté par d’autres acteurs majeurs, dont OpenAI côté ChatGPT et Google côté Gemini, ce qui en a fait un point de convergence entre plusieurs écosystèmes IA plutôt qu’un standard propre à un seul éditeur.
Le protocole MCP est-il gratuit et open source ?
Oui, le protocole MCP est un standard ouvert et open source depuis sa publication par Anthropic en novembre 2024. Sa spécification est librement accessible et implémentable par n’importe quel éditeur. Cette ouverture limite le risque de verrouillage fournisseur, à condition de choisir des serveurs qui respectent la spécification plutôt que des extensions propriétaires non documentées.
Quelle est la différence entre un client MCP et un serveur MCP ?
Le client MCP vit dans l’assistant IA et émet les demandes de l’agent ; le serveur MCP expose les fonctions d’un système externe et traduit ces demandes en opérations réelles sur un outil ou une base de données. Le client demande, le serveur exécute. Une troisième pièce, le host, orchestre l’ensemble et applique les règles d’accès.
Le protocole MCP se substitue-t-il aux API classiques ?
Non, le protocole MCP ne prend pas la place des API classiques : il les standardise pour les agents IA. Vos API restent la source de vérité et gardent leurs propres interfaces. Le protocole ajoute au-dessus une couche commune, qui donne aux agents un point d’entrée uniforme au lieu d’un connecteur spécifique à réécrire pour chaque outil.
Quels éditeurs et assistants IA supportent le protocole MCP ?
Le protocole MCP est pris en charge par Anthropic et son assistant Claude en natif, par OpenAI côté ChatGPT, par Google côté Gemini, ainsi que par de nombreux environnements de développement. Le gouvernement français l’a également adopté pour brancher des assistants IA sur des outils administratifs, selon les communications publiques disponibles sur le sujet.
Le protocole MCP est-il sécurisé pour une entreprise ?
Le protocole MCP peut être sécurisé, mais sa sécurité dépend de son intégration, pas du standard seul. Des failles documentées comme CVE-2025-6514 (notée 9,6 sur l’échelle CVSS) rappellent que chaque serveur ajouté agrandit la surface exposée. Un usage sûr repose sur l’authentification, le moindre privilège et la validation des sorties avant toute mise en production.
Comment authentifier l'accès des agents IA aux données via MCP ?
Une couche d’autorisation de type OAuth 2.1 a été ajoutée au protocole MCP en juin 2025 et doit être appliquée à tout serveur en production. Chaque serveur s’authentifie, et les autorisations suivent le principe du moindre privilège : un agent qui lit une donnée ne dispose pas d’un droit d’écriture. Le contrôle d’accès par rôle, côté système d’information, renforce ce cadre.
Qu'est-ce qu'un tool poisoning via un serveur MCP ?
Le tool poisoning est une attaque où une instruction malveillante est glissée dans la description d’un outil ou dans une donnée renvoyée par un serveur MCP, puis exécutée par le modèle comme si elle venait de l’utilisateur. La défense consiste à traiter toute sortie de serveur comme non fiable par défaut et à la valider avant qu’elle n’entre dans le contexte du modèle.
Le protocole MCP est-il compatible avec le RGPD ?
Le protocole MCP peut être compatible avec le RGPD, à condition d’encadrer les flux de données. Dès qu’un serveur donne accès à des données personnelles, il faut cartographier ces flux, journaliser les accès et vérifier le lieu d’hébergement, idéalement dans l’Union européenne. Le protocole ne garantit pas la conformité à lui seul : elle dépend de votre gouvernance des données.
Faut-il commencer par un serveur MCP en lecture seule ?
Oui, commencer par un serveur MCP en lecture seule est la meilleure approche. Cela permet d’apporter de la valeur, comme nourrir un assistant avec une donnée métier, tout en limitant le risque au minimum. Les actions en écriture, plus sensibles, ne s’ouvrent qu’ensuite, sous validation humaine et une fois la journalisation et la surveillance éprouvées.
Qu'est-ce qu'une passerelle (gateway) MCP et à quoi sert-elle ?
Une passerelle MCP est un point de passage unique par lequel transitent les échanges entre les agents et les serveurs. Elle centralise l’authentification, la journalisation et le contrôle de débit, là où ces règles étaient dispersées chez chaque fournisseur. Elle sert à gouverner l’ensemble depuis un seul endroit, ce qui simplifie l’audit et la surveillance des accès.
Le protocole MCP est-il assez mature pour la production ?
Le protocole MCP est utilisable en production, mais avec des précautions. Une nouvelle spécification publiée fin juin 2026 déplace une part de la responsabilité de sécurité vers les équipes qui implémentent. La maturité dépend donc de vos choix : serveurs audités, authentification systématique et ouverture progressive. Un déploiement sans ces garde-fous reste risqué, quelle que soit la solidité du standard.
Le protocole MCP crée-t-il une dépendance (lock-in) à un fournisseur d'IA ?
En principe, non : le protocole MCP est un standard ouvert conçu pour découpler le modèle de l’intégration, ce qui permet de changer d’assistant sans réécrire les serveurs. Le risque de verrouillage réapparaît si vous choisissez des extensions propriétaires non documentées. Le critère de portabilité, c’est-à-dire la capacité d’un serveur à fonctionner avec plusieurs assistants, protège de cette dépendance.
Quelle différence entre un serveur MCP local et un serveur distant ?
Un serveur MCP local tourne sur la même machine que l’agent et communique via le transport STDIO, ce qui limite l’exposition. Un serveur distant est atteignable à travers le réseau via HTTP et SSE, ce qui élargit les possibilités mais aussi la surface d’attaque. Un serveur distant doit toujours être authentifié, alors qu’un serveur local reste confiné à son environnement.
Par Geoffrey Lamri, fondateur d’IA Agency. Article mis à jour le 24 août 2026.
Ressources et liens utiles
[2] “Specification”, Model Context Protocol, 2026
[3] “Model Context Protocol”, Wikipédia, 2026
[4] “MCP Security Cheat Sheet”, OWASP, 2026
[5] “Model Context Protocol : risques de sécurité et contrôles”, Red Hat, 2026
[6] “MCP Security”, CISA / NSA, juin 2026
Adopter le protocole MCP ?
Cas d'usage, serveurs, authentification, RGPD : nous objectivons la décision avant l'ouverture.
Demander mon audit IA →
