ReAct vs Plan-and-Execute vs LATS : 3 patterns, 1 bench

Trois patterns d'agents dominent le paysage des agents LLM depuis 2024 : ReAct, Plan-and-Execute et LATS (Language Agent Tree Search). Chaque pattern a ses fans, ses benchmarks officiels, et ses haters. Moi, je voulais savoir lequel tient vraiment la route quand on les pose sur les mêmes 4 tâches avec le même modèle sous-jacent. Verdict après 80 runs et 37 $ de facture : le résultat est beaucoup moins clair que les tutoriels veulent bien le dire. Voici mon benchmark complet.

Les 3 patterns en 30 secondes chacun

ReAct (Reason + Act) : l'agent alterne « réfléchis » / « agis ». Pattern le plus simple, le plus ancien, le plus utilisé. Chaque tour = une pensée + une action + une observation. Boucle jusqu'à stop.

Plan-and-Execute : l'agent commence par produire un plan complet (5-10 étapes) avant d'agir. Puis il exécute chaque étape. Si une étape échoue, il replanifie.

LATS : variation tree search sur ReAct. L'agent explore plusieurs branches d'actions en parallèle, évalue chaque branche avec un scoring, et choisit la meilleure. Théoriquement supérieur, pratiquement coûteux.

Les 4 tâches test

Chaque tâche est lancée 20 fois par pattern avec le même modèle (Claude Sonnet 4.5, température 0,3). Budget max 3 $ par run.

Les résultats bruts

Taux de succès (task complete + tests verts)

Coût moyen par run (USD)

Latence moyenne (secondes)

Les 3 enseignements contre-intuitifs

Enseignement 1 : ReAct gagne sur les tâches simples

Sur T1 (debug test), ReAct a un taux de succès de 95% — meilleur que les deux autres. Pourquoi ? Parce qu'un debug simple est un aller-retour rapide avec l'environnement : lance le test, lis l'erreur, fix, relance. Plan-and-Execute perd du temps à produire un plan que le premier tool call rend obsolète. LATS perd du temps à explorer des branches inutiles.

Leçon : sur les tâches courtes (< 10 tool calls), la simplicité de ReAct bat les patterns plus sophistiqués.

Enseignement 2 : Plan-and-Execute brille sur les tâches cadrées

Sur T2 (endpoint REST) et T3 (CSV), Plan-and-Execute gagne. Ces deux tâches ont une structure claire : il y a un « bon » plan qu'on peut produire à l'avance, puis il suffit de l'exécuter. ReAct, qui improvise, rate souvent une étape (oublie d'ajouter la validation, oublie de tester les cas d'erreur). LATS explore trop.

Leçon : sur les tâches structurées où un plan est devinable à l'avance, Plan-and-Execute bat ReAct de 10-15 points.

Enseignement 3 : LATS ne vaut le coup que sur les tâches très dures

Sur T4 (refactor d'un module complexe), LATS gagne nettement — 80% vs 70% (PaE) vs 55% (ReAct). Mais au prix de 2,87 $ par run contre 0,95-1,18 $ pour les autres. Soit un surcoût de 2,4× pour +10 points de succès.

Leçon : LATS ne se justifie que si tu es prêt à payer 3× pour gagner 10 points, et seulement sur des tâches très complexes (>15 tool calls).

Ma matrice de décision

Après 80 runs, voici ma règle simple :

Un pattern hybride qui marche encore mieux

Pendant mes tests, j'ai essayé une combinaison : produire un plan rapide (3 étapes max, via Plan-and-Execute), puis exécuter chaque étape en mode ReAct. Sur mes 4 tâches, ce hybride a donné un taux de succès moyen de 87%, meilleur que n'importe quel pattern seul, pour un coût équivalent à Plan-and-Execute.

def hybrid_agent(task):
    plan = produce_plan(task, max_steps=3)  # une seule fois
    for step in plan:
        react_loop(step, max_iterations=10)

C'est devenu mon défaut depuis 2 mois.

Ce qu'il faut retenir

1. 1.Aucun pattern n'est universellement meilleur — chaque tâche a son sweet spot.
2. 2.ReAct gagne sur les tâches courtes, Plan-and-Execute sur les tâches structurées, LATS sur les tâches complexes critiques.
3. 3.LATS coûte 2-3× plus cher pour des gains marginaux sauf sur les tâches très longues.
4. 4.Un hybride Plan (court) + ReAct est souvent meilleur que n'importe lequel des 3 purs.

Pour aller plus loin sur l'architecture de chacun de ces patterns et leur implémentation en Python avec LangGraph, j'ai écrit un guide complet :

Agents LLM en Python

Des agents qui marchent. En Python.

Découvrir →