Gouvernance Power BI : automatiser l'audit et l'administration avec PowerShell

Introduction

« Qui a accès à ce rapport ? »
« Quels jeux de données ont échoué à leur dernière actualisation ? »
« Quels rapports personne n'a ouverts depuis six mois ? »

3 questions de gouvernance parfaitement légitimes. Et 3 bonnes raisons de passer votre après-midi à cliquer, écran par écran, dans le portail d'administration Power BI.

Au début, tout va bien : trois espaces de travail, cinq rapports, deux collègues. La gouvernance Power BI se fait « à l'œil ». Puis le déploiement prend — des dizaines d'espaces, des centaines de rapports, des utilisateurs qui arrivent et repartent — et ces questions ne se répondent plus à la main. Pire : même quand vous trouvez la réponse, elle est déjà périmée le mois suivant, et impossible à reproduire à l'identique.

C'est exactement ce que PowerShell résout. Quelques scripts suffisent à lister l'ensemble de vos espaces de travail, rapports et jeux de données, à cartographier qui a accès à quoi, et à exploiter les journaux d'activité pour retracer qui a fait quoi — automatiquement, et de façon reproductible. Dans cet article, on vous montre comment utiliser PowerShell pour gouverner Power BI, pas à pas.

PowerShell et l'API Power BI Service : de quoi parle-t-on ?

Avant d'écrire le moindre script, clarifions deux termes qu'on confond souvent — et qui ne désignent pas du tout la même chose.

PowerShell, c'est l'outil. Un langage de script et une console, installés sur votre poste (ou sur un serveur), conçus pour automatiser des tâches : lire des fichiers, boucler, filtrer, exporter un CSV, enchaîner des actions. PowerShell est généraliste — il ne connaît rien à Power BI en particulier. C'est votre chef d'orchestre : il sait donner des ordres et traiter des résultats, mais encore faut-il qu'il sache à qui s'adresser.

L'API REST de Power BI, c'est justement l'interlocuteur. C'est la « porte d'entrée » que Microsoft expose sur Power BI Service : un ensemble d'adresses web (des endpoints, sous https://api.powerbi.com/...) auxquelles on envoie des requêtes pour lister un espace de travail, lancer une actualisation, lire des droits d'accès… L'API, elle, ne connaît que Power BI. Elle attend des requêtes HTTP et répond en JSON (du texte structuré). Et elle se moque de savoir si la requête vient de PowerShell, de Python ou d'ailleurs.

Autrement dit : PowerShell pose les questions, l'API Power BI y répond. L'un pilote, l'autre exécute côté service ; les deux communiquent par des requêtes HTTP.

Reste un maillon : comment PowerShell parle-t-il à l'API ? Par le module officiel MicrosoftPowerBIMgmt, qui fait le pont de deux façons :

• Des cmdlets toutes prêtes pour les besoins courants — Get-PowerBIWorkspace, Get-PowerBIReport… Simples et lisibles, mais elles ne couvrent qu'une partie de l'API.
• Un passe-partout, Invoke-PowerBIRestMethod, qui appelle n'importe quel endpoint — y compris les API d'administration indispensables à la gouvernance — en gérant l'authentification à votre place.

Concrètement, une cmdlet n'est qu'un raccourci sur un appel d'API. Les deux lignes ci-dessous renvoient la même chose :

# Via la cmdlet (le raccourci) 
Get-PowerBIWorkspace 

# Via l'API directement (même résultat, mais tout l'API vous est ouvert) 
Invoke-PowerBIRestMethod -Url "groups" -Method Get | ConvertFrom-Json

NB :  on écrit en PowerShell, on s'adresse à l'API Power BI, et le module MicrosoftPowerBIMgmt sert de traducteur entre les deux. Pour la gouvernance, on s'appuiera surtout sur Invoke-PowerBIRestMethod — c'est le seul moyen d'atteindre 100 % du service, cmdlet disponible ou non.

Voici la liste des modules (librairies) Power BI pour les scripts PowerShell.

Descriptif	Nom du module	Lien vers la galerie PowerShell
Module de cumul pour les applets de commande Power BI	NA
Module d’administration pour les applets de commande Power BI	MicrosoftPowerBIMgmt.Admin Module
Module de capacités pour les applets de commande Power BI	MicrosoftPowerBIMgmt.Capacities Module
Module de données pour les applets de commande Power BI	MicrosoftPowerBIMgmt.Data Module
Module de profil pour les applets de commande Power BI	MicrosoftPowerBIMgmt.Profile Module
Module de rapports pour Power BI	MicrosoftPowerBIMgmt.Reports Module
Module Espaces de travail pour Power BI	MicrosoftPowerBIMgmt.Workspaces Module

Mise en place de l'environnement PowerShell

Commençons par ouvrir Windows PowerShell ISE, c'est PowerShell mais avec une meilleure interface visuelle. L'exécuter en tant qu'admin est nécessaire pour la suite.

Installons les modules avec cette commande :

Install-Module -Name MicrosoftPowerBIMgmt

On se connecte ensuite à Power BI Service grâce à la commande

Connect-PowerBIServiceAccount

Vous pouvez passer sur la version PowerShell non ISE si vous avez un souci.

Une fenêtre de connexion apparaît. On s'identifie.

On est connecté. Essayons d'obtenir la liste des espaces de travail.

Get-PowerBIWorkspace -All

Et voilà ! Nous pouvons voir déjà pas mal d'informations sur chaque espace de travail. Nous allons télécharger un csv avec les informations sur les espaces de travail.

Si votre compte est un compte d'administrateur Power BI, vous pouvez utiliser un paramètre Scope et le définir sur Organization ; cela vous donnera accès à tous les espaces de travail de votre locataire (même si vous n'y avez pas accès et que d'autres utilisateurs de votre organisation les créent).

Get-PowerBIWorkspace -Scope Organization -All

La liste est beaucoup plus longue d'un coup.

Allons télécharger un csv avec la liste des espaces de travail pour pouvoir en faire un tableau de bord par exemple.

Get-PowerBIWorkspace -Scope Organization -All | ConvertTo-Csv | Out-File c:\PowerBIWorkspaces.csv

On constate que cela fonctionne ! On peut automatiser l'actualisation du fichier à 8h en planifiant la tâche avec le planificateur de tâches Windows ou ce script :

$a = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-NoProfile -Command "Connect-PowerBIServiceAccount; Get-PowerBIWorkspace -Scope Organization -All | ConvertTo-Csv | Out-File c:\PowerBIWorkspaces.csv"'
$t = New-ScheduledTaskTrigger -Daily -At 08:00
Register-ScheduledTask -TaskName 'PowerBI - Inventaire' -Action $a -Trigger $t -RunLevel Highest

Pour désactiver la tâche (elle reste enregistrée, prête à être réactivée) :

Disable-ScheduledTask -TaskName 'PowerBI - Inventaire'

Et pour la réactiver :

Enable-ScheduledTask -TaskName 'PowerBI - Inventaire'

Pour la supprimer définitivement :

Unregister-ScheduledTask -TaskName 'PowerBI - Inventaire' -Confirm:$false

Get-ScheduledTask -TaskName 'PowerBI - Inventaire' affiche son état (Ready / Disabled), et Start-ScheduledTask -TaskName 'PowerBI - Inventaire' la déclenche immédiatement — pratique pour tester sans attendre 8h. Console en admin, comme pour l'enregistrement.

Attention :

Avant de planifier : trois points à connaître

• La connexion n'est pas automatique. Connect-PowerBIServiceAccount en mode interactif ouvre une fenêtre de login : à 8h du matin, la tâche attendra que quelqu'un s'authentifie. Le jeton n'est pas conservé d'une session à l'autre.
• Pour une exécution vraiment automatique, il faut un compte de service (service principal) : une identité Entra ID qui s'authentifie sans intervention humaine. C'est un sujet à part entière — configuration côté Entra ID, autorisation dans les paramètres du tenant, gestion du secret — qu'on gardera pour un prochain article.
• La machine doit être allumée. Le Planificateur de tâches est local : si le poste est éteint ou en veille à 8h, rien ne s'exécute (l'option -StartWhenAvailable rattrape le tir au prochain démarrage, mais avec du retard). Pour un inventaire fiable, la cible c'est un serveur, une VM, ou une solution cloud type Azure Automation.

En clair : le script ci-dessus vous montre le mécanisme de planification. Le passage en production demande ces trois briques supplémentaires.

Comment déplacer des rapports Power BI d'un espace de travail Développement à un espace de travail Production avec PowerShell ?

On crée 2 espaces de travail : Article_PowerShell_DEV et Article_PowerShell_PROD

On exécute le script sur PowerShell.

$noms = 'Article_PowerShell_DEV', 'Article_PowerShell_PROD'
$noms | ForEach-Object { New-PowerBIWorkspace -Name $_ } |
    Select-Object Name, Id, IsOnDedicatedCapacity | Format-Table

Les espaces de travail sont créés.

On renomme et publie les 2 rapports (ne pas hésiter à utiliser Claude si vous n'êtes pas à l'aise avec les scripts bien longs ;)).

Connect-PowerBIServiceAccount

$espace   = Get-PowerBIWorkspace -Name 'Article_PowerShell_DEV'
$dossiers = 'C:\Users\User\Desktop\Formact\PBI', 'C:\Users\User\Desktop\ARCEP\PBI'
$cibles   = 'ARCEP', 'Formact'

if (-not $espace) { throw "Espace de travail introuvable." }

foreach ($dossier in $dossiers) {
    Get-ChildItem -Path $dossier -Filter '*.pbix' |
        Where-Object { $n = $_.BaseName -replace '^DEV_'; $n -in $cibles } |
        ForEach-Object {
            try {
                $fichier = if ($_.BaseName -like 'DEV_*') { $_ }
                           else { Rename-Item -Path $_.FullName -NewName "DEV_$($_.Name)" -PassThru }

                New-PowerBIReport -Path $fichier.FullName -Name $fichier.BaseName `
                                  -Workspace $espace -ConflictAction CreateOrOverwrite
                Write-Host "OK  : $($fichier.Name)" -ForegroundColor Green
            }
            catch {
                Write-Host "ERR : $($_.Exception.Message)" -ForegroundColor Red
            }
        }
}

Les 2 rapports sont bien renommés et publiés dans l'espace DEV.

On les passe en PROD.

$dev  = Get-PowerBIWorkspace -Name 'Article_PowerShell_DEV'
$prod = Get-PowerBIWorkspace -Name 'Article_PowerShell_PROD'
$tmp  = 'C:\Temp\Promotion'
New-Item -ItemType Directory -Path $tmp -Force | Out-Null

Get-PowerBIReport -Workspace $dev | ForEach-Object {
    $rapport = $_
    try {
        $nomProd = $rapport.Name -replace '^DEV_', 'PROD_'
        $chemin  = Join-Path $tmp "$nomProd.pbix"

        Export-PowerBIReport -Id $rapport.Id -WorkspaceId $dev.Id -OutFile $chemin
        New-PowerBIReport -Path $chemin -Name $nomProd -Workspace $prod -ConflictAction CreateOrOverwrite

        Write-Host "OK  : $($rapport.Name) -> $nomProd" -ForegroundColor Green
    }
    catch {
        Write-Host "ERR : $($rapport.Name) - $($_.Exception.Message)" -ForegroundColor Red
    }
}

On constate que ça marche.

On a bien passé les rapports en production.

Conclusion

On pourrait détailler l'ensemble des possibilités, mais ce serait trop long. Nous réservons d'autres fonctionnalités pour des articles ultérieurs.

Si cet article vous a plu et si vous souhaitez approfondir ces notions, n'hésitez pas à vous former directement avec nous.