TL;DR — En 2026, le choix du mode de stockage Power BI Fabric se résume à trois arbitrages : fraîcheur des données, vitesse de requête, et contraintes IT. Import reste le plus rapide (174 000 unités de durée vs 724 000 pour DirectQuery selon FourMoo 2026). Direct Lake s’impose comme le mode par défaut dès que vos données vivent dans OneLake. DirectQuery ne se justifie que dans des cas extrêmes de legacy ou de résidence de données réglementée.
Si vous développez des modèles sémantiques Power BI dans un contexte bancaire ou assurantiel, le choix du mode de stockage n’est pas un détail technique. Il conditionne la performance perçue par les utilisateurs, le coût de la capacité Fabric, la gouvernance des données et votre capacité à répondre aux exigences réglementaires (BCBS 239, Bâle III, Solvabilité II).
Ce guide est écrit pour les BI Developers qui doivent trancher — souvent seuls, parfois sous pression d’un BI Manager ou d’un Head of Data — entre trois modes dont les frontières ont évolué significativement avec Microsoft Fabric. Pas de théorie creuse : des critères opérationnels, des benchmarks sourcés, un arbre de décision et un cas terrain anonymisé.
Le mode Import charge les données dans le cache VertiPaq du modèle sémantique lors d’un refresh planifié ou incrémental. Les requêtes DAX s’exécutent entièrement en mémoire. Résultat : c’est le mode le plus rapide en lecture, sans exception.
Le benchmark FourMoo de janvier 2026 le confirme sur un modèle identique : Import atteint environ 174 000 unités de durée de requête, contre 247 000 pour Direct Lake et 724 000 pour DirectQuery. L’écart avec DirectQuery est de l’ordre de 4x. (source : fourmoo.com)
Les limites restent les mêmes qu’en 2023 : duplication des données (source + modèle PBIX), dépendance au refresh pour la fraîcheur, et contraintes mémoire sur les très gros volumes. Le refresh incrémental atténue le problème volumétrique mais ne le supprime pas.
En mode DirectQuery, chaque visuel Power BI génère une requête SQL envoyée à la source. Aucune donnée n’est stockée dans Power BI. La fraîcheur est maximale — temps réel strict — mais la latence utilisateur est la plus élevée des trois modes.
Le benchmark FourMoo 2026 positionne DirectQuery à 724 000 unités de durée, soit 4,2x plus lent qu’Import. La consommation de capacité Fabric est faible (la charge est sur la source), mais l’expérience utilisateur en souffre dès que les volumes ou la complexité du modèle augmentent.
En banque-assurance, DirectQuery reste pertinent dans deux situations précises : données très sensibles qu’on refuse de répliquer pour des raisons réglementaires, ou systèmes legacy (core banking, SGBD propriétaires) non intégrables dans Fabric à court terme.
Direct Lake est le mode introduit avec Microsoft Fabric. Il pointe directement sur des tables Delta stockées dans OneLake (lakehouse ou warehouse), sans refresh traditionnel. Le moteur VertiPaq charge les données en mémoire à la volée depuis OneLake.
Conséquences pratiques :
La contrainte principale : Direct Lake nécessite une capacité Fabric (workspace Fabric activé). Il n’est pas disponible sur un workspace Power BI Premium standard. (source : learn.microsoft.com)
| Critère | Import | Direct Lake | DirectQuery |
|---|---|---|---|
| Vitesse de requête | ★★★ (174k unités) | ★★ (247k unités) | ★ (724k unités) |
| Fraîcheur des données | Selon refresh | Quasi temps réel | Temps réel strict |
| Duplication des données | Oui | Non (OneLake) | Non |
| Capacité Fabric requise | Non | Oui | Non |
| Volumétrie (milliards de lignes) | Limitée (incrémental requis) | Optimisé | Possible, perfs délicates |
| Modèle DAX complexe | Idéal | Bon | Risqué |
| Gouvernance / source unique | Non | Oui | Non |
| Coût infrastructure | Moyen (refresh + stockage) | Faible (OneLake) | Variable (source) |
Si oui, Direct Lake est le point de départ naturel. Vous bénéficiez de la fraîcheur quasi temps réel, de l’absence de duplication et de la gouvernance centralisée. Passez à la question 2.
Si non (données dans un SGBD externe, un ERP, un core banking non intégré), vous êtes sur Import ou DirectQuery. Passez à la question 3.
Direct Lake couvre la quasi-totalité des besoins analytiques en banque-assurance. Si votre cas d’usage tolère une latence de quelques minutes (reporting de gestion, pilotage risque, tableaux de bord ALM), Direct Lake suffit.
Si vous avez un besoin de temps réel strict sur une source déjà dans Fabric, envisagez un pipeline de streaming vers OneLake + Direct Lake. Ce pattern est plus robuste que DirectQuery sur une source externe.
Certaines données (données personnelles de clients, données de crédit, données de marché sous licence) peuvent être soumises à des contraintes de résidence ou de non-réplication. Dans ce cas, DirectQuery sur la source d’origine peut être la seule option conforme.
Attention : ce cas est moins fréquent qu’on ne le croit. La plupart des contraintes réglementaires françaises (RGPD, ACPR) portent sur la sécurité et la traçabilité, pas sur l’interdiction de répliquer dans un environnement sécurisé Fabric.
Import est le mode le plus permissif pour les modèles DAX lourds : agrégations complexes, rôles de sécurité dynamiques (RLS), relations many-to-many, tables de calcul. Direct Lake supporte la majorité de ces patterns mais présente quelques limitations spécifiques documentées par Microsoft.
Si votre modèle inclut des tables calculées ou des colonnes calculées complexes, testez Direct Lake en environnement de recette avant de valider l’architecture.
Si votre organisation n’a pas encore migré vers Fabric (workspace Power BI Premium classique), Direct Lake n’est pas disponible. Dans ce cas, Import est le choix par défaut pour les performances, DirectQuery pour les cas de fraîcheur ou de non-réplication.
Une banque régionale française (environ 2 000 collaborateurs, réseau d’agences, activités de crédit et d’épargne) a migré son reporting de gestion vers Microsoft Fabric en 2025. Le contexte initial : 14 modèles Import distincts, des refreshs planifiés toutes les 4 heures, des incidents réguliers de timeout sur les gros modèles (portefeuille de crédit, reporting COREP).
Architecture retenue après audit :
Résultats mesurés à 6 mois :
Ce cas illustre le pattern le plus courant en banque française : un mix Direct Lake + Import, avec DirectQuery en mode transitoire sur les systèmes legacy.
Le temps réel est souvent une fausse exigence. Interrogez vos utilisateurs : ont-ils réellement besoin de données à la seconde, ou à la minute, ou à l’heure ? Dans 80 % des cas en reporting bancaire, une fraîcheur de 15 à 30 minutes est suffisante. Direct Lake couvre ce besoin sans la dégradation de performance de DirectQuery.
Direct Lake ne supporte pas toutes les fonctionnalités d’Import. Les tables calculées, certaines relations complexes et quelques fonctions DAX peuvent forcer un fallback automatique vers DirectQuery (le mode “fallback” de Direct Lake). Ce fallback est silencieux par défaut : vos performances se dégradent sans alerte visible. Activez les logs de diagnostic Fabric pour le détecter.
Direct Lake consomme la capacité interactive Fabric. Le benchmark FourMoo 2026 montre que la plupart des modèles Direct Lake dépassent 80 % d’utilisation de capacité interactive. Dimensionnez votre SKU Fabric en conséquence, surtout si vous avez de nombreux utilisateurs simultanés.
Direct Lake n’a de valeur que si OneLake est bien gouverné. Si vos tables Delta sont mal partitionnées, non optimisées (V-Order désactivé), ou alimentées par des pipelines instables, les performances de Direct Lake seront décevantes. L’optimisation V-Order des tables Delta est documentée par Microsoft comme un prérequis pour des performances proches d’Import.
Si vous hésitez encore sur l’architecture à retenir pour votre contexte spécifique — volumétrie, contraintes réglementaires, état de votre capacité Fabric — un audit ciblé de 2 à 5 jours permet de trancher avec des données concrètes issues de votre environnement.
Audit BI Maturity — 2 à 5 jours, 3 000 à 5 000 € : analyse de votre architecture sémantique actuelle, recommandation de mode de stockage par domaine métier, feuille de route de migration Fabric. Accéder à l’audit →
Trois hypothèses de travail, explicites :
Hypothèse 1 — Fabric est votre cible à 18 mois. Dans ce cas, investissez dès maintenant dans l’architecture OneLake et préparez vos tables Delta. Direct Lake sera votre mode par défaut pour 70 à 80 % de vos modèles analytiques.
Hypothèse 2 — Vous avez des modèles de clôture réglementaire figés. Import incrémental reste le meilleur choix : vitesse maximale, modèles DAX sans contrainte, données de clôture par nature non temps réel.
Hypothèse 3 — Vous avez des systèmes legacy non intégrables à court terme. DirectQuery est acceptable en transitoire, à condition de documenter la dégradation de performance et de fixer une date de migration.
Le mix gagnant en banque-assurance France en 2026 : Direct Lake pour l’analytique courant + Import pour le réglementaire + DirectQuery en transitoire legacy. Ce n’est pas une architecture par défaut : c’est le résultat d’une analyse domaine par domaine, modèle par modèle.
Direct Lake remplace-t-il définitivement Import en 2026 ?
Non. Import reste plus rapide en requête (174 000 vs 247 000 unités de durée selon FourMoo 2026) et plus permissif sur les modèles DAX complexes. Direct Lake s’impose comme mode par défaut pour les données dans OneLake, mais Import garde sa place sur les modèles de clôture réglementaire et les cas où la vitesse prime sur tout.
Peut-on utiliser Direct Lake sans capacité Fabric ?
Non. Direct Lake nécessite un workspace Fabric activé avec une capacité Fabric (SKU F ou équivalent). Il n’est pas disponible sur un workspace Power BI Premium classique (P SKU). (source : learn.microsoft.com)
Qu’est-ce que le fallback DirectQuery en Direct Lake et comment le détecter ?
Quand Direct Lake rencontre une fonctionnalité non supportée (table calculée, relation non compatible), il bascule automatiquement en mode DirectQuery pour la requête concernée. Ce fallback est silencieux. Pour le détecter, activez les traces de diagnostic dans Fabric et surveillez les requêtes DAX générées via Performance Analyzer dans Power BI Desktop.
DirectQuery est-il compatible avec les exigences RGPD en France ?
DirectQuery ne réplique pas les données dans Power BI, ce qui peut sembler favorable au RGPD. Mais la conformité RGPD dépend de la sécurisation de la source, pas du mode de stockage Power BI. Un modèle Import dans un tenant Microsoft 365 hébergé en France (région EU) est tout aussi conforme qu’un DirectQuery, à condition que les contrôles d’accès et la traçabilité soient en place.
Comment choisir le SKU Fabric pour Direct Lake avec 500 utilisateurs simultanés ?
Le benchmark FourMoo 2026 montre que Direct Lake consomme plus de 80 % de capacité interactive sur la plupart des modèles. Pour 500 utilisateurs simultanés, commencez par un SKU F64 minimum et montez à F128 si vous avez plus de 10 modèles Direct Lake actifs. Mesurez la consommation réelle avec le Fabric Capacity Metrics App avant de dimensionner définitivement.
Peut-on mixer Direct Lake et Import dans le même workspace Fabric ?
Oui. Les modes de stockage sont définis au niveau du modèle sémantique, pas du workspace. Vous pouvez avoir des modèles Direct Lake, Import et DirectQuery dans le même workspace Fabric. C’est d’ailleurs le pattern recommandé pour les environnements bancaires avec des domaines métier hétérogènes.
Direct Lake supporte-t-il la sécurité au niveau des lignes (RLS) ?
Oui, Direct Lake supporte le RLS (Row Level Security) et l’OLS (Object Level Security). Les rôles de sécurité dynamiques basés sur USERNAME() ou USERPRINCIPALNAME() fonctionnent. Certaines configurations RLS très complexes peuvent déclencher un fallback DirectQuery : testez systématiquement en recette avec des profils utilisateurs réels.