Aujourd’hui, l’IA générative n’est plus réservée aux géants de la tech : elle devient un levier concret de performance pour toutes les organisations déjà engagées sur la donnée (BI, data platform, KPI). Chez ActinVision, les équipes basées à Paris, Strasbourg, Lyon et Montréal accompagnent les entreprises pour transformer leur plateforme data existante en agents IA opérationnels, en combinant Microsoft Fabric et Microsoft Foundry dans des scénarios métier concrets.
La plupart des entreprises collectent déjà de gros volumes de données, mais peinent encore à les exploiter au quotidien : les utilisateurs dépendent d’équipes data, d’outils complexes ou de rapports figés. Les data agents Fabric et Foundry changent la donne en permettant de parler aux données en langage naturel, tout en respectant la sécurité, la gouvernance et les contraintes budgétaires.
-
2. Qu’est-ce qu’un data agent Foundry et pourquoi le combiner avec Fabric ?
-
dbt + Microsoft Fabric : un investissement stratégique dans le modern data stack
-
Et maintenant ? Trois axes d’action concrets avec ActinVision
1. Qu’est-ce qu’un data agent Microsoft Fabric ?
Un data agent Fabric est un agent conversationnel directement connecté à vos données dans Microsoft Fabric (Lakehouse, Warehouse, bases KQL, modèles sémantiques Power BI). Il permet aux utilisateurs métiers de poser des questions en langage naturel et d’obtenir des réponses basées sur les données, sans écrire de requêtes techniques.
Concrètement, le data agent Fabric s’appuie sur le modèle de sécurité déjà en place (workspaces, rôles RLS/OLS, permissions sur les tables et les modèles) pour ne travailler qu’avec les données auxquelles l’utilisateur est autorisé à accéder. Il lit ensuite le schéma des objets et leur contexte – tables, colonnes, mesures, relations – afin de comprendre comment la donnée est structurée et reliée. À partir de la question posée en langage naturel, il génère automatiquement la requête la plus adaptée (SQL, KQL ou DAX), l’exécute sur les bonnes sources, puis reformule le résultat dans une réponse claire et compréhensible pour l’utilisateur.
La fiabilité de l’agent repose en grande partie sur la couche sémantique que vous lui fournissez. Un data agent ne devine pas le sens exact de vos données. Pour répondre de façon fiable, il s’appuie sur :
- Le contexte : descriptions des tables, des colonnes, des indicateurs, exemples de questions.
- Les instructions : règles métier, logiques de calcul, conventions internes, contraintes d’interprétation.
- Les synonymes : vocabulaire réellement utilisé par les équipes (ex. CA, revenu, sales, marge, MRR).
C’est cette couche sémantique qui fait le lien entre le langage naturel des utilisateurs et la structure technique de votre plateforme data. Sans elle, l’agent peut répondre… mais avec des approximations. Avec elle, il devient un véritable expert métier, capable de restituer une information pertinente, contextualisée et immédiatement exploitable. Côté consommation, le data agent Fabric peut être utilisé :
- Directement dans l’interface Microsoft Fabric, pour les profils data et analystes.
- À travers les expériences Copilot intégrées à Fabric, pour ajouter une couche d’assistance intelligente sur les rapports, modèles et notebooks.
- Publié dans Microsoft 365 Copilot pour être accessible dans Teams, Outlook, Word, Excel, etc., et permettre aux utilisateurs métiers d’interagir avec les données sans quitter leur environnement de travail.
En résumé, le data agent Fabric est l’expert conversationnel de vos données Microsoft Fabric.
2. Qu’est-ce qu’un data agent Foundry et pourquoi le combiner avec Fabric ?
Microsoft Foundry (Azure AI Foundry) est une plateforme end-to-end pour concevoir, tester, déployer et superviser des applications et agents IA à grande échelle. Un data agent Foundry est un agent hébergé dans cette plateforme, capable d’orchestrer plusieurs sources d’information et plusieurs outils IA dans un même flux de conversation.
Avec Foundry, il est possible de concevoir plusieurs types d’agents complémentaires : certains vont interroger directement un data agent Fabric pour exploiter des données structurées comme les ventes, les stocks ou les indicateurs financiers et de production, d’autres vont se concentrer sur l’analyse de documents non structurés (PDF, factures, contrats, comptes rendus, documentations), tandis qu’un troisième type va plutôt récupérer de l’information sur le web ou via des API métier (CRM, ERP, outils de planification, etc.). L’intérêt majeur de Foundry est de pouvoir orchestrer ces différents agents au sein d’un même scénario conversationnel cohérent, de sorte que l’utilisateur n’ait qu’un seul point d’entrée alors que l’IA, elle, mobilise en arrière‑plan toutes les bonnes sources d’information.
Exemple de cas d’usage
On peut par exemple imaginer un responsable commercial qui discute avec un agent Foundry dans Microsoft Teams :
- L’agent interroge le data agent Fabric pour récupérer les ventes par client et par période.
- Il interroge un CRM pour vérifier les objectifs, le pipe commercial et le statut des opportunités.
- Il consulte des documents (compte-rendus de rendez-vous, contrats, factures) via un agent « file search ».
- Il propose une liste de comptes à prioriser et génère un message type personnalisé pour chaque client.
Dans ce scénario, le data agent Microsoft Fabric reste le cœur analytique sur la donnée structurée, tandis que Foundry orchestre l’ensemble et connecte l’IA à d’autres briques de votre SI.
3. Tarification : Fabric, Foundry et licences utilisateurs
La tarification d’un projet d’agents IA repose d’abord sur les composants techniques : d’un côté, la plateforme Microsoft Fabric avec ses capacités dédiées (qui dimensionnent les ressources disponibles pour les data agents), de l’autre la plateforme Foundry (Azure AI Foundry), facturée principalement à la consommation des modèles et des outils utilisés par les agents. Ces deux briques constituent le socle « infrastructure et services IA » sur lequel vont tourner vos scénarios.
À cela s’ajoute une troisième dimension : le canal d’accès choisi pour les utilisateurs finaux, qu’il s’agisse d’une utilisation directe dans Fabric, d’une application ou d’un portail Foundry, ou encore d’une intégration dans Microsoft 365 Copilot (Teams, Outlook, Word, etc.). Il est donc essentiel de bien distinguer les coûts de plateforme (capacités et consommation Azure/Fabric/Foundry) des licences utilisateurs, qui dépendent des profils (Fabric/Power BI, Microsoft 365, Copilot) et viennent compléter le budget global du projet.
a) Côté développeurs : capacités Fabric et consommation Foundry
Fabric
Pour créer et exécuter un data agent Fabric, une capacité Fabric de type F2 au minimum est nécessaire. Cette capacité constitue un point d’entrée adapté à un POC ou à des premiers usages limités. Des capacités plus élevées (F4, F8, F16…) permettent ensuite d’absorber davantage d’utilisateurs et de requêtes. La capacité est mutualisée entre tous les workloads Fabric (engineering, data science, real-time, Power BI, etc.). Les data agents consomment simplement une partie de cette capacité (CPU, mémoire, appels aux modèles IA), comme n’importe quel autre workload.
Foundry
Dans Foundry, les agents fonctionnent en mode consommation via un abonnement Azure. Créer ou configurer un agent Foundry n’a pas de coût fixe en soi : les coûts proviennent de :
- La consommation des modèles (Azure OpenAI, modèles du catalogue Foundry) : tokens d’entrée/sortie facturés au million de tokens, selon le modèle.
- L’utilisation des outils (par exemple file search, web search, connecteurs).
- Le stockage et les ressources associées (index, logs, mémoire, fichiers).
Microsoft propose des mécanismes d’engagement (Agent Commit Units) qui permettent de réserver un volume d’usage pour les agents et d’obtenir de meilleurs tarifs unitaires. Plus l’engagement est élevé, plus le coût par appel diminue.
b) Côté utilisateurs finaux : quelles licences ?
La licence dépend avant tout de l’interface par laquelle l’utilisateur va accéder à l’agent IA : directement dans Fabric, via une application ou un portail construit sur Foundry, ou encore au travers de Microsoft 365 Copilot dans Teams, Outlook, Word, etc. Chaque option s’appuie sur des licences différentes (Fabric/Power BI, Microsoft 365, Copilot), ce qui influe directement sur le coût par utilisateur.
En pratique, le modèle économique d’un projet d’agents IA se construit donc comme un équilibre entre trois paramètres : le dimensionnement des capacités Fabric nécessaires pour absorber la charge, le volume de consommation dans Foundry lié aux appels de modèles et d’outils, et le choix du ou des canaux d’accès avec les licences Microsoft 365 et Copilot associées. C’est ce triptyque qui permet d’ajuster finement le budget en fonction des usages réels et de la population cible.
4. Sécurité et gouvernance : Fabric et Foundry
La sécurité est souvent la première question abordée dans les projets d’IA générative. Bonne nouvelle : les data agents Fabric et Foundry ne créent pas de brèches, ils réutilisent la sécurité et la gouvernance déjà en place dans vos environnements Microsoft.
a) Côté Fabric
Le data agent Fabric s’exécute avec l’identité de l’utilisateur qui lui parle. Concrètement :
- L’utilisateur se connecte avec son compte Entra ID (Azure AD).
- Le data agent utilise cette même identité pour accéder aux workspaces, tables, datasets, modèles sémantiques.
- Il applique les mêmes mécanismes que le reste de Fabric : permissions sur les workspaces, rôles sur les modèles, RLS (Row-Level Security) et OLS (Object-Level Security).
Si un collaborateur n’a pas accès à certaines tables, colonnes ou lignes, l’agent ne pourra ni les interroger ni les afficher dans la conversation. La gouvernance reste donc maîtrisée dans Fabric.
b) Côté Foundry
Dans Foundry, l’agent peut être configuré pour :
- S’exécuter au nom de l’utilisateur final, en propageant son identité vers les outils (Fabric, API protégées, etc.).
- Utiliser un compte applicatif/technique avec des permissions limitées à un périmètre précis.
Pour des cas d’usage sensibles (par exemple des factures clients contenant des Personally Identifiable Information PII ou des données bancaires), il est possible d’ajouter des briques Azure AI pour détecter et masquer automatiquement les informations sensibles avant qu’elles ne soient utilisées par l’agent.
Une couche de gouvernance et de classification avec Microsoft Purview peut également être ajoutée pour taguer les données sensibles, suivre les accès et surveiller l’activité des agents. Les agents IA ne cassent pas la sécurité existante : ils se contentent de la réutiliser.
5. Comment démarrer : de la preuve de valeur à l’industrialisation
La réussite d’un projet d’agents IA ne se joue pas uniquement sur la technologie, mais sur l’équilibre entre architecture, coûts et usages métier. Côté back-end, il s’agit de dimensionner correctement vos capacités Fabric et votre consommation Foundry. Côté utilisateurs, le choix du canal (Fabric, Foundry, Copilot) conditionne les licences nécessaires et le modèle économique.
Pour démarrer, l’approche recommandée est d’avancer par étapes :
Commencer petit
Commencer petit, c’est d’abord lancer un premier data agent Fabric sur un périmètre de données bien cadré, par exemple les ventes France, la production ou la relation client pour une équipe commerciale ou opérationnelle basée à Paris, Strasbourg ou Lyon. Cet agent peut ensuite être orchestré par un agent Foundry, qui vient s’appuyer sur ce socle Microsoft Fabric et éventuellement le compléter avec une autre source comme des documents métiers, des données web ou des API CRM pour couvrir un premier cas d’usage IA très concret.
Cadrer 1 ou 2 parcours métier prioritaires
L’étape suivante consiste à cadrer un ou deux parcours métier prioritaires, par exemple répondre aux questions des équipes commerciales sur la performance clients, piloter la production industrielle, suivre la consommation énergétique ou analyser la rentabilité par offre et par région sur le marché français ou européen. Cela implique de définir clairement les KPIs, les questions types, les sources de données et les règles métier qui devront être intégrées dans la couche sémantique des data agents, afin d’assurer des réponses fiables et réellement actionnables.
Mesurer usage, coûts et valeur créée
Une fois les premiers scénarios en place, il devient essentiel de mesurer l’usage, les coûts et la valeur créée, en suivant le nombre d’utilisateurs actifs, le volume de conversations, le temps gagné et la rapidité des décisions prises par les équipes métiers. En parallèle, l’analyse des coûts de capacité Fabric et de consommation Foundry associés à ces usages permet d’ajuster le dimensionnement technique et le modèle économique, en particulier pour des déploiements multi-sites ou multi-pays (France, Europe, Canada).
Étendre progressivement
Sur cette base, l’organisation peut ensuite étendre progressivement le dispositif d’agents IA opérationnels en ajoutant de nouveaux cas d’usage pour le marketing, la finance, la supply-chain ou le service client, toujours ancrés dans la réalité des besoins terrain. Il devient alors possible de connecter de nouvelles sources comme d’autres bases de données, des CRM, des ERP ou une GED, et d’enrichir les agents avec des outils supplémentaires de recherche de documents, d’actions sur des API métier ou de génération de contenu, pour faire évoluer la plateforme Microsoft Fabric et Foundry en véritable colonne vertébrale IA au service des équipes
C’est en avançant ainsi, par paliers, que les organisations peuvent faire des agents IA Fabric et Foundry un véritable levier d’efficacité pour les équipes, sans perdre le contrôle sur le budget ni sur la sécurité.
ActinVision accompagne les organisations en France et au Canada dans la mise en place d’agents IA opérationnels avec Microsoft Fabric et Microsoft Foundry : cadrage des cas d’usage, architecture, gouvernance, mise en œuvre et accompagnement au changement.
Si vous envisagez de déployer des solutions IA sur votre plateforme data, ou de faire évoluer vos usages Microsoft Fabric vers des agents IA, contactez nos équipes pour échanger sur votre contexte, vos enjeux et vos premiers cas d’usage.