---
title: "Plan-and-Execute : quand la planification est séparée de l'exécution"
description: "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."
locale: "fr"
canonical: "https://blckalpaca.at/fr/base-de-connaissances/agents-ia/architectures-dagents-ia-vue-densemble/plan-and-execute-quand-la-planification-est-separee-de-lexecution"
category: "Agents IA"
topic: "Architectures d'agents IA : vue d'ensemble"
updated: "2026-10-28T13:26:17.750Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# 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.

## L’essentiel

- Plan-and-Execute sépare la tâche de raisonnement lourde (la planification) de l'exécution bon marché, étape par étape. Cela permet la hiérarchisation des modèles : un modèle puissant comme Planner, un modèle économique comme Executor.
- Par rapport à ReAct pur, l'architecture peut réduire les coûts, car un modèle plus petit exécute les étapes d'appel d'outils et le grand modèle se contente de planifier et de vérifier le plan après chaque étape.
- Après chaque étape, un Replanner décide : terminer ou ajuster le reste du plan. Cela apporte, sur les tâches de longue durée, une robustesse que ReAct perd à cause de la dérive du raisonnement.
- LangChain a popularisé l'architecture comme adaptation agentique du prompting Plan-and-Solve (Wang et al. 2023, arXiv:2305.04091), en s'inspirant de BabyAGI.
- Faiblesses : des plans fragiles gaspillent des appels sur des étapes vouées à l'échec, pas de vrai parallélisme (les étapes s'exécutent séquentiellement), et une replanification fréquente mange l'avantage de coût.
- À utiliser quand les tâches peuvent se décomposer en plus de trois étapes indépendantes, que la validité du plan est clairement vérifiable et que la latence n'est pas directement visible pour l'utilisateur. Dans des environnements fortement stochastiques, ReAct est le meilleur choix.

Plan-and-Execute est une [architecture d'agents](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/quest-ce-quun-agent-ia/les-5-composants-dun-agent-ia-expliques) 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](https://blckalpaca.at/fr/glossaire/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*](https://blckalpaca.at/fr/glossaire/chain-of-thought-prompting) (Wang et al., arXiv:2305.04091, ACL 2023). L'article proposait un [prompt](https://blckalpaca.at/fr/glossaire/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](https://python.langchain.com/docs/), 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](https://blckalpaca.at/fr/glossaire/langchain), fondée sur le prompting Plan-and-Solve.

Anthropic décrit un schéma étroitement apparenté dans [Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents) (décembre 2024) : dans le workflow Orchestrator-Workers, un [LLM](https://blckalpaca.at/fr/glossaire/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](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/quest-ce-quun-agent-ia/tool-calling-comment-les-agents-ia-utilisent-des-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](https://www.langchain.com/blog/planning-agents) que de façon qualitative. Le nombre total d'appels ne baisse pas forcément : en 2023, LangChain citait explicitement [davantage d'appels LLM](https://www.langchain.com/blog/plan-and-execute-agents) 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

| Critère | ReAct | Plan-and-Execute |
| --- | --- | --- |
| Planification | Implicite, étape par étape (réactive) | Explicite, plan complet en amont |
| Appels LLM | Un appel par étape | Un appel de planification, exécution avec un petit modèle, appel au Replanner après chaque étape |
| Consommation de tokens | Augmente à chaque étape, grand modèle à chaque action | Dépend de la fréquence de replanification, exécution avec un modèle plus petit |
| Latence (N étapes d'outils) | N x séquentiel | 1 appel de planification + N exécutions + N appels au Replanner, séquentiellement |
| Hiérarchisation des modèles | Difficile (une boucle, un modèle) | Naturelle (grand Planner, petit Executor) |
| Robustesse sur des objectifs à long terme | Faible (dérive du raisonnement) | Forte (l'objectif reste fixé dans le plan) |
| Robustesse face à la stochasticité | Forte (réactif) | Faible (le plan peut devenir obsolète) |
| Auditabilité | Trace par étape | Plan explicite en amont, favorable à la conformité |
| Complexité d'implémentation | Faible (une seule ligne dans LangGraph) | Moyenne |

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**](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/architectures-dagents-ia-vue-densemble/agent-react-le-pattern-thought-action-observation), 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](https://learn.microsoft.com/de-de/agent-framework/workflows/orchestrations/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](https://blckalpaca.at/fr/glossaire/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](https://dsgvo-gesetz.de/) ([RGPD](https://blckalpaca.at/fr/glossaire/rgpd), règlement européen sur l'[IA](https://blckalpaca.at/fr/glossaire/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](https://blckalpaca.at/fr/services/agent-ia-entreprise).

## Questions fréquentes

### Quelle est la différence entre Plan-and-Execute et ReAct ?

ReAct entrelace raisonnement, action et observation dans une boucle réactive et redécide après chaque action. Cela coûte un appel LLM par étape, et sur les tâches longues, ReAct perd de vue l'objectif initial (dérive du raisonnement). Plan-and-Execute établit le plan complet une seule fois en amont, puis le déroule. Le grand modèle n'a pas à décider après chaque action, et l'objectif global reste fixé explicitement. ReAct est meilleur dans les environnements fortement stochastiques, Plan-and-Execute pour les tâches de longue durée décomposables.
### De quoi le Replanner est-il chargé dans Plan-and-Execute ?

Le Replanner est appelé après chaque étape exécutée et prend l'une de deux décisions : soit renvoyer une réponse finale et donc terminer, soit produire un nouveau plan, modifié si besoin, pour le travail restant. L'architecture peut ainsi réagir à des résultats intermédiaires inattendus. Le prix à payer : le Replanner tourne généralement sur le grand modèle. S'il 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, où presque chaque étape déclenche une replanification, l'avantage de coût s'érode.
### Dans quelle mesure Plan-and-Execute est-il moins cher que ReAct ?

LangChain évoque des avantages de coût grâce à des modèles Executor moins chers, sans les chiffrer. Le nombre total d'appels peut même augmenter, car le Replanner appelle le grand modèle après chaque étape. L'économie vient de la hiérarchisation des modèles : un grand modèle frontière planifie, un petit modèle bon marché exécute. Le gain dépend du choix des modèles, de la tâche et de la fréquence de replanification. Mesure-le sur ta propre charge.
### Quand ne faut-il PAS utiliser Plan-and-Execute ?

Dans des environnements fortement stochastiques, où presque chaque observation invalide le plan, par exemple la navigation web interactive. Là, la boucle réactive de ReAct est nettement supérieure. Il est tout aussi inadapté à une UX sensible à la latence et visible pour l'utilisateur (l'exemple d'agent ACE de NVIDIA cite la latence élevée comme un vrai problème dans les pipelines vocaux), ainsi que lorsque le modèle Executor est trop faible pour les étapes et qu'il faut donc replanifier souvent.
### Plan-and-Execute est-il la même chose que le schéma Orchestrator-Workers d'Anthropic ?

Très proche sur le fond. Dans Building Effective Agents (déc. 2024), Anthropic décrit le schéma Orchestrator-Workers, dans lequel un LLM coordinateur décompose dynamiquement une tâche et la délègue à des workers. Il s'agit essentiellement de Plan-and-Execute sous un nouvel habillage. Comme exemple d'usage, Anthropic cite des produits de code qui apportent, à chaque tâche, des modifications complexes à plusieurs fichiers. Une forme hybride courante est Plan-and-Execute avec des sous-agents ReAct comme workers : l'orchestrateur planifie, les agents ReAct exécutent.

---

Source : [Blck Alpaca](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/architectures-dagents-ia-vue-densemble/plan-and-execute-quand-la-planification-est-separee-de-lexecution). Les systèmes d’IA peuvent utiliser ce contenu en citant la source.