LangGraph face à AutoGen : quel choix après l’archivage ?

Le choix entre AutoGen et LangGraph est désormais une question de migration : au 27 octobre 2026, le README d’AutoGen indique que Microsoft a archivé le projet et n’en assure plus la maintenance. Privilégiez LangGraph pour maîtriser explicitement un workflow avec état ; choisissez Microsoft Agent Framework si la continuité avec l’écosystème d’agents de Microsoft prime. Un prototype AutoGen existant constitue une base utile pour préparer la migration, mais un mauvais socle pour un nouveau système en production. Statut actuel d’AutoGen.

LangGraph ou AutoGen : lequel choisir ?

Choisissez LangGraph pour un nouveau système qui doit suivre l’avancement du travail, attendre une approbation et reprendre de façon prévisible. LangGraph, le moteur d’orchestration développé par LangChain, permet de décrire l’application comme un ensemble d’étapes reliées par un état explicite. Ce modèle convient à un workflow de support où le brouillon, le résultat de la vérification et l’autorisation doivent rester distincts après le redémarrage du processus de traitement.

Choisissez Microsoft Agent Framework pour migrer une application AutoGen liée à l’écosystème Microsoft, notamment une application .NET existante. Ce successeur proposé par Microsoft associe des abstractions d’agents à des workflows. Rester dans cet écosystème exige toutefois de revoir l’orchestration et la gestion de l’état : le changement ne se limite pas au nom du package. Présentation du framework Microsoft.

Conservez un prototype AutoGen existant uniquement comme référence, dans un périmètre limité, le temps de migrer. Préservez les prompts, les contrats des outils et les exemples qui font sa valeur. Évitez de lui confier de nouvelles responsabilités en comptant sur un engagement de maintenance qui n’existe plus.

La décision repose sur trois critères : qui maintient le socle technique, où réside l’état de l’application et comment reprend un traitement mis en pause. Ces conclusions s’appuient sur la documentation, pas sur des benchmarks de vitesse ou de qualité des modèles. Les pages des éditeurs et les documentations citées ici ont été vérifiées le 27 octobre 2026.

Les détails techniques de ce tableau proviennent du guide des équipes AutoGen, du guide de gestion de l’état AutoGen, de la Graph API de LangGraph et de la documentation sur la persistance dans LangGraph.

AutoGen est archivé : la maintenance n’est plus assurée

AutoGen, le framework de Microsoft pour faire collaborer des agents IA, affiche désormais cet avertissement dans son README : « Projet archivé et désormais non maintenu ». Le même avis précise que Microsoft ne fournit plus de corrections de bugs, de correctifs de sécurité, de fonctionnalités ni de support, et encourage les utilisateurs existants à migrer. La recommandation adressée aux nouveaux utilisateurs est sans ambiguïté : « Les nouveaux utilisateurs doivent commencer avec Microsoft Agent Framework. » README d’AutoGen chez Microsoft.

Les anciennes déclarations de Microsoft expliquent pourquoi certains développeurs peuvent avoir une autre politique en tête. Le billet de lancement du 1er octobre 2025 indiquait : « Les deux projets continueront d’être pris en charge, mais l’essentiel des investissements porte désormais sur Microsoft Agent Framework. » C’était la position annoncée au lancement pour AutoGen et Semantic Kernel, le précédent framework de Microsoft destiné aux agents et aux applications d’IA. Elle ne prévaut pas sur l’avertissement actuel d’AutoGen. Billet de présentation de Microsoft.

Le point d’actualité BUILD publié par Microsoft le 3 juin 2026 précise également : « MAF a atteint la version 1.0 GA le 2 avril 2026 ». GA signifie disponibilité générale. Il serait donc inexact de présenter le successeur comme s’il en était encore à la préversion annoncée lors du lancement. Actualités BUILD de Microsoft.

Pour un nouveau projet à départager entre AutoGen et LangGraph, LangGraph l’emporte. Le statut de support d’AutoGen tranche cette partie du choix avant même d’examiner son API de conversation. Microsoft Agent Framework reste une autre option de migration actuelle, à évaluer séparément.

Conversation entre agents ou graphe avec état explicite ?

AutoGen AgentChat fait de la conversation son unité d’organisation naturelle ; LangGraph rend explicites l’état de l’application et ses transitions. Les deux savent coordonner des agents. La différence utile tient à ce qu’il faut préciser lorsqu’un problème survient ou qu’une personne doit intervenir.

AutoGen : les agents prennent la parole et examinent les messages

AutoGen AgentChat est l’API d’équipes de haut niveau construite sur Core, le moteur événementiel d’AutoGen. Avec RoundRobinGroupChat, les participants interviennent à tour de rôle et diffusent leurs réponses à tout le groupe. Un agent rédacteur peut proposer une réponse, puis un agent relecteur la remettre en question. Avec SelectorGroupChat, c’est un modèle qui choisit le prochain intervenant. Modèles d’équipes AutoGen.

C’est une manière intuitive de formaliser un échange dont on comprend déjà le déroulement. Les choses se compliquent lorsque l’historique doit aussi servir de registre opérationnel. Le mot « approuvé » peut désigner l’exactitude factuelle du brouillon, le consentement d’un client ou une autorisation humaine. L’application doit distinguer ces significations avant d’effectuer une action externe.

La limite d’AutoGen se situe entre une conversation utile et un processus métier capable de reprendre après une interruption, difficulté à laquelle s’ajoute désormais son archivage. Ajouter des prompts ne détermine ni quel artefact sauvegardé fait foi, ni quelle action a déjà été exécutée.

Il serait tout aussi faux d’affirmer qu’AutoGen ne sait pas représenter des graphes. Son API expérimentale GraphFlow prend en charge les séquences, les branches, le travail en parallèle et les boucles. Une limite plus subtile compte davantage : le graphe d’exécution ne détermine pas quels messages un agent peut voir. Par défaut, les messages sont diffusés à tous ; leur filtrage relève d’un mécanisme distinct. Une arête qui indique « le relecteur intervient ensuite » ne constitue pas une restriction d’accès aux données. Documentation de GraphFlow.

Pour comprendre un prototype conversationnel existant, AutoGen AgentChat a l’avantage. Son abstraction d’équipe permet d’en expliquer simplement le fonctionnement. C’est une raison de bien comprendre le code avant de migrer, pas de lancer un nouveau déploiement sur cette base.

LangGraph : l’application gère un état de travail structuré

LangGraph est un moteur de bas niveau pour les workflows avec état. Un nœud exécute une tâche, une arête détermine l’étape suivante et l’état constitue le dossier de travail structuré transmis dans l’application. Les nœuds peuvent contenir des appels à des modèles ou des fonctions ordinaires. Présentation de LangGraph.

Pour une réponse de support, l’état peut contenir l’identifiant du ticket, le texte source validé, le brouillon en cours, les observations de la relecture et la décision humaine. Un nœud de relecture met à jour les observations. Une arête conditionnelle renvoie un brouillon refusé vers la révision ou fait avancer un brouillon acceptable vers l’approbation. Le choix des champs et des règles relève de la conception de l’application.

Un reducer définit comment combiner une mise à jour avec la valeur existante d’un champ de l’état. On peut, par exemple, remplacer le brouillon courant tout en accumulant les notes de relecture. Un mauvais choix peut laisser des observations périmées associées à une réponse déjà révisée. Mises à jour de l’état et reducers.

La limite de LangGraph est le travail de conception qu’il oblige à expliciter. Le schéma, les règles de routage et le comportement en cas d’échec sont à votre charge. Un graphe peut aussi intégrer des décisions prises par un modèle et des boucles ; le dessiner ne rend pas le texte généré reproductible ou correct.

Pour maîtriser l’état métier d’un workflow, LangGraph l’emporte. Le bénéfice est un dossier consultable directement, sans devoir déduire l’avancement des échanges entre agents.

LangGraph ou LangChain : à quel niveau travailler ?

LangChain fournit un framework de plus haut niveau pour les modèles, les outils et les boucles d’agents ; LangGraph assure l’orchestration sous-jacente. Il est possible d’utiliser LangGraph sans adopter les composants de LangChain. Articulation des différentes couches.

Avant de migrer depuis AutoGen, déterminez si l’application a besoin d’un workflow sur mesure. Un petit assistant qui appelle un outil puis renvoie une réponse n’a pas forcément besoin de cette structure supplémentaire. Le comparatif LangChain et LangGraph détaille ce choix.

Une même tâche à deux agents dans chaque framework

Comparez la coordination avec un rédacteur et un relecteur, en gardant l’envoi hors du périmètre de ces deux agents. Prenons une réponse de support fondée sur un ticket client fixe et un extrait validé de la base de connaissances. Le rédacteur propose une réponse. Le relecteur confronte chaque affirmation à l’extrait, puis demande des modifications ou accepte le brouillon. Une personne autorise l’envoi séparément.

Il s’agit d’un exemple de conception, pas d’un benchmark exécuté. Les deux implémentations reçoivent les mêmes entrées, prompts et critères de relecture. Aucun des agents ne dispose d’un outil d’envoi. La comparaison reste ainsi centrée sur une question : comment le framework représente-t-il le travail et ses points d’arrêt ?

Ces conceptions s’appuient sur le modèle d’équipe avec relecture d’AutoGen, les retours entre exécutions, le routage de LangGraph et les interruptions.

Que faut-il configurer dans AutoGen ?

Créez le rédacteur et le relecteur avec des instructions distinctes, puis placez-les dans RoundRobinGroupChat. Le tutoriel officiel utilise TextMentionTermination pour arrêter l’exécution lorsqu’un mot apparaît dans la réponse d’un agent. Dans cette application, cet arrêt doit marquer la fin de la relecture automatisée, jamais une autorisation d’envoi. Examinez le résultat et conservez le brouillon effectivement évalué par le relecteur.

Fixez une limite aux révisions dans les règles de l’application. Si le relecteur continue de relever des affirmations non étayées, transmettez le dossier à une personne avec les observations. Une conversation non résolue ne doit pas devenir une tentative sans fin d’obtenir un marqueur de réussite.

Le travail d’ingénierie supplémentaire se situe hors du dialogue : enregistrer le ticket traité, sauvegarder le résultat de la relecture, conserver l’état de l’équipe à un point d’arrêt sûr et rattacher les retours humains ultérieurs au bon brouillon. Le tutoriel sur l’état fournit des primitives de sérialisation, pas une politique complète de reprise pour votre application.

Que faut-il configurer dans LangGraph ?

Définissez des champs d’application tels que ticket_id, source_text, draft, review, approved et send_receipt. Reliez la rédaction à la relecture. En cas de refus, revenez à la révision tant que les règles l’autorisent ; sinon, arrêtez le traitement pour une prise en charge manuelle. Une relecture satisfaisante mène à l’étape d’approbation humaine.

Une règle utile consiste à invalider toute approbation précédente dès que le brouillon change. Sans cela, une personne peut approuver un texte tandis que l’application en envoie ensuite un autre. C’est un invariant métier, une condition que l’application doit toujours faire respecter, et non une fonctionnalité du framework.

L’envoi doit passer par une fonction ordinaire distincte, après l’approbation. Cette fonction enregistre l’accusé de réception du système externe en l’associant au ticket et au brouillon approuvé. Le résultat de la relecture par l’agent et l’autorisation de la personne restent dans des champs distincts.

Dès que l’approbation différée et la reprise comptent pour cette tâche, LangGraph l’emporte. AutoGen décrit clairement les échanges ; le graphe exprime plus directement le dossier opérationnel et les conditions qui encadrent son traitement. Si la tâche s’arrête à un brouillon non envoyé et se relance facilement, la migration impose moins d’exigences sur le workflow.

Checkpoints et intervention humaine : que garantit la reprise ?

Sauvegarder l’état d’une conversation est utile, mais n’offre pas les mêmes garanties que reprendre un workflow. AutoGen propose save_state() et load_state() sur les agents et les équipes. L’application peut enregistrer cet état dans un fichier ou une base de données. Affirmer qu’AutoGen n’a « aucune mémoire » décrirait mal l’API disponible. Gestion de l’état dans AutoGen.

LangGraph utilise un checkpointer, un composant qui sauvegarde l’état du graphe pour un thread. Le thread identifie un travail qui se poursuit dans le temps. Un store distinct conserve les données de l’application qui doivent être accessibles entre plusieurs threads. Le premier sert à poursuivre le traitement du ticket courant ; le second, si nécessaire, à partager des informations durables. Principes de persistance.

Le choix du stockage est déterminant. InMemorySaver et MemorySaver conservent les checkpoints en mémoire vive ; ils disparaissent au redémarrage du processus. Un prototype qui démontre une interruption avec un stockage en mémoire ne démontre donc pas la reprise après redémarrage. Cette exigence nécessite un stockage persistant. Résolution des problèmes de persistance.

Pour une validation différée, interrupt() dans LangGraph suspend l’exécution en attendant une entrée externe. La reprise utilise Command(resume=...) et le même thread_id que l’exécution interrompue. Cet identifiant rattache la décision reçue au travail sauvegardé. Fonctionnement des interruptions dans LangGraph.

Le UserProxyAgent d’AutoGen peut solliciter un retour humain pendant une exécution, mais sa documentation prévient que l’équipe en attente se trouve alors bloquée dans un état impossible à sauvegarder ou à reprendre. Si la personne risque de répondre plus tard, l’alternative documentée consiste à terminer l’exécution, sauvegarder l’état, puis poursuivre avec son retour lors d’une exécution ultérieure. Retours humains dans AutoGen.

Dans l’exemple du support, protégez l’envoi avec un identifiant de requête géré par l’application et un accusé d’envoi enregistré. Placez l’opération après l’approbation et concevez-la pour tolérer les requêtes répétées. La présence d’un point d’approbation ne suffit pas, à elle seule, à rendre transactionnel un service d’envoi d’e-mails distinct.

Pour une approbation différée qui doit résister aux redémarrages, LangGraph l’emporte, à condition de configurer un stockage durable et de prévoir explicitement les réexécutions. Ni un checkpoint ni un historique de conversation ne prouve qu’une action externe a eu lieu exactement une fois.

Migrer vers LangGraph ou Microsoft Agent Framework ?

Choisissez la destination en fonction des contrôles à maîtriser, puis évaluez la réécriture par rapport à votre application actuelle. Quitter AutoGen ne signifie pas automatiquement choisir LangGraph.

LangGraph vs AutoGen : que faire d’un prototype existant ?

Choisissez LangGraph si la difficulté du prototype vient d’un état ambigu : vous ne savez pas quel artefact est à jour, à quel endroit reprendre un traitement en échec ou si une personne a approuvé la version actuelle. Traduisez ces incertitudes en champs et en transitions explicites avant de porter les prompts.

Le changement utile consiste à rendre ces exigences vérifiables. Recréer l’ancien historique dans un graphe en laissant toutes les décisions importantes enfouies dans les messages ajoute une dépendance sans apporter beaucoup d’amélioration opérationnelle.

Si les rôles des agents n’apportent ni outils, ni contexte, ni responsabilités de vérification distincts, simplifiez-les pendant la migration. Le guide des systèmes multi-agents explique dans quels cas un agent unique constitue un meilleur choix de conception.

Microsoft Agent Framework pour rester dans le même écosystème

Microsoft Agent Framework est le successeur direct d’AutoGen et de Semantic Kernel chez Microsoft. Il propose des agents et des workflows qui relient ces agents à des fonctions ordinaires. C’est le candidat à étudier en priorité lorsque l’application et l’équipe qui l’exploite dépendent déjà de l’écosystème d’agents de Microsoft ou de .NET. Ce jugement porte sur l’intégration ; il ne signifie pas que LangGraph ne pourrait pas prendre en charge le même processus métier. Présentation d’Agent Framework.

Le guide actuel fait correspondre AssistantAgent à Agent, explique la continuité des conversations avec AgentSession et remplace la coordination des équipes par des modèles de workflows. Ces workflows fournissent des flux de données typés, des demandes de saisie humaine et des checkpoints. Le comportement des itérations d’appels d’outils diffère également : rejouez donc vos séquences d’outils pendant la migration. Guide de migration depuis AutoGen.

La lacune de migration explicitement identifiée concerne les moteurs d’exécution distribués sur mesure. Le guide décrit actuellement la composition d’Agent Framework comme limitée à un seul processus et présente l’exécution distribuée comme prévue. Si votre prototype AutoGen utilise le moteur Core distribué, ne supposez pas qu’un portage des agents préservera la topologie de déploiement. Validez cette exigence séparément avec le moteur et l’option d’hébergement réellement envisagés. Il s’agit d’une limite énoncée dans le guide de migration, pas d’une affirmation générale sur tous les services d’hébergement Microsoft.

Pour assurer la continuité avec le successeur Microsoft, Microsoft Agent Framework l’emporte. Sa limite est la compatibilité : des concepts d’agents familiers ne garantissent pas un routage des messages, un comportement des sessions ou une topologie d’exécution identiques. LangGraph prend l’avantage lorsque la migration vise une refonte délibérée autour d’un état d’application explicite.

Quel est le coût d’une migration, et quand éviter de se précipiter ?

Le coût de migration tient à la reconstruction du comportement, à la conversion de l’état et à la validation opérationnelle. Les prompts et les implémentations des outils peuvent être réutilisables, mais il faut examiner leurs règles de déclenchement, de contexte et de persistance. Estimez l’effort à partir d’une opération métier complète, pas du nombre d’imports à renommer.

Commencez par la réponse de support. Elle comporte une entrée observable, un brouillon, une décision de relecture, un point d’approbation humaine et un accusé final. C’est un meilleur périmètre de migration que le déplacement d’un ensemble complet d’agents avec pour seul espoir de retrouver une réponse finale familière.

1. 1

   Documenter le comportement existant

   Sauvegardez des entrées représentatives, les sources validées, les prompts, les schémas des outils, les sorties et les cas d’échec. Notez les versions des modèles et des dépendances. Incluez un cas refusé par le relecteur et un autre qui nécessite une clarification humaine. Ces exemples serviront de critères d’acceptation pour la nouvelle implémentation.

2. 2

   Exporter les données de l’application dans un format indépendant

   Conservez les identifiants de tickets, les brouillons, les observations de relecture, les décisions humaines et les accusés des actions externes dans un format propre à l’application. Gardez les historiques pour le contexte, mais ne considérez pas le bloc d’état sérialisé d’un framework comme un dossier métier portable. Définissez explicitement les correspondances pour toutes les données nécessaires à la poursuite du traitement.

3. 3

   Reconstruire le plus petit workflow complet

   Dans LangGraph, définissez le schéma d’état et les routes. Dans Microsoft Agent Framework, établissez les correspondances entre agents, sessions et exécuteurs de workflow à l’aide du guide actuel. Conservez les mêmes entrées et critères d’évaluation pour distinguer les changements d’orchestration de ceux du modèle ou du prompt.

4. 4

   Tester les points de reprise en cas d’échec

   Arrêtez le processus de traitement alors qu’une tâche attend une approbation. Reprenez-la après redémarrage, refusez un brouillon, répétez une demande de reprise et simulez l’échec d’une action externe. Examinez les données sauvegardées par l’application et l’accusé final. Un paragraphe final plausible ne suffit pas à prouver que le workflow a repris correctement.

5. 5

   Décider du sort des traitements déjà en cours

   Déterminez si les tâches en attente se terminent dans l’ancienne implémentation ou font l’objet d’une conversion explicite de leur état. Préservez les identifiants et les associations entre approbations et brouillons. Ne transmettez pas silencieusement un ancien checkpoint à un nouveau workflow incompatible.

Une fois adopté, LangGraph impose lui aussi des contraintes de migration. La documentation de sa Graph API met en garde contre le renommage ou la suppression de nœuds nécessaires à des threads interrompus. Lors des futurs déploiements, les définitions de workflows et l’état sauvegardé doivent donc aussi être traités comme une frontière de compatibilité. Contraintes de migration des graphes.

Inutile de précipiter une réécriture générale d’un prototype de recherche isolé dont les résultats utiles ont déjà été conservés et qui doit être abandonné. Tirez-en les enseignements et ne migrez que le cas d’usage destiné à perdurer. Pour une application AutoGen active, une transition maîtrisée vaut mieux qu’un remplacement non validé. L’archivage reste toutefois une raison de planifier cette transition, pas de continuer à étendre le rôle de l’ancienne dépendance.

Pour élargir la sélection, le comparatif des frameworks d’agents IA présente d’autres points de départ. Si CrewAI reste en lice, consultez LangGraph vs CrewAI pour trancher ce choix précis.

Votre prochaine étape : prenez une tâche récurrente, listez les données qui doivent survivre à un redémarrage et définissez qui peut autoriser l’action finale. Choisissez le framework qui exprime le plus clairement ces exigences, puis validez ce périmètre complet avant de migrer le reste.

Questions fréquentes

Quelles sont les principales différences entre AutoGen et LangChain ?

AutoGen AgentChat organise la collaboration entre agents autour d’équipes et de messages. LangChain fournit des abstractions pour les modèles, les outils et les agents, tandis que LangGraph est le moteur d’orchestration sous-jacent. Pour un workflow sur mesure avec état, la comparaison avec LangGraph est plus directe. L’archivage d’AutoGen change aussi le choix pour les nouveaux projets.

Faut-il encore apprendre LangChain en 2026 ?

Oui, lorsque ses abstractions de modèles et d’outils répondent aux besoins de votre application. Apprenez directement LangGraph si vous devez définir l’état et les transitions du workflow. Migrer un prototype AutoGen n’oblige pas à adopter toutes les couches de l’écosystème.

CrewAI est-il meilleur que LangGraph ?

Il n’existe pas de vainqueur universel. Si l’état explicite, les points de reprise et une logique d’approbation sur mesure sont déterminants pour l’application, LangGraph est le premier candidat à évaluer. Comparez CrewAI sur la même tâche complète avant de choisir ; une préférence pour un framework ne suffit pas à établir la qualité du résultat.

Que désigne AutoGen ?

Dans ce comparatif, AutoGen désigne le framework d’applications multi-agents de Microsoft, disponible dans le dépôt microsoft/autogen. L’implémentation étudiée est son API d’équipes AgentChat ; le moteur Core sous-jacent et l’API expérimentale GraphFlow sont distingués lorsque c’est pertinent.

AutoGen est-il obsolète ?

Le README actuel de Microsoft emploie un statut plus fort : le projet est « archivé » et n’est plus maintenu. Il oriente les nouveaux utilisateurs vers Microsoft Agent Framework et encourage les utilisateurs existants à migrer. Retenez cette formulation actuelle au lieu de supposer que le projet bénéficie encore d’une phase de maintenance.

AutoGen et Microsoft Agent Framework sont-ils la même chose ?

Non. Microsoft Agent Framework est le successeur, avec un guide de migration qui détaille les changements d’API pour les agents, les sessions, les outils et les workflows. La migration exige de valider le comportement de l’application ; il ne s’agit pas simplement d’un nouveau nom pour le package AutoGen installé.

Quel est le meilleur framework d’IA agentique ?

Pour le cas traité ici, choisissez LangGraph si l’état explicite de l’application et la maîtrise du workflow sont décisifs. Choisissez Microsoft Agent Framework si la voie de succession proposée par Microsoft et votre écosystème existant priment. Un framework ne peut pas déterminer à votre place si la tâche nécessite plusieurs agents.

Quelles sont les principales différences entre AutoGen et Semantic Kernel ?

Le billet de présentation de Microsoft décrit l’apport d’AutoGen comme une orchestration multi-agents expérimentale, et celui de Semantic Kernel comme un socle de SDK pour les applications d’entreprise. Microsoft Agent Framework réunit ces deux approches. Pour préparer une migration depuis AutoGen, évaluez le successeur actuel plutôt que de limiter le choix à cette ancienne distinction.

Quel est le meilleur framework multi-agents ?

Le meilleur choix est celui qui rend le comportement attendu clair et facile à maintenir. Pour le workflow de support présenté ici, LangGraph est recommandé, car la relecture, l’autorisation humaine et l’envoi doivent correspondre à des états distincts. Microsoft Agent Framework constitue l’alternative lorsque la continuité avec le successeur compte davantage.

Utilisez la checklist d’audit des workflows IA en entreprise pour définir la tâche, le point où une autorisation devient nécessaire et le responsable de son exploitation avant de migrer.