Optimisation des performances Power BI : DAX, modèles et requêtes

Un rapport Power BI dont le chargement prend 15 secondes est un rapport que les utilisateurs cessent d'utiliser. La performance n'est pas une subtilité technique : c'est la différence entre l'adoption et l'abandon de la BI. Chaque seconde de temps de chargement d’un rapport réduit considérablement l’engagement des utilisateurs. Les recherches montrent systématiquement que les tableaux de bord interactifs (temps de chargement inférieur à 3 secondes) reçoivent 4 à 5 fois plus de vues que les tableaux de bord lents (plus de 10 secondes), et que les utilisateurs confrontés à une lenteur constante reviennent aux processus manuels dans les 30 jours.

La bonne nouvelle est que les problèmes de performances de Power BI peuvent presque toujours être résolus. D'après notre expérience dans l'optimisation de centaines d'environnements Power BI, 90 % des problèmes de performances sont dus à l'une des cinq causes profondes : mesures DAX inefficaces, modèles de données surdimensionnés, mauvaise conception des relations, utilisation inappropriée de DirectQuery ou capacité insuffisante pour la charge de travail. Ce guide propose une approche systématique pour diagnostiquer et résoudre chacun de ces problèmes.

Si votre environnement Power BI rencontre des problèmes de performances que votre équipe ne peut pas résoudre en interne, nos services d'optimisation des performances Power BI fournissent une analyse pratique et des mesures correctives.

Points clés à retenir

• L'analyseur de performances dans Power BI Desktop identifie les visuels et les requêtes qui sont lents --- commencez toujours ici avant d'optimiser
• DAX Studio révèle si les requêtes lentes sont goulots d'étranglement dans le moteur de stockage (analyse des données) ou le moteur de formule (calcul) --- le correctif diffère considérablement
• Les erreurs de performances DAX les plus courantes sont l'imbrication CALCULATE inutile, l'utilisation d'itérateurs là où les agrégateurs suffisent et la matérialisation de grandes tables intermédiaires.
• La taille du modèle a un impact direct sur les performances : la suppression des colonnes inutilisées, la réduction de la cardinalité et l'optimisation des types de données peuvent réduire les modèles de 40 à 70 %
• Les tables d'agrégation offrent des performances de requête 10 à 100 fois supérieures pour les grands ensembles de données grâce au pré-calcul des données récapitulatives.
• DirectQuery est 10 à 100 fois plus lent que le mode Importation pour les rapports interactifs --- utilisez-le uniquement lorsque les exigences de fraîcheur des données l'exigent réellement
• L'analyse comparative avant/après avec des métriques documentées est essentielle pour prouver l'impact de l'optimisation et prévenir la régression.

---

Outils et méthodologie de diagnostic

Analyseur de performances

Performance Analyzer est l’outil de diagnostic intégré de Power BI Desktop. Il enregistre le temps d'exécution de chaque requête générée par chaque visuel sur une page de rapport, décomposant le temps en trois composants :

Comment utiliser l'Analyseur de performances :

1. Ouvrez votre rapport dans Power BI Desktop.
2. Accédez à Affichage > Analyseur de performances.
3. Cliquez sur « Démarrer l'enregistrement ».
4. Interagissez avec le rapport (modifiez les filtres, parcourez les pages, appliquez des slicers).
5. Cliquez sur « Arrêter ».
6. Consultez les résultats, triés par durée totale.

Interprétation des résultats :

• Si le temps de requête DAX domine, le problème réside dans vos mesures ou votre modèle. Utilisez DAX Studio pour une analyse plus approfondie.
• Si le temps d'affichage visuel domine, le problème réside dans la configuration visuelle (trop de points de données, un formatage conditionnel complexe ou un visuel personnalisé peu performant).
• Si le temps « Autre » domine, le problème vient de l'infrastructure (latence du réseau pour DirectQuery, goulots d'étranglement de la passerelle ou limitation de capacité).

L'étape critique que la plupart des gens ignorent : Copiez la requête DAX depuis Performance Analyzer (clic droit > "Copier la requête") et collez-la dans DAX Studio. Performance Analyzer vous indique quel visuel est lent. DAX Studio vous explique pourquoi.

### Studio DAX

DAX Studio est un outil open source gratuit qui fournit des fonctionnalités de diagnostic approfondies pour le moteur Analysis Services sous-jacent à Power BI. Il s’agit de l’outil le plus important de la boîte à outils de tout ingénieur de performances Power BI.

Principales fonctionnalités de DAX Studio :

Horaires du serveur : affiche la répartition entre l'heure des requêtes du moteur de stockage (SE) et du moteur de formule (FE).

• Les requêtes du moteur de stockage (SE) sont des analyses de données exécutées sur le stockage en colonnes (moteur VertiPaq). Ils sont hautement parallélisés et rapides. Les requêtes SE apparaissent sous forme d'instructions xmSQL dans la trace.
• Les opérations Formula Engine (FE) sont des calculs monothread effectués sur les résultats des requêtes SE. Les opérations FE constituent le principal goulot d’étranglement dans la plupart des mesures lentes du DAX.

L'objectif d'optimisation est de transférer autant de travail que possible dans le moteur de stockage et de minimiser les opérations du moteur de formule.

Plans de requête : DAX Studio peut afficher des plans de requête logiques et physiques, montrant exactement comment le moteur traite votre mesure. Pour les utilisateurs avancés, les plans de requête révèlent des opportunités d'optimisation invisibles dans les seules données de synchronisation.

VertiPaq Analyzer : analyse l'intégralité du modèle de données et signale la taille des colonnes, la cardinalité, le type d'encodage et la taille du dictionnaire pour chaque colonne de chaque table. C'est ainsi que vous identifiez les colonnes et les tableaux surdimensionnés qui gonflent votre modèle.

Méthodologie d'optimisation systématique

1. Référence : Enregistrez les temps de chargement pour chaque page à l'aide de Performance Analyser. Taille du modèle de document (Fichier > Informations > Réduire la taille du fichier > Analyser). Enregistrez les mesures de capacité si vous êtes sur Premium/Fabric.

2. Identifier : Triez les résultats de Performance Analyser par durée totale. Concentrez-vous sur les 5 visuels les plus lents : ceux-ci ont le plus d'impact lorsqu'ils sont optimisés.

3. Diagnostiquer : Copiez chaque requête lente dans DAX Studio. Analysez le temps SE vs FE. Identifiez les modèles DAX spécifiques provoquant des goulots d'étranglement FE.

4. Optimiser : Appliquez des correctifs ciblés (expliqués en détail ci-dessous). Testez chaque changement individuellement pour mesurer son impact.

5. Valider : Réexécutez Performance Analyzer et comparez-le à la ligne de base. Documentez l’amélioration pour chaque optimisation.

6. Surveiller : configurez une surveillance continue des performances (mesures de capacité, problèmes signalés par les utilisateurs, vérifications périodiques de l'analyseur de performances) pour éviter toute régression.

---

Modèles et correctifs DAX lents

Modèle 1 : Imbrication CALCULER inutile

Le problème :

Bad Measure =
CALCULATE(
    CALCULATE(
        SUM(Sales[Amount]),
        FILTER(ALL(Products), Products[Category] = "Electronics")
    ),
    Date[Year] = 2025
)

Les instructions CALCULATE imbriquées n'ajoutent pas de puissance --- elles ajoutent de la confusion et parfois une surcharge de performances. Chaque CALCULATE crée un nouveau contexte de filtre, et leur imbrication peut produire des résultats inattendus et forcer le moteur de formule à effectuer des transitions de contexte redondantes.

Le correctif :

Good Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics",
    Date[Year] = 2025
)

Combinez les arguments de filtre en un seul CALCULATE. Plusieurs arguments de filtre sont appliqués simultanément (intersection). Cela produit le même résultat avec une exécution plus propre.

Modèle 2 : FILTRER avec TOUS au lieu de filtres de colonne directs

Le problème :

Slow Measure =
CALCULATE(
    SUM(Sales[Amount]),
    FILTER(ALL(Products), Products[Category] = "Electronics")
)

FILTER(ALL(Products), ...) force le moteur à matérialiser l'intégralité de la table Products dans le moteur de formule, puis à parcourir chaque ligne pour appliquer le filtre. Pour une table comportant des millions de lignes, c'est extrêmement lent.

Le correctif :

Fast Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics"
)

Les filtres de colonne directs dans CALCULATE sont résolus dans le moteur de stockage, ce qui est plusieurs fois plus rapide. Utilisez FILTER uniquement lorsque vous devez appliquer une condition complexe qui ne peut pas être exprimée sous la forme d'une simple comparaison de colonnes (par exemple, filtrage sur une valeur de mesure ou une condition impliquant plusieurs colonnes).

Règle générale : Si votre condition FILTER fait référence à une seule colonne avec une comparaison simple, remplacez-la par un argument de filtre CALCULATE direct. Réservez FILTER pour les conditions véritablement complexes.

Modèle 3 : itérateurs là où les agrégateurs suffisent

Le problème :

Slow Total = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

SUMX parcourt chaque ligne de la table Sales, évaluant l'expression de chaque ligne dans le moteur de formule. Pour une table Sales de 10 millions de lignes, cela signifie 10 millions d'opérations FE.

Le correctif :

Si le calcul est une simple multiplication de deux colonnes, pré-calculez-le comme une colonne calculée :

-- Add calculated column: Sales[LineTotal] = Sales[Quantity] * Sales[UnitPrice]
-- Then use aggregator:
Fast Total = SUM(Sales[LineTotal])

SUM fonctionne dans le moteur de stockage, qui traite les données en colonnes par lots hautement optimisés. La colonne calculée augmente la taille du modèle mais réduit considérablement le temps de requête.

Quand conserver SUMX : Utilisez SUMX lorsque vous avez besoin d'une logique conditionnelle au niveau des lignes (par exemple, SUMX(Sales, IF(Sales[Type] = "Return", -Sales[Amount], Sales[Amount]))) ou lors d'une itération sur une petite table (tables de dimensions comportant des milliers, et non des millions, de lignes).

Modèle 4 : Grandes tables intermédiaires

Le problème :

Slow Measure =
SUMX(
    SUMMARIZE(Sales, Products[Category], Date[Month]),
    [Complex Calculation]
)

SUMMARIZE crée une table intermédiaire dans le moteur de formule. Si la combinaison de Catégorie et Mois produit 10 000 lignes et que [Calcul complexe] déclenche des requêtes SE supplémentaires pour chaque ligne, le résultat est plus de 10 000 requêtes --- un modèle de performances catastrophique connu sous le nom de « tempêtes de requêtes SE ».

Le correctif :

Fast Measure =
VAR SalesTable =
    ADDCOLUMNS(
        SUMMARIZE(Sales, Products[Category], Date[Month]),
        "@SubTotal", CALCULATE(SUM(Sales[Amount]))
    )
RETURN
    SUMX(SalesTable, [@SubTotal] * [SomeMultiplier])

En matérialisant le sous-total dans ADDCOLUMNS (qui utilise efficacement la transition de contexte), les références ultérieures à @SubTotal ne déclenchent pas de requêtes SE supplémentaires. Les variables (VAR) garantissent également que la table n'est évaluée qu'une seule fois, même si elle est référencée plusieurs fois.

Modèle 5 : Impact sur les performances de sécurité au niveau des lignes

Le problème :

RLS avec des expressions DAX complexes évalue chaque requête, ajoutant une surcharge qui s'aggrave entre les visuels. Une règle RLS mal écrite peut doubler ou tripler les temps de chargement des rapports.

Les tueurs de performances RLS courants :

• LOOKUPVALUE dans les filtres RLS (force l'évaluation FE par ligne)
• Opérateurs CONTAINS ou IN sur les grandes tables
• Règles RLS référençant des mesures au lieu de simples filtres de colonnes
• RLS multi-tables avec problèmes de direction de filtre croisé

Le correctif :

• Utilisez des comparaisons de colonnes simples : [TenantId] = USERNAME() ou [Region] IN VALUES(SecurityTable[Region])
• Pré-calculer les mappages de sécurité dans une table de dimensions dédiée avec des relations directes
• Évitez les mesures dans les règles RLS --- utilisez uniquement des filtres au niveau des colonnes
• Testez les performances RLS avec DAX Studio en comparant les temps de requête avec et sans RLS actif

---

Réduction de la taille du modèle

Pourquoi la taille du modèle est importante

Le mode Importation Power BI stocke les données dans un format de colonnes hautement compressé (moteur VertiPaq). La taille du modèle a un impact direct :

• Consommation de mémoire : Le modèle entier doit tenir en mémoire. Sur Premium/Fabric, les modèles plus grands consomment plus de capacité et peuvent déclencher une limitation de la pression de la mémoire.
• Durée d'actualisation : Les modèles plus volumineux prennent plus de temps à s'actualiser, car davantage de données doivent être traitées, compressées et chargées.
• Performances des requêtes : Les modèles plus grands produisent des analyses plus volumineuses, ce qui augmente le temps de requête, même pour un DAX bien optimisé.
• Taille du fichier : Les fichiers PBIX contenant des modèles volumineux sont lents à enregistrer, à publier et à télécharger.

Identification des contributeurs à la taille du modèle

Utilisez VertiPaq Analyzer de DAX Studio (Avancé > Afficher les métriques) pour identifier les tables et colonnes les plus volumineuses :

Techniques d'optimisation

Supprimer les colonnes inutilisées :

L’optimisation à impact le plus élevé. Chaque colonne de votre modèle consomme de la mémoire, qu'elle soit utilisée ou non. Auditez votre modèle et supprimez toute colonne non référencée dans un visuel, une mesure, une relation ou une règle RLS.

Impact typique : réduction de la taille du modèle de 20 à 40 %.

Réduire la cardinalité des colonnes de texte :

Les colonnes de texte comportant de nombreuses valeurs uniques (descriptions, adresses, notes) sont mal compressées. Si la colonne est nécessaire uniquement à des fins d'affichage (et non de filtrage ou de regroupement), envisagez de la déplacer vers un tableau détaillé uniquement ou de tronquer les valeurs longues.

Pour les colonnes utilisées dans le regroupement/filtrage, envisagez le regroupement : au lieu de 50 000 noms de produits uniques, regroupez-les en 500 catégories de produits avec une table de recherche distincte pour les détails des produits individuels.

Optimiser les types de données :

• Utilisez Integer au lieu de Decimal lorsque les valeurs sont des nombres entiers (économisez 50 % par colonne)
• Utilisez Date au lieu de DateTime lorsque l'heure n'est pas nécessaire (réduit la cardinalité)
• Évitez de stocker des valeurs numériques sous forme de texte (le texte est bien pire que les nombres)
• Utilisez du booléen au lieu du texte pour les colonnes oui/non ou vrai/faux

Impact typique : réduction de la taille du modèle de 10 à 20 %.

Grandes tables divisées :

Une table de faits de 100 millions de lignes peut être divisée en données actives (année en cours, chargées à chaque actualisation) et données historiques (années précédentes, chargées moins fréquemment ou stockées sous forme d'agrégations). Cela réduit à la fois la taille du modèle et la durée de rafraîchissement.

Tableaux d'agrégation (couverts en détail ci-dessous) :

Pour les tables de faits volumineuses, les tables d'agrégation offrent la plus grande amélioration des performances en pré-calculant les données récapitulatives selon des granularités fréquemment interrogées.

---

Tableaux d'agrégation

Que sont les tables d'agrégation

Les tables d'agrégation sont des tables récapitulatives précalculées que Power BI interroge au lieu d'analyser la table détaillée complète. Lorsqu'un utilisateur affiche un graphique affichant les revenus mensuels par région, Power BI interroge la table d'agrégation (qui peut contenir 120 lignes : 10 régions x 12 mois) au lieu de la table détaillée (qui peut contenir 50 millions de lignes de transactions).

La puissance des tableaux d’agrégation réside dans le fait qu’ils sont transparents pour les consommateurs. Les utilisateurs interagissent avec les mêmes visuels et mesures. Power BI achemine automatiquement les requêtes vers la table d'agrégation lorsque la granularité de la requête correspond, et passe à la table de détail pour les requêtes d'exploration ou de niveau de détail.

Conception de tableaux d'agrégation

Étape 1 : Identifiez la granularité de l'agrégation.

Analysez vos rapports pour déterminer les granularités de requête les plus courantes. Pour un tableau de bord des ventes :

• Requête la plupart des visuels exécutifs au niveau Mois + Région + Catégorie de produit
• Requête de visuels Manager au niveau Semaine + Magasin + Produit
• Requête de tables détaillées au niveau de transaction individuelle

Concevez une ou deux tables d’agrégation selon les granularités les plus fréquemment demandées.

Étape 2 : Créez la table d'agrégation.

Dans Power Query, créez une nouvelle table qui regroupe votre table de faits selon la granularité d’agrégation :

Étape 3 : Configurez les mappages d'agrégation.

Dans Power BI Desktop, sélectionnez la table d'agrégation, accédez à Propriétés > Gérer les agrégations et mappez chaque colonne d'agrégation à la colonne et à la fonction de la table de détail correspondante :

Étape 4 : Masquer le tableau d'agrégation.

Les utilisateurs ne doivent pas interagir directement avec la table d'agrégation. Masquez-le de la vue du rapport. Power BI l'utilise automatiquement et de manière transparente.

Impact sur les performances de l'agrégation

Ces améliorations s’étendent à toutes les pages du rapport. Une page avec 10 visuels, chacun interrogeant la table d'agrégation au lieu de la table de détail, peut se charger en 1 seconde au lieu de 30 secondes.

Maintenance de la table d'agrégation

• Actualiser les tables d'agrégation selon le même calendrier que les tables de détail pour maintenir la cohérence
• Surveiller les taux de réussite de l'agrégation à l'aide de DAX Studio (les événements de trace indiquent si les requêtes atteignent l'agrégation ou échouent)
• Ajoutez de nouvelles tables d'agrégation à mesure que vous identifiez des modèles de requêtes courants supplémentaires
• Supprimer les tables d'agrégation dont le taux de réussite descend en dessous de 50% (elles consomment de l'espace sans bénéfice suffisant)

---

Optimisation DirectQuery

Quand DirectQuery est nécessaire

DirectQuery interroge la base de données source en temps réel au lieu d'importer des données dans le moteur en mémoire de Power BI. C'est nécessaire lorsque :

• Les exigences en matière de fraîcheur des données exigent une latence inférieure à la minute (négociation boursière, surveillance de l'IoT, détection des fraudes)
• L'ensemble de données dépasse les limites de taille du modèle de Power BI (10 Go sur Premium P1, 25 Go sur P2, etc.)
• La conformité ou la sécurité exige que les données ne quittent jamais le système source
• La base de données source dispose déjà de vues matérialisées étendues et d'une infrastructure d'agrégation

Pour tous les autres scénarios, le mode Importer est fortement préféré. Le mode d'importation est 10 à 100 fois plus rapide pour les requêtes interactives et offre une meilleure expérience utilisateur.

### Stratégies de performances DirectQuery

Réduisez le nombre de visuels par page.

Chaque visuel en mode DirectQuery génère une requête distincte vers la base de données source. Une page avec 20 visuels génère 20 requêtes simultanées lors du chargement de la page, plus des requêtes supplémentaires lorsque les filtres changent. Limitez les pages DirectQuery à 8 à 10 visuels maximum.

Optimisez la base de données source.

Power BI envoie des requêtes SQL (ou des requêtes natives pour les sources non SQL) à la source. Les performances de la base de données source déterminent directement les performances du rapport. Assurez-vous :

• Des index existent sur toutes les colonnes utilisées dans les filtres, les relations et les mesures
• Les statistiques sont à jour sur les tables interrogées
• Le serveur de base de données dispose de suffisamment de CPU et de mémoire pour les requêtes analytiques simultanées ainsi que les charges de travail opérationnelles
• Envisagez de créer des vues matérialisées ou des vues indexées pour les modèles de requête courants

Activez les options de réduction des requêtes.

Dans Power BI Desktop > Options > Réduction des requêtes, activez :

• "Réduire le nombre de requêtes envoyées en n'envoyant pas de requêtes de surbrillance croisée" : empêche le filtrage croisé entre les visuels de générer des requêtes supplémentaires
• "Ajouter un bouton Appliquer à chaque slicer" : les utilisateurs ajustent plusieurs slicers avant l'exécution des requêtes, réduisant ainsi le volume total des requêtes
• "Ajouter un bouton Appliquer au volet filtre" : Même principe pour le volet filtre

Utilisez le mode de stockage double de manière stratégique.

Les tables peuvent être définies en mode « Dual », qui stocke les données à la fois en mode Import (pour les requêtes locales rapides) et maintient une connexion DirectQuery (pour les relations avec les tables DirectQuery). Définissez les tables de dimensions (Produits, Clients, Dates) en mode Double tout en conservant de grandes tables de faits dans DirectQuery. Cela améliore considérablement les performances des filtres et des slicers sans sacrifier la fraîcheur des données dans les tables de faits.

Implémenter la mise en cache des requêtes.

Activez la « mise en cache des requêtes » dans les paramètres du jeu de données du service Power BI. Cela met en cache les résultats des requêtes pendant une période configurable, en diffusant les résultats mis en cache pour des requêtes identiques. La mise en cache des requêtes est particulièrement efficace pour les tableaux de bord consultés par de nombreux utilisateurs avec les mêmes filtres (par exemple, un tableau de bord exécutif affichant des mesures à l'échelle de l'entreprise).

---

Surveillance des performances de capacité

Indicateurs de capacité clés

Pour les organisations bénéficiant d’une capacité Premium ou Fabric, les performances de l’infrastructure sont aussi importantes que la conception des rapports. La limitation de capacité peut entraîner des performances médiocres, même dans les rapports bien optimisés.

Mesures à surveiller :

L'application de métriques de capacité Microsoft Fabric

Microsoft fournit une application dédiée de surveillance de la capacité dans le service Power BI. Installez-le depuis AppSource et connectez-le à votre capacité. Il fournit :

• Utilisation du processeur en temps réel et historique avec répartition par type de charge de travail
• Analyse de limitation interactive montrant quelles opérations ont déclenché la limitation
• Consommation de mémoire par ensemble de données avec historique d'expulsion
• Actualiser les tendances de performances
• Centiles de performances des requêtes

Examinez cette application chaque semaine pendant les phases d'optimisation et mensuellement pendant l'état stable.

Adaptation de la capacité

Une capacité sous-approvisionnée entraîne une limitation et une mauvaise expérience utilisateur. Une capacité surapprovisionnée gaspille de l’argent. Le bon dimensionnement nécessite de comprendre votre modèle de charge de travail :

• Heures d'utilisation maximale : La plupart des organisations constatent une charge 2 à 3 fois plus élevée pendant les heures de bureau que pendant la nuit. Si vous dimensionnez pour le pic et que vous disposez de références Fabric F, envisagez de faire une pause pendant la nuit ou de réduire votre activité en dehors des heures d'ouverture.
• Conflit entre actualisation et interaction : Les actualisations de données et les requêtes interactives sont en concurrence pour les mêmes ressources de capacité. Planifiez des actualisations importantes en dehors des heures de pointe interactives. Si cela n’est pas possible, envisagez des capacités distinctes pour les charges de travail d’actualisation et interactives.
• Projection de croissance : Prévoyez 6 à 12 mois de croissance. La taille du modèle, le nombre d’utilisateurs et la complexité des requêtes ont tous tendance à augmenter avec le temps. Construisez une marge de 30 à 50 % dans le dimensionnement de la capacité.

---

Analyse comparative avant/après

Pourquoi l'analyse comparative est importante

L'optimisation sans mesure n'est qu'une conjecture. L'analyse comparative avant/après prouve que les changements ont amélioré les performances, quantifie l'amélioration pour les parties prenantes et crée une base de référence pour détecter une régression future.

Méthodologie d'analyse comparative

Étape 1 : Définir les métriques.

Étape 2 : Enregistrez la ligne de base.

Avant d’apporter des modifications, enregistrez toutes les mesures. Exécutez Performance Analyzer 10 fois pour tenir compte de l’échauffement et de la variabilité du cache. Enregistrez la médiane (P50) et le 95e centile (P95) pour chaque mesure.

Étape 3 : implémentez les modifications progressivement.

Effectuez une optimisation à la fois et mesurez à nouveau après chaque modification. Cela permet d'identifier les optimisations qui ont eu le plus d'impact et d'éviter de masquer une régression par une amélioration ailleurs.

Étape 4 : Enregistrez les métriques post-optimisation.

Après toutes les optimisations, enregistrez les mêmes métriques en utilisant la même méthodologie. Présenter les résultats dans un tableau comparatif :

Étape 5 : Planifiez une surveillance continue.

Les performances se dégradent au fil du temps à mesure que les données augmentent, que de nouvelles mesures sont ajoutées et que de nouveaux visuels sont créés. Planifiez des évaluations de performances trimestrielles en utilisant la même méthodologie pour détecter rapidement les régressions.

Pour les organisations ayant besoin d'une optimisation systématique des performances avec des métriques avant/après documentées, ECOSIRE fournit des services complets de performances Power BI, y compris l'analyse DAX Studio, l'optimisation des modèles et le réglage de la capacité.

---

Techniques d'optimisation avancées

Groupes de calcul

Les groupes de calcul remplacent les variantes de mesure répétitives par une logique de calcul réutilisable. Au lieu de créer des mesures distinctes pour la croissance MTD, QTD, YTD, de l'année précédente et YoY pour chaque mesure de base, un groupe de calcul applique ces transformations de manière dynamique.

Avantage en termes de performances : Moins de mesures dans le modèle signifie une empreinte de métadonnées plus petite et un chargement plus rapide du modèle. Plus important encore, les groupes de calcul encouragent des mesures de base plus simples, qui ont tendance à être plus performantes que les mesures complexes tout-en-un.

Modèles composites

Les modèles composites combinent le mode Import et les tables DirectQuery dans un seul modèle. Utilisez le mode Importation pour les tables de dimensions et les tables de faits fréquemment interrogées, DirectQuery pour les tables très volumineuses qui changent trop fréquemment pour l'importation.

Avantage en termes de performances : Les recherches de dimensions et les opérations de filtrage s'exécutent à la vitesse d'importation (microsecondes), tandis que les requêtes de tables de faits s'exécutent à la vitesse DirectQuery (centaines de millisecondes à secondes). Le résultat net est nettement meilleur que DirectQuery pur.

Actualisation incrémentielle

L'actualisation incrémentielle charge uniquement les données nouvelles et modifiées pendant l'actualisation, plutôt que de recharger l'intégralité de l'ensemble de données. Pour une table de 100 millions de lignes où seules 100 000 lignes changent quotidiennement, l’actualisation incrémentielle réduit le temps d’actualisation de 99 %.

Configuration : Définissez un paramètre RangeStart et RangeEnd dans Power Query. Configurez la stratégie d'actualisation incrémentielle pour spécifier le nombre de jours/mois de données à actualiser et la quantité de données historiques à conserver. Power BI partitionne automatiquement l'ensemble de données et actualise uniquement les partitions actives.

Avantage en termes de performances : Réduction considérable de la durée de rafraîchissement et de la consommation de capacité pendant le rafraîchissement. Permet également l'actualisation en temps réel avec les partitions DirectQuery sur la capacité Fabric.

Pliage des requêtes

Le repliement des requêtes repousse les transformations Power Query vers la base de données source, en les exécutant en tant que SQL natif plutôt que dans le moteur Power Query. Les requêtes pliées s'exécutent beaucoup plus rapidement car le moteur de base de données les optimise et les exécute de manière native.

Comment vérifier : Cliquez avec le bouton droit sur n'importe quelle étape de l'éditeur Power Query et vérifiez si « Afficher la requête native » est disponible. Si tel est le cas, la requête se replie sur cette étape. S'il est grisé, le pliage s'est interrompu lors d'une étape précédente.

Séparateurs de pliage courants : Colonnes personnalisées avec expressions M, fusion de tables de différentes sources, certaines transformations (pivotement, conversions de types complexes). Lors du repli des pauses, toutes les transformations ultérieures s'exécutent dans le moteur Power Query, qui est nettement plus lent pour les grands ensembles de données.

---

##FAQ

Quel est un bon objectif pour le temps de chargement des rapports Power BI ?

Ciblez moins de 3 secondes pour les tableaux de bord fréquemment utilisés et moins de 5 secondes pour les rapports analytiques détaillés. Ces objectifs s'alignent sur les attentes des utilisateurs vis-à-vis des applications Web et maintiennent un engagement élevé. Les rapports qui dépassent systématiquement 10 secondes doivent être prioritaires pour l'optimisation. Mesurez le temps de chargement du point de vue de l'utilisateur (y compris le réseau et le rendu), et pas seulement le temps de requête DAX. Le temps de requête DAX de Performance Analyzer et le temps de rendu visuel doivent totaliser moins de 2 secondes pour chaque visuel afin d'obtenir un chargement de page de 3 secondes avec 8 à 10 visuels.

Dois-je toujours préférer le mode Importation à DirectQuery ?

Pour les rapports interactifs utilisés par les utilisateurs professionnels, oui --- Le mode Importation est presque toujours le meilleur choix. Le mode d'importation est 10 à 100 fois plus rapide pour les requêtes, ne dépend pas des performances de la base de données source lors de l'affichage du rapport et prend en charge la gamme complète des fonctions DAX et des fonctionnalités d'IA. Utilisez DirectQuery uniquement lorsque vous avez réellement besoin d'une actualisation des données inférieure à une minute, lorsque votre ensemble de données dépasse les limites de taille d'importation ou lorsque la conformité exige que les données restent dans le système source. Considérez les modèles composites comme une solution intermédiaire : importez les dimensions et les faits fréquemment interrogés, DirectQuery uniquement les tableaux qui ont vraiment besoin d'une fraîcheur en temps réel.

À quelle fréquence dois-je exécuter des audits de performances sur mes rapports Power BI ?

Effectuer un audit de performance complet chaque trimestre pour les rapports de production. Entre les audits, surveillez les mesures de capacité chaque semaine et enquêtez rapidement sur toute lenteur signalée par les utilisateurs. Les événements majeurs qui devraient déclencher un audit immédiat comprennent : une croissance significative du volume de données (augmentation de plus de 25 %), l'ajout de nouvelles pages de rapport ou de mesures DAX complexes, des changements dans la simultanéité des utilisateurs (croissance des utilisateurs après le lancement) et des changements de capacité (mise à niveau, rétrogradation ou migration).

Puis-je optimiser les performances de Power BI sans modifier mes rapports ?

Oui, dans une certaine mesure. Les optimisations au niveau de l'infrastructure incluent : la mise à niveau du SKU de capacité, l'activation de la mise en cache des requêtes dans les paramètres du service, la planification d'actualisations importantes en dehors des heures de pointe, la configuration du clustering de passerelle pour un meilleur débit et l'optimisation de la base de données source (index, statistiques, vues matérialisées). Ces modifications améliorent les performances sans toucher aux fichiers de rapport. Cependant, les optimisations les plus efficaces impliquent généralement des modifications au niveau du rapport : réécriture des mesures DAX, réduction de la taille du modèle, tables d'agrégation et réduction du nombre visuel. L'optimisation des infrastructures répond aux contraintes de capacité ; l'optimisation des rapports aborde l'efficacité.

Qu'est-ce qui ralentit les rapports Power BI au fil du temps ?

Cinq causes courantes : (1) Croissance du volume de données --- les mêmes requêtes prennent plus de temps à mesure que les tables passent de 1 million à 10 millions de lignes. (2) Accumulation de mesures --- de nouvelles mesures sont ajoutées sans optimiser celles existantes, et les interactions entre les mesures créent une complexité accrue. (3) Étalement visuel --- les utilisateurs ajoutent plus de visuels par page, chacun générant des requêtes supplémentaires. (4) Gonflement du modèle --- de nouvelles colonnes et tables sont ajoutées sans supprimer celles inutilisées. (5) Croissance simultanée des utilisateurs --- davantage d'utilisateurs en compétition pour les mêmes ressources de capacité. Répondez à ces problèmes avec des audits de performance trimestriels, des politiques de gouvernance qui limitent le nombre visuel et mesurent la complexité, ainsi qu'une surveillance proactive des capacités.