Analyse
Claude Code nested sub-agents : orchestrer des agents en PME
Jusqu’au 10 juin 2026, les sub-agents Claude Code vivaient à un seul niveau : un agent principal pouvait déléguer des tâches, mais les sub-agents ne pouvaient pas eux-mêmes déléguer. Cette limitation, documentée explicitement dans les docs Anthropic (« subagents cannot spawn other subagents »), a été levée avec la version 2.1.172. Les nested sub-agents changent fondamentalement ce qu’une PME peut automatiser avec Claude Code.
Ce que les nested sub-agents changent
De la délégation plate à l’arborescence
Avant juin 2026, un workflow multi-agents Claude Code ressemblait à une étoile : un agent central délèguant à N agents spécialistes, chacun exécutant sa tâche isolément. Le problème : l’agent central devait tout coordonner lui-même, ce qui saturait son contexte sur les workflows complexes.
Avec les nested sub-agents, la structure devient un arbre. Un agent de planification crée un plan, délègue à des agents de module, qui eux-mêmes délèguent les sous-tâches à des agents d’implémentation. Chaque niveau ne voit que son périmètre — le contexte reste maîtrisé.
5 niveaux, mais 3 suffisent
Anthropic autorise jusqu’à 5 niveaux d’imbrication. En pratique, au-delà de 3 niveaux, la consommation de tokens explose et la latence augmente. Pour les PME, le pattern optimal est :
- Niveau 1 (Lead) : agent d’orchestration sur Opus 4.8 ou Fable 5 — il planifie, délègue et vérifie.
- Niveau 2 (Spécialistes) : agents dédiés par domaine (code, données, tests) sur Sonnet 4.6 — ils exécutent les tâches principales.
- Niveau 3 (Workers) : agents d’exécution unitaire sur Haiku 4.5 — ils font les opérations atomiques (linting, formatage, extraction).
Ce routing de modèles par niveau optimise le rapport coût/performance. Notre article sur l’architecture multi-agents Haiku/Sonnet détaille les benchmarks cost-perf.
Cas d’usage concrets pour PME
1. Refactoring codebase multi-modules
Un agent lead analyse la structure du projet et identifie les modules à refactorer. Il délègue à des sub-agents spécialistes (un par module) qui analysent les dépendances et proposent des changements. Chaque sub-agent de module délègue la rédaction des tests à des workers Haiku.
Avant les nested sub-agents, cette opération nécessitait une intervention humaine entre chaque module. Maintenant, l’agent lead orchestre l’ensemble et vérifie la cohérence inter-modules — le tout est auditable dans la Console.
2. Pipeline de traitement documentaire
Pour une PME qui traite des dizaines de factures ou contrats par jour :
- Lead : reçoit le lot de documents, les répartit.
- Spécialistes : un agent par type de document (facture, contrat, devis) — extrait les données structurées.
- Workers : valident les données extraites contre les règles métier, formatent pour l’ERP.
Notre guide d’extraction de factures avec Claude multimodal couvre l’extraction unitaire. Les nested sub-agents permettent le passage à l’échelle.
3. Audit de conformité AI Act
Avec l’échéance du 2 août 2026, les PME doivent auditer leurs usages d’IA. Un workflow nested peut :
- Lead : cartographie les outils IA utilisés dans l’entreprise.
- Spécialistes : évaluent le niveau de risque de chaque outil (article 6 de l’AI Act).
- Workers : génèrent les fiches de conformité et les recommandations.
Notre checklist AI Act pour PME fournit le cadre réglementaire que les agents peuvent appliquer.
Architecture technique
Système de fichiers partagé
Les sub-agents à tous les niveaux partagent le même système de fichiers. Un sub-agent de niveau 3 peut lire un fichier créé par un sub-agent de niveau 2. Cette architecture évite la sérialisation complexe des données entre agents — ils communiquent par le filesystem.
Vérification mid-workflow
L’agent lead peut « checkpointer » les sub-agents en cours d’exécution : vérifier leur avancement, valider des résultats intermédiaires, ou les réorienter si nécessaire. Ce mécanisme de supervision est critique pour les workflows longs (30+ minutes) où un sub-agent pourrait dévier.
Auditabilité dans la Console
Chaque action de chaque sub-agent est traçable dans la Claude Console : quel agent a fait quoi, dans quel ordre, avec quel raisonnement. Pour les PME soumises à des obligations de traçabilité (AI Act, RGPD), cette auditabilité native est un avantage structurel.
La gouvernance de Claude Code en entreprise couvre les policies et plafonds de coûts.
Gestion des coûts
Le piège de l’explosion de tokens
Un workflow naïf avec nested sub-agents peut consommer des volumes de tokens astronomiques. Chaque sub-agent a son propre contexte : si votre lead envoie 10 000 tokens de contexte à 5 sub-agents qui en envoient chacun 5 000 à 3 workers, le total atteint 10 000 + 50 000 + 75 000 = 135 000 tokens de contexte cumulé, avant même la première réponse.
Stratégies d’optimisation
- Routage de modèles : utilisez des modèles moins chers aux niveaux inférieurs. Haiku 4.5 coûte 80 % de moins que Opus 4.8 par token.
- Contexte minimal : ne transmettez aux sub-agents que les informations nécessaires à leur tâche, pas l’ensemble du contexte du lead.
- Parallélisme contrôlé : limitez le nombre de sub-agents simultanés. 3-5 en parallèle est un bon équilibre entre vitesse et coût.
- Monitoring budgétaire : définissez des alertes de coût dans la Console. Notre guide sur le monitoring des coûts Claude API détaille la configuration.
Budget type pour une PME
| Workflow | Tokens estimés | Coût estimé (Sonnet 4.6) |
|---|---|---|
| Refactoring 1 module | 50-100k | 0,20-0,50 $ |
| Refactoring codebase 10 modules (nested) | 500k-2M | 2-8 $ |
| Extraction 50 factures (nested) | 200k-500k | 0,80-2 $ |
| Audit conformité complet | 1-5M | 4-20 $ |
Limites et pièges
La profondeur n’est pas toujours la réponse
Imbriquer des agents sur 4-5 niveaux n’a de sens que si chaque niveau ajoute une réelle spécialisation. Un workflow plat avec 10 sub-agents au niveau 1 peut être plus efficace qu’un arbre de 3 niveaux avec 3 agents chacun — si les tâches sont indépendantes.
Gestion d’erreurs en cascade
Si un worker de niveau 3 échoue, l’erreur remonte au spécialiste de niveau 2, qui décide de la retrier ou de la remonter au lead. Cette chaîne de gestion d’erreurs doit être pensée dans le prompt du lead — sinon, un échec bas niveau peut bloquer tout le workflow.
Sandbox et sécurité
Les nested sub-agents héritent du périmètre sandbox du lead. Mais chaque niveau supplémentaire augmente la surface d’attaque potentielle. Les bonnes pratiques de confinement des agents s’appliquent a fortiori dans un contexte nested.
FAQ
Les nested sub-agents fonctionnent-ils avec Claude Code on the Web ?
Oui. Claude Code on the Web (environnement distant) supporte les nested sub-agents depuis la v2.1.172. Les agents s’exécutent dans le même container cloud, ce qui simplifie le partage du filesystem. La latence réseau est négligeable car tout reste côté serveur. Notre article sur Claude Code on the Web couvre l’environnement.
Peut-on utiliser des modèles différents à chaque niveau ?
Oui, c’est même recommandé. L’agent principal spécifie le modèle utilisé par chaque sub-agent via le paramètre model dans l’appel de l’Agent tool. Un pattern courant : Opus 4.8 pour le lead, Sonnet 4.6 pour les spécialistes, Haiku 4.5 pour les workers. Le fast mode d’Opus 4.8 est une option pour réduire la latence du lead sans changer de modèle.
Les Dynamic Workflows sont-ils la même chose que les nested sub-agents ?
Non. Les Dynamic Workflows sont un concept de niveau supérieur : Claude crée un plan d’orchestration et le suit strictement, y compris à travers des centaines d’agents. Les nested sub-agents sont le mécanisme technique qui permet cette orchestration. Vous pouvez utiliser des nested sub-agents sans Dynamic Workflows (orchestration manuelle), mais les Dynamic Workflows utilisent les nested sub-agents sous le capot.