MCP Power BI Modeling : retour d’expérience avec Claude Code

Qu’est-ce que le MCP Power BI ?

Le MCP (Model Context Protocol) est un standard qui permet à un agent IA d’utiliser des outils externes sans développement spécifique pour chaque action. On l’avait vu côté plateforme avec le MCP Microsoft Fabric. Ici, on descend d’un cran : celui du modèle sémantique.

Le Power BI Authoring MCP server permet à un agent de créer, modifier et supprimer, en langage naturel :

• les tables, colonnes et mesures ;
• les relations et hiérarchies ;
• les groupes de calcul, perspectives et partitions ;
• les rôles de sécurité (RLS).

Il sait aussi exécuter des requêtes DAX pour tester ses propres modifications (dans la limite de 100 000 lignes), appliquer des modifications en masse (renommer des centaines d’objets, modifier du DAX), évaluer des bonnes pratiques, et travailler directement sur des fichiers TMDL / PBIP, donc avec du contrôle de version.

Le Power BI Authoring MCP server, peut être utilisé dans trois cas d’usage : un fichier ouvert dans Power BI Desktop, un modèle dans un espace de travail Fabric, ou un dossier PBIP. Il faut au minimum le droit d’écriture (ou Build) sur le modèle. Pour un modèle publié dans Fabric, il faut aussi que l’administrateur ait activé l’endpoint XMLA en lecture/écriture sur la capacité. Aucun réglage n’est nécessaire pour un fichier ouvert dans Power BI Desktop.

De l’installation à l’utilisation : les limites rencontrées

Avant le premier test utile, il y a quelques marches à franchir. Aucune n’est bloquante, mais mieux vaut les connaître.

• Un chemin qui casse à chaque mise à jour. J’ai installé le serveur via l’extension VS Code. Celle-ci s’est mise à jour toute seule (de la 0.5.12 à la 1.0.0), alors que la configuration de Claude Code pointait encore vers l’ancien dossier, supprimé. Résultat : serveur inaccessible. Claude Code a trouvé la cause et corrigé le chemin (après avoir sauvegardé le fichier de configuration), mais le problème reviendra à la prochaine mise à jour.
• Un serveur qui ne se recharge pas en cours de route. Les serveurs MCP ne sont chargés qu’au démarrage de la session : après chaque modification de configuration, il faut reconnecter le serveur /mcp ou recharger la fenêtre.
• Une licence à accepter explicitement. Tant que l’EULA Microsoft n’est pas accepté, tous les outils renvoient une erreur. Claude Code a refusé de l’accepter à ma place : c’est ma décision, pas la sienne. Ajouter l’argument --accept-eula dans la configuration ne suffit pas tant que le serveur déjà lancé n’est pas redémarré. J’ai finalement donné moi-même l’instruction explicite d’utiliser l’outil accept_eula.
• Des noms qui doivent être exacts. Pour se connecter à un modèle Fabric, il faut le nom exact de l’espace de travail et du modèle. Une faute de frappe dans le nom de l’espace de travail et la connexion échoue. À noter que lorsqu’aucun espace de travail ou modèle ne correspond, l’agent IA via le MCP fait des propositions de ce qui pourrait correspondre à notre recherche.
• Un recalcul à déclencher après certaines modifications. Après la création d’une table ou d’une relation, le modèle doit être actualisé avant de pouvoir être interrogé. Le serveur le signale, et Claude Code a lancé cette actualisation tout seul dès que ma première requête DAX a échoué.

Les tests : ce qui a bien fonctionné

Je n’ai pas suivi un protocole rédigé à l’avance : j’ai enchaîné des demandes du quotidien d’un utilisateur Power BI, volontairement formulées de façon courte et parfois imprécise. Le premier modèle est un petit fichier Power BI Desktop (67 lignes), le second un modèle Direct Lake publié dans Fabric.

Ce qui fonctionne très bien

• La boucle écrire, puis vérifier. Après chaque création, Claude Code exécute lui-même une requête DAX pour contrôler le résultat. Quand une création ne renvoie rien, il vérifie que l’objet existe vraiment. Je n’ai pas eu à ouvrir un visuel pour savoir si ça marchait.
• Les tests de sécurité. Sur la RLS, il a simulé le rôle et m’a montré le résultat : le nombre de projets passe de 67 à 36 et la mesure sur les anomalies devient vide. C’est la preuve que la restriction ne peut pas être contournée par une mesure.
• Le travail sur un modèle publié. Sur le modèle Fabric, les modifications sont actives immédiatement, sans publication ni enregistrement.
• L’édition directe du TMDL. Pas d’interface, pas de clics : des fichiers modifiés proprement, pouvant être relus et versionnables.

Ce qui a moins bien fonctionné

Rien de dramatique, mais plusieurs points m’ont rappelé qu’un agent exécute ce qu’on lui demande, pas forcément ce qu’on veut dire.

• Une demande littérale, techniquement juste mais métier incorrecte. J’ai demandé la somme de cost_price : la mesure a été créée et renvoie 233,70. Sauf que c’est la somme des coûts unitaires des produits, sans lien avec les quantités vendues. Le coût réel des ventes est de 1 400,00. C’est Claude Code qui l’a signalé, pas moi.
• Des noms approximatifs qui font perdre un aller-retour. « Indicateur » au lieu de « Indicateurs », « Sandbox_data_nbe » au lieu de « SANBOX_DATA_NBE » : la première tentative échoue à chaque fois. Il rattrape, mais ce n’est pas instantané.
• Aucun filet de sécurité sur un modèle publié. Les modifications sont actives tout de suite sur le modèle Fabric. C’est pratique, mais il n’y a ni brouillon ni retour arrière automatique.
• Des fichiers modifiés pendant que Desktop est ouvert. Pour le TMDL, Claude Code m’a prévenu que si j’enregistrais depuis Power BI Desktop, mes modifications seraient écrasées par l’ancienne culture encore en mémoire. Il m’a fallu fermer sans enregistrer. Il n’a pas non plus vérifié lui-même que le projet se rouvrait correctement.
• Ce que le serveur ne fait pas. L’affectation d’un utilisateur à un rôle RLS reste à faire dans le service Power BI (via le MCP Fabric), et les rapports comme les visuels sont hors périmètre.
• Un garde-fou qui bloque aussi les bonnes commandes. Pour changer la culture du modèle, Claude Code a enchaîné plusieurs opérations dans une seule commande PowerShell. Le contrôle de sécurité l’a refusée en entier, probablement à tort : un caractère d’encodage invisible a été pris pour un chemin à supprimer. Claude Code a vérifié qu’aucun fichier n’avait été touché, puis refait l’opération étape par étape. Ce n’est pas un défaut du MCP, mais le réflexe est utile : l’agent contrôle l’état au lieu de le supposer.

Ce qui m’a le plus surpris : un agent qui comprend et qui anticipe

Le MCP apporte les outils. Mais c’est Claude Code qui apporte le raisonnement, et c’est là que l’expérience change vraiment de ce qu’on connaît avec un simple chat.

Il comprend sans qu’on soit précis.

Mes consignes tenaient souvent en une ligne.

• « Fais un count de la colonne Flag Anomalie » : il a d’abord regardé les valeurs de la colonne (OK : 36, Anomalie : 31), constaté qu’un COUNT simple renverrait 67, comme la mesure existante, et créé une mesure qui compte uniquement les anomalies.
• « Une mesure pour le taux » : sans précision, il a calculé le taux d’anomalies, l’a dit clairement, et m’a donné l’alternative chiffrée (53,7 % de projets OK) si je pensais à l’autre.
• « Jean peut voir uniquement les flag anomalie OK » : il en a déduit une RLS, l’a branchée sur la table que nous venions de créer, et l’a testée.
• « Si on reprend notre modèle initial » : il a retrouvé seul le projet PBIP correspondant sur le disque, en identifiant le fichier ouvert dans Power BI Desktop.

Il propose des améliorations que je n’avais pas demandées.

• Après la création de la table Anomalie, il a noté que les mesures filtraient encore l’ancienne colonne et recommandé de les rebrancher sur la nouvelle table (schéma en étoile), de masquer l’ancienne colonne, et de construire la table avec DISTINCT plutôt qu’avec des valeurs écrites en dur.
• Sur la RLS, il a prévenu que les administrateurs, membres et contributeurs voient tout, que la restriction ne vaut que pour les lecteurs, et qu’un utilisateur sans rôle ne voit rien. Il a proposé un rôle « Accès complet ».
• Pour la marge, il a ajouté la mesure CA, indispensable au calcul mais absente de ma demande, en le disant explicitement.

Il challenge, y compris son propre travail.

Quand j’ai demandé si la mesure Nb Projets OK pouvait être optimisée, la réponse a été honnête : sur 67 lignes, le gain de performance est nul. Il a quand même proposé COUNTROWS pour la lisibilité, déconseillé FILTER qui serait plus lent, et signalé un comportement subtil de CALCULATE : le filtre de la mesure remplace celui d’un segment, sauf avec KEEPFILTERS.

Il dit quand ma demande n’a pas de sens.

en-EN n’existe pas comme code de culture. Plutôt que de deviner, il m’a posé deux questions (en-US ou en-GB, et faut-il aussi changer la culture de lecture des sources Power Query), puis a sauvegardé le dossier avant d’y toucher.

Limites et points de vigilance

Conclusion