IASécurité

Kubernetes en tant que système d’exploitation par défaut pour l’IA: les clusters comme question de conformité

Gartner prévoit une adoption de plateforme à 80 % d'ici la fin de 2026. Ce qui était appelé DevEx en 2022 sera nommé inférence d'intelligence…

Par Alec Chizhik 10 juin 2026 7 min de lecture

Kubernetes en tant que système d’exploitation par défaut pour l’IA: les clusters comme question de conformité

Gartner prévoit que huit entreprises sur dix exploiteront une plateforme développeur interne d’ici la fin 2026. Ce qui sonnait encore en 2022 comme un confort DevEx intègre aujourd’hui l’inférence IA, les preuves de conformité et la prévision des coûts dans une seule pile de cluster. Celui qui ne traite pas le cluster dès maintenant comme une infrastructure critique pour le business planifie pour 2027 selon les mauvaises catégories.

Les points clés en bref

Kubernetes est le nouvel OS serveur : Le débat se déplace du « si l’IA fonctionne sur Kubernetes » au « comment elle est stable, reproductible et auditable ». En 2026, la question est opérationnelle, plus stratégique.
La conformité migre vers le cluster : La configuration des pods, les politiques d’égress et la provenance des images deviennent soudainement pertinentes pour les audits. Qui n’impose pas cela de manière centrale reconstruit l’obligation de preuve dans chaque équipe.
L’IA stateful brise les anciennes hypothèses : L’inférence nécessite une affinité GPU, des vecteurs persistants et un stockage rapide. Les patterns stateless classiques ne suffisent plus : les équipes plateformes voient cela désormais dans la planification de capacité.

Similaire :Le Platform Engineering n’est plus un projet DevEx / Lorsque la facture IA explose le budget cloud

La vague d’inférence a atterri sur Kubernetes

Celui qui débattait encore en 2024 du « AI-Workloads oui ou non dans le cluster » mène en 2026 une autre discussion : quelles pipelines d’inférence peuvent encore rester en dehors de la plateforme. Les réponses des équipes que je vois lors des audits DACH sont étonnamment similaires. Les expériences Notebook sur Sagemaker, Bedrock ou Vertex sont autorisées. L’inférence productive avec des données clients atterrit dans le cluster interne – ou elle est stoppée avant sa mise en production.

Qu’est-ce que Kubernetes en tant qu’OS par défaut pour l’IA ? Le terme décrit l’état où l’inférence IA productive s’exécute par défaut dans le cluster Kubernetes interne plutôt que dans un SaaS séparé. Le cluster devient ainsi une infrastructure critique pour le business, regroupant le scheduling GPU, les vecteurs persistants et les preuves de conformité à un seul endroit, au lieu de les répartir sur plusieurs plateformes.

Le moteur n’est pas l’élégance. Le moteur est la position des auditeurs. NIS2, EU AI Act et DORA exigent des preuves sur les flux de données, les droits des modèles et les chaînes d’accès. Si l’IA vit dans un SaaS séparé, toute la chaîne d’audit doit y être construite séparément. Qui gère déjà les mêmes contrôles dans le cluster obtient factuellement les preuves IA offertes. C’est exactement la justification opérationnelle derrière le chiffre Gartner, pas un slogan DevEx.

80 %

des grandes organisations d’ingénierie logicielle établiront une équipe plateforme interne d’ici 2026 (en 2022, c’était 45 %) – pour la plupart, cela signifie : le cluster portera alors l’inférence IA et les preuves de conformité associées.

Source : Gartner

Stateful-AI bouleverse les hypothèses stateless

L’ancienne doctrine des plateformes était simple : les pods sont du bétail, l’état réside dans le backend, le cluster ne fait qu’orchestrer. Les workloads d’inférence ne suivent pas cette règle. Un grand LLM met sept à douze secondes à se charger avant de répondre. Une base de données vectorielles perd sa localité lorsque son pod franchit les frontières des nœuds. L’affinité GPU signifie que le même pod doit rester sur le même nœud – sans quoi la latence devient inexploitable.

Les équipes plateforme y réagissent actuellement de trois manières. Premièrement : des pools de nœuds dédiés à l’inférence, avec des taints, des tolérances et des créneaux GPU garantis. Deuxièmement : des magasins vectoriels persistants sous forme de StatefulSet, et non de simple pod. Troisièmement : un ordonnancement tenant compte de la topologie, afin que les caches n’aient pas à être réchauffés à chaque mise à l’échelle. Celui qui n’aura pas ces trois composants dans sa pile en 2026 reproduira les problèmes dans chaque nouveau service d’IA.

La conformité migre dans la configuration des pods

La vérité opérationnelle que les directions préfèrent ne pas entendre : les auditeurs s’intéressent aux manifestes Kubernetes. Celui qui ne gère pas les politiques de sortie, les NetworkPolicies, la sécurité des pods et la provenance des images sous forme de code dans le cluster sera incapable de répondre en une heure d’audit à la question « avec quel endpoint votre IA communique-t-elle ? ». La plupart des équipes DACH l’ont compris, mais l’investissement accuse un retard de deux trimestres par rapport au besoin.

Concrètement, cela signifie que la politique en tant que code avec OPA Gatekeeper ou Kyverno doit être présente dans tout cluster manipulant des données clients. Les signatures Sigstore sur les images ne sont plus un gadget – elles constituent la seule preuve que seul le code validé par la pipeline s’exécute dans le cluster. Et le chiffrement en transit entre pods n’est plus une option en 2026, mais la norme par défaut. Les équipes plateforme qui ne standardisent pas ces couches freinent chaque équipe produit censée porter la stratégie IA.

Ce que les équipes plateforme doivent décider maintenant

Cela fait des semaines que je repousse trois décisions en revue, car elles dérangent dans la feuille de route plateforme. Elles ne se résolvent pas si on les met de côté.

Premièrement : la question du budget GPU. Centraliser les GPU dans un pool commun améliore le taux d’utilisation, au détriment de l’autonomie des équipes. Allouer les GPU par équipe réduit l’efficacité, mais apporte une clarté sur les responsables de la consommation. Les deux modèles fonctionnent, le modèle mixte non. Il faut trancher, pas noyer le débat.

Deuxièmement : la question du multi-tenant pour l’IA. Un pipeline RAG avec des données issues de trois domaines métier constitue un magasin vectoriel à trois risques. La simple séparation par namespaces ne suffit pas – il faut un durcissement au niveau des classes de stockage, des politiques de service mesh et un refus par défaut clair. Remettre cela à plus tard, c’est s’exposer à un incident qui ne figurait pas dans les présentations trimestrielles.

Troisièmement : la question du « Skip AI ». Certaines workloads d’IA n’ont pas leur place dans le cluster interne. L’inférence par lots non critique en latence sur des données non sensibles peut être exécutée de manière moins coûteuse et plus stable sur une plateforme gérée. Celui qui, par orgueil, fait tout tourner dans son propre cluster se prive de l’optimisation la plus simple – et encombre l’équipe plateforme de workloads dont personne ne remarquerait la disparition.

Foire aux questions

À partir de quand un cluster Kubernetes pour l’IA est-il soumis à des obligations de conformité ?

Dès que l’inférence productive s’exécute sur des données personnelles ou critiques pour l’entreprise. La directive NIS2 et le règlement européen sur l’IA (AI Act) lient cette obligation à la fonction, et non à l’architecture. Celui qui fait tourner l’inférence dans le cluster supporte la charge d’audit du cluster – y compris les manifestes, les politiques et les flux de données.

Quelle stratégie GPU est la bonne en 2026 ?

Il n’y a pas de réponse universelle. Les charges de travail très variables fonctionnent mieux sur des pools centraux avec quotas et préemption. Les produits stables avec leur propre taux d’utilisation gagnent avec des pools dédiés par équipe. L’essentiel est que le choix soit pris consciemment et non mélangé par inertie.

Avez-vous besoin d’un Service-Mesh pour les charges de travail IA ?

Si plusieurs locataires ou classes de données cohabitent dans le cluster, un Mesh aide sensiblement pour le mTLS, le contrôle de sortie (Egress-Control) et la télémétrie. Pour un seul locataire, la complexité est rarement justifiée. La question du Mesh n’est pas une question de foi, mais une question de flux de données réels.

Comment se déroule la migration si l’IA tournait jusqu’alors en dehors du cluster ?

Idéalement en trois étapes : d’abord figer les modèles et documenter les flux de données, puis intégrer le stockage et le Vector-Store dans le cluster, enfin basculer les chemins d’inférence. Ceux qui migrent d’abord les modèles paient le prix du risque de panne – les données sont, en cas de doute, l’actif le plus difficile à gérer.

Quand est-il légitime de faire tourner l’IA en dehors de son propre cluster ?

Lorsque la latence n’est pas critique, que les données ne sont pas sensibles et que la plateforme gérée fournit les parcours d’audit requis. Une inférence marketing sur des textes publics n’a pas sa place dans votre propre cluster. Une évaluation des risques avec des données clients, en revanche, oui.