Power BI, MCP, et là où l'IA peut vraiment faire la différence.

Les fichiers Power BI sont du JSON sous le capot, comme la plupart de la suite Microsoft Office. Cela signifie qu'un modèle d'IA peut les lire, comprendre leur structure et apporter des modifications ciblées sans toucher à quoi que ce soit en dehors du périmètre de ce que vous lui avez demandé.

Le serveur MCP de Power BI expose cette structure à un LLM d'une manière réellement exploitable. L'application la plus concrète pour l'instant concerne le travail sur les mesures. Quand Stephen lui a demandé de générer des mesures pour un tableau de bord, la sortie est revenue formatée en Tabular Modeling Definition Language, ce qui garde tout le contenu généré isolé du reste du fichier. En cas d'erreur, vous n'avez pas à démêler un chaos à travers tout le rapport.

Créer des pages et des mises en page visuelles, c'est une autre histoire. L'IA peut s'y essayer, mais les résultats exigent un nettoyage manuel conséquent et une bonne compréhension du format de fichier pour résoudre les problèmes. Pour l'instant, MCP est le plus fiable lorsqu'on le dirige vers la couche sémantique plutôt que vers la couche visuelle.

La réponse honnête, après avoir utilisé ces outils sur plusieurs projets, est que l'IA est fiable pour reproduire des schémas et vraiment peu fiable pour l'analyse originale.

Si vous donnez à un LLM un ensemble d'exemples réels issus d'un travail déjà réalisé et que vous lui demandez d'appliquer le même schéma à des problèmes similaires, vous pouvez obtenir de 25 à 50 % de gain de temps. Demandez-lui de construire quelque chose à partir de zéro sans aucun matériel de référence, et le taux d'erreur rend l'exercice plus coûteux qu'il ne rapporte.

Une partie de l'explication tient à un problème de données d'entraînement. Il existe d'énormes quantités de code open source dont les LLM peuvent apprendre. Le travail sur les données en entreprise, avec ses schémas spécifiques, sa logique métier et ses conventions de domaine, est en grande partie privé. Les modèles n'en ont pas vu grand-chose, contrairement à Python que l'on trouve dans d'innombrables dépôts de code publics.

L'implication pratique est que plus vous pouvez fournir de contexte, meilleure est la sortie. Donnez-lui votre dictionnaire de données réel, vos mesures existantes, vos métriques documentées. Si vous travaillez avec une base de données non documentée et devez cartographier les relations entre une centaine de tables, lui fournir le schéma réel et le laisser raisonner sur les noms de colonnes est bien plus efficace que de lui demander de générer la logique à partir d'une description.

Une approche à tenter pour les jeux de données en désordre : utilisez un modèle à grand contexte comme Gemini, donnez-lui un accès en lecture seule à des données d'exemple, et faites-lui échantillonner les données au hasard pour se construire une compréhension pratique du schéma réel avant de générer quoi que ce soit. Attention au coût si vous interrogez via un outil comme Databricks ou Snowflake, où l'IA peut lancer des requêtes itératives coûteuses sans les filtres et l'élagage qu'un analyste penserait à utiliser.

Le cas d'usage du contrôle qualité est celui où cela devient le plus intéressant pour les équipes qui gèrent des tableaux de bord complexes ou en évolution rapide.

Le problème précis : un tableau de bord d'environ 100 métriques, que l'on fait évoluer plus vite que le back-end ne peut suivre. De nouveaux rapports chaque semaine. Aucun moyen fiable de vérifier que les chiffres restent corrects après chaque mise à jour.

Cela règle le volet données. Pour un test de bout en bout qui inclut ce que Power BI affiche réellement, il existe une approche à explorer qui n'a pas encore été entièrement développée. Power BI peut être configuré pour exporter des rapports PDF planifiés. Transmettez ces PDF à un modèle multimodal, faites-lui faire de l'OCR sur les chiffres, et comparez aux valeurs attendues.

Un autre cas d'usage qui découle du travail direct sur le format de fichier Power BI : la création de modèles de rapports à grande échelle.

L'idée est simple. Construisez un rapport bien structuré qui couvre les KPI, les tendances et les classements que 90 % des clients veulent voir. Paramétrez la source de données. Au moment de démarcher un nouveau client, récupérez sur son site ses couleurs de marque et son logo, générez un nouveau fichier de données au format requis, intégrez son identité visuelle, et produisez un rapport fonctionnel à sa marque en une heure environ plutôt que de tout reconstruire de zéro.

Zach a relevé un parallèle avec le fonctionnement de Pencil.dev : une couche d'interface qui stocke la mise en page sous la forme d'un blob JSON avec des SVG intégrés, et un serveur MCP qui donne à Claude accès au canevas. La même architecture pourrait s'appliquer à Power BI. La structure du rapport réside dans un fichier JSON. Un serveur MCP qui exposerait cette structure à un LLM rendrait la génération programmatique de rapports bien plus pratique que l'approche de scripting actuelle.

Pour quiconque fait du développement commercial dans le domaine de la BI, cela vaut la peine d'être développé. Une démo fonctionnelle à la marque du client, générée à partir de ses propres données et dans ses propres couleurs, avant même un deuxième échange, change la dynamique commerciale.

Quelques remarques pratiques sur la question des outils.

Cursor est performant mais coûteux pour un usage sérieux. Si vous le sollicitez beaucoup sur un vrai projet, il est facile de dépenser 100 à 200 $ par jour. Ses paliers tarifaires sont mal pensés pour un usage professionnel soutenu.

Zed mérite d'être envisagé comme alternative. Il est gratuit, écrit en Rust et indépendant du modèle. Vous apportez vos propres identifiants d'API pour le modèle de votre choix, ce qui signifie que vous n'êtes pas enfermé dans la tarification d'un seul fournisseur. Il s'intègre avec Claude, OpenAI et d'autres.

Du côté de Claude Code, il est possible de le configurer pour fonctionner avec des modèles autres que ceux d'Anthropic. L'exécuter avec un modèle chinois à poids ouverts comme GLM47 vous donne la gestion de contexte de Claude Code pour une fraction du coût, sur des tâches qui n'exigent pas un raisonnement de pointe. Pour des charges de travail où la question se résume à « est-ce que ces deux choses correspondent » plutôt qu'à quoi que ce soit nécessitant une réelle intelligence, cet arbitrage peut avoir du sens. Faire tourner le modèle en local sur un Mac haut de gamme ou un PC de jeu signifie qu'aucune donnée ne quitte votre machine, ce qui compte pour le travail avec des clients.

Le point plus large sur le choix des modèles : les modèles ont des forces différentes, la tarification varie fortement selon le type de tâche, et les traiter comme non interchangeables est une habitude coûteuse.