Pendant longtemps, les équipes data ont dû choisir entre deux architectures imparfaites. Le data warehouse offrait de la performance et de la fiabilité, mais à un coût élevé et avec peu de flexibilité sur les formats. Le data lake promettait l'inverse : stocker tout, interroger après, payer moins. En pratique, ça donnait souvent des marais de données ingérables, sans gouvernance sérieuse, où retrouver une donnée fiable relevait de l'archéologie.

Le data lakehouse est né de cette frustration. L'idée est simple : prendre la flexibilité et le coût du lac, y ajouter les garanties transactionnelles et les performances du warehouse. Et pour tenir cette promesse, tout repose sur le format de table ouvert choisi. En 2026, trois formats se partagent l'essentiel du marché : Apache Iceberg, Delta Lake et Apache Hudi.

Lequel choisir ? La réponse honnête, c'est que ça dépend. Mais "ça dépend" mérite d'être expliqué sérieusement.

Ce que ces formats apportent concrètement

Avant de comparer, il faut comprendre ce que ces formats résolvent. Un fichier Parquet brut dans un bucket S3, c'est performant à lire, mais c'est statique. Vous ne pouvez pas mettre à jour une ligne, annuler une écriture en cours, lire une version antérieure ou garantir qu'un lecteur et un écrivain ne se marcheront pas dessus.

Les trois formats Iceberg, Delta Lake, Hudi apportent une couche de métadonnées au-dessus des fichiers Parquet (ou ORC) qui rend tout ça possible. Ils implémentent les propriétés ACID, gèrent un historique des versions, permettent le time travel et exposent un schéma évolutif. C'est ce socle commun qui rend le lakehouse viable.

Les différences sont dans les détails d'implémentation, les compromis de performance, l'écosystème et la gouvernance du projet.

Apache Iceberg

Iceberg est aujourd'hui le format qui a le vent en poupe. Né chez Netflix, il a été conçu dès le départ pour fonctionner à très grande échelle, avec des tables de plusieurs pétaoctets et des millions de fichiers. Sa gestion des métadonnées est particulièrement soignée : au lieu d'un répertoire de fichiers, Iceberg maintient une arborescence de snapshots immuables qui rend les lectures et les planifications de requêtes très efficaces.

Ce qui le distingue surtout, c'est sa neutralité. Iceberg est un standard Apache, sans propriétaire dominant. Snowflake, Databricks, AWS, Google Cloud, Dremio, Trino, Flink, Spark, tout le monde le supporte. En 2026, c'est le format qui s'est imposé comme lingua franca de l'interopérabilité dans les architectures data modernes.

L'adoption d'Iceberg a aussi été accélérée par l'émergence du concept de catalogue ouvert. Avec des projets comme Unity Catalog ou Polaris, le fait qu'Iceberg soit nativement interopérable entre moteurs devient un avantage structurel. Vous n'êtes pas enfermé dans un runtime particulier.

Son point faible historique était la gestion des mises à jour en streaming. C'est en train de se combler, mais sur des cas d'usage très orientés ingestion temps réel avec des upserts fréquents, il faut vérifier que votre version et votre moteur sont bien à jour.

Delta Lake

Delta Lake est né chez Databricks, et ça se voit dans son positionnement. Il a été conçu pour fonctionner parfaitement dans l'écosystème Spark, et c'est toujours là qu'il excelle. Si votre stack tourne principalement sur Databricks ou sur Spark managé, Delta Lake offre une expérience très fluide, avec des optimisations spécifiques comme le Z-ordering, l'Auto Optimize ou le liquid clustering apparu dans les versions récentes.

Databricks a ouvert le format sous Apache en 2019, mais le rythme d'innovation reste très lié à la roadmap de l'entreprise. C'est une force, les fonctionnalités avancées arrivent vite et sont bien intégrées mais aussi une dépendance à assumer. En dehors de l'écosystème Databricks, le support est moins universel qu'Iceberg, même si la situation s'est améliorée.

Delta Lake est aussi réputé pour sa robustesse sur les charges mixtes lecture/écriture intensive, notamment grâce à sa gestion du transaction log. Pour des équipes qui font du machine learning à grande échelle sur Databricks, c'est souvent le choix naturel et le moins risqué opérationnellement.

Apache Hudi

Hudi a une histoire différente. Développé initialement chez Uber pour gérer des volumes massifs de données avec des mises à jour très fréquentes, il a été pensé pour un problème précis : comment mettre à jour efficacement des enregistrements individuels dans un lac de données, sans réécrire des partitions entières ?

C'est là sa vraie force. Hudi excelle sur les cas d'usage où vous avez des flux d'événements continus avec des corrections, des late arrivals ou des suppressions fréquentes, typiquement des pipelines CDC (Change Data Capture) depuis des bases transactionnelles. Il propose deux types de tables, Copy-on-Write et Merge-on-Read, qui permettent d'ajuster le compromis entre performance en lecture et coût en écriture selon le cas d'usage.

En revanche, Hudi est le format le plus complexe à opérer des trois. Sa courbe d'apprentissage est plus raide, sa documentation suppose souvent une familiarité avec les internals, et son écosystème de partenaires est plus restreint. C'est un outil puissant, mais qui demande une équipe qui a envie de s'y investir sérieusement.

Comment choisir

Plutôt qu'une matrice de fonctionnalités, voici quelques questions qui orientent le choix dans la vraie vie.

Votre stack est-elle centrée sur Databricks ? Si oui, Delta Lake est le chemin de moindre résistance. L'intégration est native, le support est excellent, et vous bénéficierez des optimisations spécifiques sans effort particulier.

Avez-vous besoin d'interopérabilité entre plusieurs moteurs ? Si vous utilisez à la fois Spark, Flink, Trino et potentiellement des services cloud natifs comme Athena ou BigQuery Omni, Iceberg est aujourd'hui le choix le plus sage. C'est le format sur lequel l'industrie converge pour l'interopérabilité.

Vos pipelines sont-ils dominés par des mises à jour fréquentes sur des enregistrements individuels ? Si vous faites du CDC intensif depuis des bases transactionnelles avec des volumes élevés et des contraintes de latence, Hudi mérite sérieusement d'être évalué. Mais soyez honnêtes sur votre capacité à absorber la complexité opérationnelle.

Vous démarrez from scratch sans contrainte existante ? En 2026, Iceberg est probablement le pari le plus sûr sur le long terme. La neutralité du standard, la largeur de l'écosystème et la dynamique communautaire en font le choix par défaut pour de nouveaux projets sans contexte particulier.

Ce qui se passe dans l'industrie

La convergence est en marche. Databricks a annoncé un support Iceberg de plus en plus poussé dans ses dernières versions. AWS a investi massivement dans Iceberg avec S3 Tables. Google Cloud et Azure suivent le mouvement. Le scénario probable à moyen terme n'est pas la victoire d'un format sur les autres, mais une couche d'abstraction suffisamment solide pour qu'un catalogue comme Unity Catalog ou Apache Polaris expose les données quel que soit le format sous-jacent.

Ça ne rend pas le choix d'aujourd'hui sans importance vous vivrez avec pendant plusieurs années mais ça signifie aussi qu'une migration future sera probablement moins douloureuse qu'elle ne l'aurait été il y a trois ans.

En résumé

Il n'y a pas de mauvais choix parmi ces trois formats si vous choisissez pour les bonnes raisons. Ce qui serait une erreur, c'est de choisir par défaut sans avoir posé les bonnes questions : quel moteur d'exécution, quelle fréquence de mise à jour, quel niveau d'interopérabilité requis, quelle capacité opérationnelle de l'équipe.

Le data lakehouse tient ses promesses en 2026. La maturité des formats, la qualité des catalogues et la solidité des moteurs de requête ont rattrapé l'ambition initiale. Ce qui reste à faire, c'est votre travail de conception — et il commence par bien comprendre ce que vous construisez avant de choisir avec quoi vous le construisez.