i

Description

Pinces accrochées à un mur d’atelier, chacune entourée du contour tracé de sa place.

Source

Syced · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Bonnes pratiques Power BI transverses

Les pratiques qui valent quelle que soit la source (Fabric / OneLake ou SQL Server managé) : modèle en étoile, nommage, DAX, Power Query, RLS, performance, thèmes, accessibilité…

En bref

• Les pratiques qui valent quelle que soit la source (Fabric / OneLake ou SQL Server managé) : modèle en étoile, nommage, DAX, Power Query, RLS, performance, thèmes, accessibilité, multilingue, versionnement, déploiement, gouvernance.
• Vous saurez construire un modèle sémantique lisible, rapide, sécurisé et versionné, et le faire vivre sans casser les rapports qui le consomment (règle du lineageTag).
• Vous disposerez d'un catalogue de plus de quarante pièges classiques avec symptôme, cause et remède.
• Interprétation du dossier : « OneLake + applications mobiles SaaS » et « SQL Server managé en SaaS » sont définis dans le README du dossier ; ce fichier ne dépend d'aucun des deux.

Sur cette page

1. 1. Principes directeurs
   1. 🟢 Novice — Cinq idées à retenir
   2. 🟡 Pratique — Où se place chaque décision
2. 2. Modèle en étoile
   1. 🟢 Novice — Le principe
   2. 🟡 Pratique — Règles concrètes
   3. 🔴 Expert — Cas limites et variantes
3. 3. Nommage et conventions
   1. 🟢 Novice — Pourquoi nommer avec soin
   2. 🟡 Pratique — Convention proposée
4. 4. DAX
   1. 🟢 Novice — Les trois notions
   2. 🟡 Pratique — Écrire un DAX durable
   3. 🔴 Expert — Moteur, plans et mesures coûteuses
5. 5. Power Query et couche d'accès aux données
   1. 🟢 Novice — À quoi sert Power Query (et à quoi il ne sert pas)
   2. 🟡 Pratique — Règles
   3. 🔴 Expert — Fabric et SaaS
6. 6. Sécurité de niveau ligne (RLS) et autres protections
   1. 🟢 Novice — Le principe
   2. 🟡 Pratique — RLS statique et dynamique
   3. 🔴 Expert — Limites et interactions
7. 7. Performance
   1. 🟢 Novice — Les quatre leviers
   2. 🟡 Pratique — Méthode
   3. 🔴 Expert — Selon le mode de stockage
8. 8. Thèmes, visuels et accessibilité
   1. 🟢 Novice — Le thème comme contrat visuel
   2. 🟡 Pratique — Accessibilité
   3. 🔴 Expert — Gabarits et gouvernance du visuel
9. 9. Multilingue et traductions TMDL
   1. 🟢 Novice — Deux sujets distincts
   2. 🟡 Pratique — Traductions dans le modèle (cultures)
   3. 🔴 Expert — Pièges du multilingue
10. 10. PBIP, TMDL et Git
    1. 🟢 Novice — Pourquoi sortir du .pbix
    2. 🟡 Pratique — Règles de versionnement
    3. 🔴 Expert — Format de rapport et dérives
11. 11. Deployment pipelines et environnements
    1. 🟢 Novice — Dev, Test, Prod
    2. 🟡 Pratique — Règles
    3. 🔴 Expert — Cycle de vie complet
12. 12. Endorsement, catalogue et gouvernance
    1. 🟢 Novice — Rendre fiable ce qu'on partage
    2. 🟡 Pratique — Gouvernance utile, pas bureaucratique
    3. 🔴 Expert — Self-service sans chaos
13. 13. Mesures et lineageTag
    1. 🟢 Novice — Pourquoi c'est un sujet à part
    2. 🟡 Pratique — La règle absolue
    3. 🔴 Expert — Cas limites
14. 14. Tests et recette des chiffres
    1. 🟢 Novice — Tester un rapport, c'est tester des nombres
    2. 🟡 Pratique — Niveaux de test
    3. 🔴 Expert — Automatiser
15. 15. Documentation
    1. 🟡 Pratique — Ce qui doit être écrit
16. 16. Pièges classiques
    1. 16.1 Modèle
    2. 16.2 DAX
    3. 16.3 Power Query et données
    4. 16.4 Sécurité et gouvernance
    5. 16.5 Livraison et exploitation
    6. 16.6 Conception et adoption
17. 17. Contribution de l'IA
18. 18. Voir aussi

Niveau : 🟢→🔴

1. Principes directeurs#

🟢 Novice — Cinq idées à retenir#

1. Un rapport n'est que la vitrine d'un modèle. La qualité se joue dans le modèle sémantique (tables, relations, mesures) bien plus que dans la page.
2. Mettre la complexité à la source. Ce qui peut être calculé en amont (SQL, lakehouse) doit l'être : un calcul fait une fois en amont vaut mieux que mille fois à la requête. À l'inverse, un calcul qui dépend du contexte de filtre appartient au DAX.
3. Un nombre = une définition = une mesure. Un KPI qui existe en trois versions dans trois rapports est une dette de confiance.
4. Tout doit être reconstructible depuis des fichiers versionnés. Si le modèle n'existe que dans un .pbix sur un poste, il n'existe pas.
5. Mesurer avant d'optimiser, tester avant de livrer.

🟡 Pratique — Où se place chaque décision#

2. Modèle en étoile#

🟢 Novice — Le principe#

Un schéma en étoile (Kimball, The Data Warehouse Toolkit) sépare des tables de faits (événements mesurables : visites, commandes, relevés) et des tables de dimensions (descriptions : client, produit, date, utilisateur). Les dimensions filtrent les faits, jamais l'inverse, au moins dans le sens principal : la relation est un-à-plusieurs, côté « un » = dimension, avec filtrage de la dimension vers le fait.

            DIM_Date
               │
 DIM_Client ── FACT_Visite ── DIM_Produit
               │
          DIM_Utilisateur

Pourquoi : le moteur colonne de Power BI (VertiPaq) compresse très bien les colonnes à faible cardinalité et répond vite à des filtres propagés de petites tables vers de grandes ; un modèle « plat » ou en flocon profond coûte en mémoire, en lisibilité et en risques d'ambiguïté.

🟡 Pratique — Règles concrètes#

🔴 Expert — Cas limites et variantes#

• Dimensions à évolution lente (SCD). Type 2 : une ligne par version de l'attribut, avec bornes de validité. Dans Power BI, joindre le fait sur la clé de substitution de la version valide au moment de l'événement, pas sur la clé naturelle. Documenter si le rapport montre « l'attribut au moment de l'événement » ou « l'attribut actuel ».
• Rôles multiples d'une dimension (ex. employé créateur, employé vendeur) : plusieurs relations vers la même dimension (une active) ou plusieurs copies de la dimension ; choisir selon le besoin de filtrer simultanément.
• Tables de faits de grains différents (prévision à la semaine, réel au jour) : dimensions conformes partagées et mesures qui gèrent explicitement le grain (agrégation à la semaine).
• Semi-additivité (stocks, effectifs) : mesure dédiée (LASTNONBLANK, instantané à la dernière date) ; ne jamais exposer la colonne brute à sommer.
• Calculation groups pour les variantes de temps (cumul annuel, N-1, variation) : réduisent les dizaines de mesures dérivées, au prix d'un outillage (Tabular Editor, TMDL ou l'éditeur de groupes de calcul de Desktop) et d'une lisibilité à soigner.
• Agrégations (tables d'agrégats en Import devant une table DirectQuery) : gagnent un ordre de grandeur sur les grandes tables, à condition de tester que les requêtes « tombent » bien sur l'agrégat.

3. Nommage et conventions#

🟢 Novice — Pourquoi nommer avec soin#

Le nom est la première documentation. Un utilisateur self-service choisit une mesure par son nom ; un développeur retrouve le code par son nom. Les noms de colonne qui viennent d'une source doivent rester identiques à ceux de la source : renommer côté Power Query casse la traçabilité et complique l'actualisation du schéma. Les libellés destinés à l'utilisateur passent par les traductions (§ 9), pas par des alias.

🟡 Pratique — Convention proposée#

Règles de forme : une casse cohérente, pas d'abréviation interne obscure, pas de caractères qui compliquent le DAX ou le TMDL (apostrophes en nom de table, par exemple), un suffixe d'unité quand deux mesures ne diffèrent que par l'unité (%, k€), et des déclinaisons nommées de façon systématique (base, variante, période).

4. DAX#

🟢 Novice — Les trois notions#

• Contexte de ligne : « la ligne en cours » (colonne calculée, itérateur).
• Contexte de filtre : l'ensemble des filtres actifs (segments, lignes/colonnes du visuel, relations, RLS).
• Transition de contexte : CALCULATE transforme un contexte de ligne en contexte de filtre.

Chiffre d'affaires = SUM ( FACT_Commande[Montant] )

Chiffre d'affaires N-1 =
CALCULATE ( [Chiffre d'affaires], SAMEPERIODLASTYEAR ( DIM_Date[Date] ) )

Préférer une mesure à une colonne calculée dès que la valeur dépend du filtre ; une colonne calculée est stockée (mémoire) et recalculée à l'actualisation.

🟡 Pratique — Écrire un DAX durable#

1. Variables (VAR/RETURN) : lisibilité, évaluation unique, débogage plus simple.
2. Division sûre : DIVIDE ( num, den ) plutôt que / pour gérer le dénominateur nul.
3. Pas de IFERROR systématique : il masque des erreurs de modèle ; traiter la cause.
4. Filtres sur colonnes, pas sur tables : CALCULATE ( [M], DIM_Client[Pays] = "FR" ) — un filtre de table entière (FILTER ( ALL ( Table ), ... )) est lent et sur-contraint.
5. Mesures de base réutilisées : chaque KPI dérivé s'appuie sur une mesure de base unique, pas sur une copie de la formule.
6. Itérateurs avec parcimonie : SUMX sur une grande table coûte ; si l'expression n'est pas dépendante de la ligne, utiliser SUM.
7. Intelligence temporelle avec la table de dates marquée ; éviter les calculs temporels sur des colonnes de date du fait.
8. Mesures « % » : séparer numérateur, dénominateur, ratio pour tester chaque terme.
9. Formatage : une mise en forme normalisée (DAX Formatter ou outil équivalent) rend les revues lisibles.

Taux de couverture % =
VAR _Visites   = CALCULATE ( DISTINCTCOUNT ( FACT_Visite[ID_Client] ) )
VAR _Portefeuille =
    CALCULATE (
        DISTINCTCOUNT ( DIM_Client[ID_Client] ),
        REMOVEFILTERS ( FACT_Visite )
    )
RETURN
    DIVIDE ( _Visites, _Portefeuille )

🔴 Expert — Moteur, plans et mesures coûteuses#

• Deux moteurs : le moteur de formule (évalue le DAX, mono-thread) et le moteur de stockage (VertiPaq : requêtes xmSQL, multi-thread). Une mesure lente est presque toujours une mesure qui sollicite beaucoup le moteur de formule (itérateurs imbriqués, matérialisations volumineuses) ou qui provoque de nombreux callbacks.
• Outils d'analyse : Performance Analyzer (dans Desktop) pour repérer le visuel coupable, DAX Studio (requêtes, plans, Server Timings) pour comprendre, Tabular Editor pour les scripts et règles de bonnes pratiques (Best Practice Analyzer), et la vue DAX query de Desktop.
• Cardinalité : une colonne texte à forte cardinalité (identifiants, horodatages à la seconde) pèse lourd ; scinder date et heure, tronquer, ou ne pas importer.
• Colonnes calculées en cascade : éviter ; préférer calcul en amont.
• Relations inactives et USERELATIONSHIP : à tester sous RLS (le comportement de sécurité et les relations inactives demande une vérification explicite).
• Mesures à évaluation par lot : la fonction SUMMARIZECOLUMNS est généralement plus efficace que des combinaisons de ADDCOLUMNS/SUMMARIZE pour les tables de requête ; réfléchir au grain de sortie.
• Valeurs vides : une mesure qui retourne 0 au lieu de BLANK() force l'affichage de toutes les combinaisons (lignes vides) et dégrade les performances ; retourner BLANK() quand « pas de donnée » est sémantiquement vrai.

5. Power Query et couche d'accès aux données#

🟢 Novice — À quoi sert Power Query (et à quoi il ne sert pas)#

Power Query (langage M) charge et prépare les données : connexion, typage, filtres de lignes, fusion. Il n'est pas un moteur de transformation industriel : il convient à du nettoyage léger, pas à des jointures de centaines de millions de lignes.

🟡 Pratique — Règles#

let
    Source = Sql.Database(Serveur, Base),
    Faits = Source{[Schema = "dbo", Item = "FACT_Visite"]}[Data],
    Filtrage = Table.SelectRows(
        Faits,
        each [DateModification] >= RangeStart and [DateModification] < RangeEnd
    )
in
    Filtrage

🔴 Expert — Fabric et SaaS#

• Avec Direct Lake, Power Query disparaît de la lecture des données du modèle : la préparation vit dans le lakehouse/warehouse (notebooks, pipelines, dataflows Gen2). Les règles de nommage et de typage se déplacent en amont ; garder leur discipline. Voir 02 — architecture OneLake.
• Les dataflows Gen2 servent à des préparations répétables par des profils moins techniques, mais consomment de la capacité : mesurer.
• Les sources SaaS exposent des API à quotas : isoler l'extraction dans un composant dédié (pipeline, fonction) avec reprise, pas dans une requête Power Query interactive. Voir 03 — difficultés et pièges (OneLake).
• Côté SQL managé : exposer des vues de reporting versionnées et testées ; voir 06 — architecture SQL Server.

6. Sécurité de niveau ligne (RLS) et autres protections#

🟢 Novice — Le principe#

La RLS limite les lignes visibles par utilisateur ou groupe. Définie dans le modèle sémantique, avec des rôles dont les expressions filtrent des tables (généralement des dimensions) ; les filtres se propagent aux faits par les relations.

🟡 Pratique — RLS statique et dynamique#

• Statique : un rôle par périmètre ([Pays] = "FR"). Simple, mais prolifère.
• Dynamique : table de correspondance utilisateur → périmètre et filtre sur USERPRINCIPALNAME().

-- Rôle « Représentant » sur DIM_Utilisateur
[Email] = USERPRINCIPALNAME ()

🔴 Expert — Limites et interactions#

• OLS (sécurité de niveau objet) masque colonnes ou tables ; à combiner avec la RLS, avec les limites de compatibilité des outils clients.
• Propriétaires de l'espace de travail et rôles Contributeur/Membre/Administrateur contournent la RLS : ne donnez pas ces rôles aux consommateurs.
• Direct Lake / SQL endpoint / DirectQuery : la sécurité doit être pensée aux deux niveaux (modèle et source) ; le comportement dépend de l'identité utilisée (SSO ou compte fixe) et des états de fonctionnalité de la plateforme (à vérifier, état 2026-10).
• Intégration (rapports intégrés dans une application) : l'identité effective et les rôles se passent dans le jeton d'intégration ; une erreur ici est une fuite de données.
• Performance : une expression RLS qui référence des tables volumineuses ou utilise des fonctions coûteuses se paie à chaque requête de chaque utilisateur.
• Cache : les caches de visuels et de requêtes sont partitionnés par identité de sécurité ; beaucoup de rôles distincts réduisent le taux de succès du cache.
• Données sensibles : étiquettes de sensibilité, restrictions d'export, pas de données personnelles inutiles dans le modèle (minimisation RGPD).

7. Performance#

🟢 Novice — Les quatre leviers#

1. Moins de données : colonnes et lignes strictement nécessaires.
2. Meilleur modèle : étoile, relations simples, types adaptés.
3. Mesures efficaces (§ 4).
4. Moins de visuels par page : chaque visuel déclenche au moins une requête.

🟡 Pratique — Méthode#

Bonnes pratiques de page : peu de visuels (une dizaine) ; segments en liste déroulante plutôt qu'en longue liste ; filtres de page appliqués plutôt que mesures exclues ; info-bulles de page conçues pour être légères ; boutons de signet plutôt que dix pages quasi identiques ; éviter les visuels qui demandent des tables de plusieurs milliers de lignes.

🔴 Expert — Selon le mode de stockage#

Surveiller capacité (lissage, rejet) et concurrence : une page lente à 17 h est souvent une page normale dans une capacité saturée par des chargements concurrents. Voir 09 — comparatif pour les arbitrages de plateforme.

8. Thèmes, visuels et accessibilité#

🟢 Novice — Le thème comme contrat visuel#

Un thème JSON fixe palette, typographie, styles de visuels. Il garantit la cohérence et permet de changer l'identité en un fichier. Un thème minimal :

{
  "name": "Thème Académie",
  "dataColors": ["#1F4E79", "#2E86AB", "#F18F01", "#C73E1D", "#6B8E23", "#7D5BA6"],
  "background": "#FFFFFF",
  "foreground": "#1B1B1B",
  "tableAccent": "#1F4E79",
  "textClasses": {
    "title":  { "fontFace": "Segoe UI Semibold", "fontSize": 14 },
    "label":  { "fontFace": "Segoe UI", "fontSize": 10 }
  }
}

🟡 Pratique — Accessibilité#

Sur le mobile (application Power BI), concevoir une disposition verticale dédiée, des cartes KPI, peu de filtres et des cibles tactiles suffisantes ; tester hors ligne si le cas d'usage le requiert (les capacités hors ligne sont limitées, à vérifier).

🔴 Expert — Gabarits et gouvernance du visuel#

• Modèle de rapport (.pbit) ou rapport de base partagé : en-tête, pied, navigation, thème, pages d'aide.
• Visuels personnalisés : n'utiliser que des visuels certifiés ou audités ; un visuel tiers est du code exécuté dans le rapport.
• Cohérence entre rapports : bibliothèque de composants (cartes KPI, tables) documentée.
• Lisibilité : une page = une question ; titres qui énoncent la conclusion (« les ventes baissent dans le Sud ») plutôt que l'objet (« Ventes par région »).
• Surcharge cognitive : limiter le nombre de couleurs, aligner, supprimer le bruit (grilles superflues, ombres).

9. Multilingue et traductions TMDL#

🟢 Novice — Deux sujets distincts#

1. Traduire les métadonnées du modèle (noms de tables, colonnes, mesures, dossiers d'affichage, descriptions) : le visiteur voit « Chiffre d'affaires » ou « Revenue » selon la langue de son client.
2. Traduire le contenu (valeurs des dimensions, libellés de données) : cela se joue dans les données (colonnes par langue, table de libellés).
3. Les textes du rapport (titres, zones de texte, info-bulles) ne suivent pas toujours la traduction du modèle : les prévoir à part (mesures de titre dynamiques, par exemple).

🟡 Pratique — Traductions dans le modèle (cultures)#

Le modèle sémantique accepte des cultures (langues) avec, pour chaque objet, un translatedCaption, translatedDescription, translatedDisplayFolder. En TMDL, elles se déclarent dans le dossier cultures/ du modèle (un fichier par culture), avec des blocs linguisticMetadata à part.

Modèle.SemanticModel/
  definition/
    model.tmdl
    tables/
    cultures/
      fr-FR.tmdl
      en-US.tmdl
      de-DE.tmdl

Extrait indicatif d'un fichier de culture (la syntaxe exacte est à valider sur votre version de l'outil ; état 2026-10, à vérifier) :

cultureInfo fr-FR

  translations
    model Model
      table 'FACT_Visite'
        caption: Visites
        measure 'Nb visites'
          caption: Nombre de visites
          description: Nombre de visites réalisées sur la période
          displayFolder: Activité

Bonnes pratiques :

🔴 Expert — Pièges du multilingue#

• Traductions et références du rapport : les rapports référencent les objets par leur nom source ; la traduction ne change pas la référence, d'où l'importance de ne jamais renommer à la place de traduire.
• Mesures de titre dynamiques : SELECTEDVALUE ( LUP_Libelle[Texte] ) filtré par langue, ou USERCULTURE() dans la mesure (selon les contextes, vérifier le comportement dans le service).
• Tri : les colonnes traduites doivent avoir un tri par colonne cohérent (clé numérique), sinon l'ordre change selon la langue.
• Langue du client : le service sélectionne la culture selon les paramètres du navigateur ou de l'application mobile ; prévoir une langue par défaut.
• Contenu à plusieurs langues : privilégier un modèle « libellé par langue » (table de libellés avec LANG_COD) à des colonnes Libelle_FR, Libelle_EN qui multiplient les colonnes.
• Suppression/ajout d'une langue : procédure documentée ; une nouvelle langue = une nouvelle culture + scripts + recette.

10. PBIP, TMDL et Git#

🟢 Novice — Pourquoi sortir du .pbix#

Un .pbix est un fichier binaire : on ne peut ni le comparer, ni le fusionner, ni le relire en revue. Le projet Power BI (.pbip) découpe un rapport en fichiers texte : un dossier *.SemanticModel (modèle, en TMDL) et un dossier *.Report (définition du rapport). On peut alors utiliser un gestionnaire de versions, comparer, faire des revues.

MonRapport.pbip
MonRapport.SemanticModel/
  definition.pbism
  definition/
    model.tmdl
    relationships.tmdl
    tables/*.tmdl
    cultures/*.tmdl
MonRapport.Report/
  definition.pbir
  definition/        (format PBIR : un fichier par page/visuel)

🟡 Pratique — Règles de versionnement#

Outils : Power BI Desktop (mode développeur), Tabular Editor, éditeur de texte avec extension TMDL, Fabric Git integration (synchronisation d'un espace de travail avec Git ; limites et prises en charge de fournisseur à vérifier, état 2026-10 — Azure DevOps cloud est le cas de référence ; pour un TFS/Azure DevOps Server sur site, prévoir un chemin de publication par pipeline). Pour TFVC, voir TFVC en profondeur : l'absence d'intégration native impose un processus manuel/scripté de dépôt et de déploiement.

🔴 Expert — Format de rapport et dérives#

• PBIR (rapport en fichiers JSON par page et par visuel) est le format cible du projet de rapport, plus adapté au diff que l'ancien format monolithique ; il devient le format par défaut de Desktop et du service (annonce Microsoft du 1er septembre 2026, déploiement de mi- à fin septembre 2026) ; l'ancien format reste pris en charge. Vérifier la documentation (état 2026-10).
• Références par alias dans les requêtes de visuels : un renommage de colonne laisse des références périmées ; scripter le renommage et valider par ouverture du rapport.
• Modifier à la main les fichiers de rapport est possible mais fragile ; préférer des scripts testés ou l'outil, et toujours rouvrir dans Desktop pour valider.
• Fichiers générés (mise en page du diagramme, états de l'éditeur) : exclure de la revue ou les ignorer.
• Livraison par kits : le modèle publié s'accompagne de scripts (SQL, PowerShell) ; versionner ensemble modèle, scripts de la source et documentation, avec une version commune ; voir CI/CD pour la data.

11. Deployment pipelines et environnements#

🟢 Novice — Dev, Test, Prod#

Trois espaces de travail (au moins) : Développement, Test/Recette, Production. On développe dans le premier, on valide dans le second, on publie dans le troisième. Les deployment pipelines de Fabric/Power BI automatisent la promotion d'un étage à l'autre, avec règles de déploiement (paramètres, sources de données) propres à chaque étape.

🟡 Pratique — Règles#

Alternative ou complément quand le déploiement natif ne suffit pas : publication du modèle par XMLA (outils en ligne de commande, scripts TMDL) depuis un pipeline CI/CD — fonctionnement et état d'accès XMLA en écriture à vérifier selon votre licence (état 2026-10).

🔴 Expert — Cycle de vie complet#

• Orchestration : base (scripts SQL) → modèle → rapports → rafraîchissement → tests → notification. L'ordre compte : publier un modèle qui référence une colonne pas encore déployée en base casse le chargement.
• Compatibilité ascendante : les rapports consommateurs dépendent du modèle ; un changement cassant (renommage, suppression de mesure) exige un préavis, une période de coexistence et la liste des consommateurs (lignage).
• Versions de modèle : numéro de version visible (mesure Version du modèle, page « À propos »), cohérent avec le tag du dépôt.
• Migration de schéma de données : scripts idempotents, rejouables, avec contrôle de pré-requis.

12. Endorsement, catalogue et gouvernance#

🟢 Novice — Rendre fiable ce qu'on partage#

• Promu : « je recommande ce contenu » (par le propriétaire).
• Certifié : validé par des personnes habilitées selon des critères de l'organisation.
• Le catalogue (catalogue OneLake, Purview) permet de trouver les contenus et leur lignage.

🟡 Pratique — Gouvernance utile, pas bureaucratique#

🔴 Expert — Self-service sans chaos#

• Distinguer zones : certifiée (contrôlée), équipe (semi-libre), personnelle (libre, non fiable). Chaque zone a ses règles, et l'utilisateur sait dans laquelle il se trouve.
• Modèles composites au-dessus d'un modèle certifié : permettent l'extension locale sans copie, mais exigent de comprendre les chaînes de dépendance et la sécurité (la RLS du modèle source s'applique).
• Mesure de la gouvernance : taux de rapports utilisant un modèle certifié, nombre de modèles dupliqués, âge moyen des rapports, % d'espaces avec propriétaire. Voir la matrice Gouvernance, catalogue et self-service.
• Capacité : étiquetage des charges par domaine pour la refacturation interne ; voir 12 — coût, licences et capacité.

13. Mesures et lineageTag#

🟢 Novice — Pourquoi c'est un sujet à part#

Chaque objet d'un modèle (table, colonne, mesure) porte un lineageTag : identifiant stable qui permet aux outils de reconnaître « le même objet » malgré un renommage ou un déplacement. Les rapports et certains artefacts dérivés (rapports liés, modèles composites, métriques) s'appuient sur cette identité.

🟡 Pratique — La règle absolue#

Conséquences opérationnelles :

1. Utiliser les instructions de script qui remplacent (createOrReplace en TMDL) sur le même objet en conservant le lineageTag dans la définition, plutôt qu'un cycle delete puis create.
2. Dans une revue de diff TMDL, surveiller toute ligne lineageTag qui change ou toute mesure qui disparaît puis réapparaît : c'est un signal d'alerte.
3. Les générateurs de mesures (déclinaisons) doivent relire le lineageTag existant et le réécrire.
4. Les changements cassants (suppression, renommage) passent par un préavis et une période de coexistence (mesure ancienne conservée, marquée obsolète dans sa description).
5. Garder une liste de mesures publiques (consommées hors du modèle) distincte des mesures internes.

measure 'Chiffre d''affaires' = SUM ( FACT_Commande[Montant] )
    formatString: #,0
    displayFolder: Ventes
    lineageTag: 3f8d2c1e-0b7a-4d59-9a62-5c1d7e4b9a10

🔴 Expert — Cas limites#

• Duplication d'un modèle (copie de projet) : les lineageTag sont copiés ; deux modèles « frères » partagent des identités ; cela peut être voulu (fork) ou source de confusion dans le lignage — décider.
• Fusion de branches : deux branches qui ajoutent la même mesure avec des lineageTag différents créent un conflit logique, pas textuel : revue indispensable.
• Outils de refactoring (renommage en masse) : vérifier qu'ils conservent les tags.
• Rapports clients : les rapports hors périmètre direct de l'équipe (livrés à des clients, adaptés localement) sont ceux qui cassent en silence : inventorier.

14. Tests et recette des chiffres#

🟢 Novice — Tester un rapport, c'est tester des nombres#

L'erreur la plus coûteuse en BI n'est pas un bug d'interface : c'est un chiffre faux que personne ne remet en cause. Il faut donc une recette métier sur des chiffres connus.

🟡 Pratique — Niveaux de test#

// Test DAX (à exécuter dans DAX Studio ou la vue de requêtes) : écart entre deux définitions
EVALUATE
ROW (
    "Mesure", [Chiffre d'affaires],
    "Contrôle", CALCULATE ( SUMX ( FACT_Commande, FACT_Commande[Qte] * FACT_Commande[PrixUnitaire] ) ),
    "Ecart", [Chiffre d'affaires]
        - CALCULATE ( SUMX ( FACT_Commande, FACT_Commande[Qte] * FACT_Commande[PrixUnitaire] ) )
)

🔴 Expert — Automatiser#

• Jeu de référence figé : chiffres attendus sur une période close, stockés dans le dépôt ; toute modification de mesure rejoue le jeu.
• Exécution de requêtes DAX par ligne de commande ou API depuis le pipeline (point de terminaison de requêtes du modèle publié ; limites et droits à vérifier).
• Tests de données en continu après chaque chargement (seuils d'alerte : variation de volumétrie > x % d'un jour à l'autre).
• Données de test : jeux représentatifs, cas limites (valeurs nulles, caractères accentués, fuseaux, fin de mois, années bissextiles, clients sans visite).
• Tests de bascule de langue : afficher le rapport dans chaque langue.
• Tolérance : décider si l'écart admissible est absolu, relatif, ou nul (comptages exacts, montants à l'arrondi près).

15. Documentation#

🟡 Pratique — Ce qui doit être écrit#

16. Pièges classiques#

Catalogue transversal : symptôme → cause → remède.

16.1 Modèle#

16.2 DAX#

16.3 Power Query et données#

16.4 Sécurité et gouvernance#

16.5 Livraison et exploitation#

16.6 Conception et adoption#

17. Contribution de l'IA#

Exemples de prompts :

• « Voici la définition métier du taux de couverture et le schéma du modèle (tables, grains, relations). Écris la mesure DAX et trois cas de test avec résultat attendu. Signale toute ambiguïté de définition. »
• « Voici un diff TMDL. Liste les changements susceptibles de casser des rapports consommateurs (renommage, suppression, changement de lineageTag). »

18. Voir aussi#

• Dans ce dossier : Portail du dossier · 09 — comparatif OneLake / SQL Server · 11 — checklist de projet · 01 — OneLake, vue d'ensemble · 05 — SQL Server, vue d'ensemble · 07 — SQL Server, difficultés et pièges
• Matrice Développement BI : README · modèle sémantique · mesures et DAX · sécurité RLS · versionnement et industrialisation · tests et fiabilité des chiffres · visualisation et UX
• Outils et méthodes : GDS et données SQL/BI · Git en profondeur · TFVC en profondeur · CI/CD · CI/CD pour la data
• Références : GLOSSAIRE · NOTATION · Bibliographie et ressources · IA transverse

✻ Rédigé par Claude Sonnet 5.5