Brief IA : Microsoft révolutionne l'IA agentique avec son nouveau cadre d'agents

Microsoft révolutionne l'IA agentique avec son nouveau cadre d'agents

Brief IA
Tom Levy·8 min·16 vues

Le cadre d'agent de Microsoft, lancé en octobre 2025, permet une orchestration efficace des workflows dans les systèmes d'IA agentique, intégrant la RAG (Retrieval-Augmented Generation) en Python. Ce cadre, soutenu par le projet Agent Framework Dev et le groupe Boston Azure AI, améliore la performance des modèles d'IA tout en garantissant la sécurité et l'efficacité des interactions automatisées.

En bref
1Microsoft a lancé en octobre 2025 le Microsoft Agent Framework, un outil unifié pour créer des systèmes d'IA agentiques.
2Le cadre met l'accent sur la sécurité, en comparant des modèles protégés et non protégés pour évaluer les risques.
3Le Protocole de Contexte de Modèle permet aux agents IA de s'intégrer facilement à des systèmes d'entreprise en évolution.
💡Pourquoi c'est importantCe cadre pourrait transformer la manière dont les entreprises intègrent l'IA, en mettant l'accent sur la sécurité et l'adaptabilité.
Le brief IA que lisent les pros

Tu suis la course aux modèles IA ?

Chaque sortie (GPT, Claude, Gemini, Mistral…) décryptée le soir même, en 5 min. Gratuit.

Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.

Choisis ton rythme

Gratuit · Pas de spam · Désabonnement en 1 clic

📄
L'analyse en français

Un cadre novateur pour l'IA agentique

Le projet Agent Framework Dev représente une initiative communautaire dynamique, visant à fournir des matériaux de formation pratiques aux développeurs intéressés par la création d'agents d'IA. Ce projet s'appuie sur des frameworks et des outils modernes pour offrir une formation approfondie et accessible. En octobre 2025, le Microsoft Agent Framework a été lancé, étendant les capacités de Semantic Kernel et AutoGen dans une approche unifiée pour le développement de systèmes agentiques de production. Ce lancement a été marqué par l'organisation de l'Agent Framework Dev Day, un événement orchestré par le groupe Boston Azure AI et soutenu par Microsoft.

Le cadre s'intègre à la plateforme Microsoft Foundry, offrant des fonctionnalités d'observabilité, de configuration de sécurité et de contrôles opérationnels de niveau entreprise. En travaillant avec le contenu Python du cadre, les développeurs peuvent explorer quatre domaines techniques interconnectés, chacun s'appuyant sur le précédent et ancré dans des modèles applicables à des systèmes déployés réels.

Considérer la sécurité comme un problème de mesure empirique

Dans le développement d'agents d'IA, la sécurité est souvent traitée comme un aspect secondaire. Cependant, Microsoft propose de la placer au centre du processus de développement. Avant même de commencer à coder, les développeurs sont encouragés à évaluer la sécurité des modèles grâce à un exécuteur de comparaison à double modèle. Cet outil envoie la même requête à deux instances de gpt-4.1-mini : l'une avec les garde-fous de sécurité de Microsoft Foundry activés, l'autre avec ces protections réduites.

Pour illustrer cette comparaison, une demande d'instructions pour fabriquer un explosif artisanal est utilisée. Le modèle protégé refuse catégoriquement de répondre, tandis que le modèle non protégé pourrait ne pas le faire. Cette démonstration met en évidence les différences comportementales entre les deux déploiements, rendant la question de la sécurité tangible et non plus théorique.

Les développeurs peuvent explorer trois catégories d'entrées : le filtrage de la profanité via des listes de blocage, les identifiants gouvernementaux tels que les numéros de sécurité sociale, et d'autres informations personnellement identifiables. Chaque catégorie représente une préoccupation de conformité d'entreprise, et les différences observées entre les modèles protégé et non protégé aident à identifier où les garde-fous sont efficaces et où des améliorations sont nécessaires.

La latence est également un facteur à considérer, car les garde-fous de sécurité ajoutent une surcharge mesurable. Un troisième modèle, avec des paramètres de sécurité intermédiaires, montre que la sécurité est un spectre configurable, que les ingénieurs peuvent ajuster selon le contexte d'application.

Le code utilise le AzureAIClient pour créer des agents éphémères, exécutant les deux modèles via asyncio.gather et affichant les comptes de jetons avec les données de timing. L'architecture est volontairement minimaliste, l'objectif étant de comparer les modèles plutôt que de se concentrer sur l'infrastructure.

Connecter les agents au monde avec le protocole de contexte de modèle

Le Protocole de Contexte de Modèle (MCP) est un adaptateur universel qui permet aux agents d'IA de se connecter à des sources de données et des outils via un protocole standardisé. Cela se fait sans nécessiter de modifications du client agent lorsque le service sous-jacent change, ce qui en fait une base pratique pour construire des agents qui interagissent avec des systèmes d'entreprise en évolution.

L'architecture MCP repose sur trois composants principaux : une application hôte (l'agent IA), un client MCP, et un ou plusieurs serveurs MCP. Ces serveurs peuvent être locaux ou distants, et le code client reste inchangé, ce qui maintient la couche agent découplée des décisions d'infrastructure.

Deux mécanismes de transport sont utilisés pour couvrir les principaux scénarios de déploiement :

  • Transport STDIO : Ce transport exécute le serveur MCP en tant que sous-processus, communiquant via l'entrée et la sortie standard. Il est idéal pour les outils locaux et les intégrations CLI nécessitant une faible latence.

  • Transport HTTP/SSE : Ce transport exécute le serveur en tant que service web, communiquant via HTTP avec des événements envoyés par le serveur (SSE). Il est adapté aux services cloud et aux outils partagés nécessitant une accessibilité simultanée par plusieurs agents.

Une mise en œuvre concrète dans le domaine des tickets de support rend ces concepts tangibles. Le mcp_local_server expose des outils via STDIO, tandis que le mcp_remote_server fonctionne comme une API REST gérant les mêmes données de ticket. Le mcp_bridge traduit entre HTTP/SSE et les appels HTTP ordinaires, et le mcp_agent_client consomme ces outils, découvrant dynamiquement les outils de chaque serveur.

L'architecture permet d'envelopper une API REST existante avec un pont MCP sans modifier le backend, réduisant ainsi le coût d'intégration pour les entreprises ayant de vastes surfaces API.

Orchestration des modèles de flux de travail : séquentiel, concurrent et humain dans la boucle

L'orchestration des flux de travail est l'endroit où les agents individuels commencent à fonctionner comme des systèmes coordonnés capables de gérer des problèmes trop complexes pour qu'un seul appel de modèle puisse les résoudre proprement à lui seul.

Les trois modèles fonctionnent sur le même modèle de données SupportTicket, portant des champs tels que l'ID du ticket, le nom du client, le sujet, la description et la priorité. Utiliser le même domaine à travers les trois modèles est délibéré : l'objectif est d'observer des données identiques se déplacer à travers des architectures de traitement fondamentalement différentes et d'observer ce qui change dans la sortie, la latence et la surface de contrôle disponible pour l'opérateur.

  • Flux de travail séquentiel : Un ticket de haute priorité d'un client incapable de se connecter après une réinitialisation de mot de passe passe par une étape de catégorisation IA, qui classe et résume le problème en JSON structuré, puis entre dans une étape de génération de réponse. La sortie est une réponse complète, prête pour le client, qui reconnaît l'urgence, offre des étapes concrètes à suivre, et inclut le numéro du ticket. L'ensemble du pipeline fonctionne sans intervention humaine, et la sortie de chaque étape est visible avant de passer à la suivante, rendant la transformation des données à chaque étape explicite et inspectable.

  • Flux de travail concurrent : Un client signalant à la fois un double prélèvement et une application qui plante dans le même message expose les limites d'un pipeline séquentiel à agent unique. Les préoccupations de facturation et techniques nécessitent une expertise différente, et acheminer les deux à travers un seul agent produit un résultat moins efficace que de les acheminer chacune vers un spécialiste capable de raisonner profondément dans un domaine plus étroit.

    Le modèle concurrent élargit la question à un agent expert en facturation et un agent expert technique simultanément. L'agent de facturation s'occupe du double prélèvement et recommande un chemin de remboursement. L'agent technique se concentre sur les étapes de nettoyage du cache et de réinstallation pour l'application qui plante. Aucun des agents n'essaie de gérer les deux domaines. Le résultat agrégé donne au client une réponse complète qu'aucun spécialiste unique n'aurait pu produire seul, et le temps de réponse est limité par le plus lent des deux agents plutôt que par leur somme.

  • Flux de travail humain dans la boucle : Le cas le plus critique implique un client demandant un remboursement complet pour un abonnement premium annuel acheté une semaine auparavant. L'IA génère un projet de réponse invoquant correctement la politique de garantie de remboursement de 14 jours et offrant de traiter l'annulation immédiatement. Ensuite, l'exécution s'arrête, et le contrôle passe explicitement à un examinateur humain avant que quoi que ce soit ne soit envoyé.

    Le superviseur reçoit le projet complet et trois choix explicites : approuver et envoyer tel quel, modifier avant l'envoi, ou escalader à la direction. En cas d'approbation, le système enregistre l'action, met à jour le statut du ticket à résolu, et consigne que la réponse a été approuvée sans modification, créant une piste d'audit complète de la décision.

Ce que ce modèle rend concret est quelque chose que les diagrammes de flux de travail tendent à obscurcir : la pause humain dans la boucle n'est pas un mode d'échec ou un chemin d'exception. C'est un arrêt conçu, de première classe, dans le flux de travail. Le système attend cela sans interrogation ni délai. C'est le modèle qui rend les processus assistés par IA audités et défendables dans des environnements réglementés ou à enjeux élevés, et il mérite d'être traité comme un pair aux alternatives entièrement automatisées plutôt qu'un recours de dernier ressort.

Étendre chaque modèle approfondit considérablement la compréhension. Ajouter un agent d'analyse de sentiment avant la catégorisation dans le pipeline séquentiel, ajouter un spécialiste de la sécurité ou des comptes au fan-out concurrent, ajouter de nouvelles actions de superviseur comme "Demander plus d'informations" à l'étape humain dans la boucle, et composer des modèles séquentiels et concurrents en un seul flux de travail hybride nécessitent de comprendre comment les classes d'exécuteurs, la fabrique de clients partagée et les modèles de données se connectent à travers l'ensemble du système.

Passer de RAG à RAG agentique

Les applications standard de génération augmentée par récupération (RAG) sont simples à démarrer mais rencontrent des types de questions qui nécessitent une approche plus sophistiquée pour être résolues efficacement. Le cadre de Microsoft propose une approche agentique pour surmonter ces défis, en intégrant des agents capables de traiter des requêtes complexes de manière efficace et sécurisée. En combinant les capacités de récupération et de génération, les agents peuvent fournir des réponses plus précises et contextualisées, répondant ainsi aux besoins croissants des entreprises modernes.

Suivez Brief IA

L'actu IA du jour, aussi dans votre fil.

Commentaires