août 16, 2023Lire l'article
Dans notre premier article sur le Power BI MCP Server, nous avons expliqué ce qu'est le Model Context Protocol, comment installer le serveur MCP de Microsoft et comment le connecter à Claude Desktop ou à GitHub Copilot dans Visual Studio Code. C'est aujourd'hui l'article le plus lu de ce blog, et la question qui revient le plus souvent ensuite est simple : « D'accord, le Power BI MCP est installé. Et maintenant, je lui demande quoi ? »
Cet article répond à cette question. Nous avons retenu 10 prompts que nous utilisons réellement en mission et en formation avec le Power BI Modeling MCP Server, classés en trois familles : construire, documenter et auditer un modèle sémantique Power BI. Pour chacun, vous trouverez le prompt tel que nous le formulons, le résultat obtenu dans Power BI Desktop et le point de vigilance à garder en tête.
Le Model Context Protocol (MCP) est un standard ouvert qui permet à un agent IA (Claude, GitHub Copilot ou tout autre client MCP) d'appeler des outils exposés par un serveur MCP. Dans l'écosystème Power BI, Microsoft a publié deux serveurs MCP complémentaires :
| Serveur MCP | Où il s'exécute | À quoi il sert |
| Power BI Modeling MCP Server (serveur MCP local) | Sur votre machine | Construire et modifier les modèles Power BI : tables, colonnes, mesures, relations, propriétés |
| Power BI MCP Server distant | Dans le cloud Microsoft | Interroger des modèles sémantiques publiés et générer des analyses en DAX |
C'est le serveur MCP de modélisation Power BI qui nous intéresse ici. Il s'exécute localement, communique avec le modèle via le protocole XMLA (le même que Tabular Editor) et apporte à l'agent IA les capacités de modélisation sémantique de Power BI : lire la structure du modèle, créer ou renommer des objets, exécuter des requêtes DAX. Il se connecte indifféremment à un fichier Power BI ouvert dans Power BI Desktop, à un modèle sémantique publié dans un espace de travail Microsoft Fabric, ou à un projet Power BI (Power BI Project, format PBIP) avec ses fichiers TMDL sur disque.
Pour reproduire les prompts ci-dessous, il vous faut :
Deux précautions avant de commencer :
Tous les prompts ci-dessous ont été testés avec Claude Desktop comme client MCP, sur un modèle de ventes classique : une table de faits Ventes, des dimensions Produit, Client et Magasin, sans table de dates au départ.
Le prompt :
Crée une table calculée nommée Calendrier couvrant du 1er janvier de la première année présente dans Ventes[DateCommande] au 31 décembre de la dernière. Ajoute les colonnes Année, Trimestre (format "T1 2025"), Mois (numéro), NomMois (en français), AnnéeMois (clé de tri AAAAMM), Semaine ISO, JourSemaine et un indicateur JourOuvré. Trie NomMois par Mois et AnnéeMois par sa clé. Marque la table comme table de dates sur la colonne Date, puis crée la relation avec Ventes[DateCommande].
Le résultat : en une seule passe, le serveur MCP a généré l'expression DAX basée sur CALENDAR et MIN/MAX sur la colonne de faits, ajouté les colonnes demandées, appliqué les tris (Sort by column), marqué la table comme table de dates et créé la relation un-à-plusieurs. Le seul ajustement manuel : le format de la colonne Date, resté en date-heure, que nous avons passé en date courte.
Point de vigilance : précisez toujours la langue des noms de mois et la logique de tri. Sans consigne explicite, vous obtiendrez des mois en anglais triés par ordre alphabétique. Si vous préférez construire votre calendrier en Power Query plutôt qu'en DAX, le MCP Server ne modifie pas les requêtes Power Query : vous le ferez à la main. Pour aller plus loin sur les choix de conception, consultez notre guide sur la table de dates dans Power BI.
Le prompt :
Crée un dossier d'affichage Mesures de base dans la table Ventes et ajoute les mesures suivantes, formatées en euros sans décimale : CA (somme de Ventes[Montant]), Quantité vendue (somme de Ventes[Quantite], format entier), Nombre de commandes (nombre distinct de Ventes[NumeroCommande]) et Panier moyen (CA divisé par nombre de commandes, avec DIVIDE).
Le résultat : quatre mesures créées dans le bon dossier d'affichage, avec les formats demandés. L'agent a spontanément utilisé DIVIDE pour le panier moyen, ce qui évite les erreurs de division par zéro.
Point de vigilance : nommez les mesures vous-même dans le prompt. Laisser l'agent choisir les noms donne des résultats hétérogènes (mélange de français et d'anglais, majuscules incohérentes) qu'il faudra corriger plus tard.
Le prompt :
À partir de la mesure CA, crée les mesures CA N-1 (même période l'année précédente via SAMEPERIODLASTYEAR sur Calendrier[Date]), Variation CA (différence) et Variation CA % (variation divisée par CA N-1 avec DIVIDE, format pourcentage à une décimale). Place-les dans un dossier Time Intelligence.
Le résultat : les trois mesures sont générées correctement et fonctionnent immédiatement dans un visuel, parce que la table de dates existe et est marquée comme telle depuis le prompt 1. Le DAX produit est propre :
dax
Variation CA % =
DIVIDE ( [Variation CA], [CA N-1] )
Point de vigilance : c'est ici que l'ordre des prompts compte. Sans table de dates marquée, SAMEPERIODLASTYEAR renvoie une erreur ou un résultat faux, et l'agent ne le signalera pas forcément.
Le prompt :
Crée CA cumulé annuel avec TOTALYTD sur Calendrier[Date] et CA cumulé annuel N-1 en combinant TOTALYTD et SAMEPERIODLASTYEAR. Même format que CA, même dossier Time Intelligence.
Le résultat : deux mesures fonctionnelles. Pour la seconde, l'agent a proposé la formulation CALCULATE ( [CA cumulé annuel], SAMEPERIODLASTYEAR ( Calendrier[Date] ) ), qui est la plus lisible.
Point de vigilance : si votre exercice fiscal ne commence pas en janvier, indiquez la date de fin d'exercice dans le prompt (TOTALYTD accepte un troisième argument). L'agent ne posera pas la question de lui-même.
Le prompt :
Liste les tables qui n'ont aucune relation avec Ventes. Pour chacune, propose la relation la plus probable en te basant sur les noms et les types de colonnes, indique la cardinalité et le sens du filtre, et attends ma validation avant de créer quoi que ce soit.
Le résultat : l'agent a identifié que Magasin n'était reliée à rien et proposé Magasin[CodeMagasin] → Ventes[CodeMagasin] en un-à-plusieurs, filtre simple. Après validation, la relation a été créée en quelques secondes.
Point de vigilance : la formule « attends ma validation » est essentielle sur tout ce qui touche à la structure. Une relation mal orientée ou bidirectionnelle par défaut peut fausser silencieusement tous vos chiffres.
Le prompt :
Pour chaque colonne et chaque mesure du modèle dont la description est vide, rédige une description en français d'une phrase, orientée métier, qui explique ce que représente l'objet et, pour les mesures, comment il est calculé. Écris ces descriptions dans la propriété Description de chaque objet.
Le résultat : une cinquantaine de descriptions générées et appliquées en moins d'une minute. Elles apparaissent ensuite dans l'infobulle du volet Données de Power BI Desktop et sont reprises par Copilot dans le service Power BI. Exemple obtenu pour Panier moyen : « Montant moyen d'une commande, calculé en divisant le chiffre d'affaires par le nombre de commandes distinctes. »
Point de vigilance : relisez les descriptions des colonnes dont le nom est ambigu (Statut, Type, Code1). L'agent ne connaît pas votre métier et produira une description plausible mais générique. C'est là que vous apportez la valeur.
Le prompt :
Liste toutes les colonnes visibles dont le nom contient un underscore, un préfixe technique (dim_, fct_, id_) ou une abréviation. Propose pour chacune un nom lisible en français, avec espaces et majuscule initiale. Présente le tableau avant/après et attends ma validation avant de renommer.
Le résultat : un tableau de 18 colonnes avec les renommages proposés (cust_id → Identifiant client, prod_cat → Catégorie produit…). Après validation, l'agent a appliqué les renommages en une seule opération.
Point de vigilance : renommer une colonne via le Power BI Modeling MCP Server met à jour le modèle, mais pas les visuels du rapport. Les visuels qui référencent l'ancien nom perdent leur champ. Faites cette opération en début de projet, avant de construire les pages, ou limitez-la aux colonnes non encore utilisées. Si vous travaillez en Power BI Project avec TMDL, un rechercher-remplacer dans les fichiers du rapport peut compléter l'opération.
Le prompt :
Génère un dictionnaire de données du modèle au format Markdown : une section par table avec sa description, puis un tableau listant chaque colonne avec son type, son format, sa description et son statut (visible / masquée). Ajoute une section finale avec toutes les mesures, leur expression DAX et leur dossier d'affichage.
Le résultat : une documentation Markdown complète, prête à être collée dans un wiki, une page SharePoint ou un README de dépôt Git. Combiné au prompt 6, vous obtenez une documentation exploitable du modèle sémantique en deux prompts, là où cette tâche prenait une demi-journée.
Point de vigilance : la documentation est une photographie. Relancez le prompt à chaque livraison, ou intégrez-le dans une routine de déploiement.
Le prompt :
Liste toutes les mesures qui ne sont référencées par aucune autre mesure du modèle. Liste ensuite toutes les colonnes visibles de la table Ventes qui ne sont utilisées ni dans une mesure, ni dans une relation, ni dans un tri. Ne supprime rien.
Le résultat : l'agent a identifié 7 mesures orphelines (dont trois mesures de test oubliées) et 4 colonnes de la table de faits qui n'intervenaient dans aucun calcul.
Point de vigilance : le serveur MCP de modélisation voit le modèle sémantique, pas le rapport. Une mesure qui n'est référencée par aucune autre mesure peut très bien être utilisée directement dans un visuel. Avant toute suppression, croisez avec un outil qui analyse aussi la couche rapport, ou vérifiez visuellement. La consigne « ne supprime rien » n'est pas une option.
Le prompt :
Audite ce modèle selon les bonnes pratiques du schéma en étoile et de la performance. Vérifie en particulier : relations bidirectionnelles, relations plusieurs-à-plusieurs, colonnes calculées qui pourraient être des mesures, colonnes de haute cardinalité dans les tables de faits (identifiants, horodatages), colonnes de date-heure non séparées, tables de dates non marquées, Auto date/time, mesures sans format, colonnes clés non masquées. Pour chaque point, indique la gravité, les objets concernés et l'action recommandée. Ne modifie rien.
Le résultat : un rapport structuré en trois niveaux de gravité. Sur notre modèle de test, les constats les plus utiles ont été une relation bidirectionnelle héritée d'une ancienne version, une colonne DateHeureCommande de haute cardinalité qui gonflait la taille du fichier Power BI, et douze mesures sans format défini. Chaque constat était accompagné de l'action corrective, que nous avons pu ensuite faire appliquer prompt par prompt.
Point de vigilance : l'audit est aussi bon que la liste de contrôle que vous lui donnez. Un prompt « audite mon modèle » sans critères produit des généralités. Le prompt ci-dessus est notre liste de contrôle standard en formation ; adaptez-la à vos conventions de modélisation Power BI.
Trois enseignements ressortent de ces tests, et ils valent pour tous les usages des serveurs MCP Power BI :
Le Power BI MCP Server ne remplace pas la compréhension du modèle sémantique : il en accélère la construction pour ceux qui savent déjà ce qu'ils veulent obtenir. C'est précisément la raison pour laquelle nous l'intégrons désormais dans nos formations Power BI, en complément des fondamentaux du schéma en étoile, de Power Query et du DAX.
Si vous préférez une approche en ligne de commande, notre article sur Claude et pbi-cli couvre un flux de travail complémentaire, orienté fichiers Power BI Project, TMDL et contrôle de version.
Quelle différence entre le Power BI Modeling MCP Server et le Power BI MCP Server distant ? Le serveur MCP local (Modeling) s'exécute sur votre machine et sert à construire et modifier les modèles Power BI. Le serveur distant, hébergé par Microsoft, sert à interroger des modèles sémantiques publiés et à générer des analyses. Pour les 10 prompts de cet article, c'est le serveur local qu'il faut.
Le Power BI MCP Server fonctionne-t-il avec un modèle publié dans le service ? Oui. Le serveur MCP local peut se connecter à un modèle sémantique Fabric via le point de terminaison XMLA, à condition que la capacité le permette et que vous disposiez des droits d'écriture. Les prompts s'appliquent de la même façon.
Peut-on utiliser ces prompts avec GitHub Copilot dans VS Code plutôt qu'avec Claude ? Oui. Les prompts sont indépendants du client MCP. Nous les avons testés avec Claude Desktop, mais l'extension Power BI Modeling MCP pour Visual Studio Code donne des résultats comparables avec GitHub Copilot Chat.
Le serveur MCP peut-il modifier les requêtes Power Query ? Non. Le Power BI Modeling MCP Server agit sur la couche modèle sémantique (tables, colonnes, mesures, relations, propriétés), pas sur les étapes de transformation Power Query ni sur les visuels du rapport.
Les modifications faites par l'agent sont-elles réversibles ? Dans Power BI Desktop, elles sont appliquées au modèle en mémoire : fermer sans enregistrer les annule. Sur un modèle publié, il n'y a pas de retour arrière automatique. Travaillez toujours sur une copie ou un environnement de développement, idéalement en Power BI Project avec TMDL sous contrôle de version.
Vous voulez mettre en place ces pratiques dans votre équipe ? MYPE accompagne les organisations sur Power BI, Microsoft Fabric et l'intégration de l'IA dans les workflows data. Découvrez nos formations Power BI ou contactez-nous.
