En 2026, une architecture lakehouse repose sur trois couches découplées : un stockage objet bon marché, des fichiers en format colonnaire ouvert organisés en tables transactionnelles, et plusieurs moteurs de calcul qui lisent et écrivent ces mêmes tables via un catalogue commun. C'est la différence majeure avec l'ère Hadoop : la valeur ne réside plus dans un cluster qui stocke et calcule au même endroit, mais dans une couche de tables ouvertes que n'importe quel moteur compatible peut exploiter.
Ce n'est pas qu'un changement de vocabulaire. Le « Big Data » des années 2010 promettait de tout stocker à bas coût ; il a souvent livré des lacs de fichiers sans transactions, difficiles à mettre à jour et à gouverner, à côté d'un entrepôt de données qui restait la référence pour le reporting. Le lakehouse tente de réunir les deux mondes sur une seule copie des données.
Cet article fait le tri entre ce qui a réellement changé, ce qui relève encore de la promesse, et les décisions d'architecture qui restent à prendre pour une DSI d'ETI ou de grand compte.
Ce qu'Hadoop a apporté, et pourquoi le modèle a atteint ses limites
Apache Hadoop reste un projet actif de l'Apache Software Foundation : il regroupe HDFS (système de fichiers distribué), YARN (ordonnancement et gestion des ressources du cluster) et MapReduce (traitement parallèle de grands volumes), et une version 3.5.0 a été publiée le 2 avril 2026 1. Son apport historique est considérable : il a démontré qu'on pouvait traiter de très grands volumes sur du matériel standard, en rapprochant le calcul des données.
C'est précisément ce couplage qui a vieilli. Dans un cluster HDFS, ajouter de la capacité de stockage impose d'ajouter des nœuds de calcul, et inversement. Les fichiers déposés dans le lac n'avaient pas de notion native de transaction : une écriture interrompue pouvait laisser une table dans un état incohérent, et mettre à jour ou supprimer une ligne supposait souvent de réécrire des partitions entières. Le catalogue (typiquement le metastore Hive) connaissait des répertoires, pas des versions de tables.
Résultat, beaucoup d'organisations ont maintenu deux systèmes : un lac pour la data science et l'archivage, un entrepôt pour la BI. C'est ce que l'article fondateur sur le lakehouse, présenté à la conférence CIDR en janvier 2021, appelle l'architecture à deux niveaux, avec quatre problèmes identifiés : la fiabilité (garder deux systèmes cohérents), la fraîcheur des données (chargements différés), le support limité du machine learning et un coût total élevé lié à la duplication du stockage et aux formats propriétaires 2. Ce papier est signé par des auteurs liés à Databricks ; son diagnostic sur l'architecture à deux niveaux est cependant largement partagé.
Les trois ruptures qui définissent l'architecture lakehouse
1. Le stockage objet remplace le système de fichiers distribué
Le socle n'est plus un cluster mais un stockage objet (en cloud public ou sur site), facturé et dimensionné indépendamment du calcul. On peut arrêter tous les moteurs sans perdre les données, ou en démarrer dix sur les mêmes tables. Les fournisseurs vont désormais plus loin : Amazon S3 Tables, par exemple, propose un type de bucket dédié aux tables, au format Apache Iceberg, avec maintenance automatique (compactage des petits fichiers, gestion des snapshots, suppression des fichiers non référencés) 6.
2. Un format de fichier colonnaire ouvert comme standard de fait
Apache Parquet se définit comme un format de fichier open source orienté colonnes, conçu pour un stockage et une lecture efficaces, avec des schémas de compression et d'encodage performants 3. Il est lu par la quasi-totalité des moteurs analytiques. Ce point paraît anodin ; il est en réalité la condition de tout le reste, car il permet à un moteur SQL, un framework de streaming et une bibliothèque de machine learning de lire les mêmes fichiers sans export.
3. Une couche de métadonnées transactionnelle : la table ouverte
La véritable nouveauté est la couche de métadonnées qui transforme un ensemble de fichiers en table : liste exacte des fichiers de chaque version, schéma, partitionnement, statistiques. Le papier CIDR la décrit comme l'élément qui apporte transactions ACID, versionnement, application du schéma et gouvernance sur des fichiers de lac 2. La spécification Apache Iceberg l'illustre bien : la version 1 gère les grandes tables analytiques sur fichiers immuables, la version 2 ajoute les suppressions au niveau ligne, la version 3 ajoute notamment de nouveaux types (variant, géométrie, horodatages à la nanoseconde), les valeurs par défaut de colonnes, le lignage de lignes et les vecteurs de suppression binaires ; une version 4 est en cours de développement et n'est pas encore adoptée à la date de rédaction 4.
La valeur ne réside plus dans le cluster qui calcule, mais dans la table ouverte que n'importe quel moteur peut lire.
Interopérabilité : la promesse et ses limites concrètes
Le découplage n'a de sens que si plusieurs moteurs peuvent réellement partager les tables. Trois formats de tables ouverts coexistent (Apache Iceberg, Delta Lake, Apache Hudi), et des passerelles existent entre eux. Delta Lake UniForm, par exemple, génère de manière asynchrone des métadonnées Iceberg ou Hudi après chaque commit Delta, pour qu'une seule copie des données serve plusieurs écosystèmes 5.
Les limites documentées méritent d'être lues avant de bâtir une stratégie dessus : les clients Iceberg et Hudi y sont en lecture seule, des écritures externes peuvent corrompre la table Delta, UniForm ne fonctionne pas sur les tables où les vecteurs de suppression sont activés, et certaines évolutions de protocole sont irréversibles 5. L'interopérabilité existe, mais elle est souvent asymétrique : un moteur écrit, les autres lisent.
Il en va de même pour les nouvelles versions de format. Toutes les fonctionnalités d'une version de spécification ne sont pas supportées au même moment par tous les moteurs. Avant d'activer une fonctionnalité de format, il faut vérifier la matrice de compatibilité de chaque moteur qui lit ou écrit la table, sous peine de rendre une table illisible pour une partie des consommateurs.
Ce qui n'a pas changé : les fondamentaux qui font échouer les projets
Le lakehouse règle des problèmes techniques réels ; il ne règle pas les problèmes d'organisation qui ont fait échouer nombre de lacs Hadoop. Trois constats restent valables.
- La maintenance des tables n'est pas optionnelle : sans compactage des petits fichiers ni expiration des anciens snapshots, les performances se dégradent et les coûts de stockage augmentent. Elle doit être planifiée, ou confiée à un service géré qui l'assure explicitement.
- Le catalogue devient un point critique : c'est lui qui dit quelle version d'une table est courante. Sa disponibilité, ses sauvegardes et ses droits d'accès doivent être traités comme ceux d'une base de production.
- La modélisation reste nécessaire : stocker des données brutes au format ouvert ne dispense ni de couches de données nettoyées, ni d'un modèle métier documenté pour la BI.
- La sécurité se déplace : quand plusieurs moteurs accèdent au même stockage, les contrôles d'accès doivent être appliqués de façon cohérente au niveau du catalogue et du stockage, pas seulement dans chaque moteur.
Les décisions d'architecture lakehouse à prendre en 2026
Pour une organisation qui conçoit ou rationalise sa plateforme, les choix structurants se résument à quelques questions, à trancher explicitement plutôt qu'à laisser émerger des outils.
- Quel format de table de référence ? Choisir un format principal pour les écritures, et n'utiliser les passerelles qu'en lecture, en connaissant leurs limites.
- Quel catalogue, et qui l'opère ? Un catalogue lié à un éditeur simplifie l'exploitation mais pèse sur la réversibilité ; un catalogue ouvert demande plus d'exploitation mais préserve le choix des moteurs.
- Quels moteurs ont le droit d'écrire ? Limiter le nombre de moteurs écrivains par table réduit fortement les risques de conflits et d'incompatibilités.
- Où sont les données et sous quel droit ? Le découplage permet de choisir un stockage hébergé en Europe, voire sur site, indépendamment des moteurs ; c'est un levier de souveraineté à documenter dans l'analyse de risques.
- Qui assure la maintenance ? Définir qui compacte, expire les snapshots et surveille la volumétrie des métadonnées, avec quels indicateurs.
- Comment sortir ? Tester tôt la lecture des tables par un second moteur, pour vérifier que la réversibilité annoncée est réelle.
Ces choix ont des conséquences budgétaires directes. Séparer stockage et calcul permet d'arrêter les moteurs inutilisés et de dimensionner chaque charge de travail séparément ; cela suppose en revanche une discipline de suivi des coûts, car la facilité à lancer de nouveaux moteurs peut aussi multiplier les dépenses.
Faut-il abandonner Hadoop tout de suite ?
Pas nécessairement. Un cluster Hadoop stable, qui sert des traitements batch bien maîtrisés, peut continuer à fonctionner pendant une migration progressive. La bonne question n'est pas « Hadoop ou lakehouse » mais « quelles nouvelles données et quels nouveaux usages doivent naître directement dans des tables ouvertes ? ». Commencer par les nouveaux flux, puis migrer les tables existantes par domaine, évite de figer la plateforme dans un chantier de bascule unique.
Les tables Hive existantes peuvent souvent être converties ou réenregistrées dans un format de table ouvert sans recopier toutes les données, selon les outils du format choisi ; ce point est à valider au cas par cas sur un échantillon représentatif avant d'en faire un principe de migration.
Conclusion
Ce qui a vraiment changé depuis Hadoop tient en une phrase : le stockage, le calcul et les métadonnées sont désormais trois couches indépendantes, et la table ouverte est devenue le contrat entre elles. Cela ouvre de vrais gains de coût, de réversibilité et de souveraineté, à condition de traiter le catalogue, la maintenance et la gouvernance comme des composants de production à part entière. DATASWING accompagne ce type d'arbitrage d'architecture en partant des usages et des contraintes de souveraineté de chaque organisation.
— Questions fréquentes
Ce qu'on nous demande souvent
Quelle est la différence entre un data lake et un lakehouse ?+
Un data lake stocke des fichiers bruts sans garantie transactionnelle ni notion de version de table. Un lakehouse ajoute au-dessus de ces fichiers une couche de métadonnées qui apporte transactions ACID, versionnement, application du schéma et gouvernance, ce qui permet de servir à la fois la BI et la data science sur une seule copie des données, sans entrepôt séparé.
Hadoop est-il encore utilisé en 2026 ?+
Oui, Apache Hadoop reste un projet actif de la fondation Apache, avec une version 3.5.0 publiée en avril 2026. Beaucoup d'organisations conservent des clusters stables pour des traitements batch existants. Les nouvelles plateformes privilégient cependant le stockage objet et les formats de tables ouverts, qui découplent stockage et calcul.
Quel format de table ouvert choisir pour un lakehouse ?+
Apache Iceberg, Delta Lake et Apache Hudi sont les trois principaux formats. Le choix dépend des moteurs que vous utilisez, du catalogue envisagé et des besoins d'interopérabilité. Il est recommandé de choisir un format principal pour les écritures et de vérifier, moteur par moteur, la compatibilité réelle avec les fonctionnalités de la version de format visée.
Un lakehouse coûte-t-il moins cher qu'un entrepôt de données ?+
Il peut réduire les coûts en évitant la duplication des données entre lac et entrepôt et en dimensionnant le calcul indépendamment du stockage. Mais ces gains dépendent de la maintenance des tables, de l'arrêt effectif des moteurs inutilisés et d'un suivi FinOps rigoureux. Sans cette discipline, la multiplication des moteurs peut au contraire augmenter la facture.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
Apache Hadoop ↗Apache Software Foundation · 2026
-
[2]
Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics (CIDR 2021) ↗CIDR / Armbrust, Ghodsi, Xin, Zaharia · 2021-01
-
[3]
Apache Parquet ↗Apache Software Foundation · 2026
-
[4]
Iceberg Table Spec (format/spec.md) ↗Apache Software Foundation (dépôt apache/iceberg) · 2026
-
[5]
Universal Format (UniForm) ↗Delta Lake (Linux Foundation) · 2026
-
[6]
Working with Amazon S3 Tables and table buckets ↗Amazon Web Services · 2026
