Databricks Lakehouse : quand le data lake rejoint enfin le warehouse

Pendant une décennie, toute plateforme de données sérieuse a fait tourner deux systèmes. Un data lake pour tout déverser dans du stockage objet bon marché, et un data warehouse pour servir les tables propres et modélisées que le métier interrogeait réellement. Deux copies des données, deux jeux de pipelines, deux factures, et une dispute permanente sur celui qui détenait la vérité.

Le lakehouse est la tentative de faire s'effondrer ce clivage en un seul. Databricks n'a inventé ni le stockage ni le format de fichier, mais il a empaqueté le patron en quelque chose qu'une équipe peut exploiter en production. Après plusieurs de ces chantiers, voici ce qui est réel et ce qui relève du marketing.

Deux mondes, et pourquoi les équipes utilisaient les deux

Un data lake, c'est du stockage objet — Azure Data Lake Storage Gen2, S3, GCS — qui héberge des fichiers bruts dans n'importe quel format. C'est bon marché, cela passe à l'échelle à l'infini et c'est du schema-on-read : tu décides de la structure au moment de la requête, pas de l'écriture. Le prix à payer, c'est qu'un lake sans discipline se transforme en marécage. Pas de transactions, pas de validation de schéma, aucun moyen simple de mettre à jour une seule ligne.

Un warehouse, c'est l'inverse. Des tables structurées, des garanties ACID, du SQL rapide, une vraie gouvernance. Le prix, c'est la rigidité et le coût : tu paies pour charger les données, tu paies pour un stockage propriétaire, et les charges de machine learning qui veulent des fichiers bruts ne rentrent pas dans le modèle.

Utiliser les deux, c'est copier les données de l'un à l'autre et réconcilier les copies éternellement. La question du lakehouse est simple : et si le lake pouvait se comporter comme un warehouse sans une seconde copie ?

Ce qu'est réellement un lakehouse

L'astuce, c'est un format de table ouvert posé par-dessus les fichiers du stockage objet. Sur Databricks, c'est Delta Lake : des fichiers de données Parquet plus un journal de transactions. Ce journal, c'est tout l'enjeu. Il te donne :

• Des transactions ACID — les écritures concurrentes ne corrompent plus une table.
• La validation et l'évolution du schéma — les mauvaises données sont rejetées, les bons changements sont versionnés.
• Le time travel — interroge la table telle qu'elle était mardi dernier, ou reviens en arrière sur un chargement défectueux.
• Les upserts et les suppressions — MERGE fonctionne, ce qui compte pour l'effacement RGPD et le change-data-capture.

Comme les données restent en Parquet ouvert dans ton propre compte de stockage, une seule copie sert à tout : tableaux de bord SQL, jobs de streaming et entraînement ML lisent les mêmes tables. Aucun verrouillage sur les octets, aucune étape d'export. Voilà la récompense.

L'architecture medallion

Le lakehouse te donne les primitives ; l'architecture medallion, c'est la façon de les garder en ordre. Les données circulent à travers trois niveaux de qualité :

1. Bronze — ingestion brute, exactement telle qu'elle est arrivée. En ajout seul, auditable, jamais éditée.
2. Argent — nettoyée, dédupliquée, conformée. Jointe et typée, mais encore granulaire.
3. Or — agrégats au niveau métier et schémas en étoile que consomment tableaux de bord et rapports.

La discipline compte plus que l'outil. Le bronze est ta police d'assurance : si une transformation d'argent est fausse, tu retraites depuis le bronze au lieu de réingérer depuis la source. Saute-le et tu perds la capacité de réparer l'historique.

Unity Catalog : la gouvernance qu'on ne peut pas rajouter après coup

Unity Catalog est la pièce que la plupart des équipes sous-estiment. C'est une couche de gouvernance unique sur l'ensemble des workspaces : contrôle d'accès fin, masquage de colonnes et de lignes et — ce qui te sauve lors d'un audit — le lignage automatique. Tu peux voir quel rapport dépend de quelle table d'or, qui dépend de quel job d'argent, jusqu'au fichier brut.

La gouvernance n'est pas une fonctionnalité qu'on adapte a posteriori une fois que tu as cinq cents tables et que personne ne sait qui peut lire quoi. Active-la dès la première table. Le coût de la migrer plus tard est brutal.

Performance : Photon et le SQL warehouse

La vieille objection contre les lakes, c'était la vitesse : interroger des fichiers ne pouvait pas rivaliser avec un warehouse bien réglé. Deux choses ont comblé l'écart. Photon est un moteur de requêtes vectorisé écrit en C++ qui accélère les charges SQL et DataFrame sans changer ton code. Et les SQL warehouses de Databricks donnent aux analystes un endpoint familier : ils connectent un outil de BI et interrogent les tables d'or, ignorant qu'il y a du stockage objet en dessous.

Le stockage et le calcul sont séparés, donc tu montes les clusters de requête en puissance pour une clôture de mois chargée puis tu les redescends sans toucher aux données. Cette élasticité, c'est là que l'économie du cloud penche vraiment en ta faveur — la même discipline que je défends dans les plateformes d'IA sereines.

Quand le lakehouse est la mauvaise réponse

Ce n'est pas une amélioration universelle. Sois honnête sur l'échelle :

• Des données petites et purement relationnelles. Si tout tient confortablement dans Postgres et que tu ne sers que de la BI, un warehouse managé est plus simple et moins cher. Un lakehouse, c'est de la machinerie dont tu n'as pas besoin.
• Aucune capacité d'ingénierie. Delta, les clusters et le flux medallion sont une vraie surface opérationnelle. Une équipe minuscule se noie.
• Des schémas en étoile purs et stables, sans ML ni streaming. Le lakehouse brille quand les charges sont mixtes. Si les tiennes ne le seront jamais, la flexibilité est un poids mort.

---

Le lakehouse gagne sa place quand tu as véritablement les deux mondes — données brutes et en streaming alimentant le ML et tables propres alimentant le métier — et que tu es fatigué de payer deux fois pour les garder synchronisés. Commence avec Delta et les niveaux medallion, active Unity Catalog immédiatement, et laisse Photon se soucier de la vitesse. La suite dans cette série : comment Microsoft joue la même partie avec Fabric, OneLake et Copilot Studio.