Décomposition de Tâches (Task Decomposition)

La décomposition de tâches (task decomposition) est le processus par lequel un agent IA divise un objectif complexe en une série de sous-tâches plus simples et exécutables, chacune pouvant être résolue par un appel au LLM, un appel d’outil ou une combinaison des deux.

Catégorie: Technique de planning pour agents IA
Aussi appelé: Task breakdown, décomposition de tâches, goal decomposition, subtasking
Techniques: Zero-shot prompting, few-shot prompting, décomposition récursive, décomposition programmatique, HTN (Hierarchical Task Networks)
Représentations: Séquence linéaire, DAG (graphe acyclique dirigé), arbre hiérarchique
Frameworks: LangChain, LangGraph, CrewAI, AutoGen, MetaGPT, BabyAGI
Verdict: Fondation de tout agent IA performant. Sans décomposition, un LLM ne peut pas résoudre des problèmes complexes de manière fiable

Pourquoi décomposer ?

Quand vous demandez à un LLM de « refactoriser cette codebase en TypeScript », de « planifier une conférence d’une semaine » ou de « créer un site web personnalisé », vous lui soumettez un objectif trop large pour être traité en une seule passe. L’échec est quasi garanti si le modèle tente tout d’un bloc. Quatre raisons fondamentales imposent la décomposition :

Limites de contexte : un objectif complexe avec toutes ses instructions, données et contraintes peut dépasser la fenêtre de contexte du modèle, ou au minimum saturer sa capacité d’attention effective. Même les modèles à 1M tokens de contexte (context window) montrent une dégradation sévère des performances bien avant cette limite.

Complexité du raisonnement : les LLM performent nettement mieux sur des problèmes petits et bien définis que sur des scénarios multi-étapes intriqués. Décomposer transforme un problème difficile en N problèmes faciles.

Spécificité des outils : les outils sont conçus pour des fonctions précises (recherche web, exécution de code, requête SQL). La décomposition permet de mapper chaque sous-tâche à l’outil approprié via le tool use.

Récupération d’erreur : si une sous-tâche échoue, on peut isoler l’échec, replanifier et retenter uniquement cette partie au lieu de recommencer l’ensemble. C’est un avantage structurel majeur en production.

Techniques de décomposition

Décomposition par le LLM (zero-shot)

L’approche la plus directe : on demande simplement au LLM de décomposer l’objectif en étapes.

Prompt : "Décompose l'objectif suivant en sous-tâches exécutables :
Objectif : Créer un rapport comparatif des trois meilleurs CRM pour PME."

Réponse LLM :
1. Rechercher les CRM les plus populaires pour PME
2. Identifier les 3 CRM les mieux notés
3. Pour chaque CRM : collecter les fonctionnalités clés, le prix, les avis
4. Créer un tableau comparatif structuré
5. Rédiger une analyse avec verdict et recommandation
6. Mettre en forme le rapport final

Points forts : flexible, s’adapte à tout domaine, aucune configuration nécessaire. Points faibles : inconsistant (le même prompt peut produire des plans différents à chaque exécution), étapes parfois trop vagues ou mal ordonnées.

Décomposition par le LLM (few-shot)

On fournit des exemples de décompositions réussies dans le prompt. Le LLM imite le format, la granularité et la logique des exemples fournis. Plus robuste que le zero-shot, mais consomme plus de tokens de contexte. C’est l’approche recommandée quand vous avez un type de tâche récurrent et que vous connaissez la structure idéale de décomposition.

Décomposition récursive

Le LLM décompose l’objectif en sous-objectifs, puis chaque sous-objectif est évalué : est-il assez simple pour être exécuté directement ? Si non, il est décomposé à son tour. Le processus se répète jusqu’à atteindre des actions atomiques.

class TaskDecomposer:
    def __init__(self, client, max_depth=3):
        self.client = client
        self.max_depth = max_depth

    def decompose(self, task, depth=0):
        if depth >= self.max_depth:
            return [task]  # Arrêt de la récursion
        
        if not self._should_decompose(task):
            return [task]  # Tâche atomique
        
        subtasks = self._generate_subtasks(task)
        result = []
        for st in subtasks:
            result.extend(self.decompose(st, depth + 1))
        return result

    def _should_decompose(self, task):
        """Le LLM décide si la tâche doit être décomposée."""
        prompt = f"""Tâche : {task}
        Cette tâche doit-elle être décomposée si :
        - Elle implique plusieurs opérations distinctes
        - Elle touche plusieurs fichiers ou composants
        - Elle bénéficierait de points de validation
        Répondez par JSON : {{"decompose": true/false}}"""
        response = self.client.chat.completions.create(...)
        return json.loads(response)["decompose"]

Le framework TDAG (Dynamic Task Decomposition and Agent Generation, mai 2025) formalise cette approche en créant dynamiquement un sous-agent spécialisé pour chaque sous-tâche, avec une « skill library » évolutive qui s’enrichit au fil des exécutions.

Décomposition programmatique

Pour les tâches récurrentes et bien définies, on code explicitement la logique de décomposition au lieu de la confier au LLM. Par exemple, une tâche « recherche et rapport » sera toujours décomposée en : extraction de mots-clés, recherche, collecte de données, analyse, rédaction, mise en forme.

Points forts : déterministe, reproductible, rapide (pas d’appel LLM pour la décomposition elle-même). Points faibles : rigide, ne s’adapte pas aux cas imprévus sans modification du code.

Décomposition hiérarchique (HTN)

Inspirée des Hierarchical Task Networks de la planification classique, cette approche définit une hiérarchie de tâches abstraites qui se décomposent en tâches concrètes selon des règles prédéfinies. C’est un compromis entre la flexibilité du LLM et la rigueur du code : la structure est fixe, mais le LLM remplit les détails.

Le framework UniDebugger (novembre 2025) illustre cette approche avec trois niveaux d’escalade pour le debugging logiciel : le niveau 1 utilise deux agents (Locator, Fixer) pour les bugs simples ; si ça échoue, le niveau 2 ajoute Slicer et Summarizer ; le niveau 3 active les sept agents spécialisés pour les bugs complexes. La décomposition elle-même est une forme de hiérarchie adaptative.

Représenter le plan décomposé

Une fois la tâche décomposée, les sous-tâches doivent être structurées de manière exploitable par l’agent. Le choix de la représentation impacte directement la capacité de l’agent à exécuter, paralléliser et récupérer des erreurs.

Représentation	Structure	Parallélisme	Usage idéal
Séquence linéaire	Liste ordonnée : tâche 1 → tâche 2 → tâche 3	Non	Processus simples et strictement ordonnés
DAG (graphe acyclique dirigé)	Nœuds = sous-tâches, arêtes = dépendances. Les tâches sans dépendance entre elles peuvent s’exécuter en parallèle	Oui	Workflows complexes avec des tâches partiellement indépendantes
Arbre hiérarchique	Structure récursive où chaque nœud se décompose en enfants	Possible (entre branches)	Décomposition multi-niveaux, abstraction progressive

Le DAG est la représentation la plus puissante pour les agents en production. Il capture explicitement les dépendances (« la tâche C nécessite les résultats de A et B ») tout en permettant d’identifier les tâches qui peuvent être exécutées en parallèle via des parallel tool calls. Les frameworks avancés comme celui proposé par les chercheurs en systèmes agentiques (2024) génèrent automatiquement des « task graphs » à partir de l’objectif utilisateur, avec un Orchestrator qui planifie et un Executor qui optimise l’exécution séquentielle et parallèle.

Lien avec Chain-of-Thought et Tree of Thoughts

La décomposition de tâches est intimement liée aux techniques de raisonnement séquentiel :

Chain-of-Thought (CoT) : c’est une décomposition implicite du raisonnement. Quand le modèle « réfléchit étape par étape », il décompose le problème en sous-problèmes résolus séquentiellement. C’est du single-path reasoning : une seule chaîne de pensée.

Tree of Thoughts (ToT) : c’est du multi-path reasoning. Le modèle génère plusieurs chemins de décomposition, évalue chaque branche et sélectionne la meilleure. Plus coûteux, mais plus robuste pour les problèmes avec des pièges logiques.

La distinction clé : CoT et ToT décomposent le raisonnement. La task decomposition décompose l’action. Dans un agent, les deux se combinent : le CoT/ToT guide le raisonnement sur « comment décomposer », et la task decomposition produit le plan d’action concret.

Décomposition et économies de coût

Un bénéfice sous-estimé de la décomposition : elle permet d’utiliser des modèles plus petits et moins coûteux pour chaque sous-tâche au lieu d’un seul gros modèle pour tout.

Amazon a publié une étude (AWS, 2025) montrant comment la décomposition d’une tâche de génération de site web personnalisé en trois sous-tâches (personnalisation, création visuelle, construction du site) permet d’utiliser des LLM spécialisés et plus petits pour chaque rôle au lieu d’un modèle frontier pour l’ensemble. La réduction de coût atteint 70 à 90 % en passant à la taille de modèle inférieure pour chaque sous-tâche, sans sacrifier la qualité du résultat final.

Le principe est simple : une sous-tâche bien définie (« génère un titre accrocheur pour cette page ») ne nécessite pas un modèle à 400 milliards de paramètres. Un modèle plus léger suffit, et le résultat est souvent aussi bon parce que le problème est plus simple.

Pattern « modèle par sous-tâche » En production, routez chaque sous-tâche vers le modèle le plus adapté. Raisonnement complexe → Claude Opus 4.6 ou o3. Génération de texte simple → Haiku 4.5 ou GPT-4o. Extraction de données → Gemini 3 Flash. La décomposition est ce qui rend ce routing possible.

Décomposition dans les agents de code

C’est dans le développement logiciel que la décomposition a le plus mûri. Les agents de code modernes (Claude Code, Codex CLI, Cursor) utilisent des stratégies de décomposition sophistiquées :

Types de sous-tâches

Un decomposer pour agents de code catégorise typiquement les sous-tâches en types standardisés :

Type	Description	Exemple
`analysis`	Comprendre du code, des exigences ou des données	« Analyser la structure du module auth »
`code_edit`	Modifier du code existant	« Ajouter la validation d’email dans le formulaire »
`file_create`	Créer de nouveaux fichiers	« Créer le composant UserProfile.tsx »
`test`	Écrire ou exécuter des tests	« Ajouter des tests unitaires pour le service de paiement »
`refactor`	Restructurer sans changer le comportement	« Extraire la logique de validation dans un helper »
`configuration`	Modifier des fichiers de config	« Mettre à jour le tsconfig.json pour le strict mode »

Ce typage permet à l’agent de sélectionner la stratégie d’exécution appropriée pour chaque sous-tâche et de valider que le résultat correspond au type attendu.

Escalade adaptative

Le framework UniDebugger (novembre 2025) illustre une décomposition adaptative pour le debugging : au lieu de décomposer une fois pour toutes, le niveau de décomposition s’ajuste dynamiquement à la difficulté. Un bug simple (typo, variable mal nommée) est traité directement. Un bug complexe (race condition, fuite mémoire) déclenche une décomposition plus fine avec des agents spécialisés.

Prompt plans pour le coding IA

Une pratique populaire dans les workflows de coding IA (popularisée par des développeurs comme Addy Osmani) consiste à générer un « prompt plan » : un fichier structuré contenant la séquence de prompts correspondant à chaque sous-tâche. L’IDE exécute chaque prompt séquentiellement, vérifie le résultat, puis passe au suivant. Cette approche « petites boucles itératives » réduit considérablement le risque d’erreurs catastrophiques.

Décomposition et systèmes multi-agents

La décomposition est le mécanisme naturel pour distribuer le travail dans un système multi-agents. Chaque sous-tâche est assignée à un agent spécialisé :

MetaGPT (2023) : décompose le développement logiciel en rôles (Product Manager, Architect, Engineer, QA) et assigne chaque phase à l’agent correspondant.

CrewAI : modélise les agents comme des membres d’équipe avec des rôles (Researcher, Writer, Reviewer) et décompose la tâche en fonction de ces rôles.

MAAD (2025) : un système multi-agents pour la conception d’architecture logicielle qui décompose les spécifications fonctionnelles en artefacts architecturaux, chaque artefact étant produit par un agent dédié.

Le pattern commun : la décomposition crée la structure du travail, et l’orchestration multi-agents l’exécute. Sans décomposition, pas de distribution. Sans distribution, le modèle unique devient le goulot d’étranglement.

Limites et pièges

Le dilemme de la granularité

Trop grossier : les sous-tâches restent trop complexes pour être exécutées de manière fiable. « Gérer la logistique » n’est pas une action exécutable.

Trop fin : le plan devient interminable, dépasse la fenêtre de contexte, et le coût de coordination entre sous-tâches annule les bénéfices. « Ouvrir le navigateur, taper l’URL, cliquer sur le champ, saisir le texte… » multiplie les points de défaillance.

La bonne granularité : chaque sous-tâche doit être exécutable en un seul appel d’outil ou un seul appel LLM focalisé. C’est la règle empirique la plus fiable.

Perte de cohérence entre sous-tâches

Quand chaque sous-tâche est traitée indépendamment, le résultat global peut manquer de cohérence. Le ton d’un rapport peut varier entre sections, la logique d’un code peut être incohérente entre modules. La décomposition doit s’accompagner de mécanismes de cohérence : contexte partagé, revue globale, contraintes cross-tâches.

Ne pas sur-optimiser la décomposition Amazon prévient dans ses recherches qu’une décomposition trop agressive peut sacrifier la richesse contextuelle que le LLM apporte naturellement quand il traite le problème dans son ensemble. Parfois, les relations cachées entre sous-problèmes ne sont visibles que dans le contexte complet. C’est un compromis à évaluer au cas par cas.

Inconsistance de la décomposition LLM

Un même objectif soumis deux fois au même LLM peut produire deux décompositions différentes (nombre de sous-tâches, ordre, granularité). Pour les applications en production, combinez la décomposition LLM avec des contraintes programmatiques : types de sous-tâches autorisés, profondeur maximale, validation structurelle du plan généré.

Gestion des dépendances

Identifier correctement les dépendances entre sous-tâches est critique. Si le LLM omet une dépendance (la sous-tâche C utilise un résultat de B, mais B n’est pas marquée comme prérequis), l’exécution parallèle provoquera une erreur. La représentation en DAG force l’explicitation des dépendances et permet de les valider avant l’exécution.

Bonnes pratiques

Valider la décomposition avant l’exécution

Ne lancez pas directement l’exécution du plan. Vérifiez d’abord : toutes les sous-tâches sont-elles exécutables avec les outils disponibles ? Les dépendances sont-elles correctes ? Le plan couvre-t-il l’objectif complet ? Un second appel LLM en mode « reviewer » peut faire cette validation à moindre coût.

Décomposer itérativement, pas monolithiquement

Au lieu de décomposer tout l’objectif d’un coup, décomposez les 3 à 5 prochaines étapes, exécutez, observez les résultats, puis décomposez les étapes suivantes. Ce pattern « rolling decomposition » est plus robuste que la décomposition monolithique car il intègre les résultats réels dans la planification.

Typer les sous-tâches

Assignez un type à chaque sous-tâche (analysis, code_edit, search, etc.). Ce typage permet de router automatiquement vers le bon outil, le bon modèle et la bonne stratégie de validation.

Limiter la profondeur de récursion

Pour la décomposition récursive, fixez une profondeur maximale (3 niveaux est un bon défaut). Au-delà, la décomposition devient trop fine et le coût de coordination explose.

Évaluer la qualité d’une décomposition

Comment savoir si votre décomposition est bonne ? Quatre critères permettent d’évaluer objectivement :

Complétude : le plan couvre-t-il l’intégralité de l’objectif ? Aucune étape nécessaire ne doit être omise. Vérifiez en relisant l’objectif original et en validant que chaque aspect est traité par au moins une sous-tâche.

Faisabilité : chaque sous-tâche est-elle exécutable avec les outils et les données disponibles ? Une sous-tâche « interroger la base de données clients » n’a de sens que si l’agent a accès à cette base. Validez la faisabilité en croisant chaque sous-tâche avec l’inventaire des outils disponibles.

Ordre correct : les dépendances sont-elles respectées ? On ne peut pas rédiger l’analyse avant d’avoir collecté les données. La représentation en DAG force l’explicitation de ces dépendances et permet de les vérifier automatiquement avant l’exécution.

Efficacité : pas de sous-tâches redondantes ou inutiles. Un plan qui inclut « vérifier que le fichier existe » puis « ouvrir le fichier » alors que l’ouverture inclut déjà la vérification est superflu. Chaque sous-tâche doit apporter une contribution unique à l’objectif final.

En production, la méthode la plus fiable reste le test de bout en bout : exécutez le plan, mesurez le taux de réussite, identifiez les points de défaillance, affinez. Les benchmarks comme SWE-bench et WebArena évaluent implicitement la qualité de la décomposition à travers la réussite des tâches complexes. Un agent qui décompose bien réussit plus souvent.

Verdict

La décomposition de tâches est le mécanisme qui transforme un LLM en agent. Sans elle, le modèle est limité aux problèmes résolvables en une seule passe. Avec elle, il peut s’attaquer à des objectifs arbitrairement complexes en les réduisant à des sous-problèmes gérables.

La technique a considérablement mûri entre 2023 et 2026. On est passé de BabyAGI (décomposition naïve en boucle infinie) à des systèmes comme TDAG et UniDebugger qui adaptent dynamiquement la décomposition à la complexité réelle du problème. Mais les fondamentaux restent les mêmes : diviser pour mieux régner.

Pour les développeurs : commencez par une décomposition programmatique pour vos cas d’usage récurrents, et réservez la décomposition LLM pour les tâches nouvelles ou imprévisibles. Typez vos sous-tâches, validez vos plans, limitez la profondeur, et n’oubliez pas que parfois, ne pas décomposer (quand la tâche est simple) est la meilleure stratégie.

Questions fréquentes

Quelle est la différence entre décomposition de tâches et Chain-of-Thought ?

Le Chain-of-Thought décompose le raisonnement : le modèle explicite ses étapes de réflexion pour arriver à une réponse. La task decomposition décompose l’action : elle produit un plan de sous-tâches concrètes et exécutables. Le CoT aide le modèle à mieux penser. La décomposition aide l’agent à mieux agir. Les deux sont complémentaires : le CoT peut guider la façon dont la décomposition est réalisée.

Faut-il toujours décomposer une tâche ?

Non. Pour les tâches simples (répondre à une question factuelle, traduire un texte court, résumer un paragraphe), la décomposition ajoute de la complexité inutile. La règle : si le LLM peut traiter la tâche en un seul appel avec un résultat fiable, ne décomposez pas. Si la tâche implique plusieurs outils, plusieurs étapes dépendantes ou une complexité de raisonnement élevée, décomposez.

Comment choisir la bonne granularité de décomposition ?

Visez le « sweet spot » : chaque sous-tâche doit être exécutable en un seul appel d’outil ou un seul appel LLM focalisé. Si une sous-tâche nécessite encore plusieurs étapes pour être réalisée, elle n’est pas assez décomposée. Si elle décrit une micro-action triviale (cliquer sur un bouton), elle est trop fine. Testez empiriquement : si une sous-tâche échoue régulièrement, c’est qu’elle est probablement trop complexe et mérite d’être re-décomposée.

La décomposition réduit-elle vraiment les coûts ?

Oui, de deux façons. Premièrement, des sous-tâches bien définies peuvent être routées vers des modèles plus petits et moins chers (70 à 90 % de réduction par taille de modèle inférieure). Deuxièmement, chaque sous-tâche consomme moins de tokens de contexte qu’une tâche monolithique, car seul le contexte pertinent est fourni. Le surcoût est la coordination (appels supplémentaires pour la décomposition elle-même), mais il est largement compensé dans la plupart des cas.

Quels frameworks permettent la décomposition de tâches ?

LangGraph (extension de LangChain) est le plus flexible pour les workflows avec branchements et boucles. CrewAI est idéal pour la décomposition par rôles (chaque agent gère un type de sous-tâche). AutoGen (Microsoft) convient aux workflows conversationnels multi-agents. Pour les agents de code, des frameworks comme TDAG ou UniDebugger proposent une décomposition adaptative spécialisée. Si votre besoin est simple, un loop ReAct sur l’API Claude ou OpenAI suffit sans framework externe.