Power BI trop lent : mon modèle est trop lourd à cause du détail par jour

Rapport Power BI lent et fichier lourd : regrouper les données par mois pour optimiser les performances

Votre fichier met de longues minutes à s'actualiser, chaque clic sur un segment fait tourner la roue, et le .pbix pèse plusieurs centaines de mégaoctets. Vos données arrivent détaillées par jour, parfois par ticket de caisse, alors que vos rapports se lisent au mois.

Si personne ne regarde jamais le détail quotidien, ne le chargez pas. Dans Power Query, la fonction Regrouper par ramène vos données à une ligne par mois : environ trente fois moins de lignes, et un modèle de données qui respire. Avant de vous lancer, prenez deux minutes pour vérifier que c'est bien là que se situe le problème.

D'abord, vérifier que le détail par jour est le vrai coupable

Power BI compresse très efficacement les données. Quelques millions de lignes ne lui font pas peur. Ce qui pèse réellement et consomme de la mémoire, ce sont :

• le nombre de colonnes. Chaque colonne chargée et jamais utilisée est du poids mort ;
• des colonnes aux valeurs toutes différentes : un numéro de commande, un commentaire libre, une date avec l'heure à la seconde. Elles se compressent très mal ;
• les colonnes calculées au lieu de mesures. Une colonne calculée est stockée pour chaque ligne, alors que les mesures sont calculées à la volée au moment de l'affichage.

Commencez par supprimer ce qui ne sert pas : retirer dix colonnes allège souvent davantage un modèle que de diviser le nombre de lignes par trente. Si le modèle reste volumineux après ce ménage, ou si votre table compte des dizaines de millions de lignes, le regroupement est la bonne réponse.

Quand regrouper par mois, et quand s'en abstenir

Regroupez si vos rapports se lisent au mois ou au trimestre, si personne ne descend jamais au jour, et si le rafraîchissement des données est devenu pénible.

Ne regroupez pas si vous avez besoin de comparer des semaines, de suivre un cumul à date, de compter des jours ouvrés, ou d'expliquer un pic en retrouvant la journée concernée. Une fois le détail supprimé du modèle, il n'y est plus : les utilisateurs qui en ont besoin ne pourront plus le visualiser.

La méthode en 6 étapes

1. Créez une référence de votre requête d'origine (clic droit > Référence). Vous travaillez sur la copie et gardez l'original intact.
2. Créez une colonne de mois qui reste une vraie date : sélectionnez la colonne Date, puis Ajouter une colonne > Date > Mois > Début du mois. Chaque ligne porte désormais le 1er du mois.
3. Cliquez sur Transformer > Regrouper par, et passez en mode Avancé.
4. Comme critères de regroupement, mettez Début du mois et tous les axes d'analyse dont vous avez besoin : Produit, Magasin, Commercial.
5. Ajoutez vos agrégations : Somme de Ventes, Somme de Quantité. Nommez chaque colonne créée et vérifiez ses types de données.
6. Sur la requête d'origine, décochez Activer le chargement. Le mode Import charge les données dans le modèle telles qu'elles sortent de l'éditeur : il ne faut donc charger que les données regroupées, uniquement les données que les rapports vont utiliser.

« Regrouper par / Group By dans Power Query », extrait du livre Microsoft Power BI en images, p. 143.

En vidéo : Tout savoir sur le GROUP BY dans Power Query

Les 4 pièges du regroupement

Oublier l'étape 6. Si la requête détaillée reste chargée à côté de la requête regroupée, vous n'avez rien allégé : vous avez ajouté une table.

Oublier un axe d'analyse. Si vous regroupez par mois sans la colonne Produit, plus aucun visuel ne pourra ventiler par produit. Listez vos besoins avant de regrouper.

Regrouper ce qui ne s'additionne pas. Une somme de ventes mensuelles s'additionne sans risque pour donner un trimestre. Un nombre de clients distincts, non : le même client présent en janvier et en février serait compté deux fois. Même chose pour une moyenne. Dans ce cas, conservez la somme et le nombre de lignes, et recalculez la moyenne dans une mesure, qui saura calculer le bon résultat à chaque niveau.

Transformer le mois en texte. Une colonne « 2026-01 » en texte casse la relation avec votre table de dates et se trie mal. « Début du mois » reste une date, votre schéma en étoile reste intact, et tout continue de fonctionner.

Ce que le regroupement ne règle pas

Le regroupement allège le modèle : cela réduit la taille du fichier et améliore la vitesse de chargement des visuels. Il n'accélère pas forcément l'actualisation. Si votre source de données est une base de données SQL, le moteur délègue le regroupement au serveur et ne reçoit que le résultat : le gain est total. Si la source est un gros fichier Excel ou un CSV, le connecteur doit quand même lire toutes les lignes avant de les regrouper, et le temps de chargement augmente avec le volume du fichier.

Côté rapport : visuels et interactions

Un modèle léger ne suffit pas si la page est surchargée. Chaque visuel envoie ses propres requêtes DAX au moteur, et plus de visuels signifie plus de temps à charger. Trois réflexes pour améliorer les performances côté rapport :

• Limitez le nombre de visuels par page : au-delà d'une dizaine, le temps de chargement se dégrade nettement. Évitez les visuels décoratifs et les tableaux de centaines de lignes que personne ne lit.
• Modifier les interactions entre visuels (onglet Format) : par défaut, chaque segment refiltre tous les autres visuels. Coupez les interactions inutiles, et chaque clic déclenche moins de requêtes.
• Simplifiez les filtres : ceux qui portent sur des colonnes à forte cardinalité (numéro de ticket, horodatage) sont les plus coûteux.

Les autres leviers pour un modèle plus léger

• Supprimez les colonnes inutilisées. C'est le geste le plus rentable.
• Désactivez l'option Date/heure automatique, qui crée une table de dates cachée pour chaque colonne de date.
• Séparez date et heure en deux colonnes, et réduisez le nombre de décimales, via les paramètres de chaque colonne.
• Privilégiez les mesures aux colonnes calculées : les mesures DAX ne coûtent rien tant qu'on ne les affiche pas.
• Ne chargez pas les requêtes Power Query intermédiaires (désactivation vue à l'étape 6).
• Gardez les transformations dans Power Query plutôt que dans le modèle : elles s'exécutent une fois, à l'actualisation, et vous évitez de ralentir chaque clic.
• Pour les très gros volumes, mettez en place l'actualisation incrémentielle, qui ne rafraîchit que les mises à jour récentes.

« Optimiser la performance d'un jeu de données », extrait du même livre, p. 185.

Une précision sur le dernier levier de l'infographie : DirectQuery réduit la taille du fichier, puisque les données restent dans la source, mais l'affichage devient en général plus lent, chaque clic interrogeant la base. À éviter tant que le mode Import suffit. Réservez-le aux volumes que le mode Import ne peut pas absorber ou aux besoins de temps réel.

En vidéo : Les 20 commandements de Power Query

Et si le problème venait de la capacité ?

Un modèle bien construit tourne vite sur une simple licence Pro. Mais si vos rapports sont partagés à des centaines de personnes, ou si le modèle dépasse la limite de taille des licences Power BI standard, le goulot n'est plus dans votre .pbix. C'est là qu'interviennent Power BI Premium par capacité (mémoire dédiée, modèles plus gros) ou Power BI Embedded pour intégrer les rapports dans vos propres applications. Ces choix relèvent de l'architecture de votre business intelligence, pas de l'optimisation d'un rapport, et le support Power BI de Microsoft documente les limites de chaque offre.

Questions fréquentes

Peut-on regrouper en DAX plutôt que dans l'éditeur de requêtes ? Non, pas pour alléger. Une table calculée s'ajoute au modèle sans retirer le détail. Le regroupement doit se faire en amont, dans l'éditeur de requêtes ou à la source.

Puis-je garder le détail pour une seule page du rapport ? Oui, en conservant une table regroupée pour les pages de synthèse et une table détaillée limitée aux derniers mois. C'est un compromis courant pour les rapports Power BI de pilotage.

Mon modèle regroupé est toujours lent, que faire ? Le problème vient probablement des mesures ou des visuels. Pour résoudre les problèmes de ce type, utilisez l'Analyseur de performances (onglet Optimiser) : il chronomètre chacun d'eux et permet d'identifier les goulots d'étranglement. Attention, les performances dans Desktop ne reflètent pas toujours celles du service, où l'utilisation est partagée entre plusieurs utilisateurs et où chaque utilisateur ajoute sa charge.

Un tableau de bord et un rapport Power BI, est-ce la même chose ? Non. Le rapport est le fichier que vous construisez dans Power BI Desktop ; le tableau de bord est une page d'épingles assemblée dans le service. Alléger le rapport accélère les deux.

Pour aller plus loin

• Le livre Microsoft Power BI en images, disponible sur Amazon, d'où viennent les deux infographies (p. 143 et 185).
• Nos formations Power BI, pour apprendre à utiliser le regroupement, les mesures et les autres leviers, et concevoir dès le départ un modèle léger, avec des rapports plus rapides. Bien utiliser ces outils, c'est ce qui sépare un rapport que l'on subit d'un rapport que l'on consulte.