De protocole à Infrastructure : Comment gouverner MCP avant qu'il ne vous gouverne
Slug: mcp-infrastructure-entreprise-securite-gouvernance-2026
Résumé exécutif
Le Model Context Protocol (MCP), lancé par Anthropic fin 2024, a accompli en 18 mois ce que la plupart des standards mettent une décennie à réaliser : une adoption véritablement généralisée par l’industrie. Soutenu par OpenAI, Google, Microsoft et AWS, et désormais gouverné par la Linux Foundation, MCP est aujourd’hui déployé en production dans des centaines d’entreprises.
En mars 2026, MCP alimente des workflows agentiques à grande échelle et est devenu la couche d’intégration de facto pour l’IA d’entreprise. Mais cette adoption rapide a dépassé la gouvernance.
La plupart des équipes sécurité n’ont jamais audité leurs déploiements MCP. La plupart des CTO ne savent pas combien de serveurs MCP fonctionnent dans leur organisation.
Cet article explique ce que fait réellement MCP, pourquoi il est devenu une composante essentielle de l’architecture d’entreprise, les trois vecteurs de sécurité qui préoccupent les chercheurs de RSA 2026, et un cadre de gouvernance pratique à mettre en place avant qu’un incident ne vous y oblige.
3 enseignements clés :
- MCP résout le problème d’intégration quadratique : sans lui, connecter N agents à M outils nécessite N×M connecteurs personnalisés. Avec MCP, vous construisez une fois et vous connectez partout.
- Le protocole a évolué plus vite que les contrôles de sécurité des entreprises : la plupart des déploiements sont sur-permissionnés, non audités et invisibles pour les équipes IT.
- Les entreprises qui prennent de l’avance ne sont pas celles qui ont les meilleurs modèles, mais celles qui disposent de l’architecture MCP la plus propre et la mieux gouvernée.
3 actions à mettre en place immédiatement :
- Réaliser un inventaire des serveurs MCP : quels serveurs sont en fonctionnement, qui les a déployés et quelles permissions ils possèdent.
- Appliquer l’authentification, les permissions limitées et l’observabilité à chaque serveur avant le prochain déploiement d’agent.
- Désigner un responsable de la gouvernance MCP — ce rôle n’existe pas encore dans la plupart des organigrammes, et c’est précisément le problème.
Risque si ignoré :
Les Shadow Agents — des agents IA non validés accédant à des systèmes critiques via des serveurs MCP non gouvernés — reproduisent l’explosion du Shadow IT de 2015, mais avec des capacités d’exécution, pas seulement d’accès aux données.
Introduction
En novembre 2024, Anthropic publie discrètement une spécification open source appelée Model Context Protocol.
L’objectif initial est modeste : standardiser la manière dont les assistants IA se connectent aux outils externes et aux sources de données.
Plus de connecteurs personnalisés.
Plus de middleware fragile.
Un protocole unique, compatible avec n’importe quel modèle et n’importe quel outil.
Seize mois plus tard, MCP est devenu quelque chose que personne n’avait vraiment anticipé : une infrastructure d’entreprise.
Pas une commodité pour développeurs.
Pas une API expérimentale.
Une infrastructure — du type de celles qui, lorsqu’elles tombent en panne ou sont compromises, entraînent avec elles les opérations métier.
Le 9 mars 2026, les mainteneurs du protocole MCP ont publié une feuille de route mise à jour reconnaissant explicitement cette évolution :
« MCP a largement dépassé ses origines de protocole pour connecter des outils locaux. Il fonctionne désormais en production dans des entreprises de toutes tailles, alimente des workflows agentiques et est façonné par une communauté en pleine croissance. »
La question pour les dirigeants d’entreprise n’est plus faut-il adopter MCP.
La plupart des organisations l’ont déjà fait.
La vraie question est :
Est-ce que vous gouvernez MCP… ou est-ce que MCP se gouverne tout seul ?
Paysage actuel : de l’expérimentation à la couche opérationnelle
Les chiffres sont révélateurs.
Les téléchargements de serveurs MCP sont passés d’environ 100 000 en novembre 2024 à plus de 8 millions en avril 2025.
L’écosystème compte aujourd’hui :
- plus de 5 800 serveurs MCP
- plus de 300 clients MCP
Les acteurs majeurs de l’industrie — OpenAI, Google DeepMind, Microsoft et AWS — ont officiellement adopté le standard.
En décembre 2025, Anthropic a confié MCP à la Linux Foundation, au sein de la nouvelle Agentic AI Foundation, avec OpenAI et Block comme co-fondateurs.
BCG résume bien la situation :
MCP est « une idée d’une simplicité trompeuse aux implications considérables ».
Sans MCP, la complexité d’intégration augmente de manière quadratique.
Chaque nouvelle application IA connectée à un nouvel outil nécessite une intégration personnalisée.
10 applications IA et 100 outils signifient potentiellement 1 000 intégrations à développer et maintenir.
Avec MCP, cette complexité devient linéaire.
Construisez un serveur une fois.
Tous les agents compatibles MCP peuvent s’y connecter.
Ce gain d’efficacité a accéléré l’adoption à une vitesse rarement observée dans les technologies d’entreprise.
Salesforce, ServiceNow, Workday, Accenture, Deloitte — plus de 50 partenaires enterprise construisent ou déploient déjà des systèmes compatibles MCP.
Mais ces métriques d’adoption ne racontent pas toute l’histoire.
La plupart de ces déploiements se font sans gouvernance de niveau enterprise.
Le protocole a priorisé l’interopérabilité plutôt que la sécurité dans sa conception initiale.
La communauté rattrape progressivement ce retard.
Mais la production est déjà en avance sur les garde-fous.
L’architecture : ce que fait réellement MCP
Comprendre l’architecture MCP est indispensable pour la gouverner.
MCP est un protocole client-serveur.
Dans un contexte d’entreprise :
Le host est votre orchestrateur d’IA :
- Gemini Enterprise
- Claude for Enterprise
- Microsoft Copilot
- ou un framework agentique interne.
Il gère les interactions avec les LLM et les conversations utilisateur.
Le client MCP est intégré dans le host.
Il initie les connexions vers les serveurs MCP pour le compte de l’utilisateur ou de l’agent.
Les serveurs MCP sont des processus légers qui exposent des capacités spécifiques :
- accès lecture/écriture à Jira
- base de connaissances Confluence
- base de données interne
- CRM client
Chaque serveur définit :
- les outils qu’il expose
- les ressources accessibles
- les prompts qu’il peut générer.
Le point crucial pour les CTO :
Les serveurs MCP sont des points d’exécution.
Ils ne se contentent pas de récupérer des informations.
Ils peuvent modifier les systèmes.
Un agent connecté à un serveur MCP Jira peut :
- créer des tickets
- modifier des statuts
- réassigner des tâches
- fermer des incidents.
Un agent connecté à une base de données interne peut écrire des enregistrements, pas seulement les lire.
C’est le changement architectural que beaucoup de discussions exécutives sur l’IA ignorent.
RAG récupère.
MCP agit.
Les trois vecteurs de sécurité surveillés à RSA 2026
Moins de 4 % des soumissions liées à MCP à la conférence RSA 2026 portent sur les opportunités.
La communauté sécurité se concentre presque entièrement sur les risques.
Trois vecteurs dominent la discussion.
1. Sur-permissionnement
Les serveurs MCP sont souvent déployés avec plus de permissions que nécessaire.
Un cas d’usage en lecture seule reçoit un serveur en lecture/écriture.
Un assistant interne accède à des systèmes de production.
C’est le problème classique du principe du moindre privilège, désormais reproduit sur chaque serveur MCP.
2. Empoisonnement d’outils et prompt injection
Du contenu malveillant dans les systèmes connectés aux serveurs MCP peut manipuler le comportement des agents.
Un attaquant capable d’injecter du contenu dans :
- une page Confluence
- un ticket Jira
- un email
peut potentiellement influencer les actions de l’agent.
Les serveurs MCP connectés à du contenu généré par les utilisateurs sont particulièrement exposés.
3. Shadow agents et serveurs non gouvernés
Une session RSA démontrera comment une vulnérabilité MCP pourrait permettre l’exécution de code à distance et la compromission complète d’un tenant Azure.
Plus largement, les chercheurs alertent sur un phénomène plus courant :
Des connecteurs MCP créés par la communauté entrent dans les environnements d’entreprise sans audit de sécurité.
Des développeurs expérimentant avec l’IA déploient des serveurs MCP :
- sur leur machine locale
- sur une infrastructure non enregistrée.
Les équipes de gouvernance IT ignorent leur existence.
La surface d’attaque s’étend de manière invisible.
Scénario : le Shadow MCP Server
Considérons une situation simple.
Une équipe déploie un serveur MCP pour exposer les données Jira d’un projet à un assistant IA interne.
Le serveur est créé rapidement pour une expérimentation.
L’authentification est mal configurée.
Un agent externe découvre ce serveur MCP et invoque les outils exposés.
Soudain, des données sensibles de projet deviennent accessibles en dehors de l’organisation.
Dans ce cas :
- le modèle fonctionne correctement
- la vulnérabilité se situe dans la couche d’exposition des outils
C’est l’équivalent agentique du problème des Shadow APIs rencontré lors de l’essor de l’économie des API.
Le cadre de gouvernance : trois contrôles avant de passer à l’échelle
Les organisations qui déploieront MCP en toute sécurité en 2026 sont celles qui mettent en place trois contrôles fondamentaux dès maintenant.
Contrôle 1 : inventaire et classification
Vous ne pouvez pas gouverner ce que vous ignorez.
La première étape consiste à établir un inventaire complet des serveurs MCP :
- quels serveurs sont déployés
- par qui
- connectés à quels systèmes
- avec quelles permissions.
Ce n’est pas un audit ponctuel.
Cela doit devenir une pratique continue.
Classifiez chaque serveur selon la sensibilité des systèmes connectés :
- Tier 1 : données clients, systèmes financiers
- Tier 2 : opérations internes
- Tier 3 : outils non sensibles
Contrôle 2 : authentification, permissions limitées et observabilité
Pour chaque serveur MCP — en commençant par les systèmes Tier 1 — implémentez :
- une authentification intégrée SSO
- des permissions strictement limitées au cas d’usage
- des logs structurés pour chaque action.
Sans logs, pas de réponse à incident.
Sans permissions limitées, impossible de contenir une compromission.
Contrôle 3 : un responsable de gouvernance
Ce rôle n’existe pas encore dans la plupart des organigrammes.
Quelqu’un doit être responsable :
- de l’inventaire MCP
- des standards de sécurité
- de l’approbation des nouveaux serveurs
- de la coordination avec l’équipe sécurité.
Dans les organisations déployant MCP à grande échelle, ce rôle émerge souvent chez :
- un responsable Platform Engineering
- ou un responsable AI Infrastructure.
Le formaliser accélère fortement la maturité organisationnelle.
Conclusion
MCP a accompli quelque chose de remarquable :
une adoption industrielle en moins de 18 mois.
Le protocole résout un problème réel : la complexité d’intégration de l’IA.
Mais il ne résout pas la gouvernance.
C’est le travail qui attend maintenant les dirigeants technologiques.
La fenêtre pour une gouvernance proactive est encore ouverte.
Mais elle se referme rapidement.
Construisez l’inventaire.
Limitez les permissions.
Désignez un responsable.
L’architecture que vous gouvernez aujourd’hui est l’infrastructure que vous pourrez faire évoluer sereinement demain.
Auteur : Godwin Avodagbe
Deputy Director Digital Transformation, GALEC (E.Leclerc Group).
Fondateur eKoura & HitoTec.
Programme CTO – Cambridge Judge Business School.
Comments ()