MCP facilite le passage d’un « agent » à un « agent qui agit ». Le piège, c’est que le succès s’emballe : chaque nouveau système devient un nouveau serveur, chaque équipe livre « juste un outil de plus », et bientôt votre surface d’intégration est trop vaste pour être maîtrisée, trop incohérente pour être sécurisée, trop chaotique pour être opérée.

Pendant ce temps, le modèle est montré du doigt pour des défaillances qui sont en réalité des problèmes de conception d’intégration. Les définitions d’outils gonflent. La précision de sélection chute. Le contexte est dévoré avant même qu’on tape un prompt. Le travail de Tool Search d’Anthropic en est une reconnaissance explicite : les définitions d’outils pour 50+ outils MCP peuvent consommer des dizaines de milliers de tokens, et la découverte à la demande peut réduire drastiquement cette charge tout en améliorant la précision.

La recherche d’outils aide sur l’économie de contexte. Elle ne résout pas, à elle seule, les problèmes de gouvernance et d’ opérations qui surgissent dès que MCP alimente de vrais workflows.

C’est là que le pattern MCP gateway fait la différence entre une démo qui fonctionne et une plateforme durable, une distinction qui devient critique au moment de déployer des workflows IA sans supervision comme Claude Code Routines.

Ce qu’est un MCP gateway

Un MCP gateway est un point d’entrée MCP unique qui fédère les outils de plusieurs serveurs MCP en une surface d’outils gérée La valeur n’est pas « un saut de plus ». La valeur, c’est que le gateway devient l’endroit naturel pour centraliser les préoccupations transversales : authentification, politique, routage et télémétrie.

Une définition précise (avec la terminologie d’Arcade.dev, explicite et actuelle) : les gateways « fédèrent les outils de plusieurs serveurs MCP en une collection unique », permettent de mélanger des outils issus de serveurs différents, et « tous les outils d’un serveur MCP n’ont pas à être disponibles pour le même LLM ».

Deux implications concrètes :

  • Vous arrêtez de connecter chaque client/agent à un maillage de serveurs toujours plus grand.
  • Vous obtenez un moyen maîtrisé d’exposer des surfaces d’outils différentes à différents agents, workflows, IDE et utilisateurs, sans dupliquer les serveurs backend.

Registre vs gateway : la découverte n’est pas la gouvernance

À mesure que l’écosystème grossit, distinguer les registres, gateways et execution runtimes devient essentiel. À la base, vous avez besoin des deux :

  • Un registre : une couche de découverte qui aide les clients à trouver des serveurs et leurs métadonnées (pensez « app store pour serveurs MCP »). Le projet officiel MCP Registry se positionne explicitement ainsi.
  • Un gateway : un plan de contrôle à l’exécution qui décide ce qui est exposé, à qui, sous quelle politique, avec quel audit.

Les confondre mène à des systèmes fragiles. Les registres réduisent la fragmentation en standardisant les métadonnées de découverte. Les gateways réduisent la fragmentation en standardisant le contrôle à l’exécution.

Une architecture de référence qui tient en production

Une architecture durable, c’est :

Clients/hôtes MCP (IDE, agent runtime, copilots) → Gateway (endpoint MCP unique + politique + télémétrie) → Serveurs MCP backend (capacités système + orchestration) → Systèmes/APIs upstream

Transport : privilégiez le Streamable HTTP pour les vrais déploiements

Si vous construisez quelque chose d’accessible à distance ou utilisé par plusieurs clients, le Streamable HTTP est la colonne vertébrale pragmatique. La spécification de transport MCP rend aussi la posture de sécurité explicite pour les transports HTTP : ce n’est pas de l’hygiène facultative.

Concrètement, lors de l’implémentation du Streamable HTTP, les serveurs doivent valider l’en-tête Origin (rebinding DNS), doivent se lier à localhost en exécution locale, et doivent implémenter l’authentification.

Pourquoi « penser gateway » est désormais obligatoire : les serveurs exposés sont déjà un problème

Ce n’est pas théorique. L’équipe TRACE de Bitsight a rapporté avoir trouvé environ 1 000 serveurs MCP exposés sur internet sans aucune autorisation et démontré qu’ils pouvaient récupérer les listes d’outils et d’autres métadonnées.

Deux enseignements :

  1. N’exposez pas d’endpoints MCP sur l’internet public sans un vrai mécanisme d’autorisation.
  2. Si vous souhaitez rendre MCP utilisable à grande échelle (entre agents, IDE et utilisateurs) pour des tâches privilégiées comme les workflows IA d’astreinte SRE, vous avez besoin d’une « porte d’entrée » cohérente qui applique la sécurité de base et les politiques.

Un gateway, c’est cette porte d’entrée.

Autorisation : suivez le modèle MCP et évitez les deux erreurs les plus fréquentes

L’autorisation MCP (pour les transports HTTP) repose sur les concepts OAuth 2.1 : le serveur MCP est un resource server, le client MCP est un client OAuth, et l’émission de tokens est gérée par un serveur d’autorisation.

Trois points de la spécification comptent de façon disproportionnée en pratique :

  • L’autorisation est optionnelle dans les implémentations MCP. C’est l’une des raisons pour lesquelles on voit autant de déploiements non sécurisés.
  • La liaison d’audience est obligatoire lors de la validation des tokens : les serveurs doivent vérifier que les tokens ont été émis pour eux en tant qu’audience cible.
  • Le passage de tokens en transit est explicitement interdit : les serveurs ne doivent pas accepter ni faire transiter des tokens arbitraires ; les APIs upstream nécessitent des tokens distincts émis par leur propre serveur d’autorisation.

Cela correspond à un principe de conception gateway :

Séparez l’identité de la porte d’entrée de l’autorisation downstream

Vous voulez deux contrôles distincts :

  1. Identité de l’appelant au niveau du gateway (qui invoque cette surface MCP ?)
  2. Autorisation au niveau de l’outil (ce qui peut être invoqué, et sous quels scopes/permissions ?)

Cette séparation fait toute la différence entre « on a mis une clé dans un fichier de config » et « c’est sûr pour une production multi-utilisateurs ».

Un exemple concret de la façon dont un gateway peut gérer les environnements multi-utilisateurs (sans devenir un système d’auth sur mesure) : la documentation du gateway d’Arcade décrit un mode production où un service s’authentifie avec une clé API et transmet séparément un identifiant d’utilisateur final (Arcade-User-ID), ce qui permet au gateway d’appliquer des politiques par utilisateur pendant que l’application appelante reste le client authentifié.

Vous pouvez implémenter le même concept de façon vendor-neutre : authentifiez le workload appelant, propagez une assertion d’identité utilisateur, et appliquez une politique de moindre privilège pour l’exécution d’outils au nom de cet utilisateur.

Surfaces d’outils : votre gateway doit sélectionner, pas agréger

L’implémentation de gateway la plus simple, c’est « tout proxyfier ». C’est aussi le moyen le plus rapide de recréer une surcharge d’outils, juste un niveau au-dessus.

Un gateway en production doit prendre en charge des surfaces d’outils sélectionnées :

  • Outils en liste blanche (choisissez explicitement ce qui est exposé)
  • Vues par agent / par workflow (différents clients reçoivent différents sous-ensembles)
  • Instructions d’utilisation orientées LLM à la surface (comment cette collection d’outils doit être utilisée)

C’est la leçon de l’ère des intégrations : la réutilisation vient de briques stables, mais la fiabilité vient de surfaces construites pour un usage précis.

Passer à l’échelle au-delà de « quelques outils » : combinez sélection et découverte à la demande

La surcharge d’outils est désormais assez répandue pour que les fournisseurs de modèles construisent des mécanismes de premier ordre pour y répondre. L’approche Tool Search d’Anthropic est explicite : au lieu de charger toutes les définitions d’outils dès le départ, vous marquez les outils comme différés (defer_loading : true) et les découvrez à la demande.

Deux précisions importantes pour être exact :

  • La recherche d’outils est un outillage modèle/client (ex. Claude), pas une fonctionnalité centrale du protocole MCP.
  • Elle complète les gateways : le gateway réduit ce qui est éligible, et le mécanisme côté modèle réduit ce qui est chargé en ce moment même.

Une règle pratique (confirmée par la documentation de Claude) : gardez un petit ensemble d’outils fréquemment utilisés en mode non différé, et différez le reste pour qu’ils ne soient chargés que via la recherche.

Cela vous donne un pattern scalable :

  • Gateway : politique + sélection + nommage/contrats stables
  • Client/modèle : découverte dynamique pour préserver le contexte et améliorer la précision de sélection

Opérations et gouvernance : traitez MCP comme une plateforme d’intégration, pas comme une fonctionnalité

Une fois que MCP est impliqué dans de vrais workflows, vous avez besoin des mêmes contrôles qui ont rendu les programmes API viables :

  • Auth centralisée et application des politiques
  • Routage et mise en forme des requêtes (quel serveur/outil backend est utilisé)
  • Limitation de débit / throttling pour protéger les upstreams et contenir les abus
  • Logs d’audit et traçage pour « qui a fait quoi, quand et pourquoi »

Ce n’est pas spéculatif : ce sont des responsabilités et des « politiques de gateway » bien établies dans la pratique moderne des API gateways (auth, limitation de débit, monitoring, CORS, etc.).

Une nuance pour MCP : méfiez-vous du cache « utile ». Tout ce qui dépend de l’identité de l’appelant ou des politiques (y compris « quels outils sont disponibles ») doit être traité comme scopé à l’identité ou non mis en cache.

Ordre de construction : le chemin le plus court vers un MCP gateway sûr et opérable

Si vous implémentez ce pattern, cette séquence minimise les reprises :

  1. Un endpoint Streamable HTTP pour les clients.
  2. Validation de l’Origin + valeurs de liaison sûres par défaut (selon les recommandations de transport MCP).
  3. Authentification à la porte d’entrée sur chaque requête ; échec fermé.
  4. Listes blanches d’outils et surfaces d’outils nommées (traitez les noms d’outils comme des APIs).
  5. Vues par agent/par workflow (moindre privilège par défaut).
  6. Instructions de surface (rendez le contrat d’outil explicite pour le modèle).
  7. Discipline des tokens : liaison d’audience, pas de passthrough, tokens upstream séparés.
  8. Logs d’audit structurés pour les appels d’outils (entrées, sorties, acteur, décision de politique).
  9. Limitation de débit par appelant et par classe d’outil.
  10. Découverte d’outils à la demande là où c’est supporté (chargement différé + recherche d’outils).

Conclusion

MCP s’impose parce qu’il standardise la façon dont les agents se connectent aux systèmes réels. Mais la standardisation accroît la composabilité plus vite qu’elle n’accroît l’ opérabilité. Les registres accélèrent la découverte. La recherche d’outils réduit le coût de contexte. Aucun des deux ne vous donne la gouvernance.

Un MCP gateway est le plan de contrôle manquant : il transforme « un tas de serveurs » en une surface d’intégration gérée avec une sécurité cohérente et des opérations prévisibles, sans sacrifier l’interopérabilité qui a rendu MCP si séduisant au départ.