Données & outils
MCP en entreprise : à quoi sert ce protocole ?
Le Model Context Protocol (MCP) est un standard ouvert pour relier une application d'IA à des logiciels et à des données : un serveur MCP déclare ce que l'IA peut consulter et les actions qu'elle peut demander. Publié par Anthropic en novembre 2024, il relève depuis décembre 2025 d'une fondation rattachée à la Linux Foundation. Il simplifie le branchement, mais ne garantit pas la sécurité à lui seul : compte dédié, droits minimaux, validation humaine et journal restent à mettre en place.
Mis à jour le 9 min de lecture
Sommaire · 7 parties
Le MCP, c'est quoi ?
Le Model Context Protocol, ou MCP, est un standard ouvert. Il fixe une façon commune de relier une application d'IA aux systèmes où se trouvent les données : espaces documentaires, outils métier, environnements de développement. Anthropic, l'éditeur de l'assistant Claude, l'a publié en open source le 25 novembre 2024, avec sa spécification et des kits de développement.
Il répond à un problème d'intégration. Jusque-là, chaque nouvelle source de données demandait sa propre connexion, développée sur mesure. Avec MCP, un logiciel est exposé une fois, par un serveur MCP, puis toute application d'IA compatible peut s'y connecter. L'objectif annoncé par Anthropic : remplacer des intégrations fragmentées par un protocole unique.
MCP standardise la connexion, pas le reste. Il ne décide ni des données à exposer, ni des droits à accorder, et il ne corrige pas une base remplie de doublons : une information fausse reste fausse, même transmise par un protocole standard.
MCP dépend-il d'un seul éditeur ?
Non. MCP est l'un des trois projets fondateurs de l'Agentic AI Foundation (AAIF), une fondation consacrée aux agents d'IA. La Linux Foundation, organisation à but non lucratif qui héberge notamment les projets Linux et Kubernetes, en a annoncé la création le 9 décembre 2025. Anthropic a apporté MCP à l'AAIF, aux côtés de projets de Block et d'OpenAI. Objectif affiché par Anthropic : que le protocole reste ouvert, neutre et piloté par sa communauté, avec un modèle de gouvernance inchangé. Les décisions techniques reviennent aux mainteneurs du projet, désignés à titre individuel : aucun siège n'est réservé à une entreprise.
Amazon Web Services, Google, Microsoft et OpenAI comptent parmi les membres de l'AAIF. Selon la Linux Foundation, le protocole est adopté par ChatGPT, Gemini, Microsoft Copilot et Visual Studio Code, en plus de Claude. Un serveur MCP n'est donc pas lié à un seul assistant.
La spécification évolue par révisions identifiées par une date. Cette date ne change que lorsqu'une modification rompt la compatibilité avec la version précédente. À la date de cet article, la révision actuelle est celle du 28 juillet 2026. Elle a supprimé l'échange d'initialisation entre client et serveur, et programmé le retrait de plusieurs fonctionnalités, pas avant le 28 juillet 2027. Un serveur MCP doit donc être maintenu, comme n'importe quel logiciel.
Que peut en faire une PME ?
Une PME peut donner à un assistant ou à un agent un accès cadré à ses logiciels : lire des informations, préparer ou exécuter des actions, dans le périmètre que déclare le serveur.
Le protocole ne dispense pas du travail préalable : choisir les données utiles, corriger les doublons, définir les droits. Chez OMEGA, c'est la partie Connecter de chaque projet : relier les systèmes, fiabiliser les données, gérer les accès. Quelques usages types, en commençant par la lecture :
- Dans le CRM, le logiciel de gestion de la relation client : lire l'historique d'un compte avant un rendez-vous, puis proposer la mise à jour de la fiche.
- Dans l'ERP, le progiciel de gestion intégré : consulter l'état d'une commande ou le stock d'un article, en lecture seule pour commencer.
- Dans les documents : rendre consultables, comme ressources, les procédures ou les contrats d'un service, dans la limite des droits de la personne qui pose la question.
- Pour les tâches répétées : partager un prompt qui prépare un compte rendu ou une réponse type, plutôt que de laisser chacun réécrire sa consigne.
MCP, API directe ou connecteur sans code : que choisir ?
Tout dépend de qui décide de l'action. Si l'enchaînement est connu d'avance, une API appelée par un programme ou un connecteur sans code suffit, et reste plus prévisible. MCP se justifie quand une application d'IA doit choisir elle-même entre plusieurs actions : le modèle découvre les outils déclarés par le serveur, lit leur description et choisit lequel appeler.
La mise en place diffère aussi. Une API directe demande un développement pour chaque intégration, réservé à l'application qui l'appelle. Elle donne accès à ce que l'éditeur expose, dans la limite des droits du compte, et convient à un enchaînement fixe et répétitif. Un connecteur sans code se configure sans développement, mais reste lié à sa plateforme et aux actions prévues par son éditeur : il sert aux enchaînements simples entre outils courants. Un serveur MCP s'installe ou se développe, puis se maintient. Il sert à plusieurs applications d'IA compatibles et n'expose que les outils, ressources et prompts qu'il déclare. Les trois se combinent : les outils d'un serveur MCP peuvent appeler l'API du logiciel.
| Critère | Serveur MCP | API directe | Connecteur sans code |
|---|---|---|---|
| Qui décide de l'action | Le modèle, parmi les outils déclarés par le serveur. | Le programme, selon ce que le développeur a écrit. | L'enchaînement configuré dans la plateforme. |
| Mise en place | Un serveur à installer ou à développer, puis à maintenir. | Un développement pour chaque intégration. | Une configuration, sans développement. |
| Réutilisation | Un même serveur sert à plusieurs applications d'IA compatibles. | Propre à l'application qui l'appelle. | Liée à la plateforme qui fournit le connecteur. |
| Périmètre accessible | Les outils, ressources et prompts déclarés par le serveur. | Ce que l'API expose, dans la limite des droits du compte. | Les actions prévues par l'éditeur du connecteur. |
| Adapté pour | Une application d'IA qui choisit entre plusieurs actions. | Un enchaînement fixe et répétitif. | Un enchaînement simple entre outils courants. |
Quels sont les risques ?
Trois risques se cumulent : l'injection de prompt, les serveurs non vérifiés et les droits trop larges. Dans un scénario décrit par l'OWASP, fondation à but non lucratif consacrée à la sécurité des logiciels, un e-mail piégé pousse un assistant de messagerie à transférer des informations sensibles. L'assistant ne devait que lire, mais savait aussi envoyer.
- L'injection de prompt (LLM01), en tête du Top 10 2025 de l'OWASP sur les applications de grands modèles de langage (LLM) : des consignes cachées dans un e-mail, un document ou la réponse d'un outil détournent le modèle. Selon l'OWASP, on ne sait pas s'il existe une parade infaillible.
- Les serveurs non vérifiés : un serveur local exécute du code sur vos postes, un serveur distant reçoit vos données. Le modèle lit le nom et la description de chaque outil : un serveur peut y glisser des consignes qui orientent l'agent, jusque dans l'usage des outils d'autres serveurs, et modifier ces descriptions après votre accord. La spécification tient pour non fiable la description d'un outil venue d'un serveur qui n'est pas de confiance. L'Agence nationale de la sécurité des systèmes d'information (ANSSI) recommande d'évaluer le niveau de confiance des modules externes d'un système d'IA.
- Les droits trop larges, que l'OWASP nomme « Excessive Agency » (LLM06), soit une agentivité excessive : des fonctions, des permissions ou une autonomie qui dépassent le besoin. Exemple type : un outil censé lire une base, connecté avec un compte qui peut aussi modifier et supprimer.
Quelles protections mettre en place ?
Imposez les limites dans les droits et dans les outils, pas seulement dans les consignes du modèle : la spécification reconnaît que le protocole ne peut pas faire respecter seul ses principes de sécurité.
Pour un serveur distant, elle décrit une autorisation fondée sur OAuth 2.1, la version en cours de normalisation du protocole d'autorisation OAuth : jetons d'accès émis pour ce seul serveur, droits demandés au plus juste. Ce mécanisme reste facultatif : vérifiez-le pour chaque serveur.
- Un compte dédié : jamais un compte administrateur, ni celui d'un salarié. Si l'agent agit au nom d'une personne, il n'a pas plus de droits qu'elle.
- Des permissions minimales, en lecture seule au départ. L'ANSSI recommande de revoir ces droits dès l'activation, puis régulièrement, par exemple tous les mois.
- Des outils déclarés et étroits, chacun limité à une action précise, plutôt qu'un outil générique capable de tout faire. Relisez leur description avant la mise en service, préférez une application qui redemande votre accord quand une description change, et branchez le moins de serveurs possible.
- Une validation humaine avant toute action irréversible, comme un paiement ou une suppression. La spécification recommande qu'une personne puisse toujours refuser l'appel d'un outil ; l'ANSSI, qu'un système d'IA ne puisse pas exécuter seul une action critique.
- Un journal de chaque appel d'outil : la demande, le compte utilisé, le résultat. La spécification le recommande pour l'audit, l'ANSSI aussi.
Sources
- Anthropic, « Introducing the Model Context Protocol », 25 novembre 2024 (nouvel onglet)
- The Linux Foundation, annonce de la création de l'Agentic AI Foundation (AAIF), 9 décembre 2025 (nouvel onglet)
- Model Context Protocol : spécification officielle, révision du 28 juillet 2026 (architecture, transports, autorisation, outils) (nouvel onglet)
- OWASP Top 10 for LLM Applications 2025 : LLM01, Prompt Injection (nouvel onglet)
- OWASP Top 10 for LLM Applications 2025 : LLM06, Excessive Agency (nouvel onglet)
- ANSSI, « Recommandations de sécurité pour un système d'IA générative », avril 2024 (R3, R9, R29, R35) (nouvel onglet)
Avant tout chiffrage, nous partons de vos outils et de vos priorités.
Commencer le diagnostic
03
Comment fonctionne MCP ?
MCP distingue trois rôles. L'hôte est l'application d'IA utilisée : un assistant, un agent, un outil de développement. Il crée un client pour chaque serveur auquel il se connecte. Le serveur donne accès à un système, comme un dossier de fichiers, une base de données ou un logiciel métier.
Un serveur peut être local : il tourne sur la même machine que l'application, qui le lance elle-même (transport « stdio », pour entrées-sorties standard). Il peut aussi être distant : c'est alors un service accessible par le réseau en HTTP, le protocole du web, qui sert en général de nombreux clients (transport « Streamable HTTP »).
Le serveur peut proposer trois types d'éléments, dont le client obtient la liste sur demande :