i

Description

Falaise de roches sédimentaires empilées en couches successives, chaque strate conservant une période.

Source

DimiTalen · 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.

Versionnement et industrialisation des rapports

Ce thème évalue la façon dont un produit BI est stocké, relu, fusionné, déployé et restauré : projets Power BI Project (PBIP) avec définitions TMDL (modèle) et PBIR (rapport), Git ou TFVC…

En bref

Ce thème évalue la façon dont un produit BI est stocké, relu, fusionné, déployé et restauré : projets Power BI Project (PBIP) avec définitions TMDL (modèle) et PBIR (rapport), Git ou TFVC, revue de modifications, environnements dev/test/prod, deployment pipelines, règles de paramètres, scripts XMLA/TMDL, retour arrière. Pour les principes de gestion de source, voir GDS et données SQL/BI.

Sur cette page

1. 1. Pourquoi ce thème
2. 2. Ce que mesure le thème
3. 3. Les 5 niveaux
4. 4. Jalons par niveau
5. 5. Lecture détaillée par niveau
   1. 🟢 Niveau 1 — Fichier partagé
   2. 🟢 Niveau 2 — Dépôt de fichiers
   3. 🟡 Niveau 3 — Projet texte
   4. 🟡 Niveau 4 — Pipeline
   5. 🔴 Niveau 5 — Continu
6. 6. Atteinte partielle et notation
7. 7. Passer au niveau suivant
8. 8. Voir aussi

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

1. Pourquoi ce thème#

Un .pbix est un binaire compressé : impossible à comparer, à fusionner, à relire ligne à ligne. Deux personnes qui modifient le même .pbix se marchent dessus et l'une perd son travail. Le format PBIP (d'abord en préversion, aujourd'hui stabilisé ; à vérifier selon la fonctionnalité) éclate le produit en fichiers texte : *.SemanticModel/definition/*.tmdl (tables, mesures, relations, rôles, cultures) et *.Report/definition/ (pages, visuels au format PBIR en JSON). Le texte se versionne, se diffe, se relit, se fusionne. Sans cela, il n'y a ni revue de code, ni historique, ni déploiement reproductible.

2. Ce que mesure le thème#

• Axe : du fichier partagé au pipeline de livraison continue avec retour arrière.
• Indicateurs clés : part des artefacts BI versionnés en format texte ; fréquence de déploiement ; délai de retour arrière ; part des changements passés en revue ; taux d'échec de déploiement.
• Unités : %, déploiements/mois, minutes.

3. Les 5 niveaux#

4. Jalons par niveau#

5. Lecture détaillée par niveau#

🟢 Niveau 1 — Fichier partagé#

• Signes : Rapport_v3_final_OK.pbix, publication depuis le poste de l'auteur, aucune idée de ce qui a changé.
• Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Dépôt de fichiers#

• Signes : les .pbix sont dans Git (ou TFVC) avec un historique ; le dépôt gonfle (binaire non delta-compressible), le diff est impossible.
• Gain : traçabilité, retour à une version.
• Limite : pas de revue de fond, pas de fusion.
• Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Projet texte#

Structure typique d'un PBIP :

Rapport Ventes.pbip
Rapport Ventes.SemanticModel/
    definition/
        model.tmdl
        tables/FACT_VISITE.tmdl
        relationships.tmdl
        roles/Perimetre.tmdl
        cultures/en-US.tmdl
Rapport Ventes.Report/
    definition/
        pages/pages.json
        pages/<id>/visuals/<id>/visual.json

• Signes : on lit un diff de mesure comme du code ; deux développeurs travaillent sur deux tables ; la revue se fait sur le TMDL. Le TMDL a des règles de forme strictes (indentation, une seule colonne clé par table) : un validateur de syntaxe avant ouverture évite de corrompre le projet.
• Gain : parallélisme, revue, historique fin.
• Limite : la fusion de fichiers JSON de rapport (PBIR) reste plus délicate ; les identifiants de visuels sont des GUID.
• Difficulté : 3/5 · Effort : 3/5.

🟡 Niveau 4 — Pipeline#

• Signes : trois espaces (ou trois capacités) ; un pipeline de déploiement du service Power BI, ou un pipeline CI qui publie via les API/outils en ligne de commande (Tabular Editor CLI, fabric-cicd, API REST — outils à vérifier selon version). Les paramètres changent par environnement via règles, pas à la main.
• Gain : reproductibilité.
• Limite : tous les objets ne se déploient pas de la même façon (certaines sources, passerelles, droits restent à configurer) ; écart possible entre les environnements.
• Difficulté : 4/5 · Effort : 4/5.

# Esquisse de pipeline (étapes logiques, indépendantes de l'outil)
stages:
  - validate:   # syntaxe TMDL, BPA, tests de mesures sur le modèle de test
  - deploy_test: # publier dans l'espace Test avec règles de paramètres
  - smoke_test:  # requêtes DAX de référence, rafraîchissement
  - approve:     # validation humaine (métier)
  - deploy_prod

🔴 Niveau 5 — Continu#

• Signes : fusion validée → déploiement vers Test automatique → promotion prod après tests et approbation ; retour arrière exercé ; notes de version générées.
• Gain : livrer souvent, petit, sûr (voir DL — intégration et livraison continues et CI/CD pour la data).
• Limite : un changement de modèle (schéma) n'est pas réversible comme un changement de rapport (ex. suppression de colonne, perte du lineage) ; le retour arrière requiert une stratégie de compatibilité ascendante.
• Difficulté : 5/5 · Effort : 5/5.

6. Atteinte partielle et notation#

Règle commune. « Un 5 partiel » : le déploiement automatique existe pour le modèle, mais pas pour les rapports (BI-IND-5.1 = 0,5) ; retour arrière jamais exercé (5.2 = 0) ; compatibilité entre kits vérifiée à la main (5.3 = 0,5) ; notes de version rédigées à la main (5.4 = 0,5).

7. Passer au niveau suivant#

Moyens possibles (facultatifs) :

Pièges :

• Faux positif : « tout est dans Git » mais le déploiement passe encore par une publication manuelle depuis Desktop.
• Goodhart : compter les déploiements encourage des micro-déploiements sans valeur ; mesure aussi le taux d'échec et le délai de retour arrière.
• Renommer un objet publié casse les rapports liés : la livraison d'un modèle est un contrat (MOD, DAX).
• Écraser le travail d'un collègue : sans fusion lisible, la dernière sauvegarde gagne.

8. Voir aussi#

• Thèmes voisins : TST · MOD · GOV · OPS
• Autres matrices : DL — gestion de version et branches · DL — déploiement et exploitation · PD — délais et DataOps
• Contenus : Git en profondeur · TFVC en profondeur · GDS et données SQL/BI · CI/CD · Azure DevOps / TFS en profondeur

✻ Rédigé par Claude Sonnet 5.5