Accueil › Glossaire › Plan-Execute

Plan-Execute

Le pattern Plan-Execute est une architecture d’agent IA qui sépare explicitement la phase de planification (un LLM génère un plan multi-étapes complet) de la phase d’exécution (un agent ou un LLM plus petit exécute chaque étape séquentiellement), avec une phase de re-planification optionnelle qui ajuste le plan en fonction des résultats obtenus.

C’est une réponse directe aux limites du pattern ReAct. Dans ReAct, l’agent décide de sa prochaine action à chaque étape, sans vision globale. Il peut tourner en rond, manquer des étapes importantes, ou suivre des trajectoires sous-optimales. Le pattern Plan-Execute force l’agent à réfléchir au problème dans son ensemble avant de commencer à agir, tout en conservant la flexibilité de s’adapter quand les choses ne se passent pas comme prévu.

Inspiré par le papier « Plan-and-Solve Prompting » (Wang et al., 2023) et le projet BabyAGI de Yohei Nakajima, le pattern Plan-Execute est implémenté dans LangGraph et est devenu l’architecture recommandée pour les tâches complexes nécessitant coordination et multi-étapes.

Pourquoi séparer planification et exécution

Le pattern ReAct (Thought-Action-Observation) est efficace mais présente deux faiblesses structurelles pour les tâches complexes :

Un appel LLM par action : à chaque étape, le LLM complet est invoqué pour décider de la prochaine action. Sur une tâche à 10 étapes, c’est 10 appels au modèle frontier, chacun avec un contexte croissant. Le coût et la latence augmentent linéairement.

Pas de planification globale : le LLM ne « voit » qu’une étape à la fois. Il ne peut pas optimiser la séquence d’actions, identifier les dépendances entre étapes, ni paralléliser les tâches indépendantes. Cela mène à des trajectoires sous-optimales.

Le pattern Plan-Execute résout ces deux problèmes en séparant les responsabilités : un LLM puissant (le Planner) pense au problème globalement une seule fois, puis des exécuteurs plus légers (les Executors) gèrent chaque étape individuellement.

Architecture en trois composants

Le Planner (planificateur)

Le Planner est un LLM frontier (Claude Opus 4.6, GPT-5.4) qui reçoit l’objectif de l’utilisateur et génère un plan multi-étapes. Ce plan est une liste ordonnée de sous-tâches, chacune suffisamment précise pour être exécutable par un agent simple avec des outils.

Le prompt du Planner inclut typiquement : l’objectif de l’utilisateur, les outils disponibles, et une instruction de produire un plan concis sans étapes superflues. Le résultat est structuré (liste numérotée ou JSON) pour être parsé par le système.

Exemple de plan généré : pour l’objectif « quel est l’âge du Premier ministre du Manitoba élevé à la puissance 0,43 ? », le Planner produit : (1) Rechercher qui est le Premier ministre actuel du Manitoba, (2) Trouver son âge, (3) Calculer cet âge élevé à la puissance 0,43.

L’Executor (exécutant)

L’Executor reçoit chaque sous-tâche du plan et l’exécute en utilisant les outils disponibles (recherche web, calculatrice, base de données, API). Il peut être un agent ReAct simple, un LLM plus petit et moins coûteux, ou même un script codé pour les étapes mécaniques.

L’avantage clé : l’Executor n’a pas besoin d’être un modèle frontier. Un modèle économique (Haiku, Flash, GPT-4o-mini) peut exécuter les sous-tâches individuelles, car elles sont suffisamment simples et bien définies par le Planner. C’est ce qui permet la réduction de coût de 90% mentionnée dans les architectures Planner-Worker.

Le Replanner (re-planificateur)

Après chaque exécution, le Replanner évalue les résultats et décide : le plan est-il toujours valide ? Faut-il ajuster les étapes restantes ? Peut-on répondre à l’utilisateur ?

Le Replanner reçoit en contexte : l’objectif original, le plan initial, les étapes déjà complétées avec leurs résultats, et les étapes restantes. Il peut : confirmer la prochaine étape, modifier le plan si une étape a produit un résultat inattendu, ajouter des étapes manquantes, ou conclure que l’objectif est atteint et formuler la réponse finale.

C’est cette capacité de re-planification qui distingue le pattern Plan-Execute d’un simple plan statique. L’agent s’adapte aux résultats réels sans perdre la vision globale.

Plan-Execute vs ReAct : quand utiliser lequel

En pratique, les meilleurs agents combinent les deux : le Planner utilise une vue Plan-Execute globale, et chaque Executor utilise une boucle ReAct locale pour ses sous-tâches. C’est l’architecture dominante dans Claude Code, Codex et les agents de recherche avancés.

Variantes du pattern

ReWOO (Reasoning Without Observation)

ReWOO (Xu et al.) pousse la séparation plus loin : le Planner génère le plan complet avec des variables d’assignation. Les étapes peuvent référencer les résultats d’étapes précédentes via des variables (${1} pour le résultat de l’étape 1). Cela permet d’exécuter certaines étapes en parallèle et évite d’appeler le LLM entre chaque action.

Exemple : « Étape 1 : Search(Premier ministre du Manitoba). Étape 2 : Search(âge de ${1}). Étape 3 : Calculate(${2} ^ 0.43). » Les étapes 1 et 2 sont séquentielles (2 dépend de 1), mais si d’autres étapes étaient indépendantes, elles pourraient s’exécuter en parallèle.

Le papier revendique une accélération de 3,6× grâce à cette parallélisation.

LLMCompiler (DAG de tâches)

LLMCompiler va encore plus loin en construisant un graphe acyclique dirigé (DAG) de tâches plutôt qu’une simple liste. Une unité de scheduling (Task Fetching Unit) ordonnance les tâches dès que leurs dépendances sont satisfaites, et un Joiner évalue dynamiquement s’il faut re-planifier ou répondre. C’est l’approche la plus performante pour les tâches hautement parallélisables.

LangChain Deep Agents

Lancé en mars 2026, Deep Agents est un « harness » d’agent construit sur LangGraph qui intègre la planification via un outil write_todos, la gestion de contexte via des outils filesystem (écrire des notes, résultats intermédiaires dans des fichiers), et la délégation de sous-tâches à des sous-agents isolés. C’est l’évolution la plus récente du pattern Plan-Execute dans l’écosystème LangChain.

Implémentation avec LangGraph

L’implémentation officielle dans LangGraph utilise un graphe à trois nœuds :

Nœud « planner » : génère le plan initial à partir de l’objectif utilisateur.

Nœud « agent » : exécute la prochaine étape du plan avec les outils disponibles.

Nœud « replan » : évalue les résultats, met à jour le plan, et décide de continuer ou de terminer.

Les arêtes du graphe : planner → agent → replan → (agent si le plan continue, END si terminé). La condition de sortie vérifie si le Replanner a produit une Response (réponse finale) ou un Plan (suite du travail).

Le prompt du Replanner est crucial. Il reçoit l’objectif original, le plan initial, les étapes complétées avec leurs résultats, et l’instruction : « Mettez à jour votre plan en conséquence. Si plus aucune étape n’est nécessaire, répondez directement. Sinon, ne listez que les étapes qu’il reste à faire. »

Cas d’usage concrets

Recherche multi-sources

« Compare les parts de marché de Salesforce, HubSpot et Pipedrive en Europe en 2025. » Le Planner décompose : (1) rechercher les chiffres Salesforce Europe, (2) rechercher HubSpot Europe, (3) rechercher Pipedrive Europe, (4) synthétiser la comparaison. Les trois premières étapes sont indépendantes et parallélisables.

Développement logiciel

Claude Code applique Plan-Execute implicitement : face à une issue GitHub, il analyse le problème (planification), implémente les modifications (exécution), lance les tests (vérification), et ajuste si des tests échouent (re-planification). L’ensemble du cycle est un Plan-Execute avec boucle de feedback.

Automatisation d’entreprise

« Prépare un rapport hebdomadaire : récupère les métriques Jira, les données Google Analytics, crée un résumé et envoie-le par email. » Le Planner identifie les 4 sous-tâches, l’Executor appelle les API respectives via MCP, et le Replanner vérifie que toutes les données sont collectées avant de passer à la synthèse.

Limites

Rigidité du plan : si l’étape 3 sur 5 révèle que l’approche entière est mauvaise, le Replanner doit reconstruire un plan depuis zéro. C’est plus coûteux que l’adaptabilité continue de ReAct.

Qualité du plan initial : si le Planner produit un plan incomplet ou mal ordonné, l’exécution échouera même avec un bon Executor. Le few-shot prompting et des descriptions d’outils détaillées améliorent la qualité du plan.

Overhead de coordination : les appels au Replanner après chaque étape ajoutent de la latence. Pour les tâches simples (2-3 étapes), un agent ReAct simple est souvent plus rapide.

Passage d’information entre étapes : le résultat d’une étape doit être correctement transmis à l’étape suivante. Si le Planner et l’Executor sont des LLM différents, le format de passage de contexte (résumé textuel, JSON structuré, variables) doit être bien défini.

Bonnes pratiques

Gardez les plans concis. Instruisez le Planner de ne pas ajouter d’étapes superflues. Un plan de 15 étapes pour une tâche qui en nécessite 5 gaspille des ressources et augmente le risque d’erreur.

Chaque étape doit être auto-suffisante. Une étape du plan doit contenir toutes les informations nécessaires à son exécution, sans dépendance implicite au contexte. L’Executor ne devrait pas avoir besoin de « deviner » ce que le Planner voulait dire.

Limitez la re-planification. Autorisez 2 à 3 cycles de re-planification maximum. Au-delà, le système peut entrer dans une boucle de re-planification indéfinie. Si le plan n’est pas résolvable après 3 tentatives, escaladez vers l’utilisateur.

Exploitez la parallélisation. Identifiez les étapes indépendantes et exécutez-les simultanément. Les variantes ReWOO et LLMCompiler rendent cela natif, mais même avec une implémentation simple, vous pouvez détecter les dépendances et paralléliser manuellement.

Observez et itérez. Utilisez un outil d’observabilité (LangSmith, Langfuse) pour visualiser les plans générés, les résultats d’exécution et les re-planifications. Les plans défaillants révèlent des lacunes dans les descriptions d’outils ou dans le prompt du Planner.

Évolution du pattern en 2026

Le pattern Plan-Execute a considérablement évolué depuis ses origines. Plusieurs tendances marquent sa maturation.

Intégration avec le filesystem comme mémoire. LangChain Deep Agents (mars 2026) utilise des outils filesystem pour persister le plan, les résultats intermédiaires et les notes de l’agent dans des fichiers. Cela résout le problème de l’overflow de la fenêtre de contexte sur les tâches longues : au lieu de tout garder dans le prompt, l’agent écrit dans des fichiers et relit sélectivement ce dont il a besoin.

Sous-agents avec contexte isolé. Les Deep Agents permettent de spawner des sous-agents qui héritent d’un sous-ensemble du contexte du parent. Chaque sous-agent travaille sur sa sous-tâche avec un contexte propre et frais, éliminant le context drift qui dégrade les performances sur les tâches longues.

Domain-specific cognitive architectures. La tendance identifiée par LangChain est de coder la logique de planification dans l’architecture de l’application plutôt que de la laisser au LLM. Pour un agent de code, la séquence « écrire les tests → coder → exécuter les tests → corriger » est codée en dur dans le flux, pas générée par le Planner. Le LLM se concentre sur le contenu de chaque étape, pas sur la structure du plan. C’est l’approche d’AlphaCodium, de Claude Code et des agents les plus fiables en production.

Convergence avec le multi-agent. Dans les systèmes multi-agents (AutoGen Magentic-One, CrewAI), le Plan-Execute se transforme : le Planner est un agent orchestrateur qui assigne les sous-tâches à des agents spécialisés. Chaque agent spécialisé est un Executor avec ses propres outils et son propre contexte. L’orchestrateur joue le rôle combiné de Planner et Replanner.

Le conseil clé pour les développeurs en mars 2026 : commencez par un Plan-Execute simple avec LangGraph (3 nœuds), puis évoluez vers les variantes plus sophistiquées (ReWOO, Deep Agents, multi-agent) uniquement quand les limitations apparaissent en production.