Il y a plus de 10 ans, alors que j’étais ingénieur solutions, j’ai vu des entreprises commencer à déployer Kubernetes dans le cadre de projets annexes. Il s’agissait d’initiatives expérimentales, souvent menées en parallèle de tests d’autres orchestrateurs de conteneurs. Les charges de travail de production s’exécutaient encore sur des machines virtuelles dans vSphere, un environnement conçu autour d’objectifs de niveau de service et de délai de reprise. Tout le monde y contribuait, pas seulement les administrateurs de serveurs. Voilà ce qu’on pouvait appeler une solution de classe entreprise.
Puis les choses ont évolué. Le cloud public a pris son essor, les applications ont été modernisées et Kubernetes s’est imposé comme la solution de référence des entreprises pour exécuter leurs applications conteneurisées. Le moteur restait le même : les impératifs commerciaux, qui exigeaient une montée en charge rapide. Les entreprises voulaient accélérer, et j’ai accompagné de nombreux clients pionniers qui cherchaient à faire de Kubernetes une plateforme adaptée aux exigences de l’entreprise.
Pour ces clients, l’objectif était dicté par les attentes de l’entreprise. Un projet expérimental interne avance comme il peut, dans le meilleur des cas. Une plateforme d’entreprise doit évoluer au rythme de l’activité et, idéalement, devenir un élément essentiel de sa compétitivité. Kubernetes suscite désormais ce niveau d’attente, mais ne constitue pas à lui seul une plateforme complète comme l’est vSphere. Ses fondations open source sont remarquables, mais ce n’est qu’un début.
Une nouvelle étude commandée par F5 à SlashData montre l’ampleur du chemin qui reste à parcourir pour répondre aux exigences des entreprises. Parmi les entreprises qui utilisent Kubernetes en production, 61 % lui imposent un niveau d’exigence égal ou supérieur à celui du reste de leur parc informatique, mais seules 38 % atteignent un niveau de maturité adapté aux besoins de l’entreprise.
Dans ce rapport, la qualité entreprise ne se résume pas à un score élevé. Elle exige un contrôle d’admission automatisé, une isolation stricte des locataires, une observabilité centralisée, des objectifs de reprise documentés et un basculement testé au cours des 12 derniers mois. L’enquête a évalué les pratiques réelles des équipes, et non leur perception de leur propre maturité, à partir de 445 réponses recueillies en août 2026 auprès de professionnels de terrain travaillant dans des organisations de plus de 500 salariés.
La plupart des environnements sont bien établis, mais pas encore matures
Je considère les définitions du rapport comme des jalons sur un parcours que chacun suit. Je doute qu’une organisation puisse un jour considérer ce parcours comme achevé, et il faut toujours faire des arbitrages entre les priorités. Le rapport nous donne un aperçu de la situation actuelle des entreprises. La moitié d’entre elles (51 %) se situent au niveau établi, où les normes sont définies et largement appliquées, mais où des lacunes restent visibles. Par ailleurs, 11 % sont encore en phase de standardisation. Près de neuf entreprises sur dix (88 %) atteignent le niveau le plus élevé dans au moins un domaine, mais seules 22 % y parviennent dans les quatre. Même parmi les 51 % d’entreprises qui obtiennent un score global de 80 ou plus, une sur quatre (24 %) ne remplit pas un seul des prérequis, ce qui l’empêche d’accéder au niveau le plus élevé.
L’observabilité est l’élément qui fait le plus souvent défaut. Parmi les entreprises qui manquent de peu le niveau supérieur, 36 % ne disposent pas d’une observabilité centralisée et 31 % n’ont pas de contrôle d’admission automatisé. Ces deux constats correspondent à ce que j’ai observé sur le terrain. Chez la plupart de mes clients, que Kubernetes soit utilisé ou non, c’est l’observabilité qui faisait défaut. La résolution des problèmes était difficile, mobilisait bien plus de personnes que nécessaire et tournait trop souvent à la recherche d’un coupable.
Le contrôle d’admission est essentiel pour gérer les environnements à grande échelle. Un client s’appuyait largement sur ce mécanisme pour encadrer l’utilisation de vSphere en raison de la taille de son environnement. Les environnements Kubernetes prennent rapidement de l’ampleur, et le défi le plus souvent cité dans le rapport est la complexité de la gestion des clusters et des environnements (39 %). Les contrôles essentiels à grande échelle deviennent nécessaires plus tôt que la plupart des équipes ne le pensent. Pourtant, seuls 28 % prévoient d’investir dans l’observabilité au cours des 12 prochains mois, contre 42 % qui prévoient d’investir dans la sécurité et l’application des politiques.
La maturité est un sport d’équipe
Au fil des années, les rôles ont pris plus d’importance que je ne l’aurais imaginé. J’ai rencontré les équipes plateforme et DevOps parce qu’elles connaissaient NGINX, lui faisaient confiance et souhaitaient l’utiliser. J’ai également rencontré les équipes réseau et sécurité, qui voulaient s’assurer que Kubernetes pouvait s’intégrer aux pratiques NetOps et SecOps de leur entreprise, plutôt que de créer des processus de travail entièrement distincts.
Un client a fait quelque chose d’inhabituel pour l’époque : il a confié à son ingénieur DevOps son propre F5 BIG-IP. Il a appris à en maîtriser tous les rouages et lui a fait faire des choses que j’avais rarement vu les administrateurs BIG-IP traditionnels réaliser eux-mêmes (clin d’œil à Steven !). C’était une véritable marque de confiance. La réussite a toujours reposé sur la collaboration et la confiance, car obtenir des résultats à la hauteur des exigences d’une entreprise suppose que les équipes s’appuient les unes sur les autres, plutôt que de se contourner mutuellement.
Les résultats de l’étude vont dans le même sens. Lorsqu’une équipe dédiée à l’ingénierie de plateforme exploite Kubernetes et qu’une équipe de sécurité centralisée distincte définit les politiques, 66 % des entreprises atteignent un niveau de maturité adapté aux exigences de l’entreprise, soit environ deux fois plus qu’avec d’autres modes d’organisation. Seules 19 % des entreprises fonctionnent ainsi. L’étendue du déploiement compte également : 53 % des entreprises qui utilisent Kubernetes comme plateforme standard dans toute l’organisation atteignent le niveau de maturité le plus élevé, contre 25 % de celles où son utilisation se limite à une seule équipe.
Il s’agit d’une corrélation, et non de la preuve d’un lien de causalité. Les organisations plus grandes et plus investies sont peut-être tout simplement plus enclines à répartir le travail de cette manière. Ce constat rejoint néanmoins mon expérience : les équipes qui se partagent la charge de travail et se font mutuellement confiance pour assumer leurs responsabilités respectives sont celles qui atteignent un niveau de maturité adapté aux exigences de l’entreprise.
L’IA prend de l’avance sur la gouvernance
J’ai également été témoin des prémices de ce phénomène. Une entreprise déployait rapidement des charges de travail de machine learning qui devenaient essentielles à son activité. Ce pan de l’entreprise était au cœur de l’innovation dans une structure par ailleurs plutôt traditionnelle. À un tel rythme, la gouvernance peut vite se laisser distancer.
Parmi les entreprises qui utilisent Kubernetes en production, 45 % déploient des modèles ou les mettent à disposition, et 86 % d’entre elles ont étendu leur pare-feu applicatif web (WAF) ou leur protection des API à ce trafic. Les contrôles spécifiques à l’IA restent à la traîne. Seules 43 % inspectent les outils des agents et le trafic du protocole Model Context Protocol (MCP), même si 49 % prévoient de le faire dans les 12 prochains mois. Les environnements matures sont en tête en matière de limitation du débit et de quotas de jetons (80 % contre 50 %), mais cet avantage disparaît pour l’inspection des prompts et du trafic MCP. Les pratiques de gouvernance établies pour les charges de travail traditionnelles sont utiles, mais elles ne couvrent pas encore tous les besoins.
Ce que l’étude implique pour votre pile technologique
L’étude ne désigne pas un produit en particulier. Elle met en évidence des lacunes, qui correspondent à des périmètres de responsabilité. L’observabilité commence par la télémétrie en périphérie, qui relève des équipes plateforme et réseau. Web application and API protection (WAAP) présente l’un des écarts d’adoption technologique les plus marqués entre les niveaux de maturité : 69 % des environnements de niveau entreprise y ont recours, contre 50 % des autres. Les politiques associées relèvent des équipes de sécurité et doivent être héritées par chaque cluster. Le basculement doit être testé entre les clusters, ce qui nécessite une collaboration entre les équipes réseau et plateforme.
L’approche de F5 s’adapte à la manière dont ces équipes travaillent réellement. Les équipes Kubernetes commencent par l’open source, car une pile logicielle comme Kubernetes en fait le choix par défaut. Elles peuvent démarrer avec des projets comme NGINX Ingress Controller, une solution Ingress bénéficiant d’un support à long terme malgré l’arrêt du projet communautaire ingress-nginx, ou NGINX Gateway Fabric, qui est entièrement conforme à Gateway API.
À terme, ces équipes recherchent les garanties offertes par une solution commerciale et se tournent alors vers F5 NGINX Enterprise pour bénéficier d’images renforcées, de la gestion des identités en périphérie, de politiques de sécurité propres à chaque application, d’accords de niveau de service pour le support ou de la capacité à gérer un parc à grande échelle.
Les équipes réseau et sécurité souhaitent que Kubernetes s’intègre à leurs pratiques existantes. Ainsi, F5 BIG-IP avec Container Ingress Services (CIS) leur permet d’appliquer des politiques centralisées de gestion du trafic et de sécurité et de gérer le basculement entre clusters depuis BIG-IP, tandis que les équipes plateforme continuent de travailler dans Kubernetes.
Pour les charges de travail d’IA exécutées à l’échelle d’un néocloud ou d’une usine d’IA, F5 BIG-IP Next for Kubernetes étend cette approche avec des fonctionnalités de gestion du trafic et de sécurité conçues pour l’IA dans Kubernetes. Chaque équipe conserve les outils qui lui sont familiers, et le point de contrôle commun assure leur coordination.
Notre livre blanc complémentaire décline cette approche en quatre phases, chacune assortie de critères de sortie. Le calendrier est donné à titre indicatif : commencez donc par la phase qui correspond à votre niveau de maturité actuel et adaptez le planning à votre situation.
- Standardiser (mois 0 à 3) : un modèle d’ingress pris en charge dans chaque cluster, une télémétrie en périphérie et des rôles clairement définis pour la plateforme et la sécurité.
- Mettre en place (mois 3 à 9) : un standard Gateway API, un WAF pour une sécurité héritée et une télémétrie centralisée.
- Niveau entreprise (mois 9 à 18) : contrôle d’admission automatisé, point de contrôle unique pour le trafic et les politiques, et basculement testé.
- Optimisation (à partir du 18e mois) : garde-fous pour l’IA, politiques sous forme de code et réévaluation trimestrielle de la maturité.
C’est à la phase 4 que l’IA entre de nouveau en jeu, à l’image des charges de travail de machine learning que j’ai évoquées plus tôt. Les équipes y parviennent en s’appuyant sur les bases qu’elles ont déjà établies avec F5 NGINX Enterprise et BIG-IP avec CIS. Pour répondre aux besoins à grande échelle des néoclouds et des usines d’IA, ces bases peuvent être étendues à BIG-IP Next for Kubernetes. Quelle que soit l’échelle, l’efficacité de la technologie dépend de la solidité des partenariats sur lesquels elle repose.
Déterminez votre point de départ. Téléchargez une feuille de route pour atteindre un niveau de maturité Kubernetes adapté aux exigences de l’entreprise, évaluer votre situation et disposer d’un plan étape par étape. Consultez ensuite le rapport État des lieux des stratégies Kubernetes en entreprise en 2026 pour découvrir l’intégralité de l’étude.
Pensez également à consulter notre article de blog, « Contrôle du trafic et sécurité cloud-native pour Kubernetes : une solution conçue pour toutes les équipes ».
À propos de l’auteur
Articles de blog associés
Pourquoi la plupart des entreprises n’ont pas encore atteint la maturité en matière de Kubernetes
Une étude de F5 révèle que seules 38 % des entreprises qui utilisent Kubernetes en production atteignent un niveau de maturité adapté aux exigences des grandes entreprises. Voici ce qui freine les autres et par où commencer.
Analyse des modèles de sécurité de l’IA par F5 Labs : quand les agents IA exposent des données sans l’intervention d’un attaquant
Des agents cherchant à accomplir des tâches anodines peuvent entraîner des divulgations inattendues de données et des risques pour l’entreprise si les limites qui leur sont imposées ne sont pas rigoureusement appliquées.
Comment les RSSI peuvent mesurer les risques de sécurité liés à l’IA
Découvrez comment CASI, ARS et les renseignements sur les menaces de F5 Labs aident les RSSI à mesurer les risques de sécurité liés à l’IA tout au long de son cycle de vie.
Inférence : l’élément le plus important de l’IA dont vous faites semblant d’ignorer l’existence
Faire évoluer l’IA à grande échelle implique de faire évoluer l’inférence. Découvrez pourquoi les serveurs d’inférence sont essentiels pour gérer les performances, la télémétrie et la sécurité des charges de travail d’IA en production.
Que pensent les équipes SecOps de l’IA ? Partie 2 : Protection des données
F5 a mené une analyse approfondie des opinions exprimées par les professionnels de la sécurité sur Reddit au sujet de l’IA.
Que pensent les équipes SecOps de l’IA ?
F5 a mené une analyse approfondie des opinions exprimées par les professionnels de la sécurité sur Reddit concernant l’IA.