---
term: "Architecture d'API Gateway"
seoTitle: "Qu'est-ce qu'une API gateway ? Architecture, patterns et trade-offs"
headline: "Qu'est-ce qu'une API gateway ?"
slug: api-gateway
category: api-realtime
shortDefinition: "Une API gateway est une porte d'entrée gérée pour vos API : un point d'entrée unique qui route, authentifie et applique un rate limiting à chaque requête."
relatedTerms:
  - api-rate-limiting-throttling
  - microservices-vs-monolith
  - api-orchestration
  - cors-cross-origin-resource-sharing
contrastsWith:
  - api-orchestration
faq:
  - question: "Qu'est-ce qu'une API gateway et comment fonctionne-t-elle ?"
    answer: "Un point d'entrée unique placé devant vos services backend. Chaque requête arrive à la gateway, qui authentifie l'appelant, applique les limites de débit, route vers le bon service, transforme ou agrège éventuellement les réponses et enregistre des données d'observabilité — puis renvoie le résultat. Les clients voient une seule API cohérente ; la topologie qui se trouve derrière reste privée et modifiable."
  - question: 'Quelle est la différence entre une API gateway et un load balancer ?'
    answer: "La couche et l'intention. Un load balancer répartit le trafic entre des copies identiques d'un service, pour la capacité et la disponibilité — il se demande « quelle instance ? ». Une gateway prend des décisions qui tiennent compte de l'API — « quel service, cet appelant est-il autorisé, à quel débit, avec quelle transformation ? ». Les deux sont complémentaires : le montage classique place un load balancer devant les instances de la gateway, et les services derrière les deux."
  - question: "Une API gateway n'est-elle qu'un reverse proxy ?"
    answer: "C'en est un, spécialisé. Toute gateway est un reverse proxy — elle termine les requêtes des clients et les transmet vers l'intérieur — mais dotée d'un cerveau de politiques taillé pour les API : authentification, limites de débit par clé, transformation des requêtes, agrégation et observabilité au niveau de l'API. Si vous n'avez besoin que de transfert et de TLS, un simple reverse proxy suffit ; la gateway justifie sa place dès que les politiques entrent en jeu."
  - question: 'Quelle est la différence entre une API gateway et un service mesh ?'
    answer: "Le sens du trafic. La gateway gouverne le trafic nord-sud — les clients qui entrent dans le système. Un service mesh gouverne le trafic est-ouest — les services qui communiquent entre eux à l'intérieur, via des sidecars qui gèrent mTLS, retries et routage. Les grands systèmes utilisent les deux ; les petits n'ont généralement besoin ni du mesh ni, parfois, de la gateway."
  - question: "Qu'est-ce que le pattern Backend-for-Frontend (BFF) ?"
    answer: "Une variante de la gateway : au lieu d'une seule gateway pour tous les clients, chaque type de client — web, mobile, partenaires — dispose de sa propre gateway légère, qui façonne les réponses selon ses besoins. Elle met fin au tiraillement où une API générique sert mal tout le monde, au prix de davantage d'éléments à déployer. Le BFF, c'est le pattern de la gateway qui admet que les clients diffèrent."
  - question: 'Une API gateway est-elle un point de défaillance unique ?'
    answer: "Sur le plan architectural, oui — tout passe par elle — c'est pourquoi les gateways de production tournent en flottes clusterisées, mises à l'échelle horizontalement derrière un load balancer, avec health checks et failover. La parade est standard ; la faute consiste à faire tourner la porte par laquelle tout passe sur une seule instance, parce que tout fonctionnait bien en staging."
  - question: 'Une API gateway ajoute-t-elle de la latence ?'
    answer: "Un saut réseau, généralement quelques millisecondes — et souvent un gain net : l'agrégation fusionne plusieurs allers-retours du client en un seul, le cache répond aux requêtes répétées à l'edge, et la réutilisation des connexions vers les backends est plus rapide que les connexions à froid des clients. Le bilan honnête met ce saut en regard des allers-retours et du code de politiques dupliqué qu'il élimine."
  - question: "Quand n'avez-vous PAS besoin d'une API gateway ?"
    answer: "Plus souvent que ne le disent les éditeurs : un seul service avec un seul type de client, une app rendue côté serveur qui appelle son propre backend, des API internes derrière un VPN, ou partout où un reverse proxy existant couvre déjà TLS et routage. Une gateway rentabilise son coût opérationnel quand il y a beaucoup de services, beaucoup de clients ou de vraies politiques à centraliser — pas avant."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'API Gateway pattern — microservices.io'
    url: 'https://microservices.io/patterns/apigateway.html'
  - name: 'Backend for Frontends — Sam Newman'
    url: 'https://samnewman.io/patterns/architectural/bff/'
  - name: 'Envoy Proxy (open source)'
    url: 'https://www.envoyproxy.io/'
  - name: 'Cloud Code & backend guide'
    url: 'https://docs.parseplatform.org/parse-server/guide/'
cta:
  title: "La porte d'entrée, déjà construite"
  text: "Back4app place une gateway gérée devant chaque app : authentification, limites de débit, routage vers les API générées automatiquement et Cloud Code — le tout appliqué à l'edge de la plateforme, sans aucune infrastructure de gateway à déployer ni à faire évoluer de votre côté."
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-15'
translationKey: api-gateway-architecture
---

**Une API gateway est une porte d'entrée gérée pour vos API : un point d'entrée unique qui route, authentifie et applique un rate limiting à chaque requête.** L'idée, c'est la centralisation : le travail transversal dont chaque endpoint a besoin (qui êtes-vous, à quel rythme pouvez-vous appeler, où va cette requête, que s'est-il passé) quitte N services pour rejoindre une seule couche de politiques que les clients ne peuvent pas contourner.

## Points clés

| Question | Réponse |
| --- | --- |
| Ce que c'est | Un point d'entrée unique : router, authentifier, limiter, transformer, observer |
| vs. load balancer | Le LB choisit une instance ; la gateway prend des décisions de politique au niveau de l'API |
| vs. reverse proxy | Une gateway *en est* un — avec un cerveau de politiques d'API en plus |
| vs. service mesh | Gateway = nord-sud (clients entrants) ; mesh = est-ouest (de service à service) |
| La question honnête | Savoir si vous en avez besoin — beaucoup de systèmes n'en ont pas encore besoin |

## Ce que fait la porte d'entrée

La liste des tâches d'une gateway, sous forme de configuration plutôt que de N copies de middleware — une route déclarative typique :

```yaml
# route de la gateway : une entrée, des politiques attachées
route: /orders/**
  service: orders-api:8080          # routage — la topologie reste privée
  auth: bearer-jwt                  # authentification à la porte
  rate_limit: 100/min per key       # quotas avant d'atteindre les backends
  transform:
    strip_headers: [X-Internal-*]   # traduire entre l'edge et l'intérieur
  timeout: 5s
  observe: log + trace + metrics    # un seul endroit pour tout observer
```

Côté client, une gateway gérée disparaît dans le SDK — un seul appel, avec les contrôles de la porte appliqués avant l'exécution de la moindre ligne de votre code :

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// One managed entry point: auth, rate limits, and routing applied per call
const receipt = await Parse.Cloud.run('placeOrder', { cartId: 'crt_812' });
// The platform's gateway verified the session, applied limits,
// and routed to the function — none of it in your code.
console.log(`Order ${receipt.orderId} confirmed`);
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// One managed entry point: auth, rate limits, and routing applied per call
final function = ParseCloudFunction('placeOrder');
final response = await function.execute(parameters: {'cartId': 'crt_812'});
if (response.success) {
  print('Order ${response.result['orderId']} confirmed');
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// One managed entry point: auth, rate limits, and routing applied per call
ParseCloud.callFunction("placeOrder",
                        parameters: ["cartId": "crt_812"]) { result in
  if case .success(let receipt) = result {
    print("Order confirmed: \(receipt)")
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// One managed entry point: auth, rate limits, and routing applied per call
val params = hashMapOf("cartId" to "crt_812")
ParseCloud.callFunctionInBackground<Map<String, Any>>("placeOrder", params) { receipt, e ->
  if (e == null) Log.d("Orders", "Order ${receipt["orderId"]} confirmed")
}
```

## Les quatre sosies, départagés

| | Reverse proxy | Load balancer | **API gateway** | Service mesh |
| --- | --- | --- | --- | --- |
| Question traitée | « Transmets ceci vers l'intérieur » | « Quelle instance ? » | **« Quel service, en avez-vous le droit, à quel débit ? »** | « Comment les services communiquent-ils en sécurité ? » |
| Trafic | Nord-sud | Nord-sud | **Nord-sud** | Est-ouest |
| Base de décision | Hôte/chemin | Santé + algorithme | **Politique d'API : auth, limites, forme** | Identité du service |
| Couche typique | L7 basique | L4/L7 | **L7, au niveau de l'API** | Des sidecars partout |
| Relation | Classe parente de la gateway | Généralement devant la gateway | — | Coexiste derrière elle |

```mermaid
flowchart LR
  accTitle: Architecture d'API gateway
  accDescr: Les clients web, mobile et partenaires envoient leurs requêtes à un load balancer placé devant une API gateway clusterisée, qui authentifie, applique les limites de débit et route vers les services internes ; les services et leur topologie restent privés derrière elle.
  W["Web"] --> LB["Load balancer"]
  M["Mobile"] --> LB
  P["Partenaires"] --> LB
  LB --> G["API gateway (clusterisée)<br/>auth · limites · routage ·<br/>transformation · observabilité"]
  G --> S1["Service des commandes"]
  G --> S2["Service des utilisateurs"]
  G --> S3["Service de recherche"]
```

La [description canonique du pattern](https://microservices.io/patterns/apigateway.html) ajoute la variante à connaître : le **[Backend-for-Frontend](https://samnewman.io/patterns/architectural/bff/)** — une gateway légère *par type de client*, chacune façonnant les réponses pour son client — qui échange davantage d'éléments à déployer contre la fin des API taille unique qui ne vont à personne.

## Les inconvénients, sans détour

La gateway centralise le pouvoir, et la centralisation se paie de quatre façons. **Point de défaillance unique :** tout passe par elle — faites-la tourner en cluster derrière un load balancer, ou acceptez que sa panne soit *la* panne. **Le nouveau goulot d'étranglement :** chaque équipe produit soumet désormais ses changements de configuration sur un seul composant partagé ; la gouvernance et l'outillage en libre-service font partie de l'adoption, ce ne sont pas des extras. **Le monolithe ressuscité :** la logique d'agrégation qui s'accumule dans la gateway reconstruit en silence l'application centralisée que vous aviez décomposée — gardez-la riche en politiques et pauvre en logique. **La prolifération de la configuration :** des centaines de routes avec des politiques par route, c'est une base de code ; relisez-la comme telle. Aucun de ces points ne plaide contre les gateways ; tous plaident contre les gateways adoptées à la légère.

## Cas d'usage courants

- **Porte d'entrée des microservices** — l'histoire fondatrice : de nombreux services, une seule API cohérente, une topologie libre d'évoluer derrière elle.
- **Produits multi-clients** — web, mobile et partenaires avec des auth, des formes et des limites différentes — le terrain de prédilection du BFF.
- **Monétisation d'API** — clés, plans, quotas et mesure de l'usage appliqués en un seul point.
- **Migrations** — le strangler pattern : la gateway route les anciens chemins vers le système legacy et les nouveaux vers son remplaçant, de façon invisible.
- **Politiques à l'edge** — CORS, TLS, hygiène des en-têtes et [rate limiting](/glossary/fr/rate-limiting-api/) (limitation de débit) appliqués une fois au lieu de N.

## En avez-vous besoin ? Matrice de décision

| Une gateway justifie sa place quand… | Passez-vous-en (ou reportez-la) quand… |
| --- | --- |
| De nombreux services se trouvent derrière une seule API | Un seul service sert un seul type de client |
| Les clients diffèrent par l'auth, la forme ou les limites | Un reverse proxy couvre déjà TLS + routage |
| Les politiques doivent être appliquées de façon centralisée | Les politiques ne sont qu'à un import de middleware |
| La topologie change plus vite que les clients | La topologie tient en une seule machine |
| Quelqu'un porte la gateway comme un produit | Personne ne l'exploiterait |

La réponse que la plupart des pages comparatives passent sous silence : **pas encore** est une architecture légitime. Ajoutez la porte quand il y a un bâtiment derrière.

## Limites et trade-offs

- **La disponibilité devient celle de la gateway.** Clusterisez-la, surveillez-la par health checks et simulez sa panne — la parade est standard et non optionnelle.
- **Un saut de latence, à mettre honnêtement en balance** avec les allers-retours et le middleware dupliqué qu'il supprime ; mesurez, ne présumez ni dans un sens ni dans l'autre.
- **L'agrégation est une pente glissante.** Composer des réponses est légitime ; la logique métier dans la gateway, c'est le pattern ESB avec un nouveau badge.
- **Les options open-source ont un coût d'exploitation.** D'excellentes gateways existent en open source (des stacks basés sur Envoy et leurs équivalents) — chacune est un système distribué que vous devez désormais faire tourner, mettre à niveau et sécuriser.
- **Les gateways gérées échangent le contrôle contre la tranquillité.** La porte exploitée par la plateforme est la bonne réponse précisément quand exploiter une gateway serait une corvée sans valeur différenciante.

## La gateway sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. La couche gateway est fournie avec la plateforme : chaque requête — REST, GraphQL, SDK ou appel Cloud Code, comme dans les onglets de code ci-dessus — entre par un edge géré qui authentifie sessions et clés, applique des limites de débit par app et route vers les API générées ou vers vos fonctions, la plateforme se chargeant du clustering et de la mise à l'échelle qui rendent une porte d'entrée sûre. La matrice de décision s'effondre : vous obtenez les garanties d'une gateway dès le premier jour, sans jamais avoir à posséder la porte.