I. Introduction
Quand on veut automatiser des tâches Power BI ( auditer les accès, surveiller l’usage des rapports, gérer les workspaces) la solution classique est l’API REST Power BI. Elle fonctionne. Mais elle a un coût : avant d’écrire la moindre ligne de code utile, il faut gérer l’authentification, la pagination des résultats, la transformation du JSON en tableau exploitable… Bref, beaucoup de plomberie pour peu de valeur ajoutée.
Depuis que je travaille dans Microsoft Fabric, j’ai découvert une alternative qui change vraiment la donne : la librairie Python semantic-link-labs.
II. Un petit exemple : la liste des workspaces
A. Le problème avec l’API REST
Concrètement, voici ce qu’il faut faire rien que pour récupérer la liste des workspaces via l’API REST :
- Enregistrer une application dans Azure Active Directory
- Configurer les permissions et générer un secret
- Écrire le code d’authentification (avec la librairie MSAL)
- Appeler l’API, gérer la pagination (les résultats arrivent par tranches de 100)
- Convertir le JSON retourné en tableau utilisable
C’est faisable, mais c’est long, technique, et source d’erreurs. Et il faut refaire tout ça pour chaque nouveau script.
B. La même chose avec semantic-link-labs
pythonimport sempy_labs as labs
df = labs.admin.list_workspaces()
display(df)
Trois lignes. Un DataFrame pandas directement exploitable. L’authentification, la pagination, la conversion du JSON : tout est géré en coulisses par la librairie.
III. L’intérêt de la librairie semantic-link-lab
A. Ce qu’elle permet de faire
Au-delà de la simplicité, semantic-link-labs couvre un large périmètre de gouvernance et d’administration Power BI :
- Audit des accès : qui a accès à quel rapport, avec quel niveau de permission
- Suivi de l’usage : quels utilisateurs ouvrent réellement les rapports (et lesquels ne le font jamais.)
- Inventaire des assets : liste des rapports, modèles, workspaces, items inutilisés
- Analyse des modèles sémantiques : Best Practice Analyzer, Vertipaq Analyzer, accès au Tabular Object Model
- Migration vers Direct Lake : automatisation complète du passage depuis les modes Import ou DirectQuery
- Administration : gestion des capacités, des pipelines de déploiement, des environnements
B. L’intégration native avec Fabric : le vrai avantage
Ce qui distingue vraiment semantic-link-labs de l’API REST, c’est son intégration dans l’écosystème Fabric. Les résultats de chaque fonction sont des DataFrames pandas, directement enregistrables dans un Lakehouse sous forme de tables Delta. Ces tables sont ensuite exploitables en Direct Lake dans un rapport Power BI de gouvernance, sans aucune étape intermédiaire.
L’ensemble du pipeline (collecte, stockage, visualisation) tient dans un seul notebook Fabric planifiable, sans infrastructure externe.
C. Les limites à connaître
semantic-link-labs ne remplace pas l’API REST dans tous les cas.
Quelques points d’attention :
- Les fonctions d’administration nécessitent le rôle Fabric Administrator sur le tenant
- La librairie évolue rapidement : les signatures de fonctions peuvent changer entre les versions.
- Certaines opérations très spécifiques (transfert de propriété d’un modèle, par exemple) restent réservées à l’API REST
IV. En résumé
Si vous travaillez dans Microsoft Fabric et que vous avez des besoins de gouvernance ou d’automatisation Power BI, semantic-link-labs est clairement le point de départ à privilégier. Elle ne remplace pas l’API REST pour tout, mais elle couvre l’essentiel des cas du quotidien avec une fraction de la complexité.
L’API REST reste utile pour les opérations spécifiques qu’elle seule expose, ou pour les automatisations qui s’exécutent en dehors de Fabric. Mais pour un référent BI qui vit dans les notebooks Fabric, c’est désormais l’outil naturel.
Pour aller plus loin :
Documentation semantic-link-labs
GitHub microsoft/semantic-link-labs
Cet article a été rédigé par Stéphane BADRE, consultant Seenovate et référent Microsoft Data.
