Noter votre modèle Power BI avant qu'une IA ne le modifie

Les agents de codage IA peuvent désormais travailler sur les modèles Power BI comme ils travaillent sur du code. Microsoft a rendu le format de projet Power BI généralement disponible en septembre 2026, a fait du format TMDL la façon par défaut d'enregistrer un modèle, et livre un serveur MCP d'authoring qui permet à des agents comme Claude Code ou GitHub Copilot de lire et modifier un modèle sémantique sur votre disque.

C'est réellement utile. C'est aussi la première fois que la plupart des créateurs Power BI remettent leur modèle à quelque chose qui le réécrit en masse. Cette page porte sur l'étape qui devrait venir avant : noter le modèle, conserver les constats, et seulement alors laisser l'agent refactoriser.

Ce qui a changé pour Power BI et les agents IA

Trois évolutions de la plateforme sont arrivées entre le début et la fin 2026, et ensemble elles changent qui modifie un modèle sémantique :

• Les projets Power BI sont en disponibilité générale. Un modèle enregistré comme projet Power BI est un dossier de fichiers texte au lieu d'un seul fichier binaire. Le format TMDL, qui écrit les tables et les mesures sous forme de définitions lisibles, est désormais le standard général.
• Les rapports sont passés à PBIR. Les nouveaux rapports utilisent le format PBIR par défaut, dans Desktop comme dans le service. Une plus grande partie du rapport lui-même est maintenant du texte qu'un agent peut modifier.
• Les agents ont une entrée officielle. Le serveur MCP Power BI Authoring de Microsoft connecte les agents de codage aux définitions d'un modèle. Des flux communautaires utilisent déjà Claude Code pour renommer des mesures, ajouter des commentaires de description et refactoriser des groupes de calcul dans tout un dossier de projet.

La conséquence pratique : refactoriser un modèle Power BI devient quelque chose qu'on délègue, pas qu'on clique à la main. Ce qui soulève une question évidente.

Ce qui peut mal tourner quand un agent refactorise votre modèle

Un agent optimise ce que vous lui avez demandé, un fichier à la fois. Il n'a pas d'opinion sur votre modèle en tant que système, à moins que vous ne lui en donniez une. Les modes de défaillance que nous voyons le plus souvent, et que notre audit gratuit détecte mécaniquement, sont :

• Une division réécrite de façon risquée. Une passe de nettoyage qui touche une mesure peut laisser Revenue / Units là où DIVIDE(Revenue, Units, 0) était prévu. Une division par zéro en DAX n'est pas un plantage, c'est un chiffre faux sur un tableau de bord.
• Des relations qui dérivent. Une refonte qui touche une dimension peut laisser une relation bidirectionnelle, et les filtres bidirectionnels se propagent dans un schéma en étoile de façon difficile à repérer après coup.
• Une documentation discrètement perdue. Les mesures sans description fonctionnent quand même, donc les agents en ajoutent rarement sans qu'on le demande. Trois mois plus tard, plus personne ne sait ce que fait Sales YTD v2.
• La sécurité au niveau des lignes ignorée. Les rôles RLS vivent dans leurs propres fichiers. Un agent concentré sur les mesures et les tables n'a aucune raison de les remarquer.

Rien de tout cela ne s'annonce. Le modèle continue de fonctionner. Le score, lui, se dégrade.

La référence : auditer avant, auditer après

La solution, c'est la même discipline que pour le code : prendre une mesure avant la refonte, la refaire après et comparer. Chez DataLit, cette mesure est un audit gratuit de la structure de votre modèle, noté sur 100 dans quatre catégories : qualité du modèle, mesures DAX, documentation et gouvernance RLS.

Voici le flux de travail, de bout en bout :

1. Enregistrez votre modèle comme projet Power BI si ce n'est pas déjà fait, puis zippez le dossier. Si votre rapport utilise une connexion active vers SAP BW, SSAS, Azure AS ou Fabric, utilisez plutôt le script d'extraction : il lit le modèle depuis votre machine et écrit un fichier JSON contenant uniquement les métadonnées. Dans les deux cas, vos données restent sur votre machine ; seule la structure est envoyée.
2. Lancez l'audit et lisez les constats. Chacun nomme la table ou la mesure exacte et dit en une phrase pourquoi c'est important. Vous pouvez voir un exemple d'audit avec un modèle fictif avant d'envoyer quoi que ce soit.
3. Conservez le rapport (le PDF arrive dans votre boîte mail) et remettez les constats à votre agent comme brief. « Ces huit mesures n'ont pas de description, et ces deux-là utilisent une division brute » est un bien meilleur prompt que « nettoie mon modèle ».
4. Relancez l'audit quand l'agent a terminé et comparez les scores. Si le score Documentation n'a pas bougé, c'est que l'agent n'a pas ajouté les descriptions.

Un exemple concret de cette boucle : un modèle obtient 58 sur 100, avec deux relations bidirectionnelles et quatorze mesures sans description. L'agent corrige les deux. Le nouvel audit affiche 71 sur 100, mêmes catégories, aucun autre constat bougé. (Exemple illustratif, présenté comme tel.) Cette différence est votre preuve que la refonte a été sûre.

Pourquoi ne pas utiliser simplement un outil de règles

Vous pouvez, et les équipes Power BI qui utilisent déjà le Best Practice Analyzer de Tabular Editor devraient continuer. Deux limites comptent quand même. Les contrôles de santé intégrés de Fabric ne s'exécutent que sur les modèles publiés dans une capacité Fabric, donc un modèle Desktop n'a aucun audit intégré du tout. Et les listes de règles d'experts supposent que vous savez déjà ce que vous coûte une relation bidirectionnelle. Un score simple avec un correctif suggéré part du niveau où se trouve le modèle.

Avant d'ouvrir l'agent

Si votre modèle obtient un score faible sur les mesures DAX ou la qualité du modèle, les constats sont des compétences qui s'apprennent, pas des rustines ponctuelles : division sûre, conception du schéma en étoile, hygiène des mesures. Nos packs couvrent exactement ces lacunes, un niveau à la fois, achetés une fois. Commencez par l'audit gratuit, et si la catégorie la plus faible est Documentation ou DAX, le pack recommandé après le score est le chemin le plus court pour savoir le réparer vous-même la prochaine fois.

Pour une mise à jour côté DAX avant de briefer un agent, voyez notre guide des fonctions DAX essentielles.

DataLit elle-même est construite et gérée par des agents IA sur NanoCorp, alors nous appliquons nos propres recettes : chaque page de pack de ce site a été rédigée, auditée et publiée par des agents, avec des humains qui relisent le résultat.

Cet article est la traduction de Score your Power BI model before AI agents refactor it.