Pendant des années, chaque data platform stockait vos données dans son propre format. Changer d’outil voulait dire copier, convertir et resynchroniser. Ce modèle est en train de céder. En effet, Apache Iceberg s’impose comme le format de table commun à Snowflake, Databricks, Microsoft Fabric, BigQuery et Oracle. Début novembre 2026, plusieurs annonces l’ont encore confirmé. Voici ce qu’elles changent concrètement pour vos équipes.
Apache Iceberg : un format de table, pas une base de plus
Apache Iceberg est un format de table ouvert, géré par la fondation Apache. Il décrit comment organiser des fichiers Parquet dans un stockage objet. Surtout, il ajoute des métadonnées qui rendent ces fichiers transactionnels.
Concrètement, chaque écriture crée un nouvel instantané de la table. Les lecteurs voient donc toujours un état cohérent. De plus, le format gère l’évolution de schéma, le partitionnement caché et le retour dans le temps.
Le point clé reste le catalogue. Il indique quel fichier de métadonnées est la version courante d’une table. Pour cela, la spécification Iceberg définit une API standard, l’Iceberg REST Catalog. C’est elle qui permet à plusieurs moteurs de partager les mêmes tables.
Pour un DBA, ces notions sont familières. On retrouve des transactions, des journaux et des conflits de concurrence. Seule l’architecture change : le stockage et le calcul sont séparés.
Ce que les éditeurs ont annoncé début novembre
Côté Microsoft, OneLake accepte désormais les écritures Iceberg via l’API REST Catalog. Jusqu’ici, ce point d’accès était limité à la lecture. Désormais, PyIceberg, DuckDB ou Snowflake peuvent créer des tables natives et valider des instantanés dans Fabric. En parallèle, OneLake devient un stockage natif pour Unity Catalog d’Azure Databricks, en disponibilité générale depuis le 5 novembre.
Snowflake avance aussi sur plusieurs fronts. Le 2 novembre, Open Data Sharing est passé en disponibilité générale. Il permet de partager des tables Iceberg avec des consommateurs hors Snowflake, sans copie. Ensuite, le 4 novembre, les sauvegardes de tables Iceberg sont arrivées en GA sur AWS. Enfin, l’accès en lecture et écriture entre comptes via Horizon Catalog ne demande plus de gérer des secrets.
Google suit le même chemin. Le 2 novembre, son Lakehouse a rendu disponible la fédération de catalogues distants. BigQuery peut ainsi interroger des tables Iceberg gérées par Unity Catalog, AWS Glue ou Horizon Catalog. Aucune migration de données n’est nécessaire.
Databricks, de son côté, avait déjà passé ses tables Iceberg managées et Iceberg v3 en GA en mai 2026. Et Oracle a annoncé fin octobre un support élargi d’Iceberg dans son Autonomous AI Lakehouse.
Apache Iceberg déplace la bataille vers le catalogue
Si tout le monde lit le même format, où se joue la différence ? Désormais, elle se joue dans le catalogue et la gouvernance. Chaque éditeur veut devenir le point central qui référence vos tables.
Unity Catalog, Horizon Catalog, OneLake et le Lakehouse de Google exposent tous l’API REST Catalog. Pourtant, ils ne gèrent pas tous les droits, la traçabilité ou l’optimisation de la même façon. Par conséquent, le choix du catalogue principal devient une décision d’architecture majeure.
C’est aussi une question de dépendance. Un format ouvert ne suffit pas si les règles d’accès restent enfermées dans un seul outil. Il faut donc vérifier qui gère les permissions quand un moteur tiers lit vos tables.
Les points de vigilance pour vos équipes
D’abord, la concurrence d’écriture. Avec plusieurs moteurs, deux validations peuvent entrer en conflit. Microsoft précise d’ailleurs que les écritures OneLake reposent sur une concurrence optimiste. Une validation en conflit échoue au lieu d’écraser une version plus récente. Vos pipelines doivent donc savoir relire l’état puis réessayer.
Ensuite, la maintenance. Une table Apache Iceberg accumule des instantanés et des petits fichiers. Sans compactage ni expiration des instantanés, les performances se dégradent et le stockage gonfle. Certaines plateformes automatisent ce travail, d’autres non.
Puis, la sauvegarde. Un format ouvert n’est pas une stratégie de reprise. L’arrivée des sauvegardes Iceberg chez Snowflake le rappelle bien. Il faut définir les objectifs de reprise de chaque table, comme pour une base de production.
Enfin, les coûts. Lire des données hébergées dans un autre cloud génère des frais de sortie. Google propose d’ailleurs un cache pour limiter ces frais de requêtes inter-cloud. Il faut donc mesurer ces flux avant de multiplier les moteurs.
Comment démarrer avec Apache Iceberg
Inutile de tout migrer d’un coup. Commencez plutôt par un cas d’usage limité, par exemple un jeu de données partagé entre deux équipes. Ensuite, choisissez le catalogue qui fera référence et documentez ce choix.
Testez aussi les écritures concurrentes et la maintenance de vos tables Apache Iceberg sur un volume réaliste. Ces essais révèlent vite les vraies limites de chaque moteur. De même, vérifiez que les droits restent appliqués quand un outil tiers accède aux tables.
Si vous préparez une migration, ce sujet doit entrer dans le cadrage. Notre article sur la migration data platform détaille les pièges classiques. Et pour donner du sens à ces tables, la couche sémantique reste le complément naturel.
Conclusion : un format ouvert, des choix à faire
Apache Iceberg tient sa promesse : vos données ne sont plus prisonnières d’un seul moteur. Toutefois, l’ouverture du format ne règle ni la gouvernance, ni l’exploitation, ni les coûts. Ces sujets relèvent du savoir-faire des équipes bases de données.
Chez Axians, nous accompagnons nos clients sur ces architectures ouvertes. Nous intervenons sur le conseil et le choix du catalogue. Nous prenons aussi en charge le build, la migration et le service managé. Nous formons aussi vos équipes à l’exploitation des tables Iceberg sur Snowflake, Microsoft Fabric ou ClickHouse. L’objectif reste simple : profiter de l’ouverture sans perdre la maîtrise.