Module 5 — Planification et décomposition des tâches

La boucle ReAct du module 2 est réactive : à chaque tour, le modèle choisit l'action qui suit celle qu'il vient de faire. Sur une tâche courte, ce comportement suffit. Dès qu'un objectif dépasse cinq ou six étapes, la myopie du modèle se voit : il oublie qu'il fallait aussi comparer les prix, il relit deux fois la même page, il termine avant d'avoir couvert tous les concurrents. Ce module ajoute une phase de planification explicite, avec ses gains et son prix.

Plan puis exécution

Le patron « plan puis exécution » (parfois nommé Plan-and-Execute dans la littérature anglophone) sépare la boucle en deux temps. D'abord, un appel dédié rédige un plan lisible en cinq à huit étapes. Ensuite, la boucle ReAct exécute chaque étape, l'une après l'autre, en gardant la vue d'ensemble comme repère.

Sur le fil rouge, une question comme « quels concurrents ont ajouté un tableau Kanban en 2025, avec quelle intégration Slack ? » donne le plan suivant :

1. Lister trois a cinq concurrents connus dans la meme categorie.
2. Chercher la roadmap 2025 de chacun (mots-cles Kanban).
3. Pour chaque concurrent avec Kanban, verifier l'integration Slack
   sur la page de connecteurs.
4. Croiser les informations avec un article comparatif tiers.
5. Rediger une note synthetique avec chaque source citee.

L'exécution reprend ensuite ce plan dans une nouvelle boucle. À chaque itération, la pensée du modèle commence par « étape 2 du plan » ou « étape 4 du plan », ce qui rend la trace plus lisible et l'écart au plan visible.

Le prix d'un plan

La planification ajoute un appel initial et une petite instabilité — le modèle qui replanifie mal peut casser une tâche que la boucle réactive résolvait. Sur nos évaluations du module 10, l'ajout de la planification coûte en moyenne 3 800 jetons supplémentaires par question, soit 15 % de plus que la version réactive. En contrepartie, le taux de bonnes réponses passe de 62 % à 78 % sur les questions à cinq étapes ou plus. Sur les questions courtes, en revanche, la planification est neutre voire négative : le plan invente des étapes inutiles.

D'où la règle appliquée dans le fil rouge : un plan seulement si la question est complexe. Un petit classifieur en amont — ou un appel court au modèle avec la consigne « cette question exige-t-elle une décomposition en plus de trois étapes ? » — décide s'il faut planifier ou passer directement à la boucle ReAct.

Replanification en cours de route

Un plan écrit avant que l'agent connaisse le terrain vieillit vite. À l'étape 3, le modèle découvre un concurrent qui n'était pas dans la liste initiale. À l'étape 5, deux sources se contredisent et il faut aller en chercher une troisième. Le plan doit alors être révisé, pas ignoré.

La règle qui marche : après chaque observation, l'agent se pose deux questions internes — « le plan est-il toujours valable ? » et « manque-t-il une étape ? ». Si oui, il appelle un outil revisor_plan qui prend l'état courant et renvoie un plan mis à jour. On limite la replanification à trois révisions maximum, faute de quoi l'agent passe son temps à replanifier au lieu d'exécuter.

def peut_on_replanifier(historique_plans):
    return len(historique_plans) < 3

def revisor_plan(plan_actuel, faits_recueillis, obstacle):
    return client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "Tu revises un plan d'agent."},
            {"role": "user",   "content": (
                f"Plan actuel :\n{plan_actuel}\n\n"
                f"Faits recueillis :\n{faits_recueillis}\n\n"
                f"Obstacle rencontre :\n{obstacle}\n\n"
                "Renvoie le plan revise en gardant les etapes deja faites."
            )},
        ],
        temperature=0.2,
    ).choices[0].message.content

Le point clé, souvent oublié : conserver l'historique des plans. Sans lui, l'agent revient à une étape qu'il vient d'écarter, ce qui produit l'oscillation du module 8.

Sous-agents et décomposition profonde

Sur des tâches plus lourdes, la décomposition peut passer d'un plan à une hiérarchie d'agents. Un agent superviseur écrit le plan, puis délègue chaque étape à un agent spécialisé — un pour la recherche web, un pour la lecture d'URL, un pour la rédaction. Chaque sous-agent a un contexte propre, ses propres outils, sa propre limite d'itérations.

L'intérêt : la mémoire de travail de chaque sous-agent reste courte, ce qui limite les dérives du module 4. L'inconvénient : les appels se multiplient, la latence enfle, les échecs sont plus difficiles à localiser. On observe empiriquement qu'au-delà de trois niveaux de hiérarchie, la fiabilité globale se dégrade : chaque niveau ajoute son taux d'erreur, qui se multiplie. Un agent racine avec deux sous-agents suffit dans la plupart des cas.

Quand la planification n'aide pas

Trois situations où la planification est un piège.

La tâche est ouverte au point qu'aucun plan pertinent n'est écrivable a priori. « Cherche des idées de fonctionnalités » ne se planifie pas ; il vaut mieux laisser la boucle réactive explorer. Un plan produit des étapes plausibles mais superficielles.

Les outils sont peu fiables. Si chercher_web échoue une fois sur trois, un plan précis à cinq étapes casse dès la première panne. Il faut d'abord fiabiliser les outils, ou passer à un plan très souple.

Le coût du plan dépasse celui de l'exécution. Sur une tâche à deux étapes, écrire un plan de deux étapes coûte plus cher que de simplement les faire. La règle « décomposition seulement si plus de trois étapes » évite ce piège.

En résumé

• Le patron plan puis exécution aide sur les tâches complexes, coûte cher sur les tâches courtes ; conditionner par la complexité.
• La replanification est nécessaire mais bornée à trois révisions, avec conservation de l'historique pour éviter l'oscillation.
• Les sous-agents limitent la mémoire de chacun mais font enfler la latence ; deux niveaux suffisent.
• Un plan n'améliore rien sur les tâches ouvertes, avec des outils fragiles, ou plus courts que le plan lui-même.

Module suivant : l'autocritique — faire relire son propre travail par un vérificateur, et les limites de cet exercice.