Support formation Rapports Power BI

PBIP, PBIR, TMDL et Git

En bref

  • Objectifs : enregistrer un rapport en projet Power BI (PBIP) ; créer un dépôt Git et lire une différence dans Visual Studio Code ; connecter un espace de travail Fabric à Git ; organiser le travail en branches et choisir une méthode de mise en production.
  • Prérequis : page Les formats de fichiers : PBIX, PBIT, PBIP, PBIR, TMDL (partie 0) ; Git et Visual Studio Code installés.
  • Licence requise : aucune pour Git sur le poste ; espace de travail sur une capacité Fabric (F), Premium ou Premium par utilisateur pour l'intégration Git.

Pourquoi ?

Un PBIX est un fichier binaire : impossible de savoir ce qui a changé entre deux versions, de revenir à l'état d'hier ou de fusionner le travail de deux personnes. Le format projet enregistre le rapport et le modèle en fichiers texte que Git sait comparer, historiser et fusionner.

Méthode manuelle (vue TMDL)Méthode Git
Ce qui est versionnéLe modèle sémantique scriptéLe modèle et le rapport (pages, visuels, thèmes)
DéclenchementDiscipline : scripter avant de modifierChaque validation (commit) est une version
HistoriqueFichiers .tmdl nommés à la mainAuteur, date, message, différences ligne à ligne
Travail à plusieursImpossible à fusionnerBranches, fusion, revue
PublicationManuelleSynchronisation de l'espace de travail, pipelines de déploiement

La méthode manuelle est décrite dans la page Vue TMDL (partie 3).

Notions clés

Les briques

  • Projet Power BI (PBIP) : le rapport est enregistré au format PBIR (un fichier JSON par page, visuel et signet), le modèle au format TMDL (un fichier par table, rôle, culture).
  • Dépôt Git local : sur le poste, il enregistre l'historique des validations.
  • Dépôt distant : Azure DevOps (Azure Repos) ou GitHub, référence partagée de l'équipe.
  • Intégration Git de l'espace de travail : un espace de travail Fabric est relié à une branche et à un dossier du dépôt et se synchronise dans les deux sens.
  • Pipelines de déploiement : promotion du contenu de l'espace de développement vers le test puis la production.

[Capture : schéma d'ensemble, poste du développeur (Power BI Desktop et VS Code) relié à un dépôt Azure DevOps ou GitHub, lui-même relié à l'espace de travail Dev, puis flèches vers les espaces Test et Prod via le pipeline de déploiement]

Ce qui va dans Git, et ce qui n'y va pas

Ventes/
├── Ventes.Report/            # définition du rapport (PBIR)
├── Ventes.SemanticModel/     # définition du modèle (dossier definition en TMDL)
├── .gitignore
└── Ventes.pbip

Le fichier .gitignore, créé automatiquement, exclut :

**/.pbi/localSettings.json
**/.pbi/cache.abf

cache.abf contient les données importées (taille, confidentialité) ; sans lui, Desktop ouvre le modèle vide et il suffit d'actualiser. localSettings.json contient des réglages propres au poste. Dans un espace de travail connecté, seules les définitions sont synchronisées : ni les données, ni les identifiants, ni les paramètres d'actualisation.

Statut

Selon la documentation Microsoft Learn (mise à jour de décembre 2025), le format projet est encore en préversion : activez Enregistrer en tant que projet Power BI (.pbip) dans Fichier > Options et paramètres > Options > Fonctionnalités en préversion, ainsi que le stockage du rapport en PBIR et du modèle en TMDL si ces options y figurent encore.

Pas à pas

Préparer le projet et créer le dépôt

1. Dans Power BI Desktop, Fichier > Enregistrer sous > type Projet Power BI (*.pbip), dans un dossier dédié au chemin court.

[Capture : boîte de dialogue Enregistrer sous avec le type « Projet Power BI (*.pbip) », puis Explorateur Windows montrant les dossiers .Report, .SemanticModel et le fichier .gitignore]

2. Dans VS Code, Fichier > Ouvrir le dossier, puis volet Contrôle de code source > Initialiser le dépôt. Saisissez un message (Version initiale du rapport Ventes) et Validez.

[Capture : VS Code, volet Contrôle de code source sur un projet PBIP, liste des fichiers modifiés, zone de message et bouton Valider]

3. Publiez la branche : VS Code propose de créer le dépôt sur GitHub ; pour Azure DevOps, créez d'abord le dépôt dans Repos > Files, puis Clone > Clone in VS Code.

Équivalent en ligne de commande :

cd C:\Projets\Ventes
git init
git add .
git commit -m "Version initiale du rapport Ventes"
git remote add origin https://dev.azure.com/<organisation>/<projet>/_git/<depot>
git push -u origin main

4. Modifiez une mesure dans Desktop et enregistrez : VS Code signale definition/tables/Ventes.tmdl. Un clic affiche la comparaison ligne à ligne ; l'extension Git Graph visualise l'historique.

[Capture : VS Code en comparaison côte à côte d'un fichier .tmdl, ancienne expression DAX en rouge à gauche, nouvelle en vert à droite]

Connecter un espace de travail à Git

Prérequis : capacité Fabric, Premium ou Premium par utilisateur ; paramètres du locataire Les utilisateurs peuvent synchroniser les éléments de l'espace de travail avec leurs dépôts Git (et avec les dépôts GitHub) activés ; rôle Administrateur de l'espace de travail ; compte Azure DevOps lié au même utilisateur Microsoft Entra, ou jeton d'accès personnel GitHub (lecture et écriture sur Contents).

5. Paramètres de l'espace de travail > Intégration Git : choisissez le fournisseur, renseignez l'organisation, le projet, le dépôt, la branche et le dossier, puis Connecter et synchroniser. À la première synchronisation, le contenu est copié du côté non vide vers le côté vide.

6. Au quotidien, le volet Contrôle de code source de l'espace de travail affiche les éléments Non validé, Mise à jour requise ou en Conflit :

ActionSensDémarche
ValiderEspace de travail vers GitModifications > cocher > message > Valider
Mettre à jourGit vers espace de travailMises à jour > Tout mettre à jour
AnnulerRetour à l'état synchroniséModifications > cocher > Annuler

[Capture : espace de travail connecté à Git, colonne Statut Git des éléments et volet Contrôle de code source ouvert sur l'onglet Modifications]

Exemple

Démarche type en équipe, chaque développeur sur sa branche :

  1. Créer feature/mesures-marge depuis main.
  2. Faire des validations petites et fréquentes, avec un message « verbe + objet » (Ajoute la mesure Marge %).
  3. Mettre régulièrement sa branche à jour depuis main.
  4. Ouvrir une demande de tirage (pull request) vers main ; le référent relit les différences et approuve.
  5. Dans l'espace de travail d'équipe connecté à main, Mettre à jour.

Pour s'isoler sans Desktop, Brancher vers un autre espace de travail crée une branche et un espace de travail dédiés.

[Capture : demande de tirage dans Azure DevOps ou GitHub, branche feature vers main, onglet Fichiers montrant la différence sur un fichier .tmdl, bouton Approuver]

Pour mettre en production :

OptionPrincipePour qui
Pipelines de déploiementSeul l'espace Dev est connecté à Git ; promotion Dev, Test, Prod avec règles de déploiementÉquipes Power BI, recommandée en formation
Intégration Git par étapeUne branche par environnementÉquipes qui suivent Gitflow
API et outilsDéploiement par script (bibliothèque Python fabric-cicd, API REST Fabric)Chaînes CI/CD automatisées

Pièges et bonnes pratiques

  • Un espace de travail n'est connecté qu'à une seule branche à la fois.
  • Fermez Power BI Desktop avant de modifier les fichiers avec un autre outil : il ne détecte pas les modifications externes.
  • N'enregistrez pas un projet dans un dossier OneDrive ou SharePoint synchronisé ; utilisez un dossier local versionné.
  • Les fichiers sont en UTF-8 sans BOM et Desktop écrit des fins de ligne CRLF : configurez core.autocrlf pour éviter des différences parasites.
  • Évitez les images lourdes dans le rapport.
  • Conflit : choisissez la version de l'espace de travail ou celle de Git dans l'interface, ou résolvez dans Git puis mettez à jour l'espace.
  • Retour arrière : Annuler pour ce qui n'est pas validé ; git revert <commit> pour une validation, puis Mettre à jour l'espace et actualiser le modèle.
  • Une demande de tirage peut déclencher un pipeline Azure DevOps qui contrôle le modèle (Best Practice Analyzer de Tabular Editor) et le rapport (PBI Inspector).

À retenir

  • PBIP = rapport en PBIR + modèle en TMDL, en fichiers texte comparables.
  • Les données (cache.abf) ne vont jamais dans Git.
  • L'intégration Git relie un espace de travail Fabric à une branche, dans les deux sens.
  • Une branche par évolution, une demande de tirage pour fusionner, un pipeline pour déployer.

Pour aller plus loin

  • Projets Power BI Desktop (PBIP). Source
  • Intégration Git des projets Power BI. Source
  • Prise en main de l'intégration Git. Source
  • Gérer les branches. Source
  • Bonnes pratiques CI/CD dans Fabric. Source
  • Tutoriel de bout en bout : Git et pipelines de déploiement. Source

Exercice

  1. Enregistrez le fichier du fil rouge en PBIP, ouvrez le dossier dans VS Code, initialisez le dépôt et validez la version initiale.
  2. Ajoutez une mesure dans Desktop, enregistrez, observez la différence dans VS Code, validez.
  3. Créez une branche feature/page-synthese, modifiez une page, validez, revenez sur main et rouvrez le PBIP pour constater que la page n'a pas changé.
  4. Fusionnez la branche dans main.
  5. Avec une capacité Fabric (l'essai suffit) : connectez un espace de travail à main, modifiez un visuel dans le service, Validez, puis récupérez la modification avec git pull.
  6. Annulez la dernière validation avec git revert et Mettez à jour l'espace de travail.