Planification et décomposition de tâches

Le plan comme contrat entre l'utilisateur et l'agent

Un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire qui exécute une tâche complexe sans plan explicite prend, à chaque tour, une décision locale sans engagement sur la suite. Cela fonctionne tant que la tâche tient dans une ou deux actions. Dès qu'elle exige plusieurs étapes interdépendantes, l'absence de plan devient le principal facteur d'échec silencieux : le modèle contredit à l'étape quatre une hypothèse posée à l'étape deux, sans qu'aucun mécanisme ne le détecte avant la fin du parcours.

Ce chapitre traite la planification comme un artefact d'ingénierie à part entière — quelque chose que l'on produit, que l'on valide, que l'on borne en coût, et que l'on révise selon des règles explicites plutôt qu'à la discrétion du modèle. Les notions de replanification et de budget qui suivent ne sont pas des raffinements optionnels : sans elles, un agent de planification en production finit tôt ou tard par boucler ou par dépasser silencieusement son coût prévu.

Pourquoi planifier plutôt que réagir pas à pas

Le mode réactif — proche du patron ReAct — consiste à observer l'état courant, choisir une action, observer le résultat, recommencer. Il suffit pour des tâches courtes à faible profondeur, où chaque décision ne dépend que du contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire immédiat. Il devient fragile dès que la tâche exige plusieurs étapes interdépendantes : réserver un vol suppose de connaître des dates avant de comparer des prix, qui eux-mêmes conditionnent le choix de l'hôtel. Sans représentation explicite de cette structure, le modèle improvise à chaque tour, avec un risque élevéhaut risqueConformitéCatégorie de l'AI Act regroupant les usages soumis à conditions strictes : recrutement, crédit, éducation, infrastructures critiques. Elle impose documentation, examen des biais et contrôle humain effectif.Voir dans le glossaire de contredire une décision prise trois tours plus tôt.

Planifier consiste à faire produire — par le modèle lui-même ou par un composant dédié — une décomposition de l'objectif en sous-tâches ordonnées, avant ou pendant l'exécution. Le plan devient un artefact que l'on peut inspecter, valider, modifier et reprendre après une interruption. C'est aussi la seule façon réaliste de maîtriser un budget : sans plan, il est impossible d'estimer a priori le nombre d'appels outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire nécessaires, et donc le coût.

Un plan cohérent en apparence peut reposer sur des prémisses fausses — un outil qui n'existe pas, une donnée périmée, une contrainte oubliée. Planifier réduit le risque d'incohérence entre étapes, mais ne dispense jamais de vérifier les résultats intermédiaires produits par chaque étape.

Anatomie d'un plan

Un plan utilisable en production comporte généralement cinq éléments :

• Un objectif formulé de façon vérifiable — « publier un article de 800 mots optimisé pour la requête X » plutôt que « améliorer le SEO du site ».
• Une liste de sous-tâches, avec pour chacune l'outil ou la capacité mobilisée.
• Des dépendances entre sous-tâches : séquentielles, parallèles, ou conditionnelles à un résultat précédent.
• Des critères de succès par étape, permettant de détecter un échec localisé sans attendre la fin du parcours.
• Un budget alloué : nombre d'appels, jetons, durée maximale.

La forme la plus simple est une liste numérotée que le modèle génère en un tour dédié, avant d'entrer en phase d'exécution. Des architectures plus élaborées maintiennent le plan comme une structure de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire vivante — un graphe de tâches mis à jour à chaque observation, plutôt qu'un texte figé relufonction d'activationIAOpération non linéaire appliquée en sortie d'un neurone. Sans elle, empiler des couches serait inutile : une succession d'opérations linéaires reste équivalente à une seule.Voir dans le glossaire à chaque tour.

Représenter le plan : liste, graphe ou arbre

Le choix de représentation conditionne directement ce que l'agent peut faire avec son plan.

Liste séquentielle. La représentation la plus simple : une suite ordonnée d'étapes, exécutées l'une après l'autre. Facile à générer, facile à auditer, mais elle interdit le parallélisme et représente mal les dépendances conditionnelles — une étape « si le stock est disponible, alors... sinon... » s'exprime mal dans une liste plate.

Graphe de dépendances. Chaque sous-tâche devient un nœud, relié aux sous-tâches dont elle dépend. Cette représentation autorise l'exécution parallèle des branches indépendantes — utile quand plusieurs sources de données doivent être interrogées séparément avant une étape de synthèse commune — et rend explicite ce qui bloque quoi. Le coût est une complexité d'implémentation plus élevée : il faut un ordonnanceur, pas seulement un curseur qui avance dans une liste.

Arbre de recherche (planification par exploration). Utilisé quand plusieurs stratégies concurrentes sont plausibles et qu'aucune n'est manifestement meilleure a priori — l'agent explore plusieurs branches de plan, les évalue partiellement, et retient la plus prometteuse. C'est le principe derrière les approches de type Tree of Thoughts appliquées à la planification d'agent. Le coût en jetons croît avec le facteur de branchement, ce qui impose presque toujours un budget dédié par branche, distinct du budget global — sans quoi une seule branche exploratoire peut épuiser le budget avant qu'aucune décision ne soit prise.

La grande majorité des agents en production n'ont pas besoin d'un graphe de dépendances ni d'un arbre de recherche. Une liste séquentielle avec points de contrôle après chaque étape couvre la plupart des cas d'usage métier. Réserver les représentations plus riches aux tâches où le parallélisme ou l'incertitude de stratégie sont démontrés par l'usage réel, pas anticipés par précaution.

Stratégies de décomposition

Trois familles de stratégies dominent les architectures d'agents actuelles.

Décomposition ascendante implicite (ReAct). Le modèle raisonne et agit tour par tour sans plan préalable formalisé — chaque étape émerge du contexte accumulé au fil des observations. Économique en jetons de planification, mais sujette à la dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire : rien n'empêche le modèle de boucler ou de perdre de vue l'objectif initial sur une tâche longue, faute de point de référence explicite auquel se recomparer.

Plan-and-Execute. Un tour de planification produit une liste de sous-tâches figée, ensuite exécutée séquentiellement par un exécutant — le même modèle, ou un modèle plus petit et moins coûteux dédié à l'exécution. Cette séparation des rôles limite le nombre d'allers-retours de planification et facilite l'audit du plan avant tout appel outil réel. Sa faiblesse : un plan figé s'adapte mal si une étape révèle une information qui invalide les suivantes.

Décomposition hiérarchique avec replanification. Le plan initial ne descend qu'à un niveau de granularité grossier ; chaque sous-tâche complexe est décomposée à son tour, au moment de son exécution. Combinée à une boucle de replanification, cette approche tolère mieux l'incertitude de l'environnement, au prix d'une consommation de jetons plus élevée et d'une architecture plus complexe à instrumenter et à déboguer.

Pour la majorité des cas d'usage en production, une planification Plan-and-Execute à deux niveaux — un plan global, puis une exécution outil par outil — offre le meilleur rapport entre contrôlabilité et coût. Réserver la décomposition hiérarchique complète aux tâches où l'imprévisibilité de l'environnement est démontrée par des données réelles, pas supposée par prudence excessive.

La boucle de replanification

Aucun plan ne survit intact à l'exécution réelle. Un outil renvoie une erreur, une donnée attendue est absente, une contrainte inconnue au moment de la planification apparaît en cours de route. La boucle de replanification introduit un point de décision après chaque étape : le résultat observé est-il conforme au critère de succès défini pour cette sous-tâche ? Si oui, l'exécution continue sur l'étape suivante du plan sans intervention supplémentaire. Si non, trois issues sont possibles : corriger l'étape en cours avec des paramètres ajustés, réviser le plan à partir de ce point en conservant l'objectif global, ou abandonner la branche et remonter au niveau supérieur pour reconsidérer l'objectif lui-même.

Chaque décision de replanification consomme du budget. Une politique de replanification sans limite converge souvent vers une boucle : le modèle retente indéfiniment une variante de la même action échouée, en particulier si le message d'erreur retourné par l'outil est ambigu ou ressemble à un problème transitoire — un délai réseau, une limite de débit — alors qu'il s'agit en réalité d'une erreur structurelle qui ne se résoudra pas par une nouvelle tentative.

Un agent qui replanifie sans compteur dédié peut consommer un budget de jetons bien supérieur à celui du plan initial, sans qu'aucune limite globale ne le signale avant l'épuisement complet du quota. Toujours plafonner le nombre de replanifications par sous-tâche, indépendamment du budget global du parcours.

Budgets : jetons, appels, temps, profondeur

Un agent de planification sans budget explicite est un système sans garde-fou. Quatre dimensions doivent être bornées indépendamment, car elles ne se substituent pas l'une à l'autre :

• Budget de jetons — la somme des jetons d'entrée et de sortie consommés sur l'ensemble du parcours, planification et replanifications comprises. C'est la métrique la plus directement liée au coût facturé par appel d'API.
• Budget d'appels outils — un plafond sur le nombre d'invocations, indépendant du coût en jetons ; un outil de recherche web peut être négligeable en jetons mais coûteux en latence ou en appels API tiers facturés séparément.
• Budget de temps (wall-clock) — déterminant dans un contexte interactif ; un plan techniquement correct qui prend quinze minutes n'est pas acceptable si l'utilisateur attend une réponse en ligne.
• Budget de profondeur de replanification — le nombre de fois qu'une même sous-tâche peut être retentée avant d'être escaladée vers une intervention humaine ou une réponse d'échec explicite.

La pratique la plus robuste consiste à décomposer le budget global en sous-budgets alloués par sous-tâche au moment de la planification, plutôt que de laisser toutes les étapes puiser dans un pot commun. Une sous-tâche qui dépasse son enveloppe déclenche une escalade — replanification au niveau supérieur, ou retour explicite à l'utilisateur — sans consommer le budget réservé aux sous-tâches suivantes.

Objectif : produire une synthèse comparant cinq concurrents sur leurs grilles tarifaires. Plan : cinq sous-tâches de collecte, une par concurrent, chacune bornée à quatre appels outils et trois mille jetons ; puis une sous-tâche de synthèse bornée à deux mille jetons, sans appel outil. Si la collecte pour un concurrent échoue après ses quatre appels, l'agent marque cette sous-tâche comme partielle et passe à la synthèse avec les données disponibles, plutôt que de puiser dans le budget des autres sous-tâches pour compenser l'échec.

Un budget trop serré produit des plans tronqués qui se présentent comme complets — le modèle ne signale pas toujours explicitement qu'il a dû raccourcir sa recherche pour tenir le quota. Prévoir un statut explicite par sous-tâche — complet, partiel, échoué — et le propager jusqu'à la réponse finale limite ce risque d'illusion de complétude.

Pièges fréquents

Sur-décomposition. Découper une tâche simple en dix sous-tâches microscopiques multiplie les points de défaillance et le coût de planification sans bénéfice proportionnel. Un signe révélateur : des sous-tâches sans critère de succès distinct de la sous-tâche suivante — elles n'existent que parce que le modèle a numéroté chaque phrase de son raisonnement comme une étape.

Sous-décomposition. À l'inverse, confier une sous-tâche trop large à un seul appel d'outil masque les échecs partiels : l'agent ne sait pas si la moitié du travail a réussi et l'autre non, il reçoit un succès ou un échec binaire sur un périmètre trop large pour être exploitable ou corrigé finement.

Dérive de plan (plan drift). Après plusieurs replanifications successives, le plan réellement exécuté n'a plus grand-chose à voir avec l'objectif initial formulé par l'utilisateur. Chaque révision individuelle semblait raisonnable au moment où elle a été prise, mais leur accumulation a fait dévier la trajectoire. Recomparer périodiquement le plan courant à l'objectif d'origine — pas seulement à l'état du tour précédent — limite ce phénomène.

Plans fantômes. Le modèle produit un plan plausible et bien formaté, mais qui mobilise des outils qui n'existent pas réellement dans le contexte d'exécution — il planifie avec les capacités qu'il imagine, pas celles qui sont effectivement déclarées. Valider chaque étape du plan contre la liste réelle des outils disponibles avant de lancer l'exécution évite de découvrir le problème à mi-parcours, une fois du budget déjà consommé.

Boucle de replanification silencieuse. Sans compteur dédié, un échec répété d'une même sous-tâche peut donner l'impression de progresser — le plan « avance » d'un tour à l'autre dans le journal — alors que la même action légèrement reformulée est retentée indéfiniment sans jamais changer de nature.

Checklist de mise en production

• Chaque sous-tâche dispose d'un critère de succès vérifiable, distinct d'un simple « l'outil a répondu sans erreur ».
• Le budget global est décomposé en sous-budgets par sous-tâche, avec un mécanisme d'escalade explicite en cas de dépassement.
• Un plafond de replanification par sous-tâche est défini et journalisé, indépendamment du budget global de jetons.
• Le plan est validé contre la liste réelle des outils disponibles avant le lancement de l'exécution.
• Le statut de chaque sous-tâche — complet, partiel, échoué — est propagé jusqu'à la réponse finale, pas seulement conservé dans le journal interne.
• Une comparaison périodique entre le plan courant et l'objectif initial est intégrée à la boucle de replanification, pas seulement une comparaison au tour précédent.
• Les échecs répétés au-delà du plafond déclenchent une réponse explicite d'échec ou une escalade humaine, jamais un silence ni une réponse partielle présentée comme complète.

Ce dernier point mérite d'être isolé : un agent qui échoue silencieusement — en renvoyant une réponse partielle présentée comme complète — est plus dangereux en production qu'un agent qui échoue bruyamment. Le coût d'un échec visible est une frustration ponctuelle, résolue par une nouvelle tentative ou une intervention ciblée. Le coût d'un échec invisible est une décision prise en aval sur une base fausse, découverte bien plus tard, à un moment où la corriger coûte largement plus cher que ne l'aurait coûté un budget de replanification correctement dimensionné dès la conception du plan.