Google transforme l’infrastructure des agents Gemini en service cloud
Le 22 octobre 2026, Google Cloud dévoile Agent Compute Engine, un service de calcul qui exécute chaque agent IA dans sa propre microVM isolée matériellement, sans aucun identifiant dans la sandbox. Évaluez la préversion dès son ouverture si vous faites tourner des agents Gemini en production, et traitez l’isolation microVM-par-agent comme la nouvelle référence à répliquer.
22 octobre 2026. Google Cloud dévoile Agent Compute Engine, un service de calcul pensé spécifiquement pour exécuter des agents IA à l’échelle, lors des conférences AGNTCon et MCPCon. 22 octobre 2026. Chaque agent y tourne dans sa propre microVM isolée matériellement, une sandbox qui ne contient aucun identifiant. 22 octobre 2026. Le service propulse déjà Gemini dans ses tâches d’agent pour le travail, et une préversion publique doit arriver avant la fin de l’année. Pourquoi c’est important : l’agent qui agit à votre place détient des clés, et Google vient d’inventer un endroit où il peut agir sans en détenir aucune.
Un runtime dédié aux agents, enfin
Jusqu’ici, un agent IA n’est qu’un programme qui tourne quelque part — dans un conteneur, sur une VM, dans un cluster Kubernetes — avec les mêmes primitives que n’importe quelle application. Le problème, c’est qu’un agent n’est pas une application comme les autres : il prend des décisions, il appelle des outils, il lit et écrit des identifiants, et il le fait avec un degré d’autonomie qui rend la revue humaine illusoire à l’échelle.
Agent Compute Engine répond à ce vide en proposant un runtime dédié. L’annonce de Google Cloud est explicite : il s’agit d’un service de calcul « construit spécifiquement pour exécuter des agents IA à l’échelle ». La brique centrale est la microVM isolée matériellement — une frontière d’isolation qui ne repose pas sur le partage du noyau d’un conteneur, mais sur la virtualisation matérielle, la même technologie qui sépare déjà les locataires d’un hyperviseur.
Le choix de la microVM plutôt que du conteneur n’est pas anodin. Un conteneur partage le noyau de son hôte ; une compromission du runtime ou une escalade de privilèges y est un scénario connu. Une microVM, elle, s’appuie sur une frontière plus profonde — typiquement KVM ou une technologie équivalente — et réduit la surface qu’un agent compromis peut atteindre. Pour un service dont le produit est précisément « un agent autonome qui manipule vos outils », cette profondeur d’isolation est le minimum viable, pas un luxe.
Une microVM par agent, zéro identifiant dans la sandbox
Le détail le plus frappant de l’annonce tient en une phrase : la sandbox ne contient aucun identifiant. Concrètement, l’agent ne reçoit pas de clé API, de jeton de service ou de secret de base de données embarqué dans son environnement d’exécution. Les identifiants nécessaires à ses actions sont injectés à l’extérieur de la microVM, au moment de l’exécution, via un mécanisme qui ne les expose pas au processus lui-même.
C’est un renversement par rapport à la pratique courante. Aujourd’hui, la plupart des agents embarquent leurs secrets dans des variables d’environnement ou un coffre accessible depuis le runtime — exactement le modèle que la compromission de Railway vient de rappeler à ses risques : quand l’hôte est compromis, les secrets lisibles deviennent volables. En déplaçant la garde des identifiants hors de la sandbox, Google retire à l’agent la capacité de les exfiltrer par lui-même, même s’il est totalement compromis.
Le modèle « une microVM par agent » change aussi le rayon de souffle d’un incident. Là où une flotte d’agents partageait un même hôte et un même espace de secrets, chaque agent devient une unité jetable et isolée. Un agent corrompu ne peut ni lire les identifiants de ses voisins, ni rebondir vers l’infrastructure qui les héberge. Pour un RSSI, la question n’est plus « comment confiner cent agents », mais « comment rejeter un agent à la fois ».
Gemini a déjà basculé dessus
Le point le plus rassurant de l’annonce n’est pas marketing : Agent Compute Engine n’est pas un service vide qui attend ses premiers clients. Google indique que l’infrastructure « propulse déjà Gemini » dans ses fonctions d’agent pour les tâches de travail. Autrement dit, le produit est dogfoodé en interne avant d’être exposé, ce qui réduit le risque d’un lancement théorique dont personne n’a éprouvé les limites.
Ce détail a une seconde lecture. Si Gemini — l’agent le plus exposé de l’écosystème Google — tourne déjà sur cette couche d’isolation, c’est que le modèle microVM-par-agent supporte une charge réelle, avec de vrais appels d’outils et de vrais flux de secrets. Pour les équipes qui hésitent à confier leurs propres agents à une abstraction nouvelle, c’est un argument plus solide qu’une page de documentation.
La préversion publique, annoncée « plus tard cette année », sera le moment de vérité : les détails qui manquent encore — tarification, granularité des politiques, latence d’amorçage d’une microVM à froid — détermineront si le service tient ses promesses au-delà de la démonstration. D’ici là, l’architecture est déjà lisible, et c’est elle qu’il faut retenir.
La gouvernance s’étend au cloud, à l’hybride et à l’on-premise
Le second volet de l’annonce concerne la gouvernance. Google étend les capacités de gouvernance de Gemini for business pour permettre aux entreprises d’« exécuter, gouverner et mettre à l’échelle » leurs agents, non seulement dans le cloud, mais aussi en hybride et on-premise.
Cette extension répond à une objection récurrente des grandes organisations : on ne confie pas un agent qui manipule des données sensibles à une infrastructure qu’on ne contrôle pas. En déclinant la gouvernance sur les trois surfaces — cloud, hybride, sur site — Google cherche à faire de son modèle d’isolation une référence applicable partout, pas seulement dans ses propres datacenters. C’est aussi une façon de répondre aux réglementations qui imposent une résidence des données ou un périmètre de traitement précis.
Pour un opérateur, la conséquence pratique est simple : les politiques qui encadrent « qui peut déployer quel agent, avec quels outils, dans quelle zone » deviennent un objet de configuration de premier ordre, au même titre que les droits d’accès d’un service classique. L’agent cesse d’être un programme hors contrôle pour devenir une charge de travail gouvernée.
Ce que ça change pour un SRE, et ce qu’il manque
Sur le terrain, Agent Compute Engine ne supprime pas le travail, il le déplace. Le SRE n’a plus à défendre un hôte partagé contre une flotte d’agents ; il doit en revanche concevoir le flux d’injection des identifiants, auditer les outils auxquels chaque agent a accès et instrumenter l’observabilité de microVMs qui naissent et meurent en quelques secondes. La microVM répond à la question de l’isolation, pas à celle de la responsabilité — personne n’a encore résolu « qui on-call un agent qui échoue ».
Il manque aussi des éléments de comparaison. Le concurrent direct le plus proche, AWS, pousse ses propres briques d’exécution d’agents via Bedrock et ECS, tandis que les fournisseurs de modèles — OpenAI, Anthropic — vendent surtout des runtimes logiciels, pas des frontières matérielles. Tant que la tarification et les limites d’Agent Compute Engine ne sont pas publiques, impossible de dire si le surcoût d’une microVM par agent se justifie face à un conteneur bien configuré pour les charges les moins sensibles.
La lecture la plus utile de l’annonce est donc architecturale. Google pose un standard : l’agent de production mérite une frontière matérielle et une sandbox sans identifiant. Que vous adoptiez le service ou non, cette exigence est désormais ce qu’on peut légitimement demander à n’importe quelle plateforme d’agents.
Verdict
Si vous faites tourner des agents Gemini en production, inscrivez-vous à la préversion d’Agent Compute Engine dès son ouverture et commencez par y migrer les agents qui manipulent des identifiants ou des données sensibles — ce sont eux qui justifient le coût d’une frontière matérielle. Si vos agents tournent sur une autre pile, ne restez pas sur un conteneur partagé qui embarque ses secrets : répliquez le modèle une microVM par agent, zéro identifiant dans la sandbox, ne serait-ce qu’avec gVisor, Kata Containers ou Firecracker et un coffre externe qui injecte les secrets au moment de l’appel. Si vous évaluez des plateformes d’agents, faites de l’isolation matérielle et de la garde externe des identifiants deux critères de sélection non négociables. L’annonce de Google n’est pas une promesse de plus : c’est la première fois qu’un grand cloud transforme l’exigence de confiance dans un agent en un produit de calcul à part entière.