Reverse proxy, load balancer et API gateway : à quoi ils servent et quand les utiliser

Les plateformes modernes placent souvent plusieurs composants réseau entre les utilisateurs et les services applicatifs. Une requête peut arriver sur un reverse proxy, passer par un load balancer, puis traverser une API gateway avant d’atteindre enfin un service.

Cette pile peut être très utile, mais elle peut aussi devenir confuse. Reverse proxies, load balancers et API gateways sont tous placés devant le code applicatif. Ils peuvent tous router du trafic. Certains produits combinent même deux ou trois de ces rôles dans un seul système.

La distinction importante n’est pas leur position. La distinction importante est le problème qu’ils résolvent :

• un reverse proxy gère le point d’entrée public vers un ou plusieurs services internes
• un load balancer répartit le trafic entre des instances saines
• une API gateway applique les règles et la gouvernance d’une API

Utilisez-les quand ils résolvent un vrai problème. N’ajoutez pas les trois seulement parce que le schéma d’architecture paraît plus complet.

La version courte

Composant	Rôle principal	À utiliser quand
Reverse proxy	Accepter le trafic public et le transférer en interne	Vous avez besoin de routage, terminaison TLS, cache ou masquage des origines
Load balancer	Répartir le trafic entre plusieurs backends	Vous exécutez plusieurs instances, zones, régions ou versions
API gateway	Contrôler et protéger l’accès aux APIs	Vous avez besoin d’authentification, rate limits, quotas, validation, analytics ou versioning d’API

Dans une petite application, un reverse proxy peut suffire. Dans une application qui scale, le load balancing devient nécessaire. Dans une plateforme d’APIs publique ou multi-équipes, une API gateway devient utile parce que le contrôle du trafic ne consiste plus seulement à atteindre un serveur ; il consiste à appliquer des règles.

Reverse proxy

Un reverse proxy est un serveur qui reçoit les requêtes clients et les transfère vers des services internes. Le client parle au proxy, pas directement à l’application d’origine.

Utilisateur
  -> Reverse proxy
      -> Application web
      -> Service API
      -> Service d'assets statiques

Le reverse proxy vous donne un point d’entrée public contrôlé tout en gardant la topologie interne privée.

Bénéfices

Le premier bénéfice est la protection des origines. Vos serveurs applicatifs n’ont pas besoin d’être exposés directement à internet. Le proxy devient la surface publique, et les services derrière lui peuvent rester sur des réseaux privés.

Le deuxième bénéfice est le routage centralisé. Vous pouvez router /app vers le frontend, /api vers le backend, et /assets vers un stockage objet ou un service statique sans demander au navigateur de connaître l’emplacement de chaque système.

Le troisième bénéfice est la terminaison TLS. Le proxy peut gérer les certificats HTTPS et transférer du trafic simple ou mutuellement authentifié à l’intérieur du réseau privé.

Les reverse proxies sont aussi utiles pour :

• la compression des réponses
• les en-têtes de cache et le cache en bordure
• les en-têtes de sécurité
• les limites de taille de requête
• les redirections et hostnames canoniques
• le filtrage basique des requêtes
• le routage blue-green ou canary quand le proxy le supporte

Quand l’utiliser

Utilisez un reverse proxy quand vous avez besoin d’un point d’entrée public propre devant un ou plusieurs services internes.

Bons exemples :

• un domaine qui sert à la fois un frontend et une API
• masquer les adresses internes des services
• terminer HTTPS avant que le trafic atteigne l’application
• router plusieurs applications depuis un seul hostname
• ajouter du cache ou de la compression hors du code applicatif

Comment bien l’utiliser

Gardez le proxy concentré sur les responsabilités exposées au réseau public. Il doit simplifier le routage et la gestion des connexions, pas devenir une couche applicative cachée.

Une bonne configuration de reverse proxy définit généralement :

• les hostnames acceptés
• les chemins qui pointent vers chaque service
• la façon dont TLS est terminé
• les en-têtes transférés
• les tailles maximales de requête et de body
• le comportement des timeouts
• les logs d’accès avec identifiants de requête

L’erreur la plus fréquente consiste à mettre de la logique métier dans le proxy. Les règles d’authentification, d’abonnement, de permissions et les workflows produit appartiennent généralement à l’application ou à la couche API gateway, pas à un ensemble de règles de routage proxy.

Load balancer

Un load balancer répartit le trafic entre plusieurs instances backend. Son rôle est la disponibilité et le passage à l’échelle.

Utilisateur
  -> Load balancer
      -> Instance API A
      -> Instance API B
      -> Instance API C

Si une instance tombe, le load balancer arrête de lui envoyer du trafic. Si le trafic augmente, vous ajoutez des instances et le load balancer répartit les requêtes.

Bénéfices

Le principal bénéfice est la disponibilité. Un seul processus, serveur ou conteneur applicatif ne doit pas être le seul chemin vers votre plateforme. Le load balancing permet aux instances saines de continuer à servir le trafic quand une instance est indisponible.

Le deuxième bénéfice est le scaling horizontal. Au lieu de rendre un seul serveur toujours plus gros, vous pouvez ajouter des serveurs et répartir la charge.

Le troisième bénéfice est le failover. Un load balancer peut contourner les instances, zones ou régions indisponibles selon le design.

Les load balancers aident aussi avec :

• les health checks
• le connection draining pendant les déploiements
• les mises à jour rolling sans interruption
• la pondération du trafic entre versions
• le routage régional
• la protection contre une distribution déséquilibrée du trafic

Quand l’utiliser

Utilisez un load balancer quand vous avez plusieurs cibles backend pour le même workload.

Bons exemples :

• plusieurs réplicas d’API
• plusieurs conteneurs d’application web
• des services active-active entre zones de disponibilité
• du failover régional
• des déploiements rolling où anciennes et nouvelles versions coexistent
• des services à fort trafic qui nécessitent du scaling horizontal

Si vous n’avez qu’une seule instance backend, un load balancer peut quand même être utilisé par la plateforme d’hébergement, mais il ne résout pas encore grand-chose pour votre application. Sa valeur apparaît quand il dispose de plusieurs cibles saines.

Comment bien l’utiliser

Le load balancer n’est utile que si ses health checks sont fiables. Un processus vivant ne signifie pas forcément que le service est prêt à gérer du vrai trafic.

Des health checks utiles doivent vérifier que le service peut faire son travail critique. Pour une API, cela peut inclure la disponibilité du processus, le chargement de la configuration requise et l’accès aux dépendances essentielles.

Définissez explicitement :

• le chemin de health check et la réponse attendue
• le comportement des timeouts et retries
• la durée de connection draining
• l’algorithme de répartition
• les besoins de sticky sessions, s’il y en a
• les règles de failover par zone ou région

Évitez les sticky sessions sauf nécessité réelle. Si l’état utilisateur ne vit qu’en mémoire sur un serveur, le load balancing devient fragile. Préférez des stores partagés, des serveurs applicatifs stateless ou une infrastructure de session explicite.

API gateway

Une API gateway se place devant les APIs et applique les règles d’utilisation. Elle répond moins à la question “quel serveur doit recevoir cette requête ?” qu’à la question “cette requête est-elle autorisée, bien formée, dans les limites prévues et observable ?”

Client
  -> API gateway
      -> contrôles d'authentification et de politique
      -> rate limits et quotas
      -> validation de requête
      -> Service API

L’API gateway devient le plan de contrôle de l’accès aux APIs.

Bénéfices

Le premier bénéfice est l’application cohérente des règles. Au lieu d’implémenter rate limits, contrôles d’authentification et validation différemment dans chaque service, la gateway peut appliquer des règles communes à l’entrée de la plateforme API.

Le deuxième bénéfice est la protection des APIs. Les APIs publiques doivent être protégées contre les clients abusifs, les intégrations cassées, les pics accidentels de trafic et les requêtes trop volumineuses.

Le troisième bénéfice est la gestion du cycle de vie des APIs. Les gateways aident souvent avec le versioning, la dépréciation, les analytics, la gestion des clés, les plans d’usage et l’accès développeur.

Les API gateways sont utiles pour :

• l’authentification et l’autorisation
• les rate limits et quotas
• la validation de schéma ou de payload
• la gestion des clés API
• la transformation des requêtes et réponses
• le routage par version
• les logs d’audit
• les analytics d’usage
• les APIs monétisées ou partenaires

Quand l’utiliser

Utilisez une API gateway quand l’accès aux APIs doit lui-même être géré.

Bons exemples :

• APIs publiques utilisées par des clients ou partenaires
• APIs internes partagées entre plusieurs équipes
• plateformes microservices avec des exigences communes d’authentification et de politique
• APIs qui nécessitent quotas, rate limits ou plans payants
• APIs versionnées avec des clients externes durables
• plateformes qui ont besoin d’analytics API centralisés

Vous n’avez probablement pas besoin d’une API gateway complète pour une petite application privée avec un seul backend et un seul frontend. Commencez avec l’authentification applicative et un reverse proxy. Ajoutez une gateway quand la politique, l’échelle ou les frontières entre équipes le justifient.

Comment bien l’utiliser

Gardez la gateway responsable de la politique API, pas du comportement produit.

Bonnes responsabilités pour une gateway :

• vérifier les tokens ou clés API
• rejeter les requêtes clairement invalides
• appliquer les rate limits
• router par version d’API
• enregistrer l’usage des APIs
• ajouter des identifiants de corrélation

Mauvaises responsabilités pour une gateway :

• décider des permissions métier complexes
• posséder les workflows produit
• masquer des frontières de services floues
• transformer chaque requête parce que les APIs amont sont incohérentes

Une API gateway peut devenir un goulot d’étranglement si chaque équipe dépend d’elle pour chaque changement d’API. Gardez les règles explicites, versionnées et automatisées via de la configuration ou de l’infrastructure as code.

Comment ils fonctionnent ensemble

Ces composants sont souvent combinés. L’architecture dépend de l’échelle et de la forme de la plateforme.

Petite application

Utilisateur
  -> Reverse proxy
      -> Application web
      -> API

C’est suffisant pour beaucoup de systèmes au départ. Le reverse proxy gère TLS, hostnames, routage, compression et comportement réseau basique.

Application web qui scale

Utilisateur
  -> Reverse proxy ou load balancer couche 7
      -> Instance web A
      -> Instance web B
      -> Instance web C

À ce stade, les responsabilités de reverse proxy et de load balancer peuvent vivre dans le même produit. L’important est que le trafic public soit routé proprement et réparti entre des instances saines.

Plateforme API publique

Client
  -> API gateway
      -> Load balancer
          -> Instance API A
          -> Instance API B

La gateway applique les règles API. Le load balancer répartit le trafic autorisé entre les instances saines du service.

Plateforme multi-services

Client
  -> Reverse proxy
      -> API gateway
          -> Service commandes
          -> Service paiements
          -> Service utilisateurs

Ce modèle peut fonctionner quand le reverse proxy possède les hostnames publics et TLS, tandis que la gateway possède la politique API. Les services restent concentrés sur le comportement métier.

Les règles de décision

Choisissez le composant en fonction du problème devant vous.

Utilisez un reverse proxy quand la question est :

• Comment exposer ce service proprement ?
• Comment router un domaine vers plusieurs services internes ?
• Comment terminer TLS de manière cohérente ?
• Comment garder les origines privées ?

Utilisez un load balancer quand la question est :

• Comment répartir le trafic entre réplicas ?
• Comment survivre à la panne d’une instance ?
• Comment déployer sans interruption ?
• Comment router le trafic entre zones ou régions ?

Utilisez une API gateway quand la question est :

• Comment appliquer authentification et quotas API ?
• Comment protéger des APIs publiques ou partenaires ?
• Comment gérer les versions d’API ?
• Comment suivre l’usage API par client, clé, tenant ou plan ?

Erreurs fréquentes

La première erreur consiste à traiter ces composants comme interchangeables. Ils se recoupent, mais leur modèle opérationnel est différent. Un reverse proxy n’est pas automatiquement une couche de gestion d’API. Un load balancer n’est pas automatiquement un système d’autorisation. Une API gateway n’est pas automatiquement une stratégie de scaling.

La deuxième erreur consiste à ajouter une gateway trop tôt. Si une seule équipe possède un frontend et un backend, une gateway peut ajouter plus de surface opérationnelle que de valeur.

La troisième erreur consiste à cacher un mauvais design de services derrière des règles de routage. Si chaque requête nécessite une transformation lourde dans la gateway, les APIs amont doivent probablement être nettoyées.

La quatrième erreur est le manque d’observabilité. Ces composants sont sur le chemin des requêtes, donc ils doivent émettre des logs et métriques utiles : codes de statut, latence, cible amont, raison de rejet, décisions de rate limit et identifiants de requête.

Un point de départ pratique

Pour une nouvelle plateforme, commencez simplement :

1. Placez un reverse proxy ou un point d’entrée managé devant l’application.
2. Ajoutez du load balancing quand il existe plusieurs instances ou régions.
3. Ajoutez une API gateway quand la politique API devient un sujet produit ou plateforme.
4. Gardez la logique métier applicative dans l’application.
5. Rendez chaque couche observable avant que le trafic de production en dépende.

La meilleure architecture n’est pas celle avec le plus de boîtes. C’est celle où chaque boîte a un rôle clair.

Les reverse proxies donnent un point d’entrée contrôlé. Les load balancers donnent disponibilité et passage à l’échelle. Les API gateways donnent la gouvernance des APIs.

Utilisez la plus petite combinaison qui rend ces responsabilités claires.