Qu’est-ce que le Model Context Protocol (MCP) — et pourquoi est-il important pour la sécurité des données en entreprise

Si votre organisation déploie des assistants IA — ou prévoit de le faire — vous allez rencontrer le Model Context Protocol (MCP). MCP est la nouvelle norme qui définit comment des outils d’IA comme Claude et Microsoft Copilot se connectent aux systèmes d’entreprise : référentiels de fichiers, bases de connaissances, bases de données et applications métier.

En résumé, c’est la plomberie qui rend l’IA utile dans un contexte professionnel. Et comme toute plomberie, elle reste invisible quand tout fonctionne, mais peut provoquer des catastrophes en cas de défaillance. Pour les CIO, directeurs IT et VP AI, MCP n’est pas un simple détail technique réservé aux développeurs. C’est une décision de gouvernance des données IA qui détermine si le déploiement d’IA dans votre organisation sera sécurisé, conforme et traçable — ou rien de tout cela.

Résumé Exécutif

À retenir : Le Model Context Protocol s’impose rapidement comme l’interface standard pour connecter les assistants IA aux données et systèmes d’entreprise. La façon dont une organisation met en œuvre MCP — et si cette mise en œuvre intègre une gouvernance adaptée à l’entreprise — détermine si l’adoption de l’IA crée de la valeur ou génère des risques.

Pourquoi c’est important : La plupart des implémentations MCP sur le marché aujourd’hui sont conçues pour la facilité des développeurs, pas pour la gouvernance d’entreprise. Les organisations qui déploient des intégrations MCP sans gouvernance connectent des outils d’IA à des référentiels de données sensibles sans contrôles d’accès, sans traçabilité ni documentation de conformité, alors que les secteurs réglementés l’exigent. La décision de gouvernance autour de MCP doit être prise avant le déploiement, et non après un incident de sécurité ou une enquête réglementaire.

5 points clés à retenir

1. MCP devient la norme pour l’intégration IA-système, permettant aux assistants IA d’interagir avec les données d’entreprise — téléversement, téléchargement, recherche et gestion de fichiers — via un protocole universel plutôt que des connexions point à point sur mesure.
2. Le protocole en lui-même est neutre sur la gouvernance. Un serveur MCP peut être mis en œuvre avec des contrôles d’accès, des journaux d’audit et des mécanismes de conformité adaptés à l’entreprise — ou sans rien de tout cela. La gouvernance ne réside pas dans le protocole, mais dans la façon dont il est déployé.
3. Les implémentations MCP sans gouvernance donnent généralement aux outils d’IA un accès large aux systèmes connectés via des comptes de service surdimensionnés, sans autorisation par utilisateur, sans journalisation par opération, ni gestion des labels de sensibilité.
4. La gouvernance MCP en entreprise exige au minimum six contrôles : authentification OAuth 2.0 avec identifiants stockés hors du contexte IA, autorisation RBAC et ABAC par opération, journalisation d’audit avec attribution, contrôles de chemin et de périmètre, limitation de débit et évaluation des labels de sensibilité.
5. Un serveur MCP gouverné qui étend les politiques de gouvernance des données existantes aux interactions IA — sans nécessiter d’infrastructure de gouvernance spécifique à l’IA — constitue le modèle d’architecture qui permet un déploiement IA rapide et défendable en entreprise.

Qu’est-ce que le Model Context Protocol et d’où vient-il ?

Le Model Context Protocol est une norme ouverte, initialement développée par Anthropic, qui définit comment les assistants IA communiquent avec des outils et sources de données externes. Avant MCP, connecter une IA à un système d’entreprise nécessitait du code d’intégration personnalisé pour chaque combinaison d’outil IA et de source de données — une approche fragmentée et coûteuse, générant des implémentations de sécurité incohérentes et une maintenance lourde.

MCP résout ce problème par la standardisation. Une organisation qui déploie un serveur MCP pour un référentiel de données peut connecter n’importe quel assistant IA compatible MCP à ce référentiel sans écrire de nouveau code d’intégration. L’IA interroge le serveur MCP sur les opérations disponibles, le serveur décrit ses fonctions, et l’IA utilise ces fonctions pour interagir avec les données. D’un point de vue technique, MCP fonctionne comme l’USB a standardisé les connexions de périphériques — une interface universelle qui élimine le besoin de connecteurs propriétaires pour chaque paire d’appareils.

Le protocole connaît une adoption rapide dans l’industrie de l’IA. Les principales plateformes IA, dont Claude, Microsoft Copilot et un écosystème croissant d’outils IA d’entreprise, prennent désormais en charge MCP comme méthode d’intégration native. Pour les responsables IT, cette évolution signifie une chose : MCP n’est plus une technologie émergente à surveiller, mais une norme à gouverner.

Comment MCP fonctionne dans un contexte d’entreprise

En pratique, un déploiement MCP comprend trois composants. Le client IA — Claude, Copilot ou tout autre assistant compatible MCP — est l’interface via laquelle les utilisateurs interagissent avec leurs données. Le serveur MCP se situe entre le client IA et le référentiel de données ; il reçoit les requêtes de l’IA, les valide, exécute les opérations autorisées et renvoie les résultats. Le référentiel de données est le système d’entreprise accédé — partage de fichiers, plateforme de gestion documentaire, base de connaissances ou tout autre espace de contenu.

Quand un utilisateur demande à un assistant IA de « retrouver le contrat Henderson et le partager avec le service juridique », l’IA traduit cette demande en langage naturel en une série d’opérations MCP : recherche d’un fichier selon certains critères, récupération, puis partage. Chacune de ces opérations correspond à une requête distincte au serveur MCP. Le serveur MCP décide, pour chaque requête, s’il l’exécute ou non — et c’est là que la gouvernance s’applique… ou pas.

C’est ce détail d’architecture que les responsables IT doivent comprendre : l’IA n’accède jamais directement aux données d’entreprise. Elle demande au serveur MCP d’y accéder pour elle. Le serveur MCP est le point de contrôle. Un serveur MCP doté de contrôles de gouvernance solides — authentification, autorisation, journalisation, limitation de débit — permet une intégration IA sécurisée et traçable. Un serveur MCP sans ces contrôles donne à l’IA tous les droits du compte de service utilisé, sans restriction par utilisateur, sans journalisation ni documentation de conformité. Le niveau de risque d’un déploiement MCP dépend donc entièrement de ce qui se passe à ce point de contrôle.

Pourquoi les implémentations MCP par défaut ne sont pas prêtes pour l’entreprise

La plupart des serveurs MCP disponibles aujourd’hui ont été conçus pour des développeurs individuels ou de petites équipes. Ils résolvent efficacement le problème de connectivité — ils rendent facile la connexion d’un outil IA à un système de fichiers ou une API. Mais ils ne résolvent pas le problème de gouvernance d’entreprise. Le schéma d’implémentation MCP par défaut présente quatre lacunes structurelles qui le rendent inadapté aux environnements soumis à la réglementation.

La première lacune concerne le contrôle d’accès. Les implémentations MCP par défaut connectent l’IA à une source de données via un compte de service ou une clé API, donnant à l’IA accès à tout ce que ce compte peut atteindre. Il n’y a pas d’autorisation par utilisateur — si un utilisateur peut accéder à un fichier via l’intégration MCP, tous les utilisateurs le peuvent, car l’IA fonctionne toujours sous le même compte de service, quel que soit l’utilisateur. Cela viole directement les principes du zéro trust et crée les mêmes risques d’accès excessif que les programmes de gestion des identités et des accès cherchent à éviter.

La deuxième lacune concerne la traçabilité. Les implémentations MCP destinées aux développeurs enregistrent les logs au niveau applicatif, si tant est qu’elles le fassent. Elles notent que l’IA a fait une requête — mais pas quel utilisateur l’a autorisée, ni quelles données précises ont été récupérées, ni ce qu’il en a été fait. Pour les organisations soumises à HIPAA, RGPD, SOX ou FedRAMP, il ne s’agit pas d’un simple manque de logs — c’est un problème de conformité. Ces cadres exigent une documentation nominative des accès aux données que la journalisation MCP générique ne fournit pas.

La troisième lacune concerne la sécurité des identifiants. De nombreuses implémentations MCP légères stockent les clés API ou tokens d’authentification dans des fichiers de configuration ou des variables d’environnement — accessibles à toute personne pouvant lire la configuration, y compris, dans certaines architectures, au modèle IA lui-même via sa fenêtre de contexte. Une attaque par injection de prompt contre une IA ayant accès à ses propres identifiants conduit inévitablement à une fuite de données. La protection des données selon le zéro trust impose que les identifiants ne soient jamais accessibles via les prompts IA, quelles que soient les circonstances.

La quatrième lacune est l’absence de contrôles d’exfiltration. Sans limitation de débit sur les opérations MCP, un système IA compromis ou mal configuré peut extraire des données à une échelle impossible pour un utilisateur humain. Les mêmes principes DLP qui encadrent l’export massif de données pour les humains s’appliquent aux agents IA capables d’exécuter des milliers d’opérations par minute — mais la plupart des implémentations MCP n’intègrent aucun contrôle équivalent.

API directe vs. MCP : ce qui change — et ce que la gouvernance exige toujours

Ce que la gouvernance MCP en entreprise exige réellement

Pour les responsables IT qui évaluent les déploiements MCP, la question n’est pas de savoir s’il faut utiliser MCP — le protocole s’impose suffisamment pour que la question soit tranchée. La vraie question est de savoir quels contrôles de gouvernance doivent être présents dans le serveur MCP avant toute connexion aux données d’entreprise. Six exigences sont incontournables dans les environnements réglementés.

Deux de ces exigences méritent une attention particulière, car elles sont souvent absentes des implémentations par défaut et ont les conséquences les plus lourdes en cas de manquement.

L’autorisation par opération — et non par session — constitue la différence clé entre une gouvernance MCP adaptée à l’entreprise et une gouvernance limitée aux développeurs. Un contrôle d’autorisation au niveau de la session vérifie que l’IA est autorisée à se connecter au système. Un contrôle par opération vérifie que l’utilisateur demandeur, pour cette action précise sur ces données précises, a bien le droit de procéder — pour chaque opération MCP. Seule l’autorisation par opération garantit le principe du moindre privilège. L’autorisation par session crée une fenêtre de confiance implicite, contraire à l’architecture zéro trust.

L’isolation des identifiants par rapport au modèle IA est tout aussi cruciale. Les tokens OAuth 2.0 doivent être stockés dans le trousseau sécurisé du système d’exploitation — jamais dans des fichiers de configuration, ni dans des variables d’environnement accessibles via le contexte IA, ni transmis dans les prompts IA. Le risque ici est l’injection de prompt : un attaquant capable d’injecter des instructions dans le flux d’entrée de l’IA peut, dans une implémentation mal sécurisée, demander à l’IA de révéler ses identifiants. Le stockage dans le trousseau du système d’exploitation élimine totalement cette surface d’attaque. Il s’agit d’une exigence fondamentale du zéro trust, et non d’un simple durcissement optionnel.

MCP et conformité : ce que les régulateurs finiront par demander

Les responsables IT des secteurs réglementés — services financiers, santé, juridique, secteur public — doivent partir du principe que les régulateurs finiront par s’intéresser à la gouvernance des accès IA aux données. Les signaux réglementaires sont déjà clairs : les exigences d’accès aux données du RGPD s’appliquent aux requêtes IA ; la règle du minimum nécessaire de la HIPAA s’applique aux requêtes IA sur les données patients ; les exigences de traçabilité FedRAMP s’appliquent aux opérations IA dans les systèmes d’information autorisés. Aucun de ces cadres n’a été mis à jour spécifiquement pour MCP, mais ce n’est pas nécessaire — leurs exigences sont suffisamment larges pour couvrir ce cas.

En pratique, cela signifie que les organisations qui déploient des intégrations MCP aujourd’hui doivent être en mesure de prouver, lors d’un audit futur, que chaque accès IA aux données via MCP était authentifié, autorisé selon les règles RBAC, tracé avec attribution complète et conforme aux classifications de sensibilité applicables. Les organisations incapables de fournir cette preuve s’exposent aux mêmes risques réglementaires que pour tout autre accès non gouverné — le fait qu’une IA ait fait la demande plutôt qu’un humain ne constitue pas une exception.

Il existe également un enjeu de souveraineté des données pour les organisations opérant dans plusieurs juridictions. Un serveur MCP qui fait transiter les requêtes IA via une infrastructure cloud située dans une autre juridiction peut déclencher les exigences de transfert transfrontalier du RGPD ou entrer en conflit avec les obligations de résidence des données. Les implémentations MCP gouvernées, déployées dans l’infrastructure de données existante de l’organisation — sans passer par les systèmes de fournisseurs IA externes — éliminent ce risque par conception.

Le problème du Shadow AI que MCP devait résoudre — et peut aggraver

L’un des arguments les plus forts en faveur de l’adoption standardisée de MCP est la gestion du shadow AI. Les collaborateurs qui souhaitent utiliser l’IA dans leur travail trouveront toujours un moyen, avec ou sans l’IT. Les outils IA grand public — comptes ChatGPT personnels, assistants IA dans le navigateur, plugins tiers — sont déjà utilisés dans la plupart des entreprises. Ces outils échappent totalement à la gouvernance d’entreprise : pas de contrôles d’accès, pas de traçabilité, pas de gestion de la sensibilité des données.

Une implémentation MCP gouvernée répond à ce problème en offrant aux collaborateurs une interface IA légitime, validée par l’IT, et plus performante que les alternatives shadow — car elle peut accéder aux données d’entreprise officielles — tout en assurant une visibilité complète sur la gestion des risques de sécurité. L’argument de productivité et l’argument de gouvernance vont donc dans le même sens : un serveur MCP bien gouverné est à la fois un meilleur outil pour les utilisateurs et une meilleure solution pour les équipes de sécurité que les alternatives non gouvernées déjà utilisées par les collaborateurs.

Le risque s’inverse lorsqu’une implémentation MCP non gouvernée devient l’alternative officielle au shadow AI. Remplacer un outil IA grand public sans accès aux données d’entreprise par une intégration MCP validée par l’entreprise, mais dotée d’un accès large aux données sans autorisation par utilisateur, sans journalisation ni contrôles de conformité, ne réduit pas le risque. Cela le concentre et le légitime. Les contrôles de gouvernance font toute la différence entre MCP comme amélioration de la sécurité et MCP comme source de vulnérabilité.

Comment Kiteworks Secure MCP Server garantit une gouvernance MCP adaptée à l’entreprise

La gouvernance MCP n’est pas un problème à résoudre après le déploiement — c’est une décision d’architecture à prendre avant que le premier assistant IA ne se connecte aux données d’entreprise. Les organisations qui font ce choix gagnent un avantage que leurs concurrents n’ont pas : elles peuvent déployer l’IA à grande échelle sans créer de nouveaux angles morts en matière de conformité et de sécurité, là où d’autres ralentissent ou interdisent l’IA. L’implémentation MCP gouvernée fait la différence entre une adoption de l’IA qui crée un avantage concurrentiel et une adoption qui génère un risque réglementaire.

Kiteworks Secure MCP Server a été conçu pour répondre aux six exigences de gouvernance imposées par le contexte d’entreprise. L’authentification s’effectue via OAuth 2.0 avec PKCE — les tokens sont stockés dans le trousseau du système d’exploitation, jamais transmis au modèle IA, jamais accessibles via les prompts IA. L’autorisation est évaluée à chaque opération grâce au moteur de règles de données Kiteworks, appliquant les politiques RBAC et ABAC pour que l’IA hérite des autorisations de l’utilisateur demandeur sans jamais pouvoir les dépasser. Chaque opération MCP est tracée avec attribution complète — système IA, utilisateur, données accédées, horodatage, résultat — alimentant le journal d’audit Kiteworks et s’intégrant en temps réel avec le SIEM.

La protection contre la traversée de répertoires et les restrictions de chemin absolu sont activées par défaut, bloquant l’accès IA aux fichiers système ou aux répertoires hors périmètre. La limitation de débit empêche l’extraction massive au niveau de la session et de l’utilisateur. Et parce que Kiteworks Secure MCP Server s’intègre au Réseau de données privé, il applique les mêmes politiques de gouvernance, de documentation de conformité et de sécurité que pour tous les autres flux de données de la plateforme Kiteworks — partage sécurisé de fichiers, MFT sécurisé, messagerie sécurisée, etc. — à chaque interaction IA. Pas d’infrastructure de gouvernance parallèle. Pas de gestion de règles IA séparée. La même couche de données gouvernée, étendue à MCP.

Pour les CIO et responsables IT qui veulent permettre la productivité IA sans créer de nouvelles zones d’ombre en matière de gouvernance, Kiteworks Secure MCP Server apporte la solution. Pour en savoir plus, réservez votre démo sans attendre !

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la vie privée avec l’IA
• Article de blog
  77 % des organisations échouent à sécuriser les données IA
• eBook
  AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se demandent plus si vous avez une politique IA. Ils veulent des preuves concrètes.