Les entreprises passent rapidement de l’expérimentation de l’IA à son exploitation opérationnelle. Cette évolution modifie leurs besoins en matière d’infrastructure de mise à disposition des applications.
Pendant des années, la gestion du trafic Kubernetes a souvent été considérée comme un simple détail d’implémentation technique. Les équipes chargées des plateformes choisissaient un contrôleur d’entrée, les équipes applicatives configuraient les routes et les équipes de sécurité ajoutaient des contrôles là où elles le pouvaient. Ce modèle fonctionnait lorsque le principal défi consistait à assurer le fonctionnement des applications web et des API. Il est moins adapté dès lors que la même plateforme doit prendre en charge des applications modernes, des API distribuées, des politiques de sécurité et des charges de travail d’inférence d’IA qui mobilisent des ressources de calcul rares et coûteuses.
Le rapport F5 2026 sur l’état de la stratégie applicative montre pourquoi cet enjeu est aujourd’hui crucial : 78 % des organisations exécutent elles-mêmes leurs inférences d’IA, et 52 % ont recours à l’orchestration multimodèle pour adapter et étendre leurs modèles d’IA. Concrètement, les entreprises ne se contentent pas de solliciter un modèle unique par l’intermédiaire d’un seul service. Elles exécutent des inférences dans différents environnements, coordonnent plusieurs modèles et intègrent l’IA à l’architecture de leurs applications en production.
L’IA confère un nouveau caractère d’urgence à un défi de longue date pour les entreprises : comment donner aux équipes la rapidité dont elles ont besoin tout en maintenant la gouvernance, la sécurité et la cohérence opérationnelle.
F5 NGINX Gateway Fabric contribue à répondre à cette question en réunissant trois fonctionnalités importantes : la conformité à Gateway API 1.5, l’intégration avec F5 WAF for NGINX et la prise en charge de l’extension Inference de Gateway API. Ensemble, ces fonctionnalités ouvrent la voie à une approche plus standardisée, sécurisée et adaptée à l’IA pour la gestion du trafic Kubernetes.
“La passerelle ne sert plus uniquement à acheminer le trafic vers un cluster. Elle devient un point de contrôle pour le déploiement, la protection et l’exploitation à grande échelle des applications modernes, des API et des services d’IA.”
Pourquoi les normes sont importantes
Gateway API s’impose comme une norme importante pour la gestion du trafic Kubernetes, car elle répond à un défi bien connu des entreprises : trop d’équipes résolvent le même problème de différentes manières.
Les approches traditionnelles de gestion du trafic entrant reposent souvent en grande partie sur des annotations propres à chaque implémentation et sur des configurations personnalisées. Cela peut convenir à des équipes individuelles, mais la gouvernance devient plus difficile à l’échelle de l’entreprise. Les politiques sont difficiles à auditer. Les parcours de migration se complexifient. Les équipes chargées de la plateforme peuvent avoir du mal à proposer des services en libre-service sans renoncer au contrôle. Les équipes applicatives peuvent avancer rapidement, mais le modèle opérationnel se fragmente.
Gateway API introduit un modèle natif de Kubernetes davantage axé sur les rôles. Les équipes chargées de la plateforme peuvent gérer une infrastructure de passerelle partagée. Les équipes applicatives peuvent définir le routage de leurs propres services. Les équipes de sécurité et d’exploitation bénéficient d’une structure plus claire pour appliquer les politiques. L’intérêt ne réside pas uniquement dans l’élégance technique, mais aussi dans un modèle opérationnel plus clair.
La conformité de NGINX Gateway Fabric à Gateway API 1.5 est importante dans ce contexte. La conformité ne signifie pas que toutes les implémentations sont identiques et ne dispense pas de prendre des décisions architecturales. Elle permet toutefois aux entreprises d’avoir davantage confiance dans le fait qu’elles s’appuient sur une norme qui gagne en maturité et qui est testée dans l’ensemble de l’écosystème Kubernetes.
L’enjeu est simple. Les normes réduisent la complexité évitable. Elles facilitent la généralisation des décisions relatives aux plateformes à l’ensemble des équipes et des clusters. Elles réduisent le risque d’enfermer chaque workflow dans un modèle propriétaire. Enfin, elles jettent les bases d’une modernisation à long terme, permettant aux équipes d’adopter de nouveaux modèles de gestion du trafic sans contraindre toutes les applications à migrer simultanément.
C’est important, car dans les grandes entreprises, Kubernetes se limite rarement à un seul cluster. Les organisations exploitent souvent plusieurs clusters répartis entre différentes unités opérationnelles, régions, étapes de développement et différents environnements cloud. Sans approche commune, chaque cluster peut devenir un cas particulier. Gateway API, mise en œuvre par l’intermédiaire de NGINX Gateway Fabric, permet aux équipes chargées de la plateforme d’assurer une cohérence sans ralentir la livraison des applications.
La sécurité au plus près des applications
La sécurité est souvent plus robuste lorsqu’elle est intégrée à la plateforme plutôt qu’ajoutée après le déploiement. C’est particulièrement vrai dans Kubernetes, où les équipes applicatives s’attendent à disposer de fonctionnalités en libre-service et à pouvoir effectuer des mises en production rapides.
L’intégration entre NGINX Gateway Fabric et F5 WAF for NGINX rapproche la sécurité des applications d’entreprise de la couche de passerelle Kubernetes. Grâce à cette intégration, les équipes de sécurité peuvent définir et gérer des politiques de protection des applications, tandis que les équipes responsables de la plateforme rendent ces protections accessibles au moyen de workflows natifs de Kubernetes.
La valeur métier ne réside pas dans la nécessité, pour chaque responsable informatique, de comprendre les mécanismes techniques d’association des politiques. Elle tient au fait que les équipes de sécurité peuvent conserver la maîtrise des politiques de protection, tandis que les équipes chargées des plateformes et des applications continuent d’avancer rapidement.
Cette séparation des responsabilités est essentielle. Si la sécurité dépend de la bonne mise en œuvre des contrôles par chaque équipe applicative, l’entreprise se retrouve avec une protection incohérente. Si la sécurité ralentit chaque mise en production, les équipes cherchent des solutions de contournement. Un meilleur modèle repose sur une gouvernance partagée : les équipes de sécurité définissent et gèrent les politiques, les équipes chargées des plateformes fournissent le point d’application des contrôles, et les équipes applicatives continuent à livrer des logiciels.
Cela est particulièrement pertinent à mesure qu’un nombre croissant d’applications destinées aux clients, d’API et de services intégrant l’IA migrent vers Kubernetes. Le profil de risque s’élargit à mesure que la plateforme gagne en importance stratégique. Les attaques visant les applications web, les erreurs de configuration, les routes non gérées et les disparités en matière de posture de sécurité ne sont pas seulement des préoccupations techniques ; elles deviennent également des enjeux de continuité d’activité, de conformité et de réputation.
Un modèle de WAF au niveau de la passerelle ne remplace ni les pratiques de développement sécurisé ni les programmes plus larges de sécurité des applications. Il offre toutefois aux organisations une couche pratique d’application des politiques de sécurité, au plus près de l’endroit où les applications sont mises à disposition. La sécurité peut ainsi faire partie intégrante de l’architecture de la plateforme, au lieu de relever d’un processus distinct qui doit suivre chaque déploiement.
Se préparer à l’inférence de l’IA
L’inférence d’IA modifie la gestion du trafic, car les charges de travail d’IA ne se comportent pas comme les requêtes web traditionnelles.
Une requête web classique est généralement de courte durée et relativement prévisible. Les requêtes d’inférence peuvent varier considérablement en termes de durée, de taille de charge utile, de coût et d’impact sur les ressources. Une seule requête peut mobiliser de coûteuses ressources GPU. Plusieurs modèles peuvent être utilisés pour différentes tâches. Certains modèles peuvent être optimisés pour réduire les coûts, d’autres pour améliorer les performances, et d’autres encore pour accroître la précision. La décision de routage peut avoir une incidence sur l’expérience utilisateur, l’utilisation de l’infrastructure et les coûts d’exploitation.
C’est pourquoi l’extension d’inférence de Gateway API est importante. Elle permet un routage tenant compte des modèles, afin d’orienter les requêtes en fonction de la version et du type de modèle, ainsi que du profil coût-performances. Grâce à la prise en charge de NGINX Gateway Fabric, les entreprises peuvent améliorer l’expérience utilisateur et l’utilisation de leur infrastructure, tout en acheminant les requêtes à faible valeur ajoutée ou tolérantes à la latence vers des modèles plus économiques.
L’enjeu n’est pas le mécanisme d’ordonnancement sous-jacent, mais la maturité opérationnelle nécessaire au déploiement de l’IA. Lorsque 78 % des organisations exploitent elles-mêmes l’inférence d’IA, celle-ci ne relève plus uniquement de la science des données : elle fait désormais partie de la chaîne de mise à disposition des applications d’entreprise. Et puisque 52 % utilisent une orchestration multimodèle, la gestion du trafic doit tenir compte d’un environnement d’IA plus dynamique.
La prise en charge de l’Inference Extension par NGINX Gateway Fabric aide les équipes chargées des plateformes et du machine learning à intégrer les charges de travail d’IA dans un modèle d’exploitation Kubernetes qui leur est familier. Plutôt que de créer une architecture de mise à disposition distincte pour l’IA, les entreprises peuvent commencer à gérer les services d’IA aux côtés des applications et des API, en adoptant une approche de passerelle conforme aux standards.
Cela ne signifie pas que la passerelle résout tous les défis liés à l’IA en entreprise. La gouvernance des modèles et des données, les tests de sécurité, la gestion des coûts et la conformité nécessitent toujours des contrôles plus larges. Mais le routage constitue un élément fondamental de l’environnement de production de l’IA. Si les requêtes ne sont pas acheminées efficacement, si les signaux de l’infrastructure sont ignorés ou si chaque équipe crée son propre chemin d’accès à l’inférence, la complexité s’accroît rapidement.
Le changement le plus important concerne l’architecture : l’IA devient une nouvelle catégorie de charge de travail de production, dont le déploiement doit être sécurisé, observable et régi par des politiques.
Livraison moderne d’applications à l’ère de l’IA
NGINX Gateway Fabric ne doit pas être évalué uniquement comme un composant réseau Kubernetes. Il doit être considéré comme un élément d’une stratégie de plateforme plus large pour la mise à disposition d’applications modernes.
La combinaison de la conformité à Gateway API 1.5, de l’intégration de F5 WAF for NGINX et de la prise en charge d’Inference Extension est importante, car elle relie trois priorités :
- Standardisation: réduisez la fragmentation en alignant la gestion du trafic Kubernetes sur une norme communautaire en pleine maturation.
- Sécurité: appliquez la protection des applications d’entreprise au plus près de l’endroit où les applications Kubernetes sont exposées.
- Préparation à l’IA: préparez la couche de diffusion aux charges de travail d’inférence, qui sont plus dynamiques, plus gourmandes en ressources et plus critiques pour l’entreprise que les services traditionnels.
L’avantage concret réside dans un modèle opérationnel plus cohérent. L’ingénierie de plateforme peut fournir une infrastructure partagée et des modèles en libre-service. Les équipes applicatives peuvent avancer plus rapidement sans avoir à concevoir leur propre modèle de gestion du trafic. Les équipes de sécurité peuvent appliquer les politiques au moyen des contrôles existants. Les équipes de machine learning peuvent intégrer les charges de travail d’inférence à Kubernetes sans considérer le déploiement de l’IA comme une architecture ponctuelle.
C’est important, car la prochaine phase de l’adoption de l’IA ne sera pas évaluée uniquement au nombre de projets pilotes lancés par une organisation. Elle le sera aussi à la fiabilité, à la sécurité et à l’efficacité avec lesquelles les applications intégrant l’IA fonctionnent en production.
De nombreuses entreprises disposent déjà des éléments nécessaires : plateformes Kubernetes, infrastructure de mise à disposition des applications, programmes de sécurité, initiatives en matière d’IA et équipes responsables de chacun de ces domaines. Le défi consiste à réunir tous ces éléments de manière évolutive. NGINX Gateway Fabric aide les organisations en leur fournissant une couche de passerelle conforme aux normes, capable de prendre en charge les applications traditionnelles, les API, les politiques de sécurité et les nouveaux modèles d’inférence d’IA.
Il s’agit là d’une proposition de valeur concrète. Les entreprises n’ont pas besoin de repartir de zéro ni de reconstruire entièrement leur architecture de mise à disposition des applications. Elles peuvent faire évoluer la gestion du trafic Kubernetes vers un modèle plus cohérent, plus sécurisé et mieux adapté aux charges de travail d’IA. Elles disposent ainsi d’une voie pour faire évoluer la gestion du trafic Kubernetes vers un modèle plus cohérent, plus sécurisé et mieux adapté aux charges de travail d’IA.
À mesure que l’IA s’intègre davantage aux applications d’entreprise, la réflexion sur l’infrastructure doit évoluer en parallèle. La passerelle ne sert plus uniquement à acheminer le trafic vers un cluster. Elle devient un point de contrôle déterminant la manière dont les applications modernes, les API et les services d’IA sont déployés, protégés et exploités à grande échelle.
Pour en savoir plus, consultez la page web F5 NGINX Gateway Fabric.
N’oubliez pas non plus d’assister au F5 AI Summit : cet événement virtuel de trois heures aura lieu le mardi 23 juin. Nous y aborderons en détail le déploiement des charges de travail d’IA sur Kubernetes lors de la session « Déployer l’IA sur Kubernetes avec F5 NGINX ».
À propos de l’auteur
Articles de blog associés
F5 rejoint le projet PQC du NIST pour contribuer à l’élaboration de normes résistantes aux attaques quantiques
En rejoignant le consortium du projet « Migration to PQC » du NIST, F5 contribue à élaborer des recommandations pratiques pour un monde résistant aux menaces quantiques.
La dernière version de F5 Distributed Cloud Bot Defense offre des fonctionnalités et des améliorations de nouvelle génération
Les mises à jour de la console de F5 Distributed Cloud Bot Defense améliorent la gestion des menaces automatisées et l’intégration dans des cadres de sécurité plus larges.
La nouvelle surface de risque liée à l’IA : invisible, autonome et déjà à l’intérieur
James White, vice-président de l’ingénierie chez F5 À mi-parcours de l’année 2025, le moment est bien choisi pour dresser un état des lieux de l’adoption de l’IA en entreprise et de la sécurité de l’IA. L’utilisation de l’IA générative est désormais la norme dans les entreprises De manière générale, les entreprises possèdent au moins une compréhension élémentaire de l’IA générative. Elles savent ce qu’elle est et où elle peut […]
Évaluation des LLM : renforcer la confiance grâce à la notation de sécurité
À mesure que l’adoption de l’IA s’accélère dans les entreprises, l’évaluation des LLM ne porte plus uniquement sur leurs performances, mais aussi sur la confiance qu’ils inspirent. Les équipes de sécurité doivent évaluer non seulement les performances d’un modèle, mais aussi la sûreté de son comportement. Pourtant, la plupart des cadres d’évaluation se concentrent sur des critères de précision, laissant les facteurs de sécurité et de risque dans le flou ou sans mesure.
Évaluer le niveau de préparation de votre organisation à la sécurité de l’IA
Dans un paysage de l’intelligence artificielle (IA) en constante évolution, il est non seulement important, mais impératif de savoir si votre organisation est prête à instaurer et à soutenir une culture de la sécurité de l’IA. À mesure que les technologies d’IA progressent, elles font émerger une multitude de nouveaux défis de sécurité qui, pour être gérés efficacement, exigent une approche réfléchie, globale et proactive […]
Déployer des LLM en entreprise : via une API dans un cloud privé
Pris isolément, sans mesures de protection spécialisées ni protocoles de sécurité en place, le déploiement de modèles d’IA générative (GenAI), en particulier de grands modèles de langage (LLM), à l’échelle de l’entreprise représente pour toute organisation une opportunité à haut risque, mais potentiellement très rentable. La manière précise dont votre organisation doit franchir ce grand pas dans l’univers de la GenAI nécessite une planification mûrement réfléchie. Peut-être serait-il […]