Versionnez et collaborez sur Power BI avec GitHub : le guide pas à pas

8 avril 2026

Introduction

Depuis la création de Power BI, une fonctionnalité semble manquer. On peut se connecter à des sources de données, transformer les données, automatiser, modéliser, visualiser de manière dynamique les données, partager ses rapport, ... Somme toute, l'outil semble permettre la réalisation de tout ce que l'on attend d'un outil de data visualisation...

C'est ce que l'on se dit avant de devoir collaborer à plusieurs sur un même rapport Power BI. Qui n'a jamais eu la problématique de devoir s'envoyer des fichiers pbix de manière incessante lors de la moindre coopération sur un projet ? Qui n'a jamais eu des fichiers nommés RapportVentes1, RapportsVentes2,..., RapportsVentes100, RapportVentes_Final_v100_VraiFinal.pbix etc. ? Certes, il existe des solutions de contournement avec notamment SharePoint, mais vous l'aurez compris, il existe des outils plus puissants pour ça. On parlera notamment de Git et de ses expressions : GitHub, Azure DevOps, Bitbucket, GitLab... Voyez Git comme la technologie de l'email et GitHub comme Gmail. Cet article vise à répondre à une question cruciale : Comment versionner et collaborer sur Power BI avec GitHub ?

Quelques définitions

 

 

Qu'est-ce que Git ?

Git est un système de contrôle de version décentralisé (DVCS - Distributed Version Control System), open-source et gratuit, créé en 2005 par Linus Torvalds (le créateur de Linux).

Sa fonction principale est de suivre et d'enregistrer l'historique chronologique de toutes les modifications apportées à un ensemble de fichiers (le "dépôt" ou repository). Conçu pour la vitesse et l'intégrité des données, Git permet à des équipes de toute taille de collaborer sur un même projet de manière sécurisée et asynchrone.

Git repose sur 3 piliers :

1. Décentralisé (L'autonomie) : Chaque membre de l'équipe télécharge une copie complète du projet et de son historique sur son propre ordinateur. Vous pouvez travailler hors-ligne et le projet ne disparaît pas si le serveur central tombe en panne.

2. Traçabilité (La machine à remonter le temps) : Grâce aux commits, chaque modification est enregistrée, datée et signée. Vous savez toujours qui a fait quoi, et vous pouvez revenir à une version précédente à tout moment si quelque chose casse.

3. Travail en parallèle (Les branches) : Vous pouvez créer un espace brouillon isolé (une branche) pour développer une nouveauté sans risquer de détruire le rapport principal. Une fois terminé, Git s'occupe de fusionner intelligemment votre travail avec celui des autres.

 

Qu'est-ce que GitHub ?

 

GitHub est une plateforme cloud d'hébergement et de gestion de code source, basée sur le système de versioning Git. Rachetée par Microsoft en 2018, c'est aujourd'hui la plus grande plateforme de développement collaboratif au monde.

Si Git est le "moteur" technique qui tourne en arrière-plan sur l'ordinateur du développeur, GitHub est "l'interface" en ligne qui permet aux équipes de centraliser ce travail, d'en discuter et de l'automatiser. La plateforme transforme Git, qui est un outil individuel puissant, en un véritable réseau social d'entreprise dédié à la collaboration technique.

 

 

Quand un développeur a terminé de travailler sur sa branche isolée, il ne force pas la fusion avec le projet principal. Il ouvre une "Pull Request" : une demande formelle d'intégration. Cela crée un espace de discussion visuel où le reste de l'équipe peut examiner les modifications (différence ligne par ligne), commenter, et valider le travail avant qu'il ne soit définitivement intégré au projet de production.

Pour résumer, GitHub va vous permettre de collaborer, de travailler à plusieurs sur différentes parties d'un projet/fichier/rapport, de versionner et enfin de revenir à une version précédence en cas de problème.

Avant de continuer, il est souhaitable de connaître le jargon Git.

1. Repository (ou "Repo" / Dépôt)

C'est quoi ? C'est le dossier principal qui contient tout votre projet, tous vos fichiers, et tout l'historique Git.

L'analogie : C'est le grand classeur d'archives de votre projet Power BI.

2. Commit

C'est quoi ? L'action de sauvegarder de manière permanente un ensemble de modifications dans l'historique de Git. Un commit est toujours accompagné d'un message explicatif.

L'analogie : C'est comme prendre une photographie de votre rapport à un instant T. Message de commit : "Ajout du graphique d'évolution des ventes mensuelles".

3. Branch (Branche)

C'est quoi ? Une ligne de développement parallèle et indépendante. Par défaut, tout le monde travaille sur la branche principale (souvent appelée main ou master). On crée une nouvelle branche pour tester ou développer sans casser la production.

L'analogie : C'est un brouillon ou un "bac à sable". Vous copiez le rapport officiel dans votre coin pour essayer une nouvelle mesure DAX très complexe.

4. Merge (Fusionner)

C'est quoi ? L'action de réunir deux branches. Concrètement, c'est rapatrier les modifications terminées de votre branche de travail vers la branche principale.

L'analogie : Vous avez fini votre brouillon et le calcul DAX fonctionne. Vous l'intégrez définitivement dans le rapport officiel.

5. Pull Request (PR) ou Merge Request (MR)

C'est quoi ? Sur GitHub (ou GitLab), avant de faire un Merge, on fait une demande formelle. Cela permet à l'équipe de relire le code, de le commenter et de l'approuver avant qu'il ne rejoigne la branche principale.

L'analogie : C'est soumettre son brouillon à la relecture par son chef de projet ou ses collègues avant validation finale.

6. Clone (Cloner)

C'est quoi ? Télécharger une copie exacte et complète d'un Repository (qui est hébergé sur GitHub) sur votre propre ordinateur.

L'analogie : Télécharger tout le classeur d'archives depuis le Cloud pour travailler dessus dans l'avion sans internet.

7. Push (Pousser)

C'est quoi ? Envoyer les Commits (les sauvegardes) que vous avez faits sur votre ordinateur vers le serveur distant (GitHub, Azure DevOps).

L'analogie : C'est faire un "Enregistrer sous..." sur le réseau de l'entreprise pour que vos collègues voient votre travail de la journée.

8. Pull (Tirer)

C'est quoi ? L'inverse du Push. C'est l'action de télécharger les nouveautés que vos collègues ont envoyées sur le serveur pour mettre à jour votre version locale.

L'analogie : C'est rafraîchir son dossier pour obtenir les dernières modifications faites par l'équipe pendant la nuit.

9. Conflict (Conflit)

C'est quoi ? Cela arrive quand deux personnes modifient exactement la même ligne de code au même moment et tentent de fusionner. Git ne sait pas quelle version choisir et se met en pause.

L'analogie : Alice et Bob ont tous les deux modifié le formatage de la colonne "CA" dans le rapport Power BI. L'outil vous demande : "Je garde la version d'Alice ou celle de Bob ?".

Pourquoi combiner Power BI avec GitHub ?

  • Travail simultané (La fin des fichiers bloqués) : Grâce au nouveau format .pbip, Alice peut créer des mesures DAX pendant que Bob travaille sur le design visuel, sans risque de s'écraser mutuellement.
  • Traçabilité totale : Vous savez toujours qui a modifié quelle formule, quand et pourquoi.
  • Sécurité et droit à l'erreur (Rollback) : Un bug en production ? En un clic, vous pouvez revenir à la version précédente qui fonctionnait, grâce à l'historique de Git.
  • Contrôle qualité (Pull Request) : Aucune modification n'est publiée sans avoir été relue et validée par un pair.

 

Point sur les formats PBIP(Power BI Project) & PBIR(Power BI Enhanced Report)

Avant de passer à la pratique avec GitHub Desktop, il y a une notion technique fondamentale à comprendre : Git ne sait pas lire les fichiers binaires.

Historiquement, lorsque vous enregistriez votre travail dans Power BI, vous créiez un fichier .pbix. Ce fichier est un fichier binaire (en réalité, un dossier compressé). Pour le cerveau humain comme pour Git, un fichier binaire ressemble à ça : 01100110 01101111 01110010 01101101.... C'est un bloc opaque.

Le problème avec le .pbix : Si Alice modifie la couleur d'un titre et que Bob modifie une mesure DAX dans le même fichier .pbix, Git voit simplement que le "bloc opaque A" est devenu le "bloc opaque B". Il est incapable de dire ce qui a changé à l'intérieur, et encore moins de fusionner le travail d'Alice et de Bob. C'est le conflit assuré.

Power a donc sorti un nouveau format de fichier : le PBIP (Power BI Project). Il a aussi sorti le format PBIR (Power BI Enhanced Report) pour mieux organiser le projet.

Dans le PBIP, on retrouve la plupart des éléments qui composent le rapport sous forme de fichiers json dans des dossiers. Présentons les différents éléments.

Le dossier du Rapport (.Report) : L'interface visuelle
C'est ici que l'on retrouve la fameuse extension .pbir dont nous parlions. Ce dossier contient tout ce que l'utilisateur final voit et avec lequel il interagit :

  • Les pages et les visuels : La position de chaque graphique, les couleurs, les titres.
  • Le thème : Le fichier JSON contenant la charte graphique de l'entreprise.
  • Les signets (Bookmarks) et la navigation.
  • Les visuels personnalisés : Si vous avez importé des graphiques spécifiques depuis l'AppSource.

Le dossier du Modèle Sémantique (.SemanticModel) : La partie Data comme le modèle sémantique sur Power BI Service
C'est le "cerveau" de votre tableau de bord. Il contient toute la logique métier, traduite en texte (via le format TMDL) :

  • Le code Power Query (M) : Les scripts qui nettoient et transforment vos données sources.
  • Le modèle de données : Les tables et les relations entre elles (le fameux schéma en étoile).
  • Les mesures DAX : Toutes vos formules de calcul (Chiffre d'affaires, Marge, etc.).
  • Les rôles de sécurité (RLS) : Les règles qui définissent qui a le droit de voir quelles données.

Le petit fichier .pbip (Le chef d'orchestre)

Au milieu de ces dossiers, on retrouve un tout petit fichier portant l'extension .pbip. Il ne pèse que quelques kilo-octets. Son seul rôle est de faire le lien : quand vous double-cliquez dessus, il lance Power BI Desktop et va piocher les informations dans les deux dossiers pour reconstituer votre rapport à l'écran. Pour le dire simplement : le .pbip est le fichier de travail de l'humain, tandis que les autres sont les fichiers de travail de la machine (et de Git).

Comment versionner ses rapports Power BI avec GitHub ?

Etape 1 : Créer un compte GitHub (https://github.com/)

Etape 2 : Installer GitHub Desktop (https://desktop.github.com/download/).

Etape 3 : Créer un dossier quelque part dans votre explorateur de fichiers

Etape 4 : Ouvrir le rapport Power BI, qui est encore un fichier pbix, et faire enregistrer sous le format pbip (onglet Fichier puis Enregistrer sous...).

 

 

Etape 5 : vous pouvez voir que vous avez 2 dossiers (le rapport et le modèle sémantique en fichiers json), 1 fichier gitignore(GIT Ignore, des choses que Git doit ignorer) et 1 fichier pbip( voyez ça comme votre pbix). Maintenant, ouvrir GitHub Desktop et ajouter un nouveau repository (ou choisir l'option add existing repository et donner le chemin vers le dossier projet) en choisissant un nom et indiquant le chemin vers notre dossier de projet.

 

 

 

On voit les changements ici.

Etape 6 : Publier le repository

 

 

 

Et voilà ! Faisons un test.

Etape 7 : On réouvre le fichier power bi (pbip) et on change le titre

On sauvegarde.

Sur GitHub Desktop, on voit les changements.

 

Etape 8 : On commit. Remplir le champ Summary et cliquer sur Commit.

Etape 9 : On push to GitHub pour mettre en prod. On retourne voir les changement sur GitHub.

 

 

Le changement de titre a été pris en compte. Les équipes ont accès à la dernière version.

Etape 10 : supprimons le fichier pbip et faisons un commit + push.

 

Imaginons qu'on veuille revenir en arrière. Il suffit de revert les changes dans le commit dans History après un clic droit.

 

On push une seconde fois et c'est bon, notre projet est sauvé !

 

 

Conclusion

Nous avons vu comme utiliser GitHub pour collaborer et versionner sur Power BI.

Franchir le cap de l'intégration Git demande un petit effort initial pour s'approprier un nouveau vocabulaire (Commit, Push, Branch), mais le gain en sérénité, en efficacité et en qualité pour votre équipe Data est tout simplement inestimable.

De plus, Microsoft semble pousser les utilisateurs à utiliser ce type d'outil avec notamment la sortie du format PBIR en disponibilité générale.

Articles en relation

Devenez un expert en Power BI

avec nos formations 100% pratique et sur mesure
Découvrir nos formations

Retrouvez nos autres marques

linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram