Google ouvre son lakehouse aux données AWS et Azure pour alimenter les agents IA

Google Cloud présente un borderless Lakehouse destiné à interroger et gouverner des données réparties entre Google Cloud, Amazon Web Services, Microsoft Azure, Databricks, Snowflake et des systèmes sur site. Le constructeur s’appuie sur BigQuery, le format ouvert Apache Iceberg et Knowledge Catalog pour fournir aux agents IA un contexte commun sans imposer la copie immédiate de toutes les données vers un entrepôt unique.

La promesse répond à un problème réel : un agent peut accéder à un modèle puissant tout en prenant de mauvaises décisions parce que les ventes, stocks, contrats et journaux techniques vivent dans des silos différents. Mais « sans frontière » ne signifie ni sans transfert, ni sans coût, ni sans dépendance à Google. L’architecture doit être évaluée requête par requête.

La réponse rapide

Le problème n’est plus seulement de stocker, mais de donner du contexte

Une entreprise peut conserver les transactions dans BigQuery, les fichiers historiques dans Amazon S3, une base opérationnelle sur Azure et les notebooks d’analyse dans Databricks. Un tableau de bord accepte parfois ces séparations. Un agent autonome, lui, doit découvrir la bonne donnée, comprendre sa fraîcheur, obtenir l’autorisation et agir avant que le contexte ne change.

Copier toutes les sources vers un dépôt central simplifie certaines analyses, mais crée du délai, des duplications et des responsabilités supplémentaires. Interroger chaque système à distance évite la migration, au prix d’une latence et d’une disponibilité moins prévisibles. Le borderless Lakehouse cherche à offrir les deux modes plutôt qu’une réponse unique.

Cette distinction est importante. Une requête ponctuelle sur un petit jeu de données peut rester distante. Un calcul répété pour des milliers d’agents devra probablement être mis en cache, matérialisé ou rapproché du moteur de calcul. L’emplacement logique paraît unifié ; les octets, eux, restent soumis au réseau et aux factures de sortie.

Apache Iceberg fournit le contrat de table ouvert

Iceberg décrit les schémas, partitions, instantanés et fichiers qui composent une table analytique. Plusieurs moteurs peuvent ainsi travailler sur des données Parquet sans dépendre d’un format propriétaire différent pour chacun. Google présente ses tables Iceberg gérées comme une base de lakehouse ouverte, stockée dans des buckets contrôlés par le client.

L’ouverture a cependant des règles. La documentation de BigQuery avertit qu’une modification directe de fichiers suivis par une table Iceberg gérée peut rendre la table incohérente. Des préfixes de stockage qui se chevauchent peuvent même conduire le nettoyage automatique à supprimer des fichiers considérés comme étrangers. « Format ouvert » ne veut donc pas dire que tous les moteurs peuvent écrire simultanément sans coordination.

Une organisation doit désigner le propriétaire des écritures, gérer les catalogues et tester les opérations de maintenance. L’interopérabilité est réelle pour la lecture et certains workflows, mais elle ne supprime pas les verrous opérationnels d’un service géré.

BigQuery Omni rapproche le calcul des données

BigQuery Omni permet d’exécuter des analyses BigQuery sur des données situées dans Amazon S3 ou Azure Blob Storage via des tables BigLake. Google documente plusieurs stratégies : jointure à distance, vue matérialisée, transfert par requête ou chargement complet. Chacune échange fraîcheur, coût et performance.

Une jointure distante convient à une exploration occasionnelle et à un volume raisonnable. Une vue matérialisée devient plus cohérente pour un tableau de bord ou un agent qui pose sans cesse la même famille de questions. Un transfert est préférable lorsque les transformations sont complexes ou lorsque le volume rend les allers-retours trop chers.

Le terme « requêter sur place » doit donc être mesuré. Il faut observer les octets lus, les données traversant les régions, les temps de démarrage et les limites des opérateurs SQL. Un prototype sur quelques gigaoctets ne prédit pas le coût d’une flotte d’agents interrogeant des téraoctets en continu.

Knowledge Catalog devient la carte utilisée par les agents

Google a renommé Dataplex Universal Catalog en Knowledge Catalog et le présente comme un catalogue alimenté par Gemini. Il indexe des métadonnées techniques et métier, recherche des actifs en langage naturel et construit un contexte destiné aux analystes comme aux agents.

Cette couche est aussi critique que le moteur de requête. Deux colonnes appelées revenue peuvent représenter un montant brut dans un système et un revenu reconnu dans un autre. Sans définition, propriétaire, fréquence de mise à jour et indicateur de qualité, un agent peut joindre des données techniquement compatibles mais sémantiquement fausses.

L’automatisation de la description aide à démarrer ; elle ne doit pas inventer la gouvernance. Les équipes métier doivent valider les termes importants, les classifications sensibles et les règles de rétention. Un graphe de contexte erroné peut propager une même erreur dans toutes les réponses avec une apparence de cohérence.

Les permissions doivent survivre à l’unification

Une interface unique ne doit pas aplatir les droits. Un agent chargé des stocks n’a pas besoin des salaires, même si les deux jeux de données apparaissent dans le même catalogue. Les identités de service, politiques de colonnes, masquage et journaux doivent être appliqués au moment de chaque accès.

La difficulté augmente lorsqu’une politique Google doit coexister avec IAM sur AWS, les rôles Azure et les autorisations d’une plateforme tierce. Le plus petit dénominateur commun peut être trop permissif ; une traduction stricte peut bloquer les usages légitimes. Des tests d’autorisation automatisés sont nécessaires, avec des scénarios positifs et négatifs.

Les agents ajoutent un autre risque : ils génèrent des requêtes et choisissent des outils de manière dynamique. Un prompt hostile caché dans un document ne doit pas suffire à étendre leur accès. Les permissions doivent être imposées hors du modèle, avec des budgets, des listes de sources et des approbations pour les actions sensibles.

Une architecture multicloud reste une architecture distribuée

La disponibilité d’un résultat dépend du catalogue, du moteur, du connecteur, du cloud distant et du réseau. Un incident dans une seule couche peut rendre un agent partiellement aveugle. Les réponses doivent donc indiquer la fraîcheur des sources et être capables de s’arrêter lorsqu’une donnée obligatoire manque.

Il faut également prévoir l’observabilité : requête générée, tables consultées, version du schéma, volume lu, politique appliquée, résultat intermédiaire et décision finale. Sans cette trace, une entreprise ne peut pas expliquer pourquoi un agent a recommandé un réapprovisionnement ou bloqué une transaction.

Les objectifs de reprise doivent distinguer le catalogue et les données. Restaurer des fichiers sans leurs métadonnées ne reconstitue pas forcément une table exploitable. À l’inverse, un catalogue sauvegardé pointant vers des données supprimées donne une carte précise d’un territoire qui n’existe plus.

Comment évaluer le borderless Lakehouse

Un pilote devrait partir d’un seul processus, par exemple rapprocher les stocks AWS et les commandes BigQuery pour proposer un réapprovisionnement. Il faut mesurer la précision, la fraîcheur, le coût par décision, la latence et le comportement lorsque l’une des sources devient indisponible.

L’entreprise peut ensuite comparer trois architectures : requête distante, réplication ciblée et centralisation complète. Le meilleur choix sera souvent hybride. Les données volumineuses et stables restent proches de leur stockage ; les agrégats fréquemment utilisés se rapprochent du calcul ; les informations sensibles conservent leurs contrôles locaux.

Le borderless Lakehouse est donc moins la disparition des frontières qu’une couche de traduction et de gouvernance au-dessus d’elles. Son intérêt dépendra de la qualité du catalogue, de la maîtrise des écritures Iceberg et de la transparence des coûts multicloud. Pour les agents IA, une donnée accessible n’est utile que si elle est aussi comprise, autorisée, fraîche et traçable.