Architectures d'agents IA : vue d'ensemble

Pourquoi des architectures d'agents ?

Un agent LLM, c'est plus qu'un modèle doté d'outils : il lui faut une structure qui détermine quand il réfléchit, quand il appelle un outil, quand il établit un plan et quand il se corrige lui-même. C'est précisément cette structure que décrivent les architectures d'agents : des design patterns récurrents, devenus ces dernières années le vocabulaire commun du secteur.

Fait remarquable, leurs origines sont très rapprochées : les cinq patterns canoniques ReAct, Reflexion, Plan-and-Execute, ReWOO et Tree-of-Thoughts sont apparus dans une courte fenêtre entre octobre 2022 et mai 2023, principalement autour de Princeton, Google et Northeastern (Shunyu Yao est coauteur de trois des cinq articles). Depuis, le secteur a soit généralisé ces patterns en primitives de framework (par exemple create_agent de LangChain, auparavant create_react_agent de LangGraph, ou planning=True de CrewAI), soit les a hybridés en patterns successeurs (LATS, LLMCompiler, Plan-and-Act).

Pour les décideurs et les tech leads, la question clé est rarement « Quel pattern est le plus avancé ? », mais plutôt « Quel pattern résout cette tâche concrète avec un coût, une latence et une auditabilité acceptables ? ». Cet aperçu propose pour cela une cartographie indépendante des éditeurs.

ReAct : raisonnement et action imbriqués

ReAct (Yao et al., arXiv:2210.03629, octobre 2022, ICLR 2023) est le socle de presque tous les agents actuels qui utilisent des outils. Le principe : le LLM génère en alternance des tokens « Thought » (raisonnement) formulés librement et des tokens « Action » (appels d'outils), puis relit l'« Observation » (le résultat de l'outil). La boucle Thought → Action → Observation → Thought → … tourne jusqu'à ce que le modèle émette un Finish[answer] final.

Le problème résolu : le Chain-of-Thought (CoT) pur hallucine des faits, car il n'est pas ancré dans la réalité. À l'inverse, les agents purement « action-only » ne savent ni raisonner de manière abstraite sur des objectifs à long terme ni se remettre de leurs erreurs. ReAct réunit les deux : le raisonnement pilote l'usage des outils, et les observations des outils corrigent le raisonnement. Dans l'étude originale, cela a apporté +34 points de pourcentage sur ALFWorld (tâches ménagères textuelles) et +10 points de pourcentage sur WebShop (navigation e-commerce) par rapport aux baselines d'imitation/RL de l'époque, mais face à des modèles de la génération GPT-3/PaLM. Les chiffres absolus sont aujourd'hui dépassés et ne valent que comme effets relatifs.

Points forts : faible latence, faible complexité d'implémentation, forte interprétabilité grâce à une trace de raisonnement facile à suivre. Dans LangChain, ReAct tient en une ligne (create_agent, exécuté sur LangGraph). Son prédécesseur create_react_agent est déprécié depuis LangGraph v1. CrewAI utilise ReAct en interne dans chaque agent. n8n implémente la boucle dans le nœud natif AI Agent via le function calling. La vue d'exécution du nœud journalise chaque appel d'outil. Les équipes marketing sans développeurs internes disposent ainsi d'un log auditable. L'ancien type d'agent « ReAct Agent » a été déprécié par n8n avec la version 1.82.0 : les nouveaux nœuds AI Agent fonctionnent en « Tools Agent », et avec n8n 3.0, l'ancienne version du nœud proposant l'option ReAct disparaît complètement.

Points faibles : lorsque les descriptions d'outils sont ambiguës, le modèle hallucine les arguments des outils. Il existe un « reasoning drift » : une fois engagé sur une idée erronée, l'agent interprète les observations suivantes dans ce sens. Et le contexte gonfle, car chaque étape traîne à nouveau le prompt système et toute la trajectoire précédente (coût O(N·T)). En pratique, la limite se situe généralement entre 10 et 25 étapes, avant que la perte de contexte ou la dérive ne prennent le dessus.

Un enseignement pratique important : les modèles frontier modernes maîtrisent nativement la boucle raisonnement-action via le function calling. Selon le blog de n8n, le prompting ReAct explicite est devenu largement superflu. Ce qui compte aujourd'hui, ce sont la mémoire, les plafonds d'itérations et la traçabilité. L'erreur de production la plus fréquente avec des modèles plus faibles est un JSON mal formé dans les arguments des outils. Utilise donc la sortie structurée ou le mode function calling partout où le fournisseur le permet.

Reflexion : des agents qui s'autocritiquent

Reflexion (Shinn et al., arXiv:2303.11366, NeurIPS 2023) place une boucle d'autocorrection autour d'un agent existant. Trois composants s'articulent : un Actor (le plus souvent un agent ReAct ou CoT) produit une trajectoire ; un Evaluator l'évalue (de manière binaire, scalaire ou via une suite de tests externe) ; un modèle de Self-Reflection transforme l'évaluation et la trajectoire en feedback verbal : un paragraphe de critique en langage naturel, stocké dans une mémoire épisodique. Lors de la tentative suivante, cette réflexion est fournie à l'Actor en préambule. La « mise à jour de la politique » est purement linguistique ; aucun poids n'est modifié.

L'enseignement central de l'article : l'analyse d'erreurs qu'un LLM verbalise lui-même est un signal d'apprentissage plus fort qu'une simple récompense numérique, et ce entièrement in-context, sur plusieurs tentatives. Sur HumanEval (génération de code Python), Reflexion a atteint 91 % de pass@1 contre environ 80 % pour la baseline GPT-4 au moment de l'étude.

Attention toutefois : sur MBPP, Reflexion a fait moins bien que la baseline, car les tests unitaires qu'il générait lui-même présentaient un taux élevé de faux positifs et l'agent annonçait prématurément un « succès ». Reflexion n'améliore donc pas les résultats à tous les coups. Il lui faut un signal d'évaluation de haute qualité. Pour les tâches sans oracle clair (écriture créative, recherche ouverte), les réflexions dégénèrent en platitudes vagues, et les « réflexions confabulées » (c'est-à-dire des causes d'erreur mal diagnostiquées) transmettent la mauvaise correction à la tentative suivante.

Coûts : par tentative, environ 2 à 5 fois une exécution ReAct, multiplié par K tentatives, soit, avec la valeur typique K=3, 6 à 15 fois une exécution ReAct. Les tentatives sont obligatoirement séquentielles, ce qui exclut en général les cas d'usage en temps réel.

Trois règles pratiques : premièrement, plafonne toujours les itérations (max_reasoning_attempts dans CrewAI, revision_number ≤ N dans LangGraph). Deuxièmement, fournis si possible un signal de vérité terrain externe (tests unitaires, évaluateur RAG, correspondance regex), car l'autoévaluation seule n'est pas fiable. Troisièmement, mets les réflexions en cache : beaucoup d'équipes les persistent dans une base vectorielle par type de tâche et constituent ainsi une bibliothèque de compétences émergente. Une remarque sur la terminologie : dans certaines sources (blog LangChain), « Reflection » désigne toute boucle d'autocritique, tandis que « Reflexion » renvoie spécifiquement à l'article de Shinn et al. Il est donc utile de distinguer Reflexion (Shinn et al.) et le pattern Reflection au sens large.

Plan-and-Execute : d'abord le plan, ensuite l'exécution

Le pattern Plan-and-Execute découple la planification de l'exécution. Un Planner établit une seule fois un plan numéroté en plusieurs étapes, un Executor (souvent un sous-agent ReAct) le déroule étape par étape, et un Replanner décide après chaque exécution s'il faut s'arrêter ou produire un plan restant ajusté. Sur le plan conceptuel, il s'appuie sur le prompting « Plan-and-Solve » (Wang et al., arXiv:2305.04091, ACL 2023) et sur BabyAGI. Le pattern doit son nom et sa diffusion au portage réalisé par LangChain.

Le levier décisif : la planification est une tâche de raisonnement difficile (grand modèle), l'exécution consiste à utiliser des outils étape par étape (modèle plus petit et moins cher). Cet échelonnement des modèles peut réduire les coûts, car les nombreuses étapes d'exécution tournent sur un modèle plus petit. LangChain ne décrit cette économie que de manière qualitative, et l'article original de LangChain reconnaît que le pattern nécessite plus d'appels au modèle qu'un agent ReAct. En outre, les plans formulés explicitement sont auditables, un argument fort dans les contextes enterprise et de conformité.

Points faibles : la fragilité du plan. Si le plan initial est faux, l'Executor gaspille des appels sur des étapes vouées à l'échec jusqu'à ce que le Replanner s'en aperçoive. L'exécution reste séquentielle (pas de vrai parallélisme). Et chaque replanification rappelle le grand modèle ; dans des environnements très stochastiques, on replanifie presque à chaque étape, ce qui annule l'avantage de coût. Règle empirique : à utiliser lorsque les tâches se décomposent en plus de trois étapes indépendantes, qu'il existe un oracle clair pour valider le plan et que la latence n'est pas directement perceptible par l'utilisateur. À éviter lorsque l'environnement est fortement stochastique. Dans ce cas, la boucle réactive de ReAct est strictement meilleure. Le pattern « Orchestrator-Workers » d'Anthropic est au fond la même chose, présentée sous un nouvel angle.

ReWOO : raisonner sans observation permanente

ReWOO (Xu et al., arXiv:2305.18323, mai 2023) est la réponse optimisée en coûts à l'appétit de ReAct pour les tokens. Trois modules : un Planner génère en un seul appel au LLM toute la chaîne d'étapes du plan et d'appels d'outils, une syntaxe de variables (#E1, #E2, …) permettant de faire référence à des résultats pas encore disponibles. Un Worker exécute les outils dans l'ordre prévu et remplace les espaces réservés par les vrais résultats. Enfin, un Solver lit, dans un dernier appel au LLM, la tâche et l'ensemble des éléments de preuve, puis formule la réponse.

L'effet : N appels au LLM sont remplacés par exactement deux (Planner + Solver), quel que soit le nombre d'étapes d'outils. Sur HotpotQA, l'article rapporte une efficacité en tokens multipliée par 5 avec +4 % de précision par rapport à ReAct, et une réduction de tokens constante sur six benchmarks de NLP. ReWOO est en outre robuste aux pannes d'outils : le plan est déjà fixé, et le Solver détecte proprement les éléments de preuve manquants.

Limites : aucune adaptation en cours d'exécution. Si l'élément de preuve 3 contredit le plan, ReWOO ne peut pas replanifier dans la même passe. Sans contexte d'environnement, le Planner a du mal avec des écosystèmes d'outils inconnus (few-shot prompting ou fine-tuning nécessaire). Et les outils s'exécutent de manière séquentielle. Le vrai parallélisme n'arrive qu'avec son successeur LLMCompiler (Kim et al., arXiv:2312.04511), via un DAG.

Pour les agences marketing, ReWOO est souvent le meilleur pattern dans n8n : la force de n8n, ce sont les workflows déterministes et déclaratifs, la substitution de variables est native, et des tâches comme « rechercher X → enrichir → formater → envoyer » deviennent ainsi faciles à déboguer, peu coûteuses et tolérantes aux pannes. Les retours de terrain font état d'environ 65 % de réduction des coûts en tokens pour un gain de précision de 4–5 %. Anti-pattern : n'utilise pas ReWOO pour des tâches où les résultats des outils invalident souvent le plan (p. ex. la navigation web interactive) ; Plan-and-Execute ou ReAct y sont meilleurs.

Tree-of-Thoughts : la recherche plutôt que la ligne droite

Tree-of-Thoughts (Yao et al., arXiv:2305.10601, NeurIPS 2023) rompt avec la logique strictement linéaire, de gauche à droite, du CoT. Au lieu d'une seule chaîne de pensée, on déploie un arbre : chaque nœud est un « Thought » (une solution partielle), à chaque point le modèle génère k candidats, un State-Evaluator les évalue (par exemple par un vote sûr/peut-être/impossible), et un algorithme de recherche (BFS ou DFS avec backtracking) parcourt l'arbre. L'article présente explicitement cela comme une recherche de type « Système 2 », en référence aux formalismes de résolution de problèmes de Newell & Simon.

Les résultats sur les tâches fortement axées sur la recherche sont spectaculaires : Game of 24 résolu à 74 % (contre 4 % avec CoT et 7,3 % avec IO), Mini-Crosswords au niveau des mots à 60 % (contre 16 % avec CoT), écriture créative plus cohérente. Le prix est toutefois énorme : environ 10 à 100 fois plus de tokens qu'un appel CoT unique, voire davantage avec des arbres de recherche larges et profonds. Le tableau des ordres de grandeur ci-dessous calcule avec une largeur b=5 et une profondeur d=3, et arrive ainsi à 50–150×. En outre, l'efficacité dépend fortement de la qualité du générateur (GPT-3.5+ToT n'a atteint que 19 % au lieu de 74 % sur Game of 24).

L'enseignement de terrain le plus important sur ToT : pour le raisonnement général, il est largement obsolète en 2026, car les modèles de raisonnement modernes (par exemple GPT-5 avec raisonnement, Claude avec Extended Thinking, Gemini 3 avec Thinking) effectuent la recherche en interne. ToT reste pertinent comme fondement conceptuel de la recherche arborescente des agents (c'est la base de LATS) ainsi que pour trois niches : les secteurs réglementés soumis à audit, les puzzles et l'optimisation avec récompenses vérifiables, et les déploiements de petits modèles avec des proposers peu coûteux. Dans des outils comme n8n, ToT ne passe pratiquement pas à l'échelle en raison de l'explosion combinatoire. L'approximation propre est le « Best-of-N sampling » : plusieurs exécutions en parallèle parmi lesquelles un critique choisit la meilleure (ToT de profondeur 1).

Routing et patterns hiérarchiques

Au-delà des cinq patterns de raisonnement, Anthropic cite dans « Building Effective Agents » (décembre 2024) deux autres patterns structurants qui, en pratique, forment souvent le cadre. Le routing classe une entrée et l'oriente vers un chemin spécialisé, par exemple une étape de classification qui répartit les demandes de support par type entre différents prompts ou modèles. Les architectures hiérarchiques imbriquent un orchestrateur et des sous-agents : un LLM coordinateur décompose dynamiquement la tâche et délègue à des agents subordonnés. Plan-and-Execute avec des sous-agents ReAct correspond exactement à cette variante (l'Orchestrator-Workers d'Anthropic).

Sur la prudence vis-à-vis de la hiérarchie, c'est Cognition (Devin) qui fournit l'enseignement le plus cité : « Don't Build Multi-Agents » (juin 2025) avertissait que des agents parallèles prennent implicitement des décisions contradictoires et livrent des résultats fragiles. La position actualisée « Multi-Agents: What's Actually Working » (avril 2026) juge le multi-agent viable pour des setups parallèles en lecture, monothread en écriture. Traduit pour les clients d'agence : mise sur un agent solide doté d'outils. Les sous-agents parallèles, utilise-les uniquement pour collecter des informations, jamais pour des écritures ou des changements d'état.

Comparaison : quel pattern pour quel usage

Le tableau des ordres de grandeur ci-dessous est à lire comme une valeur indicative approximative (estimations synthétisées à partir des données des articles et de retours de terrain, pas de mesures directes). Mesure-le toi-même sur ta propre charge :

Le fil conducteur pour la pratique

Tous patterns confondus, l'enseignement de terrain le plus important des articles de blog sur les agents en production publiés en 2024–2026 (Anthropic, Cognition, LangChain) est étonnamment sobre : commence par le pattern le plus simple qui fonctionne (le plus souvent ReAct), et ne passe à la planification, à Reflexion ou à la recherche que si des modes de défaillance mesurés l'exigent. Anthropic le formule ainsi : « Les implémentations les plus réussies utilisaient des patterns simples et composables plutôt que des frameworks complexes. »

Les patterns successeurs apparus depuis l'automne 2023 sont au fond des recombinaisons des cinq patterns d'origine : LATS (Zhou et al., octobre 2023) = ToT + Reflexion + MCTS, disponible dans LangGraph comme implémentation de référence ; LLMCompiler (Kim et al., décembre 2023) = ReWOO + DAG parallèle, jusqu'à 3,7× plus rapide que ReAct selon l'article ; Plan-and-Act (Erdogan et al., mars 2025) = Plan-and-Execute pour les horizons longs. Les frameworks convergent eux aussi vers une primitive commune associant state graph et tool calling : Microsoft a consolidé AutoGen et Semantic Kernel dans le Microsoft Agent Framework (AutoGen est officiellement en mode maintenance), et LangChain a remplacé create_react_agent par langchain.agents.create_agent avec middleware. Pour les décideurs qui évaluent la stack Microsoft, c'est l'aiguillage déterminant.

Pour finir, trois règles pratiques non négociables : premièrement, chaque agent a besoin de plafonds stricts (recursion_limit, max_iterations), sans quoi les boucles font exploser les coûts. Deuxièmement, les outils d'observabilité (LangSmith, Langfuse, Arize Phoenix) sont de facto obligatoires. Troisièmement, la conformité impose de persister des traces Thought/Action/Observation complètes avec masquage des PII. C'est essentiel, en particulier pour les systèmes concernés par le RGPD et le règlement européen sur l'IA.

Remarque : les affirmations relatives à la conformité dans ce texte sont fournies à titre informatif et ne constituent pas un conseil juridique. Les chiffres de benchmark cités proviennent pour la plupart des articles originaux des années 2022–2023 (ère GPT-3.5/GPT-4) et doivent être compris comme des tailles d'effet relatives, et non comme des valeurs absolues pour les modèles frontier actuels.