Modèle en étoile Power BI : le guide pour bien démarrer

Un modèle en étoile organise vos données Power BI autour d’une table de faits centrale (les ventes, les tickets, les heures saisies) reliée par des relations un-à-plusieurs à des tables de dimensions (dates, clients, produits). Les dimensions servent à filtrer et regrouper, la table de faits à calculer. C’est la structure que Microsoft recommande pour obtenir des rapports rapides, des chiffres justes et un DAX simple. Voici comment la construire et les erreurs à éviter.

Qu’est-ce qu’un modèle en étoile dans Power BI ?

Le schéma en étoile vient de la modélisation des entrepôts de données. Le principe : chaque table du modèle a un seul rôle, soit fait, soit dimension. Dessiné dans la vue Modèle, on obtient une table au centre et des tables autour : une étoile.

Les tables de faits : ce qui se passe

Une table de faits enregistre des événements ou des observations : une ligne de commande, un ticket de support, une écriture comptable, une inscription. Elle contient :

des clés vers les dimensions (date, identifiant client, identifiant produit) ;
des valeurs numériques à agréger (quantité, montant, durée).

Elle a souvent beaucoup de lignes et grossit avec le temps. Sa granularité, c’est-à-dire ce que représente une ligne, doit être claire et constante : « une ligne = une ligne de commande », pas un mélange de lignes et de totaux.

Les tables de dimensions : qui, quoi, où, quand

Une table de dimension décrit les entités de l’activité : clients, produits, magasins, collaborateurs, dates. Elle contient une clé unique (une ligne par client, par produit…) et des colonnes descriptives qui serviront à filtrer et regrouper : nom, catégorie, ville, segment.

Exemple pour une activité commerciale :

Table	Rôle	Exemples de colonnes
Ventes	Faits	Date, IdClient, IdProduit, Quantité, Montant
Dates	Dimension	Date, Année, Mois, Trimestre
Clients	Dimension	IdClient, Nom, Ville, Segment
Produits	Dimension	IdProduit, Libellé, Catégorie, Gamme

Pourquoi le modèle en étoile est-il si important ?

Chaque visuel d’un rapport envoie une requête au modèle : filtrer, regrouper, résumer. Le modèle en étoile répond exactement à ce schéma : les dimensions filtrent et regroupent, les faits se résument. Résultat :

des performances meilleures, car les filtres partent de petites tables vers la grande ;
un DAX plus simple : les mesures comme SUM(Ventes[Montant]) fonctionnent naturellement par client, par produit ou par mois ;
un volet Données lisible pour les auteurs de rapports, qui trouvent les champs là où ils les attendent ;
des chiffres cohérents d’un visuel à l’autre.

Comment construire un modèle en étoile, étape par étape

La plupart du temps, vous partez d’un export « à plat » : une seule table où chaque ligne de vente répète le nom du client, sa ville, le libellé et la catégorie du produit. Voici comment le transformer dans Power Query.

Importez la source et nettoyez-la : types, espaces, valeurs vides (voir Power Query : nettoyer vos données dans Excel et Power BI).
Créez une requête de référence pour chaque dimension (clic droit sur la requête > Référence), par exemple Produits.
Dans Produits, ne conservez que les colonnes du produit (IdProduit, Libellé, Catégorie, Gamme), puis supprimez les doublons sur la clé IdProduit.
Répétez l’opération pour Clients.
Dans la requête de faits Ventes, supprimez les colonnes descriptives désormais portées par les dimensions : ne gardez que les clés et les valeurs numériques.
Ajoutez une table de dates (voir ci-dessous).
Dans la vue Modèle, créez les relations entre chaque clé de dimension et la colonne correspondante de Ventes.

Si votre source n’a pas d’identifiant unique pour une dimension, ajoutez-en un dans Power Query avec une colonne d’index, puis fusionnez-le dans la table de faits.

La table de dates : indispensable

Les dates méritent leur propre dimension. Une table de dates contient une ligne par jour, sans trou, sur toute la période couverte, et les colonnes utiles à l’analyse. Vous pouvez la créer en DAX :

Dates =
ADDCOLUMNS(
    CALENDAR(DATE(2024, 1, 1), DATE(2026, 12, 31)),
    "Année", YEAR([Date]),
    "N° mois", MONTH([Date]),
    "Mois", FORMAT([Date], "mmmm"),
    "Trimestre", "T" & QUARTER([Date])
)

Ensuite :

reliez Dates[Date] à la colonne de date de la table de faits ;
si vous utilisez les fonctions de time intelligence classiques (TOTALYTD, SAMEPERIODLASTYEAR…), marquez-la comme table de dates (clic droit sur la table > Marquer comme table de dates) : Power BI vérifie alors que les dates sont uniques, sans valeur vide et contiguës ;
triez la colonne Mois par N° mois, sinon les mois s’affichent par ordre alphabétique ;
envisagez de désactiver l’option Date/heure automatique, qui crée une table de dates masquée pour chaque colonne de date et alourdit le modèle.

Une table de dates partagée permet aussi d’analyser plusieurs tables de faits (ventes et objectifs, par exemple) sur le même axe temporel.

Relations un-à-plusieurs et sens du filtrage

La relation un-à-plusieurs (1-N)

Dans un modèle en étoile, chaque relation relie le côté « un » (la dimension, où chaque clé est unique) au côté « plusieurs » (la table de faits, où la clé se répète). Un client apparaît une fois dans Clients et autant de fois qu’il a d’achats dans Ventes.

Si Power BI propose une relation plusieurs-à-plusieurs alors que vous attendiez du 1-N, c’est presque toujours le signe de doublons dans la dimension : à corriger dans Power Query plutôt qu’à contourner.

Le sens du filtrage : de la dimension vers les faits

Par défaut, le filtre circule dans un seul sens : de la dimension vers la table de faits. Sélectionner « Lyon » dans un segment filtre les clients lyonnais, qui filtrent leurs ventes. C’est le comportement souhaité dans l’immense majorité des cas.

Le filtrage bidirectionnel fait aussi remonter le filtre des faits vers la dimension. Microsoft recommande d’en limiter l’usage : il ajoute du traitement, peut dégrader les performances et rend parfois le comportement des segments déroutant pour les utilisateurs. Il a sa place dans des cas précis, comme certaines relations plusieurs-à-plusieurs passant par une table de liaison.

Pour les besoins courants, il existe de meilleures solutions :

pour n’afficher dans un segment que les valeurs ayant des données, appliquez au segment un filtre de niveau visuel « [mesure] n’est pas vide » ;
pour un calcul ponctuel, activez le bidirectionnel dans la mesure seulement, avec CROSSFILTER :

Nb produits vendus en Belgique =
CALCULATE(
    DISTINCTCOUNT(Produits[IdProduit]),
    CROSSFILTER(Produits[IdProduit], Ventes[IdProduit], BOTH),
    Clients[Pays] = "Belgique"
)

Plusieurs dates dans la table de faits

Une vente a souvent une date de commande et une date de livraison. Entre deux tables, une seule relation peut être active. Gardez la relation active sur la date la plus utilisée et activez l’autre dans une mesure :

CA par date de livraison =
CALCULATE([CA total], USERELATIONSHIP(Dates[Date], Ventes[DateLivraison]))

Les erreurs classiques à éviter

Tout garder dans une table plate. Ça marche au début, puis les calculs se compliquent, le modèle grossit et les comparaisons entre sources deviennent impossibles.
Activer le bidirectionnel partout « pour que ça marche ». C’est la cause de nombreux résultats incohérents et de rapports lents.
Des dimensions en flocon : Produits relié à Sous-catégories, relié à Catégories. Mieux vaut le plus souvent fusionner ces tables en une seule dimension Produits, ce qui permet aussi de créer une hiérarchie Catégorie > Sous-catégorie > Produit.
Relier deux tables de faits entre elles. Les faits se relient aux dimensions, jamais directement entre eux : passez par des dimensions communes (dates, produits).
Des clés de types différents (texte d’un côté, nombre de l’autre) : la relation échoue ou ne trouve pas de correspondances.
Mélanger les granularités dans une même table de faits, par exemple des ventes journalières et des objectifs mensuels : créez deux tables de faits distinctes.
Compenser un modèle bancal par du DAX : une colonne calculée de rattrapage cache souvent un problème de structure (voir Power BI mesure vs colonne calculée : laquelle choisir ?).

Se former à la modélisation Power BI

Le modèle en étoile est l’étape qui sépare les rapports fragiles des rapports fiables : c’est aussi la condition pour que le DAX devienne simple (voir DAX : 5 notions essentielles à maîtriser dans Power BI). Si vous cherchez l’ordre logique d’apprentissage, lisez Se former à Power BI : par où commencer ?. La formation Power BI — Perfectionnement DAX & modélisation consacre une large place à la modélisation, appliquée à vos propres cas avec nos experts. Pour découvrir les bases (Power Query, premières relations, visuels), Power BI — Fondamentaux est le bon point de départ.

Questions fréquentes

Le modèle en étoile est-il obligatoire dans Power BI ?

Non, Power BI accepte n’importe quelle structure. Mais c’est la conception recommandée par Microsoft : sans elle, vous obtiendrez plus vite des calculs faux, des rapports lents et un DAX compliqué.

Peut-on avoir plusieurs tables de faits dans un même modèle ?

Oui, et c’est fréquent : ventes, objectifs, stocks. Chacune se relie aux dimensions qu’elle partage (dates, produits). On parle parfois de « constellation ». L’essentiel est de ne pas relier les tables de faits directement entre elles.

Que faire si ma dimension contient des doublons ?

Supprimez-les dans Power Query sur la colonne clé, après avoir vérifié qu’il s’agit de vrais doublons et non de deux versions différentes d’un même client. Une clé unique côté dimension est indispensable pour une relation un-à-plusieurs.

Faut-il toujours créer sa propre table de dates ?

C’est fortement conseillé dès que vous analysez des évolutions dans le temps. Une table de dates explicite, partagée par toutes les tables de faits, vous donne la maîtrise des colonnes (exercice fiscal, semaine, jours ouvrés) et des calculs de time intelligence.