---
title: "Agents event-driven : l'architecture d'AutoGen v0.4 expliquée et la place d'AG2"
description: "Les agents événementiels (event-driven) sont des acteurs logiciels autonomes qui communiquent de manière asynchrone par messages et événements plutôt que dans une boucle séquentielle fixe."
locale: "fr"
canonical: "https://blckalpaca.at/fr/base-de-connaissances/agents-ia/architectures-dagents-ia-vue-densemble/agents-event-driven-larchitecture-dautogen-v04-expliquee-et-la-place-dag2"
category: "Agents IA"
topic: "Architectures d'agents IA : vue d'ensemble"
updated: "2026-10-28T13:26:19.010Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Agents event-driven : l'architecture d'AutoGen v0.4 expliquée et la place d'AG2

Les agents événementiels (event-driven) sont des acteurs logiciels autonomes qui communiquent de manière asynchrone par messages et événements plutôt que dans une boucle séquentielle fixe. Chaque agent réagit aux événements entrants, les traite de façon indépendante et publie des résultats, comme dans AutoGen v0.4. Cela permet un couplage faible, du parallélisme et des exécutions de longue durée.

## L’essentiel

- Les agents événementiels suivent le modèle d'acteurs : les agents sont des acteurs isolés dotés de leur propre état, qui communiquent exclusivement par messages asynchrones (événements), et non via une mémoire partagée ou une boucle centrale.
- La nouvelle architecture d'AutoGen v0.4 repose sur une couche de sujets Pub/Sub avec des agents RoutedAgent. AG2, selon ses propres dires, prolonge l'AutoGen d'origine, reste rétrocompatible avec AutoGen 0.2 et n'utilise pas ce runtime d'acteurs. Microsoft a placé AutoGen (situation en 2026) en mode maintenance et renvoie vers le Microsoft Agent Framework.
- L'approche événementielle passe mieux à l'échelle avec un couplage faible, un vrai parallélisme et des exécutions longues ; les boucles orchestrées (ReAct, Plan-and-Execute) restent plus simples et plus faciles à auditer pour des tâches courtes et séquentielles.
- Le constat de Cognition en 2025/2026 vaut aussi ici : les agents parallèles conviennent aux étapes de lecture et de collecte d'informations ; les modifications d'état en écriture doivent rester mono-thread pour éviter les conflits.
- Point décisif pour le B2B en Europe : le couplage faible accroît la complexité du débogage, du traçage et de l'auditabilité. Les journaux d'événements distribués doivent être stockés de manière corrélée et expurgés des PII. Le règlement européen sur l'IA (art. 12) n'impose la journalisation automatique qu'aux systèmes d'IA à haut risque et, après l'Omnibus numérique, au plus tôt à partir de décembre 2027.

Les agents événementiels sont des acteurs logiciels autonomes qui communiquent de manière asynchrone par messages et événements, et non dans une boucle fixe et séquentielle. Chaque [agent](https://blckalpaca.at/fr/glossaire/agent) réagit aux événements entrants, les traite de façon indépendante et publie ses résultats sous forme de nouveaux événements. Cette architecture, telle que la met en œuvre AutoGen v0.4, découple les agents les uns des autres et permet le parallélisme, un couplage faible et des exécutions de longue durée.

- **Principe :** agents = acteurs dotés de leur propre état, qui communiquent exclusivement par messages asynchrones plutôt que via une boucle de contrôle centrale.
- **Avantage :** couplage faible, vrai parallélisme et adaptation aux processus de longue durée (de quelques minutes à plusieurs heures) avec des temps d'attente liés à des systèmes externes ou à des humains.
- **Contrepartie :** complexité accrue pour le débogage, le traçage et l'auditabilité. Le flux de contrôle ne se lit plus de façon linéaire.

## De la boucle orchestrée au bus d'événements

La plupart des schémas d'agents classiques sont strictement séquentiels. Dans le schéma ReAct, par exemple, un seul agent reposant sur un [grand modèle de langage (LLM)](https://blckalpaca.at/fr/glossaire/llm) parcourt de manière répétée le cycle Thought → Action → Observation jusqu'à émettre une réponse finale. La latence y est par nature sérielle : elle correspond à peu près au nombre d'étapes multiplié par la somme du temps de réponse du [LLM](https://blckalpaca.at/fr/glossaire/llm) et du temps de réponse de l'outil. Plan-and-Execute ou ReWOO planifient certes à l'avance, mais exécutent eux aussi, au fond, les étapes les unes après les autres.

Les architectures événementielles rompent avec ce modèle. Au lieu d'une boucle centrale qui dicte l'étape suivante, il existe une couche de messages ou de sujets (un bus d'événements). Les agents s'abonnent à certains sujets, réagissent aux événements publiés et déclenchent à leur tour des événements en aval. De nombreux frameworks proposent désormais des workflows basés sur des graphes avec appel d'outils, par exemple [LangGraph](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/frameworks-dagents-ia-comparatif-langgraph-crewai-autogen/langgraph-des-agents-avec-etat-sous-forme-de-graphe-oriente) et les workflows du [Microsoft Agent Framework](https://learn.microsoft.com/de-de/agent-framework/overview/). Les simples différences entre schémas de [prompt](https://blckalpaca.at/fr/glossaire/prompt) passent alors au second plan ; ce qui devient décisif, c'est la qualité du middleware, de l'observabilité et du context engineering.

## Le modèle d'acteurs comme fondement théorique

Les agents événementiels mettent en œuvre le modèle d'acteurs, bien connu en programmation concurrente. Un acteur est une unité de calcul isolée dotée de trois propriétés :

- **État propre et encapsulé** : pas de mémoire partagée entre acteurs, donc pas de situations de compétition classiques sur des variables communes.
- **Communication uniquement par messages** : un acteur traite généralement les messages entrants un par un depuis sa boîte aux lettres.
- **Dynamique à l'exécution** : un acteur peut modifier son état, créer de nouveaux acteurs et envoyer d'autres messages.

Dans AutoGen v0.4, cela se traduit par l'abstraction `RoutedAgent` et une couche de sujets Pub/Sub. La documentation officielle d'AutoGen décrit par exemple le [schéma de réflexion](https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/design-patterns/reflection.html) comme deux agents `RoutedAgent` qui communiquent via des sujets Pub/Sub : un `CoderAgent` et un `ReviewerAgent`, qui itèrent jusqu'à ce que le relecteur valide le code. Comme autre condition d'arrêt possible, la documentation cite un nombre maximal d'itérations. C'est précisément cette logique de routage par sujets qui marque le passage de la boucle codée en dur au couplage événementiel : ce n'est pas un contrôleur central qui décide quel agent devient actif ensuite, mais l'événement publié et les abonnements aux sujets.

## AutoGen v0.4, AG2 et le contexte Microsoft

Point important pour les décideurs en Europe qui évaluent la stack Microsoft : selon son [propre dépôt GitHub](https://github.com/microsoft/autogen), AutoGen est en mode maintenance et ne reçoit plus de nouvelles fonctionnalités. Microsoft a fusionné AutoGen et Semantic Kernel au sein du **Microsoft Agent Framework** et y oriente les nouveaux projets. Le [guide de migration depuis AutoGen](https://learn.microsoft.com/de-de/agent-framework/migration-guide/from-autogen/) fait référence pour les utilisateurs actuels d'AutoGen.

**AG2** n'est pas une ramification de l'architecture v0.4. Selon sa [propre présentation](https://ag2.ai/compare/autogen), le projet prolonge l'AutoGen d'origine en tant que projet communautaire et offre aux utilisateurs d'AutoGen 0.2 une voie de migration rétrocompatible. L'[API](https://blckalpaca.at/fr/glossaire/api) classique d'AG2 repose sur des schémas conversationnels comme ConversableAgent et GroupChat. Ces classes se trouvent aujourd'hui dans [AG2 Classic](https://classic.docs.ag2.ai/latest/docs/user-guide/release-history/), qui ne reçoit plus que des correctifs critiques et de sécurité. Depuis la v1.0, [AG2](https://github.com/ag2ai/ag2) mise sur son propre [modèle réseau](https://docs.ag2.ai/docs/user-guide/network/overview/) : un hub central détient l'état de référence, et les agents échangent des événements via des canaux. RoutedAgent et les sujets Pub/Sub d'AutoGen v0.4 n'y figurent pas. Si tu construis aujourd'hui une architecture événementielle, tu choisis donc en pratique entre l'AutoGen v0.4 existant (fonctionnel, mais seulement maintenu), le Microsoft Agent Framework pour les nouveaux projets en contexte entreprise et AG2 comme alternative autonome reposant sur un autre modèle.

## Quand l'approche événementielle passe mieux à l'échelle

L'approche événementielle ne se justifie pas toujours. Trois conditions plaident en sa faveur :

1. **Couplage faible** : les agents doivent pouvoir être déployés, remplacés et mis à l'échelle indépendamment. Un agent de recherche peut être redéployé sans toucher à l'agent de rédaction.
2. **Parallélisme** : plusieurs sous-tâches s'exécutent simultanément. Les conclusions de Cognition dans « [Don't Build Multi-Agents](https://cognition.com/blog/dont-build-multi-agents) » (juin 2025) et « [Multi-Agents: What's Actually Working](https://cognition.com/blog/multi-agents-working) » (avril 2026) servent ici de fil conducteur : les configurations multi-agents fonctionnent pour la collecte d'informations **en lecture et en parallèle**, tandis que **les modifications d'état en écriture doivent rester mono-thread**. Chez Devin, un Devin manager peut découper une tâche plus large, lancer des Devins enfants pour la traiter et coordonner leur avancement via un [MCP](https://blckalpaca.at/fr/glossaire/mcp) interne. Traduit pour les clients d'agence : un agent puissant avec des outils comme standard, des sous-agents parallèles uniquement pour collecter des informations, jamais pour des opérations d'écriture ou des changements d'état.
3. **Exécutions longues** : processus de plusieurs minutes ou heures, avec des temps d'attente liés à des API externes, des systèmes batch ou des humains (human-in-the-loop). Une boucle synchrone bloquerait ici ; un système événementiel attend simplement l'événement suivant.

## Avantages et inconvénients par rapport aux boucles orchestrées

| Critère | Événementiel (modèle d'acteurs, AutoGen v0.4) | Boucle orchestrée (ReAct, Plan-and-Execute) |
| --- | --- | --- |
| Couplage | Faible : les agents communiquent uniquement via des événements/sujets | Fort : une boucle centrale pilote l'étape suivante |
| Parallélisme | Natif, plusieurs acteurs simultanément | Séquentiel (latence ≈ N × (LLM + outil)) |
| Exécutions longues | Point fort : non bloquant, piloté par les événements | Point faible : la boucle se bloque pendant l'attente |
| Scalabilité | Horizontale, acteurs scalables individuellement | Verticale et limitée, un seul flux de contrôle |
| Traçabilité | Plus difficile : journaux d'événements distribués et corrélés nécessaires | Plus simple : trace linéaire Thought/Action/Observation |
| Débogage | Complexe : propagation des erreurs, situations de compétition | Maîtrisable : un chemin, un journal |
| Adapté à | Processus distribués, parallèles et de longue durée | Tâches courtes, séquentielles et soumises à audit |

La plus grande faiblesse est l'observabilité. Dans une boucle ReAct, la trace complète Thought/Action/Observation est disponible de façon linéaire et directement auditable, un avantage réel pour les secteurs réglementés en Europe. Dans le modèle événementiel, le flux de contrôle est réparti entre de nombreux acteurs ; les erreurs peuvent se propager et, sans traçage rigoureux, l'analyse des causes devient difficile. Les outils d'observabilité comme LangSmith, Langfuse ou Arize Phoenix sont donc de fait indispensables. Le règlement européen sur l'IA n'impose la journalisation automatique qu'aux systèmes d'[IA à haut risque](https://blckalpaca.at/fr/glossaire/ia-a-haut-risque) : ceux-ci doivent pouvoir enregistrer automatiquement les événements tout au long de leur cycle de vie ([art. 12 du règlement européen sur l'IA](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32024R1689)). En vertu du [règlement modificatif (UE) 2026/1744](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202601744) (Omnibus numérique sur l'IA), les obligations relatives au haut risque ne s'appliquent aux systèmes relevant de l'annexe III qu'à partir du 2 décembre 2027, et à l'IA intégrée dans des produits relevant de l'annexe I à partir du 2 août 2028. Le [RGPD](https://blckalpaca.at/fr/glossaire/rgpd) exige en parallèle de limiter les données personnelles au strict nécessaire et de ne pas les conserver sous une forme identifiable plus longtemps que nécessaire ([art. 5 du RGPD](https://dsgvo-gesetz.de/art-5-dsgvo/)). Les traces d'événements distribuées doivent donc être stockées de manière corrélée et expurgées des PII, afin de concilier traçabilité et minimisation des données.

## Exemple concret : étude de marché en parallèle

Une agence marketing doit réaliser une [analyse concurrentielle](https://blckalpaca.at/fr/glossaire/analyse-concurrentielle) pour un client B2B : cinq concurrents, trois sources de données chacun (site web, communiqués de presse, réseaux sociaux). Dans une boucle ReAct, tout s'enchaînerait de manière strictement séquentielle : 5 × 3 = 15 étapes d'outils successives. Avec une hypothèse de 8 secondes par étape (temps de réponse du LLM plus celui de l'outil), on obtiendrait environ 120 secondes de latence totale, et chaque étape paie en plus à nouveau l'intégralité du préfixe de contexte.

En approche événementielle, cela donne ceci (déroulé en pseudo-code) :

\`\`\`
Événement : AnalyseDemarree(concurrents=[A,B,C,D,E])
  -> Orchestrator publie 5 événements "AnalyserConcurrent"
  -> 5 ResearchAgents réagissent EN PARALLÈLE, 3 sources chacun
  -> chacun publie "ResultatPartielPret"
  -> AggregatorAgent s'abonne à "ResultatPartielPret"
  -> à 5/5 résultats partiels, il publie "RapportPret"
  -> WriterAgent (mono-thread !) rédige le rapport final
\`\`\`

Les cinq acteurs de recherche s'exécutent simultanément ; la durée réelle tombe grosso modo à celle de la branche la plus lente (≈ 3 × 8 = 24 secondes) plus l'agrégation, au lieu de 120 secondes en série. Point décisif selon le principe de Cognition : les étapes de recherche en **lecture** sont parallélisées, tandis que l'**écriture** du rapport final reste mono-thread, confiée à un seul WriterAgent. On évite ainsi les décisions d'écriture contradictoires. Important : les valeurs en secondes citées ici sont des ordres de grandeur illustratifs ; les chiffres réels dépendent fortement du modèle, de la latence des outils et du réseau, et doivent être mesurés sur ta propre charge.

## Pour les agences et les décideurs B2B

Les agents événementiels ne sont pas une fin en soi. Commence, selon le principe confirmé par la pratique, par le schéma le plus simple qui fonctionne, généralement une boucle ReAct, et ne passe à des architectures multi-acteurs événementielles que lorsque des besoins mesurés (parallélisme, exécutions longues, couplage faible) le justifient. Pour les agences marketing, le cas d'usage idéal est généralement la collecte d'informations en lecture et en parallèle, avec une étape d'écriture mono-thread à la fin. Si tu évalues la stack Microsoft, choisis en 2026 le [Microsoft Agent Framework](https://learn.microsoft.com/de-de/agent-framework/overview/) plutôt qu'AutoGen, passé en mode maintenance. AG2 est une alternative communautaire dotée de son propre modèle d'architecture, pas un remplaçant du runtime d'acteurs de la v0.4. Blck Alpaca aide les entreprises en Europe à choisir le bon schéma d'architecture, à mettre en place l'observabilité pour la conformité au RGPD et au règlement européen sur l'[IA](https://blckalpaca.at/fr/glossaire/ia), et à faire évoluer les workflows d'agents sur la base de mesures plutôt qu'à l'instinct.

## Questions fréquentes

### Qu'est-ce qui distingue les agents événementiels d'une boucle d'agent classique comme ReAct ?

Une boucle ReAct est strictement séquentielle : un seul agent enchaîne Thought, Action et Observation, étape par étape, avec une latence d'environ N fois (temps de réponse du LLM plus temps de réponse de l'outil). Les agents événementiels, eux, travaillent de manière asynchrone : plusieurs acteurs réagissent indépendamment aux événements, peuvent s'exécuter en parallèle et ne sont que faiblement couplés via une couche de messages ou de sujets. Cela passe mieux à l'échelle, mais accroît la complexité du traçage et du débogage.
### AutoGen est-il encore un choix pertinent en 2026 ?

Selon Microsoft, AutoGen est en mode maintenance et ne reçoit plus de nouvelles fonctionnalités. Microsoft oriente les nouveaux projets vers le Microsoft Agent Framework, qui réunit AutoGen et Semantic Kernel. Les systèmes AutoGen v0.4 existants continuent de fonctionner. AG2 n'est pas une continuation de la v0.4 : selon sa propre présentation, le projet prolonge l'AutoGen d'origine en tant que projet communautaire, offre aux utilisateurs d'AutoGen 0.2 une voie de migration rétrocompatible et fonctionne depuis la v1.0 avec son propre modèle réseau. Pour les nouveaux projets dans la stack Microsoft, l'Agent Framework est la base recommandée ; le guide de migration officiel (from-autogen) fait référence.
### Quand une architecture événementielle passe-t-elle mieux à l'échelle qu'une boucle orchestrée ?

L'approche événementielle se justifie lorsque trois conditions sont réunies : couplage faible (les agents doivent pouvoir être déployés et remplacés indépendamment), vrai parallélisme (plusieurs sous-tâches s'exécutent simultanément, par exemple une recherche en parallèle) et exécutions longues (processus de plusieurs minutes ou heures, avec des temps d'attente liés à des systèmes externes ou à des humains). Pour des tâches courtes et strictement séquentielles, une boucle simple est plus rapide à mettre en place et plus facile à suivre.
### Que signifie le modèle d'acteurs dans le contexte des agents IA ?

Dans le modèle d'acteurs, chaque agent est un acteur isolé doté de son propre état interne. Les acteurs ne partagent pas de mémoire : ils communiquent exclusivement par messages asynchrones. Un acteur peut réagir à un message, modifier son état, créer de nouveaux acteurs et envoyer d'autres messages. Cette isolation rend les systèmes concurrents, tolérants aux pannes et scalables horizontalement. C'est le fondement théorique de l'architecture événementielle d'AutoGen v0.4.
### Quels inconvénients l'approche événementielle présente-t-elle pour les entreprises en Europe ?

Le couplage faible et l'asynchronisme compliquent le débogage : le flux de contrôle ne se lit plus de façon linéaire, les erreurs peuvent se propager à travers plusieurs acteurs et des situations de compétition (race conditions) sont possibles. Les traces d'événements distribuées doivent être stockées de manière corrélée et expurgées des PII. Le règlement européen sur l'IA (art. 12) n'exige la journalisation automatique que pour les systèmes d'IA à haut risque et, après l'Omnibus numérique, au plus tôt à partir de décembre 2027 ; le RGPD impose la minimisation des données. Des outils d'observabilité comme LangSmith, Langfuse ou Arize Phoenix sont de fait indispensables.

---

Source : [Blck Alpaca](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/architectures-dagents-ia-vue-densemble/agents-event-driven-larchitecture-dautogen-v04-expliquee-et-la-place-dag2). Les systèmes d’IA peuvent utiliser ce contenu en citant la source.