Cinq migrations qui transforment les équipes d'infrastructure en 2026

Le réseautage en 2026 n’est pas dicté par une seule tendance — c’est la pression des délais qui prime. Un contrôleur d’entrée largement utilisé a été mis hors service. Une grande bibliothèque TLS a changé ses paramètres par défaut. Une méthode de proxy vieille de dix ans commence enfin à faire ses preuves en production. Un service mesh a remplacé son API d’extensibilité. Et l’épuisement de l’IPv4 est passé d’un sujet de discussion à un véritable projet de migration dans les organisations soumises à des mandats fédéraux. Aucun de ces points n’est hypothétique — ils obligent déjà les équipes d’infrastructure et de plateforme à agir. Voici où en sont chacun de ces éléments.

1. Ingress-NGINX est mis hors service — voici la véritable trajectoire de migration de l’API Gateway

La déclaration principale est exacte, mais il est utile d’être précis sur ce qui s’est réellement passé, car la terminologie a causé une confusion réelle sur les calendriers de migration.

Ce qui a pris fin. Le contrôleur kubernetes/ingress-nginx, maintenu par la communauté et géré par le SIG Network de Kubernetes, a atteint un niveau de maintenance à effort limité en mars 2026, et le dépôt a été officiellement archivé et rendu en lecture seule le 24 mars 2026. La mise hors service a été annoncée pour la première fois par le Security Response Committee le 11 novembre 2025, puis renforcée dans une déclaration conjointe du Kubernetes Steering Committee et du Security Response Committee le 29 janvier 2026, qui estimait que la moitié des environnements cloud-native étaient concernés. La cause principale n’était pas une faille architecturale unique — c’était l’épuisement des mainteneurs (le projet fonctionnait avec un ou deux volontaires) combiné à une dette technique, notamment les annotations arbitraires de snippets de configuration NGINX, que les mainteneurs considéraient comme une vulnérabilité de sécurité irrécupérable plutôt qu’une fonctionnalité.

Ce qui n’a pas pris fin. Deux distinctions importantes, souvent confondues : - L’API Ingress de Kubernetes elle-même n’est pas dépréciée ni en voie de suppression — elle est figée en fonctionnalités, avec un développement actif désormais concentré sur Gateway API. - Contrôleur NGINX Ingress (nginxinc/kubernetes-ingress), maintenu commercialement et en open source par F5/NGINX Inc., est une base de code totalement différente et n’est pas affecté par cette mise hors service.

Les déploiements existants de ingress-nginx continuent de fonctionner ; rien ne se brise du jour au lendemain. Ce qui s’arrête, ce sont les nouvelles versions, les correctifs de bugs, et — surtout — les patches CVE. Cela commence déjà à représenter un vrai risque : quatre CVE de haute gravité ont été divulgués simultanément le 2 février 2026, suivi en mai d’un dépassement de tampon critique dans le heap (« NGINX Rift », CVE-2026-42945), sans correctif en amont. Dans les environnements soumis à des exigences strictes, « logiciel en fin de vie dans le chemin de requête L7 » est désormais une constatation courante lors des audits SOC 2 / PCI-DSS / ISO 27001. Certaines plateformes gérées (Azure AKS Application Routing, certaines configurations d’ingress GKE) ont promis des patchs étendus par le fournisseur jusqu’en novembre 2026 — c’est une étape intermédiaire, pas une solution.

Où en est réellement Gateway API. La formulation initiale « migrer vers Gateway API v1.4 » est déjà dépassée. La version 1.4.0 a atteint la disponibilité générale (GA) le 6 octobre 2025, avec l’ajout de BackendTLSPolicy et TLSRoute en GA. Depuis : - v1.5 est sorti le 27 février 2026 — la plus grande mise à jour à ce jour, promouvant six fonctionnalités auparavant expérimentales (dont ListenerSet et la graduation complète de TLSRoute) vers le canal Standard/GA, et introduisant un modèle de version basé sur un train de versions, inspiré du processus SIG Release de Kubernetes. - v1.6 est la version en cours à la mi-2026, avec des manifests d’installation standard et expérimentale publiés à github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/.

L’outil de migration réel. ingress2gateway, maintenu par le SIG Network, a atteint 1.0 le 20 mars 2026 — en synchronisation délibérée avec la fin de vie. L’outil avant la version 1.0 ne comprenait que trois annotations ingress-nginx ; la version 1.0 supporte plus de 30 annotations courantes (CORS, TLS backend, correspondance regex, réécritures de chemin) et chaque annotation est accompagnée de tests d’intégration au niveau du contrôleur qui comparent le comportement en temps réel, pas seulement la structure YAML. Il a aussi introduit une architecture d’émetteur plug-in pour cibler des extensions spécifiques à une implémentation :

# Installation
ngo install github.com/kubernetes-sigs/ingress2gateway@v1.0.0

# Conversion en mode dry-run de tout dans un namespace, annotations ingress-nginx
ingress2gateway print --providers ingress-nginx --namespace production > gwapi.yaml

# Cibler une extension spécifique (ex. Envoy Gateway)
ingress2gateway print --providers ingress-nginx --emitter envoy-gateway > envoy-gwapi.yaml

L’outil émettra un avertissement pour tout ce qu’il ne peut pas traduire fidèlement (par exemple, nginx.ingress.kubernetes.io/proxy-body-size n’a pas d’équivalent direct dans Gateway API), plutôt que de supprimer silencieusement le comportement — il faut toujours vérifier ses avertissements avant la migration, et valider d’abord dans un cluster non production. Plus de sept implémentations (Cilium, Contour, Envoy Gateway, GKE Gateway, Istio, etc.) sont déjà conformes au canal actuel, offrant ainsi un vrai choix de fournisseur pour la migration.

2. TLS post-quantique passé du brouillon à la norme par défaut

Ce point résiste bien à l’argument « récolter maintenant, déchiffrer plus tard » — le trafic chiffré avec une clé classique aujourd’hui peut être capturé et stocké, puis déchiffré rétroactivement dès qu’un ordinateur quantique cryptographiquement pertinent sera disponible. Ce qui a changé, c’est que la solution n’est plus expérimentale.

OpenSSL 3.5 (sorti en avril 2025) a été le point d’inflexion : il a fait du groupe d’échange de clés hybride — combinant X25519 elliptique classique et ML-KEM-768 post-quantique standardisé par NIST — la clé par défaut pour TLS 1.3, et non une option à activer. Le nom enregistré par l’IANA est X25519MLKEM768 (codepoint 0x11ec) ; une alternative orientée FIPS, SecP256r1MLKEM768 (codepoint 0x11eb), associe ML-KEM-768 à la courbe P-256. En raison de son caractère hybride, la session reste sécurisée tant que l’une ou l’autre moitié tient — une faille de ML-KEM ou une future faille de X25519 seule ne suffit pas à compromettre la clé de session. C’est la construction décrite dans le brouillon de l’IETF draft-ietf-tls-hybrid-design.

Les préoccupations pratiques pour ceux qui terminent TLS à la périphérie :

• La surcharge est négligeable pour l’échange lui-même. L’échange hybride fonctionne à peu près dans la même gamme que X25519 classique — quelques dizaines de milliers d’opérations par seconde sur un seul cœur — donc le coût CPU n’est pas un problème.
• La taille de la charge utile est le vrai coût. Les clés publiques ML-KEM-768 font environ 1,2 Ko, ce qui augmente la taille des ClientHello/ServerHello. Si le groupe préféré du serveur nécessite une clé que le client n’a pas envoyée à l’avance, vous obtenez un HelloRetryRequest et un aller-retour supplémentaire. Chrome et Firefox évitent cela en pré-calculant des clés pour X25519MLKEM768 et X25519 simple ; tous les clients ne le font pas. Surveillez la latence du handshake P99 après activation de la préférence PQC — c’est là qu’une régression pourrait apparaître.
• L’adoption est déjà large. Chrome (v131, novembre 2024) et Firefox (v135, février 2025) supportent le schéma hybride ; le JDK l’a intégré dans ses versions early-access en 2026 ; et toute build NGINX ou HAProxy compilée avec OpenSSL 3.5+ l’inclut.

La pression réglementaire est réelle et datée : la suite CNSA 2.0 des États-Unis fixe une date limite stricte pour les systèmes de sécurité nationale, et la feuille de route PQC coordonnée de l’UE vise des secteurs à haut risque selon un calendrier similaire. Pour un proxy Layer-7, la migration pratique consiste plus à « recompiler avec OpenSSL 3.5+ et surveiller » qu’à un remplacement complet — ce qui est une opération bien plus simple que ce que la notion de « quantum-proofing » laisse entendre.

3. MASQUE et CONNECT-UDP : la norme est plus ancienne qu’on ne le pense, les déploiements sont nouveaux

À corriger d’emblée : CONNECT-UDP n’est pas une idée émergente — c’est une norme IETF terminée, RFC 9298, depuis août 2022. Ce qui est réellement nouveau en 2026, c’est le déploiement à l’échelle de la production et les extensions qui s’y superposent.

MASQUE (Multiplexed Application Substrate over QUIC Encryption) est une famille de spécifications, pas une seule RFC. La chaîne de dépendances : RFC 9000 (transport QUIC) → RFC 9221 (datagrammes QUIC non fiables) → RFC 9114 (HTTP/3, qui rétrofit la méthode Extended CONNECT) → RFC 9297 (Datagrammes HTTP et protocole Capsule — le mécanisme pour transporter des données multiplexées dans une connexion HTTP) → RFC 9298 (CONNECT-UDP lui-même) → RFC 9484 (CONNECT-IP, octobre 2023, étendant le modèle au tunneling IP complet). Un client ouvre une requête Extended CONNECT avec :protocol: connect-udp, et le proxy relaie les datagrammes UDP vers la cible, encapsulés en Datagrammes HTTP sur une connexion QUIC déjà chiffrée. Parce qu’il fonctionne sur le port 443 aux côtés du HTTPS classique, le trafic tunnelé — WebRTC, jeux, WireGuard, etc. — est structurellement indiscernable d’une navigation normale pour tout middlebox n’ayant pas cassé TLS.

Ce n’est pas théorique : MASQUE supporte déjà Apple iCloud Private Relay et la flotte WARP de Cloudflare, et c’est une option active dans les produits Zero Trust d’entreprise.

Ce qui fait encore évoluer la norme : - draft-ietf-masque-connect-udp-listen (actuellement draft -13, publié le 30 juin 2026) étend CONNECT-UDP au UDP initié par le serveur — utile pour des protocoles peer-to-peer comme WebRTC que CONNECT-UDP seul ne supporte pas proprement, donnant aux proxies MASQUE une voie pour remplacer les relais STUN/TURN. - draft-ietf-httpbis-connect-tcp propose une alternative basée sur un modèle pour le TCP, pour combler des lacunes comme la possibilité d’héberger plusieurs services proxy distincts derrière un seul serveur HTTP. - Les implémentations open source mûrissent rapidement : masque-go (basé sur quic-go) supporte à la fois client et proxy pour RFC 9298, et des outils de tunneling généralistes comme gost demandent à ajouter le support MASQUE pour transporter des protocoles comme WireGuard via HTTP/3.

Pour les équipes d’infrastructure, la conclusion pratique est moins « adopter un protocole à la pointe » et plus « prévoir que les pare-feux d’entreprise, construits autour de l’idée de bloquer les ports UDP non standard », deviennent de moins en moins efficaces par conception — ce qui peut jouer en votre faveur ou non, selon que vous construisez le tunnel ou que vous cherchez à le voir.

4. Extensibilité des proxies : WasmPlugin est dépassé, pas seulement populaire

C’est le point où la formulation initiale doit être le plus corrigée — non pas parce que la technologie est fausse, mais parce que « filtres Wasm interchangeables à chaud » décrit la période 2021–2025, pas l’état actuel, et le paysage a encore évolué récemment.

Istio a introduit l’extensibilité Wasm avec le CRD WasmPlugin dès Istio 1.12 (2021), remplaçant les anciens patchs fragiles EnvoyFilter pour ajouter une logique personnalisée au plan de données Envoy. La mécanique de base reste exacte : un plugin est un module WebAssembly sandboxé (compilé depuis Rust, Go/TinyGo, C++, ou AssemblyScript avec le SDK Proxy-Wasm), distribué via un registre OCI, et le service d’extension d’Envoy (ECDS) charge en direct une nouvelle version sans redémarrage ni perte de connexions — il suffit de changer une balise OCI, et Envoy récupère et échange le module en temps réel.

Ce qui a changé, c’est la surface d’API au-dessus de cette mécanique. Istio 1.30 a introduit l’API TrafficExtension, qui unifie l’extensibilité Wasm et Lua sous une même ressource, et devient désormais le mécanisme d’extensibilité recommandé — WasmPlugin fonctionne toujours (Istio convertit en interne les ressources WasmPlugin existantes en TrafficExtension avant de générer la configuration Envoy), mais tout nouveau travail doit cibler la nouvelle API :

apiVersion: extensions.istio.io/v1alpha1
kind: TrafficExtension
metadata:
  name: basic-auth-gateway
spec:
  targetRefs:
    - kind: Gateway
      group: gateway.networking.k8s.io
      name: bookinfo-gateway
  phase: AUTHN
  wasm:
    url: oci://ghcr.io/istio-ecosystem/wasm-extensions/basic_auth:1.12.0
    pluginConfig:
      basic_auth_rules:
        - prefix: "/productpage"
          request_methods: ["GET", "POST"]

TrafficExtension formalise aussi Lua comme une option de premier ordre, plus légère — scripts inline sans étape de distribution de module, HTTP-only (couche 7), avec une empreinte mémoire significativement plus petite que Wasm (environ 20–26 MiB, quel que soit le degré de concurrence, contre 110–290 MiB pour Wasm selon la charge). La recommandation pratique : privilégier Lua pour la manipulation d’en-têtes simple, la journalisation ou le routage conditionnel, et réserver Wasm pour des extensions nécessitant de véritables tests, une gestion de version, et une portabilité entre versions d’Envoy — flux d’authentification personnalisés, logique de limitation de débit complexe, transformation de charge utile.

Une note éditoriale à signaler : ce sujet recoupe largement des articles précédents sur la blog, notamment sur Proxy-Wasm et l’ambient mesh d’Istio. La nouveauté réelle et encore non publiée ici concerne spécifiquement l’API TrafficExtension et sa supériorité sur WasmPlugin — il serait judicieux de commencer par cette perspective si vous traitez cette section, ou de la supprimer si vous souhaitez éviter tout chevauchement.

5. Clusters Kubernetes uniquement IPv6 : NAT64/DNS64 passe de laboratoire à obligation en production

La fatigue dual-stack décrite ici est précise et, dans un cas bien documenté, n’est plus optionnelle. ESnet — le réseau scientifique du Department of Energy des États-Unis — a publié sa transition vers Kubernetes uniquement IPv6 utilisant Cilium, sous contrainte d’un mandat fédéral pour éliminer IPv4. Leur principal obstacle pratique n’était pas la couche réseau elle-même — c’était des adresses IPv4 codées en dur dans le code applicatif, qui n’apparaissaient qu’une fois IPv4 disparu. Ils ont utilisé le Multi-pool IPAM de Cilium pour attribuer à chaque namespace son propre préfixe /64, permettant une micro-segmentation propre sans masquer l’adresse.

Le mécanisme central n’a pas changé conceptuellement, mais les outils ont mûri :

• NAT64 réalise une traduction stateful entre pods IPv6-only et internet IPv4, utilisant le préfixe connu 64:ff9b::/96 (RFC 6052). Jool reste l’implémentation open-source la plus courante et en production.
• DNS64 synthétise des enregistrements AAAA pour des domaines ne publiant que des A, en préfixant l’adresse IPv4 avec le préfixe NAT64 — permettant à un client IPv6-only de résoudre et atteindre un service IPv4-only de façon transparente. CoreDNS propose un plugin DNS64 ; Unbound et BIND sont aussi courants.
• Une option plus récente à surveiller : kubernetes-sigs/nat64, un projet expérimental explorant un agent NAT64 en eBPF dans le cluster — visant à éviter la surcharge opérationnelle d’un NAT64/DNS64 externe dédié, qui reste la pratique la plus courante (mais plus lourde).

# Exemple : résolveur DNS64 en add-on de cluster
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dns64
  namespace: network-services
spec:
  replicas: 3
  selector:
    matchLabels: { app: dns64 }
  template:
    metadata:
      labels: { app: dns64 }
    spec:
      containers:
        - name: unbound
          image: mvance/unbound:latest
          ports:
            - containerPort: 53
              protocol: UDP
            - containerPort: 53
              protocol: TCP

Un point à noter pour le cloud : sur EKS, l’endpoint API du cluster n’est accessible qu’en IPv4, même si le cluster est IPv6-only — donc en pratique, « IPv6-only » signifie encore « IPv6-only pour le trafic pod-pod et pod-internet », avec une transition NAT64/DNS64 nécessaire à la frontière, pas une élimination totale d’IPv4. Cette nuance est importante pour ceux qui écrivent un guide de migration « go IPv6-only » — les pods peuvent être IPv6-only, mais le plan de contrôle ne l’est généralement pas.

Le fil conducteur

Aucun de ces cinq sujets n’est de la hype — chacun est motivé par une contrainte externe forte : un contrôleur mis hors service avec une date limite fixe, une norme cryptographique déjà déployée, une RFC vieille de dix ans qui voit enfin une adoption concrète, une API qui remplace sa propre version dans un service mesh majeur, et un mandat fédéral qui pousse à une migration en production. C’est un filtre utile pour décider de ce qui vient ensuite : pas « ce qui est techniquement intéressant » mais « ce qui a une échéance ».

---

Sources

Fin de vie d’Ingress-NGINX / Gateway API - Communiqué conjoint du Kubernetes Steering + Security Response Committees — https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/ - Historique des releases/archives de kubernetes/ingress-nginx — https://github.com/kubernetes/ingress-nginx/releases - Annonce de Ingress2Gateway 1.0 — https://kubernetes.io/blog/2026/03/20/ingress2gateway-1-0-release/ - Notes de version Gateway API v1.4 — https://kubernetes.io/blog/2025/11/06/gateway-api-v1-4/ - Notes de version Gateway API v1.5 — https://kubernetes.io/blog/2026/04/21/gateway-api-v1-5/ - Dépôt Gateway API (version v1.6.0 en cours) — https://github.com/kubernetes-sigs/gateway-api - Suivi CVE de la fin de vie d’Ingress-NGINX — https://www.herodevs.com/blog-posts/ingress-nginx-end-of-life-2026-migration-and-support

TLS post-quantique - OpenSSL Corporation, aperçu de la préparation post-quantique — https://openssl-corporation.org/post-quantum.html - OpenSSL 3.5, paramètres par défaut hybrides PQC — https://faisalyahya.com/access-control/openssl-3-5-entering-the-post-quantum-era/ - Modèles de déploiement TLS post-quantique en production — https://www.systemshardening.com/articles/network/tls-post-quantum-hybrid-deployment/ - Cryptographie post-quantique dans Kubernetes — https://kubernetes.io/blog/2025/07/18/pqc-in-k8s/

MASQUE / CONNECT-UDP - Explication du protocole MASQUE — https://http.dev/masque - Architecture MASQUE et dépendances RFC — https://instatunnel.substack.com/p/masque-the-http3-tunneling-protocol - draft-ietf-masque-connect-udp-listen — https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp-listen/

Extensibilité des proxies - Introduction à l’API TrafficExtension d’Istio — https://istio.io/latest/blog/2026/traffic-extension-api/ - Concepts d’extensibilité d’Istio (Wasm vs. Lua) — https://istio.io/latest/docs/concepts/extensibility/ - Référence WasmPlugin — https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/

Clusters IPv6-only / NAT64 - Cas d’utilisation IPv6 native de Cilium (ESnet) — https://cilium.io/use-cases/ipv6/ - kubernetes-sigs/nat64 (agent NAT64 eBPF) — https://github.com/kubernetes-sigs/nat64 - Contraintes réseau EKS IPv6 — https://aws.github.io/aws-eks-best-practices/networking/ipv6/

---

Changelog

Supprimé : blocs de métadonnées SEO, mots-clés cibles, et cadre promotionnel « insight éditorial » du brouillon source — rien de cela n’est contenu de l’article.

Corrigé : - « Gateway API v1.4 » mis à jour partout — v1.4 était la version au moment de l’annonce de fin de vie d’ingress-nginx, mais l’API a depuis évolué jusqu’à v1.6 (actuelle). L’article reflète maintenant la version en cours et cite les fonctionnalités spécifiques ajoutées à chaque release. - Clarifié que la fin de vie d’ingress-nginx a été principalement causée par l’épuisement des mainteneurs et la dette technique accumulée (notamment l’annotation « snippets »), et non par une faille de sécurité architecturale unique comme le laissait entendre le brouillon. - Distinction explicite entre le projet kubernetes/ingress-nginx mis hors service et le contrôleur maintenu commercialement et en open source par F5/NGINX Inc. — ces deux contrôleurs sont souvent confondus. - Correction de la section MASQUE/CONNECT-UDP : CONNECT-UDP est une norme terminée (RFC 9298) depuis août 2022, pas un mécanisme émergent — la nouveauté en 2026 concerne la mise en déploiement à grande échelle et les extensions en cours, pas la nouveauté du protocole lui-même. - Ajout des codepoints IANA exacts pour les groupes hybrides PQC (X25519MLKEM768 = 0x11ec, SecP256r1MLKEM768 = 0x11eb) et mention du brouillon IETF (draft-ietf-tls-hybrid-design) qui définit la construction hybride.

À considérer pour jugement éditorial : La section 4 (extensibilité des proxies / WasmPlugin) recoupe beaucoup de contenus précédents sur Proxy-Wasm et l’ambient mesh d’Istio. La reformuler en insistant sur l’API TrafficExtension d’Istio 1.30, qui la remplace, est recommandé pour éviter le chevauchement.

Ajouté : exemples concrets en CLI/YAML pour ingress2gateway, TrafficExtension, et une déploiement DNS64 ; identifiants CVE précis et dates pour la sécurité d’ingress-nginx ; étude de cas réelle d’ESnet/Cilium sur migration IPv6-only ; nuance sur le contrôle IPv4-only du plan de contrôle EKS.