Pendant quinze ans, les architectures de données ont oscillé entre deux mondes qui s’ignoraient. D’un côté l’entrepôt de données (data warehouse), structuré, rapide, fiable, mais coûteux et rigide. De l’autre le lac de données (data lake), souple, bon marché, capable d’absorber n’importe quel format, mais souvent transformé en marécage ingouvernable. Le lakehouse promet de réconcilier les deux. Promesse marketing ou vraie rupture architecturale ?
Deux philosophies opposées
L’entrepôt impose un schéma à l’écriture : la donnée doit être nettoyée, validée et structurée avant d’entrer. Résultat, une qualité élevée et des requêtes analytiques très performantes, au prix d’une grande rigidité et d’un stockage onéreux. Ajouter une nouvelle source peut demander des semaines de modélisation.
Le lac fait l’inverse : il stocke tout, brut, et applique le schéma à la lecture. Très économique grâce au stockage objet, idéal pour la science des données et les contenus non structurés (images, journaux, texte), mais sans garanties transactionnelles ni gouvernance, il devient vite difficile à exploiter de manière fiable. On y trouve tout, mais on ne sait plus ce qui est à jour ni ce qui est de confiance.
Ce que change le lakehouse
L’idée centrale du lakehouse est d’apporter les garanties de l’entrepôt directement sur le stockage objet bon marché du lac. La brique technique qui rend cela possible, ce sont les formats de table ouverts comme Delta Lake, Apache Iceberg ou Apache Hudi. Ils ajoutent, par-dessus de simples fichiers, une couche de métadonnées qui apporte :
- des transactions ACID, donc des écritures fiables même en cas d’accès concurrents ;
- le voyage dans le temps, pour interroger ou restaurer une version antérieure de la table ;
- l’évolution de schéma contrôlée, sans tout reconstruire quand une colonne change ;
- des performances proches de celles d’un entrepôt grâce à l’indexation, au partitionnement et à la compaction des fichiers.
On obtient ainsi une seule copie de la donnée, exploitable à la fois par les analystes en SQL et par les scientifiques des données en Python, sur un stockage qui coûte une fraction de celui d’un entrepôt classique.
Les bénéfices concrets
Le premier gain est la fin de la duplication. Dans une architecture traditionnelle, la même donnée est souvent copiée du lac vers l’entrepôt, ce qui multiplie les coûts, les délais de synchronisation et les risques d’incohérence entre deux sources censées dire la même chose. Le lakehouse supprime ce double stockage et ce pipeline fragile.
Le second gain est l’ouverture. Les formats étant standards et ouverts, on n’est plus prisonnier d’un seul moteur : plusieurs outils peuvent lire et écrire les mêmes tables. C’est un argument de poids contre l’enfermement propriétaire, et une assurance pour l’avenir.
Les limites à connaître
Le lakehouse n’est pas exempt de défauts. Les performances sur des requêtes très exigeantes peuvent encore rester en deçà des meilleurs entrepôts spécialisés. La gestion des petits fichiers, si elle n’est pas automatisée, dégrade les performances avec le temps. Et la maturité des outils varie selon le format choisi. Ce n’est donc pas une solution magique, mais une architecture qui demande de la rigueur opérationnelle.
Faut-il franchir le pas ?
Migrer un entrepôt mature et parfaitement rodé vers une nouvelle architecture ne se justifie pas toujours : si tout fonctionne et que le coût est maîtrisé, la prudence est de mise. En revanche, pour une entreprise qui démarre, qui jongle déjà avec un lac difficile à gouverner, ou qui souffre du coût de la duplication, l’approche lakehouse est aujourd’hui la plus pertinente.
Notre recommandation : commencer par un cas d’usage ciblé, choisir un format de table ouvert, et valider la gouvernance (catalogue, droits d’accès, qualité) avant d’industrialiser. Le lakehouse ne dispense pas de discipline, il la rend simplement plus accessible et moins coûteuse.