L’IoT au cœur des usines, REX concret multiplateformes

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 Fardata, on décrypte les services de données d'Aytics et d'IA. Le tout avec un ton accessible, des choix techniques assumés. et une touche derma. Alors que vous soyez architecte, analyste, dat engineer ou product honur ou simplement curieux, fardata vous accompagne pour comprendre les enjeux réels, éclairer les compromis et prendre de meilleures décisions et parfois avec le cri des mouettes en bruit de fond. Et si ce genre de contenu vous parle, n'hésitez pas à vous abonner. Alors, cap sur l'épisode du jour. J'ai le plaisir d'être accompagné par Marc et Vincent pour parler de RTI Realme Intelligence et ceux dans un contexte industriel avec un enjeu multiplateforme. Ils ont tous deux travaillé sur un projet client avec un enjeu clair, analyser des milliers de capteurs et les visualiser en temps réel dans des dashboards. Marc Vincent, avant d'entrer dans la solution, est-ce que vous pouvez d'abord vous présenter et puis après nous expliquer le contexte du projet et les enjeux côté industriel ? Bonjour à tous. Donc moi Marc AG, je suis Solution Engineer chez Microsoft. Et donc je suis accompagné par Vincent avec qui on a fait le projet. Bonjour à tous, je m'appelle Vincent et je suis architecte cloud et donc on a collaboré avec Marc et je me suis occupé plutôt de la partie implémentation. Euh l'idée c'était de montrer bah les les les capabilités de de Microsoft fabrique dans les usines où on a bah des milliers de de device qui vont produire des quantités de données pharamineuses.

Architecture

1:47Et l'idée en fait c'est de pouvoir bah justement pouvoir intégrer ces données au fil de l'eau et avoir des bah des des reportings comme il se doit, c'est-à-dire des reportings temps réel qui vont permettre de monitorer bah tous les devices pour des opérateurs. Donc ça c'est vraiment le le point principal. Puis ensuite faire de l'analytics puisque l'idée c'est ensuite pouvoir prendre des décisions sur sur des capteurs et autres. Et le et comme on est dans le monde de l'IA aujourd'hui, bah l'idée aussi c'est derrière pouvoir avoir des agents, des agents opérationnels qui vont se charger eux à la fois de collecter enfin de de récupérer la data et de l'analyser et surtout permettre à des opérateurs d'avoir des des insights en temps réel. Et la le challenge qu'on avait par sur le client en question, c'était de se dire "OK, moi j'ai euh vous avez Microsoft Fabrique en tant que plateforme data temps réel, par contre nous on a un patrimoine qui n'est pas sur Microsoft Fabrique." Et l'idée donc ce client comme il avait beaucoup de technologies, il a du Snowflex, il a du databx, l'idée c'était aussi de se dire bah on va prendre des données de son euh patrimoine, de son écosystème et on va les mixer avec ses données temps réelles. Et dernier point qui est très important, le client nous dit les sources de vérité aujourd'hui, c'est pas forcément Microsoft Fabrique. Comment moi je vais pouvoir lire ces données temps réel sur ma plateforme de ma zone de vérité ? Et c'est ça tout le challenge. Donc on va pas vous décrire tout le projet qu'on a fait pour le client en question dans ces usines. Là l'idée c'est de de de vous montrer un petit peu à quoi ça ressemblait. Donc pour la démo, on va simuler euh des devices euh qui seraient dans des usines hein qui euh qui remontent des capteurs. Donc ça va être l'humidité, la température, la pression et la qualité de l'air. Et à partir de ces euh devices là, donc on va les intégrer euh sur Microsoft Fabrique. pour faire pour simuler ces ces ces IoT. Vincent a fait une application sous un une VM Linux pour essayer de rester le plus léger possible et surtout pour que vous puissiez vous rejouer demain cette démo environnement. Donc on va déverser et simuler de de de la de la donnée quoi venant des de ces devices là et on va les les streamer pour les les embarquer dans dans Microsoft Fabrique au travers un protocole MQTT. [grognement] Par la suite, on va vous montrer plusieurs capabilités de Microsoft Fabrique. C'est ce que je disais tout à l'heure. On a la partie plutôt dashboard opérationnel. Donc c'est plutôt du monitoring au départ au travers ce qu'on appelle les rayem dashboard. Et puis ensuite faut pas oublier Power BI he qui est là et qui permet justement de faire des des dashboards un peu plus chiadé, on va dire plus analytics sans pour autant oublier cette cette cet aspect. Donc c'est ce qu'on va vous montrer au travers la démo. Puis ensuite euh c'est ce que je disais tout à l'heure, on va vraiment se focaliser sur on prend des données externes. Bon là on va prendre la météo qui pourrait être des données qui viendraient d'une plateforme externe euh pour corréler tout ça et faire et interroger des agents. Donc l'idée c'était que il fallait qu'on reproduise un petit peu la le besoin du client. Donc son besoin, il était assez simple. il voulait centraliser dans une plateforme différentes usines et donc on avait la possibilité d'externaliser l'inestion de données. Donc fabrique prenait tout un sens. L'idée c'était de pouvoir ingérer la donnée multi location enfin multiloisation et donc pour y arriver, on est parti d'un besoin simple. Euh et donc j'ai reproduit dans un ensemble de machines virtuelles un boot code et ce boot code, il est développé en Rust pour être le plus léger possible comme si j'avais dû le déployer dans un device IoT dans je sais pas Arduino, un Raspberry et il va envoyer des données à Azure IoTub. On l'a testé dans un deuxième cas. Azur IoTub est en fin de vie donc on tend à le remplacer avec Azure IoT Operations et le service était aussi compatible. Donc c'est un service qui va être euh multiservice. Ce protocole MQTT ce qu'il fait c'est qu'il va générer des données assez bêtes, hein, de l'humidité, de la température, du la pression, des choses qu'on a randomisé avec un algorithme et il va les envoyer en temps réel. Ces données, elles vont être mises en queue donc par Azur IoTob et elles vont être ingérées via data stream. Euh donc c'est finalement la méthode qui va permettre d'ingérer la donnée dans fabrique. Et ce datastream, il va directement lire un ensemble de fichiers Gon euh qui vont pouvoir être manipulés via euh la base de données en temps réel dans fabrique. Cette structure Gison, elle est très riche. Donc on va utiliser le langage KQL pour la simplifier, mettre à plat les éléments et pouvoir les analyser dans une forme normale qu'on aime beaucoup dans Power BI et travailler avec cette information pour ensuite le la mettre en forme sous un ensemble de capill. Donc si on veut rester purement dans la sauce temps réel et analyse en temps réel, il y a un truc qui est super intéressant dans Microsoft Fabrique, ça s'appelle les templates plotly. Donc c'est une librairie qui est développée avec euh des différentes jauges, avec différents algos et derrière on va pouvoir afficher des charts qui sont infinies, un petit peu comme si on avait mat plot lib dans dans Python. Et l'avantage c'est que bah du coup ça devient infini. Donc toutes les les limitations avec les simples visuels qu'on a dans RTI, bah elles sont illimitées. On a des jauges, des capill, des couleurs et cetera et c'est assez assez riche. OK. Une question. Si on se concentre. Ouais. Par rapport à l'usage de IoT hub, quelle était ici la nécessité ? Tu aurais pu envoyer les données directement un event stream dans dans fabrique. Alors l'avantage, c'est que on va aujourd'hui dans Microsoft fabrique si la capacité s'éteint, on perd les messages. OK. Donc en plaçant un IoTub en dehors de Microsoft fabric, l'avantage c'est que la mémoire tampon va ça va se charger et que s'il y a une failure ou s'il y a un perte de connexion entre les deux services, ça nous assure une stabilité et le service va pouvoir reprendre la queue là où il en était, là où il s'est arrêté. OK. Donc si on regarde cette architecture, c'est une architecture lambda. En fait, l'idée c'est que nos données en temps réel, elles viennent d'Azure, de VM Azur, donc c'est notre fameux device IoT qu'on a schématisé. Elles sont intégrées dans l'evento house et l'evento house va en temps réel transformer cette donnée. Donc avec un ensemble de d'update policies, c'est vraiment la clé hein de de notre base qu'Quel. On va transformer la donnée à la volée, la normaliser, la mettre à plat. Le sujet c'est que ça ça nous permet de faire des analyses en temps réel, donc de visualiser nos données, de pouvoir prendre des capill, des indicateurs tout de suite et d'avoir une un impact sur ce qu'on fait. En revanche, ce qu'on aime, c'est aussi la comparer avec notre référentiel, toutes les informations sur les usines, les informations sur les services qui sont déployés. Et ça pour le client, c'était déployé dans deux services, Snowflake et Databx. Et via la richesse des schémas iceberg et des schémas Delta, on a réussi sans copier la donnée et c'est ça qui est super important à la représenter comme table delta dans Oneelake. Donc on a le double avantage d'être dans Microsoft fabrique avec un stockage qui est externalisé. On change pas la source, on fait pas de transformation, il y a pas de migration de données, mais on arrive à mixer des données chaudes, des données froides dans un seul endroit. Et par-dessus céta delta, bah on a créé un modèle sémantique, des rapports pour faire de l'analyse un petit peu plus profonde et surtout des agents et du copilote. Et on verra qu'il est capable de mélanger les données de plusieurs services et c'est ça qui est super intéressant. Si on zoome sur real time intelligence qui est le workload fabrique qu'on a utilisé pour faire ce projet, il y a des composants intéressant alors qu'on va peut-être pas tous voir dans la démo parce que ça nous prendrait beaucoup de temps. Mais ce que là où on voulait faire une un zoom, c'est sur la partie anonym detection. Finalement, l'anony Detection va nous permettre de détecter des patterns d'anomalie euh via des algos qui sont directement fournis en en KQL via les fonctions KQL de de l'eventhouse. Et c'est hyper intéressant parce que euh pour les opérateurs, on va pas avoir uniquement la restitution des données tempelles, mais aussi on va avoir de l'intelligence au travers ces patterns là. Donc ça aussi c'est des choses que vous avez aussi dans dans Real Time Intelligence à utiliser. Donc on est une VM. Bah tout tous ces éléments, vous allez pouvoir le retrouver sur le le guit de Vincent qui a qui a mis en place la démo. Donc une

Demo

10:16première machine, c'est la VM que j'ai appelé VM- IoT euh qui elle va simuler justement ces ces devices qu'on va streamer euh au travers l'eventous et toute l'architecture fabrique. Euh donc pour se connecter, on utilise SSH euh et on se connecte. Alors, n'oubliez pas la clé qui vous permet de d'accepter d'accéder côté SSH, la clé cryptée. Une fois qu'on est connecté, on se met sur donc il faut installer le projet, installer Rust et cetera, les packages. Donc ça c'est bien expliqué dans le guide de Vincent. Et une fois que que c'est fait, j'ai plus qu'à lancer le projet. Donc avant de de lancer le donc de simuler les IoTI, je voudrais vous montrer du coup sur fabrique mon projet. Euh et donc enfin mon projet, notre projet, excusez-moi Vincent, il est là. Donc ici, on a un tas clos avec plusieurs éléments. Donc on a l'event House qui est au cœur, on va dire, du du projet puisque c'est lui qui va store toutes les données en gison des IoT qui vont arriver. Et euh on va avoir donc plusieurs rapports qu'on a appelé near real time qui sont les les rapports les rapports temps réel sur le composant qu'on appelle RTI RTI dashboard et euh les rapports PowerBI. Si je deep dive et puis après on on verra comment c'est intégré et cetera. Mais déjà je vais vous montrer l'effet wou quand lorsqu'on va démarrer euh nos device et voir la rapidité pour pouvoir justement euh commencer à avoir des données arrivées. Donc on va démarrer par vous montrer du coup le ce rapport real time de du composant donc exclusivement disponible sur la partie RTI et qui fait partie des composants disponibles. Donc là on va afficher uniquement les données temps réelles euh sur ce dashboard là. Vous voyez que bah les données euh sont pas forcément euh toutes disponibles encore. Il va falloir que du coup je j'allume euh mon streaming et mes éléments à streamer, donc mes mes mon IoT. Donc je vais sur la machine sur donc sur sur Linux et là je vais lancer le projet. Voilà, on voit que on voit donc la les devices qui démarrent. Merci Vincent. euh où euh bah je vais avoir trois devices où à chaque fois ben on va envoyer des gison avec euh des éléments donc qui sont euh qui sont aléatoires he qui sont dans l'algo que Vincent a mis en place. Mais on a trois devices avec bah comme comme je disais tout à l'heure le device ID, la température, l'humidité, le l'air et le la pression. Donc si je retourne dans mon dans mon dashboard TL là, voilà, j'ai de la donnée qui arrive directement. Euh et ensuite une fois qu'on qu'on a vu ça, on va voir quand même qu'est-ce qui se passe côté euh euh backend. Euh d'abord il y a peu de latence hein. Il y a il y a aucune latence et c'est ça qui fait la différence par rapport à un dashboard PowerBi. Pas qu'il y a de la lance mais là on est vraiment sur du stream en continu. Voyez le refrate ici ça nous indique bien que nous sommes en continu versus un rapport PowerB. Mais vous allez voir que PowerBier a aussi tout son sens et on va le voir juste après. Euh si je retourne sur mon MQTT broker, donc l'IoTI euh on voit que ça a démarré et que j'ai des messages qui arrivent he évidemment voyez ici. Donc c'est vraiment les messages que qu'on envoie euh au travers donc les les IoT envoient vers ce ce broker qui ensuite stream côté euh Eventhouse. Voilà. Euh je vais maintenant passer la main à Vincent qui va vous parler un peu plus de la partie Eventhouse justement. Donc si je vais dessus, ce qui est intéressant dans l'eventhouse, c'est que déjà on va pouvoir comparer les quand on observe la table qui récupère les informations, on est capable de comparer le temps d'envoi de l'information depuis le device, le moment où il a été généré et le moment où il est ingéré par fabrique. Donc ça, on va le comparer avec le moment de la mise en queue et le moment d'ingestion. Et on peut remarquer que le la latence, elle est inférieure à un diè de secondes. Donc si on clique par exemple sur la table R data, on va pouvoir consulter le schéma. Et là, ce qu'on voit, c'est que le temps d'entrée du message, il est de pour la première ligne 11h55 et euh 483 msees et de l'autre côté 566 msees. Donc, on est sur de la latence euh faible et on a des données qui sont ingérées dans le service. Une fois qu'on a fait ça, notre table R data, vous pouvez le voir le fichier le petit Jason là, il est toujours formaté sous forme de Jason. On a une update policy qui vient transformer le Gizon et qui vient venir récupérer les informations qu'on veut. Donc le gone est très simple et on pourrait aller très très loin dans l'analyse, retirer des colonnes, changer les types et ça ça se fait via une update policy. L'upate policy, ensuite ce qu'elle vient faire c'est qu'elle vient alimenter une table et elle vient splitter chaque champ dans un dans une colonne et venir venir appliquer nos transformations. Donc là, on pourrait aller très loin. On peut c'est des analyses qui sont faites ligne à ligne mais dans d'autres cas d'usage les updates de policier on peut très bien faire des analyses sur du le passé donc plusieurs événements venir alimenter des informations basé sur une une fenêtre d'information et donc c'est là la vraie richesse de toute l'analyse en temps réel dans dans fabrique. Et c'est là que tu viendrais rajouter aussi l'appel de tes fonctions d'anomalie détection par exemple. Exactement. Alors ça c'est quelque chose de très très riche. Donc on si on va sur le query set, on va pouvoir voir qu'on a euh des requêtes euh qui nous permettent de faire de la détection d'anomalie avec euh du machine learning assez simple. Donc ça va être par exemple l'application de différentes règles euh pour pouvoir détecter euh une régression linéaire, une régression logistique sur la base d'information. Donc si on a un autre cas d'usage qu'on avait mis en place pour un autre client, on avait des fours et une température qui augmentait et on était capable grâce à l'algorithme directement dans le langage sans modèle de machine learning et sans rajouter de fonctionnalité de venir détecter si les temps d'allumage des fours étaient trop longs et si les températures des fours étaient hors des hors des normes. C'est pas nous qui avons défini les normes. Les normes, elles dépendent des valeurs. Donc si la valeur tous les jours elle est à une certaine valeur et qu'on voit qu'il y a un point qui sort de cette de cette dynamique et ben on va la détecter et pouvoir lancer des anomal. J'imagine qu'avec data activator tu pourrais justement recueillir ces anomalies et actionner des actions. Alors et ça c'est ça c'est une information qu'on a depuis effectivement la Fabcon qui s'est qui s'est clos la semaine dernière. Euh on on connaît les agents donc on sait qu'on est capable de faire de l'analyse textuelle et en temps réel de nos différentes informations. Maintenant on a la possibilité d'envoyer des et de déclencher un ensemble d'actions. Donc les les agents opérationnels, c'est vraiment bah le bras armé de fabrique par-dessus nos données en temps réellir détecter une anomalie. Donc on lui explique avec des instructions claires quel élément on veut analyser et après on lui donne un moyen d'action. Et lorsqu'il va pouvoir analyser ces éléments-là, déclencher une alerte, envoyer un message, prendre une recommandation sur l'information et et venir donc avoir une chaîne de bout en bout entre l'alimentation et la prise d'action avec une décision qui est faite en autonomie. Je reviens un peu sur les updates ici parce que c'est vraiment un composant hyper intéressant. Vous voyez ça un peu comme de le TL temps réel, c'est-à-dire que au moment où la donnée arrive sur notre table rata qui est finalement nos nos données brut qui arrivent des donc les gison euh du coup on va c'est hyper puissant parce que en temps réel il va aller euh faire des transformations. Donc là en l'occurrence on a on lui a demandé de parcer les données pour les mettre à plat euh dans une autre table qu'on a appelé clean clean. L'idée c'est c'est que derrière on va pouvoir plus facilement analyser avec un Power BI avec justement du KQL sur au travers les les dashboard réel qu'on avait juste avant. Mais c'est hyper puissant et hyper léger aussi en terme de consommation cu parce que souvent on parle de de de fabrique mais on oublie que les composants sont optimisées et notamment cette partie là qui est hyper léger en terme de consommation cellule. Euh si maintenant on va plus loin, donc là c'est tout le code qu'on a généré. Alors on aurait pu le faire avec l'event stream et et faire du low code no code. Nous on a décidé de le faire avec les update policy. Mais voilà aussi pour les personnes moins à l'aise avec le code KQL et les transformations via les updates policier. On a exactement le même composant en low code NOCOP et qu'on aurait pu utiliser. Ouais. Sinon copilote nous aide aussi à rédiger du script plutôt bien. Complètement. Donc on là, on a toujours nos notre copilote. D'ailleurs, on va le voir au travers le dashboard en Vincent va vous montrer les requêtes qu'il a faites pour pouvoir afficher bah les éléments qu'on qu'on a vu tout à l'heure dans le dashboard. Mais il a il peut très bien faire directement des requêtes parce que Vincent est un expert, mais on peut très bien aussi se dire que on va le faire avec Copilot. Justement, si je reviens sur ce dashboard, je je je vais vous montrer comment du coup avec Vincent, on a réussi à faire toutes ses requêtes finalement. Donc on est en mode vous avez view, on peut passer en mode edit et Vant du coup je te laisse la main pour expliquer un peu comment tu appuy. Ouais. Alors les graphiques qui sont en haut à gauche, c'est des graphiques qui sont directement intégrés par le service Power BI. Donc c'est des charts assez simples. Donc si on clique sur le petit crayon ou alors comme tu as fait pour aller dans edit, on va pouvoir modifier la requête KQL qui affiche et génère ce visuel. Donc de quoi on a besoin ? En fait, on a besoin de générer un tableau qu'on va pouvoir voir dans l'onglet résulte en bas à gauche. Et ce résultat, c'est vraiment le résultat de la de la requête qu'on a mis là-haut. Donc là, on peut voir que on a organisé la température par device et par axe de temps. Donc sur base de ça, j'ai la possibilité de générer un visuel. Donc j'ai un onglet visuel qui s'affiche juste à côté. Et quand je clique dessus, bah j'ai la possibilité sur la droite de comme dans Power BI formater mon visuel. Donc je choisis mon type de visuel, c'est un line chart. Euh et puis après je viens choisir les colonnes en axi des ordonnées, des abscisses, je mets des couleurs et et donc on a un rendu assez simple. Alors c'est moins euh recherché que les les éléments qu'on peut faire dans Power BI et c'est en général un petit peu le ce que les clients nous disent bah ouais moi j'ai l'habitude d'aller plus loin, j'ai l'habitude de faire plus de transformation, comment j'y arrive ? Donc faut voir ça comme un outil effectivement très opérationnel mais on peut aller plus loin. Donc si tu reviens sur le tableau en faisant discard change tout en haut à droite, on va voir qu'on a pardon tout en haut à droite un petit une petite croix. Ah pardon euh on va pouvoir voir qu'on a tout en bas ici des jauges. Et donc ces jauges bah là c'est pareil sauf que là on a installé dans la dans la la base de données un petit bout de code et ce bout de code il interprète euh bah le les visuels qu'on veut

21:31mettre. Donc là on va passer tout un tas de variables en disant bah je veux tel visuel les données, elles sont ici et bah je veux telle couleur, je veux tel seuil. Donc c'est un petit peu plus code que Power BI mais pour autant ça nous permet de faire des visuels très avancés. Donc là j'ai mis des jauges parce que c'était le besoin du client mais on a on a tout un tas de choses qui ressemblent au à ce qu'on a dans MAT Plopin. Alors ça peut paraître [raclement de gorge] un petit peu cavalier un petit peu comme code. Là on voit qu'il y a beaucoup de choses. On a on a c'est très verbeux. Euh alors, c'est pas moi qui l'ai inventé ce code. Ce code, je l'ai trouvé dans la doc. Euh et j'ai simplement remplacé les valeurs pour pouvoir euh euh arriver aux éléments. Vous voyez la fonction qui permet de faire une une jauge chart là qui est ligne neuf. Ça c'est dans la doc hein. Donc euh on a rien à inventer. Simplement on reprend le code euh pour y arriver. Donc on pourrait très bien être aidé de copilot qui vient nous aider à choisir le bon visuel et générer le bout de code correspondant. Et après nous le seul truc qu'on a à faire c'est vous voyez de la ligne 3 à la ligne 7 venir donner les couleurs qu'on veut le titre du du tableau et basta. Donc c'est assez simple. Une librairie qu'on installe avec un code qu'on vient exécuter, une ligne et derrière on se fait aider de copilot pour générer notre code. Et tu l'as installé où alors cette librairie ? Alors, la librairie, elle est dans la table qu'on peut voir dans Ploty Template. Euh ce qui se passe, c'est que au moment où on l'installe, on exécute un bout de code qui vient récupérer les données qui étaient disponibles dans la librairie Microsoft et puis elle se déploie dans la table et cette table, on la réutilise pour pouvoir afficher les éléments derrière. Super. Voilà, petit template, la table. Voilà. Et donc là voilà c'est tout c'est tout simple c'est les j'en ai mis que trois j'ai mis les anomalies et puis les jauges mais on pourrait récupérer tous les visuels qui existent quoi. Donc ça c'est évidemment pas quelque chose que moi j'ai inventé je juste repris en ligne. Vous avez activé le mirroring de ces données dans le oneel leg pour des questions d'analyse après de corrélation justement avec vos autres sources de données type Snowflex et datab c'est c'est ça on parlait tout à l'heure de lambda architecture. C'est on est vraiment dans ce modèle là. Une fois que on a les données temps réel, bah pour des besoins de temps réels, faut pas oublier l'analyse et justement cette possibilité de d'avoir sous format Delta ces mêmes tables et ces mêmes données en quasi temp réel en fait. Et et c'est pour ça que derrière alors là on va se pluguer, vous allez voir sur un rapport Power BI pour montrer un petit peu comment aller plus loin parce que certains clients nous disent bah OK c'est bien de faire du monitoring mais Quid euh bah des de l'analytics dont j'ai l'habitude de faire avec des visuels un peu plus avancés dans Power BIF. Donc c'est ce qu'on va vous présenter juste après. Donc là je vais je vais aller ouvrir ce rapport Power BI. Donc là sur le sur le rapport pour AB, on est connecté sur le end point du KQL et non pas sur la donnée qui est mirorée sur le le l'ho donc au format Delta pour des raisons de latency parce que le client voulait quand même avoir des données en quasi temps réel. Euh par contre euh justement le use case de redescendre la donnée, vous allez voir euh dans le L va nous permettre de faire un agent qui va prendre à la fois euh la donnée de temps réel euh qui est euh mirorée et euh les données de bah de nos autres plateformes qui sont euh en l'occurrence databl. Donc si je m'attarde d'abord sur le rapport euh temps réel, enfin le rapport Power Bay du coup qui est justement sur le endpoint KQL temps réel, Vincent si tu veux le commenter, n'hésite pas. Le rapport là, il est branché effectivement sur le modèle KQL. Et donc pour pouvoir arriver à avoir un affège en temps réel, on a utilisé du direct query. Donc direct query, on pourrait se dire que c'est effrayant, que c'est mauvais en performance. Sauf que quand on s'en sert avec les requêtes natives et des paramètres M, en fait, on a un tableau de bord qui fonctionne à merveille et qu'on ait des données dans datab, qu'on ait des données dans une base calcul. Si on arrive à transformer le la manière dont on génère notre modèle et à faire pour chaque visuel une requête, en fait, c'est là qu'on a toute la clé de l'outil et que il prend tout son sens. Donc le direct query dans ce cas d'usage, on peut voir que c'est quand même très pertinent et que ça nous permet de retrouver un mode où on est très à l'aise dans la définition de nos visuels. On a quelque chose de d'assez familier et on a des super pe Là, je vois que tu rafraîchis pas la page parce que tu as mis un autorfrh. C'est ça. Exactement. Exactement. Alors, on peut voir aussi que je me suis amusé à dessiner des cuves et puis des grands conteners. Ça, c'est des choses que j'ai fait à la main et que j'ai incrusté dans mes visuels. Euh, c'est le seul truc qui est pas dans Power BI que j'ai rajouté. Sinon, tout le reste c'est choses le PowerBi. Donc, ici euh on vous a présenté le dashboard PowerBay. Maintenant, on va parler plus d'analytics et euh on va dire de de mix de données qu'on va pouvoir faire à la fois avec nos données temps réel et nos données euh bah de d'autres d'autres sources de données telles que Databx et Snowflex. Euh dans ce use case là, du coup, je vais ouvrir mon Lake, OK ? Et quand je monous, je vais aller faire justement ce qu'on appelle des shortcuts qui vont nous permettre d'aller récupérer à la fois les données de Snowflex et les données de datab plus pas nos tables brutes et nos tables en temps réel qu'on a récupéré via le mirroring côté eventus. Donc pour faire ça, je vais faire un shortcut et je vais aller me récupérer mes objets datab mirroré et mes objets Snowflex. Assez simple hein. Je suis sur Oneel et vous voyez qu'ici euh j'ai alors je vais pas on a déjà fait des épisodes qui expliquent comment on va interconnecter via le l'iceberg et créer une base Snowflake qui va pointer sur Oneel. Donc là c'est vraiment ce casl. Et donc quand il va créer quand on va créer la base Snowflex, on va les faire pointer sur le oneel, ce qui va être hyper intéressant puisque je vais directement récupérer cette donnée là dans mon Luse sans avoir à recopier les données de Snowflake. Donc j'ai juste à aller sélectionner mon objet mirroring Snowflake et de la même façon mon catalogue datab où j'ai pareil des données externes et je vais réunir l'ensemble euh dans mon layout. Donc vous voyez que j'ai mes données plus les données externes que je vais retrouver à la fois dans Snowflex ou Datab. Là si je switch rapidement sur sur Datab les données qui sont ici. Donc on utilise ce qu'on appelle la fonction mirroring qui va nous permettre de justement mirrorer ces données là et sans avoir à les copier. Donc je récupère finalement les métadonnées, hein, c'est du mirroring mais dans Databric ou dans Snowflex, on est plus dans le shortcut, dans la mesure où on va aller pointer sur la donnée qui a été produite dans le stockage sous-jacent là donc sur Databak c'était de la la DS Gen 2. Et côté Snowflex, bah c'est le oneelake sur lequel j'ai décidé d'écrire. Donc une fois qu'on a fait notre Lake House, elle va servir de réceptacle justement à notre agent. Euh et je vais laisser Vincent vous présenter justement l'agent et comment on le configure. Donc l'agent c'est vraiment euh simple hein. C'est un outil qui est pas pensé euh comme CQL où effectivement fallait être un petit peu plus technique pour le mettre en main, même si on a vu que copilot pouvait nous aider, mais il faut quand même avoir des connaissances data euh assez rudimentaires. Là l'agence c'est très simple. L'idée c'est qu'on va venir fournir un ensemble de sources de données. Donc là, vous pouvez sur la gauche qu'on peut choisir des données, les rajouter et venir choisir nos petites nos tables particulières. Donc là, on a pris la table des de des informations météo depuis datx et on va la lier avec nos données de nos différents capteurs et les informations sur notre température. On va chercher notre table depuis notre Lake et avec ça, on va lui expliquer comment interpréter ses infos. Donc les instructions pour l'agent, c'est tout simplement qui est l'agent, qu'est-ce qui de quoi est-il responsable ? Et après, on a un petit bouton setup en haut à gauche là. Et quand on clique dessus, euh on va pouvoir aller plus finement dans les instructions. Donc on va fournir la méthode euh dans euh data source instructions et dans example queries. On va rajouter les instructions sur les différentes data sources, qui est la data source, qu'est-ce que ça contient ? Et les requêtes d'exemple, bah c'est comment on vient récupérer un item ou un autre. Donc ça c'est super riche. Le premier élément, les data source instructions, on peut aller très loin. Il faut lui fournir les informations comme si on voulait discuter avec un modèle GPT Open AI. Donc là, moi mon conseil c'est vous prenez vos instructions, vous les envoyez dans Open AI, un modèle Open AI et vous lui dites "Relmez-les à la sauce comme si je devais te fournir des instructions pour toi." Et là, il va faire un tableau avec des markdown, des éléments. Et là, quand vous les mettez, on a un taux de réussite des requêtes qui est généralement euh meilleur. Deuxième élément qui est super important, c'est les requêtes. Exemple, faut faire des choses assez simples pour dire bah voilà, pour récupérer la moyenne des températures, c'est ici. on donne les indicateurs et après avec les instructions, il vient compléter, changer les claw et ça c'est super. Donc on peut voir qu'après on peut tester cet agent et donc là on lui a demandé de nous donner le la situation environnementale dans les différentes zones géographiques et puis il peut nous expliquer quelle température il fait à tel endroit et ensuite ben on aura pourrait très bien aller plus loin dans l'analyse et aller à bien lm lui dire est-ce que la température locale a un impact sur la l'humidité de mes capteurs et donc là bah forcément on va beaucoup plus loin dans l'analyse. On a mixé des données qui viennent de deux environnements et surtout on est capable de les mélanger via notre agent et de prendre vraiment un insight plus détaillé. Et là, tu nous montres la consommation de l'agent depuis l'interface, mais on pourrait très bien la mettre dans une application tiers ou directement dans Teams. Alors, c'est vrai. Donc là, on est plutôt dans la phase de développement mais la publication ça va nous permettre de la publier dans Copilot Studio dans le centre M365 M365. On peut le voir par le petit bouton là. Donc, c'est directement disponible de l'autre côté. et on peut très bien utiliser cet agent dans Teams pour pouvoir le consommer aujourd'hui. Donc il nous faut un utilisateur fonctionnel qui peut qui peut qui a une connaissance fonctionnelle des données et après bah on le publie pour les utilisateurs métiers qui viennent consommer ce cet agent. Donc c'est très riche euh et c'est très puissant. N'oubliez pas aussi que l'agent peut très bien publier donc MCP pour pouvoir le consommer pour dans n'importe quel enfin on est vraiment sur de l'op enfin de l'open source et d'un protal ouvert quoi. Euh si je reviens du coup sur mon Lake House euh vous avez vu que ceous là il a des tables. Il a mes tables qui sont ici disponibles. Le dernier élément, c'est de se dire bah ces tables là, je veux les partager parce que tout à l'heure on a expliqué que bah Snowflex ou Datab vont pouvoir eux partager leurs données pour l'agent, pour des use case plutôt côté fabrique. Mais la réciprocité est vraie puisque je vais pouvoir aussi partager les tables temps ell donc tout ce qui va être au data, sensor location et cetera qui ont été créés en casl depuis mon event et

32:45ensuite redescendu sur le Lake House et donc sur oneelake, je vais pouvoir partager ces tables là dans Snowflex par exemple. Donc comment faire ? Je vais sur mon mirroring Snowflex. Alors pourquoi je vais sur le mirroring Snowflex ? Là, j'ai récupéré la donnée côté Snowflex, mais c'est pour tout c'est surtout pour pouvoir me connecter à l'environnement Snowflex sous-jacent parce que si vous voyez ici, j'ai un petit bouton qui me permet d'aller directement dans mon environnement Snowflake. OK ? Et une fois que j'ai fait ça, donc j'ai pas cliqué dessus, je suis directement dessus, je vais avoir mes bases de données. Dans mes bases de données Snowflex, je vais j'ai une base de données que j'ai appelé Lake House. OK ? Qui elle, vous allez le voir pointe sur one OK ? Et en fait, qu'est-ce que vous retrouvez dedans ? exactement les mêmes tables que j'ai de de l'autre côté côté houseous côté fabrique. Voyez, c'est exactement les mêmes tables. Et si je clique dessus, je clique sur une table, bah vous allez voir que bon là c'est là du coup c'est mon compute snowflake qui va lire le fichier iceberg qui est derrière qui est sur oneelake et ben je vais avoir exactement les mêmes informations. Ce qui fait que je peux très bien utiliser cette donnée de temps réel qui est redescendue dans Oneelec au travers les mécanismes qu'on a décrit tout à l'heure sur fabrique pour ensuite les utiliser et les mettre à disposition côté Snowflex sans avoir à les copier puisque la clé de voûte est en one le partage commun entre les deux les les les deux systèmes.

Conclusion

34:09Super démo, merci. Une super architecture qu'avec certaines nouveautés de la Fabcon pourrait être enrichi. On a évoqué notamment les operation agence. Ça pourrait être intéressant de faire évoluer et aussi d'avoir les activateurs pour les alertings. Ça pourrait être intéressant. On mettra dans le lien de la vidéo le repository de Vincent avec la solution que vous pourrez redéployer chez vous. Si vous avez des questions, des retours d'expérience ou si vous souhaitez creuser un point en particulier, n'hésitez pas à nous laisser des commentaires. Encore une fois, merci Vincent, merci Marc et merci à vous d'avoir suivi cet épisode de Fardata. À très vite pour un nouvel épisode et d'ici là, abonnez-vous à la chaîne. À bientôt. Merci.