Le problème qui arrive : tout le monde se branche sur tout
D'abord, un mot de vocabulaire. Le Model Context Protocol (MCP) est un standard ouvert, lancé par Anthropic fin 2024, qui définit comment un assistant IA se connecte à des outils et à des données externes. Un « serveur MCP » expose une série d'« outils » (créer un ticket Jira, lire un fichier Drive, lancer une requête SQL), et un « client MCP » (Claude, Cursor, VS Code, un agent maison) peut les appeler. On peut voir MCP comme une prise standard entre les agents et le reste du système d'information.
Le problème, c'est qu'une prise standard, tout le monde peut s'y brancher. Un développeur connecte GitHub à son éditeur, un commercial branche le CRM à son assistant, quelqu'un installe un serveur trouvé sur internet. À chaque fois, l'agent reçoit des droits et un jeton, sans vue d'ensemble.
Le guide d'adoption entreprise publié par Microsoft décrit précisément cette phase : des équipes qui expérimentent chacune de leur côté, pas de processus d'approbation, des serveurs « fantômes » qui prolifèrent, des jetons qui fuient et des outils aux permissions trop larges.
N agents et M outils, c'est potentiellement N × M connexions, chacune avec son authentification et souvent sans journal. Avec les API, la réponse avait été l'API gateway. Pour les agents, elle s'appelle passerelle MCP.
Ce qu'a fait Uber, sans en faire un mythe
Le 1er octobre 2026, l'équipe d'ingénierie d'Uber a publié « Designing MCP Gateway ». Le point de départ ressemble à ce que vivent beaucoup d'entreprises : des intégrations faites à la main par chaque équipe, de l'outillage fragmenté, de l'infrastructure dupliquée, des outils difficiles à trouver. Cela tenait à petite échelle, plus quand des centaines d'équipes se sont mises aux workflows agentiques.
Leur réponse est un service central qui, selon Uber, héberge aujourd'hui plus de 800 serveurs MCP et plus de 5 000 outils. L'architecture repose sur deux parties :
- un registre (le plan de contrôle), qui sert de source de vérité : quels serveurs existent, qui en est propriétaire, lesquels sont activés ;
- un proxy (le plan de données), qui exécute les appels et les traduit vers les protocoles internes existants (HTTP, gRPC, TChannel).
Un robot d'exploration, AutoCrawler, parcourt les API internes et les transforme automatiquement en outils MCP, avec des descriptions générées par un modèle de langage. Le point qui compte le plus pour un CTO est le suivant : tous les outils découverts sont enregistrés à l'état désactivé. Uber le résume ainsi : « discovery doesn't imply exposure », autrement dit, qu'un outil soit découvert ne veut pas dire qu'il est exposé. Chaque serveur et chaque outil doit être relu puis activé explicitement par l'équipe propriétaire. Toute modification de la description d'un outil produit un diff à approuver, et on peut revenir à une version antérieure.
Côté exécution, l'autorisation est appliquée outil par outil, avec des politiques définies au niveau du serveur et des exceptions possibles par outil. Elles s'appliquent aux humains, aux services et aux agents. La passerelle masque aussi d'office les données personnelles et sensibles dans les réponses des outils.
Gardons les proportions : la passerelle s'appuie sur un registre d'API, un service mesh et un contrôle d'accès maison. Il ne s'agit pas de recopier, mais de retenir trois principes : un point de passage unique, une activation explicite, et une politique d'accès centralisée. La conclusion du billet le dit bien : selon les auteurs, le plus difficile n'est pas l'IA, c'est le « tissu conjonctif », c'est-à-dire la découverte, la sécurité et la fiabilité.
Les risques documentés
Il n'y a rien de spéculatif ici : ces risques sont décrits par l'éditeur du protocole, par Microsoft et par des fournisseurs de sécurité.
Les outils piégés (tool poisoning). Chaque outil MCP comporte un nom et une description que le modèle lit pour décider quoi appeler. Microsoft explique qu'un attaquant peut glisser des instructions malveillantes dans ces métadonnées, invisibles pour l'utilisateur mais lues par le modèle. Il existe une variante, le « rug pull » : un outil hébergé change de description après avoir été approuvé. C'est exactement ce que le diff obligatoire d'Uber permet de bloquer.
L'injection de prompt indirecte. Un outil qui lit des e-mails, des documents ou des pages web renvoie du contenu externe que le modèle peut prendre pour des ordres. WorkOS la classe parmi les risques critiques et rappelle que, pour le modèle, il n'y a pas de différence technique entre les instructions de confiance et les données non fiables : tout arrive sous forme de texte dans le contexte.
Les permissions trop larges. Toujours selon WorkOS, un agent qui se connecte à un serveur MCP reçoit en général l'accès à tous les outils pendant toute la session. Côté protocole, les bonnes pratiques de sécurité MCP mettent en garde contre les scopes génériques (files:*, admin:*) et interdisent explicitement le « token passthrough », qui consiste à accepter puis transmettre un jeton qui n'a pas été émis pour le serveur MCP.
La fuite de données. Si les sorties des outils ne sont pas filtrées, des secrets, des identifiants ou des données personnelles peuvent remonter jusqu'à l'agent, puis en sortir. Lasso cite ce risque dans son communiqué de lancement, et Microsoft recommande de valider les entrées, de nettoyer les sorties et d'appliquer des politiques de prévention des fuites (DLP).
Deux facteurs aggravent le tout. D'après WorkOS, la plupart des serveurs MCP n'ont ni authentification par défaut (alors que la spécification impose OAuth 2.1) ni journal. Après un incident, impossible alors de savoir quel agent a appelé quel outil, pour qui et quand.
Le signal : la spécification se stabilise, les éditeurs arrivent
Le 18 juin 2026, le blog officiel du protocole a annoncé que l'extension Enterprise-Managed Authorization (EMA) est stable. Concrètement, le fournisseur d'identité de l'entreprise (Okta aujourd'hui, d'autres ensuite) devient l'autorité qui décide de l'accès aux serveurs MCP. L'administrateur autorise un serveur pour l'organisation, les utilisateurs en héritent selon leurs groupes et leurs rôles, sans écran de consentement à valider serveur par serveur. Les décisions d'accès et la piste d'audit sont centralisées dans la console de l'IdP.
Le problème visé est clair : chaque salarié autorisait chaque serveur un par un, sans politique centrale, avec le risque de connecter un compte personnel à un outil professionnel. Les premiers à l'adopter sont Okta côté identité, Claude et VS Code côté clients, et Asana, Atlassian, Canva, Figma, Granola, Linear et Supabase côté serveurs. Slack est annoncé comme en cours d'intégration.
En parallèle, l'offre se structure : passerelles open source, services managés, architectures de référence, et comparatifs de « passerelles MCP entreprise ». Celui de Tyk, daté du 22 juillet 2026, émane d'un acteur du marché et doit être lu comme tel.
En moins de deux ans : protocole émergent, menaces documentées, authentification entreprise normalisée, retours d'expérience à grande échelle. C'est le moment où une brique devient de l'infrastructure.
Les options pour une PME
Faire soi-même, en version légère. Un catalogue interne (un tableur suffit), une liste blanche de serveurs autorisés dans les clients, OAuth sur chaque serveur qui touche des données métier, et un reverse proxy qui journalise les appels. Faisable avec peu d'outils, mais tout repose sur la discipline des équipes.
L'open source auto-hébergé.
- IBM ContextForge se présente comme un registre et un proxy qui fédère des serveurs MCP, des agents et des API REST/gRPC derrière un point d'entrée unique. Il fournit une interface d'administration, l'authentification, la limitation de débit, une traçabilité OpenTelemetry et un système de plugins. Attention : la documentation signale des valeurs par défaut non sécurisées (mots de passe, clés) à changer avant toute mise en production.
- Lasso MCP Gateway est une passerelle à plugins conçue par un éditeur de sécurité. Elle orchestre les autres serveurs MCP et, selon Lasso, applique des filtres configurables aux requêtes comme aux réponses pour éviter l'exposition de données sensibles. Lasso la présente comme la première passerelle MCP centrée sur la sécurité, ce qui reste une affirmation de l'éditeur.
Les offres cloud et éditeurs.
- Amazon Bedrock AgentCore Gateway est un service managé : un point d'entrée unique pour le trafic des agents, la conversion d'API et de fonctions Lambda en outils MCP, la gestion de l'authentification entrante et sortante, et une recherche sémantique pour trouver le bon outil. AWS affirme être la seule solution entièrement managée à couvrir à la fois l'authentification entrante et sortante. C'est une affirmation d'éditeur, que je n'ai pas vérifiée. Logique si vous êtes déjà sur AWS.
- Docker MCP Catalog et Toolkit répond surtout au problème du poste de travail. Docker annonce un catalogue de plus de 300 serveurs vérifiés et packagés en conteneurs, permet de créer des catalogues personnalisés limités aux serveurs approuvés, et fait passer les clients (Claude Code, Cursor, etc.) par sa passerelle. Point à noter : la passerelle intégrée à l'offre de gouvernance « Docker AI Governance » est, d'après la documentation, accessible sur invitation uniquement.
- Si vous êtes sur Azure, le guide Microsoft décrit le même schéma avec API Management, Entra ID et API Center.
Pour choisir, trois questions suffisent : qui décide qu'un outil est activé ? Où se trouve le journal ? Qui détient les jetons ? Et, comme le rappelle Microsoft, la passerelle ne doit jamais être le seul point de contrôle.
La version minimale en 4 semaines
Microsoft conseille de commencer avec 3 à 5 outils en lecture seule et de les observer pendant 2 à 4 semaines avant d'en ajouter. Le plan ci-dessous suit cette logique.
Semaine 1 : inventaire. Recensez les clients MCP utilisés (éditeurs de code, assistants, agents maison) et tous les serveurs déjà branchés, y compris en local sur les postes. Pour chacun : propriétaire, données accédées, lecture ou écriture.
Semaine 2 : liste blanche. Faites passer les clients par un point d'entrée unique, que ce soit une passerelle open source, un service cloud ou un reverse proxy avec authentification. Tout outil absent de la liste est refusé. Séparez les outils de lecture et d'écriture, et soumettez toute écriture à une validation humaine.
Semaine 3 : OAuth et journal d'audit. Mettez en place une authentification OAuth reliée à votre fournisseur d'identité sur tout ce qui touche aux données métier, avec des scopes minimaux et des jetons à durée de vie courte. Journalisez chaque appel avec l'identité de l'agent, l'identité de l'utilisateur, l'outil, les arguments nettoyés, le statut et l'horodatage (la liste recommandée par WorkOS).
Semaine 4 : processus d'activation. Formalisez la règle d'Uber : un outil nouveau ou modifié arrive désactivé, son propriétaire le relit, quelqu'un l'approuve, puis il est activé. Toute modification de description passe par la même revue. Revue trimestrielle des droits.
Checklist
- Liste à jour de tous les clients et serveurs MCP, avec un propriétaire nommé pour chacun
- Un seul point d'entrée pour les appels agent → outil
- Les outils non approuvés sont refusés par défaut
- Lecture et écriture séparées, validation humaine sur les écritures
- Aucun serveur sans authentification en dehors du poste de développement
- OAuth via l'IdP de l'entreprise, scopes minimaux, aucun jeton de compte de service partagé
- Le serveur MCP refuse tout jeton qui n'a pas été émis pour lui (pas de token passthrough)
- Journal d'audit : agent, utilisateur, outil, arguments, statut, horodatage
- Masquage des données personnelles et des secrets dans les réponses des outils
- Les descriptions d'outils sont versionnées, et toute modification déclenche une revue
- Pas de reprise en bloc d'une API entière sous forme d'outils : commencer par 3 à 5 outils
- Test de maturité : vous pouvez couper l'accès d'un collaborateur ou d'un agent à un seul endroit
Conclusion
La passerelle MCP n'est pas réservée aux géants du numérique. Elle joue pour le trafic entre agents et outils le rôle que joue l'API gateway pour le trafic entre applications. La différence, c'est le moment où on la met en place. Une PME qui pose aujourd'hui un catalogue, une liste blanche et un journal, sur une dizaine d'outils, s'évitera un chantier de remise en ordre coûteux le jour où plusieurs équipes mettront des agents en production en même temps.
C'est le type de chantier sur lequel j'accompagne des CTO et dirigeants de PME : inventaire de l'existant, choix de l'option adaptée à votre stack, mise en place d'une version minimale qui tient la route. Si vous en êtes à vous demander combien d'agents ont déjà accès à vos systèmes, c'est probablement le bon moment pour en parler.
Sources
- Uber Engineering, Designing MCP Gateway: Uber's MCP Management Platform, 1er octobre 2026
- Model Context Protocol Blog, Enterprise-Managed Authorization: Zero-touch OAuth for MCP, 18 juin 2026
- Model Context Protocol, Security Best Practices
- Microsoft for Developers, Protecting against indirect prompt injection attacks in MCP, 28 avril 2025
- Microsoft / OWASP MCP Top 10 for Azure, Enterprise Patterns & Lessons Learned
- WorkOS, The security risks specific to MCP servers, and how to address them, 2 juin 2026
- IBM, ContextForge, documentation
- Lasso Security, MCP Gateway (GitHub)
- Lasso Security, Lasso Releases First Open Source Security Gateway for MCP, 15 avril 2025
- AWS, Amazon Bedrock AgentCore Gateway
- Docker, Docker MCP Catalog and Toolkit
- Tyk, Best enterprise MCP gateways, 22 juillet 2026 (comparatif d'éditeur)