Qu’est-ce que le jeûne et comment l’utiliser dans Power BI ?

Le terme « jeûne » circule parfois pour désigner le fait d’alléger un projet Power BI. Il ne correspond toutefois à aucune fonction, aucun bouton ni paramètre officiel du produit. Derrière cette image se cache une pratique très concrète : réduire volontairement ce que Power BI importe, stocke, transforme, calcule et dessine, sans supprimer l’information nécessaire à la décision. Bien menée, cette sobriété des données raccourcit les actualisations, rend les rapports plus réactifs et facilite leur maintenance. Mal conduite, elle produit au contraire des indicateurs incomplets ou trompeurs. Voici comment l’appliquer avec méthode.

Le « jeûne » dans Power BI : une métaphore, pas une fonctionnalité

Dans la documentation Microsoft, vous ne trouverez pas de fonctionnalité nommée « jeûne ». Selon le contexte, ce mot peut recouvrir plusieurs pratiques d’optimisation : réduction du volume importé, filtrage des lignes, suppression des colonnes inutiles, agrégation des faits détaillés, désactivation du chargement de requêtes intermédiaires, ou encore simplification du modèle et des visuels.

La bonne question n’est donc pas « comment activer le jeûne ? », mais : quelle donnée doit réellement être disponible, à quel niveau de détail, pour quel utilisateur et à quel moment ? C’est une démarche d’architecture et de gouvernance avant d’être une manipulation dans Power BI Desktop.

Dans un modèle en mode Import, les tables sont compressées et stockées dans le moteur analytique VertiPaq. Le volume brut d’un fichier ne suffit donc pas à prédire sa taille ou sa vitesse : une colonne répétant quelques catégories se compresse généralement bien, tandis qu’une colonne contenant presque une valeur différente par ligne, comme un identifiant de transaction ou un horodatage à la seconde, est plus coûteuse. En DirectQuery, les données restent surtout dans la source, mais chaque interaction peut déclencher des requêtes : réduire les données affichées et la complexité des requêtes reste alors indispensable.

Identifier le vrai frein avant de réduire les données

Alléger au hasard est une erreur courante. Un rapport peut être lent pour des raisons très différentes : source distante, transformation Power Query non repliée vers la source, modèle surdimensionné, relation ambiguë, mesure DAX coûteuse, visuel surchargé ou capacité partagée sous pression. La réponse pertinente dépend du maillon en cause.

Commencez par décrire un scénario reproductible : ouverture du rapport, actualisation d’une page, modification d’un segment, ou rafraîchissement du jeu de données. Mesurez ensuite avant et après chaque changement. Dans Power BI Desktop, Analyseur de performances aide à repérer les visuels lents et distingue le temps de requête DAX du temps de rendu. Les diagnostics de requête dans Power Query éclairent le comportement des étapes de transformation. Pour les modèles Import, des outils spécialisés tels que DAX Studio et VertiPaq Analyzer peuvent compléter le diagnostic, notamment sur la taille des colonnes et leur cardinalité.

Ne confondez pas non plus lenteur de développement et lenteur en production. Une requête qui prévisualise difficilement des millions de lignes dans Power Query peut nécessiter un travail sur la source. Un rapport très rapide dans Desktop peut ralentir après publication si les utilisateurs, les passerelles, les rafraîchissements ou la capacité diffèrent. Testez dans des conditions proches de l’usage réel.

Réduire les données le plus tôt possible dans la chaîne

Le levier le plus rentable consiste à éviter que les données inutiles entrent dans le modèle. Chaque ligne ou colonne écartée avant l’import évite potentiellement du transfert réseau, des transformations, de la compression et des calculs ultérieurs. L’ordre des opérations dans Power Query est donc important.

Définir un périmètre fonctionnel explicite

Avant d’ouvrir l’éditeur Power Query, formalisez les besoins : période historique réellement consultée, entités concernées, fréquence de mise à jour, grain nécessaire et cas d’audit. Un tableau de bord de pilotage mensuel n’a pas forcément besoin de toutes les lignes au niveau transactionnel depuis l’origine. À l’inverse, une analyse de fraude ou une réconciliation comptable peut exiger ce détail : il serait dangereux de l’agréger sans solution de consultation alternative.

Interrogez systématiquement les colonnes. Est-elle utilisée dans une relation, une mesure, un filtre, une info-bulle, une règle de sécurité, une exportation ou une page prévue à court terme ? Si la réponse est non et qu’aucun besoin documenté ne la justifie, elle n’a probablement pas à être chargée.

Appliquer filtres et sélections de colonnes dans Power Query

Dans Power Query, sélectionnez d’abord les tables utiles, puis gardez les seules colonnes nécessaires et appliquez les filtres de périmètre. Lorsque le connecteur et la source le permettent, Power Query peut traduire ces étapes en requête exécutée côté source : c’est le repliement de requête, ou query folding. Il limite les données transférées et exploite le moteur de la base de données, généralement mieux placé pour filtrer et agréger.

La possibilité de vérifier le repliement dépend de la source et de l’étape concernée. Certaines transformations personnalisées, certains connecteurs ou un ordre d’étapes défavorable empêchent sa poursuite. Ne vous contentez donc pas de supposer qu’un filtre est exécuté en amont : vérifiez-le quand l’option est disponible, discutez avec l’équipe qui administre la source, et contrôlez les temps d’actualisation.

• Préférez une vue ou une requête préparée dans la source lorsque la logique est stable, partagée et lourde à exécuter dans Power BI.
• Utilisez des paramètres pour rendre explicites une période, un environnement ou un périmètre, plutôt que de disperser des valeurs fixes dans les requêtes.
• Conservez des types de données justes : convertir sans nécessité un entier en texte, ou garder une précision excessive, peut alourdir le modèle et compliquer les jointures.
• Évitez de charger les requêtes d’étape : une requête de préparation utile à d’autres requêtes peut rester présente tout en ayant son chargement désactivé.

Construire un modèle léger, lisible et fiable

Un modèle performant est souvent un modèle simple. La structure de référence est le schéma en étoile : une ou plusieurs tables de faits, contenant les événements mesurables, reliées à des dimensions descriptives telles que Date, Produit, Client, Site ou Équipe. Les dimensions filtrent les faits ; les mesures agrègent les données de faits. Cette organisation facilite les requêtes, la compréhension des calculs et la maintenance.

Évitez autant que possible d’importer une grande table « plate » où chaque libellé est répété à chaque transaction. Isoler les attributs descriptifs dans des dimensions réduit la répétition, clarifie les relations et rend les segments plus cohérents. Utilisez des clés stables, idéalement numériques lorsqu’elles existent, mais ne modifiez jamais une clé métier sans vérifier l’unicité et les règles de jointure.

Traiter la cardinalité et le grain avec discernement

La cardinalité correspond au nombre de valeurs distinctes d’une colonne. Les colonnes à très forte cardinalité sont souvent coûteuses à stocker et parfois peu utiles aux analyses agrégées : texte libre, URL, commentaires, identifiants techniques uniques, horodatages très précis ou codes de trace. Demandez-vous si elles doivent figurer dans le modèle principal, être déplacées vers une table de détail consultable à la demande, ou être remplacées par une version analytique, par exemple une date plutôt qu’un horodatage lorsque l’heure n’est pas analysée.

Le grain mérite la même attention. Une table de ventes au niveau ligne de ticket est nécessaire pour certains contrôles ; elle est superflue dans un rapport qui ne présente que des résultats mensuels par région. Dans ce dernier cas, une table agrégée peut suffire pour la majorité des pages, à condition de définir précisément les règles : somme des montants, nombre distinct de clients, moyenne pondérée, annulations et retours ne s’agrègent pas tous de la même façon.

Limitez aussi les relations bidirectionnelles aux cas réellement justifiés. Elles peuvent rendre les filtres difficiles à prévoir et augmenter le coût des requêtes. Une relation active à sens unique entre dimension et fait est généralement le point de départ le plus robuste. Les relations plusieurs-à-plusieurs et les tables de pont sont parfois nécessaires, mais elles demandent une modélisation et des tests renforcés.

Enfin, préférez les mesures aux colonnes calculées lorsque le résultat n’a pas besoin d’être stocké ligne par ligne. Une mesure est calculée selon le contexte du visuel ; elle réduit souvent la taille du modèle, mais une mesure mal écrite peut ralentir les requêtes. Le choix doit donc reposer sur la sémantique et sur une mesure effective de performance, non sur une règle mécanique.

Adapter le stockage et l’actualisation au volume réel

Le « jeûne » ne se résume pas à importer moins : il consiste aussi à ne retraiter que ce qui a changé. Pour les tables factuelles qui s’enrichissent dans le temps, l’actualisation incrémentielle permet de partitionner les données selon une période et de rafraîchir principalement les partitions récentes, tout en conservant l’historique défini. Sa mise en œuvre suppose notamment un champ de date ou date-heure fiable, des paramètres de plage dans Power Query et une politique configurée après publication dans le service Power BI.

Il ne s’agit pas d’une solution magique. Si le filtre de dates ne se replie pas vers la source, ou si les données anciennes sont régulièrement modifiées sans mécanisme de détection adapté, le bénéfice peut être limité et le risque d’écart réel. Validez les règles de correction d’historique avec les équipes métier et techniques.

Les agrégations, quant à elles, visent surtout à accélérer les consultations. Elles permettent à Power BI de répondre à certaines requêtes par une table synthétique plutôt que par une table détaillée, lorsque le niveau demandé le permet. Elles sont pertinentes pour des modèles importants et des usages très répétitifs, mais demandent une correspondance rigoureuse entre les colonnes agrégées, les dimensions et les mesures.

Le choix entre Import, DirectQuery et un modèle composite ne doit pas être dicté par la seule taille d’une table. Le mode Import offre en général une expérience interactive très performante grâce au moteur en mémoire, en contrepartie d’une actualisation planifiée et de contraintes de capacité. DirectQuery peut convenir à un besoin de fraîcheur plus immédiate ou à des volumes difficilement importables, mais reporte une part de la charge sur la source et expose davantage aux latences. Un modèle composite peut associer détail et agrégats, au prix d’une architecture plus exigeante.

Accélérer les pages, les visuels et les mesures DAX

Un modèle aminci ne garantit pas une page rapide. Une page peut contenir trop de visuels, trop de segments, des interactions croisées inutiles ou des tableaux affichant des milliers de lignes. Chaque objet peut générer une ou plusieurs requêtes ; les segments à très forte cardinalité, comme une liste de dizaines de milliers de clients, dégradent fréquemment l’expérience et n’aident pas l’utilisateur à choisir.

Concevez chaque page autour d’une question décisionnelle. Limitez les visuels aux éléments qui y répondent, désactivez les interactions sans intérêt, utilisez le forage ou des pages de détail pour les analyses secondaires, et privilégiez des filtres hiérarchiques ou une recherche plutôt qu’une liste interminable. Les info-bulles de page et les pages dédiées au détail permettent de conserver de la richesse sans tout calculer et afficher simultanément.

Côté DAX, partez de mesures simples et nommées selon les conventions métier. Les itérateurs sur de très grandes tables, les filtres appliqués à des tables entières ou les calculs de distincts répétés méritent une attention particulière. Il n’existe pas de formule universellement « rapide » : la performance dépend de la structure du modèle, du contexte de filtre et du moteur. L’Analyseur de performances puis l’examen des requêtes générées permettront de cibler les mesures qui coûtent réellement.

La meilleure optimisation n’est pas celle qui produit le modèle le plus petit ; c’est celle qui fournit une réponse fiable au moment où la décision doit être prise.

Une méthode concrète pour appliquer cette sobriété des données

Pour éviter de transformer un projet en succession de suppressions irréversibles, adoptez une démarche courte, itérative et documentée :

1. Inventoriez les usages. Recensez les pages, mesures, exports, règles de sécurité, besoins de détail et exigences de conservation.
2. Établissez une référence. Notez la taille du modèle, le temps d’actualisation et le temps de réponse des pages ou visuels problématiques.
3. Traitez la source en premier. Filtrez le périmètre, sélectionnez les colonnes et favorisez les opérations exécutées par la base lorsque cela est possible.
4. Nettoyez le modèle. Retirez les tables et colonnes sans usage, désactivez le chargement des requêtes d’étape, corrigez les types et rapprochez-vous d’un schéma en étoile.
5. Choisissez le bon niveau de détail. Conservez le transactionnel quand il est nécessaire ; créez des agrégats lorsque les usages sont principalement synthétiques.
6. Optimisez l’actualisation et les pages. Étudiez l’incrémentiel, les agrégations et les visuels les plus coûteux, en les testant séparément.
7. Validez et documentez. Comparez les indicateurs à une source de référence, testez les cas limites et consignez le périmètre retiré, les hypothèses et les impacts attendus.

Cette dernière étape protège la confiance dans le rapport. Toute réduction doit être accompagnée d’un contrôle fonctionnel : totaux par période, cas d’annulation, valeurs nulles, changements de dimension, utilisateurs soumis à la sécurité au niveau des lignes. Une donnée absente peut rendre un tableau de bord plus rapide, mais aussi changer silencieusement un taux, un dénominateur ou une comparaison historique.

En définitive, utiliser le « jeûne » dans Power BI revient à pratiquer une sobriété analytique gouvernée. On importe moins, mais mieux ; on calcule à bon escient ; on préserve le détail là où il a une valeur prouvée. Cette discipline améliore autant la vitesse que la lisibilité des rapports, tout en donnant aux utilisateurs une base de décision plus fiable.