AutoGen en local : ce qui marche et ce qui casse

#Le modèle de conversation

Là où un cadriciel de chaînes demande de définir des étapes, AutoGen demande de définir des participants. Un agent assistant propose ; un agent mandataire vous représente, exécute éventuellement du code et renvoie le résultat ; une discussion de groupe fait intervenir plusieurs spécialistes sous un gestionnaire qui décide qui parle. Le comportement émerge de ces échanges.

C'est réellement puissant pour les tâches ouvertes — déboguer, itérer sur une analyse — et c'est exactement ce qui rend le coût imprévisible. Une chaîne fixe fait N appels au modèle. Une conversation en fait autant qu'il en faut, et « autant qu'il en faut » est décidé par le modèle dont vous doutez justement.

Cette conception a une conséquence directe sur le choix des rôles : plus il y a d'agents distincts dans la conversation, plus il y a de tours possibles avant qu'une réponse finale n'émerge, et plus le risque de dérive augmente. Deux agents qui se répondent en boucle sans jamais converger vers une conclusion sont le symptôme le plus fréquent en local, précisément parce qu'aucune limite n'a été posée avant le premier essai. Le nombre d'agents n'est donc pas seulement un choix d'architecture, c'est un multiplicateur direct du temps de calcul consommé sur votre propre carte graphique.

#AutoGen en mode maintenance : ce qui a changé

C'est le point que la plupart des tutoriels encore en ligne passent sous silence. Le dépôt officiel microsoft/autogen l'annonce lui-même noir sur blanc depuis le 2 octobre 2025 : le projet est en mode maintenance, il ne recevra plus de nouvelle fonctionnalité et sera géré par la communauté. Microsoft recommande aux nouveaux projets de partir directement sur Microsoft Agent Framework (MAF), le successeur qui fusionne les briques d'AutoGen avec celles de Semantic Kernel dans un seul kit de développement, sorti en disponibilité générale début avril 2026.

Les créateurs originaux d'AutoGen, Chi Wang et Qingyun Wu, ont quitté Microsoft fin 2024 et ont continué le développement sous le nom AG2, un fork sous licence Apache 2.0, hébergé par l'organisation ag2ai. AG2 se présente comme la continuation active du projet plutôt que comme une rupture : la base historique reste accessible sous le nom AG2 Classic pour qui ne veut rien changer à son code, pendant qu'AG2 1.0 fait évoluer l'architecture vers un protocole plus explicite entre agents. Pour un projet qui démarre aujourd'hui, AG2 est le choix le plus cohérent si vous voulez rester proche de l'API AutoGen d'origine ; Microsoft Agent Framework est celui à regarder si vous êtes déjà dans l'écosystème Microsoft et que la fusion avec les outils Semantic Kernel vous concerne directement.

#Le brancher sur un modèle local

1. 01
   Servir le modèle

   Sur un point d'accès compatible OpenAI. Pour plusieurs agents qui parlent en même temps, un serveur conçu pour la concurrence se comporte bien mieux qu'un serveur pensé pour un poste unique.
2. 02
   Configurer le client

   Adresse de base (par exemple http://localhost:11434/v1 pour Ollama), nom du modèle exactement tel qu'il a été récupéré localement, clé factice. Les serveurs locaux ignorent la clé ; la bibliothèque cliente exige souvent qu'elle existe.
3. 03
   Déclarer honnêtement les capacités

   Les cadriciels demandent si le modèle gère l'appel de fonctions ou le mode JSON. Revendiquer une capacité absente produit des erreurs incompréhensibles plus loin, au lieu d'un échec propre.
4. 04
   Augmenter la fenêtre de contexte

   L'historique grossit à chaque tour. Un contexte par défaut tronque silencieusement le début, et les agents refont alors un travail déjà fait.

#L'exécution de code : à confiner

Le schéma qui rend AutoGen séduisant — un agent écrit du code, un mandataire l'exécute, l'erreur revient, l'agent corrige — est aussi celui qui fait tourner du code écrit par un modèle sur votre machine. On l'exécute dans un conteneur, sans identifiants, sans réseau si la tâche ne l'exige pas, jamais contre votre dossier personnel. Et tout contenu récupéré depuis l'extérieur — un ticket, une page web, un fichier de documentation — doit être considéré comme potentiellement hostile.

L'observabilité compte autant que le confinement. Sur une conversation à trois ou quatre agents, un incident se diagnostique en relisant le prompt exact reçu par chaque agent à chaque tour, pas un résumé après coup. Sans trace complète, on ne sait jamais si un agent a mal interprété une instruction ou s'il a simplement reçu un contexte tronqué par manque de mémoire. Journaliser chaque échange, y compris les appels d'outils et leurs arguments exacts, coûte peu et évite de deviner ce qui s'est produit une fois la carte graphique redevenue silencieuse.

#La taille du modèle, encore

Préférez des modèles entraînés à l'appel d'outils et à la sortie structurée. C'est le même plafond que rencontrent tous les cadriciels d'agents locaux : la prose est facile, les formats stricts ne le sont pas. Le rôle de gestionnaire, dans une discussion de groupe, mérite en général le modèle le plus capable dont vous disposez : c'est lui qui décide qui parle ensuite, et une mauvaise décision de routage coûte un tour entier à chaque erreur, répété autant de fois que la conversation continue de tourner sans converger.

• CrewAI : des rôles et des livrables ordonnés
• Architecture d'un agent local
• Créer un agent local en Python avec LangChain
• Le kit QuelLLM pour monter des agents locaux
• Dépôt officiel : annonce du mode maintenance
• AG2 : le fork activement développé
• L'API compatible OpenAI d'Ollama, officielle

#AutoGen, AG2 ou CrewAI

Sur du code déjà écrit avec l'API historique d'AutoGen, la migration vers AG2 est en général mineure : l'espace de noms autogen.* d'origine reste disponible dans une branche dédiée (AG2 Classic), le temps de basculer à votre rythme. Repartir de zéro aujourd'hui est une autre décision : autant choisir directement AG2 ou évaluer Microsoft Agent Framework plutôt que d'apprendre une base de code que son propre éditeur qualifie lui-même de gérée par la communauté.

#Ce que coûte réellement une conversation

Sur une API payante, une conversation à trois agents qui s'étire sur vingt tours se voit sur la facture. En local, elle se voit sur le ventilateur du boîtier et sur l'horloge murale. Chaque tour est une génération complète : si un tour dure en moyenne cinq secondes sur votre carte, vingt tours sans condition d'arrêt représentent au minimum une minute quarante de calcul continu, souvent bien plus une fois que le contexte a grossi et que chaque génération relit un historique plus long que la précédente. Rien ne vous alerte pendant que ça se produit — pas de compteur, pas de seuil, juste un GPU qui reste chaud.

C'est pour cela que la limite de tours n'est pas un détail de configuration parmi d'autres : c'est le seul mécanisme qui transforme un coût potentiellement illimité en coût borné et prévisible, exactement comme le ferait un budget de tokens sur une API commerciale. Fixer cette limite avant le premier essai, plutôt que la découvrir après coup, est la différence entre un test de cinq minutes et une carte graphique monopolisée toute une soirée pour une conversation qui n'aboutissait à rien depuis le dixième message. Sur une machine partagée avec d'autres usages — un poste de travail, pas un serveur dédié —, cette monopolisation a aussi un coût d'opportunité concret : impossible de lancer autre chose de gourmand en GPU pendant qu'une conversation multi-agents tourne sans limite en arrière-plan.

#FAQ