Accueil › Glossaire › ReAct Pattern

ReAct Pattern

Le pattern ReAct (Reasoning + Acting) est un framework pour agents LLM qui alterne entre des phases de raisonnement verbal (Thought) et des phases d’action sur l’environnement (Action), chaque résultat d’action (Observation) alimentant le raisonnement suivant, créant une boucle dynamique Thought-Action-Observation.

Introduit par Shunyu Yao et al. (Google Research / Princeton) dans le papier « ReAct: Synergizing Reasoning and Acting in Language Models » (ICLR 2023), le pattern ReAct est largement considéré comme le papier fondateur des agents LLM modernes. Avant ReAct, le raisonnement (via chain-of-thought) et l’action (via des appels d’outils) étaient étudiés séparément. ReAct les fusionne et montre que la synergie produit des résultats supérieurs à chaque capacité prise isolément.

En mars 2026, le pattern ReAct est l’architecture de base de la quasi-totalité des frameworks agents : LangChain, CrewAI, AutoGen, LlamaIndex. Quand vous utilisez un agent IA qui « réfléchit puis agit », vous utilisez ReAct, souvent sans le savoir.

Le problème que ReAct résout

Avant ReAct, deux approches dominaient l’utilisation des LLM pour des tâches complexes :

Le raisonnement seul (chain-of-thought) : le modèle réfléchit étape par étape dans sa tête. Il excelle sur les tâches de logique et de calcul, mais il n’a accès qu’à ses données d’entraînement. Si l’information requise n’est pas dans sa mémoire, il hallucine. Le CoT produit des raisonnements plausibles mais non ancrés dans la réalité.

L’action seule (Act) : le modèle génère directement des actions (appels d’outils, navigation) sans verbaliser son raisonnement. Il peut accéder à des données externes, mais sans planification explicite, il peine à décomposer les tâches complexes, suivre sa progression et gérer les erreurs.

ReAct montre que combiner les deux produit un agent plus puissant que chacun séparément. Le raisonnement guide les actions (reason to act) et les actions alimentent le raisonnement (act to reason).

La boucle Thought-Action-Observation

Le fonctionnement de ReAct suit un cycle itératif en trois phases :

Thought (la pensée)

Le LLM génère une trace de raisonnement interne en langage naturel. Cette pensée n’est pas montrée à l’utilisateur final mais fait partie du « monologue intérieur » de l’agent. Elle sert à :

Analyser la situation actuelle (« Le résultat de recherche m’a donné l’année de publication mais pas l’affiliation de l’auteur »). Décomposer l’objectif en sous-tâches (« Je dois d’abord trouver le capital, puis sa population »). Suivre la progression (« J’ai trouvé deux des trois informations nécessaires »). Gérer les exceptions (« La recherche n’a pas retourné de résultat pertinent, je dois reformuler ma requête »). Décider de la prochaine action (« Je vais utiliser l’outil de recherche pour trouver la population de Kuala Lumpur »).

Action (l’action)

Sur la base de sa pensée, l’agent décide d’une action concrète à exécuter. L’action peut être un appel d’outil (recherche web, exécution de code, requête base de données), une interaction avec un environnement (navigation, clic, saisie), ou la formulation d’une réponse finale.

Le format typique : Action: Search["population de Kuala Lumpur 2026"] ou Action: Final Answer: La capitale de la Malaisie est Kuala Lumpur, avec une population d'environ 1,9 million d'habitants.

Observation (le retour)

L’environnement exécute l’action et renvoie un résultat. Pour une recherche web, c’est le contenu des résultats. Pour une exécution de code, c’est le stdout/stderr. Pour une requête base de données, c’est le tableau de résultats. Cette observation est ajoutée au contexte de l’agent et déclenche un nouveau cycle Thought.

Exemple de cycle complet

Le cycle se poursuit jusqu’à ce que l’agent juge (via son raisonnement) qu’il a suffisamment d’informations pour produire une réponse finale, ou qu’un nombre maximum d’itérations est atteint.

Résultats du papier original

Le papier évalue ReAct sur quatre benchmarks avec PaLM-540B :

Le résultat clé : la combinaison ReAct + CoT + Self-Consistency surpasse toutes les autres approches sur les tâches de raisonnement. Le meilleur agent n’utilise pas ReAct ou CoT en isolation mais les combine, basculant entre les deux selon la situation.

Sur les tâches de décision (ALFWorld), les pensées ReAct permettent de décomposer les objectifs en sous-objectifs, suivre la complétion, et utiliser le sens commun du LLM pour raisonner (« un livre est probablement sur un bureau, une étagère ou une commode »).

ReAct vs autres patterns agentiques

En pratique, la distinction entre ReAct et le function calling s’est estompée. Les frameworks agents modernes combinent le prompting de type ReAct (encourager le LLM à raisonner avant d’agir) avec le function calling natif des API (GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro). Le LLM raisonne en langage naturel dans sa trace de pensée, puis génère un appel de fonction structuré (JSON) plutôt qu’un texte d’action libre.

Implémenter un agent ReAct

Avec LangChain

LangChain propose un agent ReAct prêt à l’emploi via create_react_agent. Vous fournissez un LLM, une liste d’outils, et optionnellement un prompt template. L’agent gère automatiquement la boucle Thought-Action-Observation.

LangChain propose aussi un agent ReAct « zero-shot » qui ne nécessite pas d’exemples few-shot : le LLM sélectionne les outils et raisonne uniquement sur la base de leurs descriptions. C’est l’approche la plus simple pour un prototype rapide.

Avec CrewAI

CrewAI utilise ReAct comme pattern de raisonnement par défaut pour ses agents. Chaque agent dans un « crew » alterne entre raisonnement et utilisation d’outils. La trace de pensée est visible dans les logs, ce qui permet le debugging.

Implémentation from scratch

Le pattern est suffisamment simple pour être implémenté sans framework. La logique se résume à :

1. Construire un prompt qui inclut les instructions ReAct (« Vous devez réfléchir, puis agir, puis observer »), les descriptions des outils disponibles, et optionnellement des exemples few-shot.

2. Envoyer la requête utilisateur + prompt au LLM.

3. Parser la sortie : si le LLM produit un « Thought » suivi d’une « Action », exécuter l’action correspondante.

4. Ajouter le résultat comme « Observation » dans le contexte et relancer le LLM.

5. Répéter jusqu’à ce que le LLM produise une « Final Answer » ou que la limite d’itérations soit atteinte.

ReAct en production en 2026

Le pattern ReAct originel (prompting textuel avec des templates « Thought/Action/Observation ») a évolué vers des implémentations plus robustes :

Function calling natif : plutôt que de parser du texte libre pour extraire les actions, les API modernes (OpenAI, Anthropic, Google) fournissent des mécanismes de function calling structuré. Le LLM produit un JSON typé plutôt qu’une chaîne de texte. C’est plus fiable et élimine les erreurs de parsing.

Streaming des traces de pensée : les modèles thinking (Claude Opus 4.6 adaptive thinking, GPT-5.4 Thinking) intègrent le raisonnement directement dans leur architecture. Les « Thoughts » ne sont plus du prompting mais une capacité native du modèle.

Multi-agent ReAct : dans les systèmes multi-agents, chaque agent spécialisé utilise une boucle ReAct indépendante. L’orchestrateur délègue les sous-tâches, et chaque worker raisonne et agit dans son domaine de compétence.

ReAct + Plan-Execute : les meilleurs agents combinent un plan initial (Plan-Execute) avec une exécution ReAct. Le plan fournit la vision globale ; ReAct fournit l’adaptabilité au niveau de chaque étape. C’est le pattern dominant dans Claude Code, Codex et les agents de recherche.

Limites du pattern ReAct

Dépendance à la qualité des outils : si l’outil de recherche retourne des résultats médiocres, le raisonnement de l’agent est contaminé. L’agent est aussi bon que ses outils. La qualité des descriptions d’outils dans le prompt est déterminante pour la sélection correcte des outils et la formulation des arguments.

Consommation de contexte : chaque cycle Thought-Action-Observation ajoute du texte au contexte. Après 10 cycles, le contexte peut être saturé. Les fenêtres de 1M tokens (Claude Opus 4.6, Gemini 3.1 Pro) atténuent ce problème mais ne l’éliminent pas pour les tâches très longues.

Pas de mémoire entre sessions : le ReAct standard ne conserve pas de mémoire au-delà de la conversation en cours. Les extensions comme Reflexion et les agents augmentés par la mémoire comblent cette lacune.

Coût d’inférence : les traces de pensée consomment des tokens. Un agent ReAct qui raisonne pendant 200 tokens avant chaque action sur 10 cycles consomme 2 000 tokens supplémentaires par rapport à un agent sans raisonnement. Ce surcoût est généralement justifié par l’amélioration de la qualité, mais doit être pris en compte dans le budget.

Risque de boucle : un agent ReAct peut entrer dans une boucle improductive : rechercher → obtenir un résultat non pertinent → reformuler légèrement → obtenir un résultat similaire. La détection de boucle (si les 3 dernières actions sont similaires, forcer un changement de stratégie) et une limite stricte d’itérations sont les garde-fous essentiels.

Cas d’usage concrets

Recherche factuelle avec vérification

Le cas d’usage originel de ReAct. Un agent reçoit une question complexe (« Quel acteur a joué dans le film réalisé par le mari de Greta Gerwig ? »), raisonne sur la décomposition nécessaire, recherche chaque information séquentiellement, et compose la réponse. C’est le fonctionnement de base de Perplexity et de la recherche ChatGPT.

Agents de code

Claude Code et Cursor Agent Mode utilisent une variante de ReAct : le modèle raisonne sur le problème (« le test échoue parce que la fonction ne gère pas les cas null »), agit (modifie le code), observe (relance les tests), et ajuste si nécessaire. La trace de pensée permet de comprendre pourquoi l’agent a fait tel choix architectural.

Navigation web autonome

Les agents web (ChatGPT Operator, browser agents) appliquent ReAct au navigateur : raisonner sur ce qu’il faut faire (« je dois cliquer sur le bouton ‘Ajouter au panier' »), agir (cliquer), observer (la page se met à jour), puis raisonner sur l’étape suivante. Les benchmarks WebShop et WebArena mesurent cette capacité.

Automatisation d’entreprise

Un agent connecté via MCP à Jira, Slack et Google Drive peut recevoir la demande « résume les tickets critiques du sprint et envoie le résumé à l’équipe ». Il raisonne sur la décomposition (lister les tickets → filtrer les critiques → résumer → identifier le canal Slack → envoyer), exécute chaque action, et adapte son approche si un outil ne retourne pas ce qui est attendu.

Bonnes pratiques

Utilisez des exemples few-shot. Le papier original montre que quelques exemples de trajectoires réussies dans le prompt améliorent significativement la qualité du raisonnement et la sélection d’outils. Pour ALFWorld, 3 trajectoires annotées par type de tâche suffisent.

Rendez les descriptions d’outils explicites. « Recherche sur le web » est trop vague. « Recherche sur le web pour trouver des informations factuelles récentes. Utilisez quand la question porte sur des événements, des données ou des faits que vous ne connaissez pas avec certitude » est beaucoup plus efficace.

Limitez les itérations. Fixez un maximum de 5 à 10 cycles Thought-Action-Observation. Au-delà, l’agent perd souvent en cohérence. Si l’agent n’a pas résolu la tâche en 10 cycles, il est préférable de produire une réponse partielle avec les informations collectées plutôt que de continuer indéfiniment.

Permettez le basculement CoT ↔ ReAct. La meilleure stratégie identifiée par le papier combine ReAct et CoT. Si les outils ne retournent pas d’information utile, basculez vers du raisonnement pur. Si le raisonnement pur mène à une hallucination, basculez vers une recherche d’outil.

Inspectez les traces pour le debugging. L’un des avantages majeurs de ReAct est la transparence : vous pouvez lire les « Thoughts » pour comprendre exactement où l’agent s’est trompé. Exploitez cette capacité pour itérer sur vos prompts et descriptions d’outils.