Modèle en étoile Power BI : des données brutes à des KPI fiables

Pourquoi le modèle compte plus que les visuels ?

Un rapport n'est fiable que si le modèle derrière l'est. Quand les données sont chargées dans une grande table plate, les filtres se comportent bizarrement, les totaux sont comptés deux fois et chaque nouveau graphique demande un contournement. Le schéma en étoile règle cela : c'est la structure pour laquelle le moteur de Power BI est conçu. Je l'ai appliqué dans un système décisionnel sur des données de sécurité sociale (voir le projet).

Qu'est-ce qu'un schéma en étoile ?

• Table de faits — une ligne par événement mesuré : une vente, un paiement, une déclaration. Elle contient des colonnes numériques (montant, quantité) et des clés vers les dimensions.
• Tables de dimensions — les attributs descriptifs pour filtrer et regrouper : Date, Client, Produit, Région.
• Relations — un-à-plusieurs de chaque dimension vers la table de faits, filtrage dans un seul sens.

           DimDate
              │
DimClient ─ FactVentes ─ DimProduit
              │
           DimRegion

Étape 1 — Définir le grain

Écrivez une phrase : « Une ligne de la table de faits = une ligne de facture » (ou un paiement, un jour par magasin…). Chaque colonne de la table de faits doit être vraie à ce grain. La plupart des erreurs de modélisation viennent du mélange de grains dans une même table.

Étape 2 — Nettoyer et structurer dans Power Query (ou en ETL en amont)

• Supprimer tôt les colonnes inutiles.
• Corriger les types (dates en dates, montants en décimaux).
• Normaliser codes et libellés (espaces, casse).
• Découper l'export plat en table de faits et dimensions, avec des clés de substitution si les clés sources sont désordonnées.

Pour des pipelines plus gros ou partagés, faites-le en amont. Dans le projet CNSS, l'ETL tournait sous KNIME et Python et alimentait un entrepôt MySQL utilisé par les tableaux de bord Tableau.

Étape 3 — Toujours ajouter une vraie table de dates

Ne comptez pas sur la date/heure automatique. Créez une table de dates, marquez-la comme table de dates et reliez-la à chaque colonne de date analysée :

DimDate =
ADDCOLUMNS (
    CALENDAR ( DATE ( 2020, 1, 1 ), DATE ( 2027, 12, 31 ) ),
    "Annee", YEAR ( [Date] ),
    "Mois", FORMAT ( [Date], "MMM" ),
    "NumeroMois", MONTH ( [Date] ),
    "AnneeMois", FORMAT ( [Date], "YYYY-MM" )
)

Étape 4 — Écrire des mesures, pas des colonnes calculées

Les mesures sont calculées à la requête et respectent les filtres. Quelques mesures qui couvrent la plupart des tableaux de bord :

Total Ventes = SUM ( FactVentes[Montant] )

Ventes N-1 =
CALCULATE ( [Total Ventes], SAMEPERIODLASTYEAR ( DimDate[Date] ) )

Evolution % =
DIVIDE ( [Total Ventes] - [Ventes N-1], [Ventes N-1] )

Ventes MTD = TOTALMTD ( [Total Ventes], DimDate[Date] )

Rangez toutes les mesures dans une table vide dédiée (par exemple _Mesures) pour les retrouver facilement.

Étape 5 — Vérifier les KPI avant de dessiner les pages

Comparez quelques totaux avec le système source : un mois, une région, un produit. S'ils ne correspondent pas, le problème vient du grain ou d'une relation, jamais du graphique. Ensuite seulement, concevez les pages : une question par page, le KPI principal en haut à gauche, les filtres sur le côté.

Erreurs fréquentes à éviter

• Des relations bidirectionnelles partout (elles créent des filtres ambigus).
• Des relations plusieurs-à-plusieurs entre deux tables de faits — passez par des dimensions communes.
• Des clés texte avec des espaces en fin qui cassent silencieusement les relations.
• Des dates codées en dur dans les mesures au lieu d'une table de dates.

Conseil pratique

Définissez le grain avant tout le reste. Une fois la table de faits correcte, chaque nouvel indicateur devient en général une courte mesure plutôt qu'une nouvelle table ou un contournement.

Besoin d'un tableau de bord Power BI ?

Je réalise des tableaux de bord Power BI et Looker Studio sur des modèles de données propres pour des entreprises au Maroc et à distance. Voir mes services ou me contacter.