Passerelle MCP : le plan de contrôle dont votre pile d’agents IA a besoin

Les équipes qui ajoutent leur deuxième ou troisième serveur MCP se heurtent généralement au même mur, à peu près au même moment. Pas un crash, pas un message d’erreur. Juste la prise de conscience silencieuse que gérer des connexions individuelles entre chaque agent et chaque serveur ne passe pas à l’échelle, et que les questions d’authentification, de découverte et de politiques qu’elles ont reportées doivent désormais être traitées.

C’est le point de décision. Et la réponse à laquelle la plupart des équipes arrivent, après quelques semaines de multiplication des connexions, est une passerelle. Mais celle vers laquelle elles se tournent en premier est généralement du mauvais type.

Ce que les équipes apprennent après le deuxième serveur MCP

• Une passerelle MCP est un plan de contrôle conscient du protocole, et non une API gateway renommée : la distinction compte davantage qu’on ne l’imagine.
• Les API gateways génériques ne peuvent pas gérer nativement la sémantique des sessions JSON-RPC ni la découverte des outils MCP.
• Une passerelle devient nécessaire dès qu’il y a plusieurs serveurs MCP, des données sensibles ou plusieurs équipes, et pas uniquement à l’échelle d’une grande entreprise.
• MCP définit la norme de communication ; la passerelle fournit la couche opérationnelle que le protocole n’inclut volontairement pas.

Qu’est-ce qu’une passerelle MCP ?

Une passerelle MCP est une couche intermédiaire située entre les clients MCP et un ou plusieurs serveurs MCP. Elle fournit un point d’entrée unique et centralisé pour l’ensemble du trafic MCP. Chaque appel d’outil, lecture de ressource et handshake de session y transite. La passerelle gère le traitement de ce trafic : sa destination, les personnes autorisées à l’envoyer et les éléments journalisés.

Il ne s’agit pas d’un simple proxying. Un proxy transmet des octets. Une passerelle MCP prend des décisions concernant ces octets en comprenant leur signification. Elle connaît les outils, les ressources, l’état des sessions et le contexte de routage. Elle applique des politiques. Elle maintient un registre des serveurs disponibles. Elle applique l’authentification et l’autorisation avant que quoi que ce soit n’atteigne le back-end.

L’équipe d’ingénierie de Tyk décrit cela comme la différence entre le transfert du plan de données et la gouvernance du plan de contrôle : la valeur de la passerelle réside dans la couche du plan de contrôle que l’infrastructure générique ne fournit pas. L’adoption de MCP par plusieurs fournisseurs a accéléré ce phénomène : depuis qu’Anthropic a introduit le Model Context Protocol en novembre 2024, OpenAI et Google DeepMind l’ont tous deux adopté. La passerelle devient donc une couche d’infrastructure partagée, et non un composant de niche dans l’écosystème d’un seul fournisseur.

En mars 2026, l’analyse de Maxim AI basée sur les données des registres de packages estimait les téléchargements mensuels des SDK MCP à 97 millions, tous langages confondus. Lorsque autant d’agents ont besoin d’accéder à des outils, le nombre de connexions non gouvernées de type un-à-un augmente rapidement. Centralisez le point d’entrée, ou passez les six prochains mois à traquer des échecs d’authentification et des endpoints de serveur non documentés.

Où se situe la passerelle MCP dans la pile MCP

L’architecture est facile à visualiser. Les clients MCP — Claude Desktop, Cursor, des agents personnalisés ou tout autre système générant des appels d’outils — communiquent avec la passerelle via un endpoint unique. Derrière elle, plusieurs serveurs MCP gèrent les implémentations réelles des outils. Les clients n’ont pas besoin de connaître les adresses de chaque serveur. Ils acheminent tout via l’unique endpoint de la passerelle, qui s’occupe du reste.

C’est cette position qui donne à la passerelle sa valeur de plan de contrôle. Chaque client communique avec un seul point. Chaque serveur MCP s’enregistre derrière un seul point. L’authentification intervient une fois, à l’entrée. Les politiques sont appliquées avant qu’une requête n’atteigne un serveur back-end. La découverte est centralisée : un agent peut demander « quels outils sont disponibles ? » et recevoir une réponse cohérente, quel que soit le nombre de serveurs en fonctionnement.

L’équipe d’Infracloud décrit cela comme l’agrégation de serveurs MCP de confiance derrière un point d’entrée unique : une vue unifiée de tout ce à quoi les agents peuvent accéder. Cette formulation est juste. Ce qu’elle minimise, c’est l’ampleur des frictions opérationnelles qui disparaissent lorsque les clients et les serveurs MCP n’ont plus à maintenir un état de connexion n-à-n.

En quoi une passerelle MCP diffère d’un proxy MCP générique

Un proxy transmet les requêtes. C’est son rôle, et c’est un rôle réel. Une passerelle MCP fait autre chose : elle comprend la sémantique du Model Context Protocol présente dans ces requêtes.

La spécification MCP s’appuie sur JSON-RPC, avec des concepts tels que les outils, les ressources, les prompts et l’état des sessions superposés à cette base. Un proxy inverse générique et une couche de gestion ne comprennent rien de cela. Ils voient du trafic HTTP. Ils peuvent effectuer un routage selon les chemins et les en-têtes. Ils ne peuvent pas prendre de décisions de routage selon l’outil appelé, la session à laquelle une requête appartient ou le périmètre d’autorisation accordé à un agent.

Une passerelle agit selon la sémantique du protocole, au lieu de seulement transmettre des octets. C’est ce qui permet le routage spécifique au protocole et l’application des politiques : par exemple, une règle consciente de MCP telle que « cet agent ne peut appeler que des outils en lecture seule » ou « acheminer tous les appels d’outils du système de fichiers vers ce serveur précis ». Un proxy générique ne peut pas exprimer cette logique. Une passerelle MCP le peut.

C’est précisément cette distinction que le positionnement des concurrents brouille souvent. Le terme « passerelle » est employé de manière vague. La question à poser est la suivante : cette solution comprend-elle les concepts d’outils MCP et l’état des sessions, ou se contente-t-elle de transmettre le trafic dans la bonne direction ?

Comment fonctionne une passerelle MCP

Lorsqu’un client MCP envoie une requête — par exemple, un agent qui appelle un outil afin de lire un document sur un serveur interne — la requête arrive d’abord à la passerelle. Celle-ci reçoit le message JSON-RPC entrant, identifie la session à laquelle il appartient, valide les identifiants d’authentification joints à la requête, vérifie si l’agent demandeur est autorisé à appeler cet outil spécifique, puis achemine la requête vers le bon serveur MCP back-end. Le serveur la traite et renvoie le résultat au client via la passerelle.

C’est le parcours de base. Ce qui le rend non trivial, c’est la nature avec état des sessions MCP et la couche de politiques exécutée à chaque étape.

Routage et gestion du trafic consciente des sessions

Les sessions MCP ne sont pas des échanges HTTP sans état. Elles disposent d’un contexte persistant : le client a établi une connexion, négocié des capacités et s’attend à ce que les appels d’outils effectués au sein de cette session s’exécutent avec un état de serveur cohérent. C’est fondamentalement différent de la manière dont les API gateways REST gèrent le trafic.

La passerelle gère les sessions MCP avec état en acheminant les requêtes selon l’identité de la session, et non uniquement selon des modèles d’URL. Chaque requête routée par la passerelle conserve son contexte de session. La passerelle envoie chaque requête vers le serveur MCP approprié pour cette session, et non vers une instance disponible choisie arbitrairement.

L’implémentation open source MCP Gateway de Microsoft sur GitHub illustre ce fonctionnement en production : routage avec état conscient des sessions et gestion complète du cycle de vie des serveurs MCP dans Kubernetes. Les routes de la passerelle ne sont pas de simples mappages d’adresses statiques. Ce sont des points de décision conscients des sessions, capables de comprendre la position de la requête dans une interaction continue avec un agent.

L’implication pratique est la suivante : une requête qui semble identique au niveau HTTP peut devoir être envoyée vers des serveurs complètement différents selon l’état de la session. Une API gateway générique voit deux requêtes identiques et les achemine de la même façon. Une passerelle MCP voit deux requêtes dans des sessions différentes et les achemine correctement.

Registre des serveurs MCP et découverte des outils

La passerelle maintient un registre des serveurs MCP enregistrés disponibles et de leurs capacités. Les clients n’ont pas besoin de connaître les adresses des serveurs. Ils demandent à la passerelle quels outils et quelles ressources sont disponibles, et reçoivent une réponse cohérente qui reflète l’état actuel de chaque serveur derrière elle.

Cette fonction de registre MCP rend concrète, plutôt qu’ambitieuse, l’affirmation de « vue unifiée ». Les serveurs et outils MCP apparaissent et disparaissent : les serveurs sont mis à jour, de nouveaux outils sont ajoutés, les capacités évoluent. Sans registre centralisé, chaque client doit connaître indépendamment chaque serveur. La passerelle centralise cette connaissance et met à jour les réponses de découverte des outils lorsque l’inventaire des serveurs change.

L’analyse de la gouvernance de MCP Manager décrit cette approche comme le point de départ de tout modèle de gouvernance MCP sérieux : acheminer tout le trafic par un point central afin d’obtenir immédiatement visibilité et contrôle. Le registre rend cette visibilité possible. Vous ne pouvez pas gouverner ce que vous ne pouvez pas inventorier.

La passerelle maintient activement le registre, et non de manière statique. Lorsqu’un serveur est ajouté, supprimé ou mis à jour, le registre le reflète. Cela importe dans les environnements où les déploiements de serveurs sont fréquents : par exemple, un cluster Kubernetes qui renouvelle des pods de serveurs MCP exige que les clients découvrent toujours l’ensemble actuellement disponible.

Contrôle d’accès, authentification et application des politiques

Chaque appel d’outil passe par la passerelle avant d’atteindre un serveur back-end. C’est l’endroit approprié pour appliquer l’authentification, l’autorisation et la journalisation d’audit : une seule fois, de manière cohérente, sans exiger que chaque serveur MCP l’implémente indépendamment.

Le contrôle d’accès au niveau de la passerelle signifie que les agents transmettent des identités vérifiées dans chaque appel d’outil. Les flux OAuth, la validation des clés API et l’inspection des jetons interviennent avant qu’une requête n’atteigne un serveur. L’autorisation détermine quels outils un agent authentifié peut appeler, à quel rythme et avec quel périmètre. L’approche d’Aembit en matière de sécurité MCP présente cela comme une politique consciente de l’identité : la passerelle sait qui effectue la requête et ce que cette personne est autorisée à faire, indépendamment du serveur qui finira par la traiter.

La journalisation d’audit à cette couche enregistre chaque accès aux outils des serveurs MCP : qui a appelé quel outil, à quel moment, dans quelle session et avec quel résultat. C’est la couche de conformité. Pas un ajout a posteriori. L’accès aux serveurs MCP passe par un point unique, et ce point consigne tout.

Passerelle MCP vs. API Gateway : pourquoi la différence compte réellement

La confusion est compréhensible. Les deux sont des infrastructures fondées sur le modèle de passerelle. Les deux se situent devant des services back-end. Les deux gèrent l’authentification et le routage. Comme l’analyse de Tyk l’explique clairement, la plupart des entreprises auront besoin de plugins spécifiques à MCP ou d’une couche de passerelle MCP dédiée, en complément des API gateways existantes : les API gateways standards ne comprennent pas la sémantique des outils MCP immédiatement. Le Model Context Protocol n’est pas une API REST. Le traiter comme tel crée des lacunes.

Le tableau ci-dessous couvre les dimensions pour lesquelles cette différence a des conséquences concrètes. Il ne s’agit pas d’une liste présentant les passerelles MCP comme supérieures : les API gateways sont l’outil adapté aux API REST et GraphQL. L’idée est que MCP exige quelque chose pour lequel le modèle d’API n’a pas été conçu.

La dernière ligne est celle qui met fin à la plupart des débats. Une API gateway peut appliquer une autorisation sur le chemin /files/read. Une passerelle MCP l’applique sur l’appel d’outil read_file, dans une session appartenant à un agent spécifique, tout en sachant à quoi cet agent est autorisé à accéder. La même requête externe peut être autorisée pour un agent et bloquée pour un autre.

Ce n’est pas quelque chose que vous pouvez ajouter à une API gateway générique sans, de fait, construire une passerelle MCP par-dessus.

À quoi servent réellement les passerelles MCP

Les passerelles MCP apparaissent dans quatre contextes distincts chez les praticiens, chacun répondant à un problème opérationnel différent. Aucun ne se résume à « nous voulions une meilleure sécurité ». Les cas sont plus précis que cela et méritent d’être abordés séparément.

Équipes de plateformes IA d’entreprise : accès gouverné à de nombreux systèmes back-end

Les grandes organisations qui déploient Claude ou des agents en interne ont besoin d’un moyen de donner à ces agents accès à de nombreux serveurs MCP — GitHub, diagnostics Kubernetes, magasins de documents, API internes — sans exposer chaque système directement au trafic des agents et sans demander à chaque équipe d’implémenter sa propre authentification et journalisation.

La passerelle offre aux équipes de plateformes IA d’entreprise un point d’entrée unique et gouverné : les agents d’entreprise accèdent aux ressources par une seule surface, les politiques sont configurées à un seul endroit et les systèmes back-end individuels ne portent pas la charge du contrôle d’accès. L’analyse de l’équipe Infracloud sur les déploiements Claude multi-équipes décrit ce modèle répétable : configurer des serveurs approuvés dans un registre central, appliquer des plugins de sécurité au niveau de la passerelle et fournir à Claude Desktop un endpoint unique. Les utilisateurs voient un ensemble d’outils unifié. L’équipe plateforme contrôle ce qui se trouve derrière.

Les serveurs MCP internes restent internes. L’accès des agents à ces serveurs est gouverné par la passerelle. Ajouter un nouveau système back-end signifie l’enregistrer dans la passerelle, et non diffuser des modifications de configuration à chaque équipe et à chaque client. À l’échelle d’une entreprise, cette différence est considérable : maintenir la cohérence entre les serveurs MCP de dizaines d’équipes sans point de contrôle central est le type de problème qui finit par exiger des effectifs dédiés.

C’est généralement à ce moment-là que les tickets commencent à arriver.

Équipes sécurité et conformité : accès aux outils des agents IA prêt pour l’audit

Des données sensibles circulent lorsqu’un agent IA appelle un outil. Le fichier est lu, l’enregistrement est interrogé, la ligne de base de données est mise à jour. Sans passerelle, ces opérations sont authentifiées individuellement — ou non — par chaque serveur, journalisées de manière incohérente — ou pas du tout — et invisibles à l’échelle de l’organisation.

La sécurité MCP à la couche de la passerelle signifie que chaque appel d’outil est authentifié, autorisé selon une politique granulaire et journalisé avec suffisamment de contexte pour reconstituer ce qui s’est passé. Un agent a demandé cet outil. Il disposait — ou non — de ce périmètre. L’appel a réussi ou a été refusé. La passerelle l’enregistre.

C’est ce que les équipes de sécurité d’entreprise entendent par gouvernance MCP dans la pratique. Pas des politiques que les agents sont censés respecter. Une application qui s’exerce indépendamment de ce que fait l’agent. L’analyse de l’équipe d’ingénierie de Red Hat sur la sécurité MCP décrit la journalisation et la sécurité d’exécution à cette couche comme le mécanisme qui rend le comportement des agents auditable. L’équipe sécurité ne peut pas retracer ce qu’elle ne capture pas. La passerelle capture tout.

La granularité de l’autorisation est importante ici. Un agent autorisé à lire des documents ne devrait pas pouvoir les supprimer. Il s’agit d’outils différents. La séparation sécurisée de la lecture et de l’écriture par MCP au niveau des outils — appliquée par la passerelle — est le type de contrôle qui figure dans les exigences de conformité. La passerelle journalise chaque accès et peut bloquer des combinaisons d’outils avant leur exécution.

Un ingénieur sécurité avec qui j’ai récemment échangé examinait manuellement des journaux éparpillés provenant de plusieurs serveurs MCP afin de déterminer quels agents avaient appelé quels outils et si des combinaisons risquées s’étaient produites. C’est faisable pour un incident. Ce n’est pas un processus que vous voulez exécuter chaque semaine. La passerelle consolide ces journaux par conception.

Équipes DevOps : gestion du cycle de vie et des déploiements des serveurs MCP

Dans les environnements conteneurisés, les serveurs MCP doivent démarrer, rester sains, être mis à jour et s’arrêter proprement. Sans plan de contrôle centralisé, les équipes DevOps et SRE gèrent le cycle de vie de chaque serveur de manière indépendante : décisions de scalabilité, mises à jour de routage, vérifications d’état et déploiements sont traités serveur par serveur.

La passerelle agit comme un plan de contrôle centralisé pour le cycle de vie des serveurs MCP. Déployez une nouvelle instance de serveur MCP et elle s’enregistre dans la passerelle. Faites-la monter en charge et le routage s’ajuste. Arrêtez-la et les clients n’ont pas besoin de le savoir : la passerelle gère le changement de routage. L’observabilité transite par une seule surface : limitation de débit, comportement des tentatives, durée moyenne d’exécution, taux d’erreur et état de santé des serveurs sont tous visibles sans devoir agréger des journaux de serveurs distincts.

L’implémentation Microsoft sur GitHub ancre cette approche comme un véritable modèle de production plutôt qu’une aspiration architecturale :

📊 En pratique :
L’implémentation open source MCP Gateway de Microsoft sur GitHub gère le routage avec état conscient des sessions et le cycle de vie des serveurs MCP dans des environnements Kubernetes de production, notamment l’enregistrement, le routage basé sur des vérifications d’état et le transfert fluide des sessions lors des mises à jour de serveurs. Voilà à quoi ressemble réellement un comportement de plan de contrôle MCP de niveau production, et non un modèle de prototype.

Le modèle de déploiement compte. Dans Kubernetes, les serveurs MCP sont des pods. Ils sont renouvelés. Une passerelle qui comprend l’état des sessions MCP peut contourner les pods défaillants sans interrompre les sessions actives des agents. Un load balancer générique ne le peut pas, car il ne sait pas ce que signifie « au milieu d’une session » pour du trafic MCP. La limitation de débit au niveau de la passerelle évite également que des serveurs individuels soient submergés lorsqu’un traitement par lot déclenche cent appels d’outils en séquence : la passerelle absorbe ce pic avant qu’il n’atteigne le serveur.

Du côté de Latenode : les équipes qui créent des workflows agentiques connectés à plusieurs serveurs MCP bénéficient directement de ce modèle. Lorsqu’un workflow AI Agent de Latenode doit appeler des outils sur plusieurs serveurs, acheminer ces appels via une passerelle, plutôt que maintenir des connexions directes par serveur, permet de garder la topologie des agents gérable à mesure qu’elle évolue.

Les trois idées reçues qui poussent les équipes à repousser trop longtemps la passerelle MCP

J’ai constaté trois erreurs de planification spécifiques qui poussent les équipes à reporter la décision d’adopter une passerelle au-delà du moment où son ajout devient difficile. Aucune ne commence comme une erreur : ce sont des hypothèses raisonnables qui se transforment en problèmes lorsque le déploiement MCP est opérationnel.

🤔 Attendez.
La décision d’ajouter une passerelle MCP est presque toujours reportée jusqu’après une prolifération des connexions ou un incident de sécurité. À ce stade, l’ajouter a posteriori est bien plus difficile que d’intégrer le plan de contrôle dès le départ. La passerelle devient nécessaire dès que vous avez plusieurs serveurs MCP, des données sensibles ou plus d’une équipe qui gère les accès aux outils, et pas uniquement à l’échelle d’une grande entreprise. Les déploiements MCP fantômes, où les équipes mettent en place leurs propres serveurs en dehors de tout modèle de gouvernance, sont le résultat typique d’une attente trop longue.

« Ce n’est qu’une API Gateway avec un autre nom »

La version la plus courante est la suivante : l’équipe dispose déjà d’une API gateway mature, elle la maîtrise, et une passerelle MCP semble n’être qu’un changement de marque. L’analyse de Kong sur l’évolution de la gestion des API est catégorique sur ce point : la distinction se situe au niveau du protocole, et non au niveau du fournisseur.

Une API gateway générique achemine le trafic HTTP selon le chemin et la méthode. Elle ne sait pas ce qu’est un outil MCP. Elle ne peut pas router selon l’outil appelé, appliquer une politique au niveau d’un appel d’outil ou maintenir l’état d’une session dans une interaction agentique à plusieurs tours. Vous pouvez placer une API gateway devant vos serveurs MCP. Elle transmettra le trafic. La logique de routage et d’autorisation spécifique à MCP n’interviendra pas tant que vous n’aurez pas créé un plugin personnalisé qui constitue, dans les faits, une couche de passerelle IA au-dessus de l’existante. À ce stade, vous aurez construit une passerelle MCP, mais à un coût supérieur et avec une surface de maintenance plus importante.

Les API concernées sont sémantiquement différentes. Les traiter comme équivalentes est une optimisation qui semble pertinente jusqu’au premier cas où un agent a besoin d’une autorisation au niveau de l’outil et où la passerelle ne possède aucun concept d’outil.

« Nous l’ajouterons plus tard, lorsque nous aurons davantage de serveurs MCP »

Cet argument est plus difficile à contester au début, car il paraît pragmatique. Deux serveurs MCP sont gérables sans passerelle. Le coût de gouvernance est faible. Chaque équipe gère l’authentification de manière indépendante. La piste d’audit est limitée, mais personne ne l’a encore demandée.

Le problème est que la passerelle gère les éléments coûteux à ajouter rétroactivement. Une fois que des données sensibles circulent dans des connexions directes entre agents et serveurs, ajouter une couche de gouvernance implique de réarchitecturer ces connexions, de migrer l’authentification vers le point central et de reconstruire la piste d’audit désormais requise par l’équipe sécurité. La passerelle MCP fournit un plan de contrôle pour tous les serveurs MCP, et il est beaucoup plus simple que « tous » signifie réellement tous dès le départ plutôt que de l’ajouter à un système disposant déjà de modèles de connexion établis.

Le seuil est plus bas qu’il n’y paraît. Plusieurs serveurs MCP, une source de données sensible ou plus d’une équipe gérant les accès aux outils : n’importe lequel de ces éléments suffit pour que la passerelle soit rentable plus rapidement. Attendre d’atteindre une grande échelle est un mauvais déclencheur.

« La passerelle MCP est surtout un outil de sécurité »

La sécurité est le cas d’usage visible. Elle apparaît en premier dans la plupart des analyses sur les passerelles, et elle est réelle. Mais présenter la passerelle avant tout comme un outil de sécurité minimise le travail opérationnel qu’elle réalise et pousse les équipes à la déprioriser lorsqu’elles n’ont pas d’exigence de sécurité immédiate.

Les responsabilités hors sécurité sont importantes : standardisation de la découverte — les agents découvrent les outils disponibles via une source unique au lieu d’interroger les serveurs individuellement —, observabilité des modèles d’appels d’outils en temps réel et de l’état des sessions, gestion du cycle de vie des déploiements de serveurs et simplification des connexions qui élimine le câblage client-serveur n-à-n. Le positionnement d’Obot et de Moesif sur les passerelles MCP présente tous deux la passerelle avant tout comme un plan de contrôle opérationnel, la sécurité n’étant qu’une des nombreuses responsabilités qu’elle assume.

La passerelle prend en charge toute la couche opérationnelle, et pas seulement le contrôle d’accès. Elle s’intègre aux piles d’observabilité pour exposer les métriques des charges de travail IA : quels outils sont les plus appelés, quels agents génèrent le plus de trafic, quels serveurs affichent des temps de réponse dégradés. Rien de cela ne relève de la sécurité. Tout cela est nécessaire pour exploiter MCP de manière fiable en production.

Azure, Kubernetes et autres contextes de déploiement des passerelles MCP

L’endroit où vous déployez une passerelle MCP détermine les capacités qui comptent le plus. Les fonctions essentielles — routage conscient des sessions, registre, authentification, application des politiques — restent cohérentes. Le contexte de déploiement façonne la manière dont ces fonctions sont implémentées et les compromis opérationnels à gérer.

Dans les environnements natifs Kubernetes, la passerelle s’exécute généralement comme un déploiement dédié, avec une découverte de services soutenue par les mécanismes d’enregistrement propres au cluster. Les serveurs MCP sont des pods. Ils s’enregistrent auprès de la passerelle au démarrage, se désenregistrent proprement à l’arrêt, et la passerelle gère les mises à jour de routage sans exiger de modifications côté client. L’implémentation open source de Microsoft sur GitHub est conçue exactement pour ce modèle : routage avec état conscient des sessions et gestion du cycle de vie des serveurs en production Kubernetes, avec des clés API gérées via les secrets Kubernetes et des images Docker distribuées via des registres de conteneurs standards.

Dans les environnements gérés par Azure, le modèle de déploiement évolue vers l’identité managée pour l’authentification plutôt que des identifiants statiques, Azure API Management comme couche complémentaire pour le trafic REST, et la passerelle MCP pour gérer la couche spécifique au protocole au-dessus. Il ne s’agit pas d’un choix exclusif : les équipes qui utilisent à la fois des API REST et des serveurs MCP exécutent souvent une API gateway et une passerelle MCP, car ces types de trafic exigent réellement des traitements différents. Le déploiement s’aligne sur les compétences de l’équipe.

Pour les équipes qui n’utilisent pas Kubernetes, la passerelle se déploie toujours comme un service autonome, souvent dans Docker, avec un enregistrement manuel des serveurs back-end via la configuration. Dans ce modèle, le registre est statique plutôt que dynamique. La charge opérationnelle augmente parce que vous gérez l’enregistrement des serveurs manuellement, au lieu de l’automatiser via le cluster. C’est un coût réel, mais ce n’est pas une raison de renoncer à la passerelle : c’est une raison de planifier soigneusement le contexte de déploiement avant que plusieurs équipes ne dépendent d’une connectivité MCP stable.

La décision de déploiement affecte également l’observabilité. Dans Kubernetes, les métriques de la passerelle alimentent naturellement les piles Prometheus et Grafana déjà en place. Dans les environnements cloud gérés, elles sont acheminées vers CloudWatch ou Azure Monitor. Dans les configurations basées sur Docker, elles exigent une configuration explicite de transfert. Mettre en place le pipeline d’observabilité correctement au moment du déploiement est bien plus simple que de l’ajouter après coup, lorsqu’un incident est en cours et que personne ne sait quel serveur est surchargé.

Une checklist de configuration pratique pour tout contexte de déploiement :

• Confirmez la prise en charge du routage conscient des sessions avant de sélectionner une implémentation de passerelle - Décidez entre un enregistrement de serveurs statique ou dynamique selon votre modèle de déploiement - Établissez le mécanisme d’authentification (identité managée, OAuth, clés API) avant d’enregistrer le premier serveur - Acheminez les métriques de la passerelle vers votre pile d’observabilité existante au moment du déploiement - Définissez des seuils de limitation de débit au niveau de la passerelle avant de connecter des agents de production (comme point de départ : signalez les taux d’erreur soutenus supérieurs à 5 % sur tout appel d’outil, ou les pics de tentatives supérieurs à 10 en 5 minutes) - Testez la continuité des sessions lors des redémarrages de serveurs avant de déclarer le déploiement prêt pour la production

Quand utiliser une passerelle MCP et quand vous n’en avez probablement pas encore besoin

Il s’agit d’une décision rapide et pragmatique, pas d’une décision dictée par un fournisseur. La bonne réponse dépend de votre configuration actuelle, et non d’une architecture idéale.

Utilisez une passerelle lorsque :

• Plusieurs serveurs MCP fonctionnent déjà

Dès que vous avez plus d’un serveur MCP, vous devez gérer des connexions n-à-n, une authentification incohérente et l’absence d’un registre unique de ce à quoi les agents accèdent. La passerelle devient immédiatement rentable.

• Des données sensibles transitent par un serveur MCP

Si un agent IA peut lire des dossiers clients, des documents internes ou des données financières via des outils MCP, vous avez besoin d’un contrôle d’accès centralisé et d’une journalisation d’audit. Laisser chaque serveur gérer cela indépendamment représente une faille de conformité qui ne demande qu’à être découverte.

• Plus d’une équipe gère les accès aux outils

Le modèle d’entreprise : une équipe construit l’intégration de la passerelle pour l’autorisation, une autre déploie les serveurs MCP, une troisième exécute les agents. Sans plan de contrôle centralisé, la dérive des politiques est inévitable.

• La limitation de débit ou l’observabilité de l’utilisation est une exigence

La limitation de débit par agent et la visibilité en temps réel sur les appels d’outils nécessitent un point de l’architecture qui voit tout le trafic. La passerelle est ce point. Les serveurs individuels ne peuvent pas fournir cette vue transverse des agents.

• Des agents IA de production s’exécutent de manière autonome

Un workflow agentique qui fonctionne sans validation humaine a besoin de pistes d’audit. Si un agent fait quelque chose d’inattendu, « consultez les journaux » doit désigner un seul endroit, et non douze.

Vous n’en avez probablement pas encore besoin si :

• Un seul serveur MCP, un périmètre d’accès limité, une seule équipe

Un serveur, une équipe, des outils internes sans données sensibles : une passerelle ajoute une charge de déploiement sans apporter beaucoup de valeur. Réévaluez la situation lorsque le deuxième serveur apparaît ou lorsque des exigences d’audit émergent.

• Vous êtes en phase de prototypage ou d’exploration initiale

Si vous décidez encore quels serveurs MCP construire ou si vous évaluez si le protocole correspond à votre cas d’usage, une passerelle est prématurée. Créez la preuve de concept, puis ajoutez la gouvernance.

• Tous les clients sont contrôlés et approuvés

Si le seul client MCP est un workflow interne que vous contrôlez et que le serveur MCP possède un périmètre d’outils limité, une connexion directe est acceptable. La passerelle devient nécessaire lorsque les clients se multiplient ou deviennent externes.

• Aucune exigence de conformité ni d’audit n’existe

Pour les équipes sans obligations réglementaires et sans données sensibles dans le chemin des appels d’outils, la charge opérationnelle d’une passerelle entre en concurrence avec des priorités réellement plus élevées. Construisez d’abord l’automatisation, puis planifiez la couche de gouvernance au moment où elle deviendra nécessaire.

La meilleure architecture MCP est celle qui correspond à vos exigences opérationnelles réelles, et non l’architecture la plus complète sur un tableau blanc. Les agents IA et les serveurs MCP sont encore suffisamment récents pour que la bonne réponse pour une équipe de 10 personnes et celle pour une équipe plateforme de 500 personnes soient réellement différentes. Laissez les flux de données entre les composants IA et les véritables exigences de gouvernance guider le calendrier, plutôt qu’une complétude théorique.