Data warehouse, lake & lakehouse : choisir la bonne architecture
Tout CDO a été confronté à cette question : « À quoi doit ressembler notre architecture de données ? »
La réponse a radicalement évolué au cours de la dernière décennie. Le data warehouse monolithique, longtemps considéré comme la référence, n'est plus qu'une option parmi d'autres. Pour faire les bons choix d'architecture, il faut comprendre ce qui existe, quels arbitrages chaque option implique, et comment faire correspondre l'architecture au besoin métier.
Le paysage des architectures de données
Le modern data stack a empilé de la complexité par-dessus la simplicité. Voici ce qui existe aujourd'hui :
Data warehouse : stockage structuré, interrogeable en SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète →, optimisé pour l'analytique. Exemples : Snowflake, BigQuery, Redshift. Idéal pour : business intelligencebusiness intelligenceTechnologies et processus qui transforment des données brutes en insights actionnables via du reporting, des dashboards et de l'analyse, pour que les équipes décident sur des faits plutôt qu'à l'intuition.Voir la définition complète →, dashboards, reporting structuré.
Data lake : stockage brut à grande échelle, données structurées, semi-structurées et non structurées. Exemples : AWS S3, Azure Data LakeData LakeUn data lake est un référentiel centralisé qui stocke de grands volumes de données brutes dans leur format d'origine, des tables structurées aux fichiers non structurés, jusqu'à ce qu'on en ait besoin.Voir la définition complète →, GCS. Idéal pour : tout stocker, ouvrir la voie à de futurs cas d'usage.
Data lakehouse : l'hybride né de la friction entre lakes et warehouses. Transactions ACID, contrôle de schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → et requêtes SQL sur un stockage de type lake. Exemples : Databricks Delta Lake, Apache Iceberg, Apache Hudi.
Data mesh : pas une technologie, un paradigme organisationnel et architectural. La propriété des données est distribuée aux équipes de domaine. Chaque domaine produit des data products. Gouvernance fédérée. Nous y reviendrons au module 3.2.
Data fabric : une couche d'architecture qui relie des sources de données hétérogènes via les métadonnées et l'intégration automatisée. Moins une question de stockage qu'une question de connectivité et de découverte.
Modern Data Stack Explained
Vérification des acquis
1. Qu'est-ce qui distingue fondamentalement un data lakehouse d'un data lake traditionnel ?
2. Le besoin principal d'une entreprise de retail est de disposer de dashboards BI rapides et fiables, avec des engagements de SLA auprès des métiers ; ses données sont bien structurées et son équipe est SQL-native. Quelle architecture correspond le mieux ?
3. Pourquoi décrit-on le data mesh comme fondamentalement différent d'un warehouse, d'un lake ou d'un lakehouse ?
4. Sélectionnez TOUS les scénarios dans lesquels choisir un data lake est la décision la plus appropriée.
Sélectionnez toutes les réponses correctes.
5. Sélectionnez TOUTES les affirmations qui décrivent correctement les cas où le lakehouse est le bon choix d'architecture.
Sélectionnez toutes les réponses correctes.
Warehouse vs. lake vs. lakehouselakehouseUne architecture hybride qui combine la flexibilité d'un data lake et les capacités analytiques d'un data warehouse, sur une seule couche de stockage.Voir la définition complète →
Le débat warehouse-lake-lakehouse est toujours vif dans chaque équipe data. Voici comment le trancher :
Choisissez un data warehouse quand : votre cas d'usage principal est la BI et le reporting, vos données sont structurées, votre équipe est SQL-native, et vous avez besoin de performances de requête garanties avec des engagements de SLASLAEngagement formel définissant le niveau de service qu'un fournisseur garantit à un client, avec des objectifs mesurables et des conséquences en cas de manquement.Voir la définition complète → auprès des métiers.
Choisissez un data lake quand : vous avez des volumes massifs de données non structurées (logs, clickstreams, images, documents), vous voulez conserver les données brutes pour de futurs cas d'usage ML, ou le coût de stockage est une préoccupation majeure.
Choisissez un lakehouse quand : vous voulez la flexibilité d'un lake avec la fiabilité d'un warehouse. Vous êtes une organisation data-intensive qui fait à la fois du ML et de la BI. Vous ne pouvez pas vous permettre de maintenir deux systèmes distincts. C'est de plus en plus le choix par défaut des organisations matures en data.
L'émergence du lakehouse
Le pattern lakehouse est né d'une douleur précise : des organisations ont construit des data lakes, ont découvert qu'il s'agissait de marécages inexploitables de données non structurées, et avaient besoin d'une fiabilité de type warehouse sans renoncer à leurs investissements dans le lake.
Delta Lake (Databricks), Apache Iceberg et Apache Hudi ont résolu cela en ajoutant les transactions ACID, l'évolution de schéma et les capacités de time-travel au stockage objet. Résultat : le coût de stockage d'un lake avec la fiabilité de requête d'un warehouse.
Netflix a migré toute son infrastructure de données vers Apache Iceberg. Ils gèrent des centaines de pétaoctets de données avec évolution de schéma, capacité de rollback et support des lectures-écritures concurrentes, des capacités auparavant réservées à des warehouses propriétaires coûteux.
Framework de décision architecturale
Pour évaluer les options d'architecture, posez-vous quatre questions :
- Type de workload : s'agit-il de BI, de ML, de streaming, ou des trois ? Des workloads différents favorisent des architectures différentes.
- Compétences de l'équipe : les équipes SQL-native penchent vers les warehouses ; les équipes Python-native vers les lakes.
- Volume et variété des données : fort volume + forte variété = lake ou lakehouse. Données structurées à volume modéré = warehouse.
- Tolérance au vendor lock-in : les warehouses cloud-native (Snowflake, BigQuery) offrent la simplicité d'usage au prix de la portabilité. Les formats ouverts (Iceberg, Delta) maximisent la portabilité.
Il n'existe pas de réponse universellement correcte. Une architecture bien raisonnée, alignée sur vos workloads réels, vaut mieux qu'une architecture sophistiquée que votre équipe ne sait pas exploiter.
Questions du quiz
- Quelle est la principale différence entre un data lake et un data lakehouse ?
A) Le lakehouse est plus cher
B) Le lakehouse ajoute des transactions ACID et la fiabilité d'un warehouse sur un stockage de type lake
C) Le lakehouse ne supporte pas le SQL
D) Le lakehouse est uniquement pour les données non structurées
Réponse: B
- Quelle architecture choisir en priorité pour une équipe BI SQL-native avec des données structurées ?
A) Data lake
B) Data meshData meshLe Data Mesh est une approche décentralisée de l'architecture et de l'organisation des données, où les équipes métier possèdent et exposent leurs données comme des produits, encadrées par des standards partagés.Voir la définition complète →
C) Data warehouseData warehouseUn référentiel central qui consolide les données de nombreux systèmes sources dans un stockage structuré et optimisé pour les requêtes, conçu pour l'analytique, le reporting et la business intelligence.Voir la définition complète →
D) Data fabric
Réponse: C
- Quel projet open source a permis à Netflix de gérer des centaines de pétaoctets avec des capacités ACID ?
A) Apache Kafka
B) Apache Hudi
C) Apache Iceberg
D) Delta Lake
Réponse: C
À faire, tiré de cette leçon
Ces actions sont compilées dans le plan d'action du rôle.
- Choisir l'architecture en fonction des workloads, des compétences de l'équipe, du volume et de la tolérance au lock-in
Articles liés
Les articles récents du blog qui s'appuient sur cette leçon.
- DataDuckDB, DuckLake et l'analyste qui parle à ses données : un guide d'exécutionLes interfaces en langage naturel changent ce que l'on attend d'un analyste, mais sans architecture solide en dessous, elles produisent des réponses confuses sur des données mal organisées. Ce guide donne la séquence concrète pour construire la fondation technique et redéfinir le rôle analytique en même temps.
- DataArchitecture de données moderne : ce que le CDO doit arbitrer en 2026Les choix d'architecture de données engagent les organisations sur plusieurs années et conditionnent directement la capacité à exploiter l'IA. Le CDO qui tarde à clarifier sa position entre lakehouse, data mesh et fabric prend un risque stratégique concret.
- DataArchitecture de données moderne : ce que le CDO doit arbitrer en 2026Les choix d'architecture de données ne sont plus seulement techniques : ils conditionnent la vitesse à laquelle une organisation peut répondre à une décision stratégique. Ce que le CDO doit comprendre, c'est que les arbitrages de 2026 engagent les cinq prochaines années.