La gateway

La gateway est un intermédiaire placé devant les services. Elle reçoit les requêtes des consommateurs, applique les règles, transmet au service concerné, et fait le chemin inverse avec la réponse.

Elle est sur le chemin de chaque appel, ce qui définit à la fois sa valeur et ses limites. Le budget qu’elle doit tenir se chiffre : deux à cinq millisecondes de temps propre au centile 50 pour une chaîne de policies ordinaire, une quinzaine au centile 99. Ces valeurs se vérifient chez vous avant d’être annoncées, et tout ce qui suit dans cette page s’explique par elles.

Consommateur

Application, partenaire, agent

Gateway

Authentification, quotas, routage

Services

API, flux, outils

Ce qui la distingue d’un reverse proxy et d’un load balancer

C’est la confusion la plus fréquente, et elle a une conséquence pratique : beaucoup d’organisations croient avoir une plateforme d’API alors qu’elles ont un proxy avec des règles. Les trois composants sont sur le chemin de l’appel et ne gèrent pas la même unité.

Une gateway fait le travail d’un reverse proxy, terminaison TLS et routage compris, et y ajoute ce qui suppose de savoir qui appelle : l’identité du consommateur, son quota, le contrat qu’il a souscrit, le cycle de vie de la version qu’il utilise.

Le test qui tranche tient en une question posée à l’exploitant : peut-on dire, sans écrire de code, combien d’appels le partenaire X a passés le mois dernier et sur quelles routes ? Un load balancer ne le sait pas. Un reverse proxy le sait par adresse IP, ce qui ne distingue pas deux consommateurs derrière la même sortie. Une gateway le sait par souscription, et c’est la seule différence qui change quelque chose.

Trois familles de trafic

Le mot gateway recouvre désormais trois familles, parce qu’il existe trois types de trafic à gouverner : les appels synchrones, les flux d’événements, et les invocations d’outils par des agents. Elles partagent les mêmes principes, authentifier, limiter, observer, contractualiser, et diffèrent par le contrat et par le cycle de vie du trafic.

API

Requête-réponse, contrat OpenAPI

Événements

Flux continus, contrat AsyncAPI

Agents

Outils MCP, invocation en rafale

Les API. La famille historique. Du requête-réponse, un contrat OpenAPI, des policies appliquées par appel. Les protocoles servis vont au-delà du REST, mais le modèle reste le même : un appel, une réponse, une identité, un quota.

Les événements. Exposer un flux Kafka ou MQTT à des consommateurs externes pose les mêmes questions qu’exposer une API : qui s’abonne, avec quelle preuve, à quel débit, avec quel contrat. Les brancher directement sur le courtier de messages y répond mal. Les adresses internes se retrouvent exposées, les identités sont gérées dans le courtier, et rien ne filtre par consommateur.

La gateway applique alors la gouvernance d’API à ces flux : authentification des clients, quotas, filtrage et masquage de champs par abonné, traduction de protocole, un flux interne consommé en HTTP ou poussé côté externe. Le contrat s’écrit en AsyncAPI, l’équivalent d’OpenAPI pour l’événementiel : canaux, opérations, messages, schémas. Un flux documenté sur le portail et souscriptible comme une API devient un produit au même titre que le reste du catalogue.

Les agents et les modèles. Les agents consomment les API autrement. Ils découvrent des outils, décrits via le protocole MCP, et les invoquent en rafales, une seule tâche pouvant produire des dizaines d’appels. Deux besoins nouveaux en découlent.

Exposer l’existant, d’abord. Les produits du marché génèrent des définitions d’outils MCP depuis les contrats OpenAPI du catalogue. Rien n’est à réécrire, les policies restent en place, et l’agent passe par la même gouvernance que tout autre consommateur.

Gouverner ce trafic, ensuite. L’identité de l’agent se distingue de celle de l’utilisateur pour le compte duquel il agit. Les quotas se comptent en jetons consommés quand l’aval est un modèle, ce qui appelle aussi l’attribution des coûts par équipe et la mise en cache sémantique. Le point de conception qui compte : découvrir un outil n’emporte pas le droit de l’invoquer, et la décision se réévalue à chaque appel.

Faut-il trois produits ?

Plusieurs plateformes portent désormais les trois familles derrière un même control plane, et c’est le bon critère d’évaluation : un catalogue et une identité de consommateur uniques, des policies communes, trois types de trafic. Trois produits disjoints signifient trois catalogues, trois systèmes d’identité et trois portails, et l’unification promise ne se fera pas toute seule.

La question d’avant-vente qui départage : la souscription d’un consommateur à une API, à un flux d’événements et à un outil d’agent passe-t-elle par le même objet de souscription, ou par trois écrans différents ?

Ce qu’elle fait bien

Le routage. Faire correspondre un chemin public à un service interne qui peut changer d’adresse, de version ou de technologie sans que le consommateur le sache.

Le contrôle d’accès. Vérifier l’identité de l’appelant et son droit d’appeler la route. La gateway valide le jeton, elle ne décide pas des droits métier. Le partage détaillé est dans accès.

La protection du backend. Rate limiting, quotas, filtrage par adresse IP, taille maximale des corps, timeouts, circuit breaker. Les réglages sont dans la résilience. C’est la fonction la plus rentable et la moins activée : elle transforme une panne en dégradation.

L’observabilité du trafic. Journalisation structurée, identifiant de corrélation, propagation des traces. La gateway ne surveille pas, elle produit la matière qui permet de surveiller, détail dans observabilité.

La transformation légère. Réécrire un en-tête, normaliser un format de date. Légère est le mot qui compte, et la frontière exacte est posée dans médiation.

Ce qu’il faut lui refuser

La logique métier. Une règle qui commence par « si le client est de type B » a quitté le service. Elle n’est plus ni testée ni versionnée avec le code, et personne ne la relit quand la règle métier change.

L’orchestration. Appeler trois services, agréger, gérer les échecs partiels est un service à part entière, pas une policy. Une gateway qui orchestre reconstruit un bus d’entreprise, avec les défauts qui ont fait abandonner les bus d’entreprise.

L’état applicatif. Un cache se justifie. Un état métier rend la gateway non redémarrable et bloque la montée en charge horizontale.

La transformation massive. Convertir des mégaoctets de XML en JSON à chaque appel consomme le composant le plus critique de la chaîne pour un travail qui appartient à une façade.

Le test qui résume : si le retrait de la gateway cassait des fonctionnalités, et pas seulement la sécurité et le contrôle, trop de choses vivent dedans.

Deux dérives à surveiller

La dérive vers le bus. Une transformation d’en-tête, puis un champ recopié, puis un appel d’enrichissement. En deux ans la plateforme devient le point de couplage qu’elle devait supprimer. Signal fiable : une modification métier qui exige un déploiement de gateway.

La configuration manuelle. Modifications en console, sans historique, sans revue, sans retour arrière. C’est ce qu’on retrouve le plus souvent au point de départ d’un incident en audit, et le sujet entier d’industrialiser.

La troisième dérive classique, une gateway unique pour des régimes de confiance différents, est un choix de topologie. Elle est traitée dans interne et externe.

Managée ou auto-hébergée

Le critère décisif est rarement technique. Il est réglementaire, où le trafic a le droit de passer, ou capacitaire, qui saura l’exploiter. Une gateway auto-hébergée sans astreinte constituée est un risque supérieur à une gateway managée plus chère.

Gateway et service mesh

Les deux routent du trafic et ne traitent pas le même axe. La gateway gère le trafic entrant, entre domaines de confiance différents. Le mesh gère le trafic entre services d’un même domaine, avec identité et chiffrement systématiques. Le partage complet est dans gateway et service mesh.

Les piliers qu’elle porte

Les deux autres piliers ne passent pas par elle. La gouvernance se déclare dans le control plane, la découverte se joue sur le portail.