D’Iceberg à l’intelligence : le lakehouse sans frontières, prêt pour l’IA, avec Snowflake et Google Cloud

Iceberg : du silo à l’interopérabilité

Avant, chaque base de données possédait ses propres données, un modèle efficace lorsque les organisations ne disposaient que d’un seul moteur d’analyse. Aujourd’hui, les équipes data combinent souvent Apache Spark™, BigQuery, Gemini Enterprise Agent Platform, Snowflake (y compris Snowflake CoCo et Snowflake CoWork) et d’autres services selon le cas d’usage, parfois au sein du même pipeline.

Cela imposait le choix binaire de privilégier la flexibilité ou l’homogénéité :

• laisser chaque équipe utiliser son moteur préféré et répliquer les données d’un système à l’autre, au prix de redondances, d’incohérences et de risques.
• ou imposer un moteur unique à tout le monde et renoncer à la spécialisation et à l’autonomie qu’offrent les architectures multi‑moteurs.

Le secteur avait besoin d’une troisième voie, née d’un insight fondamental connu sous le nom de principe de localité des données. Il est en effet plus rapide, moins coûteux et plus sécurisé de déplacer un petit morceau de code exécutable vers l’emplacement où résident déjà les données que de déplacer d’énormes volumes de données sur un réseau.

Cette idée permettait de converger vers un modèle unique : rapprocher le calcul de chaque moteur des données, plutôt que copier les données vers chaque moteur. Toutes les données résident dans le bucket de stockage du client, et tous les moteurs s’accordent sur leur organisation physique afin que chacun puisse lire et écrire directement dans la même table.

Cela suppose un format de table ouvert et partagé, un langage commun que tous les moteurs comprennent.

Le secteur a adopté Apache Iceberg™ comme format de référence. Développé chez Netflix pour gérer des tables à l’échelle du pétaoctet, puis donné à l’Apache Software Foundation, Iceberg est pris en charge par Spark, Trino, Flink, BigQuery, Snowflake et des dizaines d’autres moteurs. Avec Iceberg comme langage commun, chaque moteur participe sans adaptateur propriétaire.

Le catalogue : d’Iceberg au lakehouse

Un format ouvert résout en grande partie la problématique de l’interopérabilité, mais soulève une nouvelle question : qui en a la responsabilité ? Lorsque plusieurs moteurs peuvent lire et écrire dans les mêmes fichiers, quelqu’un doit gérer les métadonnées des tables, appliquer les politiques d’accès, coordonner les écritures concurrentes et garantir qu’aucun moteur ne consulte un état obsolète ou incohérent. Ce rôle revient au catalogue, qui sert de couche de gouvernance du lakehouse. Il constitue l’autorité unique qui sait quelles tables existent, à quoi ressemblent leurs schémas, qui peut y accéder et où résident physiquement les fichiers de données. Sans catalogue, des données ouvertes restent des données sans gouvernance.

Le catalogue contrôle également l’accès au stockage au moyen d’identifiants délégués. Lorsqu’un moteur demande les données d’une table, le catalogue renvoie des tokens de stockage à durée limitée et au périmètre restreint, plutôt que des identifiants permanents du bucket. Ainsi, les moteurs n’obtiennent pas d’accès persistant à la couche de stockage sous-jacente.

Pour que ce modèle fonctionne avec des moteurs conçus par différents prestataires, les catalogues ont besoin d’un protocole d’intégration standardisé. Sans cela, chaque moteur nécessiterait une intégration personnalisée avec chaque catalogue. Le Iceberg REST Catalog (IRC) est la spécification d’API ouverte qui répond à ce besoin : elle définit comment les clients découvrent les espaces de noms, chargent les métadonnées de table et valident les mises à jour. Chaque catalogue expose un endpoint IRC, et chaque moteur s’y connecte comme client.

Cette combinaison d’identifiants délégués et d’un protocole standard permet concrètement aux moteurs de franchir les frontières entre catalogues, ce que le secteur appelle la fédération. Lorsqu’une requête Snowflake interroge le catalogue Lakehouse de Google Cloud, ou qu’un job BigQuery lit des données depuis Snowflake Horizon, chaque catalogue n’émet que les jetons restreints et limités dans le temps dont le moteur demandeur a réellement besoin. La gouvernance s’applique donc quel que soit le moteur à l’origine de la demande. La véritable interopérabilité doit fonctionner dans les deux sens : la fédération entrante, où des moteurs externes à votre catalogue peuvent lire et écrire vos Iceberg Tables, et la fédération sortante, où votre calcul peut lire et écrire des Iceberg Tables gérées par un autre catalogue.

Ensemble, le catalogue et les identifiants délégués fournissent une couche de gouvernance à autorité unique qui applique la sécurité, contrôle les accès et centralise les audits. Les clients peuvent désormais bénéficier d’un accès bidirectionnel aux Iceberg Tables entre catalogues, ce qui permet une architecture zéro copie avec les moteurs compatibles Iceberg.

La question architecturale clé devient : qui gère le catalogue ? Les clients peuvent déployer un catalogue autogéré en mode DIY ou, plus probablement, utiliser un Iceberg REST Catalog managé.

Pour les entreprises qui veulent gérer elles-mêmes leur catalogue, il est possible de déployer Apache Polaris™, une implémentation IRC open source populaire, co-créée à l’origine par Snowflake et Dremio, puis donnée à l’Apache Software Foundation. Cela donne à ces organisations un contrôle total, mais transfère aussi toute la responsabilité opérationnelle, y compris l’infrastructure, la mise à l’échelle, les correctifs et la disponibilité, à l’équipe du client. Contrairement aux solutions gérées, les catalogues autogérés ne sont pas serverless et ne se mettent pas automatiquement à l'arrêt lorsqu'ils ne sont pas utilisés, ce qui génère des coûts d'exploitation permanents.

Dans la pratique, la plupart des organisations choisissent un IRC managé afin de se concentrer sur les données, et non sur l’exploitation du catalogue. Lorsque Snowflake et Google Cloud entrent tous deux en jeu, chacun trouve naturellement sa place :

• Lakehouse runtime catalog (le catalogue Iceberg managé de Google Cloud, qui fait partie de Lakehouse for Apache Iceberg) est un métastore serverless et évolutif qui sert de source unique de vérité pour votre data lakehouse. Il permet à plusieurs moteurs (BigQuery, Spark géré par Google, Apache Spark, Trino, Snowflake) d’accéder à la même copie des données dans des formats ouverts comme Apache Iceberg. La fédération permet aux agents et aux moteurs d'exécution de Google Cloud d'accéder aux données, au-delà des frontières entre catalogues, qu'elles soient gérées dans Snowflake, Databricks ou AWS Glue.
• Snowflake Horizon Catalog intègre Apache Polaris et embarque des points de terminaison IRC conformes aux standards dans chaque compte Snowflake, sans configuration supplémentaire. Au-delà des opérations de catalogue de base, Horizon ajoute une couche de gouvernance d’entreprise : RBAC, masquage au niveau des colonnes, Row Access Policies, traçabilité des données et journalisation des événements d’audit. Il permet aux moteurs compatibles Iceberg comme Trino, BigQuery, Apache Flink et bien d’autres de lire et d’écrire directement dans des Iceberg Tables gérées par Snowflake.

Fédération : du lakehouse à l’open lakehouse

Lakehouse runtime catalog, Snowflake Horizon Catalog et les autres options de catalogue managé ne s’excluent pas mutuellement. Ils peuvent coexister dans la même organisation grâce à la fédération de catalogues, ce qui permet aux organisations de commencer avec un seul catalogue, puis de fédérer progressivement à mesure que les besoins évoluent.

Chaque catalogue gère ses propres tables, tandis que tous les moteurs y accèdent via IRC.

Lorsque Google Cloud gère le catalogue via le catalogue d'exécution Lakehouse, Snowflake se connecte via une base de données liée au catalogue (Catalog-Linked Database, CLD) qui découvre et synchronise automatiquement les tables à partir de ses points de terminaison IRC. Les utilisateurs Snowflake interagissent avec ces Iceberg Tables du Lakehouse Google Cloud en SQL standard, avec SELECT, INSERT, UPDATE, DELETE, ou via Snowflake CoCo ou Snowflake CoWork, comme s’il s’agissait de tables natives, avec la gouvernance Snowflake (RBAC, masquage, traçabilité) appliquée par-dessus.

De même, lorsque Snowflake gère le catalogue via Horizon, les services Google Cloud accèdent à ces tables grâce à la fédération de catalogues Lakehouse : BigQuery, Managed Service for Apache Spark et d’autres moteurs compatibles Iceberg dans Google Cloud se connectent au point de terminaison IRC d’Horizon et lisent/écrivent directement dans les Iceberg Tables gérées par Snowflake.

Le résultat ? Une plateforme de données totalement ouverte et interopérable. Tous les moteurs accèdent directement au bucket Cloud Storage du client, en lecture comme en écriture, sans recourir à des traitements ETL entre les systèmes. Chaque équipe peut ainsi utiliser l'outil qui répond le mieux à ses besoins. Pendant ce temps, la couche de catalogue applique une gouvernance unifiée à l’ensemble.

Contexte sémantique : de l’open lakehouse au lakehouse prêt pour l’IA

Un lakehouse bien architecturé résout en grande partie l’interopérabilité des données, mais l’interopérabilité seule ne rend pas les données utiles à l’IA. Entre « les données sont accessibles » et « l’IA produit des réponses et des actions exactes et fiables », trois problèmes restent à résoudre :

• Accès programmatique
• Ancrage sémantique
• Intelligence contextuelle

Accès programmatique
Les analystes interrogent les tables à l'aide du moteur de leur choix. Les agents IA, eux, ont besoin de leurs propres interfaces d'accès. Snowflake met à disposition des serveurs Model Context Protocol (MCP), qui permettent à tout client compatible MCP de découvrir les données du lakehouse, de les interroger et de raisonner à partir de celles-ci. MCP est un standard ouvert qui fournit une interface universelle entre les applications d’IA et les sources de données. Ainsi, Gemini Enterprise, les assistants de code et les frameworks d’agents personnalisés se connectent tous via le même protocole, sans nécessiter d’intégrations sur mesure. De même, BigQuery propose aussi un serveur MCP accessible aux agents d’IA internes ou non, ce qui ouvre un accès programmatique aux assets de lakehouse pour les workflows agentiques dans Google Cloud et les environnements multi-cloud.

Pour les applications qui nécessitent un contrôle programmatique direct, comme les frameworks d’orchestration, les pipelines personnalisés ou l’analytique embarquée, Cortex Agents et les agents Gemini Enterprise sont également accessibles via une API REST. Ensemble, MCP et REST donnent aux agents d’IA le même accès gouverné et authentifié aux Iceberg Tables que celui dont disposent les analystes humains, quel que soit le catalogue qui les gère.

Ancrage sémantique
Les systèmes d’IA hallucinent lorsqu’ils ne comprennent pas ce que représentent les données. Les modèles sémantiques comblent cette lacune en appliquant une couche de logique métier aux tables physiques : des métriques assorties de leurs règles de calcul, des dimensions organisées en hiérarchies, des relations entre les entités et des modèles de requêtes validés qui formalisent les connaissances métier de l'entreprise. L’information stratégique à retenir, c’est que la logique business doit résider dans la couche de données, pas dans les prompts d’IA. Lorsque les définitions résident dans un modèle sémantique au-dessus des données, chaque système d’IA hérite de la même logique correcte, ce qui réduit la dérive, les incohérences et les approximations.

Semantic View Autopilot, qui fait partie d’Horizon Context, permet de faire évoluer cette approche durablement à grande échelle. Plutôt que d’obliger les analystes à définir manuellement des centaines de modèles sémantiques, Autopilot les découvre et les maintient automatiquement en apprenant des schémas de requête, du comportement des utilisateurs, des relations entre tables, des intégrations d’outils de BI et de l’usage des rapports. Pour les équipes qui préfèrent créer et affiner des modèles en langage naturel, l’assistant CoCo intégré à Semantic Studio (en private preview) fonctionne aux côtés d’un éditeur visuel et YAML avec intégration Git. Les définitions sémantiques peuvent ainsi être versionnées et revues comme n’importe quel autre asset de code. À mesure que les données évoluent, les modèles sémantiques restent à jour afin que la précision de l’IA ne se dégrade pas avec le temps. Résultat : moins d’hallucination, plus de précision et une logique business ancrée dans les données réelles. De même, il est possible de s’appuyer sur l’Universal Semantic Layer de Google Cloud, grâce à la nouvelle prise en charge, par Looker, des modèles analytiques exécutés directement dans la base de données (in-database analytics models). Ceux-ci intègrent notamment BigQuery Graph et les Snowflake Semantic Views, afin de mettre la puissance des modèles Graph au service des utilisateurs métier dans leurs principaux parcours agentiques.

Intelligence contextuelle
Le contexte, c’est l’ensemble des connaissances qui indique à un système d’IA non seulement ce que sont les données, mais aussi comment les interpréter correctement. Snowflake Horizon Context crée et applique cette couche contextuelle : descriptions de tables et de colonnes en termes business, signaux de qualité des données (actualisation, exhaustivité, réserves), modèles d’utilisation (quelles tables font autorité pour quelles questions) et relations de domaine dans tout le lakehouse. Comme ce contexte réside dans Horizon, il hérite de la même gouvernance que les données elles-mêmes. Les agents et les utilisateurs ne reçoivent donc que le contexte et les réponses qu’ils sont autorisés à consulter. De même, Google Cloud Lakehouse fournit un contexte fiable via Knowledge Catalog, avec des insights optimisés par Gemini pour les tables lakehouse qui contribuent à atténuer les hallucinations des agents d’IA et permettent aux utilisateurs de passer des insights à l’action. Ce contexte s’applique à chaque table Iceberg, qu’elle soit native de Snowflake, liée via CLD ou fédérée depuis Google Cloud. L’IA reçoit les données avec le contexte nécessaire pour les interpréter correctement. C’est ce qui distingue une réponse générique de LLM (« le chiffre d’affaires pourrait être... ») d’une réponse ancrée (« le chiffre d’affaires du T4 était de 47,2 M USD d’après la table de référence finance.revenue, filtrée selon la définition du trimestre fiscal »).

IA agentique : de la data à l’action

Une fois le contexte d’entreprise et les vues sémantiques en place, les agents d’IA travaillent sur des données structurées et non structurées avec un haut niveau de précision. Snowflake CoWork est un agent de travail personnel pour tous les collaborateurs du savoir, capable de raisonner en profondeur, d’automatiser les tâches de routine et d’accélérer le passage des idées aux décisions, puis à l’action. Au lieu d’attendre des instructions, CoWork agit de manière proactive : il fait émerger des insights, exécute des analyses en arrière-plan et fournit des réponses gouvernées, traçables, ancrées dans les définitions business réelles de vos données.

Snowflake CoCo prolonge cette logique dans le workflow de développement, en tant qu’agent de code data-native sur l’ensemble des travaux liés au cycle de vie des données d’entreprise : créer et maintenir des pipelines, créer des Cortex Agents et des applications Streamlit, et générer du code SQL et Python validé, ancrés dans les métadonnées réelles du catalogue. Les collaborateurs du savoir comme les data engineers bénéficient du même ancrage sémantique et opèrent avec la gouvernance et l’observabilité nécessaires sur les actions humaines comme sur celles des agents.

Cette même fondation fédérée rend également les capacités d’IA de Google Cloud disponibles nativement. Comme le lakehouse s’exécute sur Google Cloud, Gemini est disponible nativement sur l’ensemble du stack. La compréhension multimodale de Gemini (texte, images, vidéo et code dans un même contexte) signifie que les données du lakehouse ne se limitent pas aux tables structurées : les documents dans GCS, les images et les contenus non structurés participent tous au workflow d’IA. Ses longues fenêtres de contexte ingèrent simultanément de vastes schémas, des définitions de modèles sémantiques et des historiques de requêtes, ce qui améliore la précision sur les questions analytiques complexes.

Gemini Enterprise se connecte au lakehouse via MCP (par l’intermédiaire des serveurs MCP de Snowflake ou du serveur MCP BigQuery) avec Lakehouse for Apache Iceberg. Avec Gemini Enterprise, les collaborateurs interrogent les données en langage naturel. Les réponses s'appuient sur les données gouvernées des tables Iceberg, tandis que les requêtes sont acheminées via les Cortex Agents et les modèles sémantiques afin d'en garantir la fiabilité. Qu’un utilisateur interagisse via CoWork, Cortex Code, Gemini Enterprise ou un agent REST personnalisé, la même couche sémantique, le même contexte et la même gouvernance s’appliquent.

Le résultat n’est pas seulement un open lakehouse : c’est un open lakehouse prêt pour l’IA, où les données sont interopérables, gouvernées, riches sémantiquement et accessibles aux humains comme aux agents d’IA via des protocoles standardisés.

Pour aller plus loin

• Découvrez les dernières améliorations produit pour créer un lakehouse interopérable dans Snowflake
• Lakehouse cross-cloud avec Snowflake et Google Cloud
• Découvrez d’autres ressources Snowflake sur Google Cloud

À noter : Apache Iceberg, Apache Polaris et Apache Spark sont des marques commerciales de l’Apache Software Foundation.