Le sens unique qui protège vos totaux
Construire un modèle en étoile dans Power BI : une table de faits, trois dimensions, et une règle simple sur le sens du filtre qui décide si vos totaux resteront cohérents.

Dans le cadre de la rubrique « Je partage mes connaissances », je vous propose de construire un modèle sémantique complet dans Power BI Desktop : une table de faits et trois dimensions, reliées les unes aux autres selon une forme précise. Cette forme n'est pas cosmétique. Elle décide si une mesure DAX répond de façon prévisible, ou si elle se contredit selon l'angle sous lequel on la regarde.
Une table au centre, des dimensions autour
Le réflexe le plus courant, quand on importe plusieurs fichiers dans Power BI, c'est de les relier au fur et à mesure des besoins, sans plan d'ensemble. Une relation en amène une autre, puis une troisième reliée à la deuxième plutôt qu'à la première. Le modèle fonctionne un moment, puis une mesure renvoie un total qui double ou qui disparaît selon le visuel où on la dépose.
Le schéma en étoile évite ce problème par construction. Une table de faits porte les événements — ici, les écritures comptables, une ligne par écriture. Autour d'elle, des tables de dimensions portent le contexte : le compte et sa hiérarchie, le centre de coûts, le calendrier. Chaque dimension se relie directement à la table de faits, jamais à une autre dimension. Le schéma inverse — une dimension reliée à une autre dimension plutôt qu'à la table de faits — porte un nom : le flocon. Il complique l'écriture des mesures et ralentit chaque rafraîchissement, pour un bénéfice qui, dans un modèle de cette taille, n'existe pas.
Le vocabulaire, avant de cliquer
- Table de faits : la table la plus longue, la plus étroite, celle qui ne descend jamais en dessous du grain qu'on a choisi — ici, la ligne d'écriture.
- Dimension : une table courte et large, qui répond à une question de contexte (quel compte, quel centre de coûts, quelle date), jamais à une question de montant.
- Cardinalité : le rapport entre les deux tables d'une relation. Un compte peut apparaître dans des dizaines d'écritures ; une écriture ne porte qu'un seul compte. C'est une relation un-vers-plusieurs.
- Direction du filtre : le sens dans lequel un filtre appliqué sur une table se propage vers l'autre. Sur un modèle à une seule table de faits, elle reste unique, dirigée vers cette table de faits — jamais dans les deux sens.
Construire le modèle, étape par étape
- Importer les trois fichiers de cet article (Accueil, Obtenir les données, Texte/CSV). Dans l'éditeur Power Query, vérifier que les colonnes Débit et Crédit sont bien typées en nombre décimal.
- Créer une quatrième table, directement en DAX, pour le calendrier :
Dim_Calendrier = CALENDAR(DATE(2025,1,1), DATE(2026,12,31)), puis ajouter Année, Trimestre, Mois et NomMois par colonnes calculées. Clic droit sur la table, Marquer comme table de dates, choisir la colonne Date. - Dans la vue Modèle, glisser Fait_Ecritures[Compte] vers Dim_PlanComptable[Compte], Fait_Ecritures[Journal] vers Dim_CentreCouts[Journal], Fait_Ecritures[Date] vers Dim_Calendrier[Date].
- Pour chaque relation créée, ouvrir Modifier la relation et vérifier deux choses : la cardinalité affiche « Un vers plusieurs (1:*) », et la direction du filtre affiche « Unique », jamais « Les deux ».
- Dans Dim_PlanComptable et Dim_CentreCouts, masquer dans la vue rapport les colonnes qui ne servent qu'aux relations (Compte, Journal, CentreCoutsID), pour ne laisser visibles que les colonnes utiles à la lecture.
Les paramètres régionaux de l'import comptent autant que les relations. Un fichier français lu avec les paramètres régionaux par défaut du poste de travail peut faire lire la virgule décimale comme un séparateur de texte : Débit et Crédit deviennent alors des colonnes de texte, et toute somme DAX dessus renvoie une erreur silencieuse ou un résultat nul. Fixer explicitement Français (France) au moment de l'import.
Vérifier ce qu'on vient de construire
Énoncé
Avant d'écrire la moindre mesure, prouver que le modèle est correctement formé : le nombre exact de relations actives, leur cardinalité, leur direction, et la présence de la table de dates.
Solution
- Ouvrir la vue Modèle. Les quatre tables doivent apparaître, Fait_Ecritures au centre, les trois dimensions autour, chacune reliée par une seule ligne.
- Cliquer sur chaque ligne de relation pour confirmer cardinalité et direction dans le panneau de droite.
- Dans Fichier, Options et paramètres, Options, onglet Données en cours : décocher la détection automatique de nouvelles relations, pour qu'un futur rafraîchissement n'en crée pas une en double.
- Vérifier la présence de l'icône calendrier à côté de Dim_Calendrier dans la vue Modèle : la preuve visuelle qu'elle est marquée comme table de dates.
Résultat attendu
| Relation | Cardinalité | Direction du filtre |
|---|---|---|
| Fait_Ecritures[Compte] → Dim_PlanComptable[Compte] | 1:* | Unique |
| Fait_Ecritures[Journal] → Dim_CentreCouts[Journal] | 1:* | Unique |
| Fait_Ecritures[Date] → Dim_Calendrier[Date] | 1:* | Unique |
Trois relations actives, aucune ligne pointillée — une ligne pointillée signalerait une relation inactive, ce qui n'a pas lieu d'être ici puisqu'il n'existe qu'une seule table de faits.
Ce qui casse si le filtre circule dans les deux sens
Sur un modèle à une seule table de faits, une direction de filtre « Les deux » ne se voit pas tout de suite : les totaux simples continuent de sortir juste. Le problème apparaît le jour où une deuxième dimension filtre en même temps que la première — un visuel croisant Centre de coûts et Catégorie comptable, par exemple. Le filtre bidirectionnel laisse alors une dimension influencer l'autre à travers la table de faits, et une carte affiche un total qui ne correspond à aucune combinaison réelle du grand livre. La règle est donc préventive : direction unique vers la table de faits, toujours, sauf besoin explicite et documenté du contraire.
Le modèle tient debout, mais un test simple le fait vaciller : une mesure qui additionne les charges et les produits sans y toucher renvoie un résultat négatif là où on attend un chiffre d'affaires positif. La suite explique pourquoi, et comment un signe mal posé peut fausser un compte de résultat entier : Le moins qui manque à l'addition.
Versions : article rédigé d'après Power BI Desktop, mise à jour d'août 2026 (interface en français). Les fonctions DAX utilisées (CALENDAR) sont disponibles dans les versions actuelles ; les noms de menus peuvent changer au fil des mises à jour mensuelles.