Patterns agentiques : ReAct, Plan-and-Execute, Reflexion

Un agent IA n'a pas une seule façon de raisonner. Selon le problème, on structure son raisonnement différemment — et ce choix d'architecture pèse autant sur la qualité que le modèle lui-même. Ce guide présente les quatre patterns de raisonnement les plus utiles : ReAct, Plan-and-Execute, Reflexion et Self-Consistency. Pour chacun : le principe, le cas où il brille, son coût. Puis vous comparerez deux de ces patterns sur une tâche identique, avec une évaluation objective — pour mesurer, et pas seulement supposer, lequel est le plus adapté. Public visé : développeur ayant construit des agents et voulant choisir leur architecture de raisonnement en connaissance de cause.

Ce que vous allez apprendre

Pourquoi le pattern de raisonnement est un choix d'architecture à part entière.
Les quatre patterns : ReAct, Plan-and-Execute, Reflexion, Self-Consistency.
Le cas d'usage et le coût de chacun.
Comparer deux patterns sur une tâche identique, avec une mesure objective.

Prérequis

Ce guide prolonge Comprendre les agents IA, qui a introduit la boucle ReAct. Il vous faut :

Une instance Ollama avec le modèle qwen2.5.
Les bases de Python.

Pourquoi des patterns de raisonnement

Donner une tâche complexe à un modèle en un seul prompt — « fais ceci » — fonctionne pour les cas simples. Dès que la tâche demande de planifier, de se corriger ou d'explorer, la réponse en un coup plafonne : le modèle n'a pas l'occasion de revenir sur son travail.

Un pattern de raisonnement est une façon de structurer les appels au modèle pour dépasser ce plafond. Au lieu d'un appel, on en orchestre plusieurs — pour planifier, pour critiquer, pour comparer. Le pattern n'est pas dans le modèle : il est dans le code qui l'appelle. C'est une décision d'architecture, et elle a un coût : plus de tours, c'est plus d'appels, donc plus de latence et de dépense.

Quatre patterns reviennent constamment. Les connaître, c'est savoir lequel sortir face à un problème donné.

ReAct : raisonner et agir en alternance

ReAct — Reason + Act — est le pattern de base, celui du premier guide sur les agents. Le modèle alterne : il réfléchit (Thought), il agit en appelant un outil (Act), il lit le résultat (Observation), et il recommence jusqu'à pouvoir répondre.

Sa force est l'adaptabilité : chaque action dépend du résultat de la précédente. C'est le bon pattern quand le parcours n'est pas connu d'avance — une recherche, un diagnostic, une exploration. Sa limite : sans plan d'ensemble, l'agent peut tourner en rond ou s'égarer sur une longue tâche. ReAct excelle sur les tâches réactives, moins sur les tâches qui demandent une vue d'ensemble.

Plan-and-Execute : planifier avant d'agir

Plan-and-Execute sépare ce que ReAct mélange. D'abord, le modèle établit un plan — la liste des étapes. Ensuite seulement, il exécute ce plan.

def plan_and_execute() -> str:
    """Planifier d'abord, exécuter ensuite — la réflexion avant l'action."""
    plan = _llm([
        {"role": "system", "content": "Tu découpes une tâche en 3 étapes "
         "courtes, une par ligne."},
        {"role": "user", "content": f"Tâche : {TACHE}"},
    ])
    resultat = _llm([
        {"role": "system", "content": "Tu exécutes un plan et renvoies "
         "uniquement le résultat final, sans commentaire."},
        {"role": "user", "content":
         f"Tâche : {TACHE}\n\nPlan :\n{plan}\n\nProduis la phrase finale."},
    ])
    return resultat

L'intérêt est la vue d'ensemble : en planifiant d'abord, l'agent garde un cap et ne se perd pas dans les détails. C'est le bon pattern pour une tâche structurée, à étapes connaissables — un rapport, une procédure, une transformation en plusieurs passes. Sa limite est le revers de sa force : un plan figé s'adapte mal si une étape révèle un imprévu. Plan-and-Execute brille quand le chemin se laisse anticiper.

Reflexion : répondre, critiquer, corriger

Reflexion ajoute une boucle d'auto-correction. Le modèle produit une réponse, puis la critique — qu'est-ce qui ne va pas ? —, puis la corrige. Et il recommence, jusqu'à ce que la réponse tienne ou qu'un budget d'itérations soit épuisé.

def reflexion(max_iterations: int = 3) -> str:
    """Répondre, critiquer, corriger en boucle jusqu'à tenir les contraintes."""
    reponse = _llm([
        {"role": "system", "content": "Tu réponds à la tâche en une phrase."},
        {"role": "user", "content": TACHE},
    ])
    for _ in range(max_iterations):
        if evaluer(reponse)["score"] == 4:
            break  # toutes les contraintes sont tenues
        critique = _llm([...])   # qu'est-ce qui cloche ?
        reponse = _llm([...])    # corrige en tenant compte de la critique
    return reponse

Reflexion est le pattern de la qualité par itération : chaque tour rapproche du but. Il brille sur les tâches où l'on peut juger la réponse — un texte sous contraintes, du code qui doit passer des tests, une sortie à valider. Son coût est le plus visible : chaque itération ajoute deux ou trois appels. Et il faut un critère d'arrêt — un budget d'itérations, sinon la boucle ne se ferme jamais.

Self-Consistency : voter entre plusieurs réponses

Self-Consistency ne boucle pas : il parallélise. On pose la même question plusieurs fois au modèle, avec une part d'aléa, ce qui produit plusieurs réponses indépendantes. Puis on retient la meilleure — par vote majoritaire si la réponse est une valeur, ou en gardant la réponse la mieux notée.

L'intuition : une erreur est souvent idiosyncratique, une bonne réponse est stable. En échantillonnant plusieurs fois, le bon résultat ressort par convergence. C'est le pattern des tâches à réponse vérifiable ou comparable — un calcul, un classement, un choix. Son coût est proportionnel au nombre d'échantillons, mais ces appels sont indépendants, donc parallélisables — la latence ne suit pas le coût.

Comparer les patterns sur une tâche

Choisir un pattern « au feeling » est une erreur. La bonne méthode : les mesurer sur une tâche identique, avec une évaluation objective.

Le lab le fait sur une tâche vérifiable — produire une phrase contenant trois mots-clés imposés, sous une limite de longueur. Une fonction evaluer, déterministe, note chaque sortie sur 4. Et un compteur d'appels au modèle matérialise le coût.

=== Plan-and-Execute ===
Phrase : L'utilisation d'images de conteneur sécurisée garantit la protection des données.
Évaluation : score 3 sur 4 | Appels modèle : 2

=== Reflexion ===
Phrase : L'utilisation d'images dans les conteneurs renforce la sécurité du système.
Évaluation : score 4 sur 4 | Appels modèle : 1

Sur ce run, Reflexion atteint le score parfait — et s'arrête au premier tour, sa réponse initiale tenant déjà les contraintes : un seul appel. Plan-and-Execute en utilise deux et n'obtient que 3 sur 4. La leçon n'est pas « Reflexion gagne toujours » : les résultats varient d'un run à l'autre, c'est la nature d'un raisonnement par LLM. La leçon est méthodologique : on ne compare des patterns qu'avec une métrique commune et un compteur de coût.

Quel pattern pour quel problème

Aucun pattern n'est supérieur dans l'absolu. Le choix dépend de la nature de la tâche.

Pattern	Brille quand…	Coût	Limite
ReAct	Le parcours est imprévisible, exploratoire	Variable	Peut tourner en rond sans plan
Plan-and-Execute	Les étapes sont connaissables d'avance	Modéré	Plan figé, s'adapte mal aux imprévus
Reflexion	La réponse peut être jugée et corrigée	Élevé (itératif)	Exige un juge fiable et un budget
Self-Consistency	La réponse est vérifiable ou comparable	Élevé (parallèle)	Inutile sans critère de sélection

La règle de décision : parcours inconnu → ReAct ; étapes anticipables → Plan-and-Execute ; réponse jugeable → Reflexion ; réponse comparable entre échantillons → Self-Consistency. Et rien n'interdit de les combiner — un agent peut planifier, puis appliquer Reflexion à chaque étape.

Dépannage

Symptôme	Cause probable	Solution
L'agent ReAct ne s'arrête jamais	Pas de condition de fin claire	Borner le nombre de tours, soigner le prompt
Plan-and-Execute exécute un plan absurde	Plan jamais relu	Ajouter une étape de validation du plan
Reflexion dégrade la réponse	Juge absent ou peu fiable	Brancher une évaluation déterministe
Reflexion ne se termine pas	Pas de budget d'itérations	Imposer un `max_iterations`
Self-Consistency coûte cher pour rien	Tâche sans réponse comparable	Choisir un autre pattern

À retenir

Le pattern de raisonnement est un choix d'architecture : il vit dans le code qui appelle le modèle.
ReAct alterne réflexion et action — pour les parcours imprévisibles.
Plan-and-Execute planifie puis exécute — pour les étapes anticipables.
Reflexion répond, critique, corrige en boucle — pour les réponses jugeables, avec un juge fiable.
Self-Consistency échantillonne et sélectionne — pour les réponses comparables.
On ne compare des patterns qu'avec une métrique commune et un compteur de coût — pas au feeling.

Prochaines étapes

Comprendre les agents IA La boucle ReAct de base, point de départ de tous les patterns.

LangGraph multi-agents Composer des agents — une autre dimension de l'architecture.

Comparatif des frameworks d'agents Choisir l'outil après avoir choisi le pattern.

Le parcours agents IA Situer les patterns dans le parcours complet.

Pour aller plus loin

ReAct: Synergizing Reasoning and Acting — l'article fondateur du pattern ReAct.
Reflexion: Language Agents with Verbal Reinforcement Learning — l'article du pattern Reflexion.