RéponsesPublié19 sources
Google veut connecter les données entre clouds pour ses agents IA, sans promettre la gratuité
Le 4 novembre 2026, Google a annoncé des évolutions de son Agentic Data Cloud, centrées sur l’accès aux données réparties entre plusieurs clouds et leur mise en contexte pour les agents IA. Le Borderless Lakehouse s’appuie sur le format ouvert Apache Iceberg pour interroger des données sans les rapatrier systématiqu...
Publié parModifié avec GPT-6 LunaImages générées avec GPT Image 2
Réponse de recherche
Points clés à retenir
- Le 4 novembre 2026, Google a annoncé des évolutions de son Agentic Data Cloud, centrées sur l’accès aux données réparties entre plusieurs clouds et leur mise en contexte pour les agents IA.
- Le Borderless Lakehouse s’appuie sur le format ouvert Apache Iceberg pour interroger des données sans les rapatrier systématiquement dans un entrepôt central.
- Les sources disponibles ne démontrent ni la disparition de tous les frais liés aux requêtes multicloud, ni la capacité d’un agent à exécuter une tâche métier de façon sûre.
Prompt IA
openai.comCreate a landscape editorial hero image for this Studio Global article: What did Google announce on November 4, 2026, about its Agentic Data Cloud, first introduced at Google Cloud Next 2026, and how do its Apach. Article summary: On November 4, 2026, Google announced updates to its Agentic Data Cloud centered on querying distributed data and giving AI agents more consistent business context, extending the architecture introduced at Google Cloud N. Topic tags: general, documentation, general web. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fak
L’annonce de Google du 4 novembre 2026 porte sur un enjeu concret : permettre aux agents d’IA d’utiliser des données réparties dans l’environnement cloud d’une entreprise, sans devoir tout regrouper au même endroit, et leur fournir le contexte métier nécessaire pour les interpréter. Deux éléments sont au cœur de cette approche : le Borderless Lakehouse, fondé sur Apache Iceberg, et Knowledge Catalog. Mais les fonctionnalités n’ont pas toutes le même niveau de disponibilité, et les éléments publiés ne prouvent ni que l’accès multicloud supprime tous les frais ni que toutes les économies avancées sont vérifiées. 4
10
Interroger les données là où elles se trouvent
Google présente le Borderless Lakehouse comme une base de données gouvernée construite autour du format ouvert Apache Iceberg. Sa documentation décrit Iceberg comme le socle d’une interface unifiée pour l’analytique et l’IA. 4
1 Les documents de Google mettent en avant la possibilité d’interroger et d’exploiter des données réparties entre plusieurs clouds sans les déplacer. Selon la couverture sectorielle de l’annonce, les requêtes peuvent porter sur des données hébergées chez AWS et Azure.
15
3
L’idée diffère d’une architecture où les données doivent d’abord être copiées dans un entrepôt central avant d’être analysées. En théorie, interroger les données sur place peut éviter certains pipelines conçus uniquement pour les recopier d’un système à l’autre. Cela suppose toutefois que les connexions, les autorisations, les formats et les services concernés soient configurés.
Une disponibilité générale qui ne couvre pas tout
La page produit de Google indique que le Borderless Lakehouse est généralement disponible. 11 Cela ne signifie pas que chaque intégration ou fonction de fédération le soit aussi : la présentation du Lakehouse par Google indique que la fédération de catalogues avec AWS Glue, Databricks Unity Catalog et Snowflake Horizon est en préversion.
10 La documentation décrit également une connexion multicloud permettant d’interroger depuis Google Cloud les données d’un Databricks Unity Catalog.
Cette distinction compte lorsqu’on évalue les affirmations sur les connexions privées, la mise en cache ou les intégrations sans copie des données. Les extraits disponibles ne permettent pas de vérifier l’ensemble des détails de réseau et de cache pour AWS et Azure, ni les intégrations sans copie avec SAP, Workday et Salesforce. Ces précisions ne peuvent donc pas être considérées comme établies ici.
Knowledge Catalog apporte le contexte métier
Des tables accessibles ne suffisent pas à expliquer à un agent ce que signifie un indicateur, quelle définition une équipe utilise ou comment plusieurs jeux de données sont liés. Google présente Knowledge Catalog comme un moyen d’associer aux données un contexte métier partagé et gouverné. L’annonce de novembre précise que le Borderless Lakehouse s’intègre à Knowledge Catalog pour indexer des données distribuées et non structurées dans le cloud, afin de fournir du contexte aux agents. 4
Google a aussi présenté l’enrichissement de contexte auto-apprenant et Knowledge Studio comme des fonctions en préversion. L’enrichissement doit repérer des lacunes dans le contexte métier à partir des interactions entre les agents et les utilisateurs. Knowledge Studio fournit aux responsables des données des outils pour explorer et examiner ce contexte. 19 Ces fonctions portent sur la gestion du contexte ; elles ne prouvent pas, à elles seules, qu’un agent peut exécuter un processus métier en toute sécurité.
Les notes de version de Gemini Enterprise documentent une préversion du mode de requête fédérée pour les connecteurs Data Cloud et une préversion de l’intégration de Knowledge Catalog. Lorsqu’un connecteur Data Cloud en mode fédéré est associé, Knowledge Catalog est automatiquement activé pour l’Assistant. Celui-ci dispose alors d’outils en lecture seule pour rechercher les données accessibles à l’utilisateur et récupérer du contexte technique et métier. 17 Il s’agit d’une intégration documentée et délimitée, pas d’une confirmation de toutes les affirmations plus générales sur la prise en charge de Gemini.
Les frais d’egress ne résument pas le coût total
Google met en avant l’accès aux données sans les déplacer, et la couverture de l’annonce évoque des requêtes entre AWS et Azure sans frais variables de sortie de données (« egress »). 15
3 Toutefois, les extraits disponibles de l’annonce et de la documentation ne démontrent pas que tous les frais liés à l’accès à un cloud distant disparaissent, ni ne donnent suffisamment de détails pour évaluer le coût total d’une charge de travail donnée.
De même, les éléments fournis ne permettent pas d’étayer la réduction d’environ 40 % des coûts de déplacement des données rapportée pour talabat, ni de confirmer la configuration précise reliant des données Iceberg dans Amazon S3 à BigQuery. Même si cette économie était vérifiée, elle ne démontrerait pas, à elle seule, une baisse équivalente du coût total des requêtes ou de celui nécessaire pour mener à bien une tâche confiée à un agent.
Des mises à jour de bases de données, mais peu de détails vérifiables
Des articles publiés au moment de l’annonce citent AlloyDB et BigQuery parmi les produits mis à jour, aux côtés de Knowledge Catalog. 3 Les extraits disponibles ne permettent pas de confirmer qu’AlloyDB peut joindre directement des données historiques Iceberg à des données opérationnelles PostgreSQL en temps réel.
Spanner Omni s’inscrit également dans la stratégie plus large de Google en matière de données, mais son calendrier est distinct : Google a annoncé sa disponibilité générale le 30 septembre 2026, en le présentant comme une base de données distribuée et multimodèle déployable sur site ou dans d’autres clouds. Elle n’a donc pas été annoncée pour la première fois comme généralement disponible le 4 novembre. 20
Ce que l’annonce dit — et ne dit pas — sur les agents
La conclusion étayée par les sources est que Google développe une couche d’accès aux données multicloud et l’associe à un contexte partagé pour les assistants et les agents IA. Cette combinaison peut aider les agents à trouver des informations pertinentes et à s’appuyer sur des définitions cohérentes. 4
17
19
Elle ne démontre pas, à elle seule, qu’un agent sait exécuter un processus métier en toute sécurité. Pour l’établir, il faudrait aussi des éléments sur les autorisations, la validation, la gestion des transactions, l’audit, la récupération après erreur et le coût total d’une tâche menée à bien. Les extraits fournis ne suffisent pas non plus à vérifier les évaluations d’analystes citées ou les comparaisons avec Microsoft, Databricks, Snowflake et AWS. L’annonce décrit une orientation de plateforme ; les promesses d’exécution autonome et leur économie demandent des preuves au-delà de l’accès aux données et des fonctions de contextualisation.
Studio Global AI
Continuez vos recherches
Cette page comprend une réponse basée sur la source que vous pouvez continuer dans Studio Global.
Les gens demandent aussi
Quelle est la réponse courte à « Google veut connecter les données entre clouds pour ses agents IA, sans promettre la gratuité » ?
Le 4 novembre 2026, Google a annoncé des évolutions de son Agentic Data Cloud, centrées sur l’accès aux données réparties entre plusieurs clouds et leur mise en contexte pour les agents IA.
Quels sont les points clés à valider en premier ?
Le 4 novembre 2026, Google a annoncé des évolutions de son Agentic Data Cloud, centrées sur l’accès aux données réparties entre plusieurs clouds et leur mise en contexte pour les agents IA. Le Borderless Lakehouse s’appuie sur le format ouvert Apache Iceberg pour interroger des données sans les rapatrier systématiquement dans un entrepôt central.
Que dois-je faire ensuite en pratique ?
Les sources disponibles ne démontrent ni la disparition de tous les frais liés aux requêtes multicloud, ni la capacité d’un agent à exécuter une tâche métier de façon sûre.