Fabric Data Agent et Fabric IQ : Microsoft Fabric à l'ère agentique

En résumé : avec le Fabric Data Agent et Fabric IQ, Microsoft Fabric ne se contente plus de restituer des indicateurs : des agents IA interrogent les données en langage naturel, en s'appuyant sur une couche de contexte métier (ontologie, graphe, règles, actions). Les fondations de la BI ne disparaissent pas pour autant : le modèle sémantique reste la référence des métriques. Un Data Agent fiable repose sur un contexte métier explicite, un bon choix de la source interrogée et une gouvernance intégrée dès la conception.

La tendance est claire chez Microsoft et notamment avec Fabric : l'IA générative et les agents IA prennent de plus en plus de place. On n'est plus dans l'effet de mode mais bien dans une réalité qui reflète l'intérêt grandissant des entreprises pour l'intelligence artificielle et ses applications concrètes.

Au-delà du reporting traditionnel : répondre aux besoins ad hoc

Côté Fabric et Power BI, les opérationnels ont toujours voulu aller plus loin dans l'exploitation de la donnée. Si les rapports interactifs et paginés restent indispensables pour diffuser une information fiable, actualisée et gouvernée, ils ne répondent pas à tous les besoins.

Qu'en est-il des analyses ponctuelles, réalisées à la dernière minute avant une réunion ? Des données historiques archivées, rarement accessibles dans les outils de reporting, mais qui peuvent s'avérer précieuses pour répondre à une question précise ou satisfaire une simple curiosité ? Ou encore de cet attribut ou de cette mesure que l'on souhaiterait ajouter à un rapport mais dont l'intégration par l'équipe IT peut prendre plusieurs jours voire plusieurs semaines ?

L'enjeu est donc de permettre aux utilisateurs d'explorer les données en toute autonomie, de tester leurs idées et de valider la pertinence de leurs analyses avant d'envisager leur intégration dans la chaîne décisionnelle.

Les limites du self-service BI

Certains ont tenté de répondre à ces besoins en misant sur le self-service BI avec des résultats et des retours terrain parfois contrastés. L'idée est séduisante : mettre à disposition des métiers une capacité dédiée, une sorte de zone de liberté où ils peuvent créer et faire évoluer leurs rapports sans dépendre systématiquement de l'IT.

Mais cette autonomie a ses limites. Que se passe-t-il lorsque les usages se multiplient, que les bonnes pratiques ne sont pas toujours maîtrisées et que les ressources disponibles atteignent leurs limites ? Le throttling (ralentissements, limitations, voire blocages temporaires) peut alors transformer cette promesse d'autonomie en source de frustration pour les utilisateurs et de sollicitations supplémentaires pour les équipes IT…

Au final, le self-service BI censé fluidifier l'accès à la donnée risque de produire l'effet inverse : davantage de contraintes, plus de support et une expérience dégradée pour tous.

De la BI traditionnelle à l'IA agentique

Pour répondre à ces enjeux et améliorer concrètement l'expérience des utilisateurs, Microsoft (comme d'autres acteurs du marché) mise de plus en plus sur l'IA et plus particulièrement sur les agents. Dans Fabric, les Data Agents s'inscrivent pleinement dans cette évolution. Avec IQ, Microsoft ajoute également une couche de contexte destinée à mieux faire comprendre aux agents la signification des données et les règles métier qui les entourent.

On dépasse ainsi les premières approches du Chat with Your Data dont le composant Q&A de Power BI était l'un des précurseurs. L'enjeu n'est plus simplement de poser une question en langage naturel et d'obtenir une réponse mais de fournir aux agents le contexte nécessaire pour interpréter les données, mobiliser les bonnes sources et produire des résultats pertinents.

Les MCP Servers, Copilot et les agents ouvrent ainsi la voie à de nouveaux usages où la contextualisation, l'orchestration et la gouvernance deviennent essentielles. L'objectif : permettre aux utilisateurs d'aller plus loin dans l'exploitation de leurs données tout en conservant un cadre maîtrisé, sécurisé et gouvernable de bout en bout.

Microsoft Fabric en 2026 : une architecture enrichie par le contexte métier

Et parce qu'un schéma vaut mieux qu'un long discours, voici comment Microsoft envisage l'exploitation de la donnée en 2026 :

Les couches de Microsoft Fabric selon Microsoft : OneLake, Power BI et Fabric IQ (source : Microsoft).

OneLake : le socle unifié des données

OneLake reste le socle de Microsoft Fabric : une couche de stockage unifiée qui centralise les données de l'entreprise quelles que soient leur origine et leur nature (structurées, semi-structurées ou non structurées). À l'image d'un OneDrive d'entreprise dédié à la donnée, il permet de rassembler ce patrimoine au même endroit pour mieux l'exploiter. Pour le détail de OneLake et des autres briques de la plateforme, voir notre page Microsoft Fabric.

Les modèles sémantiques : la fondation analytique

Vient ensuite la couche décisionnelle, ou BI analytique, qui structure les données autour de métriques fiables, de dimensions partagées et de règles d'accès cohérentes exposées au travers des Semantic Models de Power BI. Cette couche reste indispensable et répond à la grande majorité des besoins de reporting et d'analyse. Mais face à des questions ponctuelles, des explorations ad hoc ou des besoins qui sortent du cadre prévu, elle peut aussi montrer certaines limites.

Fabric IQ : donner du sens aux données

Une nouvelle couche vient désormais s'intercaler entre les utilisateurs (et/ou agents) et les données analytiques : IQ. Microsoft la présente comme une couche de contexte métier, baptisée Operational Intelligence, qui regroupe plusieurs concepts clés : Ontologie, Graphe, Règles, Objectifs et Actions.

L'idée est d'apporter aux agents ce qui leur manque souvent pour exploiter efficacement les données : une compréhension du métier, de ses relations, de ses contraintes et de ses objectifs. Cette couche vient donc compléter les modèles sémantiques et non les remplacer, en donnant davantage de sens aux données sur lesquelles les agents s'appuient pour raisonner.

Modèle sémantique, ontologie, graphe et actions : comprendre les concepts clés

Mais concrètement, à quoi correspondent ces différents concepts ? Quel est leur rôle et comment s'articulent-ils dans Microsoft Fabric ? Pour simplifier, chaque composant répond à une question bien précise :

• Modèle sémantique : qu'est-ce qui a changé ? Que nous disent les indicateurs ?
• Ontologie : que signifient ces données d'un point de vue métier ?
• Graphe : quelles entités sont liées entre elles, et quelles dépendances ou quels impacts en découlent ?
• Agent : que faut-il analyser ou examiner en priorité ?
• Action gouvernée : quelle action peut être déclenchée, dans quelles conditions et avec quelle approbation ?

En résumé, le modèle sémantique fournit les indicateurs, l'ontologie leur donne un sens métier, le graphe met en évidence les relations, l'agent raisonne à partir de ce contexte et l'action gouvernée encadre ce qu'il est autorisé à faire.

Les différents types d'agents dans l'écosystème Microsoft

Si l'on se concentre maintenant sur les agents dans l'écosystème Microsoft Fabric, trois grandes catégories se distinguent, chacune répondant à un besoin différent :

• Data Agent : c'est un analyste virtuel spécialisé dans un domaine métier. Il répond aux questions en langage naturel en s'appuyant sur des sources de données gouvernées, comme les données Fabric, les modèles sémantiques, l'ontologie ou les Data Products. Son objectif est de permettre aux utilisateurs d'explorer, de comparer et de comprendre leurs données sans nécessairement maîtriser les outils analytiques sous-jacents.
• Operations Agent : il s'intéresse davantage à ce qui se passe sur le terrain et à l'état des opérations. Il exploite les informations opérationnelles pour surveiller une situation, détecter des anomalies ou des risques puis recommander des actions adaptées. L'enjeu est de passer du constat à l'anticipation et à l'aide à la décision dans un cadre maîtrisé.
• Custom Agent : lorsqu'il faut aller au-delà de l'analyse ou de la surveillance, un agent personnalisé peut être conçu avec Copilot Studio ou Microsoft Foundry. Il s'intègre alors dans un processus métier, mobilise différents outils et orchestre les étapes nécessaires pour produire un résultat concret au sein d'une application. Voir notre offre agents IA avec Copilot Studio.

Ces approches sont complémentaires et peuvent se combiner selon les besoins de l'entreprise.

Focus : comment fonctionne un Fabric Data Agent ?

La valeur du Fabric Data Agent repose en grande partie sur son fonctionnement interne, autrement dit son workflow d'exécution ou runtime. Derrière une simple question en langage naturel se cache toute une chaîne d'étapes qui permet d'interpréter la demande, de sélectionner les bonnes données et de construire une réponse pertinente dans le respect des autorisations.

Le Data Agent entre les points d'entrée des utilisateurs et les sources de données de Fabric (source : Microsoft).

1. Une question en langage naturel

Tout commence par une question posée par l'utilisateur. Celle-ci peut provenir de différents points d'entrée : Copilot dans Power BI, Microsoft 365 Copilot, Copilot Studio, Microsoft Foundry, un client MCP, un SDK ou encore une API.

2. Un runtime qui orchestre l'exécution

Le runtime prend ensuite le relais pour interpréter la demande et orchestrer son traitement. L'identité de l'appelant est vérifiée via Microsoft Entra ID afin que les contrôles d'accès et les requêtes soient exécutés avec les privilèges appropriés. Ce processus implique plusieurs étapes :

• Comprendre l'intention de l'utilisateur et identifier les informations recherchées.
• Vérifier les autorisations, notamment les droits d'accès aux données et les restrictions éventuelles liées à la RLS (Row-Level Security) ou à l'OLS (Object-Level Security).
• Sélectionner la source appropriée parmi les sources disponibles : Lakehouse, Warehouse, modèle sémantique, Eventhouse, Ontology ou Graph.
• Récupérer le schéma et les instructions nécessaires pour comprendre la structure des données et les règles à respecter.
• Générer une requête dans le langage adapté à la source ciblée : SQL, DAX, KQL ou GQL. Cette traduction du langage naturel vers un langage de requête est communément désignée par les termes NL2SQL, NL2DAX, NL2KQL ou NL2GQL.
• Exécuter la requête en lecture dans le respect des permissions applicables.
• Restituer une réponse contextualisée accompagnée des traces d'exécution disponibles pour faciliter son analyse et son débogage.

3. La qualité du résultat dépend aussi du contexte

Un point de vigilance mérite une attention particulière : une mauvaise sélection de la source de données peut produire une réponse parfaitement plausible et bien formulée mais incorrecte dans son contexte métier.

La qualité des résultats ne dépend donc pas uniquement du modèle d'IA. Elle repose également sur la qualité des descriptions de sources, la pertinence des schémas exposés, les exemples de questions fournis et la configuration des différentes étapes d'exécution (run steps).

Ces éléments doivent être testés, documentés et versionnés avec la même rigueur que du code. C'est une condition essentielle pour obtenir un Data Agent fiable, reproductible et maintenable dans le temps.

Comment réussir un projet Fabric Data Agent ?

Le secret d'un Fabric Data Agent efficace ne réside pas uniquement dans le choix du modèle d'IA mais surtout dans la démarche pragmatique adoptée pour le concevoir, le tester, le déployer et le maintenir.

1. Cadrer le besoin métier

• Définir les questions auxquelles l'agent doit répondre, les résultats attendus et les cas hors périmètre.
• Partir d'un cas d'usage métier précis plutôt que de chercher à construire un agent universel.

2. Préparer les sources de données

• Identifier les sources de référence (authoritative sources).
• Vérifier la fiabilité des modèles de données, des clés, des descriptions, de la fraîcheur des données et des autorisations d'accès.

3. Enrichir le contexte métier

• Stabiliser les indicateurs clés de performance (KPI) et les clés d'identification des entités.
• Formaliser les entités métier, leurs relations, les règles de gestion et le vocabulaire métier.
• Mobiliser une ontologie ou un graphe de connaissances lorsque le raisonnement nécessite de parcourir plusieurs relations successives (multi-hop reasoning).

4. Configurer le Data Agent

• Sélectionner les sources de données adaptées au périmètre défini.
• Rédiger des descriptions précises pour orienter l'agent vers les bonnes données.
• Ajouter des exemples de questions et de requêtes attendues.
• Publier une version identifiée et maîtrisée de la configuration de l'agent.

5. Tester et valider les résultats

• Constituer un jeu de tests de référence (ground truth) comprenant des questions, les résultats attendus et les règles de validation.
• Vérifier la cohérence des KPI, le respect du contexte métier et des autorisations d'accès.
• Exécuter des tests de non-régression à chaque évolution des sources, des instructions ou de la configuration.

6. Étendre progressivement les capacités d'action

• Exposer uniquement les outils nécessaires au cas d'usage.
• Pour les opérations d'écriture et les actions sensibles, intégrer des outils et des workflows contrôlés via MCP, Microsoft Foundry ou d'autres composants adaptés.
• Mettre en place des mécanismes d'approbation lorsque le niveau de risque l'exige.

7. Déployer et superviser l'agent

• Versionner les instructions, les configurations et les éléments nécessaires à sa reproduction.
• Organiser la promotion entre les environnements de développement, de test et de production (Dev-Test-Prod). Voir à ce sujet notre tutoriel CI/CD Fabric avec GitHub.
• Suivre les diagnostics d'exécution, les coûts, les dérives de comportement et les évolutions des sources ou de l'ontologie.

Le principe directeur reste simple : commencer par un périmètre restreint, rendre les résultats mesurables et les comportements testables, puis élargir progressivement l'usage, domaine métier par domaine métier.

Un Data Agent reste avant tout un logiciel : il doit disposer d'un jeu de tests, d'un versionnement, d'un processus de déploiement maîtrisé et d'un propriétaire clairement identifié. L'IA ne dispense pas des bonnes pratiques d'ingénierie logicielle, elle les rend d'autant plus essentielles.

Conclusion : les agents prolongent la BI

Qu'on ne s'y trompe pas : l'arrivée des agents ne remet pas en cause les fondations de la BI, elle les prolonge.

• Le modèle sémantique reste la fondation analytique. Il garantit des métriques cohérentes et partagées. L'ontologie, le graphe et les règles métier viennent enrichir ce socle en apportant le contexte nécessaire au raisonnement de l'agent, tandis que les règles de gouvernance encadrent les actions qu'il peut déclencher.
• La pertinence d'une réponse dépend autant du choix de la source que de la requête exécutée. Une requête SQL, DAX, KQL ou GQL, même parfaitement construite, ne donnera pas un résultat fiable si elle interroge la mauvaise source. Le runtime doit donc déterminer où chercher avant de décider comment interroger les données.
• La gouvernance doit être intégrée dès la conception. Gestion des identités, permissions minimales, liste d'outils autorisés (allow-list), approbation humaine pour les actions sensibles, audit, tests et processus de promotion entre environnements sont autant de conditions nécessaires à un usage fiable et maîtrisé.

Un Data Agent fiable ne se résume donc pas à un LLM placé au-dessus d'un Lakehouse ou d'un modèle sémantique. Il repose sur un contexte métier explicite, une identité maîtrisée de bout en bout, un routage pertinent des requêtes, des outils gouvernés et une boucle de validation comparable à celle d'un logiciel.

Pour résumer cette architecture :

• OneLake et les Data Products mettent les données à disposition.
• Les modèles sémantiques portent les métriques et les définitions analytiques de référence.
• Fabric IQ enrichit les données avec le contexte et le sens métier.
• Le Fabric Data Agent interprète les questions et orchestre l'accès aux sources pertinentes.
• MCP et Microsoft Foundry permettent d'étendre les capacités des agents vers des outils et des processus, dans le respect des identités, des permissions et des politiques de gouvernance.

L'enjeu n'est donc pas simplement de faire parler les données mais de permettre aux agents de les comprendre dans leur contexte, de raisonner de manière fiable et d'agir dans un cadre maîtrisé.

Vous voulez mettre des agents IA au service de vos données Fabric ? Découvrez notre offre IA sur vos données ou parlez-nous de votre projet.