i

Description

Planche de bord d’un avion de tourisme face au soleil levant, avant le décollage.

Source

Cédric Dhaenens cedric · 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.

Checklists de projet de reporting Power BI

Des listes de contrôle exploitables (cases à cocher) pour mener un projet de reporting de bout en bout : cadrage, conception, build, recette, mise en production, exploitation.

En bref

• Des listes de contrôle exploitables (cases à cocher) pour mener un projet de reporting de bout en bout : cadrage, conception, build, recette, mise en production, exploitation.
• Une checklist de choix d'architecture (OneLake / Fabric ou SQL Server managé), une revue de rapport et une revue de modèle à utiliser en pair review.
• Chaque liste va du socle (🟢) au raffinement d'expert (🔴) ; vous pouvez la tronquer selon la taille du projet.
• Mode d'emploi : copiez la liste dans votre outil de suivi (tâches, wiki), supprimez ce qui ne s'applique pas en le justifiant, et gardez la trace des cases cochées comme preuve.
• Interprétation du dossier (OneLake + applications mobiles SaaS ; SQL Server managé) : voir le README du dossier.

Sur cette page

1. 1. Comment utiliser ces listes
   1. 🟢 Novice — Le bon usage
   2. 🟡 Pratique — Adapter à la taille
   3. 🔴 Expert — Faire de la checklist un outil vivant
2. 2. Phase 1 — Cadrage
   1. 🟢 Socle
   2. 🟡 Pratique
   3. 🔴 Expert
3. 3. Phase 2 — Conception
   1. 🟢 Socle
   2. 🟡 Pratique
   3. 🔴 Expert
4. 4. Phase 3 — Build
   1. 🟢 Socle
   2. 🟡 Pratique
   3. 🔴 Expert
5. 5. Phase 4 — Recette
   1. 🟢 Socle
   2. 🟡 Pratique
   3. 🔴 Expert
6. 6. Phase 5 — Mise en production
   1. 🟢 Socle
   2. 🟡 Pratique
   3. 🔴 Expert
7. 7. Phase 6 — Exploitation
   1. 🟢 Socle
   2. 🟡 Pratique
   3. 🔴 Expert
8. 8. Checklist de choix d'architecture
   1. 🟢 Socle — Besoins et contraintes
   2. 🟡 Pratique — Évaluation
   3. 🔴 Expert — Décision et réversibilité
9. 9. Revue de rapport
   1. 🟢 Contenu et lisibilité
   2. 🟡 Technique et ergonomie
   3. 🔴 Fiabilité et gouvernance
10. 10. Revue de modèle
    1. 🟢 Structure
    2. 🟡 Calculs et données
    3. 🔴 Sécurité, versions, durabilité
11. 11. Barème de passage et lecture des résultats
    1. 🟡 Pratique — Scorer une revue
    2. 🔴 Expert — Relier aux matrices
12. 12. Contribution de l'IA
13. 13. Voir aussi

Niveau : 🟢→🔴

1. Comment utiliser ces listes#

🟢 Novice — Le bon usage#

• Une case se coche avec une preuve (lien, capture, résultat de requête), pas « parce que c'est fait à peu près ».
• Une case non applicable est barrée avec une raison (« NA — pas de données personnelles »), jamais supprimée silencieusement.
• Les listes sont des garde-fous, pas un process : elles complètent une méthode (Scrum et data, méthodes spécifiques data) sans la remplacer.

🟡 Pratique — Adapter à la taille#

Légende : [S] socle, [M] recommandé, [E] expert. Les cases reprennent les pratiques détaillées dans 10 — bonnes pratiques transverses ; les références § n renvoient à ses sections.

🔴 Expert — Faire de la checklist un outil vivant#

• Après chaque incident, ajoutez une case qui l'aurait évité (et, si possible, un contrôle automatique).
• Retirez les cases devenues automatiques (CI) : une checklist qui grossit sans fin n'est plus lue.
• Mesurez : nombre de cases « NA » par projet, incidents évités, temps de revue.

2. Phase 1 — Cadrage#

Objectif : savoir pour qui, pour décider quoi, avec quelles données, jusqu'à quand.

🟢 Socle#

• [ ] [S] Les décisions que le reporting doit éclairer sont écrites (3 à 5 questions métier, pas une liste de graphiques).
• [ ] [S] Un sponsor et un propriétaire fonctionnel (qui tranche les définitions) sont nommés.
• [ ] [S] Les utilisateurs sont identifiés par profil (direction, manager terrain, commercial, support) et par appareil (poste, mobile, tablette).
• [ ] [S] La liste des KPI prioritaires avec définition métier d'une phrase chacun.
• [ ] [S] Les sources sont listées (application mobile SaaS, base SQL, fichiers) avec un propriétaire par source.
• [ ] [S] Le périmètre de livraison (ce qui est dedans et dehors) et un critère d'acceptation par KPI.

🟡 Pratique#

• [ ] [M] Fraîcheur attendue par KPI (J-1, horaire, temps réel) justifiée par une décision — pas par principe.
• [ ] [M] Volumétrie estimée aujourd'hui et à 3 ans (lignes de faits, nombre d'entités), croissance.
• [ ] [M] Langues à supporter (interface, libellés, données) et formats régionaux.
• [ ] [M] Sécurité : qui voit quoi (esquisse de la matrice rôle × périmètre), données personnelles présentes, base légale et durée de conservation.
• [ ] [M] Licences : lecteurs/créateurs, capacité, coûts récurrents estimés (ordres de grandeur) ; voir 09 — comparatif.
• [ ] [M] Contraintes : réseau, résidence des données, outils imposés, calendrier, compétences disponibles.
• [ ] [M] Risques identifiés avec propriétaire (quotas d'API SaaS, qualité de source, adoption, dépendance à une personne).
• [ ] [M] Rapports existants à remplacer ou faire coexister ; consommateurs connus des modèles actuels (rapports clients liés).

🔴 Expert#

• [ ] [E] Contrat de données avec chaque source (champs, types, volumétrie, fréquence, préavis de changement de schéma) ; voir sources et contrats de données.
• [ ] [E] Indicateurs de succès mesurables de l'adoption (utilisateurs actifs à 3 mois, décisions documentées) et de la qualité (écart de réconciliation toléré).
• [ ] [E] Définition de « terminé » pour le reporting : documentation, tests, formation, exploitation prévue.
• [ ] [E] Hypothèses et leurs échéances de validation.
• [ ] [E] Trajectoire d'évolution : ce qui est prévu à 6 et 12 mois, pour ne pas figer l'architecture sur le besoin du jour.

3. Phase 2 — Conception#

Objectif : une architecture, un modèle et une maquette validés avant de construire.

🟢 Socle#

• [ ] [S] Modèle conceptuel en étoile : tables de faits (grain écrit), dimensions, table de dates (§ 2).
• [ ] [S] Mode de stockage choisi par table (Import, DirectQuery, composite, Direct Lake) et justifié.
• [ ] [S] Maquette (papier ou une page) validée par un utilisateur réel.
• [ ] [S] Charte de nommage et conventions de modèle écrites (§ 3).
• [ ] [S] Architecture choisie via la checklist de choix d'architecture.

🟡 Pratique#

• [ ] [M] Dictionnaire des mesures prioritaires : nom, définition, formule en langage naturel, unité.
• [ ] [M] Stratégie d'actualisation (déclencheur, fenêtre, dépendances, reprise en cas d'échec, idempotence).
• [ ] [M] Historisation : quelles dimensions évoluent (SCD), quelle date de référence pour les chiffres.
• [ ] [M] Plan de sécurité : rôles, expressions, table de correspondance utilisateur-périmètre, partage de l'espace de travail (§ 6).
• [ ] [M] Environnements (développement, recette, production), paramètres par environnement, jeux de données de test non personnels (§ 11 du dossier 10).
• [ ] [M] Multilingue : langue source, langues cibles, source de vérité des libellés, tri par colonne (§ 9).
• [ ] [M] Mobile : si l'usage est terrain, mise en page téléphone prévue, cartes KPI, hors ligne évalué.
• [ ] [M] Capacité : estimation de la charge (rafraîchissements, utilisateurs concurrents), marge.
• [ ] [M] Source SaaS : quotas d'API, pagination, jeton, schéma qui dérive, données synchronisées avec décalage (voir 03 — difficultés et pièges (OneLake)).

🔴 Expert#

• [ ] [E] Plan de test conçu avec la conception (jeu de KPI figé, réconciliations, matrice de sécurité).
• [ ] [E] Plan de performance : budget par page (temps cible, nombre de visuels), scénarios chronométrés.
• [ ] [E] Stratégie de versions de modèle et compatibilité ascendante (aucune suppression/renommage de mesure sans préavis) (§ 13).
• [ ] [E] Couche d'exposition (vues de reporting, tables gold) distincte des tables techniques.
• [ ] [E] Plan de sortie (réversibilité) documenté : formats, dépendances propriétaires.
• [ ] [E] Revue d'architecture par une personne extérieure au projet.

4. Phase 3 — Build#

Objectif : construire petit, versionné, testé en continu.

🟢 Socle#

• [ ] [S] Dépôt de sources créé : projet Power BI (PBIP/TMDL), scripts de la source, documentation ; exclusions de fichiers de cache en place (§ 10).
• [ ] [S] Chaque évolution est committée avec un message qui dit pourquoi.
• [ ] [S] Les transformations lourdes sont en amont (SQL / lakehouse), pas dans Power Query.
• [ ] [S] Les colonnes gardent le nom de la source ; les libellés passent par les traductions.
• [ ] [S] Une mesure de base par KPI ; les dérivées s'appuient dessus.
• [ ] [S] Les relations sont en sens unique, un-à-plusieurs ; toute exception est justifiée.

🟡 Pratique#

• [ ] [M] Le repli de requêtes (query folding) est vérifié pour chaque table importée.
• [ ] [M] Les types sont explicites, la culture de conversion est fixée.
• [ ] [M] Les colonnes inutiles sont retirées ; les colonnes à forte cardinalité (horodatages) scindées.
• [ ] [M] Les mesures ont description, format, dossier d'affichage ; les colonnes techniques sont masquées.
• [ ] [M] Thème JSON appliqué ; modèle de page utilisé ; textes alternatifs renseignés (§ 8).
• [ ] [M] RLS implémentée et testée par rôle dès le début, pas à la fin (§ 6).
• [ ] [M] Validation syntaxique du projet avant chaque ouverture/commit (contrôle TMDL).
• [ ] [M] Actualisation incrémentale configurée si la volumétrie le justifie, et testée (pas de doublon, pas de trou).
• [ ] [M] Traductions générées par script depuis la source des libellés, contrôle de complétude.
• [ ] [M] Revue par un pair (revues de modèle et de rapport ci-dessous) avant fusion.

🔴 Expert#

• [ ] [E] Pipeline CI : validation de syntaxe, règles de bonnes pratiques (Best Practice Analyzer), contrôle « aucun lineageTag existant ne disparaît », contrôle « une seule clé par table », complétude des traductions.
• [ ] [E] Tests DAX automatisés sur jeu de KPI figé.
• [ ] [E] Mesures de performance consignées (durée, part moteur de formule/stockage) avant et après chaque optimisation.
• [ ] [E] Agrégations / calculation groups documentés (pourquoi, comment les valider).
• [ ] [E] Idempotence vérifiée : rejouer un chargement ne change pas le résultat.
• [ ] [E] Observabilité : journal de chargement, alertes d'échec, volumétrie par exécution.

5. Phase 4 — Recette#

Objectif : prouver que les chiffres sont justes, que la sécurité tient et que c'est utilisable.

🟢 Socle#

• [ ] [S] Chiffres de référence : pour chaque KPI, au moins un chiffre vérifiable dans la source (période close).
• [ ] [S] Réconciliation modèle ↔ source sur les totaux (écart toléré écrit).
• [ ] [S] Test de la sécurité avec un compte lecteur réel par rôle ; au moins un cas « utilisateur sans rôle » et un cas « multi-rôles ».
• [ ] [S] Recette utilisateur par un représentant du métier ; anomalies consignées et priorisées.
• [ ] [S] Actualisation réussie plusieurs fois de suite, y compris après échec simulé.

🟡 Pratique#

• [ ] [M] Cas limites de données : valeurs nulles, entités sans événement, caractères accentués et spéciaux, fuseaux, fin de mois/année, doublons à la source.
• [ ] [M] Performance : chaque page clé chronométrée (poste, mobile), sous charge simulée.
• [ ] [M] Accessibilité : contraste, navigation clavier, ordre de tabulation, textes alternatifs (§ 8).
• [ ] [M] Langues : chaque page vérifiée dans chaque langue, tri et formats corrects.
• [ ] [M] Mobile : parcours principal sur terminal réel, y compris connexion dégradée.
• [ ] [M] Non-régression : jeu de KPI figé rejoué et identique (ou écart expliqué et accepté).
• [ ] [M] Exports : ce que l'utilisateur peut exporter est conforme à la politique de sécurité.
• [ ] [M] Doc de recette : PV avec date, version du modèle, testeurs, écarts acceptés.

🔴 Expert#

• [ ] [E] Recette en double (ancien rapport contre nouveau) sur une période complète avec rapport d'écarts expliqués.
• [ ] [E] Test de reprise : arrêt en milieu de chargement, relance, résultat identique.
• [ ] [E] Test de dérive de schéma : renommage ou ajout de colonne côté source, comportement du pipeline et alertes.
• [ ] [E] Test de charge de capacité : pic de lecteurs pendant un rafraîchissement ; throttling observé ou non.
• [ ] [E] Test de bascule : si Direct Lake, vérifier le mode effectif (pas de repli DirectQuery non voulu).
• [ ] [E] Test d'identité : compte désactivé, utilisateur invité, changement de périmètre en cours de journée.

6. Phase 5 — Mise en production#

Objectif : livrer sans surprise et pouvoir revenir en arrière.

🟢 Socle#

• [ ] [S] Les artefacts déployés sont ceux de la recette (même version, pas de reconstruction).
• [ ] [S] Paramètres de production appliqués (sources, planification), identifiants dans la passerelle/connexion, pas dans le code.
• [ ] [S] Droits : lecteurs, auteurs, administrateurs ; aucun consommateur membre de l'espace de travail (contournement RLS).
• [ ] [S] Actualisation planifiée configurée, notifications d'échec vers une boîte surveillée.
• [ ] [S] Plan de retour arrière écrit et testé (version précédente disponible).

🟡 Pratique#

• [ ] [M] Notes de version (changements visibles, cassants, à valider).
• [ ] [M] Communication aux utilisateurs (date, nouveautés, changements de définition, support).
• [ ] [M] Formation ou guide de prise en main (une page), vidéo courte si utile.
• [ ] [M] Endorsement : contenu promu/certifié selon les critères de l'organisation (§ 12).
• [ ] [M] Étiquette de sensibilité appliquée.
• [ ] [M] Application / diffusion : application Power BI ou lien de rapport selon le public.
• [ ] [M] Capacité : marge confirmée en production, supervision active.
• [ ] [M] Rapports liés : consommateurs connus informés ; coexistence si changement de modèle.

🔴 Expert#

• [ ] [E] Déploiement progressif (cercle pilote, puis élargissement) avec critère de passage.
• [ ] [E] Gel de période évité (clôtures comptables, campagnes) pour livrer.
• [ ] [E] Vérification post-déploiement automatisée (rafraîchissement OK, requêtes de test, comptages).
• [ ] [E] Registre : version de modèle, version de scripts source, date, responsable, lien vers les tickets ; chaînage avec le suivi de projet (voir CI/CD pour la data).
• [ ] [E] Revue de sécurité finale (partage externe, intégration, étiquettes).

7. Phase 6 — Exploitation#

Objectif : tenir dans la durée — fiabilité, évolution, extinction.

🟢 Socle#

• [ ] [S] Supervision des actualisations : échec = alerte, avec propriétaire et délai de réaction.
• [ ] [S] Support : canal et responsable identifiés ; gabarit d'incident.
• [ ] [S] Sauvegarde/versions : sources versionnées, restauration testée au moins une fois.
• [ ] [S] Journal des changements tenu à jour.
• [ ] [S] Propriétaire identifié pour chaque rapport et chaque modèle.

🟡 Pratique#

• [ ] [M] Indicateurs d'usage : utilisateurs actifs, pages consultées, rapports inutilisés (revue trimestrielle).
• [ ] [M] Métriques de capacité : pics, lissage, rejets ; décisions de dimensionnement documentées.
• [ ] [M] Qualité des données : contrôles après chaque chargement (volumétrie, clés orphelines, valeurs hors plage) et alertes.
• [ ] [M] Gestion des changements : toute évolution passe par le même circuit (branche, revue, recette, déploiement).
• [ ] [M] Revue de sécurité périodique : correspondance utilisateur-périmètre à jour, comptes partis, partages.
• [ ] [M] Surveillance des sources SaaS : changements d'API annoncés, quotas, certificats, jetons.
• [ ] [M] Coûts suivis (capacité, base, licences) et comparés au budget.
• [ ] [M] Retour utilisateur collecté (court questionnaire, entretiens) et traité.

🔴 Expert#

• [ ] [E] Objectifs de niveau de service (fraîcheur, disponibilité) mesurés et publiés.
• [ ] [E] Analyse post-incident sans recherche de coupable ; chaque cause racine produit une case ou un contrôle automatique.
• [ ] [E] Dette de modèle : liste des mesures obsolètes, colonnes inutilisées, relations à simplifier ; budget de désendettement par trimestre.
• [ ] [E] Tests de reprise après sinistre de la chaîne (base, capacité, dépôt).
• [ ] [E] Revue d'architecture annuelle : relire la checklist de choix avec les chiffres réels d'usage et de coût ; voir les seuils de bascule du comparatif.
• [ ] [E] Plan d'extinction : critères et processus pour archiver un rapport.

8. Checklist de choix d'architecture#

À remplir avant la phase de conception ; compléter le comparatif et son arbre de décision.

🟢 Socle — Besoins et contraintes#

• [ ] Les 5 exigences non fonctionnelles majeures sont chiffrées : fraîcheur, volumétrie (actuelle, à 3 ans), nombre de lecteurs, disponibilité, temps de réponse.
• [ ] La source de vérité de chaque entité est identifiée (application SaaS, base SQL, référentiel).
• [ ] Le besoin réel de temps réel est justifié par une décision (« quelle décision change en 5 minutes ? »).
• [ ] Les compétences disponibles sont listées (T-SQL, Spark/Delta, DAX, administration de capacité).
• [ ] Les contraintes de résidence des données, de réseau privé et de conformité sont connues.
• [ ] Le budget annuel (licences, base ou capacité, personnes) est connu en ordre de grandeur.

🟡 Pratique — Évaluation#

• [ ] La grille /5 (fraîcheur, performance, coût, complexité, gouvernance, scalabilité, compétences, maturité, verrouillage) est remplie indépendamment par au moins trois personnes, puis comparée.
• [ ] Les poids des critères sont décidés avant le calcul de la moyenne.
• [ ] Un calcul de licences compare « licences par utilisateur » et « capacité » avec le nombre réel de lecteurs (tarifs vérifiés à la date).
• [ ] Le pilote est défini : périmètre (3 à 5 tables, un rapport), durée (2 à 4 semaines), critères de réussite chiffrés.
• [ ] La source SaaS est évaluée : quotas d'API, mécanismes de delta (curseur, horodatage de modification), gestion des suppressions, stabilité du schéma, données hors ligne et délais de synchronisation ; voir 01 — OneLake, vue d'ensemble.
• [ ] Les fonctionnalités en préversion sur lesquelles repose le choix sont repérées (état GA/preview vérifié à la date) et assorties d'un plan B.
• [ ] La sécurité est cartographiée par couche (source, lakehouse/SQL endpoint, modèle, rapport) ; voir 06 — architecture SQL Server et 02 — architecture OneLake.

🔴 Expert — Décision et réversibilité#

• [ ] Le plan de sortie existe : données brutes conservées dans un format ouvert, traitements portables, modèles versionnés.
• [ ] La trajectoire de coexistence (par exemple SQL managé avec mirroring vers Fabric) est décrite : étapes, critères, source de vérité par entité, critère de sortie de la coexistence.
• [ ] Un seuil de bascule est écrit (« si temps de rafraîchissement > X ou lecteurs > Y, alors reconsidérer »).
• [ ] La décision est consignée dans un enregistrement de décision d'architecture (contexte, options, notes, décision, conséquences, date de revue).
• [ ] La revue est planifiée à 6 ou 12 mois avec les mesures réelles.
• [ ] Les risques de verrouillage (orchestration, modèle de capacité, formats, outils) sont listés avec parades.

9. Revue de rapport#

À faire en pair review avant livraison de chaque rapport (30 à 45 minutes). Notez chaque ligne OK / À corriger / NA.

🟢 Contenu et lisibilité#

• [ ] Le rapport répond à la décision annoncée au cadrage ; la page principale se comprend en 10 secondes.
• [ ] Titres de pages et de visuels explicites, en langage métier ; la conclusion est lisible dans le titre quand c'est pertinent.
• [ ] Unités, périodes, devise et date de dernière actualisation visibles.
• [ ] Définitions accessibles (info-bulle, page « À propos »).
• [ ] Cohérence : mêmes couleurs pour mêmes catégories, mêmes formats de nombre.
• [ ] Pas de page surchargée : une page = une question ; environ une dizaine de visuels au plus.

🟡 Technique et ergonomie#

• [ ] Navigation claire (boutons, signets), pas de pages orphelines ; pages de test retirées.
• [ ] Filtres : segments utiles, état initial pertinent, bouton de réinitialisation.
• [ ] Interactions entre visuels vérifiées (filtrage croisé voulu, désactivé quand il trompe).
• [ ] Performance : chaque page chargée sous la cible ; pas de visuel qui renvoie des milliers de lignes.
• [ ] Mobile : mise en page téléphone si usage mobile ; test sur appareil.
• [ ] Accessibilité : contraste, texte alternatif, ordre de tabulation, information non portée par la couleur seule.
• [ ] Langues : libellés et titres traduits dans toutes les langues supportées ; formats locaux.
• [ ] Thème appliqué, aucun style local qui contourne la charte.
• [ ] Exports et partage conformes à la politique ; étiquette de sensibilité appliquée.
• [ ] Visuels personnalisés : certifiés ou audités.

🔴 Fiabilité et gouvernance#

• [ ] Les chiffres affichés sont rapprochés d'un chiffre source pour au moins trois KPI.
• [ ] Les mesures utilisées viennent du modèle partagé (pas de mesure locale qui redéfinit un KPI).
• [ ] La sécurité a été testée avec un compte lecteur pour chaque rôle.
• [ ] Le rapport est lié au bon modèle (production, pas un modèle de développement) ; paramètres corrects.
• [ ] Le propriétaire, la date, la version sont renseignés ; endorsement demandé si critères atteints.
• [ ] Le jeu de tests (captures de référence ou valeurs de KPI) est joint à la revue.

10. Revue de modèle#

À faire en revue de pair pour chaque modification significative du modèle sémantique (diff TMDL lu ligne à ligne).

🟢 Structure#

• [ ] Étoile : faits et dimensions identifiables, grain écrit pour chaque fait.
• [ ] Relations un-à-plusieurs, sens unique ; toute relation bidirectionnelle ou plusieurs-à-plusieurs est justifiée par écrit.
• [ ] Table de dates dédiée, marquée, continue ; relations inactives pour les rôles secondaires.
• [ ] Clés : entières, uniques côté dimension ; une seule colonne clé par table.
• [ ] Colonnes : aucune colonne inutile ; colonnes techniques masquées ; noms identiques à la source.
• [ ] Nommage conforme à la charte ; dossiers d'affichage cohérents.

🟡 Calculs et données#

• [ ] Mesures : description, format, dossier d'affichage ; aucune copie de formule (mesures de base réutilisées).
• [ ] DAX : variables, DIVIDE, filtres sur colonnes, pas d'itérateur injustifié, BLANK() plutôt que 0 quand c'est le sens.
• [ ] Ratios : numérateur et dénominateur testés séparément ; dénominateur indépendant des filtres non voulus (RLS, faits).
• [ ] Intelligence temporelle appuyée sur la table de dates.
• [ ] Power Query : repli vérifié, types explicites, culture fixée, pas de secret en clair, paramètres d'environnement.
• [ ] Actualisation incrémentale : filtre repliable, colonne de modification fiable, essais sans doublon.
• [ ] Intégrité : aucune clé orpheline dans les faits (ou ligne « Inconnu »).
• [ ] Cardinalité : colonnes à forte cardinalité scindées ou retirées ; taille du modèle dans le budget.

🔴 Sécurité, versions, durabilité#

• [ ] RLS/OLS : expressions revues ; matrice de tests exécutée ; comportement sous relations inactives vérifié.
• [ ] lineageTag : aucun tag existant modifié ou disparu ; aucune mesure supprimée puis recréée ; ajouts avec tags uniques (§ 13).
• [ ] Compatibilité : aucun renommage ou retrait de mesure/colonne publique sans préavis ni coexistence.
• [ ] Traductions : chaque objet exposé traduit dans chaque langue ; tri par colonne cohérent.
• [ ] Validation syntaxique TMDL passée ; le projet s'ouvre dans l'outil.
• [ ] Performance : requêtes des visuels clés mesurées (formule/stockage) avant et après.
• [ ] Mode de stockage : si Direct Lake, mode effectif contrôlé (pas de repli) ; si DirectQuery, plans de requête vérifiés côté source.
• [ ] Documentation régénérée ; notes de version rédigées ; changements cassants signalés.
• [ ] Tests : jeu de KPI figé rejoué, écarts expliqués.

11. Barème de passage et lecture des résultats#

🟡 Pratique — Scorer une revue#

Convertissez chaque ligne en avancement : OK = 1, partiel = 0,5, À corriger = 0 (les lignes NA sont exclues). Calculez le taux par bloc (socle, pratique, expert).

Ce barème reprend l'esprit de la règle commune des matrices de maturité (un niveau est acquis à 80 % sans jalon à zéro) : un élément à zéro dans le socle bloque quelle que soit la moyenne. Ce sont des repères, pas des dogmes (voir NOTATION).

🔴 Expert — Relier aux matrices#

12. Contribution de l'IA#

Prompt type : « Voici le diff TMDL ci-joint et la checklist de revue de modèle. Pour chaque ligne, réponds OK / À corriger / Indéterminé, avec la ligne du diff qui le prouve, et liste les points que seul un humain peut juger. »

13. Voir aussi#

• Dans ce dossier : Portail · 09 — comparatif · 10 — bonnes pratiques transverses · 03 — pièges OneLake · 07 — pièges SQL Server
• Méthodes : Scrum et data · Pièges et bonnes pratiques · CI/CD pour la data
• Outils : Azure DevOps / TFS en profondeur · GDS et données SQL/BI · Métriques et reporting de projet
• Matrices : Développement BI · Conduite de projet data · Auto-évaluation
• Références : GLOSSAIRE · NOTATION

✻ Rédigé par Claude Sonnet 5.5