Sécurité · 28 octobre 2026
Également publié en עברית
Kubernetes face à l'essor des agents IA : défis de sécurité et d'infrastructure
Kubernetes a été conçu autour d'une hypothèse simple : le logiciel exécute ce que ses développeurs lui ont dit de faire. Les agents IA compliquent cette prémisse. Un agent peut raisonner sur un problème, choisir une action, appeler des outils, écrire du code, interagir avec d'autres systèmes et poursuivre un but. Cette capacité explique leur utilité, mais rend également leur exécution en production différente de celle d'une application conventionnelle.
De plus en plus, les entreprises souhaitent les faire tourner sur Kubernetes. Un récent sondage de la Cloud Native Computing Foundation (CNCF) a révélé que deux tiers des organisations exécutant des charges de travail d'inférence IA les font tourner sur Kubernetes. Cela s'explique par le fait que Kubernetes est devenu la méthode standard pour déployer et exploiter des applications distribuées au cours de la dernière décennie. Il sait déjà planifier des charges de travail, allouer des ressources, récupérer en cas de panne et faire évoluer les applications à la hausse comme à la baisse.
KubeCon + CloudNativeCon se tient à Salt Lake City du 9 au 12 novembre. Inscription en cours !
La demande d'inférence peut arriver par pics, obligeant les clients à mettre à l'échelle rapidement les ressources matérielles et logicielles sous-jacentes pour répondre à une demande croissante. Dans ce sens, Kubernetes constitue un excellent choix. De même, lorsque les charges de travail IA diminuent, Kubernetes peut réduire progressivement l'infrastructure sous-jacente, assurant un fonctionnement économique.
Bien que le rapprochement entre l'inférence IA et Kubernetes soit favorable, des écarts subsistent, notamment en matière de sécurité. Des incidents récents dans des laboratoires IA de pointe, où des agents IA ont quitté les environnements de test pour lancer des cyberattaques malveillantes sur internet, soulignent la nécessité de garde-fous solides pour empêcher les charges de travail IA de se comporter de manière inappropriée.
Malheureusement, la nature probabiliste de l'IA rend impossible la prédiction exacte des ressources qu'une charge de travail IA cherchera à utiliser, augmentant ainsi la probabilité que les agents franchissent la ligne. Par conséquent, la plateforme IA idéale devrait faciliter l'application de garde-fous clairs et maintenir les charges de travail agentiques en sécurité dans des sables bien définis.
« La plateforme IA idéale devrait faciliter l'application de garde-fous clairs et maintenir les charges de travail agentiques en sécurité dans des sables bien définis. »
En confinant les charges de travail agentiques IA dans un sable logique séparé des autres charges de travail Kubernetes, une entreprise peut mieux s'assurer que, si une charge de travail IA déraille, les dommages restent dans ce sable.
Au lieu de laisser les agents accéder à toutes les ressources qu'ils souhaitent, les plateformes agentiques devraient utiliser un cadre de permissionnement explicite qui accorde ou refuse l'accès aux fichiers, aux outils et aux ressources réseau et système. Les agents doivent être totalement restreints d'exécuter du code sauf s'ils ont reçu une permission explicite.
La bonne nouvelle est que la communauté Kubernetes s'oriente vers l'adoption du sable comme élément architectural pour contraindre les agents IA. La CNCF travaille à combler les lacunes de sécurité et d'isolation de Kubernetes. Cependant, la fonctionnalité du projet open-source n'est pas encore pleinement aboutie.
Un sableage adéquat de l'IA nécessite de regarder au-delà du conteneur pour aller vers des machines virtuelles ou le système d'exploitation hôte, afin de s'assurer que les charges de travail agentiques n'affectent pas les autres applications s'exécutant dans le même environnement. Les entreprises souhaitant déployer l'IA en production peuvent aujourd'hui se tourner vers des distributions Kubernetes commerciales qui incluent déjà ces capacités de sableage.
Le suivi des charges de travail IA constitue une autre préoccupation qui tient les directeurs informatiques éveillés la nuit. Bien que les laboratoires IA de pointe n'aient pas suffisamment suivi ce que faisaient leurs modèles IA, ou même s'ils avaient accès à internet, les entreprises n'ont généralement pas le luxe de demander pardon après coup lorsque leurs agents se comportent mal.
La sécurité peut être le défi le plus évident, mais elle n'est pas le seul. Les agents changent également la consommation de calcul. Un service normal peut tourner continuellement pendant des mois, tandis qu'un agent peut n'exister que quelques secondes.
« Un service normal peut tourner continuellement pendant des mois, tandis qu'un agent peut n'exister que quelques secondes. »
Un utilisateur pose une question -> un agent démarre -> il effectue un travail, crée éventuellement d'autres agents, appelle plusieurs outils, puis disparaît.
Multipliez ce modèle par des milliers d'utilisateurs et l'infrastructure commence à ressembler à quelque chose de très différent d'un environnement Kubernetes conventionnel.
En outre, le démarrage d'une charge de travail Kubernetes depuis zéro peut prendre des secondes. Pour de nombreuses applications, cela est parfaitement acceptable. Mais pour un agent interactif, ces secondes peuvent paraître insupportablement lentes. Cela pose un problème d'infrastructure intéressant : comment obtenir l'isolation d'un environnement frais sans payer le coût de démarrage de sa création à chaque fois ?
Ainsi, la nature sporadique des charges de travail agentiques et le besoin de les faire démarrer rapidement mettent même la flexibilité de Kubernetes à l'épreuve. Tout comme la première génération de Kubernetes ne prenait pas en charge les applications état, la communauté cherche toujours la meilleure couche d'abstraction pour exécuter la nouvelle génération de charges de travail agentiques.
« Les agents restent dans un état d'animation suspendue dans une piscine chaude, permettant leur réanimation en millisecondes plutôt que les secondes nécessaires pour se réveiller complètement depuis un sommeil profond. »
Une réponse qui gagne en attention au sein de la communauté est un substrat d'agents pour faire évoluer rapidement les charges de travail agentiques basées sur Kubernetes. Avec un substrat d'agents, les conteneurs Kubernetes contenant des agents IA ne sont pas entièrement arrêtés lorsqu'ils ne sont pas nécessaires, car les réveiller depuis un état de sommeil introduirait trop de latence aux yeux de l'utilisateur. Au contraire, les agents restent dans un état d'animation suspendue dans une piscine chaude, permettant leur réanimation en millisecondes plutôt que les secondes nécessaires pour se réveiller complètement depuis un sommeil profond.