Season 7 15 Épisodes 50 min 2026

Microsoft Copilot Studio

Édition 2026. Une plongée technique approfondie dans Microsoft Copilot Studio, couvrant la Generative Orchestration, les Agent Flows, les Tools, l'Enterprise Grounding, et bien plus encore (2026).

Frameworks AI/ML Orchestration LLM Prototypage visuel

🌐 English 🇪🇸 Español 🇫🇷 Français 🇵🇹 Português 🇮🇹 Italiano 🇵🇱 Polski 🇩🇪 Deutsch 🇷🇴 Română

Lecture en cours

Click play to start

0:00

Generative Orchestration

Découvrez le changement de paradigme, des phrases de déclenchement classiques à la Generative Orchestration dans Microsoft Copilot Studio. Apprenez comment l'IA sélectionne dynamiquement les Topics et les Tools en fonction des descriptions, éliminant totalement le besoin d'un mappage conversationnel rigide. Cet épisode explique comment le routage intelligent gère sans effort les requêtes à intentions multiples.

3m 21s

Création d'agents basée sur l'IA

Apprenez à utiliser le langage naturel pour accélérer le processus de création de votre bot. Nous explorons la création d'agents basée sur l'IA, qui vous permet de générer des Topics, des Prompts et des Flows complexes simplement en les décrivant. Comprenez comment les LLMs sont utilisés au moment de la conception (build-time) pour prototyper rapidement des agents.

3m 07s

Topics et Nodes

Plongez dans l'anatomie structurelle d'un agent. Cet épisode détaille les System Topics par rapport aux Custom Topics, ainsi que la logique déterministe des Nodes requise pour des règles métier spécifiques. Apprenez à tracer des parcours conversationnels précis à l'aide de variables et de conditions.

3m 30s

State et Variables

Donnez une mémoire à votre agent. Découvrez comment travailler avec les Variables dans Copilot Studio pour transmettre le contexte entre les Topics, éliminant ainsi les questions répétitives. Nous explorons également l'utilisation des variables d'environnement pour stocker en toute sécurité les secrets d'Azure Key Vault.

3m 32s

Entities et Slot Filling

Extrayez des données structurées à partir d'un langage naturel non structuré. Cet épisode explique les Prebuilt Entities, les listes fermées personnalisées, les Regex Entities et la magie du Proactive Slot Filling, qui permet à l'IA d'ignorer des questions lorsque l'utilisateur fournit des informations à l'avance.

3m 45s

Enterprise Knowledge Grounding

Transformez vos données d'entreprise existantes en un expert conversationnel. Apprenez à connecter SharePoint, Dataverse et des sites web publics comme sources de connaissances pour les Generative Answers. Découvrez les limites et les capacités du Grounding de votre IA.

3m 22s

Tenant Graph Grounding

Libérez toute la puissance de Microsoft Graph et de la recherche sémantique pour une récupération de haute précision. Cet épisode explore le Tenant Graph Grounding, en utilisant les licences Microsoft 365 Copilot pour rechercher dans des documents d'entreprise massifs avec une compréhension sémantique profonde.

3m 18s

Prompt Tools

Donnez à votre agent la capacité d'effectuer des tâches spécifiques de traitement de données ou de résumé à la volée. Apprenez à concevoir des Prompt Tools, à définir des templates, à spécifier des entrées et à configurer des formats de réponse directement dans Copilot Studio.

3m 15s

Agent Flows

Faites le pont entre Copilot Studio et des automatisations backend complexes à plusieurs étapes en utilisant les Agent Flows. Cet épisode détaille comment ajouter des flux Power Automate en tant que Tools, en mettant l'accent sur la limite critique d'exécution de 100 secondes et les exigences de réponse synchrone.

3m 25s

Power Platform Connectors

Exploitez des milliers d'APIs existantes dans les écosystèmes Microsoft et tiers. Découvrez comment utiliser les Power Platform Connectors comme Tools actifs dans vos agents Copilot Studio pour interagir avec des services externes sans effort.

3m 40s

Le Computer Use Tool

Automatisez les systèmes hérités dépourvus d'APIs grâce à l'automatisation basée sur la vision. Découvrez la version preview du Computer Use Tool, qui exploite des modèles comme Claude Sonnet 4.5 pour interagir avec des interfaces utilisateur graphiques via une souris et un clavier virtuels, le tout avec des garde-fous de sécurité d'entreprise.

3m 21s

Authentification des utilisateurs

Sécurisez votre agent et débloquez des expériences personnalisées. Plongez au cœur de l'authentification des utilisateurs dans Copilot Studio, en comparant 'Authenticate with Microsoft' aux configurations OAuth2 manuelles. Apprenez à configurer les scopes et à garantir un accès au moindre privilège.

3m 19s

Voix et IVR

Faites passer votre agent du clavier à la ligne téléphonique. Découvrez les capacités de réponse vocale interactive (IVR) de Copilot Studio. Apprenez-en plus sur la reconnaissance vocale, le DTMF (entrées au clavier), le barge-in et la personnalisation des voix des agents avec SSML.

3m 26s

Agent Analytics

Vous ne pouvez pas améliorer ce que vous ne mesurez pas. Cet épisode détaille le tableau de bord Analytics dans Copilot Studio, en expliquant la vue hybride pour les sessions conversationnelles par rapport aux sessions autonomes, et comment exporter les transcriptions pour une analyse approfondie.

2m 58s

Model Context Protocol

Préparez vos agents pour l'avenir avec le standard ouvert pour le contexte de l'IA. Apprenez à intégrer Copilot Studio avec des serveurs Model Context Protocol (MCP) externes pour ingérer dynamiquement des Resources, des Tools et des Prompts.

3m 33s

Épisodes

Generative Orchestration

3m 21s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 1 sur 15. La plupart des développeurs de bots passent des heures à essayer de prédire et de mapper chaque phrase qu'un utilisateur pourrait taper. Tu ajoutes cinquante variantes d'une requête de support, et le système plante quand même quand quelqu'un tape une phrase que tu n'avais pas anticipée. La Generative Orchestration élimine complètement ce besoin en utilisant le matching dynamique de descriptions. Souvent, quand on entend le mot génératif dans ce contexte, on suppose que ça veut dire générer du texte conversationnel. Ce n'est pas le cas ici. La Generative Orchestration concerne uniquement le routing dynamique et la sélection de tools. C'est l'intelligence qui décide de l'action à prendre, plutôt que de juste écrire une réponse. Dans l'orchestration classique, tu crées un topic et tu définis manuellement une liste de trigger phrases. Le moteur de compréhension du langage naturel s'appuie sur ces phrases exactes pour router l'utilisateur. La Generative Orchestration supprime complètement les trigger phrases. À la place, tu écris une description claire en plain-text pour chaque topic et tool de ton agent. Le large language model sous-jacent lit la query de l'utilisateur, évalue toutes tes descriptions disponibles, et détermine dynamiquement le meilleur match. Tu ne mappes plus des inputs à des triggers. Tu décris simplement ce que font tes tools. Ça change complètement la façon dont un agent gère les inputs complexes. Prends l'exemple d'un utilisateur qui demande : Quel temps fait-il à Seattle et à quelle heure ouvre le magasin ? Dans un setup classique, ça plante. Le système détecte deux intents contradictoires et soit il en devine un, soit il renvoie une erreur de fallback. La Generative Orchestration gère ça sans effort. Le modèle parse la phrase entière et reconnaît deux buts distincts. Il scanne tes descriptions. D'abord, il trouve un tool météo. Il extrait Seattle de la query de l'utilisateur, le passe au tool météo comme paramètre d'input, et l'exécute. Ensuite, il se souvient de la deuxième moitié du prompt de l'utilisateur. Il scanne à nouveau tes topics, trouve celui décrit comme gérant les heures d'ouverture du magasin, et le trigger. Voici le point clé. L'agent chaine ces actions ensemble automatiquement. Il gère la requête météo, puis fait une transition fluide vers le topic des heures d'ouverture, en combinant les résultats. Tu n'écris aucune logique de routing ou de code de transition pour que ça arrive. Ce changement signifie que la qualité de ton agent dépend maintenant entièrement de la qualité de tes descriptions. Si la description de ton tool météo dit simplement météo, le modèle pourrait avoir du mal à router précisément. Si la description dit récupère les conditions météo actuelles pour un nom de ville spécifié, le routing devient exact. En plus, si un utilisateur trigger ce tool météo mais oublie de spécifier la ville, le moteur génératif remarque automatiquement qu'un paramètre requis est manquant. Il va générer dynamiquement une question pour demander la ville à l'utilisateur avant d'exécuter le tool. Ce que tu dois retenir, c'est ça. La Generative Orchestration transforme le routing d'un exercice fragile de phrase-matching en une recherche intelligente de capacités, te libérant pour te concentrer sur ce que ton agent peut faire au lieu de deviner comment l'utilisateur va le demander. Si tu veux soutenir l'émission, tu peux nous trouver en cherchant DevStoriesEU sur Patreon. C'est tout pour celui-ci. Merci d'avoir écouté, et continue de builder !

Création d'agents basée sur l'IA

3m 07s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 2 sur 15. D'habitude, construire un flow conversationnel implique de glisser-déposer des nodes sur un canvas, de câbler manuellement des arbres logiques et de deviner chaque trigger phrase possible que ton utilisateur final pourrait taper. Mais et si tu pouvais juste dire à une IA exactement ce que tu veux construire, et la laisser générer la logique structurelle pour toi ? Ce mécanisme s'appelle l'authoring d'agent basé sur l'IA. Il est crucial de distinguer ça du comportement de l'IA au runtime. Les devs confondent souvent l'IA générative au build time avec l'IA générative au runtime. Le runtime, c'est quand un utilisateur en direct pose une question et que l'agent génère dynamiquement une réponse en utilisant une base de connaissances externe. L'authoring au build time, c'est complètement différent. C'est quand tu utilises un assistant IA dans le studio pour construire le framework statique de l'agent lui-même. Tu commences dans le canvas d'authoring. Au lieu de cliquer pour ajouter des éléments un par un, tu interagis avec le panneau d'authoring de Copilot. Imaginons que tu aies besoin d'un flow pour gérer les retours de matériel. Tu tapes une description en langage naturel qui demande un topic interrogeant l'utilisateur sur son numéro de commande, vérifiant si l'article est un laptop ou un appareil mobile, puis fournissant la bonne adresse de retour selon le type d'équipement. Quand tu soumets ce prompt, le modèle de compréhension du langage naturel traite tes instructions et les mappe directement sur le schéma de nodes interne de Copilot Studio. Il génère automatiquement un ensemble de trigger phrases variées qu'un vrai utilisateur pourrait dire pour lancer ce flow spécifique. Il place un node de question sur le canvas pour capturer le numéro de commande et lui assigne une variable. Il crée un node de condition pour brancher la logique entre un laptop et un appareil mobile. Ensuite, il remplit les nodes de message finaux avec des adresses de retour en placeholder. Tout le squelette du topic apparaît instantanément sur ton écran. Voici le point clé. Ce processus d'authoring est strictement itératif. Tu n'es pas obligé d'accepter la génération initiale comme produit final. Si tu regardes le flow généré et que tu te rends compte que tu dois capturer la date d'achat, tu n'as pas besoin de casser manuellement les connexions et d'insérer un nouveau node. Tu dis simplement au Copilot d'authoring d'ajouter une question qui demande la date d'achat juste avant de demander le numéro de commande. Le modèle sous-jacent analyse l'état actuel de ton canvas, comprend le point d'insertion séquentiel, et modifie le flow en toute sécurité. Comme l'IA traduit le langage naturel directement en composants standard de Copilot Studio, tu gardes un contrôle total sur l'architecture. Les nodes générés ne sont pas des boîtes noires. Ce sont exactement les mêmes éléments que tu aurais créés manuellement. Tu peux cliquer dans les branches de condition, ajuster les types de variables, ou réécrire le texte du prompt à la main. Le modèle de langage gère simplement l'assemblage mécanique du canvas. La vraie puissance de l'authoring basé sur l'IA, ce n'est pas d'écrire des flows conversationnels parfaits du premier coup, mais de transformer le processus mécanique et lent du câblage de nodes en un dialogue rapide sur l'intention métier. Merci d'avoir écouté. J'espère que tu as appris quelque chose de nouveau.

Topics et Nodes

3m 30s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 3 sur 15. Même les agents IA les plus avancés finissent par avoir besoin d'une logique déterministe pour des règles métier spécifiques. Quand un client te pose une question sur ta politique de retour ou tes horaires d'ouverture, tu ne peux pas te permettre une estimation probabiliste d'un modèle de langage. Tu as besoin d'une réponse stricte et garantie. Les topics et les nodes t'offrent exactement ce contrôle structurel. Imagine un topic comme un chemin de conversation distinct. C'est un arbre de dialogue prédéfini qui dicte exactement comment ton agent gère une intention spécifique. Ton agent global est essentiellement une collection de ces topics qui travaillent ensemble pour router l'utilisateur. Un point de confusion fréquent, c'est la distinction entre les System topics et les Custom topics. C'est plus simple qu'il n'y paraît. Les System topics gèrent les comportements de base de l'agent. Ils régissent les événements centraux comme saluer un utilisateur, terminer une conversation, escalader vers un humain, ou catcher une erreur quand l'agent ne comprend pas l'input. Tu peux modifier leur texte pour coller à la voix de ta marque, mais tu ne peux pas les supprimer. Ils font partie intégrante de l'architecture du système. Les Custom topics sont les chemins que tu construis toi-même, entièrement sous ton contrôle, pour gérer tes scénarios métier spécifiques. À l'intérieur de chaque topic, la conversation s'exécute de haut en bas à travers des étapes individuelles appelées nodes. Les nodes sont les briques de construction fonctionnelles du chemin. Pour comprendre comment ils interagissent, imagine un Custom topic conçu pour gérer les demandes sur les horaires d'ouverture. Quand l'utilisateur déclenche ce topic, la première étape de ton flow pourrait être un Question node. Un Question node prompt l'utilisateur pour obtenir des informations et attend un type de réponse spécifique. Dans ce cas, l'agent demande quelle ville l'utilisateur compte visiter. Quand l'utilisateur répond, le node capture cette réponse. C'est là qu'intervient la gestion des variables. Le Question node stocke automatiquement la réponse de l'utilisateur dans une variable. Tu as maintenant un state distinct en mémoire, ce qui te permet de router la conversation dynamiquement en fonction de ce que l'utilisateur vient de dire. C'est là que ça devient intéressant. Au lieu de renvoyer une réponse générique, tu ajoutes un Condition node pour évaluer cette variable. Un Condition node agit comme un embranchement logique. Il vérifie le state actuel de ta variable par rapport aux règles que tu définis. Si la ville stockée est New York, le node dirige le flow vers une branche. Si la ville est Londres, il dirige le flow vers une autre. Tu peux ajouter autant de branches que tu veux pour différents states, plus une branche de fallback si la variable ne correspond à aucune ville connue. Enfin, à la fin de chaque branche conditionnelle, tu places un Message node. Un Message node affiche simplement du texte ou un média à l'utilisateur. La branche New York atteint un Message node indiquant que le magasin ouvre à neuf heures du matin. La branche Londres atteint un autre Message node indiquant que le magasin ouvre à dix heures. En chaînant les nodes Question, Variable, Condition et Message, tu dictes exactement le déroulement du flow logique. Ce qu'il faut retenir de plus important ici, c'est que les topics isolent tes règles métier déterministes dans des chemins prévisibles, garantissant que ton agent réponde de manière fiable quand la précision compte plus que la génération. Merci d'avoir écouté. À la prochaine !

State et Variables

3m 32s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 4 sur 15. Le moyen le plus rapide de frustrer un utilisateur, c'est de le faire répéter une info qu'il vient de te donner. Si ton bot demande un nom, déclenche un nouveau workflow, puis redemande le nom, l'expérience utilisateur est complètement cassée. Le mécanisme qui empêche cette amnésie, c'est le state et les variables. Dans Copilot Studio, une variable stocke des données extraites de l'utilisateur ou récupérées depuis un backend. La décision la plus importante que tu prends quand tu crées une variable, c'est de définir son scope. Les auditeurs confondent souvent les variables de niveau topic avec les variables globales. Une variable de niveau topic est strictement locale. Elle n'existe que tant que son topic parent est actif. Dès que ce topic se termine, la variable est effacée de la mémoire. Une variable globale, par contre, persiste pendant toute la durée de la conversation. N'importe quel topic peut la lire, et n'importe quel topic peut l'écraser. C'est tentant de faire de chaque donnée partagée une variable globale. Ne fais pas ça. Abuser des variables globales crée des changements de state imprévisibles quand les topics s'interrompent entre eux. À la place, passe les variables locales directement entre les topics. Imagine un topic qui s'appelle Greeting. Il demande son nom à l'utilisateur et le stocke dans une variable locale. Le greeting se termine, et le flow redirige vers un nouveau topic appelé Talk to Customer. Pour transférer le nom, tu configures le topic Talk to Customer pour qu'il reçoive des valeurs d'autres topics. Tu définis une variable d'input sur ce topic de destination. Ensuite, de retour dans ton topic Greeting, le node de redirection va automatiquement te demander de mapper une valeur à cet input. Tu passes la variable locale du nom à travers le node. Le topic de destination la récupère, le bot continue la conversation avec le bon nom, et ton state global reste propre. Quand ce topic de destination a fini son boulot, il peut aussi renvoyer des valeurs au topic appelant d'origine en utilisant des variables d'output. Ça, ça couvre les données générées pendant un chat. Maintenant, la deuxième partie concerne les données dont ton agent a besoin avant même qu'un chat ne commence. Si ton agent se connecte à des systèmes externes, il a besoin de credentials. Tu ne dois absolument jamais stocker de clés d'API ou de connection strings dans des variables de conversation. Pour ça, tu utilises des variables d'environnement. Les variables d'environnement vivent complètement en dehors de la session utilisateur. Elles stockent des données de configuration qui s'appliquent à l'agent lui-même, ce qui te permet de passer ton bot d'un environnement de développement au testing, et enfin à la production, sans hardcoder de valeurs. Fais bien attention à ça. Quand tu manipules des données très sensibles, les variables d'environnement s'intègrent directement avec Azure Key Vault. Au lieu de coller un mot de passe dans Copilot Studio, tu crées une variable d'environnement marquée comme secret. Cette variable stocke une référence vers une clé spécifique dans ton Azure Key Vault. Pendant le runtime, l'agent récupère le secret de manière sécurisée pour authentifier la requête backend. Le secret n'est jamais exposé dans le canvas d'édition, il n'est jamais affiché dans les logs du chat, et il est exclu de tes exports de source control. Le state le plus sûr est un state scopé, donc garde les variables de conversation locales autant que possible, passe-les explicitement entre les topics, et délègue toujours les credentials système à des variables d'environnement sécurisées. Merci d'avoir écouté, et happy coding tout le monde !

Entities et Slot Filling

3m 45s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 5 sur 15. Tu crées un bot pour prendre des commandes, mais il force les utilisateurs à passer par cinq questions fastidieuses. L'utilisateur t'a déjà donné tous les détails dans son premier message, pourtant ton bot ignore ce contexte et continue de les demander un par un. Ce comportement rigide frustre les utilisateurs, et c'est exactement le problème que résolvent les Entities et le Slot Filling. Les Entities, c'est ce qui permet à Copilot Studio de reconnaître des sujets du monde réel à partir d'un langage naturel un peu brouillon. Vois une Entity comme un data type spécifique que ton bot est entraîné à repérer dans une phrase. Au lieu d'analyser toute la phrase, je voudrais dépenser vingt balles, l'IA cherche simplement l'Entity money et extrait la valeur vingt. Copilot Studio est livré avec un grand nombre de prebuilt entities. Elles gèrent les concepts de data standards out of the box. Les prebuilt entities reconnaissent l'âge, les dates, les couleurs, les nombres, les noms et l'argent. Elles normalisent la data automatiquement. Que l'utilisateur tape vingt dollars, le signe dollar suivi de 20, ou vingt balles, la prebuilt entity money extrait la valeur numérique exacte et la devise. Mais ton business fonctionne avec une terminologie spécifique. Pour capter ça, tu crées des custom entities. Il y a deux types principaux de custom entities que tu vas utiliser. Le premier, c'est la closed list entity. Tu définis une liste stricte d'items autorisés, et ensuite tu attaches des synonymes à chaque item. Si tu vends du matériel de plein air, tu peux créer une Entity de catégorie de produit avec un item principal appelé randonnée. Tu ajoutes ensuite des synonymes comme trekking, backpacking et marche sur sentier. Quand l'utilisateur tape l'un de ces synonymes, l'IA mappe son input directement vers la valeur principale randonnée. Le deuxième type custom, c'est l'Entity d'expression régulière, ou regex. Tu utilises les regex entities quand les utilisateurs doivent fournir des strings formatées plutôt que des mots spécifiques. Un use case courant, c'est un ticket de support ou un order ID. Si ton système utilise des numéros de tracking qui commencent toujours par les lettres TRK suivies de cinq chiffres, tu définis ce pattern en utilisant une regex. L'IA va scanner le message de l'utilisateur et extraire proprement cette string exacte, en ignorant tout le texte autour. Identifier l'Entity n'est que la première étape. Tu dois stocker cette data pour l'utiliser. Cette action s'appelle le Slot Filling. Tu mappes une Entity extraite à une variable, ce qui remplit le slot avec la data de l'utilisateur. C'est là que ça devient intéressant. Copilot Studio utilise une feature appelée proactive slot filling. Par défaut, le moteur de compréhension du langage naturel évalue chaque message utilisateur par rapport à toutes les variables que ton topic de conversation requiert. Si l'IA détecte les Entities requises dans l'input initial de l'utilisateur, elle remplit ces slots immédiatement. Prends l'exemple d'un utilisateur qui déclenche ton topic d'achat en disant, je veux acheter des chaussures de randonnée à moins de 100 dollars. Tu as une custom closed list entity pour la catégorie de produit, et tu utilises la prebuilt entity money pour le budget. Grâce au proactive slot filling, l'IA traite toute la phrase d'un coup. Elle isole randonnée, la mappe à ta variable de catégorie, et la stocke. Elle isole 100 dollars, la mappe à ta variable de budget, et la stocke. Comme ces slots sont déjà remplis, le bot skippe automatiquement les nodes de question, quelle catégorie cherches-tu, et, quel est ton budget. Le flow de conversation passe directement par-dessus et va directement à la prochaine information manquante. En définissant des Entities strictes et en faisant confiance au proactive slot filling pour gérer l'extraction, tu arrêtes d'écrire des arbres de décision rigides et tu commences à builder des agents conversationnels qui respectent le temps de l'utilisateur. C'est tout pour cet épisode. Merci de ton écoute, et keep building !

Enterprise Knowledge Grounding

3m 22s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 6 sur 15. Avant, le plus dur quand tu créais un agent conversationnel, c'était de prédire chaque question de l'utilisateur et d'écrire les réponses à la main. Tu passais des semaines à mapper des arbres de dialogue, juste pour que les utilisateurs demandent un truc un peu hors script et se retrouvent dans une impasse. Enterprise Knowledge Grounding renverse complètement ce modèle. Au lieu d'écrire les réponses, ce sont tes données d'entreprise existantes qui font tout le gros du travail. Un large language model générique s'exprime super bien, mais il ne connaît absolument rien de ton entreprise spécifique. Enterprise Knowledge Grounding comble ce vide en connectant le copilot directement à tes vraies données métier, comme des sites web publics, des répertoires SharePoint, des fichiers uploadés et des tables Dataverse. Prends un scénario de support client. Tu as besoin d'un agent qui répond aux questions sur ton hardware. Au lieu de créer des centaines de custom topics, tu uploades tes manuels produits en PDF dans le copilot et tu colles l'URL de ton site de documentation public. Quand un utilisateur demande comment reset un modèle de routeur spécifique, le copilot cherche dans ces sources connectées, récupère le texte pertinent et synthétise une réponse directe. Il fournit aussi un lien de citation vers le manuel ou la page web spécifique, pour que l'utilisateur puisse vérifier l'information. Un point de confusion fréquent, c'est de savoir où vit exactement cette knowledge dans l'architecture. Tu peux attacher la knowledge à deux endroits distincts : au niveau de l'agent ou au niveau du topic. La knowledge au niveau de l'agent est globale. Elle agit comme un filet de sécurité sur tout le copilot. Si un utilisateur pose une question et qu'aucun topic écrit à la main n'est déclenché, le système fait un fallback sur ce pool global de knowledge. Il cherche dans toutes tes sources connectées au niveau de l'agent pour générer une réponse. Ça veut dire que tu obtiens de la valeur immédiate sans écrire de flows de conversation custom. Voici le point clé. Parfois, tu as besoin d'un contrôle strict sur les données que l'IA utilise, et c'est là que la knowledge au niveau du topic entre en jeu. Tu configures ça en glissant un node Generative Answers directement dans le canvas d'édition d'un custom topic spécifique. Si un utilisateur déclenche un custom topic pour traiter une demande de garantie, tu ne veux pas que l'IA tire ses réponses de ton site web marketing général. En utilisant un node Generative Answers à l'intérieur de ce topic spécifique, tu peux restreindre sa source de données exclusivement à un dossier SharePoint qui contient les documents légaux de garantie. L'IA est scopée exactement au contexte de cette étape de la conversation. Quand tu connectes ces sources d'entreprise, le système gère les accès de façon intelligente. Pour les sites web publics, le copilot indexe simplement les pages publiques. Pour les sources internes comme SharePoint, le copilot utilise les credentials Entra ID de la personne qui interagit avec le bot. Il respecte strictement les permissions de fichiers existantes. Si un employé n'a pas accès à un document interne spécifique dans SharePoint, le copilot ne lira pas ce document, et il ne l'utilisera pas pour répondre à sa question. Pour les données structurées, tu peux te connecter directement aux tables Dataverse, ce qui permet au copilot d'ancrer ses réponses dans les records en live de tes applications métier. Utiliser un node Generative Answers dans un custom topic te permet de contrôler étroitement les limites exactes de la knowledge de l'IA à des moments précis d'une conversation, pour éviter que des données globales trop larges ne viennent polluer des workflows très spécifiques. C'est tout pour cet épisode. Merci de ton écoute, et continue de builder !

Tenant Graph Grounding

3m 18s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 7 sur 15. La recherche par mots-clés standard atteint ses limites dès qu'un utilisateur pose une question nuancée sur une politique interne. Tu n'as pas besoin de meilleurs mots-clés. Il te faut un système capable de comprendre le sens réel de la question à travers des datasets massifs. C'est exactement là qu'intervient le Tenant Graph Grounding. Le Tenant Graph Grounding apporte une compréhension sémantique profonde directement à tes données d'entreprise. D'abord, clarifions une idée reçue. Ce n'est pas une recherche Dataverse standard, et ça n'a rien à voir avec le scraping de sites web publics. C'est une fonctionnalité avancée de retrieval d'entreprise qui connecte ton copilot directement à Microsoft Graph. Elle est conçue spécifiquement pour gérer les connaissances internes complexes stockées à travers ton tenant. Pour utiliser cette feature, ton environnement doit répondre à quelques prérequis stricts. Tu as besoin d'une licence Microsoft 365 Copilot. Tes données doivent être indexées par le Semantic Index pour Copilot. Et surtout, ton copilot doit être configuré avec l'authentification Microsoft Entra ID. Ce n'est pas optionnel. Le copilot doit transmettre de manière sécurisée l'identité de la personne qui pose la question à Microsoft Graph. Prends l'exemple d'un copilot RH interne conçu pour chercher dans des manuels d'employés massifs. Ces manuels se trouvent souvent sur SharePoint ou OneDrive sous forme de documents volumineux. Les outils de retrieval standards plantent souvent sur les gros fichiers, mais le Tenant Graph Grounding supporte des tailles de fichiers allant jusqu'à 512 mégaoctets. Quand un employé pose une question sur un scénario très spécifique, comme la politique de congé parental pour un second parent travaillant à temps partiel, un moteur de recherche traditionnel va chercher ces mots exacts. Si le manuel utilise une formulation différente, la recherche échoue. Voici le point clé. Parce que cette feature utilise le Semantic Index, elle mappe les relations conceptuelles entre la query de l'utilisateur et les données de l'entreprise. Elle comprend que la query sur le congé parental correspond conceptuellement à une section intitulée temps libre en famille, même si les mots-clés ne s'alignent pas parfaitement. Le flow logique s'exécute entièrement dans la limite sécurisée de ton tenant. Un utilisateur soumet un prompt au copilot. Le copilot utilise le token Entra ID de cet utilisateur spécifique pour requêter Microsoft Graph. Microsoft Graph cherche ensuite dans le Semantic Index, mais il ne regarde que les fichiers que cet utilisateur spécifique a déjà la permission de lire. Si un document est restreint, le Graph l'ignore tout simplement pour cet utilisateur. Le Graph récupère les correspondances sémantiques très pertinentes et les renvoie au copilot. Le copilot utilise ensuite ces chunks de données exacts pour générer une réponse précise et sourcée. La transaction entière se fait avec une précision quasi instantanée, contournant la latence et l'imprécision d'essayer de builder tes propres index de recherche custom sur des données SharePoint. Le Tenant Graph Grounding transfère toute la charge de retrieval de ta logique custom directement sur l'infrastructure sémantique de Microsoft 365, garantissant que ton copilot respecte les limites des données d'entreprise existantes tout en offrant une précision contextuelle inégalée. Si tu veux soutenir l'émission, tu peux retrouver DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci pour ton écoute, et continue de builder !

Prompt Tools

3m 15s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 8 sur 15. Parfois, tu n'as pas besoin de créer une API complexe ou d'intégrer un service de parsing externe pour traiter les données entrantes. Tu as juste besoin d'un large language model pour analyser une string désordonnée et la traiter exactement comme tu le veux. C'est là qu'interviennent les Prompt Tools. D'abord, on doit clarifier un point qui porte souvent à confusion. Les Prompt Tools sont complètement différents des Generative Answers. Les Generative Answers scannent une knowledge base externe ou un site web pour répondre dynamiquement aux questions des utilisateurs. Les Prompt Tools ne cherchent pas de réponses. Ce sont des instructions spécifiques et très travaillées qui disent à un large language model d'exécuter une tâche strictement définie sur les données que tu fournis. Vois un Prompt Tool comme une fonction réutilisable où la logique sous-jacente est écrite en langage naturel au lieu du code. Tu le construis en définissant un prompt template, en spécifiant des variables d'input, et en fournissant des règles de contexte strictes. Prends un scénario courant. Tu reçois un bloc de feedback client non structuré et décousu. Tu veux extraire le sentiment sous-jacent et générer une liste propre d'action items spécifiques. Au lieu d'écrire des expressions régulières complexes ou un script de parsing custom, tu crées un Prompt Tool. Tu commences par définir les inputs. Dans Copilot Studio, tu crées une variable d'input appelée feedback text et tu définis son data type. Cette simple étape dit à l'outil de s'attendre à une string dynamique à chaque fois qu'il est invoqué par le système. Ensuite, tu écris le prompt template. C'est le set d'instructions principal envoyé au language model. Tu décris précisément ce que le modèle doit faire. Tu lui donnes l'instruction de lire la variable feedback text, de déterminer si le ton est positif, négatif ou neutre, et d'identifier les tâches que l'équipe de support client doit gérer en fonction du texte. Voici le point clé. Le template est pratiquement inutile sans un contexte strict. Tu ne te contentes pas de demander le sentiment au modèle en espérant qu'il réponde gentiment. Tu définis la structure d'output exacte dans le contexte du prompt. Tu donnes l'instruction explicite au modèle de renvoyer le résultat formaté comme un objet JSON strict contenant une clé sentiment et un array action items. Tu interdis tout remplissage conversationnel. Ce contexte transforme une réponse générique et bavarde du language model en un payload de données structuré et prévisible, que tes systèmes en aval peuvent réellement parser. Quand ton agent déclenche ce tool pendant une conversation en direct, le flow d'exécution est entièrement automatisé. L'agent prend la réponse en direct du client et la passe dans ton input feedback text. Le tool injecte dynamiquement cette string dans ton template, envoie le package d'instructions complet au modèle, et te renvoie le JSON structuré. L'agent peut ensuite utiliser ces action items extraits pour mettre à jour automatiquement une base de données ou router l'utilisateur vers une file d'attente de support spécialisée. Tu définis le tool une seule fois, et l'agent l'appelle automatiquement dès qu'il reconnaît le besoin de traiter du texte non structuré. Un Prompt Tool bien conçu déplace la charge du traitement de texte complexe de ton code applicatif vers le language model, te permettant d'extraire des données parfaitement structurées à partir d'un chaos total en utilisant juste quelques lignes d'anglais simple. C'est tout pour cette fois. Merci de ton écoute, et continue de développer !

Agent Flows

3m 25s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 9 sur 15. Ton agent doit exécuter un workflow backend complexe qui s'étend sur plusieurs systèmes. Il doit peut-être interroger une base de données isolée, filtrer les données et mettre à jour un système d'inventaire, le tout en même temps. Un seul API call ne peut pas gérer cette orchestration. La solution, c'est un Agent Flow. Les Agent Flows font le pont entre Copilot Studio et Power Automate. Ils te permettent de packager une automatisation multi-étapes sous forme d'outil autonome que ton agent peut déclencher tout seul. L'agent se base entièrement sur le nom et la description que tu fournis pour le flow. En se basant sur ce texte, l'agent décide si le flow peut résoudre la requête actuelle de l'utilisateur. Quand il trouve une correspondance, l'agent extrait les paramètres nécessaires de la conversation, les passe au flow, attend l'exécution, et utilise l'output final pour générer une réponse. La structure d'un Agent Flow est stricte. Il doit commencer par un trigger spécifique conçu pour Copilot, qui définit explicitement les inputs de type texte ou nombre. Il doit se terminer par une action spécifique qui répond à Copilot, en définissant les outputs de type texte ou nombre. Tout ce qui se trouve entre ces deux nodes, c'est de la logique Power Automate standard. Tu peux boucler sur des arrays, appeler des custom connectors, ou parser des fichiers. Imagine un scénario où ton agent doit récupérer l'historique des commandes depuis une base de données SQL legacy. L'utilisateur demande ses commandes récentes. L'agent déclenche le flow, en passant la string de l'ID client en input. À l'intérieur du flow, tu construis la logique pour te connecter à la base de données SQL, exécuter la query, et formater les lignes brutes de la base de données en une string JSON propre. Le flow renvoie ensuite cette string formatée à l'agent via le node de réponse. L'agent lit la string, extrait les détails de la commande, et répond à l'utilisateur en langage naturel. Voici le point clé. L'exécution doit être entièrement synchrone. L'agent initie le flow et garde la connexion ouverte, en attendant la réponse. Si tu construis un flow asynchrone, ça ne marchera pas comme outil pour l'agent. Tu ne peux pas inclure d'étapes qui mettent la logique en pause. Si ton flow envoie un e-mail d'approbation et attend qu'un humain clique sur un bouton, l'agent va planter. Le pattern de l'outil exige un retour immédiat des données. Ça nous amène à une limite système stricte. Tu as exactement cent secondes. À partir du moment où l'agent déclenche le flow, la logique a cent secondes pour exécuter chaque étape, faire la query sur la base de données, formater l'output, et renvoyer la réponse. Si le serveur SQL legacy est surchargé, ou si ton flow itère sur trop d'enregistrements, l'exécution va dépasser la limite de timeout. Quand ça arrive, l'agent coupe complètement la connexion et renvoie un message d'erreur à l'utilisateur. Pour gérer cette limite, tu dois garder le scope de l'automatisation très restreint. Si un process backend prend cinq minutes, ne le fais pas tourner à l'intérieur de l'Agent Flow. Utilise plutôt le flow pour lancer un background job externe et renvoyer immédiatement un ID de tracking à l'agent. Ton architecture d'automatisation doit respecter la fenêtre de timeout. Conçois tes flows pour qu'ils s'exécutent rapidement, récupèrent exactement ce qui est nécessaire, et rendent le contrôle à l'agent, pour t'assurer que l'utilisateur ne se retrouve jamais à parler à une connexion bloquée. C'est tout pour cette fois. Merci de ton écoute, et continue à builder !

Power Platform Connectors

3m 40s

Télécharger

Bonjour, ici Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 10 sur 15. Tu passes des jours à écrire et à maintenir des intégrations d'API custom juste pour que ton agent puisse parler avec le monde extérieur. Pendant ce temps, des milliers de wrappers préconstruits dorment déjà dans ton environnement, prêts à être exécutés. Aujourd'hui, on s'intéresse aux connecteurs Power Platform. Les connecteurs sont des wrappers d'API standardisés. Ils offrent à Microsoft Copilot Studio un moyen prévisible de communiquer avec des services externes. Avant de voir comment ils fonctionnent, on doit dissiper une confusion fréquente. Les utilisateurs confondent souvent le fait d'utiliser un système externe comme source de connaissances, et le fait de l'utiliser comme un tool. Si ton agent interroge une base de données juste pour récupérer des faits et ancrer ses réponses conversationnelles, c'est de la connaissance passive. Utiliser un connecteur comme tool, c'est différent. C'est une opération active. Tu donnes à l'agent l'autorité d'exécuter des actions, de créer des records, ou de déclencher des process externes pour le compte de l'utilisateur. Il y a trois catégories de connecteurs disponibles. Les connecteurs standards couvrent les services Microsoft de base et les endpoints publics courants. Les connecteurs premiums nécessitent une licence spécifique et se connectent à des systèmes d'entreprise comme Salesforce ou ServiceNow. Si le système que tu dois joindre est une API propriétaire interne, tu peux créer un custom connector. Un custom connector, c'est juste un wrapper OpenAPI que tu définis toi-même. Une fois enregistré dans ton environnement, il se comporte exactement comme les standards et les premiums. L'agent se fiche de savoir qui l'a construit. Regardons comment cette logique s'articule avec un scénario concret. Tu veux que ton agent compile un résumé de projet et l'envoie par e-mail à ton équipe d'ingénierie. Au lieu de construire manuellement une requête HTTP, tu ajoutes le connecteur Office 365 Outlook directement dans ton copilote en tant qu'action. Chaque connecteur expose des opérations spécifiques. Dans ce cas, tu sélectionnes l'action pour envoyer un e-mail. C'est la partie qui compte. Tu n'écris pas de code procédural pour dicter exactement quand cet e-mail part. À la place, tu définis les paramètres dont le connecteur a besoin pour fonctionner. Le connecteur Outlook a besoin d'une adresse de destination, d'un objet et du body du message. Tu configures ces inputs et tu fournis une description claire, en langage naturel, de ce que fait l'action. Copilot se base entièrement sur cette description pour déterminer quand déclencher le tool. Quand un utilisateur dit à l'agent d'envoyer le point de statut hebdomadaire à l'équipe d'ingénierie, l'agent évalue ses tools disponibles. Il fait correspondre la requête de l'utilisateur à la description de ton connecteur Outlook. L'agent extrait ensuite dynamiquement le nom du destinataire et le texte du résumé depuis la conversation en cours. Il mappe ces valeurs extraites sur les inputs du connecteur et déclenche l'action. Une fois que l'API externe a traité la requête, le connecteur renvoie une réponse à l'agent. Ça peut être un simple code de succès ou un payload avec des détails spécifiques sur la transaction. L'agent reçoit ces données, vérifie que l'action a été complétée, et génère une réponse en langage naturel pour dire à l'utilisateur que l'e-mail a été envoyé. En standardisant l'interface, ces wrappers suppriment le besoin de gérer les tokens d'authentification, les headers et l'error handling pour chaque service individuel. Tu configures la connexion une fois, et l'agent orchestre l'exécution. Les connecteurs transforment ton agent d'une interface conversationnelle statique en un tool opérationnel qui modifie réellement l'état à travers ton infrastructure. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Le Computer Use Tool

3m 21s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 11 sur 15. Si une application n'a pas d'API, l'automatisation traditionnelle se heurte à un mur. Soit tu écris des scripts fragiles qui cassent dès qu'un bouton bouge, soit tu acceptes la saisie manuelle des données. L'outil Computer Use résout ça en permettant à ton IA de voir littéralement l'écran et d'utiliser la machine elle-même. Disponible en preview, cette feature permet à ton agent d'interagir avec une UI graphique en utilisant une souris et un clavier virtuels. Elle repose sur des Computer-Using Agents, propulsés par des modèles de vision comme Claude 3.5 Sonnet d'Anthropic. Il faut bien clarifier ce que ce n'est pas. Ce n'est pas de la Robotic Process Automation traditionnelle. La RPA standard s'appuie sur des hooks structurels sous-jacents, comme des tags DOM ou des IDs d'éléments d'UI. L'outil Computer Use fonctionne entièrement sur les pixels. Le flow logique est une boucle continue. L'outil prend une capture d'écran de l'environnement desktop et la passe au modèle. Le modèle analyse le layout visuel, raisonne sur la requête de l'utilisateur, et calcule les coordonnées précises pour son prochain mouvement. Il renvoie des instructions au système. Le système les traduit pour déplacer le curseur virtuel vers une position X et Y spécifique, cliquer sur un bouton de la souris, ou envoyer une string de frappes clavier. Après avoir exécuté l'action, l'outil prend une autre capture d'écran pour évaluer le nouvel état de l'écran, en vérifiant si une fenêtre s'est ouverte ou si du texte est apparu, avant de décider de sa prochaine étape. Imagine un scénario où tu dois extraire des données d'une application desktop Windows legacy et les entrer dans un formulaire web moderne. L'agent regarde la capture d'écran de l'app legacy, localise visuellement le numéro de facture, et stocke cette information. Il renvoie ensuite des instructions pour déplacer la souris vers la fenêtre du navigateur, cliquer dans le champ cible du formulaire web, et taper les chiffres. Il navigue dans l'interface exactement comme le ferait un opérateur humain, guidé entièrement par le contexte visuel à l'écran. Donner à un modèle d'IA le contrôle physique d'un desktop nécessite des contrôles de sécurité stricts. Voici le point clé. Tu ne déploies jamais ça sur un serveur de production ou sur la workstation principale d'un utilisateur. L'agent doit opérer dans une machine virtuelle ou un container dédié et isolé. Tu accordes à cet environnement le minimum absolu de privilèges requis pour accomplir la tâche spécifique. Parce que le modèle peut naviguer sur des navigateurs web tout seul, tu dois appliquer des contrôles réseau stricts. Tu appliques une allow list d'URL pour que l'agent ne puisse accéder qu'aux domaines approuvés, l'empêchant d'interagir avec des sites web non fiables ou des services externes. Tu t'assures aussi que la machine virtuelle ne contient aucune donnée sensible en dehors du workload immédiat. En traitant l'interface graphique comme un simple flux d'input visuel, tu combles le fossé entre le raisonnement intelligent et les logiciels legacy inaccessibles, sans écrire une seule ligne de code d'intégration. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !

Authentification des utilisateurs

3m 19s

Télécharger

Bonjour, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 12 sur 15. Un agent est seulement aussi puissant que les données auxquelles il a accès. Mais si ton agent interroge un système privé et affiche accidentellement ton calendrier personnel à un tout autre employé, tu as une faille de sécurité massive. Pour éviter ça, tu dois configurer correctement l'authentification utilisateur. L'erreur la plus courante que font les développeurs ici, c'est de confondre les credentials fournis par le maker avec les credentials de l'utilisateur final. Si tu intègres tes propres API keys ou tes credentials de service principal dans une action de l'agent, le bot exécute ces actions en ton nom. Chaque personne qui discute avec l'agent contournera ses propres limites de sécurité et accédera aux données en utilisant tes permissions. L'authentification utilisateur force l'agent à exécuter les queries exactement comme la personne qui tape le prompt, en se basant entièrement sur son identité unique. Dans Copilot Studio, tu choisis principalement entre deux états d'authentification : Authenticate with Microsoft, et Authenticate manually. Authenticate with Microsoft est la voie la plus simple pour les outils internes. Si ton agent opère exclusivement dans Microsoft Teams ou Power Apps, ce paramètre utilise automatiquement le token Microsoft Entra ID de la personne actuellement connectée à l'application. Il n'y a pas de login prompt séparé. Le user context est simplement transmis à l'agent. Tu passes à Authenticate manually quand ton agent est hébergé sur un site web externe personnalisé, ou quand tu as besoin d'un contrôle strict et granulaire sur les permissions. Cette méthode repose sur la configuration d'une connexion OAuth2 à un fournisseur d'identité, qui est généralement une App Registration dans Microsoft Entra ID. Prenons un scénario concret. Tu développes un agent qui vérifie l'emploi du temps personnel d'un employé. Tu configures Authenticate manually et tu le lies à ton App Registration Entra ID. Voici le point clé. L'agent n'obtient pas un accès global à tout le compte Microsoft de l'utilisateur. Au lieu de ça, tu définis des scopes stricts dans ta configuration. Tu configures le node d'authentification pour demander un scope spécifique appelé Calendars dot Read. Quand un utilisateur demande son emploi du temps à l'agent, l'agent met sa logique en pause et affiche une sign-in card dans le chat. L'utilisateur clique sur le lien, s'authentifie via son navigateur, et voit un écran lui demandant d'accorder à l'agent un accès en lecture à son calendrier. Une fois qu'il a donné son consentement, Microsoft Entra ID génère un access token et le renvoie de manière sécurisée à l'agent. Cet access token est strictement lié à cet utilisateur individuel et restreint uniquement au scope du calendrier. Quand l'agent effectue la véritable HTTP request pour récupérer l'emploi du temps, il inclut ce token. La backend API inspecte le token, confirme l'identité de l'utilisateur, et renvoie en toute sécurité uniquement ses événements de calendrier spécifiques. Bien configurer l'authentification utilisateur, c'est ce qui transforme un chatbot générique en un assistant personnalisé, en prouvant à tes systèmes backend exactement qui demande des données, pour que tu ne fasses jamais fuiter d'informations privées entre les sessions. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Voix et IVR

3m 26s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 13 sur 15. L'avenir du service client ne se résume pas à du texte sur un écran. Les gens appellent toujours le support, et quand ils le font, ils s'attendent à une réponse immédiate et intelligente, plutôt qu'à une arborescence de menus interminable. Combler ce fossé nécessite de connecter ton IA directement aux réseaux téléphoniques. C'est ce qu'on aborde aujourd'hui : la voix et l'IVR. Prendre un agent créé dans Copilot Studio et lui faire répondre au téléphone, ça implique de le configurer pour un channel téléphonique, généralement via Dynamics 365 ou Azure Communication Services. Ça transforme ta logique en un système IVR, en s'appuyant sur la reconnaissance vocale native pour convertir l'audio de l'appelant en texte, et sur des moteurs de text-to-speech pour lui répondre. Mais traduire une logique de chat en logique vocale implique de gérer les réalités physiques d'un appel téléphonique. Imagine un client qui appelle le support. Le bot répond et commence à lire un message d'accueil légal obligatoire ou une liste d'options. L'appelant sait déjà qu'il veut le service facturation. Si c'était un chat textuel, il taperait simplement sa question. Au téléphone, il parle par-dessus le bot. Ça nécessite une feature appelée Barge-in. Sans le Barge-in activé, le système ignore l'audio entrant jusqu'à ce que le bot ait complètement terminé son playback. Avec le Barge-in actif, le speech recognizer écoute en simultané. Au moment où il détecte que l'utilisateur parle, il coupe instantanément l'output text-to-speech du bot et traite l'audio entrant. Ça reproduit le flow naturel d'une conversation humaine et évite aux appelants de se sentir piégés par une machine. Après avoir interrompu le bot, on demande à l'appelant son numéro de compte. Il pourrait dire les chiffres à voix haute, mais il est peut-être dans une pièce bruyante. À la place, il tape les chiffres sur son écran. Ça nous amène au DTMF, ou Dual-Tone Multi-Frequency. On confond souvent la gestion du DTMF avec les inputs texte standards, mais ce sont des mécanismes totalement séparés. Le DTMF gère les interactions avec le clavier téléphonique de manière globale sur le réseau téléphonique. Quand un appelant appuie sur une touche, le réseau envoie une tonalité de fréquence spécifique. Copilot Studio capture ces tonalités directement. Tu configures des nodes d'input pour écouter les séquences DTMF, extraire les chiffres qui en résultent, et les stocker comme variables. Tu peux imposer un nombre maximum de chiffres, définir des timeouts, et définir un caractère de terminaison, comme dire à l'utilisateur d'appuyer sur la touche dièse quand il a fini de taper. Voici le point clé. Capturer l'input ne suffit pas ; la façon dont ton agent répond détermine si l'appelant raccroche. Le text-to-speech par défaut peut sonner plat. Pour corriger ça, tu utilises le SSML, ou Speech Synthesis Markup Language. Au lieu d'envoyer du plain text au moteur vocal, tu encapsules tes réponses dans des tags de markup. Le SSML te permet de contrôler le pitch, d'ajuster le débit de parole, et d'imposer des prononciations spécifiques. Si le nom de ton entreprise est un acronyme, tu peux utiliser le SSML pour forcer le moteur à le lire lettre par lettre au lieu de deviner comment ça se prononce comme un mot. Tu peux insérer des silences précis, en ajoutant une pause d'une demi-seconde après une instruction complexe pour laisser à l'appelant le temps de traiter l'information. Développer pour la voix nécessite de traiter la ligne téléphonique comme une interface unique, en prenant en compte les interruptions, les tonalités du clavier et le rythme audio. Les agents vocaux les plus efficaces ne forcent pas les utilisateurs dans des menus audio rigides ; ils combinent un Barge-in fluide et une gestion précise du DTMF pour simplement laisser la voie libre à l'appelant. Merci d'avoir écouté. À la prochaine !

Agent Analytics

2m 58s

Télécharger

Salut, c'est Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 14 sur 15. Tu lances enfin le deploy de ton agent, tu le testes toi-même, et tout a l'air parfait. Une semaine plus tard, la satisfaction des utilisateurs chute, et des process en background plantent silencieusement. Le problème ne vient pas de ton build initial, mais de ton manque de visibilité sur le comportement en prod. L'outil pour corriger ça, c'est Agent Analytics. Agent Analytics t'offre une vue unifiée des performances de ton agent une fois qu'il gère des workloads réels. La première chose que tu vois, c'est la page Summary. Elle agit comme un centre de commande. Elle agrège les indicateurs clés de performance comme le nombre total de sessions, le taux d'engagement, le taux de résolution et le taux d'escalade. Au lieu de deviner si ton agent aide vraiment les utilisateurs, les AI insights de la page Summary analysent l'intention de l'utilisateur et te montrent exactement quels topics génèrent des résolutions réussies et lesquels poussent les utilisateurs à abandonner la session ou à demander un humain. Voici le point clé. Copilot Studio tracke deux types de sessions fondamentalement différents, et le dashboard les présente dans une vue hybride. D'abord, tu as les sessions conversationnelles. C'est exactement ce que leur nom indique. Un utilisateur ouvre une fenêtre de chat et discute avec l'agent. Les analytics trackent les tours de dialogue, le sentiment de l'utilisateur et le déclenchement des topics. Ensuite, tu as les sessions autonomes. Elles tournent entièrement en background. Elles sont déclenchées par des events externes, comme la création d'un nouvel enregistrement dans une base de données ou un e-mail entrant, et non par un utilisateur qui tape un message. Il n'y a pas d'interface de chat. Les analytics trackent si l'agent a exécuté sa logique en background avec succès ou s'il a rencontré une erreur. Tu as besoin de ces deux vues pour garder un agent en bonne santé. Imagine un scénario où tu consultes ce dashboard hybride. Tes metrics conversationnelles ont l'air bonnes, mais tu remarques un pic soudain du taux d'échec. En filtrant par type de session, tu découvres que les erreurs se produisent toutes dans les sessions autonomes. Un process déclenché par un event, qui est censé mettre à jour les statuts de commande, plante en background. Le dashboard Summary te dit qu'il y a une erreur, mais il ne te donne pas la ligne de logique exacte qui l'a causée. C'est là que tu passes du dashboard aux données brutes. Copilot Studio stocke des logs d'exécution détaillés dans Microsoft Dataverse sous forme de transcripts. Tu télécharges le transcript spécifique de la session autonome qui a planté. Lire le transcript te donne la trace étape par étape de l'exécution. Tu peux voir la variable exacte qui a passé une valeur invalide, cibler le node qui plante, et corriger la logique sans avoir à recréer l'erreur à l'aveugle. Le dashboard te dit où chercher, mais le transcript te dit quoi corriger. Si tu veux nous aider à continuer ces décryptages techniques, tu peux soutenir l'émission en cherchant DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci de ton écoute, et continue de développer !

Model Context Protocol

3m 33s

Télécharger

Bonjour, ici Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, épisode 15 sur 15. Tu passes des semaines à développer des plugins personnalisés pour permettre à ton agent de requêter tes bases de données internes et de déclencher des actions. Puis une nouvelle plateforme sort, et tu te retrouves à réécrire exactement les mêmes intégrations from scratch. La solution à ce cycle sans fin de travail redondant, c'est le Model Context Protocol. Le Model Context Protocol, ou MCP, est un standard ouvert qui connecte les modèles d'IA à des sources de données et des tools externes. En adoptant un standard ouvert, tu pérennises efficacement tes agents. Tu écris la logique d'intégration exactement une fois, tu l'héberges sur un serveur MCP, et n'importe quel client d'IA compatible peut l'utiliser instantanément. Copilot Studio agit comme l'un de ces clients. Imagine un scénario où ton équipe d'ingénierie s'appuie sur 50 scripts de diagnostic internes différents et des fichiers de logs en temps réel. Tu ne veux pas créer et mapper manuellement 50 actions distinctes dans Copilot Studio. À la place, tu configures ton agent pour qu'il se connecte directement à ton serveur MCP interne propriétaire. Quand l'agent s'initialise, il demande au serveur ce qu'il peut faire. Le serveur répond avec une liste de capacités, donnant immédiatement à l'agent l'accès aux 50 tools d'ingénierie et aux ressources de fichiers en live. Un serveur MCP expose trois composants principaux à ton agent. Ce sont les Resources, les Tools et les Prompts. Les Resources sont des sources de données en read-only. Quand ton agent a besoin de vérifier un fichier de configuration en live ou un enregistrement de base de données, le serveur MCP fournit ces données sous forme de resource, en les chargeant directement dans le contexte du modèle. Les Tools sont des fonctions exécutables. Si l'agent décide qu'il doit redémarrer une machine virtuelle ou mettre à jour un ticket d'ingénierie, il appelle le tool MCP approprié, et le serveur externe exécute l'action. Les Prompts sont des templates d'instructions prédéfinis fournis par le serveur. Ils guident l'agent sur la façon exacte de formater les requêtes ou d'interpréter les données spécifiques à ce système externe. Voici le point clé. On pense souvent que quand tu connectes un serveur MCP, Copilot Studio importe et sauvegarde des copies permanentes de ces tools dans sa propre interface utilisateur. Ce n'est pas comme ça que ça marche. Les tools et les resources sont hébergés de manière complètement externe. Copilot Studio lit dynamiquement ce que le serveur expose au runtime. Si ton équipe d'ingénierie ajoute un cinquante-et-unième tool de diagnostic, ou modifie les paramètres d'un script existant, elle met simplement à jour le serveur MCP externe. Copilot Studio reflète automatiquement ces changements. Tu n'as jamais besoin de te connecter à l'interface du studio pour republier ou mettre à jour l'action. Parce que la logique vit entièrement sur le serveur, tu conserves une source de vérité unique pour les données et les actions de ton organisation. L'agent reste léger, fonctionnant simplement comme le moteur de raisonnement qui décide quand communiquer avec le serveur. En séparant tes tools de la plateforme d'agent spécifique, tu centralises tes intégrations et tu garantis que ton IA a toujours les dernières capacités, peu importe l'interface client que tu vas deploy. Je t'encourage vivement à lire la documentation officielle, à essayer de connecter un serveur MCP hands-on, ou à visiter devstories dot eu pour suggérer des sujets que tu aimerais voir abordés dans une future série. C'est tout pour cet épisode. Merci d'avoir écouté, et keep building !