Voici ce que la plupart des schémas d’architecture omettent discrètement à propos des proxys MCP : vous ne réalisez pas que vous en avez besoin avant de gérer six serveurs MCP backend, trois types de transport différents, aucune application centralisée de l’authentification, et le sentiment grandissant qu’un élément de la chaîne va exposer la mauvaise information au mauvais agent au mauvais moment.
Les recommandations de cybersécurité de la NSA sur MCP publiées en mai 2026 le disent clairement : le protocole est déjà exploité en production dans des environnements métier, financiers, juridiques et de développement logiciel. Nombre de ces implémentations ne comportent aucune authentification. Plusieurs ne disposent d’aucun contrôle basé sur les rôles. La question de la sécurité a dépassé le stade théorique. Une couche proxy n’est plus une recommandation académique. C’est ce que vous placez entre votre agent et tout ce qu’il peut manipuler.
Cet article explique ce qu’est réellement un proxy MCP, où les connexions directes échouent, comment fonctionnent les mécanismes de routage et de délégation, et à quel moment le proxy cesse d’être facultatif.
Ce que la plupart des équipes apprennent après le premier incident
- Un proxy MCP délègue aux serveurs backend : il ne contient aucune logique d’outil et ne les remplace pas.
- Les incompatibilités de transport entre clients et backends restent invisibles jusqu’au moment de la connexion ; un proxy les comble.
- Sans proxy, il n’existe aucun point d’application unique pour l’authentification, les politiques ou l’audit dans votre pile de serveurs MCP.
Ce qu’est réellement un proxy MCP
Un proxy MCP est un serveur MCP intermédiaire. Il se place entre un client et un ou plusieurs serveurs MCP backend, reçoit les requêtes concernant des outils, ressources et prompts, puis les transmet au backend qui possède réellement la capacité demandée. Il renvoie ensuite le résultat au client. Le proxy ne contient aucune logique d’outil propre.
Cette dernière phrase est essentielle. Il s’agit de délégation, pas d’hébergement.
La distinction compte, car certaines personnes confondent un proxy MCP avec un proxy HTTP générique tel que Nginx ou HAProxy. Ces outils routent le trafic HTTP en inspectant les URL et les en-têtes. Ils ne comprennent pas la sémantique du protocole MCP, ne connaissent pas les espaces de noms des outils, ne peuvent pas agréger les capacités de plusieurs serveurs dans une surface unifiée et ne peuvent pas faire le pont entre les transports MCP du client et du backend. Les considérer comme identiques conduit immédiatement à de mauvaises décisions d’architecture.
Un proxy MCP utilise nativement le protocole Model Context Protocol des deux côtés. Pour le client, il ressemble à un serveur MCP unique exposant un ensemble complet de capacités. Pour les backends, il ressemble à un client qui effectue des requêtes. Le client n’a jamais besoin de savoir combien de serveurs se trouvent derrière le proxy ni quels transports ils utilisent. Cette invisibilité est précisément l’objectif.
Pourquoi les connexions directes aux serveurs MCP échouent sous des charges réelles
Les connexions directes fonctionnent très bien lorsque vous avez un client, un serveur, des transports compatibles et que personne ne pose de questions sur l’auteur de chaque requête. Cela décrit l’ordinateur portable d’un développeur un mardi après-midi. Cela ne décrit pas un déploiement d’IA en production.
Lorsque vous passez à l’échelle — davantage de clients, davantage de serveurs backend, des environnements hétérogènes — les problèmes se multiplient rapidement. Chaque client a besoin de sa propre configuration de connexion pour chaque serveur. Chaque serveur expose directement son transport, ce qui signifie qu’un backend qui ne parle que stdio doit soudain devenir accessible à un client web qui ne parle que HTTP. Il n’existe aucun point unique où vous pouvez demander : « Qui est autorisé à appeler quoi ? » Chaque déploiement de serveur possède sa propre approche de l’authentification ou, plus souvent, aucune approche d’authentification du tout.
Le rapport de la NSA est précis à ce sujet : de nombreux déploiements MCP omettent entièrement le contrôle d’accès basé sur les rôles, et le protocole ne possède actuellement aucun mécanisme natif permettant l’échange de permissions RBAC lors de l’instanciation. La vulnérabilité n’est pas hypothétique. Des laboratoires publics ont publié des exploits fonctionnels démontrant l’exécution de code arbitraire et la réutilisation de jetons contre des serveurs exécutés sans couche d’application devant eux.
C’est généralement là que le ticket commence.
Le problème d’incompatibilité des transports : stdio, SSE et HTTP streamable
MCP prend en charge plusieurs transports : stdio pour la communication entre processus locaux, SSE pour les flux d’événements envoyés par le serveur, et HTTP streamable pour les interactions HTTP sans état. Le problème est que les clients et les serveurs MCP backend utilisent souvent des transports différents, et cette incompatibilité reste totalement invisible jusqu’à ce que quelqu’un tente réellement de les connecter.
Un plugin d’IDE peut s’attendre à communiquer via le transport stdio. Le serveur MCP backend auquel il doit accéder s’exécute comme un service distant via HTTP streamable. Sans intermédiaire, cette connexion n’a pas lieu. Ni lentement, ni imparfaitement. Elle ne fonctionne tout simplement pas.
Voyez cela comme un problème d’adaptateur de voyage. La prise est réelle. La prise murale est réelle. L’électricité existe des deux côtés. Mais sans adaptateur, rien ne circule. Un proxy MCP est cet adaptateur pour les transports MCP : il accepte une connexion entrante via le transport utilisé par le client et la transmet au backend via le transport utilisé par ce serveur. La traduction est invisible pour les deux parties.
Ce qui se passe lorsque vous transférez des requêtes entre plusieurs serveurs backend
Imaginez que votre agent ait besoin d’outils provenant de quatre serveurs MCP backend différents : un pour l’accès au calendrier, un pour les données CRM, un pour la documentation interne et un pour l’exécution de code. Sans proxy, le client a besoin de quatre configurations de connexion distinctes, de quatre configurations d’authentification distinctes et d’une exposition directe à quatre adresses et transports de serveur différents.
Dès que vous devez transférer des requêtes entre plusieurs serveurs dans un environnement de production, cela devient une dette de configuration qui s’accumule chaque fois qu’une personne ajoute un nouvel outil. Des projets comme mcp-proxy de tbxark répondent exactement à ce besoin : agréger plusieurs serveurs derrière un point d’entrée HTTP unique afin que le client voie un serveur backend, et non quatre. La configuration du client ne change pas lorsque vous ajoutez un cinquième backend. Le proxy absorbe ce changement à sa place.
C’est le problème de fan-out rendu gérable.
Comment fonctionne un proxy MCP : routage des requêtes et délégation des capacités
Il vaut la peine de comprendre précisément les mécanismes, car le comportement du proxy paraît différent selon le côté depuis lequel vous l’observez.
Du point de vue du client, le serveur proxy MCP ressemble à un serveur MCP standard. Le client se connecte, négocie les capacités et envoie des requêtes normalement. Il n’a aucune visibilité sur ce qui se passe ensuite.
Voici ce qui se passe ensuite : le proxy reçoit la requête, détermine quel serveur MCP backend possède la capacité demandée — selon le nom de l’outil, l’URI de la ressource ou l’identifiant du prompt — puis transmet la requête à ce backend en utilisant le transport approprié. Lorsque le backend répond, le proxy retransmet le résultat au client. Le proxy n’exécute aucune logique propre. Il ne réécrit pas la sortie de l’outil. Il délègue, de façon transparente.
L’étape de résolution des capacités est celle qui justifie la complexité du proxy. Si un client souhaite appeler un outil nommé « search_docs », le proxy doit savoir quel backend possède cet outil. Cela exige que le proxy conserve un registre interne indiquant quels outils, ressources et prompts se trouvent sur quels backends. Il construit ce registre en interrogeant chaque backend lors de l’initialisation et en mettant les résultats en cache. Lorsqu’une nouvelle requête d’outil arrive, le proxy la résout par rapport au registre et la route en conséquence.
Ce registre fait également du proxy bien plus qu’un simple relais passif. Il peut appliquer des politiques au moment de la résolution : rejeter les requêtes visant des outils absents de la liste blanche, retirer des capacités provenant des backends avant de les exposer à certains clients, ou ajouter un contexte d’authentification avant le transfert. La couche de routage est également la couche d’application des règles.
Agréger outils, prompts et ressources dans un point de terminaison unique
Du point de vue du client, le proxy présente une surface de capacités unifiée. Lorsque le client demande quels outils sont disponibles, le proxy répond avec l’ensemble combiné de tous les backends. Le client voit un point de connexion client MCP, un point de terminaison et une liste de capacités négociée. Il ne sait pas — et n’a pas besoin de savoir — que « search_docs » provient d’un serveur backend et que « create_ticket » provient d’un autre.
Ce modèle de point de terminaison proxy unique rend les IDE et les frameworks d’agents pratiques dans les environnements multi-backends. Claude Desktop, Cursor ou tout agent compatible MCP n’a besoin que d’une seule connexion configurée. Vous ajoutez un serveur backend, mettez à jour le registre du proxy, et chaque client connecté accède immédiatement aux nouveaux outils. Aucune reconfiguration du client. Aucun nouvel identifiant de connexion à distribuer.
Ici, les backends sont multiples et invisibles. La surface manipulée par le client reste toujours unique.
Pont entre transports et isolation des sessions entre le client et le backend
Le proxy maintient un état de connexion distinct de chaque côté. Un client se connecte via HTTP sans état et le proxy conserve cette session. Lorsque le proxy transfère vers un backend qui attend une connexion persistante avec état, il gère cette connexion indépendamment. La session du client et celle du backend sont isolées l’une de l’autre.
L’isolation des sessions est importante pour une raison facile à négliger : sans elle, l’état de session d’un client peut fuiter vers celui d’un autre. Si deux agents sont connectés au même proxy et que l’un d’eux possède un état d’exécution partiel sur un backend partagé, cet état doit rester invisible pour l’autre. La gestion des sessions du proxy applique cette séparation.
Prenons un exemple concret : un client se connecte via SSE, le proxy accepte ce flux avec état et transfère les requêtes d’outils individuelles vers des serveurs MCP distants via HTTP sans état. Le backend ne voit jamais la connexion SSE persistante. Le client ne voit jamais l’absence d’état de chaque requête. Le proxy fait le pont entre les deux et maintient des contextes propres.
Authentification, autorisation et gouvernance : là où le proxy prend toute sa valeur
C’est ici que l’argument d’architecture devient concret.
Dans un modèle de connexion directe, l’authentification et l’autorisation sont gérées — ou non — sur chaque serveur individuellement. Si vous avez six backends, vous avez six configurations d’authentification, six problèmes de gestion des identifiants et six endroits où une mauvaise configuration peut exposer ce qui ne devrait pas l’être. Il n’existe aucun point unique où demander : « Cet appelant est-il autorisé à appeler cet outil ? »
Un proxy change entièrement cette situation. Chaque appel d’outil, requête de ressource et invocation de prompt passe par le proxy avant d’atteindre un backend. Le proxy devient donc le point d’application naturel de toute votre pile d’identifiants et de politiques. Au lieu de répartir la logique d’authentification sur les backends, vous la centralisez. Le proxy valide l’identité, vérifie les autorisations et ne transmet que les requêtes conformes aux politiques. Les backends n’ont pas besoin de connaître l’identité de l’appelant. Le proxy a déjà pris cette décision.
Le débriefing RSAC 2026 de la Coalition for Secure AI résume la question qui revenait sans cesse dans la communauté : « Qui effectue cette requête ? Comment le savoir ? Que se passe-t-il lorsqu’un agent agit au nom d’un utilisateur à travers plusieurs sauts ? » Un proxy qui centralise des contrôles de sécurité de niveau entreprise constitue la réponse directe à ces trois questions. Il apporte la visibilité et le contrôle que les mécanismes d’authentification par serveur ne peuvent structurellement pas fournir.
L’évaluation de la NSA concernant la spécification d’autorisation MCP est tout aussi directe : le protocole ne permet pas nativement l’échange RBAC lors de l’instanciation. Un proxy ne corrige pas la lacune du protocole. Mais il ajoute une couche d’application au-dessus, ce dont les déploiements de production ont besoin dès maintenant.
💡 Bon à savoir :
Les équipes supposent souvent que si chaque serveur MCP possède sa propre authentification, le système est sécurisé. Pourtant, sans proxy, aucun point d’application ne peut empêcher un agent d’appeler un serveur inscrit sur liste blanche et un serveur qui ne l’est pas au cours de la même boucle. L’authentification propre à chaque serveur ne suffit pas à l’empêcher. Seule une couche qui contrôle quels serveurs peuvent coexister dans le même contexte d’agent peut le faire — et un proxy est cette couche. Un serveur MCP malveillant ajouté à l’environnement devient appelable dès lors qu’aucune couche ne vérifie le registre.
Authentification et autorisation au niveau du protocole
Un proxy intercepte chaque appel d’outil avant qu’il n’atteigne un backend. Ce point d’interception est l’endroit où résident les logiques d’authentification et d’autorisation dans un déploiement MCP bien gouverné. Validation des jetons, assertions d’identité, flux OAuth, vérification des périmètres d’autorisation : tout s’exécute au niveau du proxy avant qu’une seule requête ne soit transférée.
Concrètement, un client soumet une requête d’outil avec un jeton d’authentification. Le proxy valide le jeton, associe l’identité de l’appelant à un ensemble d’autorisations, vérifie si cette identité est autorisée à appeler l’outil demandé, puis transfère ou rejette la requête. Si le backend requiert un identifiant différent — compte de service, clé API limitée à un périmètre — le proxy échange les jetons à cette frontière. L’identifiant du client n’atteint jamais directement le backend.
Chaque requête transférée est journalisée : identité de l’appelant, nom de l’outil, horodatage, statut du résultat. Cette piste d’audit est ce que les équipes de sécurité demandent et obtiennent rarement dans les architectures à connexion directe, car personne n’a pensé à l’ajouter avant le passage en production.
Mettre en œuvre une liste blanche de serveurs MCP et l’application des politiques
La liste blanche est le modèle de gouvernance le plus simple et celui qu’il est le plus utile de mettre en œuvre tôt. Le proxy maintient un registre des serveurs MCP backend approuvés. Les requêtes destinées à tout serveur absent de ce registre sont rejetées avant leur transfert. Un agent ne peut pas appeler un backend qui ne figure pas dans la liste approuvée, quels que soient les outils annoncés par ce backend.
Mettre en œuvre la gouvernance MCP de cette manière signifie que la supervision organisationnelle réside dans la configuration du proxy, et non qu’elle est disséminée dans les configurations de chaque agent. Lorsque les équipes de sécurité demandent : « À quels serveurs MCP nos agents peuvent-ils accéder ? », la réponse est : « Ceux qui figurent dans la liste blanche du proxy. » C’est auditable. Cela peut être modifié sans reconfigurer chaque agent. Et c’est le contrôle fondamental pour éviter le type de risque où un nouveau serveur non évalué entre dans la boucle d’outils sans validation.
Le modèle de proxy MCP d’entreprise va plus loin : définition du périmètre des outils par utilisateur ou rôle, limites de débit sur certaines catégories d’outils et filtrage sortant des réponses avant qu’elles n’atteignent l’agent. Les risques de sécurité dans MCP ne se situent pas uniquement au moment de l’authentification. Ils existent aussi dans la chaîne de sortie, et le proxy est également l’endroit où vous les interceptez. Les contrôles d’authentification déterminent ce qui peut être appelé. Les filtres de sortie déterminent ce qui revient.
Quatre modèles où un proxy MCP résout un véritable problème d’architecture
Il ne s’agit pas d’arguments marketing. Chacun correspond à un mode de défaillance que le proxy évite.
Couche de sécurité et de gouvernance d’entreprise
Une équipe d’ingénierie de sécurité exécutant des workflows d’agents sur des backends CRM, de documentation interne et d’exécution de code ne dispose d’aucun point central pour auditer quel agent a appelé quel outil, avec quelle identité et à quel moment. Chaque backend exécute sa propre authentification, voire aucune. Le proxy devient le point d’application unique : chaque requête le traverse, l’identité est validée, le périmètre est vérifié et le journal complet des appels est capturé. Sans lui, la réponse à un incident après un événement d’empoisonnement d’outil implique de reconstituer l’historique d’exécution depuis six journaux de serveurs différents, à condition que ces journaux existent. Le déploiement d’une couche de gouvernance fait ici la différence entre « nous pouvons enquêter sur ce qui s’est passé » et « nous ne le pouvons pas ».
Hub d’agrégation pour des serveurs MCP hétérogènes
Une équipe RevOps utilisant Cursor a besoin d’accéder aux outils d’un serveur de calendrier, d’un serveur CRM et d’une base de connaissances interne. Sans proxy, Cursor requiert trois configurations de serveur distinctes, trois ensembles d’identifiants, et l’équipe doit mettre à jour chaque client d’agent chaque fois qu’un backend change. Avec un proxy qui agrège les trois derrière un point d’entrée HTTP unique, la configuration du client reste stable. Ajoutez un quatrième backend au registre du proxy, et chaque agent connecté y accède immédiatement. Dans Latenode, cela correspond à l’utilisation du MCP Server Builder intégré pour exposer des capacités contrôlées sous la forme d’une surface de serveur MCP local unifiée destinée à des clients tels que Claude Desktop, avec la gestion automatique des identifiants OAuth de Latenode pour les connexions aux serveurs de ressources sous-jacents. Une configuration client claire, un accès gouverné, et un modèle tarifaire par exécution qui simplifie la comptabilité à mesure que le nombre de backends augmente.
Pont entre transports pour clients et backends incompatibles
Un serveur MCP backend conçu pour s’exécuter localement comme processus stdio doit servir un client agent web qui utilise HTTP streamable. Ces deux éléments ne peuvent pas être connectés directement. Un proxy accepte la connexion HTTP du client et la transmet au processus stdio du backend. Le backend ne bouge pas. Le client ne change pas. Le proxy absorbe l’incompatibilité. Les équipes qui déploient des serveurs MCP progressivement rencontrent ce cas en permanence : un serveur conçu pour le développement local doit soudain servir des agents distants. Le proxy résout ce problème sans nécessiter la réécriture du serveur.
Reconditionner des capacités avec une authentification personnalisée, des limites de débit et des analyses
Une équipe de plateforme IA souhaite exposer un sous-ensemble d’outils MCP internes à des développeurs externes sans exposer directement les serveurs backend. Une couche proxy MCP de production se place devant, applique une authentification par clé API, limite le débit par appelant, retire les métadonnées internes des réponses et journalise chaque appel à des fins d’analyse et de facturation. Sans cette couche, déployer des capacités MCP en externe revient à exposer directement l’infrastructure backend. Le proxy est l’endroit où vous séparez l’interface publique de l’implémentation interne. Les équipes qui ignorent cette étape et déploient directement des serveurs MCP le regrettent dès qu’un appelant épuise la capacité backend ou extrait plus de données que prévu. La capacité du proxy à réduire la charge backend par l’application des limites de débit et la mise en cache représente un véritable avantage opérationnel, pas seulement théorique.
Proxy MCP vs. passerelle API : pourquoi cette distinction compte pour les architectes
Les architectes qui choisissent une passerelle API pour résoudre des problèmes de gouvernance MCP constateront qu’elle couvre environ 60 % de leurs besoins, mais qu’elle manque les 40 % spécifiques à MCP. Il est important d’être précis sur cette distinction.
| Capacité | Passerelle API | Proxy MCP |
|---|---|---|
| Connaissance du protocole | HTTP/REST ; routage par URL et en-têtes | Protocole MCP ; routage par nom d’outil, ressource, prompt |
| Agrégation des capacités | Non ; route vers un seul upstream par point de terminaison | Oui ; agrège les outils de plusieurs backends dans une seule surface |
| Fonctionnalités spécifiques à MCP | Aucune ; pas de transfert d’outils ni de routage de prompts ou ressources | Natif ; délègue les appels d’outils, ressources et prompts entre backends |
| Pont entre transports | Non ; suppose HTTP des deux côtés | Oui ; relie stdio, SSE et HTTP streamable |
| Cas d’usage le plus adapté | API REST, limitation de débit, authentification du trafic HTTP | Déploiements MCP avec plusieurs serveurs, transports mixtes ou exigences de gouvernance |
Une passerelle API peut gérer l’authentification et les limites de débit pour le trafic HTTP, ce qui est réellement utile et mérite d’être déployé pour la couche HTTP de votre pile. L’écart se situe dans la délégation : une passerelle route en faisant correspondre des URL et en appelant un upstream. Elle ne dispose d’aucun mécanisme permettant de découvrir qu’un outil nommé « search_docs » réside sur le backend A et que « create_ticket » réside sur le backend B, de les agréger dans une liste de capacités unique et de les présenter nativement à un client. Il ne s’agit pas d’un problème de configuration de la passerelle. C’est une incompatibilité architecturale entre ce que fait une passerelle et ce que requiert MCP.
📊 En pratique :
Une passerelle API configurée pour router le trafic MCP peut transférer une requête HTTP vers l’adresse d’un serveur proxy : c’est une couche de transport valide. En revanche, elle ne peut pas exposer une surface d’outils MCP unifiée à un client lorsque ces outils sont répartis entre plusieurs backends. La passerelle voit les URL. Elle ne voit pas les espaces de noms des outils. Un client qui parle MCP à une passerelle API obtient du routage. Il n’obtient ni agrégation ni pont entre transports. Les deux couches sont complémentaires, et non interchangeables.
