Modèle sémantique

Le modèle sémantique est le contrat entre les données et les décisions. Ce thème mesure à quel point il est lisible, stable, juste et évolutif : schéma en étoile, relations et cardinalités…

Guide≈ 7 min de lectureVérifiéLecture

En bref

Le modèle sémantique est le contrat entre les données et les décisions. Ce thème mesure à quel point il est lisible, stable, juste et évolutif : schéma en étoile, relations et cardinalités explicites, direction de filtre maîtrisée, calendrier dédié, rôles des dimensions, hiérarchies, métadonnées. Voir le glossaire pour les termes.

Sur cette page

1. Pourquoi ce thème
2. Ce que mesure le thème
3. Les 5 niveaux
4. Jalons par niveau
5. Lecture détaillée par niveau
6. Atteinte partielle et notation
7. Passer au niveau suivant
8. Voir aussi

Niveau : 🟢→🔴 · Code thème : MOD

1. Pourquoi ce thème#

Un modèle mal construit rend tout le reste coûteux : mesures DAX contournant des relations ambiguës, filtres qui « fuient », agrégats faux dès qu'on change de visuel, performance dégradée, RLS contournable. Le coût d'un défaut de modèle croît avec le nombre de rapports qui s'y accrochent : corriger une relation après 40 rapports liés casse des filtres, des signets et des mesures. À l'inverse, une étoile propre rend les mesures courtes et les visuels prévisibles.

⚠️ Piège

Symptôme : « le total ne correspond pas à la somme des lignes ». Cause fréquente : relation plusieurs-à-plusieurs ou dimension dégénérée mal placée. Remède : revenir à une étoile, une table de faits par grain.

2. Ce que mesure le thème#

Axe : du « tableau de données aplati » au modèle contractuel, composable et évolutif.
Indicateur clé : part des tables conformes à l'étoile stricte, nombre de relations bidirectionnelles/plusieurs-à-plusieurs justifiées, nombre de rapports cassés par une évolution de modèle.
Unité : niveau 1 à 5 ; indicateurs de contrôle en % de tables / relations conformes.

3. Les 5 niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Plat	Les chiffres sortent, mais seul l'auteur sait pourquoi et ne peut pas les réutiliser.	1 table large ; relations automatiques non vérifiées
2	Étoile lisible	Un analyste qui ouvre le modèle comprend en 10 min où est chaque mesure et chaque axe.	> 70 % des tables classées fait/dimension
3	Étoile stricte	Les agrégats restent justes quel que soit le visuel, et un calendrier unique pilote tout le temps.	0 relation bidirectionnelle injustifiée ; 1 table de dates marquée
4	Contractuel	Une évolution du modèle est annoncée, versionnée, et ne casse aucun rapport lié sans préavis.	0 rapport cassé par évolution sur 12 mois
5	Composable	Plusieurs équipes bâtissent leurs rapports sur un modèle certifié, étendu par composition, sans le copier.	> 90 % des rapports branchés sur un modèle partagé

4. Jalons par niveau#

ID	Jalon	Preuve vérifiable
BI-MOD-1.1	Le modèle charge et produit des totaux utilisables	Rapport ouvrable, totaux contrôlés une fois
BI-MOD-1.2	Les données sources sont dans le modèle (import ou connexion), pas en copier-coller	Panneau de requêtes / source déclarée
BI-MOD-1.3	Les types de colonnes (nombre, date, texte) sont définis	Aucune colonne numérique en texte
BI-MOD-2.1	Chaque table est identifiée comme fait ou dimension	Convention de nommage (`FACT_`, `DIM_`) ou description
BI-MOD-2.2	Les relations sont créées volontairement (pas par détection automatique non revue)	Vue de modèle relue, relations désactivées si doutes
BI-MOD-2.3	Les colonnes techniques (clés, identifiants) sont masquées	Champs masqués dans la vue rapport
BI-MOD-2.4	Les mesures vivent dans une table ou un dossier dédié	Dossiers d'affichage des mesures
BI-MOD-3.1	Étoile stricte : faits reliés à des dimensions, pas de chaîne de flocons arbitraire	Diagramme du modèle sans table de faits reliée à une autre
BI-MOD-3.2	Cardinalité 1-plusieurs, filtre unidirectionnel par défaut ; toute exception est documentée	Liste des relations avec motif des exceptions
BI-MOD-3.3	Une table de dates dédiée, continue, marquée « table de dates »	Propriété posée ; plage couvre données + horizon
BI-MOD-3.4	Grain de chaque table de faits défini par écrit	Description : « une ligne par visite × produit »
BI-MOD-3.5	Hiérarchies (temps, géographie, produit) définies et testées	Hiérarchies visibles et exploitables en drill
BI-MOD-4.1	Rôles de dimension (date commande/livraison) traités par relations inactives + USERELATIONSHIP, ou calendriers jouant un rôle	Mesures nommées par rôle, documentées
BI-MOD-4.2	Clés de substitution stables et unicité contrôlées côté source	Test d'unicité des clés de dimension en pipeline
BI-MOD-4.3	Toute évolution du modèle suit un cycle : annonce, version, note de changement	Journal des changements du modèle
BI-MOD-4.4	Descriptions de tables, colonnes, mesures complètes (utilisées par Copilot/catalogue)	> 95 % des objets visibles décrits
BI-MOD-5.1	Modèle certifié réutilisé en connexion directe par d'autres rapports	Nombre de rapports « thin » (sans modèle propre)
BI-MOD-5.2	Extension par composition (modèle composite) plutôt que copie	Aucun clone divergent connu
BI-MOD-5.3	Dérive du modèle détectée automatiquement (schéma source vs modèle)	Alerte sur changement de colonne source
BI-MOD-5.4	Le modèle est un artefact d'architecture décrit (qui l'étend, comment, quel SLA)	Fiche de modèle publiée au catalogue

5. Lecture détaillée par niveau#

🟢 Niveau 1 — Plat#

Signes observables : une ou deux tables très larges (50+ colonnes), relations auto-détectées sans contrôle, colonnes calculées partout, noms de colonnes sources non retouchés.
Ce qu'on gagne : rapidité du premier résultat.
Ce que ça ne garantit pas : l'exactitude des agrégats, la réutilisation, la lecture par un tiers.
Difficulté d'atteinte : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Étoile lisible#

Signes : tables nommées par rôle, clés masquées, mesures regroupées ; l'étoile existe mais admet des écarts (une dimension reliée à une autre, quelques relations bidirectionnelles « pour que ça marche »).
Gain : onboarding d'un analyste en minutes, moins d'erreurs de lecture.
Limite : les exceptions ne sont pas justifiées ; pas de calendrier garanti.
Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Étoile stricte#

Signes : diagramme d'étoile net, calendrier unique marqué (table de dates), filtre unidirectionnel, grain écrit. Les relations plusieurs-à-plusieurs sont soit absentes, soit remplacées par une table de liaison (bridge) explicite.
Gain : DAX court et prévisible ; agrégats justes ; base saine pour la performance et la RLS.
Limite : le modèle reste « celui d'un projet » ; l'évolution se fait sans protocole.
Difficulté : 3/5 · Effort : 3/5.

🧪 Exemple

Fil rouge SFA : FACT_VISITE (grain visite × produit présenté), dimensions DIM_CLIENT, DIM_PRODUIT, DIM_COMMERCIAL, DIM_DATE. La visite planifiée et la visite réalisée se rapportent à deux dates : une relation active (réalisée) et une inactive (planifiée) activée par USERELATIONSHIP dans la mesure dédiée.

🟡 Niveau 4 — Contractuel#

Signes : le modèle a un propriétaire, une version, une note de changement ; les noms de colonnes ne changent pas sans raison (voir le fil rouge « une colonne garde son nom du datamart »). Les clés sont contrôlées avant chargement.
Gain : confiance des consommateurs, évolutions sans surprise.
Limite : l'effort de coordination ; le modèle reste un monolithe tant qu'il n'est pas composable.
Difficulté : 4/5 · Effort : 4/5.

🔴 Niveau 5 — Composable#

Signes : un modèle certifié, ses extensions locales (modèles composites avec chaînage de modèles), des rapports minces. Les changements de source sont détectés avant le chargement. Le modèle est décrit à destination des humains et des outils d'IA.
Gain : une seule vérité ; coût de duplication proche de zéro.
Limite : un modèle partagé devient un point de contention ; la gouvernance doit suivre (GOV).
Difficulté : 5/5 · Effort : 5/5.

✅ Bonne pratique

Écrivez le grain d'une table de faits en une phrase dans sa description. Si vous n'y arrivez pas, la table mélange deux grains.

💡 Astuce d'expert

Les relations 1-1 sont souvent le signe d'une dimension éclatée à tort : fusionnez-les (ou gardez-les seulement si un rôle de sécurité l'impose). Une dimension dégénérée (numéro de commande) peut vivre dans la table de faits.

🤖 IA

Un assistant peut proposer une étoile à partir d'un schéma et rédiger des descriptions de colonnes ; il ignore souvent le grain métier réel et suggère des relations bidirectionnelles. Relecture obligatoire.

6. Atteinte partielle et notation#

Score selon la règle commune du README. Exemple de « 5 partiel » : un modèle certifié existe et alimente 60 % des rapports, mais la détection de dérive de schéma est encore manuelle (BI-MOD-5.3 = 0,5) et deux rapports portent encore un modèle copié (BI-MOD-5.2 = 0,5) : moyenne des jalons de niveau 5 ≈ 0,75, score ≈ 4,74.

Preuves rapides : export du modèle en TMDL (voir IND) et lecture des relations ; analyse par Tabular Editor / BPA (TST).

7. Passer au niveau suivant#

Moyens possibles (facultatifs) — ce sont des leviers, pas la promesse :

Passage	Leviers possibles
1 → 2	Séparer faits et dimensions ; masquer les clés ; poser des noms parlants
2 → 3	Supprimer les bidirectionnels sans motif ; ajouter une table de dates ; écrire le grain
3 → 4	Créer un journal de changements ; tests d'unicité de clés ; propriétaire nommé
4 → 5	Modèle certifié + rapports minces ; modèle composite ; veille de dérive de schéma

Pièges et détournements (Goodhart) :

Viser « 0 relation bidirectionnelle » en dupliquant des dimensions pour le contourner : on masque le défaut, on ne le corrige pas.
Compter les descriptions sans les lire : 95 % de « Colonne client » ne valent rien.
Figer le modèle par peur de casser : le contrat n'est pas l'immobilisme.
Faux positif : un joli diagramme d'étoile alors que la table de faits mélange deux grains.

8. Voir aussi#

Thèmes voisins : ETL (alimentation) · DAX · PRF · RLS · GOV
Autres matrices : PD — modélisation et architecture · DL — architecture et conception
Contenus : Bonnes pratiques Power BI · SQL Server SaaS — architecture · OneLake — architecture · GDS et données SQL/BI

✻ Rédigé par Claude Sonnet 5.5