Passerelle d'API ou maillage de services : lequel te faut-il, et à quel moment

Sur les schémas d'architecture qui circulent, la passerelle d'API et le maillage de services occupent deux branches voisines, au même rang, comme deux options entre lesquelles arbitrer. La question arrive telle quelle en réunion : « on met une gateway ou un service mesh ? »

La réponse dépend d'un point que la question ne mentionne pas : de quel trafic on parle. Celui qui arrive de l'extérieur, avec un client identifié, un quota, une facturation parfois. Ou celui qui circule entre tes propres services, dans ton réseau, sans utilisateur humain au bout.

Ces deux briques occupent deux étages distincts de la grille en quatre niveaux des patterns d'architecture d'API, et ce sont deux problèmes séparés, avec des propriétaires différents dans l'organisation. Les confondre mène à deux erreurs symétriques : installer un mesh pour faire de l'authentification d'API, ou pousser toute la logique de résilience interne dans la configuration de la passerelle. Cet article donne le critère qui tranche, l'état du terrain fin 2026, et le YAML qui va avec.

Le cas typique où la confusion coûte cher

Une équipe expose une API à des clients externes. Elle a besoin de clés d'API, de quotas par client, d'une documentation publiée, de journaux d'accès exploitables par le support. Elle lit un article sur le zero trust, installe un maillage de services sur son cluster, et découvre trois semaines plus tard que rien de ce qu'elle cherchait n'est couvert.

Le mesh sait chiffrer les communications entre services et vérifier l'identité de charge de travail qui appelle. Il ne sait pas qui est le client commercial derrière la requête, ne compte pas ses appels sur le mois, ne publie pas de portail développeur. Un mesh raisonne en identités d'infrastructure, une passerelle raisonne en consommateurs.

L'erreur inverse existe aussi, plus silencieuse. Une équipe met sa passerelle au milieu de tous les appels internes pour bénéficier des reprises et des coupe-circuits. Chaque appel entre deux services fait alors un aller-retour par le point d'entrée public, la latence double, et une panne de la passerelle devient une panne totale au lieu d'une simple indisponibilité externe.

Le critère qui tranche

Le raccourci le plus répandu oppose le trafic nord-sud, qui entre et sort du cluster, au trafic est-ouest, qui circule entre les services. Il donne une bonne première image, et Kong, qui édite l'une des passerelles les plus déployées, écrit pourtant dans sa propre documentation que ce découpage n'est pas rigoureux : le maillage a été pensé pour la connectivité entre microservices, mais il s'applique à d'autres architectures dès qu'il y a plusieurs services qui se parlent sur un réseau, y compris avec du monolithique ou du serverless.

Le critère plus fiable tient en une question : est-ce que l'appelant est une identité que ton métier connaît, ou une charge de travail que ton infrastructure connaît ? Un partenaire avec un contrat, un utilisateur avec un abonnement, une application tierce avec une clé, tout ça relève de la passerelle. Un pod qui appelle un autre pod relève du maillage.

Ce qui a changé sur le terrain

Trois évolutions rendent les comparatifs écrits avant 2024 partiellement caducs, et elles pèsent sur la décision.

Le retrait d'Ingress NGINX

Le 11 novembre 2025, le SIG Network de Kubernetes et le comité de réponse aux incidents de sécurité ont annoncé la retraite du contrôleur communautaire kubernetes/ingress-nginx, avec une maintenance au mieux jusqu'en mars 2026, puis plus aucune version, aucun correctif, aucun patch de sécurité. Le 29 janvier 2026, les comités Steering et Security Response ont publié une déclaration commune rappelant que ce composant sert environ la moitié des environnements cloud natifs et qu'aucune des alternatives n'est un remplacement direct.

Point à ne pas mélanger : l'API Ingress de Kubernetes elle-même n'est pas supprimée, elle est gelée en fonctionnalités. Le serveur web NGINX et le contrôleur commercial de F5 ne sont pas concernés non plus. La retraite vise un projet précis, et elle a mis des milliers d'équipes en position de choisir une nouvelle brique d'entrée, ce qui explique le retour du sujet dans les réunions d'architecture.

Gateway API a pris la place d'Ingress

Gateway API est passée en version 1.0 en octobre 2023, comme projet distinct avec son propre cycle de publication et des CRD installées séparément du cluster. Elle sépare les responsabilités en trois ressources : la classe de passerelle pour l'équipe infrastructure, la passerelle pour l'exploitant du cluster, les routes pour l'équipe applicative. Ce découpage supprime l'accumulation d'annotations propriétaires qui rendait les Ingress non portables d'un contrôleur à l'autre.

Le maillage sans sidecar est devenu une option sérieuse

Le reproche historique fait au mesh porte sur le proxy injecté dans chaque pod : mémoire consommée, démarrages à ordonnancer, débogage compliqué. Le mode ambient d'Istio, annoncé en 2022, est passé en disponibilité générale avec la version 1.24 le 7 novembre 2024. Il remplace le proxy par pod par un proxy de nœud pour la couche 4, avec un proxy de couche 7 optionnel par espace de noms. Le calcul économique du mesh n'est plus celui de 2021, ce qui ne le rend pas gratuit pour autant.

Le même objet, deux usages

Détail qui surprend beaucoup de gens : la même ressource HTTPRoute sert pour les deux trafics. Ce qui change, c'est l'objet auquel elle s'attache. Les exemples ci-dessous ciblent la version stable gateway.networking.k8s.io/v1.

Trafic entrant : la route pointe vers une passerelle.

# Route nord-sud : le client externe entre par la Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: catalogue-public
spec:
  parentRefs:
    - name: gateway-public
  hostnames:
    - "api.exemple.fr"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1/produits
      backendRefs:
        - name: catalogue
          port: 8080

Trafic interne : la même ressource s'attache à un Service au lieu d'une Gateway. C'est la contribution de l'initiative GAMMA, lancée en 2022 au sein du sous-projet Gateway API, et intégrée au canal standard depuis la version 1.1.0.

# Route est-ouest : répartition 90/10 entre deux versions internes
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: catalogue-interne
spec:
  parentRefs:
    - kind: Service
      group: ""
      name: catalogue
  rules:
    - backendRefs:
        - name: catalogue-v1
          port: 8080
          weight: 90
        - name: catalogue-v2
          port: 8080
          weight: 10

Une règle à connaître avec ce second mode : dès qu'au moins une route est attachée à un Service, les requêtes qui ne correspondent à aucune règle sont rejetées. Sans route attachée, tout passe comme avant. Cette bascule silencieuse surprend au premier déploiement.

Les pièges

Adopter le mesh pour l'observabilité, sans rien instrumenter

Le maillage fournit les métriques de trafic entre services et propage les identifiants de trace. Il ne crée pas les spans internes de ton application, et il ne sait pas qu'une requête a passé 800 millisecondes dans une requête SQL. Sans instrumentation applicative, tu obtiens une carte des appels sans le contenu des appels.

Croire que le mTLS remplace l'autorisation métier

Le chiffrement mutuel prouve qu'un service a le droit d'appeler un autre service. Il ne dit rien sur le fait que l'utilisateur final derrière la requête ait le droit de consulter cette facture. La vérification des droits reste dans le code, avec le contexte utilisateur transporté explicitement. Les articles sur JWT ou session et sur les risques d'une application non sécurisée traitent cette partie applicative.

Mettre la logique métier dans la configuration de la passerelle

Une transformation par ici, une agrégation par là, une règle de tarification qui finit en plugin. Au bout de deux ans, la passerelle contient un programme que personne ne sait tester en local et qui n'apparaît dans aucune revue de code. Quand un besoin de composition apparaît, un BFF écrit dans un vrai langage se maintient et se teste, ce que la configuration ne permet pas.

Choisir avant d'avoir un incident à raconter

Mon critère personnel avant d'installer une couche d'infrastructure : être capable de nommer deux incidents des six derniers mois que cette couche aurait évités ou raccourcis. Si la liste est vide, la couche arrive trop tôt, et sa complexité produira ses propres incidents avant d'avoir servi.

Oublier que quelqu'un doit exploiter la brique

Passerelle comme maillage, il faut une personne capable de lire les journaux du proxy, de corréler une erreur 503 avec une politique mal écrite, et de suivre les mises à jour. Sur une équipe de cinq développeurs sans profil plateforme, une passerelle managée par l'hébergeur coûte moins cher qu'un contrôleur auto-hébergé, même si la facture mensuelle est plus visible. Ce raisonnement rejoint les douze facteurs : ce qui compte, c'est ce que l'équipe sait exploiter en production.

Un ordre de mise en place qui fonctionne

1. Exposer proprement, avec du TLS et un point d'entrée unique. C'est l'étape que couvre l'article sur la mise en ligne d'un projet.
2. Centraliser l'authentification et les quotas dans la passerelle, une fois qu'il y a plusieurs consommateurs à distinguer.
3. Instrumenter l'application avec des traces et des métriques, avant toute couche réseau supplémentaire.
4. Regarder du côté du maillage quand les incidents viennent des appels internes, et pas avant.

Les équipes qui suivent cet ordre passent souvent des années sans jamais avoir besoin de l'étape 4, et ce n'est pas un retard. Pour situer cette décision parmi les autres, l'article sur les quatre niveaux des patterns d'API donne la vue d'ensemble. Pour la partie exploitation qui précède tout ça, les formations Docker pour développeurs web et CI/CD avec GitHub Actions couvrent les prérequis que le maillage suppose acquis.

Questions fréquentes