Comment utiliser les diagnostics dans Power BI pour comprendre et alléger ses rapports

On entend souvent qu’un rapport Power BI lent est forcément le signe d’un modèle trop lourd ou d’un ordinateur qui manque de puissance. En réalité, ce n’est pas toujours si simple. Un visuel bien présenté peut cacher une mesure coûteuse, un filtre mal pensé ou une requête qui se répète inutilement. Quand le rapport répond avec un petit temps de retard à chaque clic, les diagnostics deviennent alors mes meilleurs alliés : ils permettent de regarder ce qui se passe vraiment, sans deviner.

Je dis bien « les outils », parce qu’il n’y a pas un seul bouton magique intitulé “répare mon rapport”. Dans Power BI, diagnostiquer, c’est regarder à plusieurs endroits : ce qui se passe pendant le chargement des données, ce qui ralentit l’affichage des visuels, et parfois ce que Power BI enregistre en arrière-plan pour comprendre un comportement étrange.

L’idée de cet article n’est pas de transformer tout le monde en expert performance. Mon objectif est plus simple : te montrer comment j’utilise concrètement le diagnostic dans Power BI pour arrêter de deviner et commencer à observer.

Avant de cliquer partout : savoir ce qu’on cherche

Quand un rapport est lent, on a vite tendance à accuser “Power BI” en bloc. En réalité, le ralentissement peut venir de plusieurs couches très différentes.

Il peut venir de Power Query, par exemple si une requête fait trop d’étapes, si elle appelle une source lente, ou si elle empêche le fameux query folding, c’est-à-dire la capacité de Power BI à déléguer le travail à la source de données. Il peut aussi venir du modèle, avec des relations compliquées, des colonnes inutiles ou des calculs DAX trop gourmands. Et parfois, c’est simplement la page du rapport qui demande trop de choses en même temps : trop de visuels, trop de filtres croisés, trop de mesures sollicitées à chaque interaction.

Avant de lancer un diagnostic, je me pose donc toujours une question très simple : le problème arrive-t-il au chargement des données, à l’ouverture de la page, ou quand j’interagis avec un visuel ?

Cette question change tout. Si le souci arrive pendant l’actualisation, je vais regarder Power Query. Si la page s’affiche lentement, je vais ouvrir l’analyseur de performances. Si j’ai un comportement anormal ou intermittent, je peux activer les traces de diagnostic.

Activer les diagnostics dans Power BI Desktop

Pour accéder aux options générales de diagnostic, je passe par Power BI Desktop : Fichier > Options et paramètres > Options, puis je cherche la partie liée aux diagnostics dans les options globales.

Selon la version de Power BI Desktop, l’emplacement ou les libellés peuvent légèrement évoluer, mais l’idée reste la même : ces paramètres permettent notamment d’activer ou de consulter des fichiers de trace. Ces traces sont utiles quand on veut garder une trace technique de ce que fait Power BI, ou quand un support technique demande des éléments précis.

Mon conseil : je n’active pas les traces “juste au cas où” pendant des semaines. Je les utilise plutôt sur une session courte, quand je reproduis un problème. Les fichiers générés peuvent devenir volumineux et ils ne sont pas faits pour remplacer une vraie analyse de rapport. C’est un outil d’enquête, pas un tableau de bord du quotidien.

Autre point de vigilance : les diagnostics peuvent contenir des informations sur ton environnement, tes sources ou tes requêtes. Avant de partager un fichier de trace, je vérifie toujours ce qu’il contient et avec qui je le partage.

Utiliser le diagnostic de requête dans Power Query

Quand le problème concerne l’actualisation des données ou une requête qui semble interminable, j’ouvre l’éditeur Power Query. C’est là que le diagnostic de requête devient intéressant.

Dans l’éditeur Power Query, on trouve les options de diagnostic dans le ruban, généralement sous l’onglet Outils. Le principe est assez simple : on démarre l’enregistrement du diagnostic, on effectue l’action à analyser, par exemple actualiser l’aperçu ou appliquer les modifications, puis on arrête l’enregistrement. Power BI génère alors des tables de diagnostic que l’on peut examiner comme des données.

Ce que j’aime avec cet outil, c’est qu’il rend visible quelque chose qui reste souvent flou : quelles étapes prennent du temps, quelles opérations sont déclenchées, et comment Power Query dialogue avec la source.

Je ne lis pas ces tables comme un roman. Je cherche d’abord les indices évidents :

• des étapes qui prennent nettement plus de temps que les autres ;
• des appels répétés à une même source ;
• des opérations qui semblent se produire plus tôt ou plus souvent que prévu ;
• des signes que Power Query fait localement un travail qui aurait pu être fait par la base de données.

Par exemple, si je vois qu’un filtrage intervient tard dans la requête, je me demande immédiatement s’il ne pourrait pas être placé plus tôt. Réduire les lignes et les colonnes dès le début est une règle simple, mais elle évite énormément de lourdeur. Importer un grand volume de données pour jeter ensuite la moitié des colonnes, c’est comme remplir un coffre de voiture avant de trier ce qu’on voulait vraiment emporter.

Le point souvent négligé : le query folding

Je fais une petite parenthèse, parce que c’est un sujet qui revient souvent dans mes propres diagnostics. Dans Power Query, certaines transformations peuvent être traduites en requêtes envoyées à la source : une base SQL, par exemple. C’est ce qu’on appelle le query folding.

Quand le pliage de requête fonctionne, la source fait une partie du travail. Quand il se casse, Power BI peut devoir récupérer plus de données et travailler localement. Ce n’est pas toujours dramatique, mais sur des volumes importants, cela peut changer complètement l’expérience.

Dans Power Query, je vérifie parfois si l’option Afficher la requête native est disponible sur une étape. Si elle est grisée, ce n’est pas automatiquement une catastrophe, mais c’est un signal à examiner. Une transformation personnalisée, un type de fusion, une colonne ajoutée avec une logique complexe peuvent interrompre le folding.

Mon réflexe : je place les étapes les plus “délégables” le plus tôt possible, filtres, sélection de colonnes, types de données simples, puis je garde les transformations plus spécifiques pour la fin.

Analyser les lenteurs d’affichage avec l’analyseur de performances

Si le rapport est lent quand on ouvre une page ou quand on clique sur un segment, je change d’outil. Là, je vais dans l’onglet Vue de Power BI Desktop et j’ouvre Analyseur de performances.

Cet outil enregistre ce qui se passe au niveau des visuels. Je lance l’enregistrement, puis j’actualise les visuels ou je reproduis l’action qui pose problème. Power BI liste ensuite les éléments de la page avec leurs temps d’exécution et les grandes catégories d’activité, comme la requête DAX, l’affichage du visuel ou d’autres traitements.

Ce que je trouve très utile, c’est que l’analyseur aide à dépasser les impressions. On croit parfois qu’un graphique sophistiqué est responsable, alors que le vrai coupable est une carte toute simple basée sur une mesure complexe. À l’inverse, un visuel très chargé peut effectivement multiplier les requêtes et ralentir l’ensemble de la page.

Quand j’analyse une page, je procède par élimination. Je regarde d’abord les visuels les plus coûteux, puis je me demande :

• cette information est-elle vraiment nécessaire sur cette page ?
• la mesure utilisée peut-elle être simplifiée ?
• le visuel affiche-t-il trop de catégories ou trop de détails ?
• un filtre de page pourrait-il réduire le volume interrogé ?
• plusieurs visuels racontent-ils en fait la même chose ?

C’est un point que je rappelle souvent : optimiser un rapport, ce n’est pas seulement écrire du DAX plus malin ; c’est aussi faire des choix éditoriaux. Une page qui montre tout montre rarement bien.

Déconstruire une page pour comprendre ce qui coûte cher

Quand une page me résiste, j’utilise une méthode très artisanale, mais efficace : je duplique la page, puis je retire des éléments petit à petit. Je garde l’analyseur de performances ouvert et j’observe ce qui change.

Je commence par masquer ou supprimer temporairement les visuels les plus lourds. Ensuite, je teste les segments, les interactions entre visuels, les mesures principales. Cela permet de distinguer trois situations : un visuel isolé pose problème, une mesure est coûteuse partout où elle apparaît, ou la combinaison des interactions rend la page trop bavarde.

Les interactions sont un piège discret. Dans Power BI, chaque filtre croisé peut entraîner de nouvelles requêtes. Sur une page avec beaucoup de visuels, un simple clic peut déclencher une petite cascade. Je prends donc le temps d’aller dans Modifier les interactions pour désactiver celles qui n’apportent rien à la lecture.

C’est rarement spectaculaire visuellement, mais côté confort utilisateur, ça peut faire une vraie différence.

Les bonnes pratiques qui ressortent souvent du diagnostic

À force de diagnostiquer des rapports, j’ai quelques réflexes qui reviennent presque toujours. Rien de révolutionnaire, mais ce sont des gestes qui évitent bien des lenteurs.

D’abord, je supprime les colonnes inutiles dès Power Query. Une colonne qui ne sert ni aux relations, ni aux mesures, ni aux visuels n’a pas besoin de voyager dans le modèle. Ensuite, je vérifie les types de données : des types incohérents ou trop larges peuvent compliquer le modèle sans bénéfice.

Je fais aussi attention aux visuels “fourre-tout”. Une matrice avec trop de niveaux, trop de mesures et trop de détails peut vite devenir lourde. Parfois, il vaut mieux proposer une vue synthétique, puis une page de détail accessible par navigation ou exploration.

Côté DAX, je me méfie des mesures qui ont grandi au fil du temps. Une mesure commencée simplement peut finir avec des conditions imbriquées, des filtres complexes et des exceptions partout. Quand l’analyseur de performances pointe souvent vers la même mesure, je prends le temps de la relire calmement. Souvent, le simple fait de créer des mesures intermédiaires plus lisibles aide à comprendre où ça coince.

Enfin, je documente mes changements. Pas besoin d’un roman : une note courte du type “filtre déplacé plus tôt dans Power Query” ou “interaction désactivée entre tel segment et tel visuel” suffit. Quand on revient sur un rapport trois mois plus tard, ces petits cailloux blancs sont précieux.

Ce que le diagnostic ne dira pas à ta place

Le diagnostic donne des indices, pas des décisions toutes faites. Il peut montrer qu’un visuel est lent, mais il ne sait pas si ce visuel est indispensable pour ton public. Il peut révéler qu’une requête est coûteuse, mais il ne connaît pas tes contraintes métier, la qualité de ta source, ni la fréquence réelle d’utilisation du rapport.

C’est pour cela que j’essaie toujours de relier la performance à l’usage. Un rapport consulté tous les matins par une équipe entière mérite une attention particulière. Une page d’analyse utilisée ponctuellement par deux personnes peut accepter un peu plus de complexité si elle apporte une vraie profondeur.

Le bon rapport n’est pas seulement le plus rapide : c’est celui qui répond clairement à une question, sans faire patienter inutilement.

Ma petite routine de diagnostic

Quand je reprends un rapport Power BI lent, voici l’ordre que je suis généralement : je reproduis le problème, j’identifie le moment où il apparaît, puis je choisis l’outil adapté. Power Query pour l’actualisation, l’analyseur de performances pour les pages et les visuels, les traces de diagnostic pour les cas plus techniques ou difficiles à reproduire.

Ensuite, je ne corrige qu’une chose à la fois. C’est tentant de tout modifier d’un coup, mais on ne sait plus ce qui a vraiment amélioré la situation. Une modification, un test, une observation : c’est moins flamboyant, mais beaucoup plus fiable.

Et surtout, je garde en tête que diagnostiquer n’est pas une punition réservée aux rapports “mal faits”. C’est une démarche normale, presque une conversation avec son modèle. On lui demande : “Qu’est-ce qui te fatigue ? Qu’est-ce que je peux alléger ? Qu’est-ce qui mérite vraiment d’être affiché ?”

Si tu n’as jamais ouvert ces outils, commence doucement : lance l’analyseur de performances sur une page que tu connais bien, observe les résultats, puis retire un visuel inutile ou simplifie une interaction. Rien que ce premier pas peut changer ton regard sur Power BI. Et, promis, il y a une petite satisfaction très agréable à voir un rapport respirer mieux après quelques ajustements bien ciblés.