Iceberg a remporté la guerre des formats. Maintenant, c’est le catalogue qui compte

6 min de lecture

Le débat sur le format de table qui sous-tend le data lakehouse ouvert est largement tranché. Apache Iceberg s’est imposé. Snowflake, Databricks et Amazon lancent la version 3, tandis que Delta Lake s’aligne sur le même standard via UniForm. Ainsi, le véritable choix d’architecture se déplace vers un élément que beaucoup d’équipes plateforme sous-estiment encore : le catalogue.

Les points clés en bref

• Le débat sur les formats est presque clos : Iceberg v3 est généralement disponible sur Snowflake, en Public Preview sur Databricks, et les tables Amazon S3 suivent le mouvement. Delta Lake propose désormais ses tables en Iceberg via UniForm. Le principe est simple : écrire une fois, lire depuis plusieurs moteurs.
• Le catalogue devient le nouveau levier de verrouillage : La dépendance passe du format au service qui gère les métadonnées et les droits. Polaris, Unity Catalog et AWS Glue se disputent cette couche stratégique.
• La spécification REST détermine la liberté : Choisir un catalogue qui implémente pleinement l’interface REST d’Iceberg permet de garder les moteurs et les clouds interchangeables. Sans cette vérification, le verrouillage se déplace simplement d’un niveau.

LiéLakehouse multi-cloud et mise en cache des sorties  /  BigQuery défie Databricks avec un pont vers S3

Pourquoi le débat sur les formats est clos

Pendant trois ans, la première question de tout projet de lakehouse était : Iceberg, Delta Lake ou Hudi ? Cette question est désormais largement résolue. Pour les nouveaux lakehouses ouverts, Apache Iceberg s’impose comme la norme. Netflix, Apple, Airbnb et LinkedIn gèrent ainsi des volumes de données atteignant plusieurs pétaoctets. Les grandes plateformes prennent désormais largement en charge ce format, même si cette adoption n’est pas encore exhaustive.

La version 3 fait pencher la balance. Iceberg v3 intègre nativement les Deletion Vectors, la Row Lineage et le type de données Variant. Jusqu’à récemment, ces fonctionnalités donnaient un avantage technique à Delta Lake. L’écart entre les performances de Delta et la compatibilité d’Iceberg se réduit donc considérablement. Snowflake a rendu v3 généralement disponible en mai, Databricks la propose en Public Preview, et les tables Amazon S3 la prennent également en charge. La couverture n’est pas encore totale – AWS Athena, par exemple, ne lit pas encore v3.

Parallèlement, Delta Lake s’aligne plutôt que de se différencier. Grâce à UniForm, une équipe peut exposer ses tables Delta en Iceberg et les rendre lisibles depuis Snowflake, BigQuery, Redshift ou Trino. Les observateurs s’attendent à ce que les prochaines versions des deux projets convergent davantage. Pour les utilisateurs, cela signifie que la base est désormais partagée, et le pari risqué sur un format unique appartient au passé.

Quatre catalogues, quatre profils de verrouillage

Lorsque le format devient interchangeable, c’est le catalogue qui détermine l’accès. Il enregistre quelles tables existent, où se trouvent leurs métadonnées, qui a le droit de les lire et comment les opérations d’écriture sont correctement sérialisées. C’est précisément ici que se situe la nouvelle compétition. Quatre options dominent le marché, chacune avec son propre degré de liberté.

1. Apache Polaris comme référence neutre. Snowflake a ouvert Polaris en 2024 et l’a confié à la fondation Apache, où il continue d’évoluer en tant que projet indépendant des éditeurs. Polaris implémente l’interface REST Iceberg, incluant la gestion des droits et des identifiants pour les moteurs d’accès. Conséquence : le verrouillage structurel le plus faible, mais avec la charge opérationnelle d’un service autogéré ou d’une variante managée.
2. Unity Catalog dans l’écosystème Databricks. Databricks ouvre Unity Catalog aux clients Iceberg et partage désormais ses ressources en temps réel avec Snowflake, Trino, Flink ou Spark, sans copie. Conséquence : une gouvernance et des fonctions de partage puissantes, mais une attraction vers la plateforme Databricks.
3. AWS Glue avec fédération de catalogues. Glue communique par fédération avec Polaris, Unity Catalog et d’autres catalogues conformes à REST. Conséquence : ceux qui sont déjà sur AWS intègrent leurs catalogues existants au lieu de les remplacer. La migration s’effectue alors progressivement.
4. Snowflake Open Catalog comme Polaris managé. Pour les équipes qui ne souhaitent pas gérer Polaris elles-mêmes, Snowflake propose une version hébergée, tout comme Dremio. Conséquence : la neutralité de Polaris sans la charge opérationnelle, au prix d’une relation avec un fournisseur de services.

Le constat est inconfortable, mais clair : un format ouvert ne protège pas automatiquement contre le verrouillage. Le catalogue peut réintroduire la dépendance que le format venait tout juste de supprimer. La question du catalogue doit donc être posée dès le début de l’architecture.

Source : Paysage des catalogues Iceberg REST, situation mi-2026.

Où la migration vraiment bute

Le changement échoue rarement sur le format et presque toujours sur la gouvernance. Un catalogue gère non seulement les noms de tables, mais distribue également les droits d’accès et les informations d’identification temporaires de cloud aux moteurs de requêtes. C’est précisément ce Credential Vending qui doit fonctionner au-delà des frontières du cloud et rester traçable. Polaris a ajouté cela dans la version 1.4 d’avril, avec notamment des étiquettes de session pour l’attribution dans les journaux d’audit AWS et des métriques de catalogue enregistrées.

Le deuxième obstacle est la transition elle-même. Qui aujourd’hui gère des tables dans Glue, dans le Hive Metastore ou dans un format propriétaire, ne veut pas tout changer en une seule migration. La fédération de catalogues est ici le chemin pragmatique. Elle permet d’introduire progressivement un catalogue neutre comme Polaris et de continuer à utiliser les anciens systèmes en parallèle, jusqu’à ce que la transition soit bien établie.

Il reste important de prendre en compte les coûts. Les requêtes multi-cloud ne sont avantageuses que si les mouvements de données et les sorties sont pris en compte. Le catalogue régule l’accès. La question des coûts reste distincte et doit être prise en compte dans la même décision.

Ce que les équipes Cloud doivent décider maintenant

Pour les équipes de plateformes dans la région DACH, cela signifie concrètement : le choix du format ne doit plus déclencher de longue discussion, Iceberg est adopté. L’énergie doit être consacrée à la question du catalogue. Qui veut une indépendance maximale des moteurs et des clouds vérifie si le catalogue satisfait vraiment à la spécification REST. Il évalue ainsi honnêtement les coûts de fonctionnement d’une solution neutre.

Qui est déjà profondément impliqué dans une plateforme peut utiliser son catalogue, mais doit savoir quel engagement cela implique. La fédération reste une option de sortie. La question décisive est aujourd’hui celle du catalogue : qui détient les clés ? Le format est devenu secondaire. L’accès aux données multi-cloud devient une condition préalable pour que les agents IA puissent accéder au même ensemble de données.

Foire aux questions

Qu’est-ce qu’un catalogue Iceberg au juste ?

Le catalogue est le service qui sait quelles tables Iceberg existent, où se trouvent leurs métadonnées actuelles et qui a le droit de les lire ou de les écrire. Il maintient l’accès cohérent de plusieurs moteurs au même ensemble de données. Sans catalogue, une table Iceberg reste un simple assemblage de fichiers sans lien fiable.

Le débat Iceberg contre Delta Lake est-il ainsi clos ?

En grande partie. Delta Lake expose ses tables en Iceberg via UniForm, permettant ainsi aux moteurs Iceberg de les lire. Pour les nouveaux lakehouses ouverts, Iceberg est devenu la norme, le choix du format n’étant plus contraignant.

Pourquoi Apache Polaris est-il considéré comme particulièrement neutre ?

Polaris appartient à la fondation Apache et implémente l’interface REST Iceberg. Il peut être exploité en interne ou obtenu en tant que service managé via Snowflake et Dremio. Ainsi, l’accès reste indépendant d’une plateforme unique.

Dois-je migrer tout d’un coup pour un catalogue neutre ?

Non. La fédération de catalogues permet d’introduire progressivement un catalogue neutre tout en continuant à exploiter parallèlement des systèmes existants comme Glue ou le Hive Metastore. Le risque est ainsi réparti plutôt que concentré dans une migration massive.

Quel est le lien entre la question du catalogue et les agents IA ?

Les agents IA ont besoin d’un accès fiable et régulé aux données, souvent au-delà des frontières cloud. Le catalogue fournit précisément cette couche d’accès gouverné à un seul ensemble physique de données. Sans une stratégie de catalogue solide, l’analyse trans-cloud par des agents IA reste fragmentaire.

Source de l’image de titre : Pexels / panumas nikhomkhai (px:17323801)