Le meilleur mode dépend surtout du volume, du niveau de détail attendu et de la latence acceptable. Direct Lake sur OneLake ressort souvent devant, mais les gros modèles gagnent parfois avec un modèle composite bien pensé. Je vous montre comment arbitrer sans partir dans le flou.
Quel est le vrai choix à faire ?
Pour moi, le vrai choix n’est pas “Import ou DirectQuery”. C’est trop court. Le vrai choix, c’est l’architecture du modèle sémantique Power BI autour de vos données Azure Databricks. Le modèle sémantique, c’est la couche qui porte les tables, les relations, les mesures DAX et la logique métier utilisée par vos rapports.
Quand je travaille avec Databricks, je regarde surtout où vit la donnée, comment elle bouge, qui interroge quoi, et à quelle vitesse les utilisateurs attendent une réponse. C’est là que les modes de stockage deviennent intéressants.
- Import Charge les données dans Power BI. Une fois chargé, c’est souvent très rapide et très robuste. Ça marche très bien quand le volume est maîtrisé et que les rafraîchissements sont bien pensés.
- DirectQuery Garde les données côté source, ici Databricks. Power BI envoie des requêtes au moteur à chaque interaction. C’est pratique pour éviter de dupliquer, mais la performance dépend beaucoup du backend, des requêtes générées et du modèle.
- Direct Lake sur OneLake Devient très intéressant quand les données Delta sont disponibles dans OneLake. Power BI peut lire les tables Delta sans import classique dans le modèle, et sans envoyer chaque requête au moteur source comme en DirectQuery.
- Modèle composite Mélange plusieurs modes dans le même modèle. Par exemple certaines tables en Import, d’autres en DirectQuery. C’est souvent là que les architectures sérieuses commencent.
- Tables Dual Peuvent se comporter comme Import ou DirectQuery selon le contexte de requête. C’est utile pour des dimensions partagées, mais il faut rester propre dans la modélisation.
- Agrégations Import Gardent des résumés rapides en Import, tout en laissant le détail en DirectQuery. J’ai vu ça sauver des rapports qui tapaient trop fort dans Databricks pour des analyses très simples.
FireDucks accélère-t-il pandas sur de gros datasets ?
Microsoft documente Direct Lake comme un mode de stockage lié aux modèles sémantiques Fabric, avec lecture de tables Delta dans OneLake. C’est une vraie évolution, surtout si votre plateforme est déjà alignée avec Fabric et Delta.
Comme on dit à Brive, un bon plan de marquage vaut mieux qu’un bon reporting ! Si besoin, consultez moi - faites appel à un super consultant en tracking client et server side.
Mais ça ne rend pas Import ou DirectQuery obsolètes. Import reste excellent quand on veut de la vitesse et de la stabilité. DirectQuery reste pertinent quand la donnée doit rester côté source, avec une fraîcheur forte. Le piège, c’est de choisir un mode parce qu’il est à la mode.
Le vrai sujet arrive juste après. La performance réelle. Parce que sur le papier, tout peut se défendre. Dans un rapport utilisé tous les matins par 200 personnes, le choix devient beaucoup moins théorique.
Pourquoi Direct Lake ressort souvent gagnant ?
Comment le Big Data aide un prêt Non-QM immobilier ?
Direct Lake ressort souvent gagnant parce qu’il évite une partie des compromis habituels entre Import et DirectQuery quand les données sont dans OneLake.
Avec Import, Power BI copie les données dans son modèle. C’est très rapide à l’usage, mais il faut rafraîchir, stocker une deuxième version, gérer les fenêtres de chargement. Avec DirectQuery, Power BI interroge la source à chaque interaction ou presque. C’est plus frais, oui, mais chaque filtre, chaque visuel, chaque clic peut devenir une requête envoyée à Databricks.
Direct Lake change la logique. Le moteur Power BI lit les données Delta exposées dans OneLake, sans passer par une duplication classique complète comme en Import, et sans dépendre autant de requêtes DirectQuery à chaque mouvement dans le rapport. Delta, pour faire simple, c’est un format de table très utilisé dans les lakehouses, avec des fichiers Parquet et un journal de transactions qui garde l’historique et la cohérence des données.
Comment optimiser la logistique inverse en e-commerce ?
Pour un rapport Power BI connecté à des données Azure Databricks, ça veut dire quelque chose de très concret : si vos tables Databricks sont rendues accessibles dans Microsoft Fabric via OneLake, Power BI peut travailler plus naturellement sur ces données, avec une expérience souvent plus proche de l’Import côté fluidité, tout en évitant une recopie massive dans un dataset séparé.
Les tests du livre blanc vont dans ce sens. Direct Lake sur OneLake obtient les meilleurs résultats dans la majorité des cas étudiés. C’est important, parce que ça confirme ce que je vois aussi sur le terrain : quand l’architecture est propre, Direct Lake donne souvent le meilleur équilibre entre performance perçue, fraîcheur et simplicité.
Mais attention, ça ne veut pas dire meilleur partout, tout le temps. Direct Lake a des limites. La taille du modèle compte. Les fonctionnalités DAX utilisées comptent aussi. DAX, c’est le langage de calcul de Power BI. La capacité Fabric joue également, parce que c’est elle qui porte une partie de l’exécution. Et Microsoft documente des cas de fallback, c’est-à-dire des moments où le moteur ne peut pas répondre en Direct Lake et bascule vers un autre mode, souvent moins optimal.
Quelles bibliothèques Python pour nettoyer vos données ?
Chez les clients, le piège classique, je le vois souvent : on teste Direct Lake sur un rapport propre, bien modélisé, avec peu de dette technique, puis on généralise trop vite à tout le patrimoine décisionnel. Et là, on découvre les vieux modèles, les mesures DAX tordues, les tables énormes, les relations ambiguës. Direct Lake reste très solide, mais il ne répare pas une mauvaise modélisation.
| Mode | Performance perçue | Fraîcheur des données | Dépendance au moteur source | Complexité |
| Direct Lake | Souvent très bonne, proche de l’Import dans beaucoup de cas | Bonne, car lecture des données dans OneLake | Faible à moyenne, sauf cas de fallback | Moyenne, dépend de Fabric et du modèle |
| Import | Très bonne après chargement | Dépend des rafraîchissements planifiés | Faible pendant la consultation | Moyenne, surtout sur les refresh et la duplication |
| DirectQuery | Variable, très dépendante des requêtes et de Databricks | Très bonne, données interrogées à la demande | Forte, chaque interaction peut solliciter la source | Élevée dès que les rapports deviennent complexes |
Quand choisir un modèle composite ?
Le modèle composite devient préférable quand les volumes augmentent et que tout mettre dans un seul mode crée soit des lenteurs, soit des contraintes de rafraîchissement. C’est typiquement le cas avec Databricks, quand la table principale grossit vite, mais que les utilisateurs attendent quand même des rapports Power BI réactifs.
Le design que je recommande le plus souvent est assez simple : table de faits en DirectQuery, tables de dimensions en mode Dual, et agrégations en Import. Ce n’est pas une règle magique, mais c’est souvent le meilleur compromis entre fraîcheur, performance et coût de maintenance.
La logique est assez naturelle :
- La table de faits contient souvent le plus gros volume : ventes, événements, transactions, logs, clics. La laisser en DirectQuery évite de charger des centaines de millions de lignes dans Power BI.
- Les dimensions comme clients, produits, dates ou régions sont plus petites. En mode Dual, Power BI peut les utiliser comme de l’Import quand la requête reste simple, ou les faire participer au DirectQuery quand la requête touche la table de faits.
- Les agrégations en Import répondent très vite aux analyses résumées. Et soyons honnêtes, dans beaucoup de dashboards, les utilisateurs passent leur temps sur du chiffre par jour, par produit, par région, pas sur la ligne de transaction brute.
Un exemple concret : vous avez une table de ventes dans Databricks avec toutes les lignes de transaction. Vous gardez cette table en DirectQuery. Vous mettez les tables clients, produits et dates en Dual. Puis vous créez une table d’agrégation par jour, produit et région en Import. Le dashboard répond vite sur les vues globales, et Power BI descend vers Databricks seulement quand l’analyse demande le détail.
Microsoft documente bien ces mécanismes : les modèles composites, le mode Dual et les agrégations permettent de mixer plusieurs comportements de stockage dans un même modèle sémantique Power BI. C’est puissant. Mais c’est aussi plus exigeant. J’ai vu des modèles composites très rapides, et d’autres impossibles à maintenir parce que les relations, les filtres et les agrégations n’avaient pas été testés sérieusement.
| Type de table | Mode recommandé | Raison |
| Table de faits | DirectQuery | Évite de charger le plus gros volume dans Power BI et garde l’accès aux données fraîches dans Databricks. |
| Tables de dimensions | Dual | Peuvent se comporter comme de l’Import pour les requêtes simples ou accompagner le DirectQuery avec la table de faits. |
| Tables d’agrégations | Import | Accélèrent les analyses résumées les plus fréquentes dans les dashboards. |
Comment tester avant de trancher ?
Je ne choisis jamais un mode de stockage Power BI pour Databricks juste parce qu’un livre blanc, un benchmark ou une reco Microsoft dit que c’est “le bon choix”. Je m’en sers comme point de départ, pas comme décision finale.
Le livre blanc dont on parle se concentre surtout sur la performance. C’est utile, vraiment. Mais il exclut volontairement le coût et la gouvernance. Donc avant de standardiser Direct Lake, Import, DirectQuery ou un modèle composite, l’équipe doit compléter l’analyse avec son contexte réel.
Ma méthode est simple, mais pas mécanique. Je prends quelques rapports représentatifs, pas les plus beaux en démo, les vrais rapports utilisés par les métiers. Puis je mesure ce qui compte vraiment :
- Le temps d’ouverture du rapport.
- La réactivité quand on clique sur des filtres ou des segments.
- Le comportement des visuels lourds, souvent les matrices bien chargées ou les graphes avec beaucoup de catégories.
- Les pics de concurrence, quand 50 ou 200 personnes ouvrent le même rapport le lundi matin.
- La fraîcheur attendue des données, parce qu’un besoin à J+1 et un besoin à la minute ne racontent pas la même histoire.
- La taille des tables, surtout les tables de faits détaillées.
- Le comportement des requêtes générées vers Databricks, parce qu’un visuel Power BI peut parfois produire une requête SQL assez violente.
Je vérifie aussi les contraintes autour. Fabric, Power BI, Databricks, OneLake, les politiques de sécurité, le coût des capacités, les règles de gouvernance des données. Ce n’était pas forcément l’objet central des tests de performance, mais dans une vraie architecture, ça compte autant que les secondes gagnées sur un visuel.
Mon retour terrain est assez constant. Le bon arbitrage n’est presque jamais un dogme global. C’est rarement “On fait tout en Direct Lake” ou “On reste tout en Import”. Le plus souvent, je finis avec une matrice par famille de cas d’usage. C’est moins sexy, mais beaucoup plus robuste.
| Cas d’usage | Mode à tester en priorité |
| Petit ou moyen modèle très consulté | Direct Lake |
| Très gros faits détaillés | Composite |
| Besoin de simplicité et données stables | Import |
| Besoin de temps réel source | DirectQuery, avec prudence |
Et si le bon choix était surtout celui que vous testez vraiment ?
Je retiens une chose simple : pour reporting Power BI sur Azure Databricks, Direct Lake sur OneLake mérite clairement d’être testé en premier, parce qu’il ressort très souvent comme le meilleur compromis performance et architecture. Mais dès que les volumes montent, le modèle composite reprend la main avec une table de faits en DirectQuery, des dimensions en Dual et des agrégations en Import.
Le piège, c’est de choisir un mode comme une règle universelle. Il faut tester sur vos rapports, vos volumes, vos contraintes de coût et de gouvernance. Le bénéfice pour vous : un modèle plus rapide, plus stable, et surtout adapté à votre usage réel.
FAQ
- Quel est le meilleur mode de stockage Power BI avec Azure Databricks ?
Direct Lake sur OneLake ressort comme le meilleur choix dans la majorité des tests évoqués, surtout quand les données sont disponibles dans Microsoft Fabric. Mais ce n’est pas une règle absolue. Sur de gros volumes, un modèle composite peut devenir plus performant et plus maîtrisable. - Direct Lake remplace-t-il Import et DirectQuery ?
Non. Direct Lake apporte une option très intéressante entre Import et DirectQuery, mais Import reste pertinent pour des modèles simples, stables et rapides une fois chargés. DirectQuery reste utile quand on veut interroger la source directement, avec les limites de performance que ça implique. - Quand faut-il utiliser un modèle composite dans Power BI ?
Je le privilégie quand les tables de faits deviennent trop volumineuses pour un modèle simple. Le montage recommandé ici est clair : faits en DirectQuery, dimensions en Dual, agrégations en Import. Ça permet de garder du détail tout en accélérant les vues agrégées. - Pourquoi mettre les dimensions en mode Dual ?
Le mode Dual permet aux dimensions de se comporter comme de l’Import ou du DirectQuery selon le contexte de la requête. Dans un modèle composite, c’est pratique pour éviter de ralentir inutilement les analyses tout en gardant une cohérence avec la table de faits en DirectQuery. - Faut-il décider seulement sur la performance ?
Non. La performance est centrale, mais elle ne suffit pas. Il faut aussi regarder le coût, la gouvernance, la sécurité, la fraîcheur des données, les capacités disponibles et les usages réels des rapports. Le bon choix sort rarement d’une fiche produit, il sort de tests propres sur votre contexte.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes data, marketing et IT sur des sujets très concrets : fiabiliser les données, industrialiser les reporting, automatiser les flux et rendre les outils vraiment exploitables.
Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer votre architecture Power BI, Databricks ou Fabric, je peux vous aider. Contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.