Les Data Agents dans Microsoft Fabric

Phare Data

0:03[musique] [musique] Bonjour et bienvenue sur Fardata, la chaîne qui éclaire vos données. Dans l'océan des données, voir clair change tout. Sur PH data, on décrypte les services de données d'analytique CDIA, le tout avec un ton accessible, des choix techniques assumés et une touche dermarin. Alors que vous soyez architecte, analyste, data ingénieur, product honur ou simplement curieux, fardata vous accompagne pour comprendre les enjeux réels, éclairer les compromis et prendre des décisions et parfois avec le cri des mouettes en bruit de fond. Si ce genre de contenu vous parle, n'hésitez pas à vous abonner. Alors aujourd'hui, cap sur l'épisode du Zour, j'ai le plaisir d'accueillir Akram et Éric pour aller plus loin dans l'Anytics moderne au travers des date agent dans Microsoft fabrique.

La BI Conversationnelle

0:59Bonjour à tous et bienvenue à Akram qui va coanimer cette session sur la BI et notamment la BI conversationnelle qui sera notre sujet du jour. Alors, si on fait un petit historique sur ce qu'a ces dernières années, on a commencé avec ce qu'on appelle des rapports statiques où on avait des listings souvent des listings papier qui présentaient de la donnée. Tiens, donc on pouvait avoir énormément de de feuilles de papier et de tableaux pour représenter la donnée, ce qui était probablement un travail assez fastidieux. Dans les années 2010 sont arrivés des outils euh comme tableau et évidemment Power BI qui ont permis de faire de l'interaction avec ces données et notamment de de filtrer les données euh pour aller rechercher directement l'information qui allait bien. Mais on reste toujours dans un Canva qui est celui qui a été fixé par l'IT à savoir queon a designé donc un rapport avec bien des des filtres, des champs et des visualisations. Avec l'arrivée des LLM, donc des modèles de langage euh IA, aujourd'hui, on est capable d'aller poser une question en langage naturel aux données et d'avoir une réponse. Donc c'est ce qu'on appelle la conversation BI. Donc cette conversation BI permet de poser des questions quel que soit en fait le métier, tout ça dans son propre vocabulaire, dans son propre langage. Si par exemple je suis dans le monde du retail et que je suis un directeur de magasin, je peux aller poser une question sur par exemple quelle est la liste des soldats les plus vendus dans tel ou tel magasin ou quel est le produit qui a la plus forte marge ou même la liste des clients qui sont les plus importants. Alors, quel que soit le profil ou le personnage de la personne en question, on a aujourd'hui un intérêt à utiliser la conversation BI. Typiquement, je suis dans le métier de la data, je suis un analyste de données. Je peux explorer rapidement donc des ensembles de données et faire des hypothèses sur ces données, donc des projections. Puisque je rappelle hein, la BI c'est effectivement comprendre la donnée pour pouvoir prendre des décisions. Ça aide aussi d'autres types de personnat. je vais pas développer comme tout ce qui est développeur BI pour prototyper effectivement euh des dashboards, on revient au dashboard, mais également euh bah des scénarios qu'on peut imaginer avec des utilisateurs métiers, évidemment des exécutifs qui eux sont intéressés par une valeur, une un capilla et qui veulent avoir accès directement à l'information plutôt que d'avoir à consulter des rapports. Voilà. Donc ça c'est l'utilisation de la conversation BI, mais ça cache quelque part euh beaucoup de choses. Ce qu'on voit aujourd'hui en c'est évidemment euh le chat. Je pose ma question dans une interface en langage naturel et je requète des données. Je requête ces données. Mais ces données, d'où viennent-elles ? Sont-elles de bonne qualité ? Comment je sais que j'ai accédé à la bonne donnée ? Et c'est ce qu'on appelle les challenges. créer un agent conversationnel sur mes données, c'est aussi surtout s'occuper du backend parce que si on regarde bien ce qui se passe quand on fait une requête de ce type là, évidemment, on a la question, ce qu'on appelle le prompt, on a au milieu le modèle de langage et puis on a le data model qui va nous permettre de répondre. Quand mon Llm va interroger le data model, il va devoir savoir quelle est la donnée euh la signification de la donnée euh pour pouvoir bah justement la la requêter. Et évidemment, il va générer une requête qui sera dans un langage qui est propre au data model. Ça peut être du SQL. On verra qu'il y a d'autres moyens et Akram va le montrer tout à l'heure d'aller requetter la donnée. Mais ce data model revit donc une importance significative. Si on va plus loin, en fait pour pouvoir débloquer le potentiel des LM avec nos données, il faut qu'on appelle de la clarté sémantique. Et c'est tout le débat aujourd'hui de l'utilisation de l'IA avec nos données, c'est que certains champs euh certaines tables ont des noms qui sont assez à abscon. Euh souvent on a fait une modélisation plutôt IT des choses et euh et pas spécifiquement très avec une signification métier. Donc c'est enrichir tout ce qui est modèle de données avec des métadonnées qui signifient quelque chose à la fois pour l'humain et pour l'agent qui va requêter ces données. Alors, pour pouvoir faire ça, on peut s'appuyer aussi sur tout ce qui est définition de ces données qu'on va retrouver dans un catalogue de données et donc on va essayer d'enrichir au maximum ce catalogue de données. Et puis évidemment, ben le modèle de données c'est une chose, mais il faut que les données elles-mêmes soient propres. Donc, on a l'habitude maintenant de travailler sur des architectures notamment des architectures médaillon. On va attaquer plutôt une zone gold dont on sait qu'on a raffiné la donnée pour pouvoir être utilisé. Ça suppose que on est dans cette zone gold des données propres. Donc les process de data engineering et bien fait leur travail pour bah se dire que on va aller rechercher une donnée qui a une valeur significative pour un métier. Donc on a aussi dans une plateforme qui doit offrir un catalogue de données de la clarté sémantique tous ces outils de transformation. On va pouvoir parler de organisation de données, on va même pouvoir parler d'ontologie, hein, dans les dans les solutions. Alors, si on regarde bien euh ce qu'on a fait chez Microsoft, c'est construire en fait une fondation pour l'IA et au départ, c'est aussi pour alimenter les agents. Donc, on a la la partie de stockage de la donnée dans ce qui est représenté en bas, la data. toute la partie orchestration de la donnée pour arriver à construire quelque chose qui est à la fois la zone gold, la transformation de la donnée pour avoir la donnée propre significative avec un modèle sémantique. C'est ce qu'on appelle la couche de data management, donc les outils qui sont associés pour produire cette cette donnée propre. Et puis enfin, on a des outils de consommation de cette donnée. Ces outils de consommation, la donnée, bah, on les veut multiples, on a continuer à faire des rapports et ça reste le moyen BI aujourd'hui le plus utilisé. Pour WordBI est très utilisé. on a des milliers des fois des dizaines de milliers de rapports dans les entreprises, mais c'est à travers un autre moyen aujourd'hui qu'on va requêter cette donnée à travers ce qu'on appelle des agents. Alors, pour pouvoir bah faire ça, euh ce qu'on a construit chez

Microsoft Fabric

8:42Microsoft, c'est une plateforme qui s'appelle Microsoft Fabrique qui est maintenant bien connu. Alors, on va pas décliner tous les éléments qui sont présentés sur cette slide, mais il faut savoir que la couche data est représentée en par one qui offre plein de de de d'artifices pour pouvoir référencer, collecter la donnée. Et ce qu'on cherche à avoir, c'est cette exhaustivité qui de la donnée. Certains appellent ça la data de gravity. Donc Oneel nous permet ça et puis on a dans fabrique tous les outils qui nous permettent de traiter la donnée. Donc ce que j'appelle la la partie traitement de la donnée à travers bah soit des pipelines de transformation. Euh ça peut être du data factory. Si on est sur des outils ou des plutôt des flux temps réels, on a également cette capacité avec fabrique real time intelligence. Et puis enfin, on a les outils analytiques qui permettent de restituer la donnée aux utilisateurs. Et puis on va consommer en fait cette donnée bah soit dans la partie Power BI qui est représentée à l'écran, soit à travers donc ce qu'on appelle des datas agents qui est dans la partie bleue au milieu analytique. Donc ces data agents qui vont être présentés maintenant par Akram. Je te laisse la main maintenant Akram. Juste pour rappeler que finalement les sémantiques modèles pour la BI interactive était nécessaire qu'elle soit de qualité et donc je comprends après ce que tu viens de dire que pour la BI conversationnelle c'est d'autant plus important que ces sémantiques modèles soient qualitatifs pour finalement comprendre les besoins et y répondre avec les bonnes données. Alors c'est c'est un très bon point Romain, c'est que l'humain à la limite est capable de comprendre qu'il y a une erreur. Donc il a construit effectivement un modèle sémantique. Bah Unia potentiellement si on lui donne de fausses pistes, si elle a pas les bonnes les bonnes informations, c'est d'autant plus critique. Donc ça devient cette clarté sémantique, ce modèle sémantique est extrêmement critique aujourd'hui.

Microsoft Fabric Data Agent

10:48Merci Éric pour cette magnifique introduction. Euh merci Romain également. Donc euh ce qu'on va voir aujourd'hui, c'est que euh comment un data agent peut être un véritable copilote de décision. euh un copilote non seulement capable de diagnostiquer les problèmes, mais aussi de prioriser les actions à mener. Et donc, on va passer, comme tu le disais Éric de je regarde des rapports à je prends des décisions et tout ça directement sur vos données dans Fabrique, dans un lake et aussi même en temps réel. C'est ce qu'on va voir durant cette démo. Donc euh on va essayer de de se focaliser sur une entreprise fictive qui s'appelle Chic Bazar. C'est un groupe de retail grande distribution qui dispose de 92 magasins à travers le monde, qui a

Demo Chic Bazar

11:39également de deux marques et qui dispose d'un catalogue de produits multicatégories, donc du prête à porortter, de l'alimentation, décor et maison. Et donc on est clairement sur un environnement complexe avec beaucoup de données, beaucoup de cap et surtout beaucoup de décisions business à prendre au quotidien. Et là euh durant cette session, on va se concentrer sur une question clé, une vraie question de management et pas juste une question de reporting. La question est quels sont les facteurs qui entraînent de faibles ventes et où les responsables de magasin devraient-ils investir en priorité ? En fait, c'est volontairement une question qui ne peut pas être répondue uniquement avec un graphique ou un simple modèle sémantique. Elle demande de croiser plusieurs sources éventuellement, de comprendre le contexte métier et surtout de raisonner comme le ferait un analyste ou un responsable régional en général. Et pour répondre à cette question, le premier réflexe et c'est totalement normal, c'est de faire de la biaille classique comme il expliquait Éric. Donc nous avons notre base de données, un sémantique modèle euh qui consolide les ventes, la performance. Vous vous voyez ici par magasin, par produit, par période et aussi nous avons les rapports Power BI qui nous permettent de répondre à des questions factuelles et qui prennent les données de ce sémantique model. Voici un exemple de rapport où on voit ici qu'il y a trois pages. Vous pouvez voir aussi la première vue, elle est plus global qui donne de la performance de magasin. On peut voir les chiffres d'affaires, les volumes de vente. On peut aussi analyser nos différentes données selon plusieurs dimensions. Donc typiquement, c'est une vision rapide de la situation qu'un responsable peut voir. Nous avons aussi deux autres pages que nous voyons à gauche. Donc la deuxième, c'est plutôt la variation des ventes par localité et par mois. Et donc ça nous permettra d'analyser les tendances. Et la troisième, elle est dédiée aux magasins qui ont ouvert récemment et donc l'objectif c'est de suivre leur montée en puissance. Donc avec ce type de rapport, on a déjà énormément d'informations. On sait où regarder et on voit où ça va bien, où ça va moins bien. Mais quand on revient à notre question de départ, quelles sont les causes, comment investir, c'est là on atteint quelques limites. En fait PowerB, il est excellent pour analyser ce qui est déjà dans le modèle mais il reste très limité à ce gâre. Il ne sait pas dire ce qui manque dans les données. Il n'y a pas de véritable raisonnement ni explication causale. Également, c'est difficile de croiser plusieurs sources hétérogènes des temps réels, de fichiers. Et aussi ce n'est pas non plus une expérience conversationnelle. C'est à l'utilisateur de poser les bonnes hypothèses et donc ça va nous permettre de voir les symptômes mais pas toujours les causes ni les priorités d'investissement justement sur notre cas actuel. Et justement hein c'est ce qu'on dit hein la BI ça sert pas juste à consulter des données, ça sert à aussi à prendre des décisions. Ça a toujours été la finalité. Donc je pense que là tu vas nous présenter quelque chose qui permet de résoudre ce point. Exactement. On on a toujours parlé d'outil aide à la décision. Et donc là pour dépasser ces limites du reporting classique, on va maintenant s'appuyer sur les fabriques data agent. Un data agent c'est quoi ? Tout simplement un expérien connecté directement euh à vos données dans un lake. Donc l'objectif c'est de permettre aux utilisateurs de parler à leurs données en langage naturel au lieu de naviguer dans les différents rapports comme on l'a vu bien avant. On peut ensuite euh les exposer là où les utilisateurs travaillent dans fabrique, Teams, Copaloud Studio via des API et c'est ce qu'on va voir durant cette démo. Pour construire un data agent, nous avons besoin de deux connaissances complémentaires. La première et qu'on voit plus sur la gauche qui est là, c'est la connaissance métier. En fait, c'est comprendre les relations, les entités, la logique business derrière, le vocabulaire utilisé par l'entreprise. C'est très important. et d'un autre côté la connaissance des sources de données et donc là où où sont les données comment on y accéder leur structure leur qualité et traçabilité et quand on combine ces deux dimensions dans fabrique on ne crée pas juste un chatbot mais un véritable expert métier qui est basé sur vos données. Et la bonne nouvelle, Éric Romain, c'est que un data agent dans fabrique n'est pas un projet IT de plusieurs mois. Nous avons quatre étapes très simples pour le créer. D'abord, on crée l'agende en fabrique comme un nouvel objet de la plateforme. Ensuite, on lui indique quelle données on peut utiliser et ça va jouer le rôle de source de données. Ensuite, on va le configurer avec du contexte métier, don ce dont on a parlé bien avant en lui donnant quelques exemples de questions et à la fin, on va publier pour les métiers qui est le but de tout ce projet-là. Donc côté utilisateur, ce qu'il voit surtout c'est un agent prêt à l'emploi mais pas toute la mécanique derrière. Donc faisons cela, passons plus à la partie démo. Ici nous je suis dans ma plateforme fabrique. Euh j'ai un workspace qui s'appelle data agent Workspace. Nous allons créer un item euh tout simplement qui s'appelle data agent et on va l'appeler store sales data agent pour dire voilà c'est un data agent pour les ventes magasins pour notre entreprise Chic Bazar. L'idée c'est de c'est qu'il devienne l'experéia des vents des magasins de chicazar. Première chose comme on a dit on va associer les sources de données. Donc je commence par lui associer le modèle sémantique des ventes de magasins. Celui qui alimente déjà no rapport pas BI. on l'a vu bien avant. Et puis on va mettre définir les périmètres de données, donc toutes les tables qu'on peut prendre. Et là, ça va nous aider non seulement à sécuriser l'accès si on veut pas que l'agent ait accès à des données ou des colonnes spécifiques et en plus l'idée derrière c'est de lui donner un domaine métier. Ce data agence c'est pour les ventes des magasins mais on peut très bien créer d'autres agents pour d'autres métiers. Donc à ce stade-là, l'agent il sait déjà aller réinterroger les données. Mais avant de poser nos première question, je voudrais vous montrer comment se déroule l'échange avec un utilisateur et un data agent. Donc nous avons trois messages qui sont là. H premier message côté utilisateur, c'est très simple, on pose une question en langage naturel comme un chat et donc on le fait rentrer en bas ici sur le user input que vous voyez. Et puis nous avons deux messages en réponse. Le message numéro 2 qui vous que vous voyez ici, l'agent il va transformer cette question en langage naturel vers une requête qui peut être une requête SQL, KQL. C'est ce qu'on appelle les run steps. Et le message numéro 3, c'est le fait de reformuler la réponse de manière compréhensible pour l'utilisateur final. Ce qui permet toi en tant qu'utilisateur, peut-être si tu connais le SQL, de vérifier euh la query qui t'a généré pour finalement pondérer la qualité de la réponse. Exactement. C'est traçable pour les équipes data et IT et même pour les utilisateurs. Et c'est tout l'intérêt ici. Justement, on va voir comment il va interagir avec les différentes sources de données. Donc, posons une je juste pour préciser ce point-là parce que c'est important. Là, on est vraiment dans la conception comme tu l'as déroulé tout à l'heure, hein. Donc, tu es dans la conception de ton agent. Si à ce moment-là effectivement que tu regardes ben quelle est la requête qui a été générée pour vérifier la validité. Alors c'est quelque chose qu'on propose pas évidemment une fois que l'agent sera publié. On va pas on va pas afficher du SQL ou du KQL ou autre chose même euh à l'utilisateur final. Mais là on est vraiment dans cette phase de conception de la jangle comme tu le montres et ce qui nous permet de vérifier en fait si ben le la génération IA s'est bien passé. Exactement. Vous allez voir après quand on va exposer l'agent, ben l'utilisateur final, il va voir vraiment que la le message numéro 3 qui l'intéresse. Ouais, ce seront peut-être les admins qui pourront après monitorer la qualité des réponses grâce à ça, mais ce sera pas forcément pour les utilisateurs fin. Très bien. C'est ce qu'on cherche sur Romain. Simplicité pour l'utilisateur et transparence pour les équipes data et IT. Super. Et donc euh et c'est commençons à poser nos premières questions. Je vais demander à mon datagent de me donner le top 3 des magasins qui ont les ventes les plus élevées. Donc là c'est exactement comme le frit PowerB là au début. C'est une question il va me donner ici, il va me répondre avec les trois magasins. Si je j'ouvre le message numéro 2, les runsteps, vous voyez qu'il communiqueront sémantique model avec de langage d'axe. C'est le langage du sémantique model. Deuxème question dans la même le même principe montre-moi les ventes par code postal et par chaîne. Il va générer la requête d'Ax pour requetter la semantique modèle. il exécute l'analyse, il me renvoie le résultat avec le code postal et les différentes ventes. Très bien. Maintenant 3e question, on va essayer de poser une question euh qui va venir là juste après un peu plus intéressante. On va lui demander pourquoi certains magasins ont des faibles ventes. Et là vous allez voir que mon data agent, il va se comporter d'une manière à répondre d'une façon générale et générique. il va me dire voilà ça peut être à cause des faibles ventes prix moyen qui est bas faible marge la surface de vente plus rentable ou plutôt peu rentable et donc c'est une réponse logique ok mais elle reste très générique. Pourquoi ? Parce qu'il a pas trouvé cette donnée factuelle qui le laisse répondre et vous pouvez voir ici les différentes réponses qu'il m'a donné. Et donc euh c'est pas ce que j'attends d'un data agent. ce que j'attends d'un dat agent, c'est plus des réponses euh précises. Donc ce que je vais faire, je vais le configurer. Je vais aller dans mon semantic model dans la partie prep data for AI pour préparer mes données pour l'IA. Donc là, j'ai trois options. Le premier, c'est définir les paramètres. C'est pas mon besoin aujourd'hui. Le deuxième, c'est vérifier les réponses. En fait, c'est pour figer certaines réponses prédéfinies. C'est

22:18pas ce dont j'ai besoin aujourd'hui. C'est la troisième option qui m'intéresse, c'est de rajouter des instructions métier. Et là, ce qu'on va lui dire, OK, si tu as une question par rapport à la pèse des ventes, tu donnes les magasins concernés mais ne devine pas. En fait, il faut recommander si nécessaire d'enrichir l'analyse avec des données opérationnelles mais j'ai pas besoin que mon agent devine des réponses et me donne des réponses génériques comme on l'a vu bien avant. Ce qui est intéressant ici, c'est que tu le définis au niveau du modèle. Donc n'importe qui qui réutilise le modèle aura en plus les AI instruction on top, ce qui lui permettra de construire peut-être d'autres datas agents, ce qui peut être intéressant. Très bonne remarque. Oui, exactement. On le définit qu'une fois tout ça. On lui donne ce contexte métier, ses instructions et c'est réutilisable. Avant de voir le résultat de de nos instructions, en fait, il c'est important de savoir ce qu'il y a derrière l'agent. Il y a deux rôles principaux. l'orchestrateur et les outils. L'orchestrateur, il va comprendre la question que vous avez mis en langage naturel. Il va le reformuler si besoin. Il décide quel outil doit être utilisé. Dans notre cas, c'est le sémantique model. Et puis nous avons les outils qui vont générer, valider, exécuter les différentes requêtes. Et là, dans notre cas, les l'outil c'est le semantic model. Et là, vous voyez là en zone ce que nous avons utilisé, c'est les AI instruction. et donc il va faire le DAX et répondre. Donc voyons les résultats de notre petite instruction que nous avons mis. Donc on va essayer de poser une question. Quels sont est-ce que les faibles ventes sont causées par des problèmes opérationnels au magasin ? Euh et là vous allez voir que cette fois il devine pas. Il va lister les magasins ici comme je lui ai dit mais il ne va pas conclure que la cause est opérationnelle. L'agent, il explique euh les limites des données, il propose la prochaine étape de l'analyse. Il va vous dire à la fin ici, si on veut conclure, j'ai besoin de données opérationnelles parce que j'ai j'ai que des données des ventes sur les sémantiqu model. Et donc là, vous voyez qu'il a pris en considération les différentes instructions. Il a mis les DAX pour avoir la liste des magasins, mais il ne devine pas comme avant. Donc nous avec la configuration qu'on a faite ici sur PRP data for AI, l'impact il est direct. Ici on a vu qu'il tient en compte des instructions métier et sur la requête, il a mis les contraintes de raisonnement pour répondre à mes attentes. Il m'a même recommandé à la fin qu'il a besoin de données opérationnelles. Et donc, faisons cela, suivant ces recommandations. Et donc là, on va rajouter les recommandations qui nous a qui nous a donné. Donc un Lake avec des tables sur les données opérationnelles, la fréquentation, contexte opérationnel, rénovation des magasins, le staffing. Donc vous voyez ici qu'il y a cinq tables. On définit notre périmètre comme on l'a fait sur le semantic model. On a besoin des cinq tables et on va rafraîchir pour pouvoir poser nos questions avec deux sources de données. Maintenant, on a rajouté une deuxième source qui est le Lhous. Première question, est-ce que les magasins rénovés performment mieux que les autres et quels sont les meilleurs magasins ? Et donc là, la première fois, l'agent, il va me répondre uniquement à partir du modèle sémantique. Pourquoi ça ? Pour parce qu'il manque une corrélation entre la première source et la deuxième source. Et c'est pour ça que vous voyez qu'ici, il me donne les ventes, il a accès au sémantique modèle, il y a pas de souci. Mais pour corréler ça avec ma deuxième source et avoir cette information de rénovation, vous voyez que cette requête, elle est en erreur. Il arrive pas à faire cette relation entre les deux. Et donc nous ce qu'on va faire, c'est que on va l'aider. On va donner des instructions à notre agent pour les pour l'aider à faire cette corrélation. On va sur agent instruction et ici on va lui dire le champ pour lier les deux les deux sources c'est le location ID et j'en profite pour préciser le vocabulaire métier, le format de sortie, le style de réponse. On revient vers notre data agent. On va euh ici reposer la même question. Euh on va clire le chat pour commencer dès le départ et on va lui dire "OK, maintenant donne-moi le top magasin avec la notion de rénovation. euh qui performe le mieux. Et là, contrairement au départ, vous allez voir qu'il va pouvoir lier les deux sources. Il va il va pouvoir nous donner les top magasins qui ont le plus de ventes avec la notion de rénovation. Donc, il a corrélé les deux sources et c'est ce qu'on va voir sur le tableau qui va s'afficher, donc les différents magasins, leur vente et est-ce qu'ils sont rénovés ou pas. Et même si on regarde les run steps, vous vous allez voir qu'il a utilisé du DAX pour parler avec le semantic model et l'interroger. Il va utiliser du SQL cette fois sur le Lhouse pour interroger les données opérationnelles. Donc on passe d'une analyse purement descriptive à une analyse multisource orientée décision et c'est le but de notre data agent. Super, merci Akram. Et donc on a vu qu'il y avait un certain nombre de bonnes pratiques pour avoir des réponses de qualité. Tu nous as montré un certain nombre avec la préparation du sémantique modè et des instructions au-dessus du data agent. Ici on a une liste de checklist. On vous mettra dans le commentaire le lien de cette checklist pour vérifier si vous avez bien respecté toutes les étapes. Est-ce que vous avez bien défini le scope du data agent ? Est-ce que vous avez rajouté des vérifiés dansware ? Est-ce que vous avez bien uniquement listé les données que vous avez besoin de votre sémantique modèle ? est-ce que vous avez fait les tests et cetera et cetera. Donc c'est une liste, une checklist que vous pouvez suivre et puis vient ensuite un notebook qui va vous permettre d'assesser le fait que vous ayez bien suivi les bonne pratique aussi bien de développement du modèle avec les performances parce qu'on imagine qu'une requête qu'elle soit envoyée par le data agent ou qu'un utilisateur et ben il y a des problèmes de performance qui peuvent arriver si on n pas respecté toutes les bonnes pratiques. Et puis une bonne pratique c'est aussi de rajouter la description aussi bien des mesures comme des colonnes. Et on voit que dans cet exemple ici on a des problèmes. On a aussi des redondances de nom de colonne, ce qui peut poser les problèmes au LLM pour comprendre notre question et y répondre. Et puis après, on peut vérifier si on a bien euh ben tester finalement les réponses de notre modèle. On peut faire ça même en mode batch, tester euh si les réponses sont pertinentes, si c'est elles qui sont attendues. Et donc, on peut automatiser aussi ces phases de test avec un SDK qui va vous permettre comme ceci, on voit ici, on pose différentes questions et programmatiquement on va pouvoir valider que les réponses sont celles qu'on attend. Merci Romain pour cette checklist très intéressante. Et donc dans un datagent, chaque source de donnée, elle est vu comme un outil que LIA peut utiliser. Donc quand on pose une question, LIA regarde la conversation, il décide si elle a besoin de données ou pas, il vérifie les instructions mises par le créateur de l'agence, c'est ce qu'on a vu préalablement. et aussi il va faire appel à un ou plusieurs outils. Donc ça lui permettra de raisonner et répondre en transparence. Essayons d'aller encore plus loin dans nos décisions. On va enrichir notre analyse des ventes des magasins avec des données en temps réel, des informations de terrain. En l'occurrence ici, c'est la fréquentation des magasins en temps réel. Donc s'il y a s'il y a une personne qui rentre au magasin, on le détecte directement. Et ça, on le fait via real time intelligence. Éc, on en a on en a parlé brièvement quand il a présenté fabrique tout à l'heure. Et là, le but c'est que dans Fabrique, sur nos 28000 clients qui utilisent Fabrique, la deuxième composante la plus utilisée après Power BI, c'est le RTI. Donc c'est vraiment expansion. Le but c'est queà partir de données en streaming, base de données, IoTi, événement, application, métier et cetera, en fait il va fabrique va permettre à ces données de passer pour faire un parcours complet en temps réel. Donc on reçoit par exemple des événements depuis un event hub, on les fait transiter sur ce qu'on appelle un event stream pour ingérer les données. On les stock sur un event house euh une base spécifique pour les euh euh les données en temps réel et tout ça. Le langage qui est utilisé derrière c'est du KQL costock language. C'est pour analyser les temps en temps réel. Donc on va rajouter notre troisème source, notre base calcuel des de qui a des données des en temps réel. Et donc il y a deux tables euh de fréquentation de ces magasins. Concrètement, comme on l'a dit, c'est des événements euh qui viennent de eventup dans mon cas qui vont transiter par le event stream que vous voyez ici. Ça va être stocké dans un event house qui est basé sur des données KQL. Et donc là, l'avantage, c'est que vous voyez que les données arrivent en continu et vous voyez dans ce schéma là. Et toutes ces données, elles vont être déversées sur cette base de données, une table où les données arrivent en continu en temps réel. Donc ce qu'on va faire, c'est qu'on va mettre à jour notre instruction globale et on va dire attention, il y a une troisième source et c'est euh la KQL. Ce qu'on va faire, c'est que s'il y a une une question par rapport à l'actualité du terrain, vous utilisez ici euh la base CAQ pour les ventes sémantiques modèles et pour les attributs magasins comme les rénovations, on utilise le Lake House. On va aussi donner des instructions pour notre base en temps réel calqel. On va lui dire si il y a une question par rapport au ralentissement opérationnel, il faut utiliser ce KPI Botanex Core et on on va même lui donner la règle de de ce KPI sur et sur le gâteau. On va même rajouter un exemple de requête sur lesquels il peut se baser pour faire son analyse. On va mettre un exemple de question par rapport au ralentissement opérationnel et on va lui donner aussi la querie une requête KQL qui lui permettra de de lui montrer comment calculer ce KPI. Donc ce qu'on a fait, on a mis à jour les instructions globales et on a euh rajouté des instructions pour notre nouvelle base de données. On va poser une question à notre data agent qui a encore été amélioré et on va lui dire quels sont les magasins qui rencontrent actuellement des ralentissements de services. Là, on a utilisé deux mots clés déjà ralentissement de services.

33:11Deuxièmement, actuellement, ça veut dire que je veux des données euh en temps réel. Et donc là l'agent, il va interroger directement la base réelle en KQL. Et vous voyez ici que il nous donne les différents magasins qui ont des ralentissements. Il a utilisé des KQL qu'on peut voir ici avec le langage KQL pour interroger ma troisème source. Et même quand on voit son analyse, il a utilisé ici mon KPI, le botx score. Il a classé les différents magasins selon ce nouveau nouvel indicateur. Il m'a même dit que voilà la requête que tu m'as donné en instruction, elle m'a aidé pour calculer ce KPI. Et donc euh là, ce que je vais faire, c'est que je vais poser la vraie question qu'on a cherché depuis le départ. Où devons-nous investir pour réduire les ralentissements et à la fois et aussi comment améliorer leur performance commercial ? Et donc là, il y a deux notions performance commerciale donc c'est les ventes. Nous avons aussi les investissements par rapport euh au ralentissement. Et là vous voyez que notre data agent il raisonne, c'est ce qu'on attend de lui. Et il va lier nos différentes sources, décider quelle donné il a besoin pour pour nous répondre. Et là, vous allez voir que non seulement il va nous donner les différents magasins qui sont impactés, mais euh mais en plus, il va mettre cette information de fréquentation pour euh que nos données vraiment reflètent le moment actuel. Et donc là, vous voyez le magasin avec les différentes données opérationnelles et et là, vous voyez que les deux requêtes ont été exécutées en KQL et également en DAX. Donc on est maintenant dans une capable de raisonner sur des données historiques, opérationnelles et en temps réel et de guider des décisions concrètes. C'est top. On peut rappeler que tu es en lecture seule là sur les données, hein. Euh aujourd'hui, le data agent ne va ne va écrire aucune donnée. On peut rappeler aussi que tu peux parler en français avec ton data agent, non ? Oui, exactement. Euh en anglais, on dit euh voilà, c'est c'est recommandé, mais bien sûr, toutes les langues fonctionnent. Si je lui pose en question français, il va me répondre en français également. Donc multilangage, c'est c'est pris en considération. Et donc résumons ici ce que nous avons fait et la partie sécurité aussi romain, nous allons l'aborder un peu plus tard. Et donc euh au centre, on a configuré les instructions globales de l'agent. À gauche, on a ajouté et configuré plusieurs sources de données, chacune avec ses propres règles. C'est ce qu'on a fait avec le Lake House pour lui dire il faut pas deviner. C'est ce qu'on a fait avec le KQL pour lui donner le KPI. Et maintenant, on va pouvoir l'exposer aux utilisateurs finaux côté consommation. Oui, mais Akram, excuse-moi là effectivement, tu as fait des tests unitaires mais dans la vraie vie on fonctionne jamais comme ça. Tu passes en fait, tu fais du test. Euh est-ce qu'on peut faire la même chose avec les dates agents ? Exactement. Et très bonne remarque Éric. justement euh le process qui est derrière ça, il est itératif parce que là comme tu l'as dit, on voit des démos, ça passe du premier coup mais derrière il y a eu plusieurs itérations. Le l'objectif c'est de faire une configuration, poser des questions, évaluer la réponse et rebellote. Mais justement pour vous aider à améliorer euh ces itérations, ce que nous avons mis en place euh c'est qu'il y a un kit de développement data agent SDK. Et donc c'est un notebook euh écrit en Python qui va nous permettre d'évaluer notre data agent d'une façon assez automatique. Et donc ça va nous permettre de savoir quand un agent il est vraiment prêt pour un usage métier à grande échelle. Comment ça marche et c'est ce qu'on a fait justement sur notre data agent. On commence par installer ce kit de développement et on va définir un jeu de questions avec des réponses attendues. Et justement notre data agent va comparer ses réponses avec les les réponses attendues. Donc ici vous voyez que nous avons défini notre data agent avec les différentes informations. Ensuite nous allons exécuter notre data agent pour qu'il euh se compare avec les réponses et les questions de référence que nous avons définies auparavant. il va nous donner justement un score combien il y a de réponses correctes combien il y a de réponses fausses si on veut aller plus loin on peut même mettre un paramètre là le verb en tr et donc nous pouvons voir le détail de comment notre data argent il a répondu à chaque question de référence et ici il va nous donner un lien si on clique dessus et on se connecte et donc on va pouvoir voir l'échange qu'il y a eu entre le data agent et chaque question en l'occurrence ici c'est la Question numéro 1, mais j'ai défini 10 questions, mais vous pouvez définir 50 euh 60 questions et automatiquement il va vous donner un score. Donc l'idée derrière c'est de dire OK, si j'arrive à un pourcentage de 95 % 99 % de bonnes réponses euh par exemple mon data agent il est prêt à être en production. Donc là on peut vraiment dire que nous pouvons passer côté consommation après avoir montré cette partie évaluation. Et donc la bonne nouvelle, c'est qu'il peut être consommé de plusieurs façons. Même ici sur cette slide, vous voyez pas toutes les façons. Il y a même le code le MCP serveur qui manque. Euh et donc aujourd'hui ce qu'on va présenter, c'est quatre exemples concrets de consommation. Côté métier, le premier très simple, c'est d'utiliser euh notre data agent directement dans ce qu'on appelle le standalon copilot pour Power BI. En fait, c'est une interface de chat qui

Consommation du Data Agent

39:14est infusée directement dans Fabrique. Elle va permettre de chercher des rapports, des modèles sémantiques, des agents que nous avons créé et de leur poser des questions euh sur les données. Et on peut aussi référencer un data argent par exemple pour lui poser des questions. Donc c'est ce qu'on va faire pour notre fameux data agent des ventes des magasins. Ici, on va euh euh cliquer sur notre standalon copilot. Donc c'est une interface du chat comme je je l'avais dit et euh je peux je vais poser la question euh où est-ce qu'on doit investir en priorité staffing ou innovation ? Et là vous voyez que j'ai tagué mon datagent, ça veut dire que je lui parle directement. Je peux aussi taguer plusieurs d'autres dates agents. Et donc il va me faire euh la réponse euh que j'attends avec les différents magasins. Où est-ce que je dois investir ? Il est où le le staffing ? car on n'oublie pas, nous avons mis cette transformation sur le L comme données opérationnelle. Merci Akram, tu nous as montré ici le standalon copilote. Alors, on peut rappeler la différence entre les copilotes qui existent dans Microsoft Fabrique et il y en a plusieurs avec finalement ce qu'on a vu depuis le début, les data agents. On a vu que les datas agents tu peux les configurer, ils peuvent attaquer plusieurs sources de données alors que les copilotes finalement sont plutôt là pour utiliser soit un workload soit une source de données seule. Ici, on voit la différence entre Power BI copilote et les data agents. On voit que le goal est assez différent. Les datas agents, on va pouvoir converser avec plusieurs sources de données. On va aussi pouvoir plus le configurer. Le scope est sur plusieurs sources de données. On l'a vu, il parle avec des layout, des warehouses en KQL. Bientôt, on l'a appris aussi avec des données non structurées. Il va bientôt aussi pouvoir interagir avec ces fameuses UDF, mais c'est encore un sneak peck. On va avoir l'intégration avec, on l'a vu, différents outils. Tu vas nous le montrer aussi je crois après comment on peut l'interfacer avec des outils qui vont permettre de le consommer sans être dans l'interface de Microsoft Fabrique. Ici, c'est pour rappeler les différentes solutions de copilote, que ce soit pour de l'autoring, donc du développement ou que ce soit pour finalement l'usage, l'accès aux données. Et on a vu tout à l'heure que un sémantique modèle pouvait être utilisé par un data agent qui lui-même, on va le voir, va pouvoir être exposé dans différentes autres solutions. Merci Romain pour l'explication de la différence entre copilot et data agent car les deux servent les données et permettent de dialoguer en langage naturel mais de différentes manières comme tu l'as si bien expliqué. Deuxème moyen pour euh consommer les dates agent et avec cette fonctionnalité ça change complètement la donne pour les utilisateurs métiers. avec un seul clic, je dis bien un seul clic, quand on publie notre date agent et le le clic il est ici, on va pouvoir le partager avec les applications M365 des utilisateurs métier. Concrètement, ce que ça veut dire, ça veut dire qu'un utilisateur métier qui est sur Teams, qui est sur Excel, qui est sur Word, il peut communiquer avec notre data agent. Là, vous voyez sur cet exemple, par exemple, ici, nous sommes sur Teams. Quand il accède à la au copilot dans Teams, vous voyez qu'il y a un datagent et qu'il peut communiquer avec. Pareil sur Excel pour les utilisateurs métier, il peut faire appel au copilot en haut et justement taguer le data agent et pouvoir communiquer avec. Et donc c'est ce qu'on a fait pour notre fameux data agent des ventes des magasins. Un seul clic, il est disponible sur Teams et vous pouvez discuter avec le datagent et lui poser les différentes questions par rapport à vos données. 3è moyen pour et là on s'adresse plutôt aux équipes IT dev intégration. En fait il existe un kit de développement en SD Capitan qui est disponible sur Gub. Je vous ai laissé le lien ici. Et donc vous voyez que dans la démo à droite quand j'installe ce SDK, il va me permettre à me connecter à mon agent et à lui poser des questions. Par exemple ici, vous voyez que je lui pose la question : "Quels sont les magasins qui ont actuellement des faibles ventes ?" Et au lieu de me répondre euh sur un chat comme on le voyait avant, là il va me répondre directement sur le script. Donc là, c'est idéal et les use case, c'est pour les intégrer dans des portails métiers, des workflow pipeline ou des applications internes des entreprises. Exemple pour le FCA, le fabric analysis où on déploie une solution de Finups, on a créé un data agent en ligne de code comme ça, ce qui permet depuis un notebook de créer le data agent tout configuré sur les données de coût de fabrique et donc avoir un expert phinops avec lequel on peut converser. Un exemple concret. Merci Romain. Ça c'était le 3è moyen. 4e et dernier moyen. On va essayer d'aller un peu plus loin en utilisant une autre plateforme, c'est la Microsoft Fund. Donc comme nous avons une plateforme data qui est fabrique, nous avons d'un autre côté la Microsoft Fundire, connecter, gouverner des agents et des applications I. Donc elle va connecter les modèles, les outils et les différentes données et les règles métiers dans un même runtime. Si on dit par exemple fabrique elle rend li intelligente grâce aux données, on peut dire que fonder rend li lien exploitable à grande échelle. Donc l'idée derrière ce qu'on va faire c'est que on ne va plus poser des questions à la data. On va créer un agent décisionnel surfonderie, on va l'appeler Retail Operation Decision Agent. On va euh et lui il va communiquer avec le fabrique data agent pour les faits et les chiffres et on va rajouter un document PDF qui contient les objectifs stratégiques de l'entreprise. Donc le rôle de ce de cet AG n'est plus seulement d'analyser mais il va prendre des décisions alignées avec la stratégie business. Donc, on croise la performance réelle avec les objectifs de l'entreprise. C'est ce qu'on va faire ici. Donc, on va publier notre fabrique data agent pour qu'il soit euh utilisable comme un outil externe euh comme par exemple sur Microsoft Foundry. Donc là, on est en train de le publier et puis on va passer directement vers Microsoft Fund. On voit ici que nous avons notre decisionnel agent euh qu'on a euh euh créé. Et là, on lui connecte les 12 outils. Donc premier outil, c'est le fabrique date à agent et le deuxème, c'est le fichier qui contient les objectif de l'entreprise. Vous voyez ici, c'est Compagnie Strategic Objectif, un simple fichier PDF à titre d'exemple. Et puis euh nous allons poser la question. La question c'est on va essayer de croiser les deux. Donc on va lui demander quels sont les magasins qui sont en dessous de nos objectifs, de combien et quelles actions concrètes faut-il prendre. Et donc là pour un feu, on peut aussi mettre des instructions sur fonder pour notre agent. On peut même choisir le modèle à utiliser. Notamment ici c'est le GPT 4.1. Et donc ici vous allez voir qu'il va me répondre d'une manière à ce que il va euh croiser les deux données. Il va prendre des données, des objectifs pour mettre les objectifs qui ont été mises. Il va les croiser avec nos données pour dire quels sont les magasins qui surperformment ou sousperformment. Pourquoi et où est-ce qu'on doit investir ? Est-ce que c'est le staffing ? Est-ce que c'est les fréquentations de magasin qu'on qu'on essaie de de d'augmenter ? On va rénover les magasins et cetera. Et pour s'assurer de ça, on peut aller dans TR. On peut voir ici qu'il a notre data agent, il a communiqué avec Azur Fabrique pour faire des appels à notre data agent. il a communiqué avec notre fichier. Vous voyez le file search call qui nous permet de euh communiquer avec le fichier des objectifs. Et donc là, les agents ne travaillent plus seuls, ils collaborent entre données et stratégies pour produire des décisions exploitables. Tu pourrais très bien corréler d'autres sources de données externes à l'organisation, peut-être la météo, la position géographique, les autres magasins autour. Bref, ça t'ouvre le champ des des possibles. Exactement. Donc là c'est juste à titre d'exemple où on a mis je reviens ici le l'objectif de de l'entreprise mais chacun a son use case et ça peut ouvrir le champ à beaucoup de choses. Et là tu reviens vraiment à la définition de l'agent puisque l'agent euh comme bah c'est dit dans la signification sémantique du mot agent, ça agit et effectivement là tu as effectivement une logique vraiment de décision autonome faite par l'agent. Exactement. Et donc l'intérêt de fondrer aussi c'est aussi qu'on peut toucher plus de monde. On a dit exploitable à grande échelle. Et donc ce qu'on va faire c'est qu'on va toucher les execs. L'un des moyens d'y parvenir c'est de passer par une architecture multiagent. Donc là ce qu'on va faire on a on va créer un deuxième agent. On va l'appeler exact summary agent. Et son rôle il est très simple. il va juste reformuler la réponse pour un public dirigeant, plus synthétique, plus stratégique, orienté décision. Donc la même analyse va servir plusieurs audiences simplement avec des agents spécialisés parole. On ne change pas la donnée, on adapte la communication. On pour cela, on va utiliser d'enfonderrer ce qu'on appelle des workflow. tout simplement, c'est juste pour définir qui parle à qui, dans quel ordre et cetera pour faire communiquer les différents datagents. Donc ça permet de contrôler le raisonnement. Donc c'est ce qu'on va faire ici. Je suis sur fonder, on va créer le workflow multiagent stores. On va mettre nos deux agents un pour l'exc et l'autre qui va analyser. Et on va lui poser ici la question quels magasins sont donc dessous de nos objectifs, de combien et quelles actions faut-il prendre ? Et là, vous pouvez voir qu'on a une première réponse qui est une analyse qui peut être peut-être complexe pour des ex qui ont juste besoin de réponse courtes orienté décision et justement ça va la transformer vers cette réponse courte avec les top priorités avec une réponse plus adaptée au monde des exécutifs. Et je pense qu'on a fait le tour Éric Romain. Absolument. Et ce qui est intéressant dans ce que tu as montré là, c'est que on peut faceter en fait un data agent en fonction du profil de consommateur de l'agent. Ça c'est super intéressant.

Securité des données

49:54Alors par contre, il y a quelque chose qui me qui m'intéresse aussi, c'est c'est le fait que OK, on parle de chic Bazar depuis le début avec des données de Chic Bazar, maisant que je sois en fait un opérationnel dans le magasin de Marseille, est-ce que j'ai le droit de voir les données du magasin qui est par exemple en banlieu à Paris ? H merci Éric de de préciser cela et justement la réponse est non. Nous pouvons bloquer cela. Le volet sécurité. Pour finir cette session, elle est primordiale chez Microsoft. Avec Microsoft Cloud, il y a trois engagements autour de l'IA. Donc non seulement le premier, les données sont vos données. Donc vous restez propriétaire de vos données. La deuxième c'est que vos données ne servent pas à entraîner des modèles des autres. L'IA apprend pour votre entreprise, pas pour l'extérieur. Et la 3e, tout est protégé par des standards de sécurité. Et donc nous avons aussi ce qu'on appelle les principes des responsibles AI, équité, fiabilité, confidentialité et cetera. Donc tout ça va nous permettre de sécuriser votre utilisation de l'IA. Et exemple pour répondre à ta question sur notre euh data agent des magasins, vous pouvez voir ici que nous avons un agent euh à gosse avec un utilisateur admin tout. Donc ici, vous pouvez voir qu'il communique clairement avec l'agent et à droite un utilisateur landa qui n'a pas accès aux données. Donc vous pouvez voir que ici sur les sources de données, il a un warning qui lui dit vous n'avez pas les permissions suffisantes pour lire les données. Donc même s'il a accès au dat agent, il ne pourra pas extraire les données. Je pense qu'on peut être encore un peu plus granulaire avec le relevel security. Exactement Romain. Là nous avons donné des permissions sur les items, ça veut dire un layout, les sources de données, mais on peut faire du RLS, row level security, donc des lignes précises, CLS, des column level security et ça va s'appliquer en plus plus précisément sur ce qu'on veut. Donc ici la l'IA ne contourne jamais la sécurité et donc elle l'applique. Donc même si l'agent il est partagé, il respecte toujours les droits d'accès aux données.

Conclusion

52:12Merci Akram pour bah cette présentation et surtout ces ces ces démos. Alors Microsoft fabrique à travers le data agence, c'est quelque chose qui évolue en en permanence. Euh je sais plus si c'est toi Akram ou Romain qui l'a cité, mais il y a des nouvelles fonctionnalités qui vont bientôt arriver. Alors ce que je vous propose c'est aussi pour ceux qui seraient intéressés pour voir ça en détail un événement qui est prévu chez Microsoft le 1er avril, le Fabrique Road Show où nous allons passer toute une après-midi à décortiquer en détail à partir de données métiers qui vont arriver dans fabrique. On verra même les notions d'ingestion dans dans le lexosition de ces données sous la forme d'agent et on verra notamment la publication notamment et l'utilisation de ces agents dans AI Fundry et leur utilisation dans Office 365 copilote. Donc ça c'est pour les les nouveautés et les événements. Il y a d'autres événements je crois romain qui on peut citer les Tour qui arrivent à Paris le 11 mars et on peut citer aussi la Fapcon qui a lieu à Atlanta en mars aussi pour lequel je pense qu'on va voir vraiment beaucoup d'annonces sur data agent parce qu'on imagine he Microsoft investi comme aussi beaucoup de de partenaires sur ce sujet-là qui est la BI conversationnelle. En tout cas merci beaucoup à vous deux pour cette super session. Euh voilà pour cet épisode de Fardata. Si ce sujet vous a aidé à voir plus clair sur vos choix data, alors le phare aura rempli sa mission. N'hésitez pas à vous abonner, à partager autour de vous et surtout garder le cap. À bientôt. À bientôt. À bientôt.