Plan-and-Execute : quand la planification est séparée de l'exécution

Plan-and-Execute est une architecture d'agents dans laquelle un Planner établit d'abord un plan complet en plusieurs étapes, puis un Executor le déroule étape par étape. Un Replanner ajuste le plan si nécessaire. Séparer la planification de l'exécution permet de confier chaque étape à un modèle plus petit et améliore le contrôle sur les tâches de longue durée par rapport à ReAct pur.

Les réponses rapides d'abord :

• Ce que cela résout : le raisonnement étape par étape de ReAct manque de vue d'ensemble : sur les tâches longues, l'agent oublie l'objectif initial. Plan-and-Execute impose l'objectif grâce à un plan explicite établi à l'avance.
• Pourquoi cela peut coûter moins cher : un modèle plus petit et moins cher exécute chaque étape. Le grand modèle se contente de planifier et de vérifier après chaque étape si le plan tient toujours (hiérarchisation des modèles).
• Le compromis central : un meilleur contrôle et des plans auditables, contre la fragilité des plans et l'absence de vrai parallélisme. Dans des environnements fortement stochastiques, ReAct est nettement supérieur.

Origine : Plan-and-Solve, BabyAGI et le portage LangChain

Une mise en contexte précise compte ici, car l'attribution est souvent simplifiée. Le schéma de prompting sous-jacent vient de Plan-and-Solve Prompting (Wang et al., arXiv:2305.04091, ACL 2023). L'article proposait un prompt zero-shot en deux temps, en substance « Commençons par élaborer un plan / Exécutons le plan », et surpassait ainsi Zero-Shot-CoT en raisonnement mathématique.

Le nom d'agent « Plan-and-Execute » vient cependant du portage LangChain, pas de l'article original. L'architecture s'est en outre inspirée de BabyAGI (Yohei Nakajima, 2023). La formulation exacte est donc : l'architecture d'agents Plan-and-Execute popularisée par LangChain, fondée sur le prompting Plan-and-Solve.

Anthropic décrit un schéma étroitement apparenté dans Building Effective Agents (décembre 2024) : dans le workflow Orchestrator-Workers, un LLM central décompose dynamiquement une tâche, délègue les parties à des LLM workers et fusionne leurs résultats.

Les trois composants

La variante LangGraph se compose de trois nœuds :

1. Planner : génère une seule fois un plan numéroté en plusieurs étapes (Plan: List[str]).
2. Executor : en général un sous-agent ReAct qui traite les étapes du plan l'une après l'autre.
3. Replanner : décide après chaque exécution s'il renvoie une Response finale (fin du processus) ou s'il produit un nouveau plan, modifié si besoin, pour le travail restant.

Le déroulement :

Input → Planner → [Plan: Schritt_1, Schritt_2, …] → Executor(Schritt_1) → Replanner → (Executor(Schritt_2) → Replanner → …) → Response

L'innovation centrale : Plan-and-Execute découple la planification (une tâche de raisonnement lourde, pour laquelle un grand modèle se justifie) de l'exécution (utilisation d'outils étape par étape, pour laquelle un modèle plus petit et moins cher suffit).

Avantages par rapport à ReAct pur

• Exécution multi-étapes plus rapide : l'Executor traite seul une étape du plan avec tous ses appels d'outils. Le grand modèle n'intervient qu'ensuite, et non après chaque action.
• Économies grâce à la hiérarchisation des modèles : un grand modèle frontière planifie, un petit modèle bon marché exécute les étapes. LangChain ne décrit cet avantage de coût par rapport à ReAct que de façon qualitative. Le nombre total d'appels ne baisse pas forcément : en 2023, LangChain citait explicitement davantage d'appels LLM comme le prix du schéma et reconnaissait que beaucoup de ces avantages n'avaient pas fait l'objet de benchmarks.
• Des plans explicites et auditables : un argument de poids pour les applications d'entreprise et de conformité, car le plan est visible avant l'exécution.
• Vue d'ensemble : l'objectif global se maintient sur de longues trajectoires au lieu de se perdre dans la « dérive du raisonnement » de ReAct.

Faiblesses et modes de défaillance

Plan-and-Execute n'est pas une panacée. Ses principales limites :

• 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'article Plan-and-Solve documente lui-même des erreurs de calcul, des étapes manquantes et des malentendus sémantiques.
• Pas de vrai parallélisme : les plans sont des listes, que l'Executor traite séquentiellement. C'est précisément ce que corrige LLMCompiler (Kim et al., arXiv:2312.04511), qui émet un DAG au lieu d'une liste.
• Coût de la replanification : si le Replanner doit souvent replanifier, des étapes s'ajoutent, et chaque étape supplémentaire coûte un passage de plus par l'Executor et le Replanner. Dans des environnements bruités, cela arrive presque à chaque étape et érode l'avantage de coût.
• Le choix du modèle est déterminant : si le modèle Executor est trop faible pour les étapes, davantage d'étapes échouent, le Replanner doit replanifier plus souvent et l'avantage de coût fond.

ReAct vs. Plan-and-Execute : comparaison directe

La ligne sur les tokens décrit des tendances, pas des mesures. Vérifie sur ta propre charge.

Pseudocode : la boucle Plan-and-Execute

Version simplifiée, calquée sur la logique du schéma d'état de LangGraph :

```

State: input, plan (liste), past_steps (terminés), response

def planner(state):
# un grand modèle établit UNE SEULE FOIS le plan complet
state.plan = big_model.plan(state.input) # p. ex. ["1. ...", "2. ...", "3. ..."]
return state

def executor(state):
etape = state.plan[0] # prochaine étape en attente
resultat = small_model.run_react(etape) # sous-agent ReAct bon marché + outils
state.past_steps.append((etape, resultat))
return state

def replanner(state):
# soit terminé -> Response, soit nouveau plan pour le travail restant
if big_model.is_done(state):
state.response = big_model.final_answer(state)
return state, "END"
state.plan = big_model.replan(state.input, state.past_steps)
return state, "executor"

Graphe: planner -> executor -> replanner -> (executor | END)

```

Le point décisif : big_model (coûteux) ne tourne que dans planner et replanner, tandis que small_model (bon marché) porte la charge d'exécution réelle.

Exemple concret : rapport marketing quotidien

Une agence construit un agent qui produit chaque matin un rapport de veille concurrentielle. Tâche : « Recherche les trois principaux concurrents, collecte leurs nouveaux contenus des dernières 24 heures, résume-les et envoie le tout par e-mail. »

Avec ReAct pur, l'agent rappellerait le modèle complet après chaque action (recherche, scraping, résumé), avec toute la fenêtre de contexte accumulée jusque-là. Sur 12 étapes, cela fait 12 appels coûteux plus un préfixe qui ne cesse de grandir.

Avec Plan-and-Execute, le Planner établit le plan une seule fois (1 appel coûteux) :

```
Plan:

1. Identifier les concurrents A, B, C
2. Pour chacun : scraper les nouveaux contenus de blog et de réseaux sociaux des dernières 24h
3. Résumer brièvement chaque concurrent
4. Mettre en forme le rapport global
5. Envoyer par e-mail à l'équipe
   ```

Les étapes 2-5 passent ensuite par un Executor bon marché. Le grand modèle se contente de vérifier après chaque étape si le plan tient toujours, et replanifie si, par exemple, une source est inaccessible. Si cela reste l'exception, cette tâche par lots revient moins cher, car le vrai travail repose sur le modèle bon marché. En prime, le plan est documenté de façon traçable pour l'agence.

Mise en œuvre dans les frameworks (état 2026)

• LangGraph : natif, avec un tutoriel officiel. Schéma d'état canonique avec input, plan: List[str], past_steps et response ; nœuds planner, agent (Executor) et replan. Une arête conditionnelle should_end ramène à l'Executor ou à END.
• CrewAI : correspondance directe via Crew(planning=True). Cela active un AgentPlanner qui, avant chaque itération de la crew, établit un plan étape par étape et l'injecte dans chaque description de tâche. Avec Process.hierarchical plus manager_agent/manager_llm, une couche de management qui replanifie vient s'ajouter.
• AutoGen / Microsoft Agent Framework : mise en œuvre via un group chat avec un agent Planner dédié et des agents workers (RoundRobinGroupChat ou SelectorGroupChat). Dans Microsoft Agent Framework, l'orchestration Magentic est la plus proche du schéma : un agent manager établit un plan de tâches, répartit les étapes entre des agents spécialisés et replanifie quand la progression stagne. Sur demande, un humain valide le plan avant l'exécution. En 2026, AutoGen est en mode maintenance ; Microsoft oriente les nouveaux projets vers MS Agent Framework.
• n8n : pas de nœud Plan-and-Execute natif, mais c'est réaliste avec deux nœuds AI Agent (Planner + Executor), reliés par une boucle SplitInBatches qui parcourt les points du plan. Limite : sans stockage externe, les boucles n8n ne conservent pas d'état d'une exécution à l'autre. Cela suffit pour des traitements par lots (rapports quotidiens, pipelines de contenu), pas pour des agents temps réel à haute fréquence.

Quand l'utiliser et quand s'en passer

Utilise Plan-and-Execute si (a) les tâches peuvent se décomposer en plus de trois étapes indépendantes, (b) tu disposes d'une instance de contrôle claire pour la validité du plan et (c) la latence n'est pas directement visible pour l'utilisateur.

Renonce-y si l'environnement est fortement stochastique. Si chaque observation peut invalider le plan (par exemple en navigation web interactive), la boucle réactive de ReAct est nettement meilleure. Pour les workflows critiques en matière de conformité dans l'UE (RGPD, règlement européen sur l'IA), Plan-and-Execute avec human-in-the-loop s'impose : plan auditable, exécution traçable étape par étape.

Pour les agences et les décideurs B2B

Plan-and-Execute est le schéma naturel pour les processus multi-étapes planifiables et récurrents, qui font le quotidien des agences : pipelines de reporting, workflows de recherche, production de contenu. Le schéma apporte deux choses : une baisse de coûts possible grâce à la hiérarchisation des modèles et un plan vérifiable, visible dès le départ. Les deux répondent précisément aux exigences de conformité et de maîtrise budgétaire du B2B en Europe. Le conseil pragmatique tiré de l'expérience en production vaut toutefois ici aussi : commence par le schéma le plus simple qui fonctionne (le plus souvent ReAct) et ne passe à Plan-and-Execute que lorsque des modes de défaillance mesurés, comme la dérive du raisonnement, les coûts ou le manque de vue d'ensemble, le justifient. Si tu évalues quelle architecture d'agents convient à ton cas d'usage concret, Blck Alpaca t'accompagne dans le choix, la hiérarchisation des modèles et une mise en œuvre auditable.