Mettre les agents en production grâce au Foundry Agent Service et au Agent Framework
Comment un agent de préparation des ventes passe d’un code local à une déploiement hébergé, ciblé sur l’identité, isolé et surveillé, publié dans Microsoft 365 et basé sur des données commerciales.
Sources: Foundry Agent Service + Microsoft Agent Framework Explained
De prototype à agent de production
Faire fonctionner un agent IA sur un ordinateur portable est la partie facile. La tâche plus difficile dans une grande entreprise consiste à le faire fonctionner en toute sécurité pour des milliers d’utilisateurs : lui attribuer une identité, limiter ce qu’il peut lire, enregistrer ses actions, et le mettre à disposition des utilisateurs au sein des outils qu’ils ont déjà ouverts. Microsoft Foundry Agent Service, associé au framework open source Microsoft Agent Framework, vise à combler cette lacune. Le premier prend en charge l’hébergement avec des contrôles d’entreprise, des fonctionnalités de mesure et de découverte, et permet d’intégrer des agents développés avec n’importe quels outils de votre choix. Le second vous aide à créer des agents individuels ainsi que des charges de travail multi-agents grâce à des mécanismes d’orchestration.
L’idée est qu’un agent puisse être déployé directement depuis un environnement local, fonctionner sous une identité sécurisée dotée de permissions ciblées, et faire l’objet d’une surveillance interaction par interaction, ce qui permet de le déboguer, de l’améliorer et de l’échelonner sans que personne ne perde le contrôle. Les agents peuvent également être intégrés dans des outils familiers, où chaque action est traçable, gérable et isolée.
L’autre aspect important concerne le terrain concret. Les agents deviennent utiles lorsqu’ils s’appuient sur des données commerciales réelles : e-mails, réunions et systèmes opérationnels fournissent des informations personnalisées, des documents et des présentations. Les équipes utilisent des frameworks connus pour développer leurs solutions, puis gèrent la performance, les coûts et la qualité de tous leurs agents à mesure que leur nombre augmente.
Qu’est-ce qui rend difficile le déploiement au niveau entreprise ?
Créer un agent est devenu beaucoup plus simple. Cependant, le déployer de manière sûre et fiable dans toute une organisation reste un défi. Beaucoup des agents actuellement développés sont bien au-delà de la phase pilote restreinte. Certains offrent des expériences de chat utilisées par des milliers d’employés, tandis que d’autres fonctionnent discrètement en arrière-plan, parfois intégrés à des systèmes critiques.
Tous nécessitent les mêmes fondements : le contrôle d’identité et d’accès, la connectivité privée, ainsi que la télémétrie et le suivi au niveau d’un agent individuel et de toute la flotte. Assembler ces éléments manuellement est complexe, ce qui constitue le problème que les services Foundry sont conçus pour résoudre, afin que les agents fonctionnent en toute sécurité, à grande échelle et avec une visibilité totale. Il est utile d’imaginer l’alternative : une équipe qui héberge son propre agent doit décider comment cet agent s’authentifie, quel compte de service il emprunte, où sont stockés les journaux, comment les données d’un utilisateur restent séparées de celles d’un autre, et qui est averti en cas de comportement anormal. Chacune de ces réponses représente un petit projet, et une revue de sécurité interrogera sur chacune d’elles avant même que l’agent ne touche à un calendrier ou à un dossier client.
Exemple : un agent de préparation de réunions commerciales
L’exemple en cours est un agent qui aide une équipe de vente à se préparer pour les réunions avec les clients. Son code est déjà écrit, en utilisant le Microsoft Agent Framework en Python, bien que n’importe quel framework et langage puissent être substitués. Il définit un grand nombre d’outils, une logique de middleware ainsi qu’un flux de travail, et pour l’instant tout fonctionne localement.
La question ouverte est de savoir comment le transformer en une solution sécurisée, scalable, conforme aux normes et fiable au sein de l’entreprise. Dans Visual Studio Code, l’extension AI Toolkit propose une action de déploiement vers des agents hébergés. Elle empaquette l’agent tel qu’il a été écrit et le déploie au sein de Foundry en tant qu’agent hébergé. Le même agent qui fonctionnait localement apparaît désormais dans le portail Foundry, et l’environnement de test peut l’appeler pour montrer ce que la couche d’hébergement ajoute.
Demander à l’agent quels sont les rendez-vous importants prévus cette semaine illustre les nouvelles approches utilisées avec ces agents. L’agent fonctionne à l’intérieur d’un environnement sécurisé, une microVM, où il peut raisonner, consulter le calendrier, ainsi que écrire et exécuter du code, tout comme le font des agents de programmation tels que GitHub Copilot CLI ou Claude Code.
Identité, isolation et contrôles
Diverses actions ont lieu dès que l’agent est déployé, et l’image suivante montre où s’affiche la configuration relative à l’identité et aux permissions dans le portail.
- L’agent reçoit son propre identifiant unique de Microsoft Entra. Toute action qu’il entreprend, comme la lecture d’un calendrier, peut être retracée jusqu’à lui. Grâce à cette identité, il peut accéder aux ressources de manière autonome dans le cadre des permissions qui lui sont attribuées, ou bien agir au nom d’une personne en utilisant les permissions de ce dernier.
- Chaque utilisateur qui lance une session d’agent dispose d’une microVM sécurisée dédiée. Lorsque deux commerciaux posent des questions en même temps, chacun dispose d’une instance d’agent distincte, de sorte que les informations de chaque session sont lues, écrites et stockées dans son propre espace.
- Pour chaque interaction, le service vérifie les politiques et les règles définies par l’organisation, couvrant des aspects tels que le filtrage du contenu, la protection contre l’injection de commandes et l’utilisation de matériel protégé par des droits d’auteur. Un contrôle précis de ce que l’agent peut faire et à quoi il peut accéder provient de la configuration effectuée automatiquement au moment du déploiement.
De retour sur l’aire de jeu, l’agent fournit sa réponse. Sur la base des signaux qu’il a collectés et analysés, un compte client, Zava DIY, se révèle être la priorité absolue. Dans ce cas, l’agent a agi au nom de l’utilisateur, en utilisant ses identifiants et ses permissions, afin d’examiner le calendrier et d’identifier les comptes nécessitant une attention particulière. Étant donné qu’il doit lire la boîte de réception, le calendrier ainsi que les stockages de données et de fichiers, disposer de bons mécanismes de contrôle d’accès est précisément ce dont a besoin un système conforme aux exigences.
Surveillance et publication
Deux autres besoins propres aux entreprises proviennent directement de Foundry. Le premier est l’observabilité. Le portail offre des fonctionnalités de surveillance et de suivi, vous permettant de suivre chaque conversation, de voir comment l’agent répond à chaque question et de vérifier son état général.
Le deuxième aspect est la découvrabilité. Une fois qu’un agent est en cours d’exécution, il doit encore parvenir aux personnes qui en ont besoin, et personne n’aime créer une nouvelle application en espérant que tout le monde trouvera le lien et l’ajoutera à ses favoris. Si une entreprise utilise déjà Microsoft 365 et Teams, un bouton de publication peut prendre n’importe quel agent déployé dans Foundry et l’enregistrer dans ces services. Les utilisateurs peuvent alors le trouver et l’utiliser là où ils travaillent déjà, que ce soit sur un ordinateur de bureau ou sur un téléphone en dehors du bureau. Dans Microsoft 365, l’agent apparaît dans l’expérience Copilot Chat, et il est également disponible dans Teams.
La couche d’intelligence derrière les réponses fondées
Foundry s’intègre également à la couche d’intelligence unifiée d’Microsoft pour l’IA, ce qui permet aux agents de s’appuyer sur les connaissances et le contexte métier appropriés afin que leurs réponses soient pertinentes. Cela va bien au-delà de ce qu’un serveur MCP à source unique peut offrir. Elle se compose de trois éléments.
- Work IQ fournit un contexte sur la manière dont une personne travaille : liens vers des e-mails, un calendrier, des réunions antérieures, des chats Teams, des fichiers et bien plus encore.
- Fabric IQ ajoute un contexte concernant les opérations commerciales associées, telles que des données de ventes, des fiches clients ou des aspects logistiques.
- Foundry IQ combine plusieurs sources de connaissances pour un agent, allant de données structurées et de bases de données à du matériel non structuré stocké dans des services cloud, et même des images peuvent être récupérées par des processus automatisés.
Lors de la première exécution, seule la recherche dans le calendrier était visible, qui correspond à la fonctionnalité de Work IQ. L’agent plus avancé utilise les trois fonctionnalités.
Une exécution plus complète : préparation de la réunion Zava
Le même agent a accès aux trois systèmes IQ grâce aux outils et compétences qui lui ont été confiés. Sur le terrain, une note issue d’une sortie antérieure de l’agent indique une réunion importante avec Zava, ce qui amène la demande suivante à lui demander d’aider à se préparer à cette réunion.
Dans l’environnement de test, il effectue ce qui a été décrit précédemment. Il consulte Work IQ pour trouver la correspondance, en extrayant les e-mails et les conversations Teams concernant Zava. Il consulte également Fabric IQ pour obtenir des données d’utilisation, des schémas d’achat et des détails de contrat. Enfin, il recherche dans les matériaux de formation aux ventes et de marketing via Foundry IQ ce qui est le plus pertinent pour ce client.
L’agent dispose également de quelques compétences basées sur le modèle de compétences d’agent populaire. L’une génère une présentation PowerPoint et une autre crée des documents de synthèse en Word. Il renvoie deux fichiers liés : un document de synthèse en Word destiné à l’équipe interne et une présentation personnalisée à utiliser avec Zava.
- Le rapport de synthèse reprend le contexte issu de la couche de renseignements, ainsi que les informations relatives aux relations provenant du système CRM, les communications récentes de la correspondance de l’utilisateur, les analyses commerciales concernant la santé, l’utilisation et la mesure, et les tickets d’assistance provenant du système de gestion des tickets. Le résultat est un document de préparation unique contenant des sujets de discussion recommandés.
- La présentation est personnalisée pour cette interaction client spécifique et utilise les couleurs de marque de l’entreprise. Elle combine des éléments provenant de Fabric IQ et de Foundry IQ en points de discussion et des informations spécifiques au client sur les activités récentes, ainsi que des données sur les opérations commerciales, des métriques de campagne, et de nouvelles opportunités et services susceptibles de développer davantage cette collaboration.
La valeur réside dans bien plus que la simple déploiement : ces agents fonctionnent au sein de la couche d’intelligence, où ils accèdent aux données de travail, aux données commerciales et aux connaissances organisationnelles au nom d’une personne, grâce à une intégration étroite avec Microsoft 365.
Comment c’est construit
Pour les développeurs qui souhaitent créer quelque chose de similaire, le point de départ est plus simple que dans l’exemple complet. La CLI Azure Developer permet d’initialiser un nouveau projet, par exemple un agent de préparation des ventes. Les agents basés sur des conversations sont pris en charge et restent très populaires ; n’importe quel framework peut être utilisé, y compris LangGraph, et le service prend également en charge de nouveaux modèles. Des modèles fournissent les fichiers nécessaires, permettant de déboguer le projet localement avant son déploiement. Il s’agit donc d’un agent simple issu d’un modèle, offrant de nombreuses possibilités de personnalisation.
En revenant à l’agent avancé, on voit ce qui se cache derrière lui. Le code définit des outils et des sources de connaissances, y compris les trois types d’IQ, ainsi que d’autres types de compétences qui peuvent être ajoutées aux modèles d’agents de codage aujourd’hui. Au cœur de ce système, l’agent utilise le SDK GitHub Copilot, qui met en œuvre une boucle d’agent sur l’ensemble d’outils définis. Cette boucle effectue des raisonnements à partir de dizaines de fichiers, d’e-mails, de réunions antérieures ainsi que de données opérationnelles et de service, et ce sont les recommandations qui en résultent.
Le Microsoft Agent Framework relie tous les éléments entre eux et ajoute des composants tels que du middleware. Une règle d’exemple : si l’agent de codage tente de générer l’un de ces documents sans suffisamment de données provenant des trois IQ, le middleware l’empêche de le faire, car un résultat sans ces données fiables est presque toujours le fruit d’hallucinations. De tels schémas sont essentiels lorsqu’on élargit le déploiement au niveau d’une entreprise, où les contrôles de qualité s’étendent à toute l’équipe de vente ainsi qu’à des mécanismes de sécurité supplémentaires. Les avantages complets apparaissent lorsque les frameworks et ces schémas sont combinés et hébergés au sein du Foundry Agent Service.
Gérer une flotte
Lorsque plusieurs agents sont en cours d’exécution, la question suivante concerne leur surveillance et leur gestion, ce qui est possible car tout s’exécute à l’intérieur de Foundry. Le portail affiche en un seul aperçu les performances et les coûts de l’ensemble de la flotte : l’état des agents et les alertes (dans la démonstration, tous sont en bon état et il n’y a pas encore d’alertes), le coût estimé, les taux de réussite et l’utilisation des tokens, avec des détails approfondis sur le volume d’exécutions des agents les plus actifs. Les meilleurs et les pires agents en termes de taux de réussite indiquent ceux qui nécessitent une attention particulière.
Tout ce qui est nécessaire pour passer de l’expérimentation à la production, ainsi que pour le diffuser auprès de tous les utilisateurs finaux, est intégré avec une visibilité complète. L’objectif principal est de réduire la complexité liée à la création et au déploiement sécurisé et fiable d’agents au sein d’une organisation. Pour ceux qui souhaitent essayer, il suffit de démarrer un premier projet dans le portail Foundry et de consulter les exemples publics de Microsoft afin de trouver le SDK adapté.
Une séquence de travail pratique découle de tout cela. Commencez par un petit agent issu d’un modèle et faites-le fonctionner localement. Ajoutez des outils et des sources de connaissances un par un, en utilisant un middleware qui refuse de continuer en l’absence de données de référence. Déployez tôt dans l’environnement hébergé, afin que l’identification, l’isolation et le suivi soient mis en œuvre bien avant l’arrivée des utilisateurs réels. Publiez dans les outils de chat que les gens utilisent déjà uniquement une fois que les traces générées semblent fiables, et maintenez la vue globale des agents actifs une fois que plusieurs d’entre eux sont opérationnels, car c’est là que les coûts augmentent progressivement et que les taux de réussite diminuent en premier. Les équipes qui suivent cette séquence ont tendance à détecter les problèmes alors qu’il est encore peu coûteux de les résoudre.
Pourquoi les environnements locaux et hébergés se comportent-ils si différemment
Il est utile de distinguer ce que l’éditeur a écrit de ce que la plateforme ajoute. Les outils, le middleware et le flux de travail présents dans l’agent de vente ne sont que du code d’application ordinaire, qui se comporte de la même manière sur un ordinateur portable que dans le cloud. Ce qui change après le déploiement, c’est tout ce qui entoure ce code : une identité est créée, les sessions sont isolées, des politiques sont évaluées à chaque interaction, des traces s’accumulent et un chemin de publication s’ouvre. Rien de tout cela ne nécessite de réécrire l’agent, c’est pourquoi la démonstration considère le déploiement comme une seule action dans un éditeur et non comme un projet de migration.
Trois questions résument cette approche, chacune correspondant à une couche décrite ci-dessus.
- Qui agit ? L’identité Entra y répond, que l’agent utilise ses propres permissions ciblées ou emprunte celles d’un utilisateur.
- Où a lieu le travail, et qui peut le voir ? Les environnements isolés de microVM par utilisateur maintiennent les sessions séparées, et les politiques de contenu et d’injection de l’organisation s’appliquent à chaque appel.
- Qu’a-t-il fait, et fonctionne-t-il bien ? Les traces, les vues des conversations, les indicateurs de santé, ainsi que les résumés des coûts et des taux de réussite répondent à ces questions, pour chaque agent et pour l’ensemble des systèmes.
Règles de sécurité intégrées dans le code
Les contraintes de la plateforme ne remplacent pas celles intégrées directement dans l’agent lui-même. La règle de middleware qui bloque la génération de documents lorsque les trois indicateurs de qualité n’ont pas fourni suffisamment de données en est un bon exemple, car elle impose un standard de qualité que aucune politique générique ne pourrait connaître. Un rapport établi sans historique CRM ni données d’utilisation paraîtra néanmoins soigné, et un commercial pourrait se rendre à une réunion avec un client en s’appuyant sur des détails inventés. Arrêter cela au niveau du code, avant même que le fichier ne soit généré, est moins coûteux que de le détecter par la suite.
C’est la même logique qui explique pourquoi les démos regroupent les compétences en éléments distincts et réutilisables. Une compétence permettant de créer une carte et une compétence permettant d’écrire un résumé peuvent chacune être testées, mises à jour et réutilisées par d’autres agents, tandis que le cycle d’action détermine quand les appeler. En combinant ce cycle, le middleware du framework et la couche d’hébergement, on obtient trois points où appliquer un contrôle : la manière dont l’agent raisonne, ce qu’il est autorisé à émettre, et ce que l’environnement lui permet de faire.
Points à considérer avant de copier ce modèle
Cet exemple montre le meilleur des cas, où toutes les sources de données sont connectées et les permissions bien organisées. En pratique, la qualité des informations fournies dépend de la qualité des données CRM, de gestion des tickets et d’analyse sous-jacentes. Les permissions ciblées ne sont utiles que s’elles ont réellement été définies de manière précise ; un agent agissant avec les droits d’un utilisateur peut voir tout ce que cet utilisateur peut voir, ce qui fait que des comptes trop larges donnent naissance à des agents tout aussi peu restreints. Les tableaux de bord de flotte sont utiles pour identifier les agents les plus faibles, mais quelqu’un doit néanmoins examiner les traces pour déterminer si un faible taux de réussite est dû au modèle, à un outil, à une source de données manquante ou à des restrictions trop strictes.
Lectures complémentaires
- MAF 1.0, LangGraph ou CrewAI ? Choisir un framework d’agent en 2026 — Comparaison du Microsoft Agent Framework 1.0, de LangGraph et de CrewAI en ce qui concerne l’état, la mémoire, le débogage, les protocoles, les solutions Azure et les coûts, avec une courte méthode de décision et un modèle de déploiement.
- Prises de vue de mémoire de l’agent, compétences, dégradation et ciblage des branches — Quatre améliorations pour une couche de mémoire basée sur une base de données vectorielle intégrée destinée aux agents de programmation : des prises de vue portables pouvant être fusionnées, l’activation de compétences, une dégradation avec vérification des conflits, ainsi qu’une mémoire ciblée par branches.