Claude Code : déléguer avec des sous-agents imbriqués

Que permet la délégation imbriquée dans Claude Code v2.1.172 ?#

Si vous avez lu quoi que ce soit sur les agents IA dans Claude Code ces derniers mois, vous avez forcément rencontré la même phrase. Elle figure dans la documentation officielle, dans mon guide sur les sous-agents et dans les analyses de tous les concurrents. La voici : « Un sous-agent ne peut pas lancer un autre sous-agent. » Au 11 juin 2026, cette phrase figure encore à trois endroits différents sur code.claude.com/docs/en/sub-agents. Anthropic ne l’a tout simplement pas encore mise à jour.

Le 10 juin à 20:44 UTC, Claude Code v2.1.172 est apparu sur GitHub Releases. L’entrée principale du journal des modifications tenait en une ligne :

Cette même version a également corrigé un bug qui ne pouvait se produire qu’avec l’imbrication : un sous-agent d’arrière-plan restait affiché comme actif dans le panneau des agents après l’arrêt du sous-agent imbriqué qu’il avait lancé.

C’est un cas rare où la documentation officielle contredit encore la version publiée. Je vais maintenant expliquer en quoi l’imbrication diffère des sous-agents parallèles, ce que signifie « profondeur 5 » et les trois scénarios où elle est réellement utile aujourd’hui.

En quoi les sous-agents imbriqués diffèrent-ils des sous-agents parallèles et séquentiels ?#

J’ai passé beaucoup de temps à essayer ces trois approches moi-même. Voici comment je les vois : la délégation a trois dimensions. La largeur, la longueur et la profondeur. Chacune répond à un problème différent.

La largeur : les sous-agents parallèles. La conversation principale lance N sous-agents indépendants au même niveau. Chacun reçoit une tâche précise, travaille dans sa propre fenêtre isolée et ne renvoie que le résultat. La largeur fait gagner du temps : 5 sous-agents qui travaillent en parallèle terminent en autant de temps qu’un seul mettrait à faire le même travail de façon séquentielle. C’est le modèle que j’ai présenté dans mon guide sur les sous-agents parallèles avec des worktrees.

La longueur : une chaîne de sous-agents. A travaille et transmet le résultat à B, B travaille et le transmet à C. Chacun voit les données reçues de l’agent précédent. La longueur établit un ordre : B ne peut pas commencer avant d’avoir reçu les données de A. Exemple classique : un sous-agent de recherche rassemble d’abord les sources, puis un sous-agent de rédaction écrit un article à partir de ces sources, et enfin un sous-agent de vérification des faits contrôle l’article. C’est une séquence linéaire ; la conversation principale garde le fil de toute l’histoire.

La profondeur : les sous-agents imbriqués. A lance B, B lance C, C lance D. Chaque enfant travaille au sein de son parent, dans sa propre fenêtre isolée, et ne renvoie que le résultat à son parent. La conversation principale ne voit rien de ce qui se passe chez les enfants, petits-enfants et arrière-petits-enfants. C’est la nouveauté de la version v2.1.172.

La principale confusion vient de l’idée que profondeur 5 signifie « vous pouvez lancer 5 sous-agents simultanément ». Ce n’est pas le cas. La profondeur désigne un niveau vertical dans l’arbre, pas le nombre d’enfants simultanés. Il peut y avoir un ou cent sous-agents à chaque niveau. Profondeur 5 signifie que la chaîne de délégation peut descendre de 5 étapes : conversation principale → petit-enfant-1 → petit-enfant-2 → petit-enfant-3 → petit-enfant-4 → petit-enfant-5. Et l’arbre peut se ramifier à chaque niveau.

La version 2.1.172 a supprimé la règle selon laquelle un sous-agent ne pouvait pas en lancer un autre.

Si vous cherchez à gagner en vitesse, il vous faut de la largeur. Si vous avez un ordre d’exécution strict à respecter, il vous faut de la longueur. La profondeur est utile dans un seul cas : quand l’une de vos tâches comprend une sous-tâche bruyante (15 requêtes Web, exploration de journaux, lecture d’une douzaine de fichiers). Et que vous ne voulez pas que ce bruit envahisse votre fenêtre principale.

Que signifie « 5 niveaux de profondeur » en pratique ?#

Voici un point important concernant l’honnêteté. J’ai passé une demi-journée à consulter la documentation et les analyses de la communauté pour découvrir qu’Anthropic n’avait pas donné de définition précise. Voici ce qu’il faut savoir.

C’est une limite, pas un paramètre.

La limite est intégrée côté serveur. Une rétro-ingénierie du client v2.1.172 n’a révélé aucune constante MAX_DEPTH. Cela signifie que la vérification se fait quelque part dans l’API Anthropic, et non localement sur votre machine. Vous ne pouvez pas définir --max-depth 7 pour approfondir l’arbre. Vous ne pouvez pas non plus définir --max-depth 2 pour imposer une limite plus basse et plus sûre. Le seul contrôle dont vous disposez est la liste d’autorisation Agent(agent_type) dans le frontmatter, mais elle limite les types d’agents enfants, pas la profondeur.

Anthropic n’a pas défini précisément ce que signifie « 5 ». C’est le deuxième point important :

Anthropic n’a pas précisé exactement ce que signifie « 5 ». Les sources officielles ne précisent pas si depth=5 signifie cinq niveaux sous la racine ou cinq agents au total, racine comprise.

Pour l’instant, les intégrations tierces l’interprètent différemment. L’ADR-147 du projet ruvnet/ruflo part du principe que « 5 niveaux d’enfants sous la racine = 6 agents dans la chaîne ». J’utilise la même convention dans mes expériences : la conversation principale est au niveau 0, ses enfants directs au niveau 1, et ainsi de suite jusqu’au niveau 5. Mais ce n’est pas indiqué dans la documentation publique.

La limite est déjà activée, sans indicateur. Vous n’avez rien à activer. Après avoir mis à jour Claude Code vers la version v2.1.172, vous pouvez ajouter Agent aux tools d’un agent enfant, qui pourra alors lancer un autre sous-agent. L’essentiel est que l’agent parent doit l’autoriser (tools: Agent(...)).

Où se situe votre délégation aujourd’hui : en largeur, en longueur ou en profondeur ?#

Passez en revue vos 5 derniers prompts. Combien de fois avez-vous fait ceci : une tâche commence, Claude se met à chercher dans les fichiers, envoie 10 requêtes Web, déverse tout un mur de journaux dans le contexte — et 20 minutes plus tard, vous constatez que la fenêtre est pleine. La réponse finale doit déjà se contenter d’un maigre budget de tokens parce que 70 pour cent du contexte a été consommé par les sorties intermédiaires.

C’est un scénario où il vous faut de la profondeur. Pas du parallélisme, pas une chaîne : de la profondeur. La conversation principale devrait déléguer la « recherche » à un sous-agent, qui lancerait ensuite ses propres enfants depuis sa fenêtre pour des recherches Web précises, la lecture de fichiers et des recherches dans les fichiers. Les enfants ne renvoient que des conclusions synthétisées. Un petit-enfant dit à son parent : « trouvé, confirmé » ou « pas trouvé, raison X ». Le parent rassemble tout dans un résumé unique et vous le renvoie. La conversation principale reste claire.

Avant le 9 juin, je reproduisais cela manuellement. J’ouvrais une deuxième instance de Claude Code, copiais le prompt « recherche ceci », l’exécutais, puis transférais moi-même le résultat dans la fenêtre principale. Avec la version v2.1.172, vous pouvez décrire cette tâche directement dans le prompt système de l’orchestrateur : Claude construira lui-même l’arbre.

Dans quels 3 scénarios les sous-agents imbriqués sont-ils vraiment utiles ?#

Scénario 1. Recherche approfondie avec vérification des faits

Imaginez que vous rassemblez des éléments pour un article ou une proposition commerciale. Vous devez d’abord recueillir 5–10 affirmations à partir de sources publiques, puis vérifier chacune d’elles : retrouver la source originale, vous assurer que la citation est exacte et calculer les chiffres réels.

Avant la version v2.1.172, vous aviez deux options. Soit vous faisiez tout avec un seul sous-agent, qui peinait à traiter 30 requêtes Web en entassant tout dans son contexte. Soit vous découpiez le travail manuellement : un prompt pour extraire les affirmations, puis une série de prompts pour les vérifier, avec un sous-agent distinct pour chacune. La conversation principale se serait retrouvée remplie de longs blocs de listes intermédiaires.

Dans la recette ci-dessous, la conversation principale délègue à research-orchestrator (niveau 1). Celui-ci extrait lui-même les affirmations et confie chacune à fact-verifier (niveau 2), qui délègue les recherches ciblées à web-deep-search (niveau 3). La conversation principale ne reçoit qu’un tableau d’affirmations vérifiées et de leurs sources. Tout le reste reste dans les fenêtres enfants et n’entre jamais dans votre contexte.

Scénario 2. Analyse d’un grand dépôt

On vous confie un projet contenant 200 fichiers. Vous devez en comprendre l’architecture, trouver les principaux modules et évaluer la dette technique. Lancez Glob et une douzaine d’appels Read à la main et votre fenêtre sera pleine en 10 minutes.

La profondeur résout le problème ainsi : la conversation principale lance un sous-agent « architecte ». Celui-ci lance en interne trois enfants — l’un inspecte la structure des répertoires (exécute Glob et la résume), le deuxième lit 5 fichiers de configuration clés, et le troisième recherche les principaux motifs. Chacun renvoie un résumé concis à l’architecte. Celui-ci rassemble les éléments et fournit à la conversation principale un rapport final d’une demi-page d’écran. Vous obtenez une carte du projet sans que des sorties cat de tous les fichiers ne submergent le contexte.

Scénario 3. Analyse des dépendances de bout en bout

Vous modifiez un schéma de base de données, un contrat d’API ou un fichier de configuration partagé. Vous devez comprendre où les répercussions se feront sentir. Cette tâche épuise le contexte le plus rapidement, car les dépendances sont nombreuses et chacune doit être vérifiée dans le code source.

Avec la profondeur, la conversation principale lance un impact-analyzer (niveau 1). Celui-ci lance un dependency-tracer pour chaque fichier affecté (niveau 2). Chaque tracer lance en interne un consumer-finder (niveau 3), qui parcourt la base de code à la recherche des utilisateurs de cette dépendance. Chacun renvoie ensuite uniquement l’essentiel : « ces trois endroits vont casser ». La conversation principale compose un tableau « fichiers concernés → impact » sans voir les résultats des recherches.

Comment configurer des sous-agents imbriqués en 10 minutes#

Étape 1. Vérifiez que vous utilisez la version v2.1.172 ou une version ultérieure.

claude --version

Si la version est antérieure, mettez-la à jour. La principale nouveauté de cette version tient en une ligne dans le journal des modifications : « Les sous-agents peuvent désormais lancer leurs propres sous-agents, jusqu’à 5 niveaux de profondeur » (texte intégral).

Étape 2. Créez un agent parent capable de lancer des enfants.

Fichier .claude/agents/research-orchestrator.md :

---
name: research-orchestrator
description: Délègue la recherche avec une vérification approfondie des faits
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---

Tu es un orchestrateur de recherche. Quand tu reçois un sujet :
1. Lis le contenu fourni ou récupère les URL publiques fournies.
   Extrais toi-même au plus 5 affirmations concrètes. Pour chacune, note
   le texte, l’URL ou fichier source et le passage exact qui l’appuie.
   Sans contenu source, demande-le avant toute délégation.
2. Appelle fact-verifier pour chaque affirmation : il lancera lui-même
   ses sous-agents enfants pour les recherches Web et les vérifications.
3. fact-verifier ne te renverra que les conclusions finales :
   ne charge pas les sorties intermédiaires dans ton contexte.

Le rapport final doit contenir uniquement un tableau { claim, sources[], confidence }.

La ligne tools n’accorde que le type enfant fact-verifier. L’orchestrateur extrait lui-même les affirmations : aucun fichier claim-extractor non défini n’est nécessaire. Une liste de types autorisés limite les types appelables, pas leur nombre de lancements. Bornez séparément la recette à cinq affirmations extraites au maximum.

Étape 3. Créez un agent enfant capable de lancer lui-même des petits-enfants.

Fichier .claude/agents/fact-verifier.md :

---
name: fact-verifier
description: Vérifie une affirmation au moyen de recherches Web déléguées à des agents enfants
tools: Agent(web-deep-search), Read
model: sonnet
---

Tu es un vérificateur de faits. Quand tu reçois une affirmation :
1. Formule 2-3 requêtes de recherche.
2. Lance web-deep-search pour chacune : il utilisera lui-même
   WebSearch et WebFetch, puis renverra des extraits vérifiés.
3. Réunis le tout en un seul verdict : { claim, sources[], confidence }.

Vous voyez le point essentiel ? Là encore, la ligne tools indique Agent(web-deep-search). Cela signifie que fact-verifier (niveau 2 dans notre arbre) peut lui-même lancer un autre sous-agent (niveau 3). Auparavant, cette ligne n’avait aucun effet — la documentation contient toujours la phrase suivante :

Avec la version v2.1.172, cette phrase est obsolète. La syntaxe est la même, mais elle fonctionne désormais à tous les niveaux de l’arbre.

Étape 4. Créez un petit-enfant.

Fichier .claude/agents/web-deep-search.md :

---
name: web-deep-search
description: Effectue des recherches Web et renvoie des extraits
tools: WebSearch, WebFetch
model: haiku
---

Tu as reçu une requête de recherche. Lance WebSearch, sélectionne les 3 URL
les plus pertinentes et récupère avec WebFetch des preuves textuelles
à l’appui de l’affirmation. Renvoie un tableau { url, snippet, supports_claim: yes|no }.

Le petit-enfant n’a pas Agent dans tools ; il ne lance donc pas d’autres agents plus bas dans l’arbre.

Étape 5. Lancez l’orchestrateur.

claude --agent research-orchestrator

Fournissez ensuite le texte source ou ses URL publiques : « Extrais et vérifie au plus 5 affirmations concrètes de ces sources ; donne affirmations, sources et confiance. » Avec --agent research-orchestrator, la session est elle-même l’orchestrateur ; vérificateurs et chercheurs ajoutent deux niveaux délégués. Si une session ordinaire lui délègue le travail, trois niveaux se trouvent sous cette session principale.

Quels sont les 5 anti-modèles qui gaspillent des tokens et nuisent à la visibilité ?#

Anti-modèle 1. La tâche tient dans une seule fenêtre.

Si un seul sous-agent peut s’en charger sans bruit, n’ajoutez pas de niveaux : l’imbrication ajoute des coûts et de la latence sans rien apporter.

Si un seul sous-agent peut accomplir la tâche sans bruit, l’imbrication ne fait qu’ajouter des coûts et de la latence sans rien apporter.

Anti-modèle 2. Vous recherchez la vitesse, pas l’isolation.

Si vous cherchez à gagner en vitesse, il vous faut du parallélisme, pas de la profondeur. Lancez 5 sous-agents côte à côte au même niveau au lieu de construire une chaîne. La profondeur sert à déplacer le travail préparatoire bruyant dans une fenêtre enfant, pas à accélérer les choses.

Anti-modèle 3. Le travail est par nature superficiel.

« Trouve ce fichier et montre-le-moi » est une demande en deux étapes ; elle n’a pas besoin d’une hiérarchie à trois niveaux. L’imbrication est utile quand une tâche comporte une sous-tâche bruyante. S’il n’y a pas de bruit, n’ajoutez pas de sous-agents.

Anti-modèle 4. Des prompts vagues au premier niveau.

C’est le scénario le plus dangereux. Si vous donnez un prompt vague à l’orchestrateur de niveau 1, ce flou se multiplie. Un prompt vague au niveau 1 devient 4 prompts vagues au niveau 2 et 16 au niveau 3. Quand les petits-enfants commencent à travailler, ils ne savent même pas ce qu’ils cherchent.

Anti-modèle 5. Croissance géométrique des coûts.

Le principal argument économique : l’imbrication multiplie l’utilisation des tokens, et cette multiplication s’accentue avec la profondeur.

Le principal argument économique : l’imbrication multiplie l’utilisation des tokens, et cette multiplication s’accentue avec la profondeur.

Calcul approximatif : une chaîne de profondeur 3 avec une ramification de 3 à chaque niveau représente 27 sous-agents. Cela fait au moins 27 fois plus de tokens qu’une simple requête. Avec l’abonnement Pro de Claude, ce calcul épuise votre limite quotidienne en quelques heures. Avec un abonnement Max, vous consommerez en une journée le quota d’une semaine.

Anti-modèle en bonus (d’après mon expérience) : « 50 agents qui font un travail inutile. »

Quand je regarde les projets d’autres personnes, je vois souvent ceci : « J’ai 50 agents au travail. » Je demande ce qu’ils font. Et ces 50 agents font un travail inutile. Ils produisent des piles de sorties superflues, des tonnes de résumés bruts, des doublons et des murs de journaux. Chacun fait quelque chose d’« utile en général », et le résultat est un contexte submergé et une facture de tokens comparable à celle d’une petite entreprise. La profondeur 5 ne résout pas ce problème — elle l’aggrave. Si, dès le niveau 1, on ne sait déjà pas qui fait quoi, une profondeur de 5 signifie cinq niveaux de confusion.

Avant de lancer un sous-agent, évaluez-le en répondant à 4 questions en une demi-minute :

• Que fait-il exactement (en une phrase) ?
• Quels fichiers touche-t-il ?
• Que renvoie-t-il à son parent ?
• Qui vérifie son travail ?

Si vous ne pouvez pas répondre en 30 secondes, ce sous-agent ne devrait pas exister. J’ai expliqué cette règle séparément dans mon guide sur les sous-agents parallèles.

Pourquoi l’imbrication sans ingénierie du contexte entraîne-t-elle 5 niveaux d’hallucinations ?#

Voici une question qu’on me pose souvent : « J’ai mis Claude Code à jour, ajouté Agent à tools, l’arbre se construit, mais la réponse finale est toujours à côté de la plaque. Pourquoi ? »

La réponse est simple. Chaque sous-agent de Claude Code repart de zéro. Voici ce que dit la documentation officielle :

Au niveau 1, cela reste gérable : l’orchestrateur transmet une description de tâche concise à son enfant. Mais au niveau 3, le petit-enfant reçoit un message de délégation de son parent, qui n’avait lui-même reçu qu’un message de délégation. Chaque niveau n’a transmis qu’une partie du contexte. Au niveau 5, vous avez un sous-agent dont la fenêtre contient la phrase « vérifie l’affirmation X », et rien d’autre. Il ne sait pas sur quel projet il travaille, quelle tâche il résout ni sur quoi il doit se concentrer.

Sans CLAUDE.md, un petit-enfant de niveau cinq ressemble à un employé qui se présente au bureau pour la toute première fois de sa vie, sans aucune orientation. Il fera quelque chose puisqu’il a reçu une tâche. Mais ce ne sera pas ce dont le projet a besoin.

C’est pourquoi la configuration est essentielle. La profondeur 5 sans CLAUDE.md correctement configuré, sans business/ ni pipeline de compétences, c’est le casino. Avec ces éléments, c’est un outil.

Qu’est-ce qui a changé dans v2.1.172 en dehors de l’imbrication ?#

Ouvrez le journal complet des modifications de v2.1.172 : vous verrez que toute la version porte sur les sous-agents.

Correctif 1. Un sous-agent d’arrière-plan ne reste plus « bloqué » à l’état actif dans le panneau des agents après l’arrêt du sous-agent imbriqué qu’il a lancé. Ce bug ne peut se produire qu’avec l’imbrication.

Correctif 2. Les restrictions availableModels s’appliquent désormais aussi aux sous-agents. Auparavant, si vous limitiez les modèles que l’équipe pouvait utiliser (par exemple en interdisant opus pour faire des économies), les sous-agents pouvaient contourner la règle en la remplaçant dans leur propre configuration. Avec v2.1.172, la règle s’applique partout.

Correctif 3. La flèche vers le haut dans l’historique des prompts affiche désormais les prompts de l’onglet actuel du sous-agent, et non ceux de l’agent principal. Une amélioration de la visibilité.

Correctif 4. L’utilisation du CPU au repos a été réduite : l’indicateur /goal ne redessine plus le terminal à 5 Hz lorsque celui-ci est inactif, et l’interface est redessinée moins souvent pendant que les sous-agents parallèles travaillent.

Je tiens à souligner que les quatre correctifs concernent les sous-agents. Cela signifie qu’Anthropic a publié toute l’infrastructure de l’imbrication, et pas seulement une ligne dans le journal des modifications. L’imbrication était déjà utilisée depuis un certain temps en interne chez Anthropic avant sa publication.

Liste de contrôle : quand l’imbrication aide et quand elle nuit#

Utilisez l’imbrication si :

• La tâche comprend une sous-tâche impliquant un grand nombre de requêtes Web, de recherches dans les fichiers ou de lectures de fichiers.
• Il est acceptable de perdre cette sous-tâche (si le petit-enfant répond « rien trouvé », l’orchestrateur peut continuer).
• Vous n’avez pas besoin des résultats intermédiaires dans la fenêtre principale.
• Vous disposez d’un CLAUDE.md et d’un contexte de projet assemblé sur lequel le sous-agent peut s’appuyer.
• Vous pouvez clairement décrire ce que chaque niveau renverra (entrée, sortie, format).
• Vous avez un abonnement Max ou une réserve de tokens suffisante pour ×27.

N’utilisez pas l’imbrication si :

• Un seul sous-agent peut résoudre la tâche sans bruit.
• Vous avez besoin des résultats intermédiaires dans la fenêtre principale (cela signifie que vous recherchez le parallélisme).
• Le projet ne possède pas de CLAUDE.md ou ne contient qu’un contexte métier très limité.
• Les prompts de niveau 1 sont vagues (leur flou se multipliera de façon exponentielle dans l’arbre).
• Vous avez besoin de vitesse — à résultat comparable, le parallélisme est plus rapide que la profondeur.
• Vous avez un abonnement Pro et travaillez toute la journée — vous épuiserez la limite en quelques heures.

D’autres ressources sont disponibles sur Ailoot.