MCP et Microsoft Fabric : piloter toute la plateforme en langage naturel

Dans notre article précédent sur le format PBIP, comment faire passer Power BI à l’ère DevOps : des fichiers texte lisibles, versionnables sous Git, éditables dans VS Code. C’était un premier pas vers une plateforme de développement professionnelle.

Une nouvelle brique vient prolonger cette logique, et cette fois, elle touche l’ensemble de la plateforme Microsoft Fabric. Le Model Context Protocol (MCP) permet à un agent IA d’administrer vos environnements Fabric en langage naturel : créer des espaces de travail, manipuler des données, construire des modèles, gérer des permissions. Sans passer par l’interface. Sans connaître les API par cœur.

Qu’est-ce que le MCP ?

Le MCP est un protocole universel qui définit comment un assistant IA interagit avec des outils externes de manière structurée et sécurisée. Il repose sur trois composants :

• L’hôte — l’environnement dans lequel vous travaillez, par exemple VS Code
• Le client — l’agent IA qui reçoit vos instructions, par exemple Copilot ou Claude
• Le serveur — le programme qui expose les capacités de Fabric à l’agent, par exemple le Fabric MCP Server

Avant le MCP, connecter un assistant IA à Fabric nécessitait d’écrire du code spécifique pour chaque action, de gérer l’authentification manuellement, et de connaître en détail les API de chaque composant Fabric. Avec le MCP, n’importe quel agent compatible, Copilot, Claude, ou un agent personnalisé, peut interagir avec Fabric via un protocole standardisé, sans développement spécifique.

Le Fabric MCP Server : ce qu’il fait concrètement

Le Fabric MCP Server s’installe via une extension VS Code. Une fois connecté à votre compte Microsoft, l’agent IA a accès à l’ensemble de votre environnement Fabric. Il couvre six grandes catégories d’opérations :

• Recherche dans le catalogue — trouver des objets par nom, type ou espace de travail (lakehouses, notebooks, pipelines, modèles sémantiques…)
• Gestion des espaces de travail — lister, créer, modifier, supprimer
• Gestion des objets Fabric — créer, modifier, supprimer tous types d’objets
• Gestion des permissions — attribuer et révoquer des accès (administrateur, membre, contributeur, lecteur)
• Organisation — structurer les espaces de travail en dossiers
• Suivi des capacités — vérifier les ressources disponibles et les statuts d’opérations

Des tâches qui nécessitaient auparavant plusieurs écrans et une connaissance fine des API deviennent de simples instructions :

Sur la sécurité, un point important : l’agent ne peut jamais faire plus que ce que vous avez le droit de faire vous-même. Si vous n’avez pas accès à un espace de travail, l’agent non plus. Toutes les actions sont enregistrées dans les journaux d’audit Fabric avec votre identité.

Ce que ça change concrètement

Avant le MCP Fabric, administrer une plateforme multi-espaces de travail impliquait de jongler entre l’interface Fabric, les API REST, et parfois des scripts d’automatisation. Chaque action nécessitait de naviguer entre plusieurs écrans, de connaître les bons paramètres, et d’exécuter les opérations une par une.

Avec le MCP, ces mêmes opérations s’enchaînent en langage naturel depuis VS Code. L’agent comprend le contexte, exécute les actions dans le bon ordre, et remonte les erreurs de façon lisible. Pour les équipes qui gèrent des environnements Fabric complexes (plusieurs espaces de travail, plusieurs couches de données, plusieurs profils d’accès) c’est une réduction significative de la charge opérationnelle.

Les tâches répétitives d’administration, de configuration et de documentation, qui représentaient une charge non négligeable, deviennent pilotables par un agent, sans lui déléguer les décisions d’architecture.

Retour d’expérience, ce qu’on a testé

Le projet

Pour tester le MCP Fabric dans un contexte réel, on s’est appuyé sur un projet existant : construire un modèle sémantique exploitable par un assistant « Talk with your data » à partir de données ingérées dans un lakehouse. Un cas d’usage concret, avec de vraies tables, de vraies relations, et de vraies contraintes.

Ce qu’on a réussi à faire faire à l’agent

Une fois connecté, le MCP Fabric s’est montré capable de prendre en charge des tâches qu’on aurait normalement réalisées manuellement via l’interface Fabric :

• Explorer l’espace de travail, lister les objets disponibles (lakehouses, notebooks, pipelines)
• Exécuter un notebook de chargement de données et suivre son statut jusqu’à la fin
• Explorer les tables du lakehouse via des requêtes SQL directement depuis l’agent
• Créer un modèle sémantique complet de 26 tables en schéma en étoile, avec ses relations
• Corriger itérativement le modèle : ajout de colonnes manquantes sur les tables de faits, correction de types de données sur plusieurs colonnes

Ce qui frappe, c’est la fluidité du workflow : des opérations qui auraient nécessité plusieurs onglets et une connaissance fine des API s’enchaînent en langage naturel, sans friction.

Installation, un comportement à anticiper

Le serveur MCP Fabric se télécharge et s’installe automatiquement au premier lancement. C’est pratique, mais ça a un effet de bord : ce téléchargement initial prend parfois plus de temps que le délai autorisé par le client MCP, ce qui provoque un échec à la première connexion. Ce n’est pas un blocage définitif, il suffit de relancer une fois l’installation terminée. On a rencontré ce comportement à trois reprises entre mai et juin, à chaque nouvelle version du serveur.

À noter également : certains outils SQL du serveur nécessitent une dépendance supplémentaire qui n’est pas installée par défaut. Sans elle, ces outils restent désactivés. Cela n’a pas bloqué notre travail, mais c’est à anticiper si vous avez besoin de ces fonctionnalités. Votre agent IA vous indiquera exactement ce dont il a besoin pour avancer et comment l’installer.

Difficultés rencontrées en cours d’utilisation

Une fois connecté, on a rencontré quelques frictions concrètes :

• Explorer les tables du lakehouse : l’outil list_lakehouse_files du MCP ne remonte pas les tables Delta nativement, il liste les fichiers du système, pas les tables enregistrées. Contournement : créer une session Spark et exécuter SHOW TABLES directement sur le lakehouse pour obtenir la liste des tables et inspecter leurs schémas.
• Encodage des fichiers de définition (BOM UTF-8) : lors des appels à update_semantic_model_definition, deux échecs consécutifs avec l’erreur VALIDATION_ERROR: Unexpected UTF-8 BOM. L’encodage [System.Text.Encoding]::UTF8 de PowerShell insère silencieusement un BOM en début de fichier JSON. Résolu en forçant New-Object System.Text.UTF8Encoding($false) — le paramètre $false supprime explicitement le BOM.
• Sessions Livy instables : les sessions Spark créées via Livy tombaient régulièrement en état déconnecté, renvoyant des erreurs API 400 BadRequest dès qu’on tentait de les réutiliser trop tard. Comportement connu dans Fabric : il faut systématiquement vérifier l’état de la session avant chaque requête, et en recréer une neuve si elle a expiré.
• Manipulation de JSON via PowerShell : les opérations de lecture, modification et réécriture des définitions de modèle sémantique en base64 se sont révélées peu fiables avec PowerShell, problèmes d’encodage et de gestion des caractères spéciaux. Bascule définitive vers Node.js (node -e) pour ces opérations, avec de meilleurs résultats et un comportement plus prévisible.
• Authentification Azure CLI transitoire : une erreur Failed to acquire authentication token: Failed to invoke the Azure CLI est apparue une fois en cours de session. Un simple retry immédiat a suffi à la résoudre — probablement un timeout réseau ponctuel.

En résumé

Le MCP Fabric tient ses promesses : piloter une plateforme Fabric en langage naturel, enchaîner des opérations complexes sans passer par l’interface, c’est possible et ça fonctionne. Les frictions rencontrées sont réelles mais toutes surmontables, elles relèvent davantage de comportements à connaître que de limitations bloquantes.

Limites et points de vigilance

Préversion instable

Le serveur est encore en cours de développement. Toute intégration construite aujourd’hui devra potentiellement être adaptée avant la version définitive. À ne pas utiliser en production critique sans filet de sécurité.

Activation obligatoire par les administrateurs

Le Fabric MCP Server doit être activé au niveau du tenant Fabric par un administrateur avant tout usage. Ce n’est pas activé par défaut, une démarche auprès des admins de l’organisation est nécessaire.

Périmètre encore incomplet

Le serveur ne couvre pas encore l’intégralité des actions possibles dans Fabric. Certaines opérations avancées nécessitent encore de passer par d’autres moyens.

Revue de sécurité recommandée

Le MCP est une technologie récente. Microsoft recommande une revue de sécurité avant tout déploiement en contexte professionnel, couvrant le serveur MCP, le client IA utilisé, et le fournisseur de modèle associé. Les actions étant tracées dans les journaux Fabric avec l’identité de l’utilisateur, définir clairement qui peut utiliser ces outils est indispensable.

Conclusion

Le Fabric MCP Server ne remplace pas l’interface Fabric, il la contourne pour les tâches où l’interface est un frein : opérations répétitives, enchaînements d’actions, administration programmatique. Pour un développeur ou un administrateur Fabric qui travaille déjà dans VS Code, c’est une évolution naturelle : l’agent devient un assistant d’administration à part entière, capable d’agir là où on lui demande d’agir.

La préversion impose la prudence sur les usages critiques. Mais le potentiel est là, et notre prochain article explorera la même logique appliquée aux modèles sémantiques Power BI, avec le MCP Power BI.