01. L'éternel débat — Lakehouse ou Warehouse ?
Depuis l'arrivée de Microsoft Fabric, une question revient systématiquement dans les équipes data : faut-il construire sur un Lakehouse ou sur un Warehouse ? Les deux options coexistent dans la plateforme, avec leurs propres forces, leurs propres limites — et leurs propres évangélistes.
L'architecture traditionnelle que la plupart d'entre nous connaissent ressemble à ça :
Le Warehouse sert de couche de serving entre l'ingénierie data et les outils de reporting. Il centralise les modèles dimensionnels, expose des vues SQL propres, et garantit la performance des requêtes analytiques. C'est un pattern éprouvé — mais est-il encore le seul modèle viable dans Fabric ?
Un article récent publié sur le Microsoft Fabric Community Blog par Tamanchu apporte un éclairage intéressant sur ce sujet, en plaçant Direct Lake au centre de la réflexion. Voici ma lecture de cette analyse.
02. Direct Lake — Ce que ça change vraiment
Direct Lake est le mode de connexion Power BI qui permet d'interroger directement les tables Delta stockées dans OneLake, sans avoir à importer les données dans un dataset ni passer par DirectQuery. C'est la combinaison idéale :
- Performance quasi-import — les données sont lues depuis le parquet compressé V-Order, optimisé pour l'analyse columnaire
- Pas de refresh planifié — les nouveaux fichiers Delta sont visibles immédiatement sans déclencher de pipeline de refresh
- Stockage unifié dans OneLake — une seule copie des données, partagée entre le Lakehouse, le Warehouse et Power BI
Ce que ça signifie concrètement : si vos données sont déjà dans un Lakehouse bien structuré, Power BI peut les exploiter directement avec une latence minimale. Le Warehouse n'est plus automatiquement nécessaire comme couche intermédiaire de serving.
Direct Lake combine la fraîcheur de DirectQuery avec la performance de l'Import. Il lit les fichiers Parquet Delta directement depuis OneLake, charge les données en mémoire dans Analysis Services à la demande, et ne nécessite aucune copie supplémentaire des données.
03. Le piège silencieux — Le fallback vers DirectQuery
C'est le point le plus important de l'article, et probablement le plus méconnu en production. Direct Lake peut silencieusement basculer vers DirectQuery dans certaines conditions, sans aucun avertissement visible dans votre rapport.
Les trois scénarios de fallback à connaître :
- V-Order manquant — vos tables Delta ne sont pas optimisées avec le V-Order de Microsoft. Sans cette optimisation, Direct Lake ne peut pas charger les données en mémoire efficacement et bascule en DirectQuery.
- Dépassement des limites de rowgroups — chaque SKU Fabric a une limite sur le nombre de rowgroups qu'un dataset Direct Lake peut charger. Au-delà, fallback automatique.
- Metadata périmée — si les statistiques Delta ne sont pas à jour (OPTIMIZE non exécuté depuis longtemps), Direct Lake peut ne pas réussir à résoudre le schéma et bascule.
Il n'y a aucun avertissement dans votre rapport quand Direct Lake bascule en DirectQuery. Les visuels continuent de s'afficher — mais avec une performance dégradée et un comportement différent sur les calculs DAX complexes. Surveillez le mode de connexion dans les Performance Analyzer de Power BI Desktop.
La bonne pratique : activer OPTIMIZE WITH (VORDER = true) sur vos tables Delta critiques, monitorer la taille des rowgroups, et mettre en place une routine de maintenance régulière.
# Optimiser avec V-Order pour Direct Lake
spark.sql("""
OPTIMIZE gold.FactSales
ZORDER BY (DateKey, CustomerKey)
""")
# Nettoyer les anciens fichiers
spark.sql("VACUUM gold.FactSales RETAIN 168 HOURS")
# Vérifier l'état V-Order
spark.sql("""
DESCRIBE DETAIL gold.FactSales
""").show(truncate=False)04. Quand le Lakehouse seul suffit
L'architecture simplifiée Lakehouse → Direct Lake → Power BI fonctionne très bien dans un certain nombre de contextes. Voici les conditions qui font qu'un Warehouse est superflu :
✅ Le Lakehouse suffit si…
- Les données sont déjà pré-modélisées dans les couches Gold (tables de faits et dimensions propres)
- Les utilisateurs finaux consomment principalement via Power BI et non via des clients SQL tiers
- Les besoins en SQL serving sont minimes (pas d'applications, d'APIs ou d'outils BI autres que Power BI)
- L'équipe maîtrise la maintenance Delta (OPTIMIZE, VACUUM, V-Order)
Dans ce scénario, ajouter un Warehouse introduit une couche supplémentaire sans valeur réelle : plus de pipelines à maintenir, plus de latence potentielle, plus de capacité consommée. La simplicité gagne.
05. Quand le Warehouse reste indispensable
Le Warehouse n'est pas mort pour autant. Il reste le bon choix dans plusieurs situations concrètes :
| Situation | Pourquoi le Warehouse |
|---|---|
| Consommateurs SQL externes | Applications tierces, outils ETL legacy, connexions ODBC/JDBC — le Warehouse expose un endpoint SQL standard |
| T-SQL comme couche primaire | Equipes analytiques qui écrivent leurs propres requêtes SQL, procédures stockées, vues complexes |
| Plusieurs applications dépendantes | Quand de nombreuses applications s'appuient sur la couche serving, un contrat SQL stable est préférable aux chemins Delta |
| Séparation gouvernance | Quand l'entreprise exige une séparation formelle entre l'équipe data engineering et la couche serving analytique |
Dans Fabric, le Warehouse peut lire directement les tables Delta du Lakehouse via des shortcuts. On peut donc avoir une architecture hybride : le Lakehouse stocke les données, et le Warehouse expose une couche SQL propre par-dessus — sans duplication de données.
06. Framework de décision en 5 questions
Plutôt que de débattre de "Lakehouse vs Warehouse" en abstracto, l'approche pragmatique consiste à répondre à 5 questions sur votre contexte spécifique :
- Qui consomme les données ? — Analystes Power BI uniquement, ou aussi des développeurs SQL, des applications, des APIs ?
- Comment sont-elles consommées ? — Power BI exclusivement, ou aussi via SQL client, notebooks, exports CSV ?
- Y a-t-il des consommateurs SQL externes ? — Si oui, un endpoint SQL stable (Warehouse) est quasiment incontournable.
- Quelles contraintes de gouvernance s'appliquent ? — Faut-il séparer formellement l'ingestion du serving ? Des certifications de données sont-elles requises ?
- Quelle complexité opérationnelle l'équipe peut-elle absorber ? — Maintenir un Warehouse + un Lakehouse coûte plus cher en engineering que l'un ou l'autre seul.
Si la réponse aux questions 1 et 2 est "Power BI uniquement" et que la réponse à 3 est "non", commencez par le Lakehouse + Direct Lake. Vous pourrez toujours ajouter un Warehouse plus tard si le besoin se matérialise.
07. Conclusion — Le contexte bat le dogme
La phrase qui résume le mieux l'article de Tamanchu : "Context beats dogma every time." Il n'y a pas de réponse universelle à "Lakehouse ou Warehouse ?". Il y a des réponses adaptées à chaque contexte.
Ce que Direct Lake change fondamentalement, c'est qu'il retire le Warehouse de la liste des composants obligatoires dans une architecture Fabric orientée Power BI. Avant Direct Lake, le Warehouse servait de couche de performance entre les données brutes et les rapports. Aujourd'hui, cette couche peut être absorbée directement par le Lakehouse — à condition de maintenir correctement ses tables Delta.
Mon point de vue en tant que Data Engineer : la vraie question n'est pas "quel produit choisir" mais "quel pattern de consommation sert mes utilisateurs". La technologie suit la réponse — pas l'inverse.
Si vous travaillez sur une architecture Fabric et que vous vous posez cette question, commencez par mapper vos consommateurs et leurs outils. La décision devient souvent évidente une fois ce travail fait.
Retrouvez-moi sur LinkedIn pour en discuter — et lisez l'article original de Tamanchu, très bien écrit et riche en nuances.
Sources & Références
- Direct Lake Is Changing the Lakehouse vs Warehouse Debate in Microsoft Fabric — Tamanchu, Fabric Community Blog (juin 2026)
- Direct Lake overview — Microsoft Learn
- Lakehouse overview in Microsoft Fabric — Microsoft Learn
- Data warehousing in Microsoft Fabric — Microsoft Learn
- Delta optimization and V-Order — Microsoft Learn