# gVisor, Agent Substrate, OpenRL : Google confie l'infrastructure des agents IA à la CNCF

Google a annoncé le 5 novembre 2026 la donation de gVisor, Agent Substrate et OpenRL à la Cloud Native Computing Foundation, trois briques qui isolent, orchestrent et entraînent les agents IA autonomes.

Auteur : Veille Moon AI
Catégorie : Produit
Publié le : 2026-11-09T05:38:19+00:00
Mis à jour le : 2026-11-09T05:38:19+00:00

Le 5 novembre 2026, Google a annoncé la donation de trois projets d'infrastructure à la Cloud Native Computing Foundation (CNCF) : gVisor, Agent Substrate et OpenRL. L'annonce, signée par Drew Bradstock, vice-président produit Kubernetes et orchestration chez Google, intervient juste avant KubeCon North America, qui se tient à Salt Lake City du 9 au 12 novembre 2026. La presse spécialisée américaine a immédiatement résumé l'enjeu sous une formule : Kubernetes, acte deux.

## Trois couches pour faire tourner des agents à grande échelle

Les trois projets couvrent des besoins différents mais complémentaires. gVisor isole l'exécution du code non fiable qu'un agent génère ou déclenche : c'est un noyau applicatif léger, écrit en Go, exécuté en espace utilisateur, qui intercepte les appels système avant de les transmettre, sous conditions, au noyau Linux réel de la machine hôte. Il a été ouvert en source sous licence Apache 2.0 en 2018 et fait déjà tourner, selon Google, des millions de sandboxes chaque jour sous GKE Sandbox et Cloud Run.

Agent Substrate gère l'exécution de grands nombres d'agents sur Kubernetes sans gaspiller de ressources quand ils sont inactifs. Le projet sépare l'état persistant d'un agent (mémoire, fichiers, configuration, identité) de la puissance de calcul qui l'exécute : les premiers sont portés par des « Actors », les seconds par des « Workers » piochés dans une réserve de pods pré-chauffés. Quand un agent se met en pause en attendant une réponse de modèle ou un tour humain, son état est sauvegardé sur un stockage à plusieurs niveaux et le Worker est rendu disponible pour une autre session.

OpenRL, le plus récent des trois, a été lancé en research preview en février 2026, orchestre l'entraînement par renforcement des modèles sur une infrastructure Kubernetes. Il fournit quatre primitives Python simples (sample, forward_backward, optim_step, save_state) via une API compatible Tinker, et s'appuie sur l'allocation dynamique de ressources de Kubernetes pour répartir les accélérateurs. Gemma et Qwen sont validés comme modèles de référence ; le support TPU est annoncé en préparation. OpenRL se combine avec llm-d, projet CNCF fondé par Red Hat, Google Cloud, IBM Research, CoreWeave et NVIDIA.

« Nous pensons que ces donations accélèreront le développement et l'adoption des charges agentiques à travers ces projets, comme ce fut le cas avec Kubernetes », écrit Drew Bradstock dans l'annonce officielle de Google Cloud.

## Pourquoi Google renonce au contrôle exclusif

La motivation tient à trois éléments : gouvernance, performance, adoption. gVisor ne rentre pas dans les cases habituelles de la sécurité informatique, qui opposent « conteneur classique » et « machine virtuelle ». Les auditeurs et régulateurs traitent souvent la virtualisation complète comme synonyme de sécurité, une dichotomie qui a freiné l'adoption de gVisor malgré un niveau de protection jugé équivalent par ses contributeurs.

S'ajoute un problème de performance. Des équipes internes chez Google, ainsi que chez Ant Group et Modal, ont développé des patchs noyau Linux qui améliorent sensiblement les performances de gVisor. Les mainteneurs du noyau Linux ont refusé de les intégrer en amont au motif que gVisor restait un projet entièrement détenu par un seul acteur. En passant sous gouvernance CNCF, ces patchs ont désormais une chance réelle d'être upstreamés.

Enfin, la liste des adoptants actuels de gVisor (Google, Ant Group, OpenAI, Anthropic, et des entreprises spécialisées comme Modal et Tines) montre que seules de grandes structures capables d'investir dans l'adaptation du projet s'en servaient. Avec la donation, Ant Group, Modal et Tines s'engagent comme mainteneurs, tandis qu'OpenAI, Tencent et NVIDIA poursuivent leurs contributions.

## Un calendrier de transfert, mais des dates qui divergent selon les sources

Le calendrier publié par les contributeurs de gVisor, Etienne Perot et Jing Chen, est précis pour ce projet : candidature soumise le 7 septembre 2026, examen le 22 septembre, acceptation par la CNCF le 28 septembre, billet officiel le 2 octobre. L'onboarding vers le statut Sandbox a commencé début novembre. Pour Agent Substrate, les sources ne s'accordent pas totalement : un article indépendant publié le 10 octobre situe aussi l'acceptation au 28 septembre, alors que le billet officiel de Google Cloud du 5 novembre évoque une acceptation « le mois dernier », soit en octobre.

| Étape | Date communiquée | Source |
| --- | --- | --- |
| Candidature de gVisor à la CNCF | 7 septembre 2026 | Blog gVisor (Perot, Chen) |
| Examen par la CNCF | 22 septembre 2026 | Blog gVisor |
| Acceptation en statut Sandbox | 28 septembre 2026 | Blog gVisor ; confirmé pour Agent Substrate par un article indépendant du 10 octobre |
| Billet officiel gVisor | 2 octobre 2026 | Blog gVisor |
| Annonce Google Cloud (3 projets) | 5 novembre 2026 | Google Cloud Blog, Google Open Source Blog |
| Onboarding Sandbox | Début novembre 2026 | Blog gVisor |

Dans les prochaines semaines, l'infrastructure de build et de test migre vers GitHub Actions et Buildkite, et l'infrastructure de test interne de Google cesse de bloquer les pull requests externes. Dans les prochains mois, le dépôt quittera l'organisation GitHub de Google, des mainteneurs extérieurs obtiendront les droits de fusion, et la gouvernance basculera vers un vote par organisation.

La question de la maturité d'Agent Substrate illustre bien ces divergences. Google annonce une version 1.0 et une disponibilité générale sur Google Kubernetes Engine (GKE), avec plus de 100 contributeurs depuis le lancement du développement public en mai 2026. Mais selon un article publié le 6 novembre par TechTimes, le fichier README du dépôt GitHub décrit toujours le projet comme antérieur à la version 1.0, sans garantie de compatibilité ascendante, et aucune version finale v1.0.0 n'apparaît dans la liste des publications du dépôt à la date de l'article, seulement un candidat de version daté du 29 octobre.

## Ce que cela change pour le contrôle et la conformité des DSI françaises

L'intérêt pour un responsable informatique en France ne tient pas d'abord à la technique, mais à la gouvernance. Tant que gVisor restait un projet détenu par un seul hyperscaler, les équipes de sécurité et de conformité devaient évaluer un risque de dépendance qui s'ajoutait au risque technique : une feuille de route décidée ailleurs, des correctifs soumis au bon vouloir d'un seul acteur, et une difficulté à faire reconnaître le projet par des référentiels d'audit qui assimilent trop souvent la virtualisation matérielle à la seule garantie de sécurité valable. Le passage sous gouvernance CNCF, avec vote par organisation et mainteneurs non liés à Google, répond directement à ce point de friction documenté par les contributeurs eux-mêmes.

Le contexte sécuritaire donne du poids à la démarche. Dans un rapport de sécurité daté du 4 novembre 2026, OpenAI cite explicitement gVisor et Firecracker comme des sandboxes importantes pour limiter les dégâts des vulnérabilités du noyau Linux exploitées, ce qui confirme un usage réel en production chez un acteur majeur du secteur.

Pour une entreprise française qui construit une stratégie multi-modèles, comme celle que propose Moon AI, édité par Stellarr Studio SAS, avec plus de 100 modèles accessibles via un abonnement unique, la question de l'infrastructure d'exécution des agents reste distincte de celle de l'accès aux modèles eux-mêmes. Mais les deux sujets se recoupent dès qu'une organisation confie à un agent l'exécution de code ou d'actions : la couche qui isole et orchestre cette exécution devient alors aussi déterminante pour l'auditabilité que le choix du modèle de langage.

Reste une nuance que les équipes de conformité ne doivent pas oublier : la page officielle des projets CNCF décrit le statut Sandbox comme expérimental et pas encore largement éprouvé en production. Passer sous gouvernance neutre réduit un risque de gouvernance, mais ne garantit pas, à ce stade, une maturité opérationnelle suffisante pour des charges critiques.

## Les limites à vérifier avant un déploiement en production

### Pas de GPU, pas de snapshot CUDA en direct

La documentation d'Agent Substrate publiée par Google liste des limites précises : le passage direct de périphériques GPU dans les conteneurs d'agents n'est pas pris en charge, et gVisor ne peut pas instantanément sauvegarder des contextes CUDA actifs. Les connexions réseau ouvertes, par exemple vers une base de données ou un serveur MCP, ne sont pas préservées lorsqu'un agent se suspend : le code de l'agent doit se reconnecter après la reprise. Les clusters pris en charge sont les clusters GKE Standard en version 1.37 ou ultérieure.

### Agent Substrate face à Agent Compute Engine

Google propose en parallèle un service managé distinct, Agent Compute Engine, annoncé le 22 octobre 2026, qui attribue à chaque agent sa propre microVM avec attestation matérielle via l'infrastructure Titanium de Google, et conserve les identifiants hors du bac à sable. Ce service est annoncé en préversion dans les mois à venir, sans date précise ni grille tarifaire publiée à ce stade.

| Critère | Agent Substrate (open source, donné à la CNCF) | Agent Compute Engine (service managé Google) |
| --- | --- | --- |
| Nature de l'isolation | Noyau logiciel gVisor ou microVM Cloud Hypervisor au choix | MicroVM matérielle avec attestation Titanium |
| Disponibilité | Code source public, GA sur GKE pour les charges non critiques | Préversion annoncée, sans date précise |
| Tarification | Infrastructure Kubernetes de l'utilisateur | Non communiquée |
| Gouvernance | CNCF, statut Sandbox | Service propriétaire Google Cloud |

## Questions fréquentes

### La donation à la CNCF change-t-elle quelque chose pour une entreprise qui utilise déjà gVisor ?

Oui, sur le plan de la gouvernance. L'entreprise continue d'utiliser le même code, mais la feuille de route et les décisions de fusion ne dépendent plus d'un seul éditeur. Les patchs de performance bloqués jusqu'ici par les mainteneurs du noyau Linux, au motif que gVisor appartenait à un seul acteur, ont désormais une chance d'être intégrés en amont.

### Agent Substrate est-il prêt pour la production ?

Google annonce une version 1.0 et une disponibilité générale sur GKE, avec un seuil de reprise annoncé sous 500 millisecondes et une densité dix fois supérieure aux runtimes de conteneurs classiques. Ces chiffres sont ceux communiqués par Google, sans méthode de benchmark détaillée dans ses billets. Un article de TechTimes relève par ailleurs que le dépôt GitHub du projet se décrit encore comme antérieur à la version 1.0 à la date de l'annonce. Il est recommandé de vérifier directement le tag de version et la politique de stabilité dans le dépôt avant toute mise en production.

### Quelle différence entre Agent Substrate et Agent Compute Engine ?

Agent Substrate est un runtime Kubernetes open source, désormais sous gouvernance CNCF, qui s'appuie sur gVisor ou sur des microVM Cloud Hypervisor. Agent Compute Engine est un service managé distinct de Google, qui attribue à chaque agent une microVM matérielle attestée, actuellement en préversion annoncée sans date ni tarif publiés.

### Que signifie concrètement le statut « CNCF Sandbox » ?

C'est le premier palier de maturité de la CNCF, que la fondation elle-même qualifie d'expérimental et pas encore largement éprouvé en production. Il atteste d'une gouvernance neutre et ouverte, pas d'une garantie de fiabilité opérationnelle. gVisor est, de son côté, engagé sur une trajectoire vers le statut Incubation, supérieur au Sandbox.

© 2026 Stellarr Studio SAS. Tous droits réservés. Moon AI, Moon Blur et Stellarr Studio sont des marques déposées à l’INPI.