Google a franchi une étape importante dans l’infrastructure pour agents d’intelligence artificielle avec deux annonces liées à Google Kubernetes Engine : la disponibilité générale de GKE Agent Sandbox en mai 2026 et la présentation d’un second projet, Agent Substrate. Derrière ces noms techniques se cache une idée simple, mais lourde de conséquences : Kubernetes reste essentiel pour faire tourner l’infrastructure cloud moderne, mais il n’a pas été conçu pour orchestrer directement des millions d’agents IA intermittents, stateful et potentiellement risqués.
L’article original publié par The New Stack souligne un changement de perspective important. Les agents IA ne se comportent pas comme des microservices classiques. Ils ressemblent davantage à des processus d’un système d’exploitation : ils dorment longtemps, se réveillent sur événement, exécutent une tâche, conservent leur mémoire de travail, puis se rendorment. C’est précisément ce comportement qui met sous pression le modèle historique de Kubernetes.
Pour les équipes cloud native, l’enjeu n’est donc pas de savoir si Kubernetes disparaît. Il ne disparaît pas. La vraie question est plutôt : quelle couche doit prendre en charge le cycle de vie spécifique des agents IA ? Google répond avec une combinaison en deux parties : Agent Sandbox pour l’exécution sécurisée, Agent Substrate pour l’ordonnancement adapté aux agents.
Pourquoi les agents IA ne sont pas des workloads Kubernetes classiques
Kubernetes a été pensé pour gérer des services relativement stables : des applications web, des API, des bases de données répliquées, des workers, des déploiements conteneurisés dont la durée de vie est assez longue. Le modèle fonctionne très bien lorsqu’il s’agit de placer des Pods, maintenir un nombre de réplicas, redémarrer un service défaillant ou répartir la charge entre plusieurs instances.
Un agent IA fonctionne différemment. Il peut rester attaché à une session utilisateur pendant plusieurs heures, tout en ne consommant réellement du calcul que quelques secondes de temps en temps. Un agent de programmation, par exemple, peut recevoir une instruction, analyser un dépôt, générer du code pendant dix secondes, puis attendre vingt minutes avant le prochain prompt. À l’échelle d’une entreprise, cela peut représenter des milliers de sessions actives administrativement, mais inactives du point de vue CPU.
Traiter chaque agent comme un Pod Kubernetes permanent revient alors à réserver de la mémoire et du CPU pour des sessions qui dorment la majorité du temps. Ce modèle devient coûteux, peu efficace et difficile à dimensionner.
Des sessions longues, mais rarement actives
Les agents IA sont des workloads « bursty » : leur activité arrive par à-coups. Ils doivent pouvoir démarrer rapidement lorsqu’un utilisateur attend une réponse, mais ils ne justifient pas forcément de garder une unité de calcul complète mobilisée pendant toute leur durée de vie.
C’est là que le parallèle avec un système d’exploitation devient utile. Un OS moderne gère des milliers de processus, dont beaucoup sont en attente. Il les suspend, les réveille, leur attribue du temps CPU, puis libère des ressources pour d’autres processus. L’infrastructure agentique doit tendre vers le même modèle : hiberner les sessions inactives et les restaurer rapidement lorsque nécessaire.
Du code généré à l’exécution, donc non fiable par défaut
Un autre point distingue fortement les agents IA des services traditionnels : le code exécuté peut être généré dynamiquement par un modèle. Dans le cas d’un agent de développement, d’un assistant d’automatisation ou d’un agent capable d’appeler des outils système, la plateforme ne peut pas supposer que le comportement sera toujours prévisible.
Cela change le niveau d’exigence en matière de sécurité. Un conteneur classique partage le noyau de l’hôte et repose sur un ensemble d’isolation suffisant pour beaucoup d’usages, mais pas toujours adapté à du code considéré comme non fiable. Pour les agents IA, l’isolation doit être pensée comme un prérequis, pas comme une option réservée aux environnements sensibles.
Un état à préserver entre deux réveils
Un agent utile conserve un contexte : historique de session, fichiers temporaires, mémoire de travail, état du raisonnement ou de l’environnement d’exécution. Si cet état disparaît à chaque mise en veille, l’expérience devient mauvaise et l’agent perd une partie de sa valeur.
La plateforme doit donc sauvegarder et restaurer cet état, y compris la mémoire volatile et l’état du système de fichiers. C’est plus proche d’une mise en hibernation que d’un simple redémarrage de conteneur. Pour l’utilisateur, la reprise doit sembler quasi immédiate ; pour l’infrastructure, elle doit libérer les ressources pendant les périodes d’inactivité.
Le control plane Kubernetes n’est pas taillé pour des millions d’agents dormants
Le cœur du problème se situe dans le control plane. Kubernetes orchestre les workloads via son serveur API central et son scheduler. Ce design est excellent pour des décisions de placement relativement durables : créer un Pod, le placer sur un nœud, le maintenir en vie, le remplacer si besoin.
Les agents IA créent une dynamique différente. Ils peuvent générer une grande quantité d’événements fins : réveils, suspensions, reprises, routage vers une session spécifique, migration ou allocation rapide d’un environnement d’exécution. Si chaque agent actif ou endormi devient un objet Kubernetes complet, le control plane risque de devenir le goulot d’étranglement.
Le sujet n’est pas seulement le volume. C’est aussi la nature des décisions. Une mauvaise décision de routage pour une requête web courte se dilue rapidement dans le trafic. Pour un agent dont l’exécution peut durer plus longtemps, une mauvaise allocation peut augmenter fortement la latence perçue par l’utilisateur et bloquer une session derrière une ressource mal choisie.
Autrement dit, Kubernetes reste très utile pour provisionner les machines, gérer les Pods de base et maintenir l’infrastructure. Mais l’ordonnancement fin des agents nécessite une couche plus spécialisée, située au-dessus ou à côté du control plane Kubernetes.
Agent Sandbox : une boîte sécurisée pour exécuter du code d’agent
GKE Agent Sandbox répond d’abord au problème de l’exécution sécurisée. Il s’agit d’un environnement open source construit sur Kubernetes, destiné à fournir aux agents un espace durci pour exécuter du code potentiellement non fiable.
Le bon modèle mental n’est pas le conteneur standard, mais plutôt une cellule d’isolation. Là où un conteneur traditionnel repose sur le partage du noyau hôte, Agent Sandbox part du principe que le workload peut être dangereux, imprévisible ou simplement mal contrôlé. Il faut donc lui fournir une barrière plus robuste.
Selon les éléments communiqués par Google, Agent Sandbox s’appuie par défaut sur gVisor, applique une politique réseau de type default-deny et propose une interface extensible permettant d’utiliser d’autres technologies, comme Kata Containers, pour une isolation encore plus forte au niveau du noyau.
Des pools chauds pour éviter les démarrages trop lents
Le problème classique des environnements fortement isolés est le temps de démarrage. Si chaque requête doit attendre la création complète d’un sandbox, l’utilisateur subit plusieurs secondes de latence. Pour un agent conversationnel ou un agent de code, c’est souvent inacceptable.
Agent Sandbox utilise donc des pools de sandboxes préprovisionnés. Google indique que l’API peut allouer jusqu’à 300 sandboxes par seconde et par cluster, avec 90 % des allocations terminées en 200 millisecondes. L’idée est de rapprocher la sécurité forte de l’expérience attendue d’un service interactif.
Des snapshots de Pods pour libérer les ressources inactives
La mise en veille des agents repose sur une logique de snapshots. Lorsqu’une session devient inactive, son état peut être sauvegardé afin de libérer le calcul sous-jacent. Lorsqu’un événement arrive, la session est restaurée à la demande.
Ce mécanisme est essentiel économiquement. À grande échelle, payer pour garder en mémoire vive des milliers ou millions de sessions dormantes n’a pas de sens. Le snapshot permet de déplacer le coût vers le stockage et de réserver le calcul aux moments réellement actifs.
Agent Substrate : une couche d’ordonnancement pensée pour les agents IA
Si Agent Sandbox sécurise l’exécution, Agent Substrate s’attaque au problème suivant : où faire tourner les agents, comment les réveiller, comment les surallouer sans saturer le cluster et comment éviter de faire passer chaque micro-décision par le scheduler Kubernetes.
Agent Substrate ne remplace pas Kubernetes. Il s’installe plutôt comme une couche spécialisée, à côté du control plane standard. Kubernetes continue de fournir l’infrastructure de base : nœuds, Pods, autoscaling, primitives cloud native. Substrate prend en charge les décisions propres aux agents : sessions persistantes, hibernation, réveil, routage vers le bon acteur et multiplexage sur des workers préchauffés.
Le principe rappelle la mémoire virtuelle. Un système d’exploitation permet à des programmes d’adresser plus de mémoire que la machine n’en possède physiquement, en déplaçant les pages froides vers le disque. Agent Substrate applique cette logique aux sessions d’agents : beaucoup de sessions déclarées, beaucoup moins de calcul réellement actif.
Un modèle d’acteurs plutôt qu’un modèle de Pods permanents
Agent Substrate introduit une approche dans laquelle les agents sont traités comme des acteurs stateful. Un pool de workers fournit la capacité prête à l’emploi, tandis que les agents sont activés, suspendus ou restaurés selon les événements.
D’après les informations disponibles, le projet s’appuie notamment sur deux ressources personnalisées :
- WorkerPool, qui décrit la capacité de calcul préchauffée et disponible pour exécuter les agents ;
- ActorTemplate, qui définit la forme des agents à lancer, indépendamment du framework utilisé.
Cette séparation permet d’exécuter différents environnements d’agents : ADK, LangChain, Claude Code ou tout conteneur OCI compatible. L’objectif n’est pas seulement d’héberger un agent isolé, mais des harnais complets d’exécution agentique.
Surallocation et réveil rapide
L’un des intérêts majeurs de Substrate est la surallocation contrôlée. Puisque tous les agents ne sont pas actifs en même temps, la plateforme peut enregistrer beaucoup plus de sessions que ce que les ressources physiques permettraient d’exécuter simultanément.
Google évoque une sursouscription de 30x ou plus, avec une activation inférieure à la seconde dans certains cas. Le point clé est que les workers sont déjà prêts lorsque l’événement arrive. L’agent n’attend donc pas une décision complète du scheduler Kubernetes ni la création d’un environnement depuis zéro.
Pourquoi cette évolution compte pour les équipes cloud native
Pour les architectes plateforme, DevOps et équipes IA, l’arrivée de ces briques confirme une tendance : l’agent IA devient une nouvelle forme de workload, suffisamment différente pour justifier sa propre couche d’exécution.
Jusqu’ici, les grandes catégories de calcul étaient relativement claires : machines virtuelles, conteneurs et serverless. Les agents introduisent une quatrième logique : des sessions longues, souvent inactives, stateful, interactives, capables d’exécuter du code non fiable et sensibles à la latence de réveil.
Ce changement oblige à revoir plusieurs décisions d’architecture :
- Coût : ne pas réserver un Pod complet pour chaque session dormante ;
- Sécurité : considérer le code généré par modèle comme non fiable par défaut ;
- Latence : préchauffer les environnements pour éviter les cold starts ;
- État : sauvegarder et restaurer la mémoire de session sans casser l’expérience utilisateur ;
- Scalabilité du control plane : éviter de transformer chaque événement d’agent en opération Kubernetes lourde.
Comment choisir entre Kubernetes, Agent Sandbox et Agent Substrate
Ces technologies ne s’excluent pas. Dans un déploiement réel, elles ont plutôt vocation à fonctionner ensemble, chacune à son niveau.
- Kubernetes reste la base pour gérer les clusters, les nœuds, les Pods de workers, l’autoscaling et l’intégration avec l’écosystème cloud native.
- Agent Sandbox apporte l’isolation nécessaire lorsque les agents exécutent du code généré, manipulent des outils système ou interagissent avec des ressources sensibles.
- Agent Substrate prend en charge l’ordonnancement spécifique des agents, leur hibernation, leur réveil et leur placement sur des pools de workers adaptés.
Une équipe qui déploie quelques agents internes peut commencer par une architecture Kubernetes classique renforcée par des contrôles de sécurité. En revanche, une plateforme qui exécute des agents de code pour des milliers d’utilisateurs aura rapidement besoin d’un modèle plus spécialisé : sandboxing fort, sessions persistantes, snapshots et scheduling hors du chemin critique Kubernetes.
Le rôle de kagent et des plateformes Kubernetes natives
L’écosystème commence déjà à intégrer ces idées. Solo.io a connecté Agent Substrate à kagent, sa plateforme d’agents Kubernetes-native. L’objectif est de permettre à des environnements agentiques complets d’être programmés comme des acteurs sur un worker pool, depuis une interface unifiée.
Cette intégration illustre probablement la trajectoire à venir : les développeurs ne voudront pas assembler manuellement toutes les briques d’exécution, de sécurité, de snapshot et de routage. Ils chercheront des plateformes capables de masquer la complexité tout en restant compatibles avec les standards cloud native.
Vers un nouveau standard d’orchestration pour les agents IA ?
L’histoire de Kubernetes montre qu’un standard peut émerger lorsqu’un problème d’infrastructure devient suffisamment universel. Les conteneurs avaient besoin d’un orchestrateur commun ; Kubernetes a fini par s’imposer. Les agents IA pourraient suivre une trajectoire similaire, mais rien n’est encore acquis.
Agent Substrate ressemble davantage à un premier signal fort qu’à une conclusion définitive. D’autres runtimes spécialisés arriveront probablement, portés par les hyperscalers, les éditeurs d’outils IA et les fournisseurs de plateformes développeurs. Le risque est clair : si chaque cloud propose son propre control plane d’agents, l’écosystème pourrait se fragmenter au moment même où les entreprises cherchent de la portabilité.
Pour l’instant, le message principal est limpide : Kubernetes reste la machine sous-jacente, mais l’ordonnancement des agents IA est en train de se construire au-dessus de lui. Comme un système d’exploitation qui gère des processus dormants, les futures plateformes d’agents devront savoir suspendre, restaurer, isoler et router des millions de sessions sans faire exploser les coûts ni la latence.
La décennie des conteneurs a été remportée par Kubernetes. La prochaine bataille pourrait se jouer sur la couche qui saura orchestrer les agents IA avec la même évidence.