Google Cloud mise sur des agents IA pour gérer les bases de données et les workloads persistants

En août 2026, Google Cloud a présenté deux offres destinées à réduire le travail opérationnel nécessaire pour faire fonctionner des agents IA : des agents spécialisés dans la gestion des bases de données, et un nouveau runtime Cloud Run pour les agents qui doivent rester en ligne plutôt que repartir de zéro à chaque requête. L’ensemble s’inscrit dans la stratégie « Agentic Data Cloud » de Google Cloud, qui vise à rendre l’infrastructure plus autonome, conversationnelle et adaptée aux agents. 211

Des agents pour gérer les bases de données de bout en bout

Annoncés au début du mois d’août, les Database Operations Agents sont intégrés à Gemini Cloud Assist. Ils couvrent deux étapes distinctes du cycle de vie d’une base de données : la mise en service initiale, puis la supervision et la maintenance.

Le Database Onboarding Agent : du besoin métier au déploiement

Le Database Onboarding Agent s’attaque au « jour zéro », c’est-à-dire aux opérations préalables à la mise en production. À partir d’une description des besoins d’une charge de travail, il peut recommander un service de base de données approprié et guider les équipes dans la configuration, le paramétrage et le déploiement.

L’objectif est de limiter les décisions d’architecture et les étapes de provisionnement effectuées manuellement. L’agent prend en charge AlloyDB, Bigtable, Cloud SQL et Spanner. 2

Le Database Observability Agent : surveiller, diagnostiquer et corriger

Le Database Observability Agent prend le relais pour les opérations des « jours un et deux » : surveillance d’un parc de bases, détection d’anomalies, diagnostic, dépannage, optimisation et maintenance. Il prend en charge Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore et Memorystore. 213

Pour rechercher l’origine d’un incident, il corrèle les données issues de Database Insights et Database Center, de Cloud Monitoring, de Cloud Logging et de Cloud Trace, ainsi que les métriques, les informations sur les requêtes, l’inventaire et les données relatives aux problèmes. Cette corrélation doit lui permettre de produire une analyse de cause racine plutôt que de simples alertes isolées. 2

L’outil ne se limite pas aux recommandations. Avec l’accord d’un humain, il peut exécuter des actions correctives validées, par exemple activer le regroupement des connexions (connection pooling) dans Cloud SQL ou ajouter des index. Les fonctions d’investigation et de remédiation intégrées étaient proposées en préversion à un groupe de clients sélectionnés. 2

Les agents sont accessibles depuis les conversations Gemini et les pages pertinentes de la console Google Cloud. Google a également prévu des points d’accès via la ligne de commande, des serveurs et outils MCP, des outils tiers et des environnements de développement intégrés. 2

Cloud Run accueille des agents qui doivent rester actifs

Le 28 août, Google Cloud a aussi présenté en préversion une instance Cloud Run singleton. Contrairement au fonctionnement habituel des services sans serveur, cette ressource correspond à une seule instance, sans autoscaling. Elle vise donc des workloads avec état et continuellement disponibles plutôt que des services sans état conçus pour absorber un grand volume de requêtes. 4

Une instance peut fonctionner pendant sept jours maximum. Une politique de redémarrage automatique est configurée par défaut, tandis que son URL HTTPS reste stable lors des mises à jour et des redémarrages. L’utilisateur peut également arrêter l’instance, puis la reprendre ultérieurement. 4

Google cite un prix de 5,70 dollars pour 30 jours d’exécution continue avec 1 vCPU et 1 Gio de mémoire vive, grâce à un vCPU partagé et à des budgets de burst. L’intérêt mis en avant ne serait pas seulement financier : contrairement à une machine virtuelle dédiée, l’utilisateur n’a pas à assurer la maintenance du système d’exploitation et de la VM, à gérer le pare-feu ni à provisionner lui-même un point d’accès HTTPS. 4

Le premier cas d’usage évoqué concerne les agents IA personnels de longue durée, comme OpenClaw ou Hermes, qui servent un seul utilisateur et doivent conserver leur état même lorsque l’ordinateur portable de celui-ci est éteint. 4

Google cite par ailleurs un témoignage client d’OffDeal faisant état d’une réduction de 88 % des démarrages à froid. Ce chiffre rapporté par un client ne constitue ni une garantie générale de performance de Google, ni un benchmark applicable à tous les workloads. 4

Une infrastructure pensée pour les agents, pas seulement pour les applications web

Ces deux annonces répondent à deux besoins différents mais liés. Les Database Operations Agents rendent la couche de données plus « agentique » : une interface en langage naturel peut aider à provisionner, observer, diagnostiquer et, après approbation, corriger des bases de données gérées. Les instances Cloud Run fournissent de leur côté une primitive de calcul mieux adaptée aux processus d’agents durables et conservant un état. 24

Google Cloud part ainsi du constat que les agents IA ne se comportent pas toujours comme des applications web classiques. Ils peuvent avoir besoin d’une identité et d’un point d’accès persistants, d’une mémoire ou d’un état durable, d’une exécution en arrière-plan sur une longue période et d’un accès continu à des outils et à des données.

L’approche retenue combine donc automatisation opérationnelle et infrastructure gérée. Elle ne supprime toutefois pas entièrement l’intervention humaine : pour les changements importants sur les bases de données, l’exécution des remédiations reste soumise à une validation. 24