Monte Carlo · 6 janvier 2026
Entrepôt, lac ou lakehouse : quelle architecture pour vos données ?
- architecture data
- composants
- modernisation
Data warehouse, data lake, data lakehouse : trois termes omniprésents, souvent employés l'un pour l'autre. Ce guide de Monte Carlo remet les définitions à plat et — plus utile encore — donne des critères pour choisir.
Trois modèles, trois philosophies
L'entrepôt de données (warehouse) centralise des données structurées, optimisées pour l'analyse et le décisionnel en SQL — l'univers de Redshift, BigQuery ou Snowflake. Le lac de données (lake) accueille tout — structuré, semi-structuré, brut — à faible coût de stockage, au service de l'analytique avancée et du machine learning, en dissociant stockage et calcul. Le lakehouse combine les deux : la souplesse du lac, plus les garanties de l'entrepôt (transactions, contrôle de schéma, SQL) apportées par des technologies comme Delta Lake ou Apache Iceberg.
Choisir selon les usages, pas selon la mode
Les critères proposés sont pragmatiques : le profil des utilisateurs (équipes BI → entrepôt ; data scientists → lac ; équipes mixtes → lakehouse), la nature des données, la structure de coûts — stockage bon marché mais traitement coûteux côté lac, investissement initial plus lourd côté entrepôt — et le mode de traitement, schéma imposé à l'écriture ou appliqué à la lecture. L'article note enfin que les innovations récentes des grands éditeurs brouillent de plus en plus ces frontières.
Ce que cela change pour une PME
Le vocabulaire compte : quand un prestataire propose « un data lake » à une PME dont tout le patrimoine est structuré et tiendrait dans une base unique, il y a sur-dimensionnement. Comprendre ces trois modèles permet de poser les bonnes questions — qui va s'en servir, pour quelles données, à quel coût récurrent. C'est le rôle de l'axe « architecture » de l'Audit Data : partir des usages réels et dimensionner au plus juste, quitte à choisir la solution la plus simple.