Dans un précédent article, on a montré comment exposer une API Spring existante comme serveur MCP avec Spring AI, pour brancher un agent dessus. Un serveur, un domaine, une équipe : le cas le plus simple.
Mais un SI ne se résume pas à un seul domaine. Dès qu’on imagine plusieurs équipes reproduire la même démarche chacune sur son périmètre (RH, CRM, devops…), un problème apparaît, et il n’est pas technique. Il est organisationnel.
Le maillage direct ne tient pas à l’échelle d’un SI
Un serveur MCP isolé, c’est simple à raisonner : un client, un serveur, un jeu d’outils. Le problème commence quand un SI compte cinq, dix, vingt domaines, chacun avec son serveur, et que plusieurs agents (assistants internes, outils de dev, automatisations) doivent s’y connecter.
Si chaque agent se connecte directement à chaque serveur dont il a besoin, plusieurs choses se dégradent en même temps.
Chaque serveur MCP a ses propres secrets d’accès au système qu’il expose, et ces secrets finissent dispersés dans autant de configurations d’agents qu’il y a de combinaisons agent-serveur. Une étude GitGuardian a compté plus de 24 000 secrets uniques exposés dans des fichiers de configuration MCP en 2025 : la dispersion n’est pas une hypothèse, c’est déjà un fait établi. Le même flou touche la visibilité des outils : un serveur MCP expose tout son catalogue à qui s’y connecte, sans notion de rôle. Un agent qui a besoin de consulter des données RH pour répondre à une question voit aussi, s’il est connecté au même serveur, les outils de modification de contrat ou de paie. Rien dans le protocole n’empêche ça, c’est une question de gouvernance, pas de spécification.
Et sans point de passage commun, savoir quel agent a appelé quel outil, quand, avec quel résultat, suppose d’agréger les logs de chaque serveur séparément, si tant est qu’ils logguent de façon homogène.
Le protocole MCP définit très bien la conversation entre un client et un serveur, mais rien sur ce qui se passe quand il y en a beaucoup des deux côtés. C’est ce vide que la gateway MCP vient combler.
Ce qu’est une gateway MCP
Une gateway MCP joue pour le protocole le même rôle qu’une API gateway pour des API REST : un point d’entrée unique entre les clients et les serveurs, qui fédère l’accès et centralise les préoccupations transverses. Les agents ne se connectent plus directement aux serveurs de chaque domaine ; ils se connectent à la gateway, qui route vers le bon serveur en appliquant au passage authentification, filtrage des outils, journalisation.
Concrètement, la gateway fusionne les catalogues d’outils de tous les serveurs fédérés en un seul. Le problème, c’est que rien n’empêche deux domaines de nommer un outil de la même façon : le serveur finance et le serveur RH peuvent chacun exposer un outil get_status, sans lien entre les deux. La gateway résout ça en préfixant chaque outil par son domaine d’origine, par exemple finance.facture.creer ou rh.contrat.consulter : c’est ce qu’on appelle le namespacing, et il rend chaque outil identifiable sans ambiguïté, même quand deux domaines réutilisent les mêmes noms génériques.
Autre conséquence directe : les équipes plateforme n’ont plus qu’un seul point d’entrée à sécuriser et à surveiller, au lieu d’un par serveur.
Sécurité : un seul plan de contrôle plutôt que N
C’est l’argument le plus direct en faveur d’une gateway, et celui qui justifie qu’on en parle avant les autres.
L’authentification se centralise. La révision de novembre 2025 de la spécification MCP formalise le rôle du serveur MCP comme resource server OAuth 2.1 : il doit répondre 401 avec un en-tête WWW-Authenticate pointant vers ses métadonnées de ressource protégée (RFC 9728), et le client doit lier son jeton au bon destinataire via les resource indicators de la RFC 8707. Une gateway qui implémente ce flux une fois, au lieu de chaque serveur de domaine, réduit la surface de ce qui peut mal se configurer, et permet de brancher le SSO de l’entreprise à un seul endroit.
Les autorisations, elles, se filtrent par rôle. La gateway sait quel agent, avec quelle identité, fait la requête ; elle peut donc ne renvoyer dans le tools/list que le sous-ensemble d’outils autorisés pour ce rôle, avant même que l’agent ne sache que le reste existe. Le principe de moindre privilège s’applique à l’exposition elle-même, pas seulement à l’exécution.
Reste un point que la gateway atténue sans le résoudre entièrement : le contenu des réponses d’outils. L’OWASP classe l’empoisonnement d’outils MCP comme une menace critique (MCP03:2025) : une instruction malveillante peut se cacher dans la description d’un outil, évaluée une fois à la connexion, ou dans le contenu d’une réponse, qui repart directement dans le contexte du modèle sans filtrage équivalent. Le client fait confiance à ce que le serveur renvoie au même titre qu’à une instruction utilisateur, ce que la littérature sécurité appelle parfois le trust gap du protocole. Une gateway ne supprime pas ce risque, mais elle donne un point unique où appliquer des règles de détection, de masquage de données sensibles ou de validation de paramètres, plutôt que de les dupliquer dans chaque serveur.
Enfin, chaque appel d’outil, avec l’identité de l’agent, la latence, le statut, peut être tracé au même endroit, avec les mêmes outils d’observabilité (OpenTelemetry, dans la plupart des implémentations actuelles). C’est ce qui rend un audit de sécurité possible sans devoir recouper les logs de dix systèmes différents.
Autonomie des équipes : chaque domaine garde son serveur
La centralisation côté sécurité pourrait laisser penser qu’une gateway MCP recentralise aussi l’organisation. C’est l’inverse qui se produit en pratique.
Sans gateway, une équipe qui veut exposer son domaine en MCP doit aussi porter l’authentification, la gestion des secrets, la politique d’accès et l’audit, ou s’en passer. Avec une gateway, ces responsabilités reviennent à la plateforme, et l’équipe domaine garde ce qui la concerne vraiment : son serveur, ses outils, sa modélisation métier, son cycle de version.
C’est le même déplacement de frontière qu’on a connu avec les API gateways face aux microservices : la gateway ne dit pas à l’équipe CRM comment modéliser ses outils MCP, elle lui garantit que ce qu’elle publie sera authentifié, filtré et audité sans qu’elle ait à le réimplémenter. Chaque équipe publie et fait évoluer son serveur à son rythme ; la gateway absorbe les changements de version sans que les autres domaines en soient affectés.
Source : Bulles d'Entreprises
Sélection précise des outils : la gateway comme filtre métier
Le dernier bénéfice est moins évident, mais devient central à mesure que le nombre de serveurs fédérés augmente : celui de la précision du catalogue d’outils exposé à un agent donné.
Un modèle qui doit choisir parmi des centaines d’outils issus de vingt serveurs fédérés sans filtrage perd en précision de sélection : c’est un phénomène documenté sous le nom de context bloat, où la seule accumulation de définitions d’outils dans le contexte dégrade la capacité du modèle à choisir le bon. C’est aussi, mécaniquement, une surface d’attaque plus large : chaque outil supplémentaire dans le contexte est un vecteur potentiel d’instruction indésirable.
La gateway devient le point où l’on aligne l’exposition sur l’usage réel. Un agent dédié au support client n’a besoin que des outils de consultation du domaine CRM et éventuellement de la facturation, pas de l’ensemble des outils devops ou RH accessibles ailleurs dans le SI. Cette curation, faite une fois au niveau de la gateway plutôt que négociée serveur par serveur, c’est ce qui permet de garder un agent focalisé sur son métier plutôt que noyé dans un catalogue générique.
Panorama des solutions existantes
Le marché des gateways MCP s’est structuré rapidement en 2025-2026, avec des positionnements différents. Sans prendre parti pour un produit en particulier, quelques repères.
Côté open source, IBM ContextForge (Apache 2.0) fédère MCP mais aussi A2A, REST et gRPC derrière un même endpoint, avec une interface d’administration et un support OpenTelemetry natif : c’est l’option la plus proche d’une gateway API généraliste étendue à l’agentique. Docker MCP Gateway traite chaque serveur MCP comme un conteneur isolé et signé, dans la continuité des workflows Compose déjà connus des équipes qui packagent déjà tout en conteneurs. Solo.io agentgateway, donné à la CNCF via le projet kagent mi-2025, vise plutôt les infrastructures Kubernetes déjà construites autour d’un plan de données agentique. Lasso Security, à l’inverse des précédents, ne prétend pas être une gateway complète : c’est une couche de sécurité et de détection de menaces à poser devant une gateway existante.
Côté commercial, Kong a étendu sa gateway IA existante pour couvrir MCP en plus de REST et des LLM, ce qui en fait un choix naturel pour une équipe qui a déjà Kong en place. MintMCP cible spécifiquement les secteurs réglementés avec des journaux d’audit au format SOC 2, HIPAA ou RGPD générés automatiquement.
Ce qu’une gateway coûte
Ce n’est pas une brique gratuite. Elle introduit un composant supplémentaire dans le chemin critique de chaque appel d’outil, avec une latence ajoutée qui reste faible sur une infrastructure bien dimensionnée mais qui existe. Elle devient aussi, par construction, un point de défaillance unique : si elle tombe, plus aucun agent n’accède à aucun serveur, même à ceux qui fonctionnaient parfaitement avant. Ça se traite avec les pratiques habituelles de haute disponibilité (réplication, bascule automatique), mais ça reste un système supplémentaire à exploiter et à faire évoluer, avec son astreinte.
Il y a enfin la question de la migration : une équipe qui a déjà un serveur MCP en production et des agents connectés directement doit faire basculer ces clients vers la gateway sans interruption de service, ce qui suppose une période de coexistence entre accès direct et accès fédéré plutôt qu’un couperet.
Où en est le protocole
MCP a été donné à l’Agentic AI Foundation, sous l’égide de la Linux Foundation, en décembre 2025, ce qui en fait un standard porté par une gouvernance neutre plutôt que par un seul éditeur. La feuille de route 2026 du projet identifie quatre priorités : la scalabilité du transport (sessions robustes derrière des répartiteurs de charge, découverte via .well-known), la communication entre agents, la maturation de la gouvernance, et ce qu’elle appelle elle-même la préparation à l’entreprise : audit, authentification intégrée au SSO, comportement de gateway. Ce dernier point est explicitement le moins abouti de la feuille de route à ce jour, porté principalement par la communauté plutôt que par un groupe de travail dédié.
Concrètement, ça veut dire que les gateways MCP anticipent aujourd’hui sur des besoins que le protocole ne standardise pas encore complètement. C’est un domaine qui bouge vite : les choix d’architecture faits maintenant devront probablement s’ajuster aux évolutions de la spécification dans les prochains trimestres.
Par où commencer
Introduire une gateway n’a de sens qu’à partir du moment où la gouvernance devient elle-même un problème : plusieurs serveurs, plusieurs équipes, plusieurs agents. Sur un seul serveur MCP porté par une seule équipe, comme dans notre article précédent, une gateway serait une couche d’infrastructure sans bénéfice réel.
Le signal à surveiller, c’est le moment où poser la question « quel agent peut faire quoi, sur quel domaine, et qui le sait » n’a plus de réponse simple. À ce stade, la gateway ne remplace pas le travail de chaque équipe domaine sur son serveur MCP : elle donne au SI un endroit unique où appliquer la sécurité, garder la trace des accès, et exposer à chaque agent exactement les outils dont il a besoin, ni plus ni moins.
Ressources utiles
Documentation
- Model Context Protocol - Spécification, section autorisation
- MCP Blog - Feuille de route 2026
- OWASP - MCP Tool Poisoning (MCP03:2025)
Bibliographie
- RFC 9728 - OAuth 2.0 Protected Resource Metadata
- RFC 8707 - Resource Indicators for OAuth 2.0
- Solo.io - agentgateway
- IBM - MCP Context Forge
