Microsoft Agent Framework

Phare Data

0:03[musique] [musique] Oh ! 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 farata, on décrypte les services de données d'analyti. Le tout avec un ton accessible, des choix techniques assumés et une touche d'airmarin. Alors que vous soyez architecte, analyste, dat engieur, 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. Si ce genre de contenu vous parle, n'hésitez pas à vous abonner. Cap sur l'épisode du jour. Aujourd'hui, j'ai le plaisir d'être accompagné par Aya et Samir pour parler d'un sujet qui monte très fort, à savoir les Microsoft agent framework actuellement en preview. Microsoft agent Framework, c'est un framework open source net et en Python pour construire et orchestrer des agents IA et surtout des workflow multiagents et pensez, je crois, tu vas nous en parler dès le début pour passer à la production. Mais pourquoi Microsoft insiste aujourd'hui euh sur une approche code first alors qu'on a déjà des outils low code pour construire ces datag ?

Une approche code-first pour construire des agents IA ?

1:20Bah effectivement Romain euh tu fais bien de poser la question pourquoi avoir une approche code force pour des agents ? Bah déjà, ça permet d'avoir un contrôle total et une personnalisation complète du comportement des agents. Ça permet également d'avoir de faire de l'expérimentation locale très facilement. C'est-à-dire qu'on va pouvoir tester le comportement de nos agents sur nos propres machines avec nos différents outils préférés, que ce soit du VS Code et cetera, sans dépendre du cloud. Également pour la partie portable, c'est-à-dire qu'un dével un un agent développé en code peut être déployé n'importe où sans limite de connecteur ou de modèles préfabriqués. Et ensuite, ça permet facilement de l'intégrer dans des pipeles CCD et de passer facilement du local et de l'intégrer dans n'importe quel cloud sans réécrire le code. Alors, on se pose la question de pourquoi jusqu'ici construire et faire évoluer des agents surmesure a-t-il été aussi difficile ? Effectivement, euh développer et passer à l'échelle d'agent personnalisés posait plusieurs problèmes. D'une part, les agents, les framework existants pour les agents étaient fragmentés. Ça veut dire qu'il fallait assembler beaucoup d'outils et d'API aux interfaces, aux formats existants, ce qui compliquait l'intégration de bout en bout. Ensuite, point important, la recherche sur les LLM et les agents évoluent rapidement et donc il y avait souvent un fossé entre la recherche et la production. On voit beaucoup émerger des des modèles multiagents dans les labos de recherche, mais comment les industrialiser les passer de façon viable à grande échelle ? Ensuite, comme on l'a dit précédemment, il y a une lenteur d'itération pour passer du local à la production. comment on peut faire du débogage local mais une fois en production la partie débogage est souvent plus laborieuse et plus et moins fluide. Enfin, on a des systèmes fermés qui offrent une extensibilité limitée. Les services managers qu'on a proposent uniquement des intégration prédéfinies et à ce jour, il est compliqué d'intégrer ses propres plugins et sa logique métier ou de se connecter à des systèmes d'entreprise vraiment spécifiques. Et enfin, dernier point, la plupart des framework open source qui sont sur le marché ne disposent pas de capacités entreprise ready. On n pas forcément d'intégration de en manière en matière de d'observabilité, de sécurité, de conformité et de gouvernance. Et donc ça ne garantit pas une traceité à 100 % sur le comportement des agents. Ouais. Donc il est vraiment pensé pour la production ready, le passage à l'échelle aussi, le le suusage. C'est exactement ça Romain. Donc merci Samir de l'avoir introduit. Aujourd'hui, ce que cherchent les organisations, c'est de construire des agents IA performants, très industrialisables et surtout sécuriser. Mais les framework qui existent aujourd'hui montrer rapidement leurs limites parce que d'un côté, on va trouver des framework qui sont très orientés tool calling. Donc, ils sont très capables d'appeler des tools, les exécuter. Mais dès qu'on va passer à des architectures multi-agents plus complexes avec des workflow, avec des exécutions longues durée, bah on va rapidement être face à des limites bah qui vont pas nous permettre de travailler comme on veut. Et d'un autre côté, on va trouver des SDK qui sont très peu compatibles entre elles. Euh dès qu'on va passer d'un SDK en autre, bah on va pas avoir les mêmes dépendances et les mêmes choses et donc bah on va pas arriver à passer en production. Euh résultat de tout ça, euh on n' pas d'observabilité. Donc suivre tout ce qu'on a déployé, avoir des ordres de monitoring là-dessus, bah ça va manquer beaucoup. On va pas avoir de garde de fou, pas de conformité parce que la complète, c'est quand même important. euh des difficultés à débugué localement et donc bien évidemment une intégration CICD très difficile et laborieuse. Et donc euh dans un monde un peu parfait, ce dont les entreprises ont réellement besoin aujourd'hui, c'est un framework qui va leur permettre en même temps de prototyper localement mais aussi de facilement passer à l'échelle et passer en production ce qu'ils ont commencé à faire. Et pour faire ça, on a besoin d'un framework qui va être sécure, gouvernable et basé sur des standards ouverts, intégrés dès le départ. Donc by design.

Microsoft propose différentes manières de créer des agents

5:15Alors, je crois que chez Microsoft, on n pas qu'une seule façon de construire des agents. On a euh copilote studio, j'imagine. Voilà, il y en a un certain nombre. Est-ce que tu peux nous faire le le tour un peu pour que ce soit plus clair ? Effectivement, Romain, tu tellement raison. Euh chez Microsoft, on va voir différentes approches pour construire des agents qui vont être compatibles à différents types de profil. Euh donc il y a pas qu'une seule manière de faire. Euh bah déjà si je commence avec un spectre un peu classique, on va avoir l'approche ce qui est Yas euh où le client va avoir un contrôle maximal sur ce qu'il est en train de construire. Il le déploie sur un containeur mais il va avoir plus de responsabilité côté infra et orchestration. Deuxième choix, ça va être plutôt le côté passe qui va nous donner une sorte d'équilibre entre la productivité et la personnalisation. Et le final, c'est le SAS avec une simplicité maximale. Ben, on a zéro code limite mais moins de contrôle et moins de personnalisation. Euh si je vais un peu dans le détail pour euh expliquer ça, typiquement euh dans Microsoft Fundy, on va avoir du développement, de l'expérimentation mais qui reste assez simple et assez facile euh basé sur le agent service. Euh après, si on regarde copilote, ça va être des agents plus orientés métier et le code pour des profils bah qui sont pas forcément très techniques, mais ils veulent quand même décrire leur agent, le déployer, commencer à le consommer très rapidement. Et alors, il se situe où le Microsoft agent framework là-dedans ? [rires] On va voir ça plus dans le détail, mais avant de passer dans ça, euh on va juste voir les différentes approches, comment elles se représentent exactement. Juste un petit preview de ce qu'il y a à l'intérieur. Donc typiquement, si je commence par le Microsoft Fundy, ben on va voir différents types d'approches qui va nous permettre d'avoir quand même une main pour personnaliser, customiser et créer des agents, on va dire très custom. Euh par contre, on va avoir aussi l'interface qui est assez facile à utiliser et qui reste des fois low code si on n pas envie de rentrer dans le détail et ouvrir le capot. Le copilote studio, bah c'est typiquement euh l'âge enfin l'âge la partie qui va permettre à au métiers de créer leurs agents très très facilement par excellence. Et là, on va juste drag and drop des tools, créer notre agent, le décrire avec des instructions et le mettre en production. Ce que vous allez comprendre et ça ça se voit ici, c'est que à chaque fois c'est les mêmes étapes mais de différentes euh on va dire différentes interfaces. On choisit un modèle, on donne des instructions et on définit des tools parce qu'un agent est composé principalement de ça. Après, tu as posé la question Romain, c'est que où est-ce qu'il se positionne le framework dans tout ça ? Mais en fait, c'est le cœur de cet écosystème. Ça va être vraiment au plein milieu de cet écosystème qui nous permet de faire plein de choses. Cet écosystème agentique qui va être autour bien évidemment de Azur et Messonderie euh mais aussi qui va nous permettre d'aller plus loin dans la réalisation et la définition des agents. Et donc là, si on veut vraiment voir l'ampleur de cet

Écosystème d'agents IA

8:15écosystème agentique, bah on parle pas seulement d'agent, mais tout ce qui est nécessaire de les faire fonctionner en condition réelle parce que c'est ça qu'on cherche en vrai. On va avoir des workflow multiagent, de la mémoire court terme et long terme. Et ça, je pense que Samir va l'expliquer un peu plus dans le détail. On va voir de l'observabilité, de la traçabilité et l'évolution. Ça c'est hyper important et aujourd'hui on le trouve pas partout. Et donc avoir des KP, des métrixes sur euh les agents une fois euh mis en production, ça va nous permettre de les faire évoluer, euh de modifier des choses qui vont les permettre d'être leur permettre d'être plus efficaces. Et sans oublier, donc c'est ça que je disais sur quoi je mettais l'accent tout à l'heure, c'est la sécurité, la gouvernance et l'identité. Donc chaque agent va être associé à une une identité un ID qui va nous permettre bah de mettre des architecture très sécurisé sans avoir des problèmes de d'accès ou autre. Bah le framework s'intègre aussi nativement avec des services Azure comme le Cosmos DB, le fabrique, le Azure et Search, euh des outils développeurs comme le GitHub, le Visual Studio pour que les développeurs soient très à l'aise à pousser leur leur changement. partager leur projet et aussi ben évidemment on parlait de standard ouvert bah typiquement ça va être compatible avec les open API du MCP et du A2A. Ça c'est vraiment quand on va construire des agents aujourd'hui c'est euh on peut pas s'en passer. Les MCP Tools ultra important et les way pour faire communiquer des agents différents entre eux. Et donc on va avoir une plateforme qui va nous permettre de faire tout ça et là-bas ça va être vraiment l'agent framework qui qui va être le cœur battant de tout ce qu'on va construire. Donc si je crée un dans Microsoft Fabrique, je peux créer des dates agents. On a enregistré une vidéo récemment sur le sujet. Tu peux le rajouter comme connaissance à ton ta agent que tu à ton agent que tu vas créer via le framework. Oui. Alors, il y a limite deux manières de faire. Il y a soit je vais l'ajouter autant que tools un mon agent et donc il va pouvoir faire appel à ce data agent sans problème. Après, je peux aussi construire mon MCP serveur qui définit ce data agent et l'appeler aussi. Aujourd'hui, on doit le faire à la main et le faire nous-même. Mais je pense sur la roadmap, ça arrive pour que le data agent soit exploitable depuis euh un MCP serveur. Et ça, ça va vraiment simplifier euh cette connexion entre les différents agents qu'on va trouver dans un écosystème euh Microsoft. Et donc l'objectif est clair, c'est vraiment d'avoir Microsoft Framework étant le cœur d'un écosystème très ouvert, très extensible et prêt à être mis déployé en entreprise sans problème. Bah maintenant que le cadre un peu il est posé, on va passer à quelque chose de plus concret. Et là Samir, il va nous expliquer plus dans le détail bah c'est quoi le Microsoft Alien Framework, qu'est-ce que ça nous permet de faire et jusqu'où on peut aller avec ce nouveau framework. Effectivement, rentrons dans le vif du sujet avec Microsoft Edent Framework.

Microsoft Agent Framework

11:19Donc, on l'a déjà un petit peu tiré juste avant. Donc c'est le service qui permet open source qui permet de construire et orchestrer des agents I intelligents. Euh bah faut savoir qu'aujourd'hui le projet est en public preview. Il sera bientôt disponible en general availability, mais euh voilà, aujourd'hui, vous pouvez l'utiliser pour euh construire vos premiers workflow d'agent et euh la generality sera disponible très très bientôt. Euh voilà, comme on l'a spécifié, on a la disponibilité d'avoir des standards ouverts, c'est interopérable avec beaucoup de beaucoup de services. Également, ça sert de pipeline pour la recherche mais c'est également compatible pour la production. Euh et command list open source. Donc c'est maintenu et développé par une très large communauté, que ce soit Microsoft, mais également à l'extérieur. Et donc c'est euh aujourd'hui la solution recommandée par Microsoft pour construire des workflow multiagents. Euh d'où vient l'émergence du projet ? Alors faut savoir qu'à la base côté Microsoft, on avait deux frameworks qui permettaient de construire des agents, des m des systèmes multiagents. Donc on avait d'un côté sémantique kernel pour ceux qui se rappellent et Autogen. Donc sémantique kernel c'était un enfin c'est toujours un SDK très complet qui permet de construire des agents uniques. C'est ça la spécificité, c'est que c'est très simple pour construire des ces agents uniques avec une grande variété de tools et que la partie multiagent, elle était possible mais elle était un petit peu difficile à mettre en œuvre. Euh, il y avait une intégration avec l'écosystème Azure qui était qui était assez simple. Donc, on pouvait l'intégrer avec la télémétrie sur du App Insight, on pouvait l'intégrer facilement avec du AI search comme A dit précédemment. Mais voilà, pour l'orchestration multiagent, c'était assez complexe. À côté de ça, on avait on a toujours autogen. Donc Autogen, c'est un framework de recherche cette fois-ci qui permet de construire des workflow multiagents cette fois-ci. Donc on a déjà des primitives qui sont disponibles dans le dans le framework qui permettent de faire de l'orchestration. Donc soit pour avoir des agents séquentiels parallèles et cetera. On reviendra après sur les différents types d'agent. Mais voilà, l'idée c'était d'avoir des euh des des primitifs qui permettaient de faire des des des chaînes d'agents directement sans avoir à à à fournir du code supplémentaire. Mais le désavantage en fait, c'est que c'était très peu intégré à à l'écosystème Azur. Donc pour gérer l'identité, la sécurité et cetera, c'était pas la solution qu'on préconisait. Tu es en train de nous dire que avant on avait deux manières de faire et la jeune framework qui est sortie après ces deux framework qui existait déjà chez Microsoft. Est-ce que tu peux nous dire un peu plus pourquoi et c'est quoi les plus qu'on va avoir en passant sur l'agent framework ? Effectivement alors euh aujourd'hui euh la solution qui est maintenue et développée par Microsoft, bah c'est Agent Framework. Et donc l'idée comme on l'a dit précédemment en fait, c'était de réunir le meilleur des deux mondes. Donc réunir les capacités de d'intégration à l'écosystème Microsoft de sémantique kernel et également la flexibilité et la simplicité de développer des orchestrateurs multiagents d'Autogen. Et donc vous verrez tout à l'heure dans la démo, c'est que aujourd'hui pour construire des workflow multiagents, ça reprend le même paradigme que Autogen. Autogen pardon. Et alors concrètement ça ressemble à quoi ce nouveau framework ? Bah très bonne question Romain. Euh tu l'as dit au début, on dispose de deux API en Python et en DNET pour bah pour développer des agents code first dans agent framework. Euh si on revient un petit peu à la manière dont le dont le framework a été pensé par les les développeurs Microsoft, euh bah le but c'était d'être le plus simple possible. Euh donc on a trois primitives principales sur laquelle on va on va greffer différentes enfin on va greffer toute la logique toute la logique des projets. Donc on a euh ce qu'on appelle lay agent donc c'est un une primitive qui permet en fait de d'abstraire la manière d'appeler l'agent. Et maintenant dans ce nouveau framework, en fait le mode de fonctionnement tourne autour de l'argent à la différence de sémantique carnel par exemple où en fait on instancia un carnel et on développait tout un tas de tout un tas de fonctionnalités autour de ce ce kernel là et en fait c'était un petit peu abstrait, c'était pas forcément intuitif. Là aujourd'hui comme on parle beaucoup d'agents d'agent donc les développeurs se sont dit de bah finalement de bah de construire cet objet agent et en fait d'intégrer tout un tas de capacité autour de cet objet. Et l'idée c'est de facilement pouvoir lui adosser un LM sans avoir à reconner toute la logique ou appeler différentes classes. Donc qu'on lui adosse un Open AI GPT5, GPT4 ou un Deepsic, euh ça va se configurer au niveau des paramètres. C'est vraiment euh simple à simple à manipuler d'un point de vue code. Euh à côté de ça, bah on adosse à l'agent ce qu'on appelle le Fred. Donc dans la mesure où on a différents types de mémoires, les mémoires court terme et long terme, euh dans le cas de la mémoire court terme, bah le Fred en fait euh est directement adossé à à l'agent. Mais dans le cas où on a des workflow qui peuvent durer plusieurs jours, où on a besoin d'avoir des réponses qui interviennent à beaucoup plus tard et cetera, bah il y a besoin d'avoir une persistance de la mémoire et c'est là qu'intervient la notion de Fred. Et donc c'est un objet à part entière dans lequel on va euh stocker le dans des bases de données qui peuvent être de différents types. La mémoire de l'agent, la mémoire long terme de l'agent. Et enfin, on a la partie tool. Donc le tool, c'est euh c'est une notion assez large en dans Microsoft. Un tool, ça peut être un serveur MCP, ça peut être un euh une une base de données. Enfin, il y a plusieurs manières de de définir un tool. Et l'idée tout simplement ça va être de d'avoir une base de connaissance qu'on va adosser à l'intelligence de l'agent. Merci Samir. Maintenant, on a très bien compris comment construire un agent quand on crée un agent à partir du MS Framework. Euh j'ai abordé tout à l'heure le sujet de pouvoir prototyper en local, faire tourner en local et ensuite pousser dans le cloud facilement. Est-ce que tu peux nous expliquer un peu plus dans le détail comment ça se passe ? Effectivement Aya, merci pour la question. Donc j'insiste sur le fait que Edent Framework a été pensé pour être local first et indépendant du cloud. Donc en pratique, ça veut dire qu'un développeur peut démarrer son agent local sur son PC, le faire tourner, le tester sur le avec le SDK de son choix. Donc que ce soit du open API ou le SDK standard Open AI, le SDK fonder donc c'est vraiment agnostique du SDK. Tu n'es pas vender loqué finalement. Non, tu n'es pas vendor loqué. C'est c'est de l'open source. Voilà, même s'il y a des intégrations Microsoft qui sont facilitées, mais dans la pratique, c'est cloud agnostic. Effectivement, super. Ensuite, le même code de l'agent qui aura été développé en local et testé pourra être développé pourra être déployé tel que tel quel sur fonder agent services dans le cloud ou sur n'importe quel autre conteneur cloud, ce soit du AWS, du GCP ou même sur du des VMAN. C'est là qu'on voit bien l'aspect cloud agnostique. Donc le framework comme on l'a dit, il est pas verrouillé à Azure ou un cloud spécifique. On peut le faire tourner voilà sur une VB, dans Cubernetes, dans AKS ou sur n'importe quel autre fournisseur que ce soit aussi bien le le radtime.net ou le runtime Python. Ensuite là sur la slide, on voit la notion donc de runtime partagé et de SDK unifié. Et donc l'idée c'est d'avoir une continuité totale entre le code qu'on exécute localement et ce qu'on déploie en production. On développe le code une fois et après on peut le déployer partout. B c'est super Samir. Maintenant on a compris comment créer un agent avec le AG Framework. On a compris comment avoir cette portabilité assez facile entre local et dans le cloud. Maintenant la question qui se pose c'est comment l'orchestration multiagent que ça se passe dans le MS Agent Framework. Est-ce que tu peux nous expliquer les différentes manières de faire ? Jent

Orchestration multi-agents

19:11framework en fait hérite comme on l'a dit précédemment de autoen pour tout ce qui est orchestration avancée d'agent. Donc là vous voyez différents schémas pour orchestrer vos agents. Donc là on peut voir que bah chaque box en fait représente un agent et il y a plusieurs manières d'orchestrer les agents de manière native via le framework. Et donc ces schémas hérites de de autogen comme on l'a dit précédemment tout en bénéficiant des workflow durables de sémantique kernel. Ça veut dire que par-dessus ces agents, on va pouvoir connecter des couches d'observabilité, de sécurité, d'identité et voilà et intégrer vraiment tout l'écosystème Azure. Alors, est-ce que tu peux rentrer un peu dans le détail par exemple dans séquentiel ? Est-ce que c'est l'agent A qui va appeler un agent B alors que concurrent c'est l'orchestrateur qui va envoyer des infos à à certains agents ? Est-ce que tu peux rentrer dans le détail ? Euh effectivement, tu as une bonne intuition euh Romain. Euh il y a plusieurs patterns qui qui existent au sein du framework. Donc on va rentrer dans le détail de chacun des patterns. Euh pour la partie séquentielle effectivement tu as eu la bonne intuition. Donc là c'est des agents qui travaillent à la chaîne. Donc on a voilà c'est vraiment le pattern le plus simple on a un on commence par donner une tâche à un premier agent qui va produire un résultat. Ce résultat va être transmis au second agent qui va continuer le travail et cetera jusqu'au dernier agent qui va produire un résultat. Et donc à chaque agent, comme on le voit ici, on peut le on peut leur adosser des tools, des modèles, des bases de connaissance. Et l'idée en fait, c'est que euh l'état global du workflow est partagé. Ça veut dire que euh bah tous les agents en fait euh ont accès à la à une mémoire partagée. Bah, le mode de d'orchestration un petit peu euh opposé à celui qu'on vient de voir précédemment qui était le séquentiel, bah c'est le mode concurrent. C'est un petit peu la même analogie que ce qu'on pour ceux qui ont des cours de d'électricité à l'école entre le branchement en série et le branchement en parallèle. Euh l'idée ici c'est on va avoir un premier agent orchestrateur à qui on va envoyer une entrée et en fait les différents agents euh voilà ici on a l'agent 1 jusqu'à l'agent N vont recevoir la même instruction en même temps en parallèle. Et euh l'idée bah ça va être qu'ils vont devoir prêter la même instruction et chaque agent en fait va être spécialisé dans une Ouais. chacun avec leur expertise et après et après comment tu fais pour euh pour corréler finalement ces différents résultats ? Bah après l'idée ça va être qu'on va avoir un comme la mémoire va être partagée entre les entre ces différents agents, on va être en mesure d'agréger les résultats produits par ces différents agents et de et en fait d'avoir une réponse agrégée d'experts qui va être retourné à la suite. OK ? C'est l'idée et ça ça ira dans le sens de la démo tout à l'heure. Vous verrez que la démo reprendra ce pattern là. Le mode de fonctionnement suivant, le pattern suivant donc c'est le groupe chat. Donc le groupe chat, c'est quoi ? Faut essayer d'imaginer ça comme un peu un débat. Donc dans un débat, qu'est-ce qu'on a ? On a un personne qui organise le débat et qui donne la parole à à différentes personnes et qui veilleent à ce que le les temps de paroles soient équilibrés, à couper la parole à la personne qui qui parle, à demander des suppléments d'information, à interroger la bonne personne en fonction du contexte. Ben, c'est exactement l'idée qu'on va avoir ici. Donc on a un agent qu'on appelle groupe chat manager qui est l'agent orchestrateur et en fait va il va décider de de donner la parole à un agent en fonction de son domaine de compétence et c'est lui qui va un petit peu guider l'orchestration de comment on comment on interagit et comment le le les échanges se font entre les différents agents et il pourra être capable de couper la parole à un agent si les informations vont pas dans le bon sens à demander des informations supplémentaires et cetera. Alors, le mode suivant donc c'est le hand of pattern. C'est un dérivé de celui qu'on a vu précédemment. Euh l'idée c'est quoi ? Ça va être de faire de de la délégation dynamique de contexte en fonction de la spécification la spécificité de l'agent qui va être capable de bah de répondre à la à la question posée posée par l'agent précédent. Je m'explique, c'est un mode qui est principalement utilisé dans le cadre du support. Supposons voilà que vous ayez un ticket à soumettre à à une à un système de ticket. Le premier agent qui va être l'agent de premier niveau va pas être capable de répondre à la question. Donc qu'est-ce qu'il va faire ? Il va agréger les informations que vous allez lui donner et va lui et va les soumettre à l'agent de niveau 2. L'agent de niveau 2 va chercher à répondre à la question. Il va être plus spécialisé dans certaines tâches techniques, on va dire. Et s'il peut pas répondre, il va déléguer l'agent niveau 3 et cetera. Donc on peut avoir plusieurs niveaux. Et une fois que bah l'agent un agent à un certain niveau a réussi à répondre, qu'est-ce qu'il va faire ? Bah il va retourner ça à il va retourner résultat tout simplement. Donc voilà, tout simplement l'idée c'est d'avoir une délégation de contexte et de et de voilà de contexte en fonction de la de la difficulté du prompt qui a été soumis au au système multiagent. Et enfin, le dernier pattern qui est le plus complexe et le plus à la fois le plus complexe mais le plus facile à se représenter, c'est celui qu'on appelle le magtic pattern. Donc là, l'idée en fait, c'est d'avoir une orchestration multiagent qui est dans un cas où le problème à résoudre est ouvert et complexe. C'est une sorte de combinaison, enfin d'une version plus avancée du groupe chat qu'on a eu précédemment et du handoff combiné. Donc là, l'idée en fait, c'est qu'on a pas de plan défini à l'avance. comme on l'a vu précédemment, bah c'était l'exemple, c'était pour résoudre des tickets. Donc là, c'est des tâches qui sont assez définies et et dont on connaît l'output et l'input. Donc on est capable de d'avoir un plan en fait. Mais dans le cadre du dans le cadre du mattic pattern, l'agent manager qu'on voit à l'écran euh ou qu'on appelle aussi gestionnaire va construire la stratégie de résolution des des problèmes au fur et à mesure du du de la réflexion. Donc l'idée ça va être de recueillir des informations et d'affiner progressivement en fonction des objectifs. Euh l'autre terme qu'on peut donner bah c'est le c'est en fait on appelle ça un task ledger et il fait une liste dynamique de ce qu'il faut faire et évolue en fonction des retours de l'agent. Si vous êtes euh si vous utilisez euh chat GPT ou d'autres solutions comme ça, généralement quand vous posez une question assez complexe, vous voyez des petits message qui s'affiche euh dans l'écran euh de de recherche pendant que ça pendant que ça mou déjà les étapes qui va avoir à faire à traiter, c'est ça en réel. Exactement. Ouais. Et c'est sur ce même principe là que fonctionne ce pattern là. Et donc quand est-ce que tu vas choisir un pattern plus qu'un autre ? Euh bah le choix du pattern va dépendre du cas d' usage tout simplement. Euh bah on l'a vu précédemment, si vous êtes dans des cas de résolution de tickets, c'est un cas qu'on rencontre beaucoup aujourd'hui dans le bah dans dans le cadre de notre travail de CSA. La recommandation qu'on faite, bah c'est souvent le hand of pattern, mais dans les cas où euh où on on est censé avoir des des orchestrations assez déterministes et séquentielles, ça revient souvent. Ça veut dire une fois qu'on a une une sortie, bah transmettre cette sortie à l'agent suivant et cetera. Bah là, on va recommander par exemple l'agent séquentiel. Donc le choix se fait en fonction du cas d'usage du client et de la manière de dont on souhaite implémenter le la solution.

Outils et extensibilités

26:45Merci Samir. En tout cas, moi je trouve hyper intéressant tous les choix qu'on a en terme de pattern dans le framework parce qu'on passe de quelque chose qui était très basique avec soit un orchestrateur qui va avoir des sous-agents collaborateurs ou juste un agent spécialiste. Mais là, on a vraiment des choses plus efficaces et plus détaillées. Après, des agents intelligents n'ont de valeur que s'ils peuvent agir dans un écosystème d'information existant. Donc avec le MSCGN Framework, tout peut que ce soit des fonctions, des API, des services internes ou des serveurs MCP, euh l'objectif est simple, c'est de pas repartir de zéro quand on va construire notre agent. Euh bah on va avoir des intégrations déjà prêtes à l'emploi avec les systèmes d'entreprise, les bases de données, les SAS et les API un peu standard. Et puis l'agent peut être défini de manière un peu déclarative. Donc par exemple en Yamul euh on peut préciser quel outil nécessite la validation humaine. Typiquement dans la résolution de ticket, on peut avoir besoin de cette validation et le human in the loop. Euh et après on va le but c'est aussi de garder la flexibilité au développeur pour qu'ils puissent profiter de cet écosystème qui est hyper riche en terme de tools et de fonction. Mais d'ailleurs, j'ai parlé de quelque chose d'important au tout début. Euh c'est la l'importance d'avoir du monitoring et du tracing euh sur nos agents encore plus quand on a une architecture multi-agent. Et pour ça, je vraiment que tu m'expliques Samir comment ça se passe avec le MS Agent Framework. Euh effectivement, bah merci pour la question A. Donc euh effectivement, la télémétrie, c'est très important. Bah, de savoir euh euh quelles sont les réponses des agents, quand est-ce que les agents ont craché, euh quel est le coût de mes agents finalement parce qu'il y a il y a toute cette partie aussi euh monitoring des coûts qu'on a pas abordé. Euh et donc l'idée c'est déjà d'avoir on a beaucoup parlé d'interopérabilité donc déjà d'avoir l'intégration avec un un framework interopérable qui est open télémétrie euh voilà qui est un framework open source qui permet de connecter euh énormément de de services à à cet outil là pour bah pour en fait avoir de la télémétrie provenant de différentes différents canaux. Donc il y a cette connexion entre cette intégration d'open télémétrie au au à Microsoft et John Framework. Et là bon, on va un petit peu prêcher pour notre paroisse. Bah là c'est des screens de app. Et donc l'idée c'est c'est qu'on est capable une fois les span open télémétrie collectés bah de les envoyer dans appinite et après de faire du du logging assez classique pour aller euh lancer des requêtes KQL pour aller vérifier euh ce que telle telle ou telle requête a donné et cetera. Euh les coûts voilà comme on a dit bah avoir toute la toute cette partie tracing comme on le voit à l'écran. C'est parfait, très clair. Je pense maintenant on a fait le tour, on a beaucoup parlé mais on aimerait bien voir ça, voir de plus concret une démo. Voilà.

Demo

29:45Bah allons-y pour la démo. Euh commençons par une un petit schéma d'architecture pour vous expliquer ce qu'on va montrer lors de cette démo. Euh bah l'idée voilà, c'est de montrer les capacités de Microsoft Agent Framework bien sûr. Et bah ce que je voulais démontrer c'était d'utiliser l'un des patterns qu'on a eu précédemment. Donc ici le pattern euh concurrent euh comment ça va fonctionner ? Bah, on va se mettre dans la peau d'un voyageur. Euh voilà, on veut organiser un trip de plusieurs jours et on a besoin de d'avoir des informations pour de vols, savoir quel vol on va prendre en fonction de de nos contraintes, quel hôtel on va réserver et quel itinéraire on va on va choisir. Donc ces trois agents là, la sélection des vols, le choix des hôtels et la partie itinéraire, elle peut être fait de manière concurrente. Ça veut dire on n pas besoin d'attendre le retour de de de l'agent hôtel pour lancer l'agent Flight. Donc l'idée ça va être quoi ? ça va être de au sein du pattern de de concurrent, bah en fait de lancer ces trois agents en même temps, de collecter les réponses et après derrière bah de retourner le la réponse agrégée de ces trois agents pour avoir une réponse structurée de comment le voyage va s'organiser, de l'itinéraire qu'on va faire et des des vols qu'on va réserver de et des hôtels qu'on va réserver également. Euh donc on a instancier trois agents. Donc la démo, je l'ai faite en local. Voilà, pour vous montrer que tout est tout est développable en local. Euh à chacun des agents, enfin aux deux premiers agents, j'ai adosser des serveurs MCP. Donc pour la partie euh flights, donc je ne suis pas passé par des API internet, mais j'ai simulé des des des vols. Donc j'ai inventé des vols, je vous montrerai tout à l'heure. Et pour la partie hôtel, par contre là, je me suis appuyé sur un vrai serveur MCP. Donc, j'ai créé un compte sur Serpi, qui permet d'aller récupérer des données de d'hôtel sur sur Google. Et euh et après l'idée en fait, ça va être par rapport au contexte qu'on va fournir à l'agent, bah d'aller récupérer les bonnes informations des hôtels par rapport à des prix ou des des des contraintes que j'aurais fixé et en fonction des nuits et des contraintes que j'aurais fixé, bah de me recommander les bons hôtels et cetera. Et enfin bah sur la partie itinerary adjent là c'était juste pour vous montrer la capacité en fait d'avoir un un local tool et donc de lancer une fonction pé python en local. Voilà. Donc là j'ai ouvert vs code. Donc euh bah j'ai repris un petit peu l'architecture qu'on a présenté précédemment. Donc j'ai mes deux scripts qui instancent mes deux serveurs MCP. Ici, on regardera le contenu tout à l'heure. Et là, c'est la fonction main en Python qui bah qui va définir toute la logique euh du workflow d'agent euh concurrent et donc après bah qu'on va exécuter pour avoir le retour. Donc là, si on rentre dans le détail, j'ai mes différents imports. Voilà, donc sans Python, hein, on voit bien. Donc là, j'importe du pas identique. Euh sur Ad Framework, bah j'apporte le chat adjunent qu'on a vu précédemment qui est le bah en fait qui permet de définir le client chat. Et à ça, je vais adherosser mon LLM. Euh le concurrent de builder, donc c'est le pattern qu'on a eu précédemment qui permet de de définir un workflow de d'agent concurrent, euh la partie MCP et euh le le monol local qui va exécuter une fonction Python quand le LLM va juger que c'est nécessaire de l'appeler et après derrière elle va retourner du code Python. Et donc on est d'accord là quand tu as appelé le concurrent builder dans ton agent framework, ça va dépendre aussi de l'architecture ou le pattern que tu as choisi. Typiquement si j'ai choisi le séquentiel euh j'allais appeler séquentiel builder à la place. Exactement. Euh c'est ça ? Ouais. Euh donc là je le client euh Azure que j'utilise enfin le client euh de de de chat qu'utilise donc c'est le open Ail. Donc là c'est ma fonction ma ma fonction locale qui permet de construire mon itinéraire. Donc en gros ce qu'elle prend elle prend l'itinéraire. Donc là c'est le donc là c'est le prompt que j'ai défini en entrée. Donc c'est le parcours le roetrip que j'ai essayé de faire. Donc là, on l' retrip en fait, c'est à Seattle. Donc on va partir du principe que je vais à Seattle en avril pendant 5 jours. Et donc il y a différents endroits que j'ai envie de visiter. Donc il y a le marché au poisson pour ceux qui connaissent euh pour aller manger du street food et cetera. Euh voilà. Donc là c'est les différentes choses que j'ai envie de visiter. Euh Space Needle le jour 2. Donc ça c'est le jour 1. Le jour 2 aller voir Space Needle pour avoir une vue sur la ville et le et la vue sur le Montraigné. Euh également voir le musée euh et manger à Capital Hill qui est un quartier un peu un peu un peu festif. Euh jour 3, donc c'est aller faire une petite excursion en nature. Donc voilà, j'ai envie d'aller faire une randonnée et d'avoir une vue panoramique sur le lac et après voilà, j'ai d'autres activités le jour 4 et 5. Et donc l'idée de mon workflowage antique, bah ça va être de reprendre un petit peu ce ce plan ce plan de de de visite que j'ai mis et avec les API de euh pour aller voir chez les hôtels en fait, d'aller d'aller récupérer des hôtels qui sont à proximité de ces lieux-là et de me faire des recommandations de nuit pour pour avoir mon roipp qui est bien prévu. Donc voilà. Donc ça c'est ma fonction qui va me retourner le voyage à Seattle avec le nombre de jours et cetera. Sachant que bon là, j'ai défini déjà le voyage, j'aurais pu être bien moins précis, j'aurais pu mettre un plan bien plus bien plus général, large. Ouais, large. Et voilà. Et laisser le LLM en fait me faire des suggestions de de lieu à visiter. Mais là, j'ai fait le choix en fait de bah des des lieux que j'allais visiter tout simplement. Donc là, c'est mon tout le local que j'ai défini. Euh voilà. Bon, là, c'est juste une petite fonction parce que les outputs sont un peu bruts. Donc là, c'est juste pour parcer un peu la l'output qu'on aura sur le sur le le terminal. Voilà. Bon, je vais vite sur cette partie là. Et donc là, on rentre dans la partie main. Donc les donc c'est comment le l'orchestration va se faire entre mes agents. Donc voilà, là c'est la définition de mon de mon chat API. Donc c'est très très simple. J'ai juste à définir donc ça c'est une fonction de framework. J'ai juste à instancier mon client chat euh et après lui passant à paramètre ma clé API, mon modèle. Donc là c'est un GPT 5 mini de mémoire et mon endpoint open AI. Donc là, le modèle est hébergé sur fonderie. Donc j'ai construit enfin j'ai déployé mon modèle sur fonderie. Donc, j'ai ma clé, mon déploiement et ma et mon endpoint et je les passe en paramètres dans mon dans mon dans mon fichier d'environnement qui est ici. Euh là, je définis donc mes serveurs MCP, donc la partie MCP pour le les hôtels. Euh donc ce qu'il va faire c'est qu'il va aller appeler donc les ce fichier qui est ici en pardon ici. Euh et donc comme j'ai dit tout à l'heure en fait c'est des vols fictifs que j'ai placé pour ne pas aller appeler des API l'API Google par exemple mais directement récupérer via une une fausse base de données en fait des des des vols. Donc là j'ai simulé des vols voilà un vol Air France de de Charles de Gaul la Seattle à un certain prix d'une certaine durée et cetera. Donc voilà, il y a plein de vols que j'ai simulé et également des vols retour. Et donc le but en fonction des paramètres que je vais spécifier de bah c'est de va d'aller récupérer le bon vol. Par exemple, voilà, si je spécifie que j'ai pas envie d'avoir d'escal, bah le but enfin le LM en fait va être capable de me recommander le bon vol avec sans escal par exemple. Donc on est d'accord là, tu as choisi de simuler ton ta base de données directement dans ton fichier. On aurait eu le choix soit d'aller taper dans une base de données externe qui elle contient tous ces informations ou d'aller chercher directement dans des sites dans des sites web qui ont ces informations aussi. Exactement. Euh il y a des enfin les il y a pas mal d'APIs structurés qui permettent de faire le bah d'aller récupérer des des informations de vol, mais j'ai préféré voilà pour euh pour des besoins de simplicité en fait de de de le simuler. Mais je l'ai pas j'ai pas fait ça pour la partie hôtel. pour la partie hôtel, je suis vraiment allé récupérer euh j'ai instancié une clé serpi. Donc Serpay, c'est un service qui permet d'aller euh récupérer différentes informations sur le net, notamment tout ce qui va être euh Google Hotel et en fait d'aller récupérer des informations sur des hôtels avec des dates de checkin et cetera. Donc là, lors de lors de l'excusion de la démo en fait, ce sera des vraies informations sur des vrais hôtels que qu'on va récupérer. Donc là, ce sont mes deux serveurs MCP qui que j'instancie. Euh là, c'est juste pour vérifier qu'il tourne que qu' tourne bien. Donc on passe par HTTP pour les pour les exécuter. Donc voilà, là c'est je fais des ping sur les serveurs. Euh et donc là, ce sont mes deux agents, donc l'agent Flight et l'agent hôtel comme j'ai dit tout à l'heure. Donc là, voilà, c'est le prompt. tu es un agent de recherche de vol, tu dois absolument utiliser des outils MCP pour rechercher des vols parce que il y avait des petits des petits effets de bord tout lors de mes tests. Euh voilà, donc un vol CDG Seattle et Seattle CDG euh présente les ressources sous cette forme là, compagnie vol et cetera. Donc voilà, soit concis. Voilà, donc ça c'est du prompt engineering assez classique. Et pour reprendre un petit peu le l'intérêt de d'ent framework, donc vous voyez que c'est très simple. Donc j'instancie mon agent avec le chat agent, je lui donne un nom, euh je récupère le client open API que j'ai défini juste audessus, open API pardon, j'ai Open AI pardon, que j'ai défini juste au dessus. Euh et après je lui passe en tool le flight MCP que j'ai défini ici. Et donc voilà. Donc là, j'ai mon agent avec son modèle et ses tools et c'est tout. Voilà, c'est assez rapide à instancier. Ouais, c'est ce qu'on se disait au début, enfin ce qu'on expliquer au début, c'est que ça reste assez basique. On définit des instructions, un modèle, des tools pour construire notre agent. C'est ça. Euh, ça c'est le deuxième sur les hôtels. OK. Ouais. Ouais. Même paradig pour les hôtels. Donc même logique, sauf que j'appelle le tout MCP.

40:39Et sur la partie itinéraire euh bah là en fait euh bon là c'est vraiment le plus simple possible puisque j'ai déjà défini l'itinéraire donc il y a pas vraiment de de de recherches qui vont être qui vont être faites. J'ai déjà ma ville, j'ai déjà mon nombre de jours. Là je spécifie un peu les intérêts. Donc j'ai envie de goûter la nourriture locale, la nature, la technologie et cetera. Et je lui dis comment un petit peu formuler la sortie. Donc voilà, là c'est euh assez contraint mais voilà, c'est juste pour vous montrer que il est capable d'aller appeler des fonctions Python euh dans le code. Et la magie opère ici. Donc là, je définis mon concurrent de builder euh qu'on a défini lors des imports de fonction. Donc là, c'est le pattern séquentiel euh euh euh parallèle, pardon. Euh je définis bah les différents participants qui vont interagir en parallèle, donc mes trois agents, le flight, l'hôtel et le l'itinéraire. Euh je dis d'agréger les résultats sous la forme d'un d'une réponse. Euh et après bah là c'est pour construire le le workflow. Et après derrière ce workflow, je vais l'appeler un peu plus bas euh ici. Voilà, de manière asynchrone puisque les agents trôent de manière asynchrone. Et là, c'est la requête, le prom enfin le point d'entrée sur tout le workflow où j'explique voilà que je veux aller à Seattle en avril 2026 depuis Paris le 10 avril, retour le 15 avril avec ce budget avec un prix un coût d'hébergement maximum de 150 dollars par nuit et que j'ai envie et que je suis intéressé par ces différentes choses. Donc voilà, vous voyez que l'orchestration est enfin la logique est assez simple et là il y a le main. Donc là, juste pour vous montrer, j'ai mes deux serveurs MCP qui tournent ici. Donc là, le MCP Flight et le MCP euh Proxy euh pardon hôtel. Et donc mon script qui permet de d'exécuter toute cette toute cette logique. Je vais la lancer. Voilà, Samoline. Donc voilà. Donc on fait la vérification que les serveurs MCP sont bien fonctionnels. Donc les deux les deux répondent. Ils sont ils tournent sur les ports euh 8001 et 8002. Et donc là, j'ai mes trois agents qui travaillent en parallèle. Donc le serveur local euh enfin le le la partie euh tool locale euh celui qui va récupérer les vols par ici et celui qui va récupérer les données Google Serpay. Ça c'est des données réelles. Est-ce qu'il se partage des informations entre eux ? C'est-à-dire que j'ai déjà trouvé l'hôtel, donc je vais peut-être trouver l'itinéraire par rapport à ça ou non ? Là, c'est vraiment en parallèle et c'est à la fin que je vais consolider le résultat. Ouais, c'est exactement ça. C'est à la fin que les résultats sont consolidés. OK. Donc ici, on a le format final output qui va être injecté plus bas et donc qu'on va qu'on va récupérer. Euh voilà, qui va qui va nous permettre en fait d'avoir le la réponse finale par rapport au par rapport au modèle. Et donc là, j'ai bien la réponse. Donc là, si je reviens au début, voilà, comme je dis, j'ai parcé un peu les réponses pour que ce soit un peu lisible. Voilà. Euh donc voilà, là c'est mes 5 jours, il me fait mes recommandations de vol. Euh aller retour. Donc j'ai été assez large sur le choix mais j'aurais pu spécifier sans escal avec escale. J'aurais pu mettre dans le promte que je veux pas d'escale. Euh là il me fait les recommandations par rapport au prix puisque je lui ai dit qu'en fait je voulais que ça coûte pas trop cher. Donc il m'a recommandé les vols des moins chers si je vérifie bien sur les hébergements. Donc là là c'est des vraies données de d'hôtel en fait. Euh là, si on vérifia au niveau du serveur MCP, on voit qu'il a fait des vraies requettes. Euh là, si je suis bien, non, c'est l'autre. Il a fait des vraies requêtes à à Serpaper récupérer les données des hôtels. Euh voilà. Donc là, il me fait des recommandations pour les différentes pour les différents jours et il me donne des notes et des descriptions. Donc là, par exemple, il me recommande ce cet hôtel pour la première nuit, c enfin là, il fait pardon différentes recommandations d'hôtel. et à la fin, il me fait les trois meilleures recommandations par rapport au critères. Donc c'est le prix surtout que j'ai que j'ai où j'ai été strict et euh et voilà. Et là, il reprend un petit peu ce que j'avais dit par rapport au par rapport au au séjour. Donc effectivement, ça c'était assez contraint. Voilà, jeais bien dit que je voulais PL Market le premier jour, Space Tindle. Donc là, il a pas eu à inventer mais j'aurais pu être beaucoup plus large et voilà, j'aurais pu le laisser me faire mon road trip quoi. Ouais, là tu es un peu restreinte la créativité, on va dire, du modèle pour te proposer quoi que ce soit. ton prend enfin tes instructions elles ont été très très précises et là on revient à une problématique enfin une problématique quelque chose de très majeur les instructions qu'on va donner à nos agents sont primordiales et c'est ça qui va avoir enfin des résultats plus ou moins bons selon nos attentes. Exactement. Toute la partie prompt engéering est est cruciale pour ce genre de pour ce genre de travaux. Super. Donc là, on rappelle he tu es en local mais on a dit que c'était une grande force de ce framework que de pouvoir passer à l'échelle et en production rapidement. Alors, quelles seraient les prochaines étapes si tu voulais l'industrialiser ? Bah effectivement, si je veux l'industrialiser, donc d'une part, il y a la partie télémétrie dont on a parlé où en fait on va être l'idée, ça va être de bah d'envoyer des logs euh que ce soit sur fonder ou sur n'importe quel n'importe quel cloud, n'importe quel conteneur qui exécute les agents à distance. Euh et l'idée euh d'un point de vue code, c'est très simple. On va avoir des des classes qu'on va pouvoir importer sur la partie télémétrie qui hérite de edge framework. Et en fait, ça va juste être des des des fonctions de wrapping qu'on va placer dans le code. Donc typiquement euh on va être capable de de de lui dire euh récupère-moi le nombre de tokens qui a été consommé. Enfin, par défaut, il va afficher le nombre de tokens qui a été consommé, les différents appels des agents, des tools et en fait toutes ces donnéesl vont être stockées automatiquement. Et bon là, comme on est dans le cadre Microsoft, j'ai fait des enfin j'ai fait des exemples sur fonderie. Euh les informations sont envoyées directement dans votre projet fonderie euh dans votre projet fonderie et après derrière vous pouvez les les retrouver et cliquer dessus sur l'onglet tracing de votre projet fonderie pour ceux qui sont familiarisés. Et directement sur ces informations là, vous avez bah les les cols qui ont été réalisées, le temps des requêtes, les requêtes qu'on fail et cetera. Donc toute cette partie-là, elle est elle est intégrée directement. Ah super Samir pour la démonstration.

Conclusion

47:26C'était vraiment très très intéressant de voir ça de près de voir tout ce que tu as construit avec MS Framework. Et en fait, on a compris que euh ce qui nous imp ce qui nous apporte exactement, c'est un socle unifié, assez ouvert, orienté développeur euh et surtout prêt pour l'entreprise. Donc ça nous permet de passer de cette expérimentation locale à la production sans vraiment avoir de rupture. Euh tu nous as parlé aussi de la partie observabilité open télémétrique qu'on va avoir sur nos projets fonderies quand on va les partager. Et donc l'objectif c'est pas seulement de construire des agents mais c'est vraiment d'avoir cette véritable plateforme qui est capable d'évoluer, de s'intégrer avec tout l'écosystème existant. Donc en résumé, on va avoir moins de friction, plus de contrôle et une voie assez claire pour industrialiser les agents IA à grande échelle dans la vraie vie. Super. Ben merci beaucoup à vous deux. N'hésitez pas en commentaire à poser des questions ou à nous dire ce que vous en pensez de vos premiers tests de la solution du framework qui est actuellement en preview, on peut le rappeler. Merci Aya, merci Samir pour cet échange et super démo. On vous dit à bientôt sur la chaîne Fardata. À bientôt. Merci. À bientôt.