Créer un Microsoft Fabric Data Agent : tutoriel pas à pas

En résumé : ce tutoriel montre comment créer un Fabric Data Agent pas à pas, à partir d'une table de dépenses stockée dans un Lakehouse. Les Microsoft Fabric Data Agents apportent une interface conversationnelle à l'exploitation des données analytiques. L'objectif n'est pas de remplacer la plateforme analytique, mais de faciliter l'exploration de ses données. Leur réussite dépend du travail réalisé en amont : données préparées, modèle analytique cohérent, définitions métier explicites, tests de qualité et permissions correctement configurées.

Introduction

Les plateformes analytiques centralisent des volumes croissants de données, mais accéder à une information précise suppose souvent de connaître les tables, les relations, les indicateurs et les outils de requête. Pour répondre à une question métier, un utilisateur doit parfois solliciter un analyste, comprendre la structure du modèle ou attendre la création d’un rapport.

Les Microsoft Fabric Data Agents visent à réduire cette difficulté en permettant aux utilisateurs d’interroger les données en langage naturel. L’utilisateur formule une question métier, et l’agent interprète la demande, construit une requête adaptée à la source de données, l’exécute puis restitue les résultats sous une forme compréhensible. L’objectif n’est pas de remplacer la plateforme analytique, mais de faciliter l’exploration de ses données.

Pour comprendre leur intérêt, il faut examiner leur place dans l’architecture Fabric, le cheminement entre une question et son résultat, ainsi que les conditions de qualité, de sécurité et de gouvernance nécessaires à leur utilisation.

Qu’est-ce qu’un Microsoft Fabric Data Agent ?

Un Fabric Data Agent est un artefact de Microsoft Fabric qui permet de créer une expérience conversationnelle au-dessus de sources de données configurées. Les utilisateurs peuvent poser des questions sans rédiger eux-mêmes toutes les requêtes. L’agent interprète la demande, s’appuie sur le contexte et les instructions définis lors de sa configuration, puis utilise le mécanisme de requête adapté à la source.

Selon les sources sélectionnées, les requêtes peuvent notamment utiliser T-SQL pour des sources relationnelles, DAX pour un modèle sémantique Power BI ou KQL pour une base KQL. Les sources et capacités disponibles évoluent : leur statut doit être vérifié dans la documentation Microsoft avant le déploiement.

Le Data Agent se distingue d’un assistant généraliste et d’un outil d’administration de Fabric. Son rôle principal est l’interrogation analytique de sources autorisées. Il ne remplace ni les processus d’ingestion, ni les transformations, ni la conception des modèles, ni les contrôles métier.

Le Data Agent est une couche conversationnelle au-dessus de données existantes. Sa pertinence dépend du périmètre sélectionné, du contexte métier fourni et des autorisations effectives.

L’agent peut	L’agent ne doit pas être considéré comme
Interpréter des questions en langage naturel.	Un substitut à une définition métier claire.
Interroger des sources structurées autorisées.	Un outil d’écriture ou de modification des données.
Produire des requêtes SQL, DAX ou KQL en lecture seule.	Un moteur d’analyse prédictive ou de causalité avancée.
Résumer des résultats et montrer des éléments du chemin de requête.	Une garantie que chaque réponse générée est exacte sans validation.

Où se positionne-t-il dans une architecture Data ?

Dans une architecture Microsoft Fabric organisée selon le modèle Médaillon, les données passent généralement par plusieurs étapes :

• Bronze conserve les données issues des sources.
• Silver les nettoie et les harmonise.
• Gold expose des structures adaptées aux besoins analytiques.
• Un Warehouse ou un modèle sémantique Power BI peut ensuite fournir un cadre stable pour les indicateurs et les relations métier.

Le Data Agent intervient en complément de cette chaîne et se place au-dessus des actifs analytiques existants. Il ne remplace pas les pipelines ou les notebooks qui préparent les données : il permet aux utilisateurs d’interroger les sources retenues avec une formulation naturelle. Il est préférable de lui présenter des tables analytiques bien structurées ou un modèle sémantique dont les mesures sont définies, plutôt que de compter sur lui pour reconstituer des règles métier absentes. Le Data Agent facilite leur consultation, mais ne corrige pas automatiquement les problèmes de qualité, les doublons ou les définitions d’indicateurs contradictoires.

Quelle valeur ajoutée pour un projet Data ?

Faciliter le self-service analytique

Un Data Agent peut réduire la dépendance à une connaissance détaillée du SQL ou du DAX pour les questions exploratoires. Un utilisateur métier peut demander une comparaison, une répartition ou une tendance, à condition que les données et les mesures nécessaires soient accessibles et bien définies.

Accélérer l’exploration

Pour un analyste, l’agent peut aider à explorer rapidement un jeu de données et à identifier des pistes à approfondir. Les résultats doivent toutefois être confrontés aux requêtes de référence et aux règles métier avant d’être utilisés dans un reporting officiel.

Rendre les indicateurs plus accessibles

Lorsque l’agent s’appuie sur un modèle sémantique Power BI bien conçu, les utilisateurs peuvent interroger des mesures et des dimensions déjà définies. Cela rapproche les questions métier du langage analytique, sans demander à chaque utilisateur de connaître la structure physique des tables.

Ces bénéfices sont des objectifs possibles, et non des gains garantis. Ils doivent être évalués à partir de critères comme la pertinence des réponses, le temps nécessaire pour obtenir une analyse, le taux d’erreur et les retours des utilisateurs.

Fonctionnement

Le traitement peut être compris comme une succession d’étapes. Leur résultat dépend de la précision de la question, de la configuration de l’agent et du contenu disponible dans les sources.

• Interpréter la demande : identifier la mesure recherchée, la période, les dimensions d’analyse et les conditions éventuelles.
• Mobiliser le contexte : utiliser les sources sélectionnées, les schémas, les descriptions, les instructions et les exemples de requêtes.
• Générer une requête : produire une requête adaptée au type de source, par exemple T-SQL, DAX ou KQL.
• Exécuter la requête : interroger la source dans le cadre des permissions et des règles de sécurité applicables.
• Formuler la réponse : présenter les résultats de manière compréhensible et permettre à l’utilisateur de poursuivre l’exploration.

Exemple : comparer les coûts par site

Un responsable demande : « Quels sites présentent la plus forte hausse des coûts par rapport au trimestre précédent ? » Pour répondre correctement, l’agent doit identifier la mesure de coût, la date qui définit le trimestre, la dimension « site » et la méthode de comparaison. Si plusieurs dates sont disponibles ou si les coûts ne sont pas définis de manière uniforme, le résultat peut être ambigu même si la requête s’exécute sans erreur.

Cet exemple montre l’importance du contexte métier. Les définitions des indicateurs, les relations entre tables et les règles de calcul doivent être documentées et testées. L’agent peut simplifier la formulation de la requête, mais la validation reste nécessaire pour les décisions importantes.

Sources de données

Les Microsoft Fabric Data Agents prennent en charge plusieurs types de sources de données, permettant d’adapter leur utilisation aux besoins analytiques de l’entreprise.

• Lakehouse : permet d’interroger les tables sélectionnées. Les fichiers stockés dans le Lakehouse ne sont pas automatiquement accessibles comme des tables interrogeables.
• Warehouse : adapté aux données relationnelles structurées et aux requêtes SQL.
• Modèle sémantique Power BI : permet d’exploiter les mesures, les relations et les métadonnées du modèle à l’aide de requêtes DAX.
• Base de données KQL / Eventhouse : convient à l’analyse des événements, des données de télémétrie et des séries temporelles.
• Autres sources : des sources telles que les ontologies et Microsoft Graph peuvent également être intégrées, selon les fonctionnalités disponibles.

Un agent peut être configuré avec jusqu’à cinq sources de données. Il est donc recommandé de sélectionner des sources cohérentes avec le périmètre métier de l’agent, plutôt que de multiplier les connexions sans logique fonctionnelle commune. Il convient également de vérifier les possibilités d’interrogation et de mise en relation des données propres à chaque type de source, sans supposer que l’agent effectue automatiquement des jointures entre l’ensemble des sources connectées.

Le choix de la source doit être donc guidé par la question à résoudre. Pour des indicateurs métier partagés, un modèle sémantique Power BI peut être préférable lorsqu’il contient déjà les mesures et relations officielles. Pour des analyses relationnelles spécifiques, un Warehouse ou des tables de Lakehouse peuvent convenir. Pour des événements et des séries temporelles, une source KQL peut être plus pertinente.

Prérequis

La mise en œuvre d’un Microsoft Fabric Data Agent nécessite de réunir les conditions suivantes :

• Capacité : disposer d’une capacité Microsoft Fabric payante de niveau F2 ou supérieur, ou d’une capacité Power BI Premium par capacité de niveau P1 ou supérieur, avec Microsoft Fabric activé.
• Accès aux données : disposer d’un accès à Microsoft Fabric et des autorisations de lecture nécessaires sur les sources de données à interroger.
• Configuration du tenant : l’administrateur Fabric doit activer le paramètre autorisant l’utilisation de la fonctionnalité Fabric Data Agent, ainsi que les paramètres Cross-geo processing for AI et Cross-geo storing for AI, lorsque ceux-ci sont requis pour l’environnement. Ces paramètres se configurent dans le portail d’administration Fabric, dans la section Tenant settings. Leur activation doit respecter les exigences de sécurité, de résidence et de conformité des données de l’organisation.

Enfin, si vous prévoyez d’utiliser des modèles sémantiques Power BI comme sources de données, vérifiez que le paramètre XMLA Endpoints est activé.

Quel est le coût des Microsoft Fabric Data Agents ?

L’utilisation des Microsoft Fabric Data Agents nécessite soit une capacité Microsoft Fabric de niveau F2 ou supérieur, soit une capacité Power BI Premium par capacité de niveau P1 ou supérieur, avec Microsoft Fabric activé.

La fonctionnalité Data Agent ne génère pas de frais de licence supplémentaires. Le coût dépend donc de l’abonnement à la capacité Microsoft Fabric ou Power BI Premium dont dispose déjà l’organisation.

Chaque requête consomme des unités de capacité Fabric (Capacity Units – CUs). Cette consommation peut varier de 1 à 75 CUs par requête, selon sa complexité. Il est donc important de surveiller la consommation de capacité afin d’évaluer les coûts liés à l’utilisation des agents.

Sécurité, gouvernance et partage

Un Data Agent constitue un point d’accès supplémentaire aux données de l’organisation. Il doit donc être gouverné comme tout autre accès analytique. Les utilisateurs doivent disposer des permissions requises sur les sources interrogées, et les politiques de sécurité applicables à ces sources doivent rester en vigueur.

• Appliquer le principe du moindre privilège et limiter les sources au besoin métier.
• Vérifier les permissions propres à chaque type de source ; les exigences diffèrent selon qu’il s’agit d’un Lakehouse, d’un Warehouse ou d’un modèle sémantique Power BI.
• Tester les règles de sécurité au niveau des lignes et des colonnes lorsqu’elles sont utilisées.
• Prendre en compte les politiques de gouvernance et de protection des données, notamment celles de Microsoft Purview lorsqu’elles sont configurées.
• Définir qui peut interroger l’agent, consulter sa configuration, la modifier et publier une nouvelle version.

Les instructions en langage naturel améliorent le comportement de l’agent, mais ne remplacent pas les permissions et les contrôles techniques appliqués aux sources.

Un utilisateur qui peut ouvrir l’agent mais n’a pas les autorisations requises sur une source peut obtenir une erreur ou un résultat vide. Tester les scénarios avec des comptes représentatifs des différents profils métiers.

Limites et points de vigilance

• Lecture seule : L’agent est conçu pour interroger les données. Il ne crée pas, ne modifie pas et ne supprime pas les données, et ne doit pas être assimilé à un moteur d’exécution d’actions.
• Données non structurées : Les documents PDF, DOCX ou TXT ne sont pas pris en charge comme sources directes dans le périmètre décrit par la documentation consultée.
• Réponses limitées : Les réponses sont orientées vers l’exploration conversationnelle et peuvent être limitées ou résumées ; Microsoft indique notamment un plafond de 25 lignes et 25 colonnes dans les réponses décrites.
• Raisonnement avancé : Ne pas supposer que l’agent réalise des analyses prédictives, des analyses causales ou des jointures fédérées complexes entre sources.
• Variabilité des réponses : Un résultat plausible peut être incorrect si les métadonnées, les instructions ou la question sont imprécises. Une validation métier demeure nécessaire.
• Régions et capacité : La capacité, les paramètres du tenant et la région des espaces de travail peuvent conditionner l’utilisation. Vérifier les prérequis actuels avant le déploiement.

Mise en œuvre pas à pas : exemple simple d’un Fabric Data Agent

Pour illustrer la mise en œuvre d’un Microsoft Fabric Data Agent, prenons un exemple concret : la création d’un agent capable de répondre à des questions sur les dépenses d’une entreprise à partir d’une table stockée dans un Lakehouse Fabric.

L’objectif est de permettre aux utilisateurs d’interroger les données en langage naturel, par exemple pour connaître les dépenses d’un site, comparer les coûts entre deux périodes ou identifier les catégories de dépenses les plus importantes.

1. Vérifier les prérequis

Avant de commencer, vérifier les trois points suivants :

• L’environnement doit disposer d’une capacité Fabric payante compatible, de niveau F2 ou supérieur, ou d’une capacité Power BI Premium par capacité compatible, avec Fabric activé.
• Dans Microsoft Fabric, accéder à Paramètres → Portail d’administration → Paramètres du tenant, puis rechercher la section Copilot et service Azure OpenAI (Copilot and Azure OpenAI Service). Vérifier notamment :
  • l’autorisation d’utiliser Copilot et les fonctionnalités basées sur Azure OpenAI ;
  • les paramètres permettant de désigner les capacités Fabric autorisées à utiliser Copilot ;
  • les paramètres relatifs au traitement et au stockage inter géographiques des données pour l’IA, lorsqu’ils sont requis pour l’environnement.

Ces paramètres doivent être vérifiés avec l’administrateur Fabric si l’utilisateur ne dispose pas des droits d’administration nécessaires.

• S’assurer que :
  • la table contenant les données est accessible depuis une source prise en charge par Fabric Data Agent ;
  • l’utilisateur dispose des autorisations de lecture nécessaires sur cette source ;
  • les accès sont limités aux données utiles au scénario.

2. Préparer la source de données

Pour ce scénario, nous utilisons une seule table fictive, nommée couts, contenant les informations suivantes :

• Date : date de la dépense ;
• Site : site concerné ;
• Categorie : catégorie de dépense ;
• Montant : montant dépensé en euros ;
• Statut : état de validation de la dépense.

La table est chargée dans un Lakehouse Fabric.

3. Créer l’agent

Dans l’espace de travail Fabric, créer un nouvel élément de type Fabric Data Agent et lui donner un nom explicite, par exemple Agent Analyse des depenses.

4. Sélectionner la source de données

Dans l’espace de travail Microsoft Fabric, ouvrir l’élément Agent Analyse des depenses, puis accéder à la configuration des sources de données. Sélectionner Ajouter une source (Add data source) et choisir le Lakehouse contenant la table couts.

Un Fabric Data Agent peut prendre en charge jusqu’à 5 sources de données, selon les limites documentées. Pour notre scénario, une seule source suffit : le Lakehouse contenant les données de dépenses.

Cette approche permet de simplifier la configuration et de limiter le périmètre de l’agent aux données nécessaires à l’analyse. Vérifier que la source est accessible et que les autorisations de lecture requises sont en place avant de poursuivre.

5. Rédiger les instructions

Dans l’interface de Fabric Data Agent, accéder à la section Instructions, puis saisir les consignes qui définissent le comportement de l’agent et les règles métier à appliquer lors de l’interprétation des questions.

Définir des instructions simples pour encadrer les réponses de l’agent. Par exemple :

• Les montants sont exprimés en euros.
• Les analyses peuvent être réalisées par date, année, trimestre, site et catégorie de dépenses.
• Par défaut, seules les dépenses validées sont prises en compte.
• Le montant total des dépenses correspond à la somme de Montant_Cout_EUR
• Le budget total correspond à la somme de Budget_EUR.
• Par défaut, prendre uniquement en compte les lignes dont Statut_Ligne est égal à « Validée ».
• Ne pas additionner directement les quantités de Quantite lorsque les unités de Unite sont différentes, car elles ne sont pas comparables.
• Utiliser Site pour comparer les différents sites et Categorie pour analyser la répartition des dépenses.
• Si une question est ambiguë ou si les données sont insuffisantes, le signaler plutôt que d’inventer une réponse.

Ces instructions permettent de préciser les règles métier, d’harmoniser l’interprétation des questions et d’améliorer la cohérence des réponses fournies par l’agent.

6. Tester l’agent

Une fois les instructions enregistrées, tester l’agent en lui posant plusieurs questions en langage naturel afin de vérifier sa capacité à interpréter les demandes et à appliquer les règles métier définies.

Pour notre scénario d’analyse des coûts, on a utilisé ces exemples suivants :

• Dépenses totales : Quel est le montant total des dépenses validées ?
• Analyse par site : Quel site a enregistré le montant total de dépenses validées le plus élevé ?
• Analyse par catégorie : Quelle catégorie de dépenses représente le coût total le plus élevé ?

Les réponses fournies par l’agent doivent être considérées comme des résultats à vérifier, et non comme des résultats nécessairement exacts. En effet, l’agent peut mal interpréter une question, appliquer un filtre incorrect, effectuer un calcul erroné ou ne pas respecter certaines règles métier.

Il est donc essentiel de comparer ses réponses à des résultats de référence calculés obtenus directement à partir des données afin de vérifier leur exactitude.

7. Valider et partager l’agent

Une fois les tests réalisés, valider le comportement de l’agent en s’assurant que les réponses sont cohérentes avec les données sources et respectent les règles métier définies. Les éventuelles erreurs identifiées doivent être corrigées avant de mettre l’agent à disposition des utilisateurs.

Après validation, publier l’agent :

• Dans la barre d’outils de votre Data Agent, cliquez sur Publish (Publier).
• Dans la fenêtre de publication, renseignez une description, par exemple : Agent permettant d’analyser les dépenses par site, catégorie à partir des données disponibles dans le Lakehouse.
• Cliquez sur Publish pour publier la version validée.

L’agent peut ensuite être partagé avec les utilisateurs concernés, en prévoyant une mise à jour des instructions et de nouveaux tests lorsque la source de données évolue.

• Dans l’interface du Data Agent, cliquez sur Share (Partager).
• Dans la fenêtre d’accès, ajoutez le nom ou l’adresse e-mail de la personne concernée.
• Sélectionnez le niveau d’autorisation adapté :
  • Share : l’utilisateur peut également partager l’agent.
  • Edit and view details : l’utilisateur peut consulter et modifier la configuration.
  • View details : l’utilisateur peut consulter la configuration
• Cliquez sur Grant (Accorder).

Le destinataire doit également disposer des autorisations nécessaires sur les données sous-jacentes, notamment le Lakehouse. Le simple partage du lien ne garantit pas l’accès aux données.

Pour terminer, ouvrez le lien avec un compte utilisateur autorisé et testez une question simple. Vérifiez que l’agent répond correctement et que l’utilisateur dispose bien des droits nécessaires.

L’objectif est de mettre à disposition un agent utile et contrôlé, tout en gardant à l’esprit que ses réponses doivent être vérifiées pour les analyses importantes.

Conclusion

Les Microsoft Fabric Data Agents apportent une interface conversationnelle à l’exploitation des données analytiques. Leur intérêt est de faciliter l’accès à l’information et l’exploration des indicateurs, en s’appuyant sur des sources sélectionnées et des requêtes adaptées.

Leur réussite dépend du travail réalisé en amont : données préparées, modèle analytique cohérent, définitions métier explicites, tests de qualité et permissions correctement configurées. Pour un premier projet, le plus efficace consiste à choisir un cas d’usage limité, à valider un ensemble de questions représentatives et à mesurer la qualité des réponses avant d’élargir le périmètre.

Le Data Agent doit ainsi être envisagé comme un complément à l’ingénierie des données et à la Business Intelligence : il facilite l’interaction avec la plateforme, sans remplacer les fondations qui rendent les données fiables.