9 min de lecture

Google regroupe BigQuery, AlloyDB, Spanner et Apache Spark sous un même nom et appelle le résultat Agentic Data Cloud. Cela ressemble à du marketing. Mais cela devient concret lorsqu’on examine de plus près l’annonce de la Lakehouse cross-cloud : BigQuery peut désormais interroger des tables Iceberg sur Amazon S3, sans frais d’egress, via les propres liaisons Cross-Cloud Interconnect de Google. Ce n’est pas une simple annonce de fonctionnalité. C’est un argument de prix contre Databricks.

Les points clés en bref

• Lakehouse cross-cloud sans frais d’egress : BigQuery lit et écrit des tables Iceberg sur AWS S3 et Azure Data Lake Storage, sans frais d’egress grâce à Cross-Cloud Interconnect. Pas de déplacement de données, pas de copie, pas de double paiement.
• Fédération bidirectionnelle des catalogues : Databricks Unity Catalog, Snowflake Polaris et AWS Glue sont désormais fédérés. Les moteurs lisent et écrivent directement dans les catalogues respectifs des autres. Partage zéro-copie, sans ETL.
• Migration en environ 9 mois : Google indique que la durée moyenne d’une migration cloud-to-cloud est de neuf mois – bien inférieure au délai de plusieurs années précédemment annoncé.
• Iceberg géré disponible en GA : BigQuery Lakehouse est généralement disponible avec gestion automatique des tables, transactions multi-tables, capture des changements de données et optimisations basées sur l’historique.

Articles connexesÉtat de FinOps 2026 : Gestion de la valeur technologique  /  BYOD dans l’entreprise allemande en 2026

Ce que Google entend par Agentic Data Cloud

Google positionne BigQuery, AlloyDB, Spanner et Apache Spark comme une plateforme unifiée face à Databricks et Snowflake. Ce que cela signifie concrètement pour les architectures DACH est détaillé dans les annonces de Google Cloud Next 2026.

Qu’est-ce que l’Agentic Data Cloud de Google ? Il s’agit d’un cadre stratégique autour d’AlloyDB, BigQuery, Spanner, Bigtable et du service Managed Apache Spark. L’objectif : ne plus traiter les données d’entreprise uniquement pour les analystes humains, mais les rendre disponibles comme contexte pour des agents d’IA autonomes. Au cœur se trouve un « Universal Context Engine » – une couche qui empêche les agents de faire des hallucinations parce qu’ils n’ont pas accès aux bonnes données d’entreprise.

C’est une approche techniquement cohérente. Les workflows agents n’ont pas besoin de rapports statiques ; ils ont besoin d’un accès en temps réel aux données – en lecture et en écriture, à travers les frontières des systèmes. Jusqu’à présent, c’était l’argument en faveur de Databricks : une plateforme ouverte, basée sur Spark, qui peut en principe communiquer avec tout. Google tente maintenant de dévaloriser cet argument.

Concrètement, cela signifie que les agents basés sur Gemini dans Vertex AI peuvent accéder directement à BigQuery, sans passer par des pipelines ETL manuels. Le framework BigQuery Cortex accélère cela grâce à des connecteurs prêts à l’emploi pour SAP, Salesforce et Oracle. Cela ressemble à une solution catalogue standard – mais, en termes d’étendue des intégrations et de profondeur d’intégration avec GCP, c’est véritablement nouveau.

Cross-Cloud Lakehouse : la véritable offensive

L’élément qui devient pertinent dans les discussions avec les clients de Databricks n’est pas le branding axé sur l’agentique. C’est le Cross-Cloud Lakehouse. BigQuery peut désormais lire et écrire des tables Iceberg stockées physiquement sur Amazon S3 ou Azure Data Lake Storage. La connexion s’établit via Cross-Cloud Interconnect – une ligne privée dédiée, sans passer par l’internet public, ni frais de sortie (egress).

Cela est significatif car cela renverse l’argument des coûts de sortie des données. Jusqu’à présent, une migration vers BigQuery était souvent coûteuse parce qu’il fallait déplacer les données hors de S3 ou d’Azure. Aujourd’hui, ceux qui exploitent Databricks sur AWS et souhaitent tester BigQuery en parallèle n’ont plus besoin de prévoir de grands mouvements de données. Le Lakehouse réside sur S3, BigQuery y accède directement.

Fédération de catalogues et la pomme de discorde Databricks

La fédération de catalogues constitue le deuxième grand levier. Google a annoncé une fédération bidirectionnelle pour Databricks Unity Catalog, Snowflake Polaris et AWS Glue. Les moteurs peuvent écrire et lire directement dans le catalogue de l’autre – sans copies de données, sans pipelines ETL intermédiaires. Partage sans copie (Zero-Copy-Sharing).

Pour les entreprises de la région DACH qui exploitent déjà Databricks et se demandent si BigQuery convient mieux à certaines charges de travail, la discussion est différente de celle d’il y a douze mois. Il n’est plus nécessaire de choisir. On peut commencer à déplacer sélectivement les charges de travail, tandis que la base de données reste sur S3 ou dans Databricks.

« La migration n’est plus un projet pluriannuel. Les transferts cloud-to-cloud prennent aujourd’hui neuf mois en moyenne. La question n’est plus de savoir si, mais quelle charge de travail migrer en premier. »

BigQuery Lakehouse vs. Databricks pour les architectures DACH

Dans les environnements d’entreprise de la zone DACH, le débat s’articule généralement autour de trois axes : la gouvernance et la souveraineté des données, le coût total de possession (TCO) et l’intégration aux paysages SAP existants. Google a directement répondu à ces trois points.

Pour ceux qui construisent principalement de l’analytics, du BI et du contexte d’agents dans l’écosystème GCP, BigQuery Lakehouse offre aujourd’hui un argument sérieux. Pour ceux qui exploitent des workflows Machine Learning basés sur Spark avec des équipes de Data Science et souhaitent rester agnostiques au niveau du cloud, Databricks conserve l’avantage.

Ce que cela signifie pour la décision en 2026

Le contexte a changé. Ceux qui disaient en 2024 « nous restons sur Databricks car le passage à BigQuery coûterait trop cher » — l’argument des frais de sortie (egress) n’est valable que de manière limitée dès que le Lakehouse intercloud est disponible dans votre propre région. Le déplacement des données cesse d’être le principal poste de coûts.

Ce qui reste, ce sont les vraies questions : quelles charges de travail sont proches de GCP ? où exploitons-nous le Machine Learning en dehors de l’analytics ? quelle est la profondeur de notre intégration SAP ? Ce sont ces réponses qui décident, et non plus le tarif des frais de sortie.

Pour les architectes de la zone DACH, cela signifie qu’il convient de recalibrer les prochains appels d’offres pour les plateformes de données. Non pas parce que BigQuery est automatiquement meilleur désormais, mais parce que Google Cloud Next 2026 a déplacé les bases de la comparaison. Databricks réagira à cela. Comment, le reste de l’année le montrera.

Foire aux questions

Qu’est-ce que Google Agentic Data Cloud et en quoi se distingue-t-elle des offres BigQuery précédentes ?

Agentic Data Cloud est le terme stratégique de Google regroupant AlloyDB, BigQuery, Spanner, Bigtable et Managed Apache Spark. La différence avec les offres BigQuery précédentes réside dans l’objectif : on passe d’une analyse humaine à une consommation de données par les agents IA. Le Universal Context Engine, en tant que nouvelle couche, doit empêcher les hallucinations en permettant aux agents un accès direct et structuré aux données de l’entreprise.

Comment fonctionne techniquement le Cross-Cloud Lakehouse sans frais de sortie (egress) ?

BigQuery accède aux tables Iceberg via Cross-Cloud Interconnect, qui sont physiquement situées sur Amazon S3 ou Azure Data Lake Storage. Cross-Cloud Interconnect est une connexion privée dédiée entre Google et les autres hyperscalers – pas d’internet public, donc pas de coûts de sortie. Les requêtes s’exécutent comme des requêtes BigQuery natives, tandis que les tables résident sur une infrastructure tierce.

Que signifie Catalog Federation pour les installations Databricks existantes ?

Catalog Federation permet des connexions bidirectionnelles entre BigQuery et Databricks Unity Catalog. Les moteurs des deux côtés peuvent lire et écrire directement, sans copies de données ni pipelines ETL. Pour les entreprises disposant d’installations Databricks existantes, cela signifie : BigQuery peut être utilisé pour certaines charges de travail analytiques, sans avoir à toucher à la base de données Databricks.

L’affirmation de Google selon laquelle les migrations ne prennent plus que neuf mois est-elle exacte ?

Google communique neuf mois comme valeur moyenne pour les migrations cloud-to-cloud. Cela concerne la migration pure des données avec les outils de migration de Google et les outils d’évaluation pour les charges de travail Databricks. Le chiffre de neuf mois semble convaincant, mais doit être confronté au profil de complexité propre à chaque entreprise : l’intégration SAP, les pipelines ML existants et les exigences de gouvernance peuvent prendre beaucoup plus de temps.

Pour quelles entreprises DACH un passage à BigQuery Lakehouse a-t-il du sens aujourd’hui ?

Surtout pertinent pour les entreprises déjà fortement impliquées dans l’écosystème GCP et capables de séparer leurs charges de travail analytiques des flux de travail ML basés sur Spark. Les environnements SAP importants bénéficient des connecteurs Cortex. Ceux qui disposent quant à eux d’équipes Data Science avec une expertise Spark approfondie et exploitent des flux de travail Databricks MLflow n’ont aucune raison impérieuse de changer – la fédération permet aujourd’hui la coexistence plutôt qu’un choix exclusif.

Source image titre: Pexels / Noura Zaher (px:33596987)

Photo: Pexels (CC0)