Le lakehouse : unifier analytics et ML

Le copier-coller à 200 millions de dollars

En 2019, une grande banque européenne exploitait le dispositif analytique que la plupart des entreprises utilisent encore aujourd'hui : un entrepôt Teradata alimentant les équipes réglementaires et BIBITechnologies 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 →, et un lac Hadoop alimentant les data scientists. Entre les deux, 40 jobs ETLETLL'ETL (Extract, Transform, Load) est un processus d'intégration de données qui extrait les données de sources multiples, les remet en forme dans un format cohérent et les écrit dans un système cible.Voir la définition complète → nocturnes dont le seul but était de copier les données d'un système vers l'autre pour que les deux côtés voient à peu près les mêmes chiffres. **L'équipe de réconciliation existait *uniquement* pour expliquer pourquoi le « nombre de clients » de l'entrepôt et celui du lac divergeaient de 3 %**.

Quand la banque a finalement chiffré le coût de cette duplication, stockage payé deux fois, pipelines maintenus deux fois, deux régimes de gouvernance, et des effectifs dont le métier était la réconciliation, le montant a dépassé les neuf chiffres sur la durée de vie de la plateforme. Rien de tout cela n'a produit le moindre insight. C'est la taxe que vous payez pour maintenir deux copies de la vérité.

Le lakehouse est, dans son principe, un pari architectural : celui de pouvoir arrêter de payer cette taxe. Cette leçon porte sur la question de savoir si ce pari est gagnant pour *votre* organisation, car pour une minorité non négligeable d'entreprises, la séparation en deux systèmes reste le bon choix.

Ce que le 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 → change réellement

Vous connaissez déjà le 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 → entrepôt + lac. Le lakehouse n'invente pas de nouveaux besoins utilisateurs ; il redessine la frontière entre stockage et compute afin qu'une copie unique et gouvernée des données puisse servir à la fois la BI et le ML.

Le mécanisme qui rend cela possible est le format de table ouvert : Delta Lake, Apache Iceberg ou Apache Hudi. Comprenez cette couche et vous comprenez toute l'architecture ; passez à côté et tous les discours de vendeurs vous sembleront identiques.

Un 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 → brut, ce n'était que des fichiers (Parquet, ORC) posés dans un stockage objet. Pas cher, scalable et bête : pas de transactions, pas d'application de schéma, aucun moyen de mettre à jour une seule ligne sans réécrire une partition entière. C'est pourquoi vous ne pouviez pas y faire de la BI sérieuse. Le format de table ajoute une couche de métadonnées *au-dessus* de ces fichiers, qui apporte ce qu'un entrepôt a toujours eu :

• Transactions ACID : les écritures concurrentes ne corrompent pas les lectures.
• Application et évolution du schéma : les données non conformes sont rejetées à l'écriture ; des colonnes peuvent être ajoutées sans risque.
• Time travel : interroger la table telle qu'elle existait à une version antérieure, ce qui transforme la reproductibilité ML et l'audit.
• Upserts et suppressions : essentiels pour le « droit à l'oubli » du RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → et l'ingestion CDCCDCTechnique qui détecte et transmet uniquement les données modifiées d'un système source, gardant les systèmes en aval à jour sans tout recharger.Voir la définition complète →.

La conséquence stratégique : **vos données sont stockées une seule fois, dans des fichiers au format ouvert, dans votre propre stockage objet, et *plusieurs moteurs* pointent dessus**. Un moteur 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 → sert l'analyste BI. Un cluster Spark ou Python sert le data scientist. Un moteur de streaming écrit les événements frais dans les mêmes tables. Personne ne copie quoi que ce soit.

-- Same governed Delta table, two very different consumers
-- BI analyst:
SELECT region, SUM(revenue) FROM sales.transactions
WHERE order_date >= '2024-01-01' GROUP BY region;

-- Data scientist, same table, reading a reproducible snapshot:
SELECT * FROM sales.transactions VERSION AS OF 142;

Cette clause VERSION AS OF mérite qu'on s'y arrête. Dans le monde à deux systèmes, un data scientist qui avait entraîné un modèle en mars pouvait rarement reconstituer les données d'entraînement exactes six mois plus tard, quand un régulateur ou un comité de model risk le demandait. Le time travel fait de « montrez-moi les données que ce modèle a vues » une requête d'une ligne. Pour n'importe quel CDO d'un secteur régulé, cette seule capacité justifie souvent l'architecture à elle seule.

Séparer stockage et compute, voilà le vrai basculement

Le basculement plus profond n'est pas le format de fichier : c'est que stockage et compute deviennent scalables et tarifés indépendamment. Dans un entrepôt classique, vous achetiez une appliance couplée : plus de stockage signifiait une machine plus grosse, que vous ayez besoin ou non de la puissance. Dans le lakehouse, le stockage est du stockage objet de commodité à quelques centimes le gigaoctet, et vous montez ou descendez le compute à la demande.

Cela fait passer la conversation coûts du CDO de « quelle est la taille de notre entrepôt » à « quels workloads exécutons-nous, et quand ». C'est une meilleure conversation, mais elle introduit un nouveau mode de défaillance sur lequel nous reviendrons : sans discipline, un compute découplé est une facture qui croît avec la négligence.

Le tableau honnête des arbitrages

Le récit des vendeurs veut que le lakehouse domine l'ancienne séparation sur tous les axes. Ce n'est pas le cas. Voici le jugement qu'un CDO doit réellement porter.

Là où le lakehouse gagne de manière décisive :

• Source unique de vérité. Une copie, un modèle de gouvernance, un graphe de lineage. L'équipe de réconciliation disparaît. C'est le gain structurel le plus important et le plus difficile à quantifier tant que vous n'avez pas vécu la douleur de la duplication.
• ML et données non structurées. Les data scientists travaillent sur des tables gouvernées de qualité production au lieu d'extractions périmées, et le même store contient images, texte et audio qu'un entrepôt ne peut pas héberger. Si votre stratégie est réellement AI-forward, ce n'est pas optionnel.
• Coût à l'échelle. Stockage objet plus compute élastique coûte radicalement moins cher que le stockage d'entrepôt pour de gros volumes, des données froides ou peu interrogées.
• Pas de vendor lock-in au niveau du stockage. Vos données sont des fichiers au format ouvert qui vous appartiennent. Vous pouvez changer de moteur de requête sans projet de migration. C'est un vrai levier dans les négociations fournisseurs : utilisez-le.

Là où entrepôt + lac gagne encore :

• BI à faible latence et forte concurrence. Un entrepôt mature (Snowflake, BigQuery, Teradata) servant des milliers d'utilisateurs de dashboards simultanés avec un temps de réponse inférieur à la seconde reste, dans bien des cas, plus rapide et plus prévisible qu'un lakehouse réglé pour le même usage. L'écart se réduit vite, mais il existe.
• Maturité opérationnelle. Les entrepôts ont 30 ans d'outillage, d'expertise DBA et d'optimiseurs éprouvés. La stack lakehouse exige des compétences plus rares : des gens qui comprennent la compaction de fichiers, les problèmes de petits fichiers et le design des partitions. Si vous n'avez pas ces talents, l'architecture « moins chère » devient coûteuse.
• Simplicité pour les organisations purement BI. Si vous n'avez pas d'ambition ML sérieuse et des volumes modestes, un entrepôt seul est plus simple que le lakehouse *ou* la séparation en deux systèmes. N'adoptez pas un lakehouse pour résoudre un problème que vous n'avez pas.

La règle de décision que je donne aux CDO : l'avantage du lakehouse croît avec la taille de vos données, le sérieux de votre agenda ML et la douleur de votre duplication actuelle. Si les trois sont élevés, le dossier est écrasant. Si votre univers est small-data, BI uniquement, et tourne bien, le lakehouse est une solution en quête d'un problème.

Les coûts cachés que personne ne démontre

Deux réalités opérationnelles n'apparaissent jamais dans le deck commercial, et les deux atterrissent sur le bureau du CDO.

Le problème des petits fichiers. L'ingestion en streaming écrit une multitude de fichiers minuscules. Sans gestion, la performance des requêtes se dégrade fortement, car le moteur passe son temps à ouvrir des milliers de fichiers au lieu de lire des données. C'est gérable, Delta et Iceberg disposent de la compaction et du clustering, mais c'est une *responsabilité opérationnelle permanente*, pas un paramétrage unique. Budgétez l'ingénierie plateforme qui en aura la charge.

La dérive des coûts de compute. Parce que le compute est élastique et facile à démarrer, les lakehouses non gouvernés produisent des factures stupéfiantes. Un seul analyste lançant une requête non optimisée sur une table d'un pétaoctet peut brûler des milliers de dollars en quelques minutes. Le monde à deux systèmes avait un plafond de coût naturel avec son appliance fixe ; le lakehouse échange ce plafond contre de la flexibilité, et la flexibilité sans discipline FinOps n'est qu'une carte de crédit sans plafond. Le tagging des workloads, l'attribution des coûts par équipe et la gouvernance des requêtes ne sont pas optionnels : c'est le prix d'entrée.

Jugement sur la migration : comment y arriver concrètement

Admettons que vous ayez décidé que le lakehouse est le bon choix. L'erreur que je vois le plus souvent est de traiter cela comme un projet d'infrastructure en lift-and-shift. Ce n'en est pas un. C'est un programme de gouvernance et de migration de workloads qui implique accessoirement de l'infrastructure. Voici comment le séquencer.

Commencez par l'architecture medallion comme discipline structurante. Vous avez probablement entendu le découpage bronze/silver/gold ; l'intérêt pour un CDO est qu'il s'aligne proprement sur la propriété et la confiance :

• Bronze : données brutes ingérées, propriété des équipes plateforme/ingestion. Personne ne construit dessus directement.
• Silver : données nettoyées, conformées, dédoublonnées. Propriété du data engineering. C'est là que vit réellement votre source unique de vérité.
• Gold : agrégats métier et tables de features ML, propriété des équipes métier et des analystes.

Pourquoi c'est stratégiquement important : cela empêche le lakehouse de dégénérer en « data swamp », ce qui a tué la première génération de data lakes. Les couches medallion sont des frontières de gouvernance, pas seulement des étapes de traitement. Formalisez par écrit la propriété de chaque couche avant de migrer quoi que ce soit.

Migrez par workload, pas par jeu de données. N'essayez pas de tout déplacer en commençant par l'ensemble de vos données. Choisissez un workload délimité et très douloureux, idéalement un qui *exige* aujourd'hui de copier des données entre votre entrepôt et votre lac, et déplacez-le de bout en bout. L'analytique lourde en réconciliation dont souffrait la banque européenne est le candidat idéal : la migrer prouve la thèse de la source unique de vérité et produit une économie d'effectifs visible.

Faites tourner en parallèle et réconciliez avant de basculer. Pour les premiers workloads migrés, faites tourner l'ancien et le nouveau côte à côte et prouvez que les chiffres concordent. C'est fastidieux et sans gloire, et c'est l'activité la plus importante de tout le programme pour construire la confiance. La première fois qu'un dashboard migré affiche un chiffre différent du dashboard historique et que vous *ne pouvez pas* l'expliquer, vous perdez la confiance du métier pour un an.

Choisissez votre format de table délibérément : c'est un choix stratégique, pas technique. Delta Lake est étroitement intégré à Databricks et possède l'outillage le plus mature ; si vous êtes une maison Databricks, c'est le chemin de moindre résistance, mais il vous couple plus fortement à cet écosystème. Apache Iceberg est devenu le standard neutre et multi-moteurs : Snowflake, BigQuery, AWS et d'autres le supportent tous, ce qui en fait le choix le plus solide quand votre objectif explicite est l'indépendance de moteur et le levier de négociation. Prenez cette décision au niveau du CDO *avec* vos architectes, car elle détermine le levier anti-lock-in que vous conservez pour la décennie à venir. Ne la laissez pas se prendre implicitement par celui qui pilote le premier proof-of-concept.

Ne dissolvez pas votre entrepôt par réflexe. Les entreprises les plus avancées fonctionnent en hybride : le lakehouse comme source unique de vérité gouvernée, avec une partie des données de la couche gold encore servie via un entrepôt spécialisé ou une couche de serving pour la BI à plus forte concurrence. Le format de table ouvert rend cela viable : une table Iceberg peut être interrogée à la fois par vos jobs Spark et par Snowflake. La pureté n'est pas l'objectif ; éliminer la *vérité* dupliquée l'est. Vous pouvez avoir une seule copie gouvernée et la pousser malgré tout dans un moteur de serving rapide, car il s'agit d'une projection de performance, pas d'une seconde source de vérité.

Le changement organisationnel qui décide du succès

L'architecture unifie le stockage. Elle n'unifie pas automatiquement vos *gens*, et c'est là que les programmes lakehouse échouent discrètement. Dans le monde à deux systèmes, l'équipe BI et l'équipe ML avaient des plateformes séparées, des gouvernances séparées et des rituels séparés. Mettez-les sur un store unique et vous avez créé une dépendance partagée entre deux groupes qui n'ont peut-être jamais collaboré.

Le travail du CDO ici est de faire de la plateforme partagée une *responsabilité* partagée. Quelqu'un doit être propriétaire de chaque couche medallion. Quelqu'un doit être propriétaire de la compaction et de la gouvernance des coûts. La définition d'une table gold « certifiée » doit être arbitrée entre la BI et le ML, puisqu'ils vont désormais boire au même puits. Si vous migrez la technologie mais laissez l'organisation dans ses anciens silos, vous reconstruirez la séparation en deux systèmes à l'intérieur d'une plateforme unique : même duplication, désormais cachée.

Points clés à retenir

1. Le format de table, c'est tout l'enjeu. Delta, Iceberg ou Hudi est ce qui transforme un lac bête en store gouverné servant à la fois la BI et le ML. Évaluez les propositions lakehouse sur leur stratégie de format de table, et choisissez Iceberg quand l'indépendance de moteur et le levier fournisseur sont des priorités.

1. Notez la décision sur trois axes : volume de données, sérieux du ML et douleur de la duplication. Élevé sur les trois rend le lakehouse incontournable ; faible sur les trois signifie qu'un simple entrepôt bat à la fois le lakehouse et l'ancienne séparation. N'adoptez pas l'architecture par prestige.

1. Budgétez la taxe opérationnelle que la démo cache. Le problème des petits fichiers et la dérive des coûts de compute élastique sont des responsabilités permanentes. Mettez en place la discipline FinOps, tagging des workloads, attribution des coûts, gouvernance des requêtes, *avant* la mise en production, pas après la première facture choquante.

1. Migrez par workload douloureux, faites tourner en parallèle et réconciliez de manière obsessionnelle. Le premier écart de chiffre inexpliqué vous coûte un an de confiance du métier. Prouvez la thèse de la source unique de vérité sur un workload lourd en réconciliation avant de passer à l'échelle.

1. Unifiez l'organisation, pas seulement le stockage. Attribuez une propriété explicite à chaque couche medallion et arbitrez une définition partagée de la table certifiée entre BI et ML, sinon vous reconstruirez vos silos dans une seule plateforme.