Impacts sur les performances et l'architecture globale
Le choix d'un mode de connexion ne se limite pas au fichier Power BI Desktop : il détermine où sont stockées les données, quel moteur calcule, quelle charge pèse sur la source, si une passerelle est nécessaire et comment le modèle pourra être réutilisé. Cette page relie les modes de connexion (fonctionnement détaillé de chaque mode) à l'architecture globale d'une solution Power BI.
Objectifs :
- identifier les couches d'une architecture Power BI et l'endroit où se joue la performance dans chacune ;
- mesurer l'impact de chaque mode (Import, DirectQuery, Live connection, composite, Direct Lake) sur l'ensemble de la chaîne ;
- choisir une architecture type selon le contexte (volume, fraîcheur, gouvernance, nombre d'utilisateurs).
1 | Les couches d'une architecture Power BI
| Couche | Rôle | Éléments Power BI | Où se joue la performance |
| Sources | Stocker les données d'origine | Bases SQL, fichiers, API, SharePoint, entrepôt ou lakehouse Fabric | Index, vues, capacité du serveur, latence réseau |
| Accès | Relier le service Power BI aux sources du réseau interne | Passerelle de données locale (mode standard ou personnel) | Dimensionnement de la machine, emplacement réseau, nombre de sources |
| Préparation | Nettoyer, transformer, mutualiser | Power Query, flux de données (dataflows Gen1 / Gen2), pipelines Fabric | Query folding, actualisation incrémentielle, réutilisation des transformations |
| Modèle sémantique | Organiser les tables, relations, mesures et sécurité | Modèle Import, DirectQuery, composite ou Direct Lake | Schéma en étoile, cardinalité, taille en mémoire, mesures DAX, RLS |
| Restitution | Afficher et interagir | Rapports, tableaux de bord, Excel, applications | Nombre de visuels par page, interactions, filtres de mesure |
| Diffusion et gouvernance | Partager, sécuriser, superviser | Espaces de travail, applications, approbation, traçabilité (lignage), capacité | Nombre d'utilisateurs simultanés, fréquence d'actualisation, capacité Pro / PPU / Fabric |
Un rapport lent n'a pas forcément pour cause le rapport lui-même : la lenteur peut venir de la source (DirectQuery), de la passerelle, du modèle (cardinalité, DAX) ou de la page (trop de visuels). Raisonner par couches permet de localiser le problème avant de l'optimiser.
[Emplacement capture 1 | Service Power BI, espace de travail en vue « Traçabilité » (lineage) montrant de gauche à droite une source de données, une passerelle, un flux de données, un modèle sémantique et deux rapports reliés par des flèches.]
2 | Impact de chaque mode sur l'ensemble de la chaîne
| Critère | Import | DirectQuery | Live connection | Composite | Direct Lake (Fabric) |
| Emplacement des données | En mémoire dans le modèle | Restent dans la source | Dans un modèle publié ou Analysis Services | Mixte, table par table | Fichiers Delta de OneLake chargés en mémoire à la demande |
| Moteur qui calcule | VertiPaq (Power BI) | Base source, via requêtes natives | Modèle distant | VertiPaq et source | VertiPaq |
| Fraîcheur | À la dernière actualisation (8 par jour en Pro, 48 en Premium / PPU) | Quasi temps réel | Celle du modèle distant | Selon le mode de chaque table | Dès la mise à jour des tables Delta (recadrage) |
| Charge sur la source | Pendant l'actualisation seulement | À chaque interaction de chaque utilisateur | Aucune directe | Seulement pour les tables DirectQuery | Aucune sur une base relationnelle |
| Passerelle (source locale) | Pour l'actualisation | Pour chaque requête | Non (modèle Power BI) ou selon le serveur AS | Selon les tables | Non |
| Taille du modèle | Limitée par la licence et la capacité | Métadonnées seulement | Aucune côté rapport | Réduite | Limitée par la capacité Fabric |
| Transformations Power Query | Toutes | Uniquement celles qui se replient (folding) | Aucune | Selon le mode | Faites en amont (lakehouse, entrepôt) |
| Réutilisation du modèle | Bonne si publié séparément | Bonne si publié séparément | Native : c'est le principe | Extension d'un modèle partagé | Bonne, modèle centralisé dans Fabric |
Points chiffrés à retenir pour DirectQuery :
- un visuel devrait répondre en 5 secondes ou moins ; au-delà de 30 secondes, l'expérience est jugée inacceptable ;
- une requête de plus de 4 minutes échoue dans le service ;
- un visuel ne peut pas ramener plus d'un million de lignes depuis une source cloud ;
- avec la RLS, chaque utilisateur génère ses propres requêtes, ce qui multiplie la charge sur la source et sur la passerelle.
Microsoft recommande l'Import par défaut et de ne s'en écarter que pour une contrainte précise : latence, volume, gouvernance, sécurité ou architecture.
3 | Grille de décision
| Besoin principal | Mode à envisager en premier | Pourquoi |
| Interactivité maximale et transformations libres | Import | Moteur en mémoire et toutes les fonctionnalités de modélisation |
| Données récentes en quasi temps réel et historique volumineux | Table hybride (partitions Import et une partition DirectQuery) | Les données chaudes sont lues dans la source, l'historique reste en cache |
| Très gros volumes dans un lakehouse ou un entrepôt Fabric | Direct Lake | Pas d'actualisation planifiée, performances proches de l'Import |
| Croiser plusieurs sources sans tout importer | DirectQuery dans un modèle composite | Les données restent en place |
| Un modèle d'entreprise gouverné existe déjà | Live connection | Réutilise le modèle certifié sans le dupliquer |
| Filtrer la source à la volée selon l'utilisateur | DirectQuery avec paramètres M dynamiques | Moins de données lues dans la source |
| Beaucoup d'utilisateurs simultanés et source lente | Import ou agrégations sur DirectQuery | Les requêtes fréquentes sont servies par le cache |
4 | Architectures types
4.1 | Fichier autonome
Un fichier PBIX contient les requêtes, le modèle et le rapport, publié dans un espace de travail.
- Avantages : simple, rapide à produire, adapté à un besoin individuel ou à un prototype.
- Limites : chaque nouveau rapport recrée son modèle ; les transformations et les mesures sont dupliquées ; plusieurs « versions de la vérité » apparaissent ; chaque modèle sollicite la source et la passerelle lors de son actualisation.
4.2 | Modèle sémantique partagé et rapports connectés (self-service géré)
Un modèle sans rapport est publié dans un espace de travail dédié aux données, approuvé (promu ou certifié) et rendu détectable. Les créateurs de rapports s'y connectent en Live connection depuis leurs propres espaces de travail, avec l'autorisation Générer.
- Avantages : une seule actualisation pour tous les rapports, une seule charge sur la source, des mesures communes, une RLS appliquée une seule fois.
- Limites : toute donnée nécessaire doit se trouver dans le modèle partagé ; une modification du modèle impacte tous les rapports (analyse d'impact à faire avant).
4.3 | Modèle partagé étendu (modèle composite)
Un créateur se connecte au modèle partagé, puis clique sur « Apporter des modifications à ce modèle ». La Live connection devient une connexion DirectQuery vers le modèle distant, et le fichier peut recevoir des tables locales (par exemple des objectifs propres à un service).
- Avantages : personnalisation sans dupliquer le modèle central.
- Limites : les relations entre tables de sources différentes sont des relations limitées, plus coûteuses à évaluer ; des données peuvent circuler d'une source à l'autre (impact sécurité) ; le propriétaire du modèle peut décourager ce type de connexion.
4.4 | Préparation mutualisée avec des flux de données
Les transformations Power Query communes (référentiel client, calendrier, nettoyage) sont déplacées dans des flux de données. Plusieurs modèles sémantiques les consomment comme source.
- Avantages : la logique de préparation n'est écrite qu'une fois ; la source n'est interrogée qu'une fois par le flux, pas par chaque modèle.
- Limites : une couche de plus à actualiser et à orchestrer (le flux avant le modèle) ; nécessite une organisation des espaces de travail (préparation, données nettoyées, données finales) pour les scénarios avancés.
4.5 | Plateforme Fabric (lakehouse ou entrepôt et Direct Lake)
Les données sont chargées et transformées dans un lakehouse ou un entrepôt Fabric (souvent selon une organisation en couches bronze, argent, or). Le modèle sémantique lit directement les tables Delta en mode Direct Lake.
- Avantages : volumes très importants, pas de copie des données dans le modèle, fraîcheur proche du temps réel.
- Limites : nécessite une capacité Fabric ; si une requête dépasse les limites de la capacité ou utilise une fonctionnalité non prise en charge, le modèle peut basculer en DirectQuery (Direct Lake sur SQL) et perdre en performance.
[Emplacement capture 2 | Power BI Desktop, onglet Accueil, ruban montrant le bouton « Apporter des modifications à ce modèle » après une connexion à un modèle sémantique publié, avec la barre d'état en bas indiquant « Connecté en direct ».]
5 | La passerelle, maillon de l'architecture
La passerelle de données locale relie le service Power BI aux sources du réseau de l'entreprise. Elle intervient dans deux cas : l'actualisation des données importées et l'exécution des requêtes DirectQuery ou Live connection vers un serveur local.
- Mode standard ou personnel : en entreprise, préférer le mode standard, installé sur un serveur, partagé et administré ; le mode personnel ne gère que l'actualisation et dépend du poste d'un utilisateur.
- Cluster : installer plusieurs passerelles en cluster pour la haute disponibilité et la répartition de charge.
- Emplacement : placer la passerelle près des sources (même réseau ou même centre de données), pas sur un poste de travail.
- Charge : en Import, la charge est concentrée sur les plages d'actualisation ; en DirectQuery, elle suit l'activité des utilisateurs tout au long de la journée.
- Réduire le trafic : favoriser le query folding, l'actualisation incrémentielle et les agrégations ; limiter l'actualisation automatique des pages.
- Limites : 16 Mo de données non compressées par réponse en DirectQuery ; 1 000 sources de données au maximum par cluster.
[Emplacement capture 3 | Service Power BI, Paramètres > Gérer les connexions et les passerelles, onglet « Passerelles de données locales » montrant un cluster de passerelles avec son état et la liste des connexions associées.]
6 | Leviers d'optimisation par couche
| Couche | Leviers |
| Source | Index sur les colonnes de jointure et de filtre, vues préparées, index columnstore |
| Préparation | Query folding vérifié (« Afficher la requête native »), flux de données pour mutualiser, actualisation incrémentielle |
| Modèle | Schéma en étoile, suppression des colonnes inutiles, réduction de la cardinalité, mode Double (Dual) pour les dimensions d'un modèle composite, tables d'agrégation |
| Rapport | Moins de visuels par page, éviter les filtres de mesure et les TopN en DirectQuery, désactiver les interactions inutiles, analyseur de performances |
| Diffusion | Modèles partagés plutôt que dupliqués, fréquence d'actualisation adaptée, mise en cache des requêtes (capacité Premium / Fabric) |
7 | Mise en pratique
Contexte : une entreprise rennaise de distribution dispose d'une base SQL Server locale (ventes, 40 millions de lignes, mise à jour toutes les heures), d'un fichier Excel d'objectifs par commercial sur SharePoint et de 150 utilisateurs répartis dans 5 services. Chaque service a aujourd'hui son propre fichier PBIX.
- Dessiner l'architecture actuelle en couches et repérer les duplications (transformations, mesures, actualisations, charge sur la passerelle).
- Proposer une architecture cible : quel modèle partagé, quel mode de stockage par table, faut-il un flux de données pour le calendrier et le référentiel produits ?
- Choisir le mode des tables : faits Ventes (Import avec actualisation incrémentielle, table hybride ou DirectQuery ?), dimensions (Import ou Double ?), objectifs Excel (Import).
- Indiquer où se trouve la passerelle, en quel mode, et combien d'actualisations par jour sont nécessaires.
- Le service commercial veut ajouter ses objectifs sans modifier le modèle central : décrire la démarche (modèle composite étendu) et ses limites.
- Justifier chaque choix avec la grille de décision de la partie 3.
Éléments de corrigé :
- un seul modèle sémantique certifié, publié dans un espace de travail « Données », et cinq rapports en Live connection publiés dans les espaces des services ;
- ventes en Import avec actualisation incrémentielle (ou table hybride si la dernière heure doit être visible) ; dimensions en Import ;
- passerelle en mode standard, en cluster, sur un serveur du réseau de la base SQL ;
- objectifs du service commercial ajoutés dans un modèle composite étendu, en gardant à l'esprit les relations limitées.
[Emplacement capture 4 | Schéma d'architecture cible dessiné par le formateur (tableau blanc ou Miro) : base SQL et SharePoint à gauche, passerelle, modèle sémantique certifié au centre, cinq rapports à droite.]
Voir aussi
- Modes de connexion : fonctionnement détaillé de chaque mode, réglages de performance DirectQuery.
- Architecture des données : ingestion, flux de données et bonnes pratiques.
- Modèle sémantique comme source de rapport : procédure de connexion à un modèle publié.
- Optimisations & bonnes pratiques : optimisation du modèle.