Si vous avez évalué Microsoft AutoGen au cours des deux dernières années puis perdu de vue le projet, vous avez peut-être manqué une rupture significative. Le dépôt AutoGen original a été forké — et deux projets distincts se disputent désormais la même notoriété. Pour toute équipe qui doit décider où construire un système multi-agents, cette scission n’est pas une simple note de bas de page. Elle change la codebase sur laquelle vous vous engagez réellement.
Cet article fait le point. Nous expliquons ce qui s’est passé, ce que chaque branche fait bien, et donnons un verdict clair sur la question de savoir si AutoGen ou son fork AG2 a sa place dans une build en production aujourd’hui — en particulier au sein d’un parc informatique fortement orienté Azure ou Microsoft.
Ce qui s’est vraiment passé : AutoGen, AG2 et le Microsoft Agent Framework
AutoGen est né comme un projet de Microsoft Research. Son idée centrale — laisser plusieurs agents pilotés par des LLM converser entre eux pour résoudre des problèmes de manière collaborative — était genuinement novatrice à son lancement, et la communauté de recherche l’a rapidement adoptée.
Le fork a eu lieu parce que les ambitions de Microsoft pour le projet ont dépassé ses origines en laboratoire de recherche. Fin 2024, une part significative des contributeurs originaux d’AutoGen est partie et a relancé le projet sous le nom AG2 (également disponible sous le nom de package ag2 et le domaine communautaire ag2ai). Objectif déclaré : maintenir une structure de gouvernance ouverte, pilotée par la communauté, indépendante de toute feuille de route d’entreprise unique.
En parallèle, Microsoft a reconstruit ce qui restait de la lignée originale d’AutoGen. Le résultat immédiat a été AutoGen 0.4 — une réécriture complète avec des internals asynchrones et event-driven, publiée en janvier 2025. Ce n’était pas la fin de l’histoire : en octobre 2025, Microsoft a placé AutoGen 0.4 en mode maintenance (correctifs de bugs et patches de sécurité uniquement, aucune nouvelle fonctionnalité) et a lancé le Microsoft Agent Framework comme successeur officiel, fusionnant AutoGen et Semantic Kernel dans un seul SDK. L’Agent Framework a atteint la v1.0 en avril 2026 et constitue désormais le chemin actif soutenu par Microsoft. AutoGen 0.4+ est donc un framework déprécié aux fonctionnalités gelées à la date de rédaction de cet article. Côté hébergé, ces concepts alimentent l’Azure AI Agent Service et la pile Azure AI Foundry au sens large.
Ainsi, quand quelqu’un dit « j’utilise AutoGen », il peut vouloir dire :
- AG2 (le fork communautaire) : Le framework Python le plus activement maintenu, le plus fidèle en esprit au modèle de conversation multi-agents original. Disponible sur
github.com/ag2ai/ag2. - Microsoft AutoGen 0.4 : Internals réécrits, intégration Azure plus étroite, surface d’API divergente. En mode maintenance désormais — aucune nouvelle fonctionnalité. Disponible sur
github.com/microsoft/autogen. - Microsoft Agent Framework (v1.0, avril 2026) : Le successeur actif de Microsoft, qui fusionne AutoGen et Semantic Kernel. Python et .NET (C#) pris en charge comme langages de première classe équivalents. La cible de build à utiliser si vous êtes engagé dans l’écosystème Microsoft.
- Azure AI Foundry Agent Service : La direction hébergée/gérée de Microsoft, propulsée par l’Agent Framework — une catégorie de produit entièrement différente.
Pour la plupart des décideurs évaluant cela pour une build en production, la question pratique est : AG2 ou la lignée AutoGen maintenue par Microsoft ? Ce ne sont plus la même chose.
Là où la conversation multi-agents brille — et où AutoGen/AG2 a ouvert la voie
L’intuition originale derrière AutoGen était importante : beaucoup de tâches IA non triviales sont mieux gérées par une conversation structurée entre agents spécialisés que par un seul généraliste surchargé. Un agent planner décompose un objectif, un agent coder écrit le script, un agent reviewer le vérifie, un agent executor l’exécute et rend compte des résultats. Chaque agent a un rôle défini, et le protocole de conversation les coordonne.
Ce modèle s’applique bien à :
- Les workflows de recherche et d’analyse — synthèse de sources multiples, vérification croisée des résultats, itération sur les ébauches
- L’assistance au développement logiciel — tâches de coding multi-étapes avec des boucles de révision et de test
- Le Q&A interne avec accès aux outils — agents capables d’interroger des bases de données, d’appeler des API, puis de raisonner sur les résultats avant de répondre
L’architecture conversationnelle par passage de messages produit des chaînes de raisonnement observables et déboguables. Vous pouvez voir ce que chaque agent a dit aux autres et pourquoi une décision a été prise. Pour les secteurs réglementés ou les opérations soucieuses du risque, cette traçabilité a de la valeur. Lisez notre article sur les systèmes multi-agents pour un regard plus large sur les cas où cette architecture fait sens.
AG2 vs Microsoft AutoGen : sur quelle branche construire aujourd’hui
Voici une comparaison directe selon les dimensions qui comptent pour une build d’entreprise :
| Dimension | AG2 (fork communautaire) | Microsoft Agent Framework |
|---|---|---|
| Stabilité des API | Plus stable ; plus proche de l’API originale | v1.0 depuis avril 2026 ; 0.4 avait des breaking changes |
| Activité communautaire | Élevée ; mainteneurs core originaux | Soutenu par Microsoft ; communauté AutoGen 0.4 migrant vers l’Agent Framework |
| Intégration Azure | Manuelle ; apportez vos propres connecteurs | Support de première classe pour Azure OpenAI et AI Foundry |
| Outillage de production | En progression mais encore limité | Optimisé pour le stack Microsoft |
| Support des langages | Python uniquement | Python et .NET (C#) comme langages de première classe équivalents |
| Support des LLM non-Azure | Bon | Possible mais clairement non primaire |
| Option hébergée/gérée | Aucune | Azure AI Foundry Agent Service |
Le verdict : Si vous construisez sur Azure et que votre parc informatique est centré sur Microsoft, le Microsoft Agent Framework — ou Azure AI Foundry Agent Service — est la voie pragmatique. Intégration plus étroite, un vrai modèle de support et un SDK en développement actif. Notez qu’AutoGen 0.4 lui-même est passé en mode maintenance ; si vous démarrez un nouveau projet, ciblez directement l’Agent Framework.
Si vous cherchez un framework Python neutre pour des workflows multi-agents et n’êtes pas lié à Azure, AG2 est le projet le plus actif et a mieux préservé l’intention de conception originale.
AutoGen / AG2 est-il vraiment prêt pour la production ?
C’est là qu’une évaluation honnête exige de distinguer « peut-on construire quelque chose qui fonctionne » de « est-ce robuste pour des opérations d’entreprise ».
Là où les deux branches peinent à la frontière de la production :
- Fiabilité sur de longues chaînes de conversation. Les conversations multi-agents peuvent dériver, boucler ou produire des résultats incohérents à mesure que les fenêtres de contexte se remplissent. Les guardrails nécessitent un travail d’ingénierie explicite — ils ne sont pas fournis clés en main.
- Observabilité. Reconstituer ce qui s’est passé sur cinq agents lors d’un run échoué est plus difficile que ça ne devrait l’être. AutoGen 0.4 a introduit le tracing basé sur OpenTelemetry comme fonctionnalité de première classe, ce qui constitue une amélioration réelle par rapport à la v0.2. En pratique, la documentation d’instrumentation ne couvre que la Core API de bas niveau ; les abstractions au niveau AgentChat manquent de documentation dédiée au tracing, et les configurations multi-composants peuvent déclencher des conflits de fournisseurs. Pour une build en production, prévoyez d’investir dans la mise en place de l’observabilité au-delà de ce qui est documenté.
- Gestion des erreurs. Quand une étape d’agent échoue en milieu de workflow — un timeout d’API, une mauvaise réponse d’outil — aucune des deux branches n’a de logique de retry et de compensation robuste intégrée. Vous la construisez vous-même.
- Patterns de déploiement. AutoGen et AG2 sont des frameworks, pas des plateformes. Il n’y a pas de scheduler intégré, pas de queue gérée, pas de cible de déploiement. Vous apportez votre propre infrastructure.
Comparez cela avec le test de maturité production que nous appliquons à tous les frameworks d’agents : observabilité, gestion des erreurs, gestion de l’état, déploiement et contrôles de sécurité. Selon ce référentiel, les deux branches d’AutoGen obtiennent de bons résultats sur la couche raisonnement et conversation, et de mauvais résultats sur la couche opérationnelle.
Ce n’est pas un critère éliminatoire. Cela signifie que vous construisez le scaffolding opérationnel par-dessus — ou vous utilisez un framework plus opinioné qui l’intègre déjà.
Qui devrait réellement envisager AutoGen ou AG2
Cas d’usage adaptés :
- Les équipes déjà investies dans l’écosystème Microsoft/Azure, où l’Azure AI Foundry Agent Service — construit sur le Microsoft Agent Framework — ajoute une infrastructure gérée autour des workflows multi-agents
- Les applications proches de la recherche — synthèse de connaissances internes, tâches d’analyse longue durée, révision de documents complexes — où le modèle d’agents conversationnels s’adapte naturellement au workflow
- Les équipes de développement Python-native qui veulent un contrôle fin sur la conception de la conversation des agents et sont à l’aise pour construire leur propre couche de déploiement
- Les organisations qui pilotent le raisonnement multi-agents avant de s’engager sur un framework d’orchestration plus lourd comme LangGraph
Cas d’usage inadaptés :
- Les équipes qui ont besoin d’une plateforme d’agents prête pour la production avec scheduling, observabilité et déploiement intégrés sans travail d’infrastructure custom significatif
- Les projets nécessitant une intégration TypeScript ou JavaScript — AG2 est Python uniquement, et le Microsoft Agent Framework supporte Python et .NET (C#) mais pas TypeScript ou JavaScript directement
- L’automatisation de tâches simples qui ne nécessitent pas de raisonnement multi-agents — le surcoût n’en vaut pas la peine
- Les organisations sans présence Azure qui souhaitent un hébergement géré — il n’existe pas d’option gérée neutre pour AG2
Pour une comparaison plus large des frameworks Python, notre sélection de frameworks d’agents open source explique comment AutoGen/AG2 se positionne aux côtés de LangGraph, CrewAI et d’autres. Si vous évaluez spécifiquement les options multi-agents basées sur Python, CrewAI vs LangGraph est une lecture complémentaire utile.
Le cas Azure : quand le stack Microsoft comble l’écart
Un scénario où le Microsoft Agent Framework devient véritablement convaincant : votre organisation utilise déjà Azure OpenAI Service et Azure AI Foundry, et des déploiements Microsoft 365 Copilot sont en cours. Dans ce contexte, l’Azure AI Foundry Agent Service — construit sur le Microsoft Agent Framework — vous offre :
- Exécution des agents gérée avec le profil de conformité et de sécurité d’Azure
- Connectivité native aux modèles Azure OpenAI sans configuration supplémentaire
- Intégration avec la gestion des identités et des accès Microsoft
- Un chemin vers Copilot Studio pour les utilisateurs moins techniques afin d’interagir avec la même infrastructure d’agents
Pour une PME suisse ou européenne avec des exigences strictes de résidence des données et un accord Microsoft EA existant, ce n’est pas un avantage négligeable. Les centres de données européens d’Azure et les certifications de conformité ont de l’importance, et le coût d’intégration que vous dépenseriez autrement sur un framework neutre est partiellement compensé par le support Azure de première classe.
La mise en garde : vous dépendez désormais d’une feuille de route produit Microsoft, et le rythme de changement dans ce stack a été élevé — trois transitions majeures de framework en moins de trois ans. Ce qui se trouve sous l’Azure AI Foundry Agent Service aujourd’hui pourrait être substantiellement différent dans douze mois. Construisez sur des interfaces, pas sur les internals du framework.
La question décisive à se poser avant de choisir un framework
Le choix du framework mérite rarement le poids stratégique que les ingénieurs lui accordent. Les questions plus importantes sont :
- Que doit concrètement faire l’agent, et le modèle de conversation multi-agents convient-il à cette tâche ?
- Quelle infrastructure avons-nous déjà, et quelles lacunes opérationnelles le framework crée-t-il ?
- Quelle part de notre capacité d’ingénierie est consacrée à la plomberie du framework plutôt qu’au problème réel que nous résolvons ?
AutoGen et AG2 répondent bien à la première question pour les tâches de raisonnement collaboratif. Ils laissent les questions deux et trois largement à votre charge.
Cet overhead d’ingénierie est réel. Chez Orange ITS, le choix du framework suit le cas d’usage et les exigences opérationnelles — pas l’inverse. Une société de services professionnels de 50 personnes n’a pas le même calcul qu’une fintech avec une équipe MLOps dédiée.
Discutez de votre projet d’agents avant de vous engager sur un framework
Choisir entre AG2, la lignée Microsoft AutoGen, LangGraph ou un développement sur mesure dépend de votre stack, de la capacité de votre équipe et de la quantité d’infrastructure opérationnelle que vous souhaitez gérer vous-même.
Si vous êtes en phase d’évaluation, un appel de 30 minutes avec l’équipe Orange ITS peut vous faire économiser des semaines d’expérimentation avec des frameworks. Nous examinerons votre cas d’usage, votre infrastructure existante, et vous donnerons une vision directe de l’approche susceptible d’aboutir — et de celle susceptible de bloquer.