Microsoft Agent Framework 1.0 : le guide développeur

Pendant deux ans, les équipes bâtissant sur la stack IA de Microsoft ont dû faire un choix inconfortable. Semantic Kernel offrait la plomberie d'entreprise — gestion d'état, sûreté de typage, télémétrie, filtres — mais l'orchestration multi-agents y semblait greffée après coup. AutoGen offrait des abstractions élégantes et des patterns d'orchestration de niveau recherche, mais les équipes de production butaient constamment sur l'état, l'observabilité et les processus longs.

Le 3 avril 2026, Microsoft a publié Agent Framework 1.0 pour .NET et Python, et ce choix a disparu. Le framework est le successeur direct des deux, construit par les mêmes équipes, et il replie les abstractions d'AutoGen dans les fondations d'entreprise de Semantic Kernel — puis ajoute un moteur de workflows graphique qu'aucun des deux ne possédait.

Si vous exploitez des agents en production, ou prévoyez de le faire, cette version mérite une heure de votre attention. Voici ce qui compte vraiment.

Ce qu'est Agent Framework 1.0

Le framework s'organise en trois niveaux de capacités, et comprendre ce découpage est le chemin le plus rapide pour s'y orienter.

Les agents sont des unités individuelles pilotées par un LLM : elles traitent les entrées, appellent des outils et des serveurs MCP, et produisent des réponses. Le support des modèles est délibérément large : Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini et Ollama passent tous par la même abstraction. C'est décisif pour qui construit une stratégie multi-modèles avec repli plutôt que de miser un produit sur un seul fournisseur.

Le Harness est un agent opinionné, livré équipé pour les tâches longues en plusieurs étapes — planification et suivi de tâches, compaction du contexte, accès fichiers et mémoire, approbation d'outils sans redemander, et observabilité intégrée. Voyez-le comme la version pré-assemblée pour les équipes qui ne veulent pas écrire la boucle à la main.

Les workflows sont des compositions graphiques qui relient agents et fonctions ordinaires en processus déterministes et reproductibles, avec routage typé, points de reprise et support de la validation humaine.

Sous ces trois niveaux se trouvent les briques partagées : clients de modèles, session d'agent pour l'état, fournisseurs de contexte pour la mémoire, middleware pour intercepter les actions de l'agent, et clients MCP pour l'intégration d'outils.

Démarrage

L'installation tient en une ligne dans les deux langages.

Pour Python :

pip install agent-framework

from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential
 
credential = AzureCliCredential()
client = FoundryChatClient(
    project_endpoint="https://your-service.services.ai.azure.com/api/projects/your-project",
    model="gpt-5.4-mini",
    credential=credential,
)
 
agent = client.as_agent(
    name="HelloAgent",
    instructions="You are a friendly assistant. Keep your answers brief.",
)
 
result = await agent.run("What is the largest city in France?")
print(f"Agent: {result}")

Un piège à connaître d'emblée : Agent Framework ne charge pas automatiquement les fichiers .env en Python. Appelez load_dotenv() vous-même ou définissez les variables d'environnement dans votre shell.

Pour .NET :

dotnet add package Microsoft.Agents.AI.Foundry --prerelease

using Azure.AI.Projects;
using Azure.Identity;
using Microsoft.Agents.AI;
 
AIAgent agent = new AIProjectClient(
        new Uri("https://your-service.services.ai.azure.com/api/projects/your-project"),
        new AzureCliCredential())
    .AsAIAgent(
        model: "gpt-5.4-mini",
        instructions: "You are a friendly assistant. Keep your answers brief.");
 
Console.WriteLine(await agent.RunAsync("What is the largest city in France?"));

Un SDK Go existe en préversion publique via github.com/microsoft/agent-framework-go, mais les agents déclaratifs, le RAG, CodeAct et les workflows fonctionnels n'y sont pas encore. Considérez Go comme expérimental pour l'instant.

Agents ou workflows : la décision qui compte le plus

La page la plus précieuse de la documentation est celle qui vous dit quand ne pas recourir à un agent. La consigne de Microsoft est directe : si vous pouvez écrire une fonction pour traiter la tâche, écrivez la fonction.

Au-delà, la répartition est nette :

La plupart des échecs de projets d'agents en production viennent d'avoir ignoré ce tableau. Les équipes modélisent un processus métier déterministe en cinq étapes sous forme d'agent autonome bavard, puis passent des mois à combattre un non-déterminisme qu'elles ont elles-mêmes introduit. Le moteur de workflows existe précisément pour vous l'épargner.

Les patterns d'orchestration

Agent Framework 1.0 livre cinq patterns d'orchestration stables :

• Séquentiel — les agents s'exécutent dans l'ordre, chacun consommant la sortie du précédent
• Concurrent — les agents se déploient en parallèle, les résultats convergent
• Handoff — un agent transfère le contrôle à un spécialiste selon le contexte
• Group chat — plusieurs agents délibèrent dans une conversation partagée
• Magentic-One — un pattern piloté par un planificateur pour les tâches ouvertes en plusieurs étapes

Point crucial : les cinq supportent le streaming, les points de reprise, les approbations humaines et la pause/reprise pour les workflows longs. C'est ce dernier ensemble qui sépare une démo d'un système présentable à une équipe conformité.

Les points de reprise : la fonctionnalité sous-estimée

Si une exécution d'agent de quarante minutes vous a déjà lâché sur une erreur API transitoire, vous comprenez l'enjeu. Le moteur de workflows persiste l'état via des points de reprise, configurables au build ou à l'exécution, et les workflows peuvent être mis en pause puis repris à travers des redémarrages de processus grâce au stockage des points de reprise.

Cela transforme deux problèmes difficiles en simple configuration :

Reprise après incident. Un long workflow de traitement documentaire qui échoue à l'étape 7 sur 12 reprend à l'étape 7, pas à la première. Sur des modèles coûteux, c'est une économie directe, pas seulement un gain de latence.

Validation humaine. Un workflow peut se suspendre sur une action à risque, attendre des heures ou des jours une approbation arrivant par un canal totalement séparé, puis se réhydrater et continuer. Sans points de reprise, vous finissez par construire une file de jobs et une machine à états sur mesure autour de votre agent. Avec eux, c'est un comportement natif du framework.

Pour tout processus réglementé — validation de factures, revue de contrats, rapprochement financier — c'est la fonctionnalité qui rend l'automatisation agentique défendable devant un auditeur.

MCP et A2A : l'interopérabilité sans verrouillage

Deux intégrations protocolaires déterminent la place d'Agent Framework dans une stack plus large.

MCP (Model Context Protocol) permet aux agents de découvrir et d'invoquer dynamiquement des outils exposés par n'importe quel serveur conforme. Vous écrivez l'outil une fois comme serveur MCP, et tout client compatible — Agent Framework, Claude, et l'écosystème croissant autour du standard MCP — peut l'appeler. Le framework supporte aussi les outils MCP hébergés : le serveur n'a donc pas à tourner dans votre processus.

A2A (Agent-to-Agent) permet la collaboration inter-runtimes : vos agents se coordonnent avec des agents tournant dans d'autres frameworks via une messagerie structurée pilotée par le protocole. Un agent Agent Framework peut confier du travail à un agent LangGraph ou à un participant A2A de Google sans adaptateur maison. Notez que le support A2A complet était encore en cours de livraison lors de l'annonce 1.0 — vérifiez son état actuel avant de concevoir autour.

Ensemble, ces deux protocoles comptent plus que n'importe quelle fonctionnalité isolée. Ils signifient qu'adopter Agent Framework n'impose ni de réécrire vos outils, ni d'engager tout votre parc d'agents auprès d'un seul fournisseur.

Middleware, mémoire et configuration déclarative

Trois capacités orientées production complètent la version.

Les hooks de middleware interceptent et étendent le comportement de l'agent — sécurité du contenu, journalisation, portes de conformité. C'est le point d'extension pour quiconque a besoin d'une piste d'audit de chaque appel d'outil, c'est-à-dire en pratique toute équipe déployant des agents dans la finance, la santé ou le secteur public.

La mémoire d'agent repose sur une architecture enfichable couvrant l'historique conversationnel, l'état persistant et la recherche vectorielle. Vous n'êtes lié à aucun backend de mémoire particulier.

La configuration déclarative permet de définir agents et workflows en YAML. Le comportement des agents passe ainsi sous gestion de version et revue de code, au lieu d'être enfoui dans le code applicatif — un petit changement qui simplifie énormément la gouvernance.

Faut-il migrer ?

Si vous êtes sur Semantic Kernel ou AutoGen, la réponse est à terme oui. Microsoft publie des guides de migration dédiés pour les deux, incluant analyse de code et plans étape par étape. Le framework est explicitement présenté comme la génération suivante des deux projets, ce qui vous indique où va l'investissement.

Le séquencement pratique que nous recommandons :

1. Commencez par le nouveau. Construisez votre prochain agent sur Agent Framework plutôt que de rétrofiter un système en production.
2. Migrez les projets AutoGen avant ceux en Semantic Kernel. Les abstractions d'AutoGen se transposent plus directement sur le nouveau modèle d'agent.
3. Réservez les workflows aux processus que vous maîtrisez déjà. N'utilisez pas le moteur graphique pour découvrir votre processus métier, mais pour encoder celui que vous avez déjà cartographié.
4. Branchez middleware et télémétrie dès le premier jour. Ajouter l'observabilité après coup sur un système d'agents vivant est bien plus douloureux que de démarrer avec.

Une mise en garde des notes de version mérite d'être répétée : si vous connectez Agent Framework à des serveurs, agents ou modèles tiers hors Azure, ceux-ci sont régis par leurs propres licences et vous êtes responsable des données qui y transitent. Pour les équipes de la région MENA soumises à des exigences de résidence des données, cette frontière doit être revue explicitement avant de connecter quoi que ce soit hors de votre périmètre de conformité.

La vue d'ensemble

Agent Framework 1.0 n'est pas une idée neuve — c'est une consolidation. Le signal intéressant est que les frameworks d'agents du secteur convergent vers la même forme : agents typés, workflows graphiques, MCP pour les outils, A2A pour l'interopérabilité, points de reprise pour la durabilité. LangGraph y est arrivé par une voie, Agent Framework par une autre, et le camp de l'exécution durable par une troisième.

Cette convergence est une bonne nouvelle. Elle signifie que les patterns d'architecture appris aujourd'hui sont transférables, et que les outils bâtis sur MCP continueront de fonctionner pendant que la couche framework se recompose en dessous.

Pour les équipes déjà investies dans .NET ou Azure, Agent Framework 1.0 est le choix par défaut évident. Pour les autres, il mérite d'être étudié comme la déclaration la plus claire à ce jour de ce à quoi doit ressembler une plateforme d'agents de production.

Chez Noqta, nous aidons les équipes à concevoir et déployer des systèmes agentiques qui survivent au contact de la production — orchestration, observabilité et gouvernance comprises. Si vous évaluez des frameworks d'agents pour une charge de travail réelle, contactez-nous.