Lire l'article
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 ?

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.

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 ?".
.pbip, Alice peut créer des mesures DAX pendant que Bob travaille sur le design visuel, sans risque de s'écraser mutuellement.
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.
.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).
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é !
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.
