Modéliser en schéma en étoile dans Power BI

Un rapport Power BI lent, des totaux qui se contredisent d’une page à l’autre, des filtres qui ne propagent pas comme prévu : derrière ces symptômes se cache presque toujours le même problème, un modèle de données mal structuré. La bonne nouvelle, c’est qu’il existe une organisation éprouvée qui résout la majorité de ces difficultés : le schéma en étoile. C’est la fondation invisible sur laquelle reposent les rapports rapides et les calculs fiables.

Ce tutoriel fait partie d’une série sur Power BI et Microsoft Fabric ; pour situer la modélisation dans l’ensemble du parcours, le guide de référence Power BI et Microsoft Fabric donne la vue d’ensemble. Une fois vos données nettoyées (voir importer et nettoyer avec Power Query), l’étape suivante consiste à les organiser. C’est exactement l’objet de ce qui suit.

Prérequis

• Power BI Desktop installé, avec au moins deux tables chargées (par exemple des ventes et un référentiel produit).
• Des données déjà nettoyées et typées dans Power Query.
• Niveau : débutant à intermédiaire. Quelques notions de DAX aident mais ne sont pas indispensables.
• Temps estimé : 50 à 70 minutes.

Étape 1 — Distinguer les faits des dimensions

Tout part d’une distinction conceptuelle simple mais décisive. Une table de faits contient les événements mesurables de votre activité : une vente, une commande, un mouvement de stock. Chaque ligne y représente un fait daté et chiffré. Une table de dimensions contient les axes par lesquels on veut analyser ces faits : le produit, le client, la date, la région. Les dimensions répondent aux questions « par quoi ? » et « selon quel angle ? ».

Concrètement, demandez-vous pour chaque colonne : « est-ce une mesure que je vais additionner, ou un critère par lequel je vais filtrer et regrouper ? ». Les montants, quantités et durées vont dans les faits ; les libellés, catégories et identifiants descriptifs vont dans les dimensions. Cette séparation paraît théorique, mais c’est elle qui rend le modèle lisible et performant. Si vous gardez tout dans une seule grande table « à plat », Power BI fonctionne, mais les calculs deviennent ambigus et le moteur compresse moins bien les données.

Étape 2 — Identifier votre table de faits centrale

Dans un schéma en étoile, une table de faits trône au centre et les dimensions l’entourent comme les branches d’une étoile — d’où le nom. L’objectif de cette étape est de désigner clairement cette table centrale et de la débarrasser de tout ce qui n’est pas une mesure ou une clé.

Prenons une table de ventes. Elle devrait idéalement ne contenir que : les clés étrangères vers les dimensions (identifiant produit, identifiant client, date), et les valeurs numériques (quantité, montant, remise). Tout le reste — le nom du produit, la catégorie, l’adresse du client — n’a rien à faire ici : ces informations descriptives appartiennent aux dimensions. Garder le nom du produit dans la table de faits le répète des milliers de fois et gonfle inutilement le modèle. Le signal d’une bonne table de faits : elle est étroite (peu de colonnes) mais longue (beaucoup de lignes).

Étape 3 — Construire les tables de dimensions

Chaque dimension regroupe la description complète d’un axe d’analyse, sans répétition. Une dimension Produit liste chaque produit une seule fois, avec sa catégorie, sa marque, son prix de référence. Une dimension Client liste chaque client une fois, avec son segment et sa zone géographique. L’idée directrice est l’unicité : la clé d’une dimension ne doit jamais comporter de doublon.

Si vos dimensions n’existent pas encore en tant que tables séparées, vous pouvez les extraire depuis Power Query. À partir d’une table large, faites un clic droit sur la colonne clé, choisissez de supprimer les doublons, puis ne conservez que les colonnes descriptives. Vous obtenez ainsi une table de référence propre. Vérifiez ensuite que le nombre de lignes correspond au nombre réel de produits distincts : un écart révèle souvent des libellés incohérents (espaces, casse) qu’il faut normaliser en amont.

Étape 4 — Créer une table de dates dédiée

C’est l’étape que les débutants oublient le plus souvent, et celle qui débloque le plus de fonctionnalités. Sans table de dates dédiée, l’intelligence temporelle (cumuls annuels, comparaisons d’une année sur l’autre) devient pénible voire impossible. On crée donc une table de calendrier continue, indépendante, qui servira de dimension temps pour tout le modèle.

Dans Power BI Desktop, ouvrez l’onglet Modélisation et créez une nouvelle table avec cette formule DAX :

Calendrier =
ADDCOLUMNS(
    CALENDAR(DATE(2022,1,1), DATE(2026,12,31)),
    "Année", YEAR([Date]),
    "NumMois", MONTH([Date]),
    "Mois", FORMAT([Date], "MMMM"),
    "Trimestre", "T" & FORMAT([Date], "Q"),
    "JourSemaine", FORMAT([Date], "dddd")
)

La fonction CALENDAR génère une ligne par jour entre les deux bornes, et ADDCOLUMNS ajoute des colonnes calculées utiles pour le regroupement : l’année, le numéro de mois (pour trier), le nom du mois, le trimestre et le jour de la semaine. Adaptez les bornes à la profondeur réelle de vos données. Après validation, vous devez voir une table couvrant chaque jour de la période : c’est elle qui rendra possibles les analyses temporelles, détaillées dans le tutoriel DAX et intelligence temporelle.

Étape 5 — Créer les relations dans la vue Modèle

Les relations sont les fils qui relient les dimensions à la table de faits et permettent au filtrage de se propager. Sans relation, sélectionner un produit dans un graphique n’aurait aucun effet sur les ventes affichées ailleurs. On les crée et on les vérifie dans la vue dédiée.

Cliquez sur l’icône Vue Modèle dans la barre latérale gauche (l’icône représentant des tables reliées). Vous y voyez vos tables sous forme de cartes. Pour créer une relation, glissez la clé d’une dimension (par exemple IDProduit dans la dimension Produit) vers la clé correspondante dans la table de faits. Power BI trace alors une ligne entre les deux tables. Répétez pour chaque dimension, y compris la relation entre votre colonne de date dans les faits et la colonne Date du calendrier.

Le résultat visuel doit ressembler à une étoile : la table de faits au centre, chaque dimension reliée par un seul trait. Si vous voyez des relations entre deux dimensions, ou des traits en pointillés (relations inactives), notez-les : on y revient plus bas.

Étape 6 — Régler la cardinalité et le sens du filtre

Chaque relation possède deux propriétés que Power BI devine, mais qu’il faut toujours vérifier. La cardinalité décrit combien de lignes se correspondent de part et d’autre, et le sens du filtre croisé décrit dans quelle direction le filtrage se propage. Une relation mal réglée est la cause la plus fréquente des totaux incohérents.

Dans le cas normal d’un schéma en étoile, la relation entre une dimension et la table de faits est de type un-à-plusieurs (noté « 1 » côté dimension, « * » côté faits) : un produit apparaît dans plusieurs ventes, mais chaque vente concerne un seul produit. Le sens du filtre doit rester simple, de la dimension vers les faits. Double-cliquez sur une relation pour ouvrir sa boîte de dialogue et confirmer ces réglages. Le signal d’un bon paramétrage : quand vous sélectionnez un produit, les ventes se filtrent ; l’inverse n’est pas nécessaire.

Étape 7 — Éviter le flocon et les filtres bidirectionnels

Deux pièges guettent ceux qui débutent. Le premier est le flocon de neige : au lieu d’une dimension Produit autonome, on relie Produit à Catégorie, puis Catégorie à Famille, créant une chaîne. Cela fonctionne mais multiplie les relations et ralentit le moteur. Le réflexe à adopter : aplatir ces niveaux dans une seule dimension, quitte à répéter la catégorie sur chaque produit. La redondance dans une dimension est un coût négligeable, et la lisibilité y gagne énormément.

Le second piège est le filtre bidirectionnel. Il est tentant de l’activer pour « que tout filtre tout », mais il introduit des chemins de propagation ambigus et des risques de calculs faux ou de boucles. La règle de discipline : laissez tous les filtres en sens unique par défaut, et n’activez le bidirectionnel que dans des cas très précis et maîtrisés. Quand un besoin transversal se présente, il vaut presque toujours mieux le résoudre par une mesure DAX dédiée que par un filtre bidirectionnel.

Étape 8 — Soigner la présentation du modèle

Un modèle propre n’est pas qu’une affaire de performance : c’est aussi un outil que d’autres personnes vont utiliser. Deux gestes simples améliorent considérablement l’expérience. D’abord, masquez les colonnes techniques : les clés étrangères de la table de faits (les identifiants) ne servent jamais directement dans un visuel. Clic droit sur la colonne, Masquer dans la vue Rapport : elles restent actives pour les relations mais disparaissent de la liste des champs.

Ensuite, signalez explicitement votre table de calendrier comme table de dates. Sélectionnez-la, puis dans le ruban Outils de table, choisissez Marquer comme table de dates et désignez la colonne Date. Ce marquage indique à Power BI d’utiliser votre calendrier pour toutes les fonctions d’intelligence temporelle, au lieu des tables de dates automatiques cachées qu’il crée sinon — lesquelles gonflent le fichier et brouillent les calculs. Après ce marquage, une petite icône de calendrier apparaît sur la table : c’est le signal que tout est en ordre.

Étape 9 — Vérifier la cohérence du modèle

Avant de construire des rapports, une vérification finale évite des heures de débogage ultérieur. Créez une mesure de contrôle très simple, par exemple le total des ventes, et placez-la dans un visuel de type carte. Faites ensuite glisser, tour à tour, une colonne de chaque dimension dans un tableau à côté.

Si le total se ventile correctement par produit, par mois et par région, et que la somme des sous-totaux égale le grand total, votre modèle est sain. Si un total reste figé quel que soit le filtre appliqué, c’est qu’une relation manque ou pointe dans le mauvais sens. Si un total se duplique de façon inattendue, suspectez une dimension dont la clé comporte des doublons. Ce test de cohérence, mené méthodiquement dimension par dimension, est la meilleure assurance qualité d’un projet décisionnel.

Erreurs fréquentes

Tutoriels liés

• Importer et nettoyer avec Power Query — l’étape qui précède la modélisation.
• Maîtriser DAX : CALCULATE et intelligence temporelle — exploiter le modèle que vous venez de construire.
• Optimiser les performances d’un modèle — pour aller plus loin sur la compression et la mémoire.

Références

• Documentation Power BI (Microsoft Learn) : vue Modèle, création et gestion des relations, cardinalité et sens du filtre croisé.
• Guide « Comprendre le schéma en étoile et son importance pour Power BI » (Microsoft Learn).
• Référence DAX : fonctions CALENDAR, ADDCOLUMNS, et marquage d’une table de dates.

Questions fréquentes

Le schéma en étoile est-il toujours préférable à une table unique ?
Pour l’immense majorité des cas décisionnels, oui. Il améliore la compression, clarifie les calculs et accélère les requêtes. Une table unique ne se justifie que sur de très petits jeux de données jetables.

Faut-il une table de dates même pour un seul rapport ?
Oui, dès qu’une analyse temporelle est en jeu. C’est elle qui rend possibles les cumuls, les comparaisons de périodes et les filtres par trimestre, sans bricolage.

Combien de dimensions un modèle peut-il comporter ?
Autant que d’axes d’analyse pertinents : date, produit, client, région, canal, etc. L’important n’est pas le nombre mais le respect du principe — une table de faits centrale, des dimensions propres autour.

Que faire si deux tables de faits partagent des dimensions ?
C’est le schéma « en constellation ». Les mêmes dimensions (date, produit) se relient à plusieurs tables de faits. C’est parfaitement valide et constitue l’extension naturelle de l’étoile.