Un rapport Power BI qui met trente secondes à s'ouvrir : cherchez dans le modèle, pas dans le visuel

Un rapport qui met trente secondes à s'ouvrir finit par ne plus être ouvert du tout. C'est le mode d'échec le plus courant d'un projet décisionnel : le rapport est juste, il est complet, et plus personne ne le consulte.

Le réflexe est de simplifier la page. Nous commençons systématiquement ailleurs, dans le modèle, parce que c'est là que se trouvent les cinq causes qui expliquent l'essentiel des cas que nous reprenons.

1. Les colonnes que personne n'utilise

Power BI compresse les données colonne par colonne. Une colonne à forte cardinalité, comme un numéro de commande, un horodatage à la seconde ou un identifiant technique, se compresse mal et pèse lourd en mémoire, même quand aucun visuel ne la lit.

Le cas typique est une table de faits importée telle quelle depuis l'ERP, avec ses cent vingt colonnes dont douze servent réellement.

Ce qu'on fait : on supprime les colonnes inutilisées à la source, dans Power Query, pas dans le modèle. Et on remplace les horodatages complets par une date d'un côté et une heure de l'autre : deux colonnes de faible cardinalité se compressent bien mieux qu'un seul datetime unique par ligne.

Sur une table de dix millions de lignes, cette seule opération divise couramment la taille du modèle par deux.

2. Les relations bidirectionnelles

Le filtrage croisé bidirectionnel résout élégamment certains cas de figure, et il coûte cher. À chaque calcul, le moteur doit propager les filtres dans les deux sens, ce qui multiplie le travail et introduit parfois des ambiguïtés qui produisent des résultats faux.

Ce qu'on fait : on repasse toutes les relations en filtrage simple, du côté « un » vers le côté « plusieurs ». Là où le bidirectionnel semblait nécessaire, on le remplace par une fonction CROSSFILTER posée dans la seule mesure qui en a besoin. Le coût devient local au lieu d'être permanent.

3. Une table de dates absente ou mal marquée

C'est la cause la plus fréquente et la plus rapide à corriger. Sans table de dates dédiée, marquée comme telle dans le modèle, les fonctions de décalage temporel, SAMEPERIODLASTYEAR, DATEADD et TOTALYTD, ne peuvent pas s'appuyer sur l'optimisation prévue pour elles. Elles retombent sur un calcul générique, beaucoup plus lent, et parfois faux sur les exercices décalés.

Ce qu'on fait : une table de dates continue couvrant tout l'historique, sans trou, marquée comme table de dates, reliée sur la date qui porte le sens métier : la date de facture, pas la date de saisie. C'est un quart d'heure de travail et l'effet est immédiat.

4. Les colonnes calculées à la place des mesures

Une colonne calculée est évaluée à chaque rafraîchissement, pour chaque ligne, et son résultat est stocké. Une mesure est évaluée à la demande, sur le contexte affiché. Sur une table de faits volumineuse, la différence est considérable.

Le cas d'école est une colonne Marge = [Prix] - [Coût] posée sur dix millions de lignes, alors qu'une mesure SUMX ou, mieux, deux sommes soustraites, rendrait le même résultat sans rien stocker.

Ce qu'on fait : on migre en mesures tout ce qui est agrégeable. On garde en colonne calculée ce qui sert à filtrer ou à regrouper, comme une tranche d'ancienneté ou une catégorie dérivée, parce que ces usages-là ont besoin d'une valeur matérialisée.

5. Les mesures qui itèrent sans nécessité

SUMX, FILTER et leurs cousines parcourent ligne à ligne. C'est indispensable dans certains cas, inutile dans beaucoup d'autres.

Écrire :

CA France = CALCULATE ( [CA], FILTER ( Ventes, Ventes[Pays] = "FR" ) )

force un parcours complet de la table des ventes. Écrire :

CA France = CALCULATE ( [CA], Ventes[Pays] = "FR" )

laisse le moteur appliquer le filtre directement sur la colonne, ce qu'il sait faire beaucoup plus vite. Le résultat est identique, le coût ne l'est pas.

Ce qu'on fait : on relit les mesures à la recherche des FILTER sur une table entière quand un filtre de colonne suffirait. C'est la correction qui, à elle seule, rend le plus de secondes.

Où vit un modèle qui tient

Les cinq corrections ci-dessus supposent qu'il existe un endroit où poser les règles une bonne fois. C'est le rôle de la couche modélisée, celle que nous appelons gold, et c'est ce qui distingue une chaîne de données d'une collection de rapports.

BronzeIngestion

Les données brutes, telles que les systèmes les produisent. ERP, CRM, Dataverse, bases SQL, fichiers.

SilverNettoyage

Règles de nettoyage et d'alignement métier. C'est ici qu'on réconcilie les plans de comptes de six filiales.

GoldModèle sémantique

Données agrégées et optimisées. Source unique de vérité, partagée par tous les rapports et tous les services.

Mesurer avant de corriger

Toutes ces corrections sont bonnes en général ; elles ne sont pas toutes utiles sur votre rapport. Avant d'y toucher, nous regardons deux choses.

L'analyseur de performances de Power BI Desktop donne, visuel par visuel, le temps passé en requête et le temps passé en rendu. Un visuel à huit secondes de requête et deux cents millisecondes de rendu désigne le modèle sans ambiguïté.

DAX Studio donne le détail : quelle requête, quel plan d'exécution, combien de lignes matérialisées. C'est là qu'on voit qu'une mesure a produit un tableau intermédiaire de quatre millions de lignes pour rendre un seul nombre.

Sans ces deux mesures, on corrige au jugé et on passe souvent une journée à optimiser ce qui coûtait deux cents millisecondes.

Ce qu'il faut retenir

La lenteur d'un rapport vient rarement du nombre de visuels. Elle vient de colonnes qu'on n'a pas retirées, de relations trop permissives, d'une table de dates manquante, de calculs matérialisés sans raison et de mesures qui itèrent quand un filtre suffirait.

Les cinq se corrigent, et l'ordre a son importance : mesurez d'abord, sinon vous optimiserez le mauvais endroit.