Connecter Power BI au Lakehouse en mode DirectLake

Pendant des années, concevoir un modèle Power BI revenait à un compromis frustrant. Le mode Import offre des rapports rapides, mais au prix d’une copie complète des données et d’actualisations longues ; le mode DirectQuery garde les données fraîches, mais interroge la source à chaque clic, souvent au détriment de la vitesse. DirectLake, mode de stockage spécifique à Microsoft Fabric, brise ce compromis : il lit directement les tables Delta du Lakehouse, avec la rapidité de l’Import et la fraîcheur du direct, sans recopier les données. Ce tutoriel explique comment le mettre en place et, surtout, comment éviter les pièges qui font basculer un rapport hors de ce mode privilégié.

Ce tutoriel s’inscrit dans une série sur Power BI et Microsoft Fabric ; le guide de référence Power BI et Microsoft Fabric en donne la vue d’ensemble. Il suppose un Lakehouse alimenté de tables Delta propres, idéalement issues d’une transformation Spark bien optimisée.

Prérequis

• Une capacité Microsoft Fabric (référence F) : DirectLake n’est pas disponible sans capacité Fabric.
• Un Lakehouse contenant des tables Delta propres, de préférence en couche or.
• Power BI Desktop à jour si vous souhaitez modéliser sur le poste, ou simplement le portail Fabric.
• Niveau : avancé. Une bonne compréhension des modes de stockage Power BI est nécessaire.
• Temps estimé : 60 à 80 minutes.

Étape 1 — Situer DirectLake parmi les trois modes

Pour saisir l’apport de DirectLake, il faut d’abord clarifier les deux modes classiques. En Import, Power BI copie toutes les données dans le modèle ; les requêtes sont traitées par le moteur VertiPaq, très rapide, mais chaque actualisation recharge l’intégralité du volume. En DirectQuery, aucune donnée n’est copiée : chaque visuel génère une requête vers la source, ce qui garantit la fraîcheur mais dépend des performances de cette source, souvent en retrait.

DirectLake combine le meilleur des deux. Comme l’Import, il s’appuie sur le moteur VertiPaq, donc sur des performances de premier ordre. Comme le DirectQuery, il ne recopie pas les données : il lit directement les fichiers Delta stockés dans OneLake. Le résultat est un modèle qui interroge des volumes considérables à grande vitesse, sans le cycle d’actualisation lourd de l’Import ni la lenteur du DirectQuery. C’est cette équation, longtemps réputée impossible, que DirectLake résout grâce à l’architecture de Fabric.

Étape 2 — Comprendre le mécanisme du framing

La magie de DirectLake tient à une idée simple : ne charger en mémoire que ce dont une requête a besoin, au moment où elle en a besoin. Quand un visuel demande des données, le moteur charge les colonnes concernées depuis les fichiers Delta dans son cache mémoire, puis sert les requêtes suivantes depuis ce cache. Ce chargement à la demande explique pourquoi un modèle DirectLake peut dépasser la taille mémoire de la capacité : seules les portions utiles sont paginées.

L’autre concept clé est le framing. Là où une actualisation Import recopie toutes les données, une « actualisation » DirectLake ne fait que mettre à jour des métadonnées : elle pointe vers la dernière version des fichiers Delta dans OneLake. Cette opération, qui prend quelques secondes, est sans commune mesure avec un rechargement complet. Concrètement, dès qu’un pipeline ou un notebook écrit de nouvelles données dans le Lakehouse, un simple framing suffit pour que le rapport les reflète — et il peut même se faire automatiquement. La donnée préparée en amont, dans OneLake, devient ainsi disponible aux utilisateurs presque sans latence.

Étape 3 — Préparer des tables Delta optimisées

DirectLake ne donne sa pleine mesure que sur des tables Delta bien rangées. Une table fragmentée en milliers de petits fichiers, ou mal ordonnée, dégrade les performances même en DirectLake. La préparation des tables est donc une étape à part entière, pas un détail.

Deux bonnes pratiques font la différence. D’abord, l’optimisation V-Order, qui réorganise les fichiers Parquet pour accélérer les lectures du moteur d’analyse. Un point d’attention important : dans les espaces de travail Fabric créés à partir d’avril 2025 (profil orienté écriture), V-Order n’est plus activé par défaut et doit être activé explicitement sur les tables très sollicitées par les rapports ; les espaces plus anciens l’avaient en revanche d’office. Ensuite, lancez périodiquement la commande OPTIMIZE sur les tables très sollicitées pour compacter les fichiers, comme vu dans le tutoriel sur les notebooks Spark. Une table de couche or, propre, compactée et V-Ordonnée, est le carburant idéal de DirectLake. Soigner cette préparation en amont évite la plupart des déconvenues de performance que l’on attribue à tort au mode lui-même.

Étape 4 — Créer le modèle DirectLake

La création est étonnamment directe, car le Lakehouse fournit déjà tout le nécessaire. La voie la plus simple part du modèle sémantique par défaut, créé automatiquement avec le Lakehouse. Dans le Lakehouse, ouvrez ce modèle sémantique par défaut, ou créez-en un nouveau, puis sélectionnez les tables Delta à inclure — typiquement celles de votre couche or.

Les tables ainsi ajoutées sont en mode DirectLake d’emblée : aucune copie n’a lieu, le modèle pointe vers les fichiers Delta de OneLake. Vous pouvez ensuite enrichir ce modèle comme n’importe quel autre : créer des relations en étoile, écrire des mesures DAX, masquer les colonnes techniques. Depuis une version récente, Power BI Desktop permet également d’éditer un modèle DirectLake sur le poste, pour ceux qui préfèrent l’outil de conception. Le modèle obtenu se comporte, côté rapport, exactement comme un modèle Import — à ceci près qu’il n’a jamais copié vos données.

Étape 5 — Choisir entre Direct Lake on OneLake et on SQL

DirectLake existe en deux variantes aux comportements distincts, et le choix a des conséquences concrètes. Direct Lake on OneLake lit directement les fichiers Delta et peut combiner plusieurs sources Fabric ; surtout, il ne bascule jamais en DirectQuery : si les limites de la capacité sont dépassées, l’actualisation échoue plutôt que de se dégrader silencieusement. Direct Lake on SQL passe par le point de terminaison SQL analytique d’une source unique et, lui, peut basculer en DirectQuery quand il ne parvient pas à lire directement une table — par exemple sur une vue SQL.

Ce comportement de repli est à double tranchant. Il évite qu’une requête échoue, mais il masque une dégradation de performance : un rapport peut paraître fonctionner tout en étant secrètement passé en mode lent. Pour un usage exigeant et prévisible, beaucoup d’équipes préfèrent Direct Lake on OneLake, dont l’absence de repli force à bien dimensionner la capacité plutôt qu’à subir des ralentissements invisibles. Quelle que soit la variante, une vérification s’impose, traitée à l’étape 9.

Étape 6 — Construire et publier le rapport

Une fois le modèle prêt, la conception du rapport ne diffère en rien d’un projet classique. Vous glissez les champs dans les visuels, ajoutez des segments, mettez en forme. Toute la compétence acquise sur la modélisation et le DAX s’applique telle quelle ; DirectLake est transparent à ce niveau.

La différence se ressent à l’usage : les rapports répondent vite, et les données reflètent l’état récent du Lakehouse sans cycle d’actualisation lourd. Publiez le rapport dans un espace de travail rattaché à la capacité Fabric. Les utilisateurs y accèdent comme à n’importe quel rapport, sans savoir — ni avoir besoin de savoir — que le modèle ne contient aucune copie de données. Cette transparence pour l’utilisateur final, combinée à l’efficacité côté infrastructure, est précisément ce qui rend DirectLake si attractif pour les déploiements à grande échelle.

Étape 7 — Respecter les limites de la capacité

DirectLake n’est pas sans contraintes, et les ignorer expose à des surprises. Chaque référence de capacité impose des plafonds sur la taille des tables et la mémoire disponible. À titre indicatif, les plus petites capacités (F2 à F8) plafonnent autour de 300 millions de lignes par table et quelques gigaoctets de mémoire, tandis qu’une capacité F64 monte à environ 1,5 milliard de lignes par table et 25 gigaoctets de mémoire, avec une taille de modèle illimitée sur OneLake.

La conséquence pratique est qu’il faut dimensionner la capacité en fonction du volume réel. Avec Direct Lake on OneLake, dépasser un plafond fait échouer l’opération jusqu’à ce que les tables soient optimisées ou la capacité augmentée — un signal franc, sans dégradation cachée. C’est pourquoi optimiser les tables Delta (étape 3) n’est pas un luxe : une table bien rangée tient dans les limites d’une capacité plus modeste, et donc moins coûteuse. À noter aussi : Microsoft consolide son offre en retirant progressivement les anciennes capacités Premium au profit des capacités Fabric, vers lesquelles il faut désormais s’orienter.

Étape 8 — Sécuriser avec la RLS et l’identité fixe

La sécurité au niveau des lignes fonctionne avec DirectLake, mais une subtilité mérite attention. Comme le modèle lit directement les fichiers de OneLake, la question de l’identité utilisée pour accéder aux données se pose. La recommandation officielle est d’employer une identité fixe : une connexion cloud dédiée, dont les droits sont maîtrisés, plutôt que de s’appuyer sur l’identité de chaque lecteur.

Concrètement, on configure une connexion à identité fixe pour le modèle DirectLake, puis on applique la RLS au niveau du modèle sémantique, exactement selon les principes détaillés dans le tutoriel sécurité au niveau des lignes. Le filtrage par utilisateur, via la fonction d’identité, s’opère alors dans le modèle, au-dessus de l’accès aux fichiers. Cette architecture garantit que chaque lecteur ne voit que son périmètre, tout en conservant un accès aux données contrôlé et auditable. Tester ces rôles avant diffusion reste impératif, comme pour tout modèle sécurisé.

Étape 9 — Vérifier qu’on reste bien en DirectLake

Le risque silencieux, en Direct Lake on SQL, est le basculement involontaire en DirectQuery, qui annule les bénéfices de performance sans message visible. Il faut donc vérifier explicitement le mode réellement utilisé. L’outil de référence est l’Analyseur de performances de Power BI, ou des outils externes connectés au modèle, qui révèlent pour chaque visuel le mode d’exécution effectif.

Si vous constatez des requêtes en DirectQuery alors que vous attendiez du DirectLake, remontez à la cause : une table basée sur une vue SQL non matérialisée, un type de données non supporté, ou un dépassement de plafond. Corrigez à la source — matérialiser la vue en table Delta, convertir le type problématique, optimiser ou redimensionner. Cette vérification, menée régulièrement et après chaque évolution du modèle, est la garantie que vos utilisateurs profitent réellement de la vitesse promise. Un rapport DirectLake non surveillé peut se dégrader insidieusement ; un rapport vérifié tient ses promesses.

Erreurs fréquentes

Tutoriels liés

• Créer un Lakehouse dans Microsoft Fabric — la source des tables Delta.
• Transformer des données avec les Notebooks Spark — préparer et optimiser les tables.
• Sécurité au niveau des lignes (RLS) — sécuriser un modèle DirectLake.

Références

• Documentation « Vue d’ensemble de Direct Lake » (Microsoft Learn) : framing, modes OneLake et SQL, comparaison des stockages.
• Guide « Exigences de capacité Fabric » et tableau des plafonds par référence (SKU).
• Documentation « Intégrer la sécurité Direct Lake » et identité fixe.

Questions fréquentes

DirectLake remplace-t-il définitivement l’Import ?
Pas systématiquement. L’Import reste pertinent pour l’analyse en libre-service et les petits modèles agiles. DirectLake brille sur les gros volumes lake-centric, où il évite à la fois la copie et le cycle d’actualisation lourd.

Faut-il rafraîchir un modèle DirectLake ?
Pas au sens d’un rechargement de données. Le framing met simplement à jour les métadonnées vers la dernière version des fichiers Delta, en quelques secondes, et peut se faire automatiquement.

Peut-on utiliser une passerelle avec DirectLake ?
Non. DirectLake fonctionne uniquement avec des connexions cloud vers OneLake ; il ne s’appuie sur aucune passerelle, contrairement à un modèle Import connecté à une source interne.

Pourquoi mon rapport est-il parfois lent malgré DirectLake ?
Souvent à cause de tables Delta mal optimisées ou d’un repli en DirectQuery. Compacter les tables, conserver le V-Order et vérifier le mode d’exécution réel résolvent l’essentiel de ces ralentissements.