Fin d'Ingress NGINX en 2026 : que faire pour votre entreprise ?

Un immeuble peut tourner des années avec une porte que personne ne surveille. De l'extérieur, rien ne change : le courrier arrive, l'ascenseur monte, les habitants entrent et sortent. C'est la situation d'environ la moitié des environnements cloud depuis mars 2026. Leur portier logiciel, Ingress NGINX, a pris sa retraite. Les applications continuent de fonctionner. Mais plus personne ne répare la serrure.

Si votre entreprise héberge ses applications sur Kubernetes, ou si votre prestataire le fait pour vous, cet article vous concerne probablement. Voici ce qui s'est passé, comment vérifier votre situation en une seule commande, et ce que coûte réellement un changement de portier.

Ingress NGINX : le portier de la moitié du cloud

Kubernetes est la technologie qui fait tourner une grande partie des applications modernes hébergées dans le cloud. Pour qu'une application soit accessible depuis internet, il faut un composant qui reçoit les visiteurs, vérifie où ils vont et les dirige vers le bon service. C'est le rôle d'un contrôleur d'entrée : le portier de l'immeuble.

Ingress NGINX était le portier le plus répandu. Selon une étude interne de Datadog citée par le comité de pilotage de Kubernetes, environ 50 % des environnements cloud natifs reposaient sur lui. Des banques, des sites marchands, des jeunes pousses, des services publics.

Le paradoxe : ce composant critique était entretenu par une ou deux personnes, bénévoles, sur leur temps libre. Pendant des années, les mainteneurs ont appelé à l'aide publiquement. Personne n'est venu.

Pourquoi Kubernetes a arrêté le projet

En janvier 2026, les comités de pilotage et de sécurité de Kubernetes ont publié un communiqué commun, un format très rare, pour confirmer la fin du projet en mars 2026. Depuis cette date : plus aucun correctif de bug, plus aucune mise à jour de sécurité, plus rien.

Les raisons tiennent en deux points. D'abord le manque de bras : impossible d'entretenir sérieusement un logiciel utilisé par la moitié du cloud avec deux bénévoles. Ensuite la dette technique : la grande flexibilité d'Ingress NGINX, longtemps son atout, est devenue son talon d'Achille. Certains choix de conception aggravent les failles de sécurité au lieu de les contenir. Le comité est explicite : même avec des renforts, le projet ne serait plus réparable.

Ce n'est pas une hypothèse d'école. En mars 2025, une série de failles baptisée IngressNightmare, dont une notée 9,8 sur 10 en gravité, permettait de prendre le contrôle d'un cluster entier via ce composant. Elle a été corrigée à temps. La prochaine ne le sera pas.

Le piège : tout continue de fonctionner

C'est le point que le communiqué souligne en gras : les déploiements existants continueront de tourner. Aucune alerte, aucun écran rouge, aucune panne. La porte reste ouverte, l'immeuble vit sa vie, et rien n'indique que la loge est vide.

Un serveur en panne se remarque en dix minutes. Un composant non maintenu peut rester invisible pendant des mois, jusqu'au jour où une faille est découverte, publiée, puis exploitée en masse. Les attaquants lisent les mêmes communiqués que vous : ils savent que tout ce qui sera trouvé après mars 2026 ne sera jamais corrigé.

Comment savoir si votre entreprise est concernée

Si vous avez une équipe informatique interne, la vérification tient en une ligne, à exécuter avec les droits d'administrateur du cluster :

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

Si la commande renvoie des résultats, vous êtes concerné.

Si votre informatique est confiée à un prestataire, trois questions suffisent, à poser par écrit :

1. Utilisons-nous Ingress NGINX, et sur quels environnements ?
2. Si oui, quel est le plan de migration, vers quelle alternative, et à quelle échéance ?
3. En attendant la migration, quelles mesures limitent l'exposition de ce composant ?

Un prestataire sérieux répond aux trois avec des dates. Une réponse du type "on gère, ne vous inquiétez pas" mérite une deuxième question.

Les alternatives sérieuses et le coût réel d'une migration

Le successeur désigné par Kubernetes s'appelle Gateway API : même rôle de portier, conception plus récente, standard maintenu par le projet lui-même. Il existe aussi des contrôleurs tiers éprouvés, comme Traefik, HAProxy ou Envoy Gateway.

Le communiqué prévient honnêtement : aucune de ces solutions n'est un remplacement à l'identique. Les règles de filtrage écrites pour Ingress NGINX, souvent sous forme d'annotations spécifiques, doivent être traduites, testées, validées. C'est un chantier d'ingénierie, pas un clic.

Un ordre de grandeur, constaté sur des migrations réelles : pour une entreprise avec une dizaine d'applications exposées sur deux environnements, comptez un à deux jours d'audit, un à deux jours pour choisir et maquetter l'alternative, puis une demi-journée à deux jours par application selon la complexité des règles. Soit dix à vingt jours d'ingénierie, étalés sur six à huit semaines pour migrer application par application, sans coupure de service. Une infrastructure plus modeste, avec deux ou trois applications simples, se migre en moins d'une semaine.

À mettre en face : le coût d'un incident sur la porte d'entrée. Une faille comme IngressNightmare donnait accès à l'ensemble des secrets du cluster, mots de passe et certificats compris.

Les erreurs classiques d'un changement de portier

Trois pièges reviennent souvent :

• Confondre "ça tourne" et "c'est sûr". La disponibilité ne dit rien de la sécurité : c'est précisément le piège de cette retraite silencieuse.
• Migrer dans la précipitation à la rentrée. L'été, l'activité ralentit et le trafic aussi : c'est la meilleure fenêtre de l'année pour tester une nouvelle porte d'entrée, application par application.
• Traduire les règles sans les relire. Une migration est l'occasion de faire le ménage : des règles accumulées depuis des années ne méritent pas toutes d'être reconduites. Moins de règles, c'est moins de surface d'attaque.

Choisir son gardien plutôt que subir la loge vide

La retraite d'Ingress NGINX n'est pas une catastrophe : c'est la décision responsable d'un projet qui refuse de laisser croire qu'une porte est gardée quand la loge est vide. La catastrophe, ce serait de ne pas vérifier.

Concrètement, cette semaine : posez les trois questions ci-dessus à votre équipe ou à votre prestataire. Si la réponse confirme la présence d'Ingress NGINX sans plan de migration daté, l'été est le bon moment pour en bâtir un, posément, avant la rentrée.

Chez Autensai, nous accompagnons les entreprises françaises sur ce type de chantier : audit de l'existant, choix de l'alternative, migration sans coupure. Un échange de trente minutes suffit en général à savoir où vous en êtes : prendre rendez-vous.

Une porte ouverte n'a jamais arrêté personne. Un portier, si.