Accueil › Glossaire › Planning Agent

Planning Agent

Un planning agent est un agent IA piloté par un LLM qui, face à une tâche complexe, décompose l’objectif en sous-tâches ordonnées, formule un plan d’exécution, puis orchestre les étapes une par une en utilisant des outils, du code ou d’autres agents pour atteindre le résultat final.

C’est la capacité qui distingue un chatbot d’un véritable agent IA. Un chatbot répond à une question. Un planning agent reçoit un objectif (« refactorise ce codebase en TypeScript » ou « organise une conférence technique sur les agents IA ») et construit de manière autonome la séquence d’actions nécessaires pour l’atteindre.

La planification est l’une des cinq catégories fondamentales de la recherche sur les agents LLM, aux côtés de la décomposition de tâches, la sélection de plans, la réflexion et la mémoire. Elle s’appuie sur des techniques comme le chain-of-thought, le pattern ReAct et le framework Plan-Execute.

Pourquoi la planification est essentielle

Les LLM excellent sur des tâches focalisées et bien délimitées. Ils peinent quand la tâche est ambiguë, implique de nombreuses étapes dépendantes, ou nécessite de maintenir un contexte sur une longue durée. La planification résout ces trois limites.

Les limites de l’approche monolithique

Demander à un LLM de résoudre une tâche complexe en un seul appel échoue pour plusieurs raisons :

Dépassement de la fenêtre de contexte : des instructions très détaillées avec tout le contexte nécessaire peuvent dépasser la capacité du modèle, même avec les fenêtres de 1M tokens disponibles sur Claude Opus 4.6 et Gemini 3.1 Pro.

Dégradation de l’attention : les recherches montrent une dégradation des performances des agents après environ 35 minutes de temps humain continu. Le modèle « oublie » progressivement ses instructions initiales (context drift).

Pas de correction possible : un appel unique ne permet pas d’itérer. Si l’étape 3 d’un plan en 8 étapes échoue, un plan décomposé permet de corriger et reprendre ; un appel monolithique repart de zéro.

Difficulté de debugging : si le résultat final est incorrect, un plan décomposé permet d’identifier exactement quelle sous-tâche a échoué. Un appel monolithique est une boîte noire.

La décomposition de tâches

La décomposition de tâches (task decomposition) est le cœur du planning agent. Elle transforme un objectif complexe en une séquence de sous-tâches atomiques, chacune réalisable par un appel LLM focalisé, un appel d’outil, ou une combinaison des deux.

Décomposition par le LLM

L’approche la plus courante : le LLM lui-même génère la décomposition. Vous lui soumettez l’objectif de haut niveau et il produit une liste ordonnée de sous-tâches.

En zero-shot, vous demandez simplement « décompose cette tâche en étapes ». En few-shot, vous fournissez des exemples de décompositions réussies dans le prompt. Le few-shot est significativement plus fiable car il calibre la granularité et le format attendus.

Les risques de la décomposition par LLM : le modèle peut produire des plans incomplets (étapes manquantes), des étapes trop abstraites (non directement exécutables), ou des plans incohérents (étapes dans le mauvais ordre, dépendances ignorées). L’ajout d’exemples et la validation systématique du plan réduisent ces risques.

Décomposition manuelle (codée)

Pour des tâches récurrentes et bien définies, vous pouvez coder la logique de décomposition. Un workflow « recherche et rédaction de rapport » se décompose toujours en : identifier les mots-clés → rechercher les sources → extraire les informations pertinentes → rédiger le plan → rédiger les sections → relire et corriger.

Cette approche est plus fiable mais moins flexible. Elle ne s’adapte pas à de nouvelles tâches sans modification du code.

Décomposition hiérarchique (HTN)

Les Hierarchical Task Networks (HTN) décomposent les tâches en arbre : l’objectif principal se divise en sous-objectifs, chaque sous-objectif en sous-sous-objectifs, jusqu’aux actions atomiques. C’est l’approche la plus puissante pour les tâches très complexes et multi-niveaux.

La recherche récente (AgentOrchestra, 2024) utilise des frameworks hiérarchiques multi-agents où un orchestrateur décompose la tâche de haut niveau et délègue les sous-tâches à des agents spécialisés (WebSurfer, Coder, FileSurfer).

Architectures de planning agents

Architecture Planner-Worker

L’architecture dominante en mars 2026 pour les agents longs est le pattern Planner-Worker :

Le Planner est un modèle frontier (Claude Opus 4.6, GPT-5.4) chargé du raisonnement de haut niveau : comprendre l’objectif, décomposer la tâche, créer la stratégie, et assurer le contrôle qualité.

Les Workers sont des modèles plus économiques (Haiku, Flash, GPT-4o-mini) qui exécutent les sous-tâches individuelles : écrire du code, faire une recherche web, appeler une API.

Cette séparation réduit les coûts d’environ 90% par rapport à l’utilisation du modèle frontier pour toutes les étapes. Le Planner ne consomme des tokens frontier que pour les décisions stratégiques ; les Workers consomment des tokens économiques pour l’exécution répétitive.

Agent Step-by-Step

L’agent décide de sa prochaine action à chaque étape en fonction de l’état actuel. Pas de plan préalable : l’agent observe, raisonne, agit, observe le résultat, et recommence. C’est le pattern ReAct.

Avantage : très adaptable aux environnements imprévisibles. L’agent s’ajuste en temps réel. Inconvénient : pas de vision globale, risque de tourner en rond ou de perdre de vue l’objectif initial.

Une étude récente (mars 2026) sur les agents web montre que les agents step-by-step s’alignent plus étroitement avec les trajectoires humaines de référence (38% de succès global) mais sont moins précis sur les actions individuelles que les agents avec plan complet.

Agent Full-Plan-in-Advance

L’agent formule un plan complet avant de commencer l’exécution. Il identifie toutes les étapes, leurs dépendances, et l’ordre d’exécution, puis suit le plan séquentiellement.

Avantage : cohérence globale et précision des actions individuelles (89% de précision sur les éléments ciblés dans les benchmarks WebArena). Inconvénient : le plan peut devenir obsolète si l’environnement change en cours d’exécution.

Pattern Plan-Execute (hybride)

Le pattern Plan-Execute combine les deux approches : l’agent formule un plan initial, commence l’exécution, et re-planifie quand une étape échoue ou que les conditions changent. C’est l’approche la plus robuste et celle implémentée par LangChain dans son PlanAndExecute agent.

Ce pattern est natif dans Claude Code et Codex : l’agent analyse l’issue GitHub, formule un plan de résolution, commence le coding, et ajuste son plan si les tests échouent ou si une difficulté imprévue apparaît.

Stratégies de planification

Chain-of-Thought (CoT)

Le chain-of-thought encourage le LLM à « penser étape par étape » avant de produire une réponse. C’est la forme la plus simple de planification : le modèle verbalise son raisonnement, ce qui améliore la qualité des décisions.

ReAct

Le pattern ReAct (Reasoning + Acting) alterne entre phases de raisonnement (« je dois d’abord chercher les informations sur… ») et phases d’action (appel d’outil). Chaque observation nourrit le raisonnement suivant. C’est le pattern de planification le plus utilisé dans les frameworks agents.

Réflexion

Les agents réflexifs ajoutent une boucle de retour : après une séquence d’actions, l’agent évalue ses résultats, identifie ses erreurs et ajuste son plan. Le framework Reflexion (2023) a montré que cette auto-correction linguistique améliore significativement les performances sans nécessiter de mise à jour des poids du modèle.

Test-time compute scaling

Une tendance de 2026 : augmenter le temps de calcul à l’inférence (plutôt que la taille du modèle) pour améliorer la planification. Les modèles « thinking » (Claude Opus 4.6 adaptive thinking, GPT-5.4 Thinking) dédient plus de tokens au raisonnement avant de produire une réponse. Le benchmark « Test-Time Scaling of General LLM Agents » (février 2026) confirme que cette approche améliore les performances agentiques.

Le planning agent en production

Agents long-horizon

La durée des tâches que les agents peuvent gérer de manière autonome double tous les 7 mois. En mars 2026, les agents gèrent des tâches de 2 heures de manière autonome. Les projections suggèrent des journées de travail complètes (8h) d’ici fin 2026. Cependant, doubler la durée d’une tâche quadruple le taux d’échec, ce qui rend la planification et la capacité de récupération d’autant plus critiques.

Checkpointing et reprise

Les agents longs doivent pouvoir sauvegarder leur état (checkpoint) et reprendre après une interruption. La technique recommandée par Anthropic : écrire des résumés d’état dans des fichiers (CLAUDE.md, task_state.md) que l’agent relit au début de chaque nouvelle session de contexte. Le système de fichiers sert de mémoire persistante entre les sessions.

Parallélisme

Quand des sous-tâches sont indépendantes, un planning agent efficace les exécute en parallèle plutôt que séquentiellement. Chercher des informations sur 3 entreprises concurrentes, par exemple, peut se faire en 3 appels simultanés. Le Planner identifie les dépendances et maximise la parallélisation.

Gestion du budget

Chaque étape du plan consomme des tokens et du temps. Un agent qui re-planifie trop souvent ou décompose trop finement gaspille des ressources en coordination. La bonne granularité est un compromis : décomposer suffisamment pour rendre les tâches tractables, mais pas tant que le coût de coordination domine le coût d’exécution.

Cas d’usage concrets

Développement logiciel autonome

Claude Code et Codex sont des planning agents spécialisés dans le code. Face à une issue GitHub (« le bouton de login ne fonctionne pas sur mobile »), l’agent : (1) lit le code pertinent, (2) identifie la cause probable, (3) formule un plan de correction, (4) implémente les changements, (5) exécute les tests, (6) corrige les régressions, (7) soumet une PR. Chaque étape est planifiée et peut être ajustée si les tests échouent.

Deep Research

Les fonctionnalités Deep Research de ChatGPT, Perplexity et Gemini sont des planning agents spécialisés dans la recherche. L’agent décompose la question en sous-questions, formule des requêtes de recherche, explore les sources, croise les informations, et produit un rapport structuré. La planification détermine l’ordre de recherche et la profondeur d’exploration.

Automatisation de bureau

Claude Cowork planifie et exécute des workflows multi-étapes sur votre bureau : « prends les données du rapport Q3, crée un graphique de tendance, insère-le dans la présentation PowerPoint, et envoie le fichier par email à l’équipe ». Chaque étape est une sous-tâche planifiée avec des dépendances explicites.

Frameworks de planning agents

LangChain PlanAndExecute : l’implémentation la plus accessible du pattern Plan-Execute. Le Planner génère un plan complet sous forme de liste d’étapes, l’Executor les exécute séquentiellement, et le système re-planifie si une étape échoue. Configuration en quelques dizaines de lignes de Python.

AutoGen (Microsoft) : framework multi-agents où un orchestrateur (GroupChatManager) coordonne des agents spécialisés. La planification est distribuée : l’orchestrateur décompose la tâche et assigne les sous-tâches aux agents les plus compétents. Magentic-One, construit sur AutoGen, utilise un hub-and-spoke avec quatre agents spécialisés (WebSurfer, Coder, ComputerTerminal, FileSurfer).

CrewAI : framework orienté « équipes d’agents » où chaque agent a un rôle, un objectif et un ensemble d’outils. Le Crew (équipe) reçoit une tâche globale et la planification est gérée par le manager agent qui délègue les sous-tâches aux agents appropriés. Plus simple qu’AutoGen pour les cas d’usage courants.

LlamaIndex Workflows : approche basée sur des événements plutôt que des appels séquentiels. Les agents réagissent à des événements (résultat disponible, erreur, nouvelle information) et le flux est déterminé par la structure du workflow. Plus adapté aux pipelines de données et à l’intégration avec des sources documentaires.

Évaluer un planning agent

Mesurer la performance d’un planning agent va au-delà du simple taux de succès. Les métriques clés incluent :

Taux de réussite de la tâche : l’objectif final est-il atteint ? C’est la métrique la plus importante mais la plus grossière.

Efficacité du plan : combien d’étapes ont été nécessaires par rapport au minimum théorique ? Un agent qui résout une tâche en 5 étapes là où 3 suffiraient est moins efficient.

Qualité de la trajectoire : les étapes individuelles sont-elles correctes et pertinentes ? Un papier de mars 2026 propose cinq métriques de qualité de trajectoire pour les agents web, allant au-delà du simple succès/échec.

Coût total : tokens consommés, temps écoulé, nombre d’appels API. Un agent qui réussit à 100$ n’est pas forcément meilleur qu’un agent qui réussit à 2$.

Robustesse : l’agent produit-il des plans cohérents à chaque exécution, ou les résultats varient-ils fortement d’une exécution à l’autre ?

Les benchmarks de référence incluent SWE-bench (résolution de bugs logiciels réels), WebArena (tâches web complexes), et les évaluations de l’agent benchmark qui mesurent la planification, l’utilisation d’outils et la fiabilité de bout en bout.

Limites actuelles

Incohérence des plans : le LLM peut générer des plans avec des étapes contradictoires ou des dépendances impossibles, surtout pour les tâches très complexes ou les domaines peu familiers.

Surplanification : certains agents passent plus de temps à planifier qu’à exécuter. Le coût de la planification doit rester proportionnel à la complexité de la tâche.

Plans obsolètes : dans un environnement dynamique (web, système en temps réel), un plan formulé il y a 10 minutes peut être invalide. La re-planification conditionnelle est nécessaire.

Évaluation difficile : mesurer la qualité d’un plan est intrinsèquement subjectif. Les benchmarks existants (WebArena, SWE-bench, BIRD-SQL) mesurent le résultat final, pas la qualité du plan lui-même. Les métriques de qualité de trajectoire (mars 2026) commencent à combler cette lacune.