Sub-agents Claude Code : déléguer une discovery en 30 minutes
Walkthrough complet d'un Product Manager : comment briefer trois sub-agents Claude Code en parallèle (voix client, data produit, concurrence) pour transformer une matinée de recherche en quarante minutes de synthèse.
Le brief impossible du lundi matin
Lundi 9h. Le fondateur te ping : "Les clients nous parlent de plus en plus de l'onboarding. On peut s'y mettre ? J'ai besoin d'un brief pour mercredi."
Tu sais que "les clients en parlent" veut tout dire et rien dire. Avant de cadrer une solution, il faut cadrer le problème. C'est le métier d'un Product Manager : pas accoucher d'une roadmap, comprendre ce qu'on cherche vraiment à résoudre.
Avant les sub-agents, ta journée ressemblait à ça :
- 9h30. Tu ouvres Confluence, tu fouilles les vieilles specs et les notes user research.
- 10h30. Tu passes sur Jira, tu fais le tour des tickets clients, tu copies les plus parlants.
- 11h30. Tu reparcours les comptes rendus Teams des calls commerciaux des deux derniers mois.
- 14h. Tu lances une requête data, tu exportes en CSV. Tu enchaînes sur la veille concurrence.
- Lendemain matin, tu écris le brief.
Une journée et demie. Tu as collecté plus que tu n'as réfléchi.
Avec les sub-agents Claude Code, la même journée tient en quarante minutes. Tu briefes trois agents en parallèle, chacun sur une source. Tu pars en 1:1, en conf client, déjeuner. Tu reviens à 14h, tu as trois synthèses sourcées sous les yeux. Tu n'as plus à chercher. Tu lis, tu recoupes, tu décides.
C'est ce qu'on va dérouler maintenant, étape par étape.
C'est quoi un sub-agent Claude Code, concrètement
Un sub-agent, c'est une instance fraîche de Claude Code que tu lances depuis ta conversation principale. Elle ne sait rien de ce que vous vous êtes dit avant. Elle reçoit un brief, fait sa tâche dans son propre contexte, te ramène une synthèse, disparaît. C'est l'équivalent du Task tool dans la doc Anthropic.
Trois propriétés à connaître :
- Elle a son propre contexte. Tout ce qu'elle lit (50 fichiers, 30 tickets Jira, 15 pages web) reste chez elle. Ta conversation principale ne voit que la synthèse finale.
- Elle peut tourner en parallèle. Tu lances trois sub-agents dans le même message, ils travaillent en même temps. Le temps mur est divisé.
- Tu choisis ses outils. Un sub-agent qui doit lire des fichiers n'a pas besoin d'écrire. Un sub-agent qui fait de la veille web n'a besoin que de WebFetch. Tu restreins, ce qui évite les surprises.
Dans Claude Code, tu déclenches un sub-agent en demandant explicitement, en langage naturel :
Tu peux aussi taper /agents pour voir la liste de tes custom agents existants et en sélectionner un. Ou @nom-de-agent en milieu de message pour invoquer un agent spécifique. C'est la même logique que tes Skills : Claude charge ce qu'il a sous la main et le déclenche quand le contexte s'y prête. On y revient plus loin.
Le walkthrough : tes trois sub-agents en discovery
Voilà concrètement comment se passe la discovery du fondateur, en quarante minutes.
Sub-agent 1 : la voix client
Tu commences par le plus important : qu'est-ce que les clients disent vraiment ? Tu ouvres Claude Code, tu écris :
./confluence/, les comptes rendus de calls dans ./teams-notes/, et l'export Jira ./jira-export.csv. Cherche tout ce qui mentionne l'onboarding.
Ressors-moi : (1) les 3 patterns récurrents les plus fréquents, (2) deux verbatims clients par pattern avec la source précise, (3) une estimation de la criticité en t'appuyant sur le ton et la fréquence. Format markdown. Pas d'invention : si tu ne trouves pas, dis-le.
Trois minutes plus tard, ce qui revient :
"On a abandonné l'onboarding au bout de 3 jours, l'équipe a décroché." · Call commercial Acme, 2026-03-15
"Mes commerciaux n'utilisent que 30% de la plateforme." · Ticket Jira #4521
Criticité : haute (mentionné dans 4 churns sur 7 ce trimestre).
Pattern 2 : manque d'auto-config · 28 mentions, 8 clients
"Chaque nouvel admin doit refaire les 40 mêmes clics." · Compte rendu user research, 2026-02-20
"On veut pouvoir cloner notre setup." · Confluence/feedback-q1.md
Criticité : moyenne (irritation récurrente, pas bloquant).
Pattern 3 : reporting trop technique · 15 mentions, 5 clients
Verbatims et sources fournis.
Criticité : faible (demande, pas plainte).
Tu n'as pas lu un seul ticket. Tu as une synthèse propre, sourcée, avec des verbatims et une estimation de criticité que tu peux directement remettre en cause si elle te semble fausse.
Sub-agent 2 : la data produit
Pendant que le premier tourne, tu lances le deuxième dans la foulée. Cette fois, l'agent va aller chercher la data via le MCP que tu as branché sur ton outil d'analytics.
Cinq minutes :
Funnel d'activation : drop-off de 41% au step 3 (config initiale).
Cohortes : < 6 mois → 22% d'adoption · > 12 mois → 51% d'adoption.
Insight 1 : la friction est concentrée dans la phase d'activation, pas dans l'usage récurrent. Les comptes qui passent le step 3 restent.
Insight 2 : l'écart entre cohortes récentes et anciennes suggère un problème d'onboarding plus que de produit.
Insight 3 : les 38% qui adoptent l'utilisent en moyenne 4,2 fois par semaine, ce qui est solide. Le problème est le passage du seuil, pas la valeur perçue.
Et ça colle avec ce que t'a dit le sub-agent 1 : la voix client parle d'onboarding trop long, la data confirme un drop-off au step 3 d'activation. Tu as déjà ton problem statement sans avoir touché un seul tableau Excel.
Sub-agent 3 : la concurrence
Le troisième attaque la veille externe. Là, tu lui donnes accès au web.
Sept minutes plus tard :
Bolt : free tier généreux, monétisation sur les intégrations. Onboarding self-serve mais peu guidé. Gap : config initiale manuelle, comme nous.
Cetra : focus pur self-serve, claim "first value en 5 minutes". Gap retours : feature set limité au-delà du onboarding.
Drift : approche templates pré-configurés par industrie. Gap : pas de fine-tuning possible.
Opportunité différenciante : aucun ne propose d'auto-config basée sur le profil de l'équipe. Bolt et Drift ont essayé en partie, sans aller au bout. Pourrait être un angle de positionnement.
Tu as les trois pièces. Voix client, data produit, concurrence. Tu n'as pas ouvert un onglet, pas lu un PDF, pas exporté un CSV.
Le brief, maintenant
Avec les trois synthèses sous les yeux, le brief s'écrit en quarante minutes parce que tu n'as plus à chercher. Tu lis, tu recoupes (le pattern onboarding du sub-agent 1 et le drop-off step 3 du sub-agent 2 disent la même chose), tu identifies l'angle (l'auto-config qu'aucun concurrent ne tient), tu rédiges.
Tu n'es plus le PM qui collecte. Tu es le PM qui décide.
Pourquoi les sub-agents Claude Code marchent
Ce qu'on vient de faire repose sur les trois propriétés évoquées plus haut. Si tu les as comprises, tu sais quand sortir un sub-agent et quand rester dans la conversation principale.
Le contexte isolé. Le sub-agent 1 a probablement traité 80 000 tokens (verbatims, tickets, comptes rendus). Tout ça est resté chez lui. Toi, dans ta conversation principale, tu n'as reçu que la synthèse finale, soit environ 600 tokens. Ton quota n'est pas affecté, ta lisibilité non plus.
Le parallélisme. Les trois sub-agents ont tourné en même temps. Sept minutes au total au lieu de quinze en série. C'est ce qui transforme une matinée en demi-heure quand tu as plusieurs sources indépendantes.
Les outils restreints. Le sub-agent 1 n'avait que Read et Grep (pas de risque qu'il modifie un fichier). Le sub-agent 2 avait uniquement le MCP analytics. Le sub-agent 3, uniquement WebFetch. Personne ne peut faire de bêtise hors de son périmètre. C'est la même logique que les droits d'accès dans une boîte : par défaut, le minimum.
Et si tu n'es pas PM ?
La discovery n'est qu'un cas. Tout métier qui passe par "je collecte trois sources, je synthétise, je décide" peut s'appliquer la même mécanique. Trois exemples pour t'aider à transposer.
Le motif est toujours le même : trois sources hétérogènes, trois sub-agents en parallèle, une synthèse qui te permet de décider sans avoir collecté toi-même.
De l'ad hoc au custom agent : codifier ce qui marche
La discovery, tu la refais probablement deux fois par mois. Plutôt que de réécrire le même brief à chaque fois, tu le codifies dans un custom agent. C'est un fichier markdown que tu poses dans .claude/agents/, et que Claude Code sélectionne tout seul la prochaine fois que tu lui dis "fais-moi une discovery". Même logique que ta bibliothèque de Skills, mais pour des rôles complets, pas juste des workflows.
Voilà à quoi ressemble le fichier discovery-pm.md :
name: discovery-pm
description: À utiliser pour cadrer une discovery produit. Agrège voix client, data, et concurrence sur un sujet donné.
tools: Read, Grep, Glob, WebFetch
model: sonnet
---
Tu es un analyste discovery. Quand on te donne un sujet :
1. Voix client : explore les exports Confluence, Teams notes, Jira tickets. Sors 3 patterns avec verbatims et criticité.
2. Data produit : si un MCP analytics est dispo, sors adoption, funnel, comparaison cohortes.
3. Concurrence : web search sur 4 concurrents, tableau comparatif, opportunité.
Toujours citer la source. Jamais inventer une métrique. Si tu ne trouves pas, dis-le.
À partir de là, la prochaine discovery s'écrit comme ça :
Tu viens de transformer une heure de brief verbal en une ligne. Et l'agent gardera la même rigueur la dixième fois que la première.
Les pièges classiques
Tout le monde passe par au moins un de ces travers en s'y mettant.
Regarde si y a un truc à corriger dans le document.
L'agent ne sait pas ce que tu cherches. Il te ramène une liste générique de "points d'attention" qui ne sert à rien.
Lis ce mémo. Joue le rôle d'un investisseur sceptique. Ressors les 3 arguments les plus faibles avec une suggestion de reformulation pour chacun.
Objectif clair, méthode définie, format de sortie cadré.
Un agent pour la review, un pour la doc, un pour la sécurité, un pour la migration, un pour les release notes, un pour... Claude ne sait plus lequel choisir et finit par tout faire lui-même.
Tu ajoutes un nouveau custom agent seulement quand tu refais le même brief ad hoc deux fois par semaine.
Un rôle qui se résume en une phrase claire, sans recouvrement.
Tu crées un agent reviewer et tu lui laisses accès à tous les outils par défaut. Le jour où tu lui demandes de relire un document, il le réécrit.
Un agent reviewer ne doit avoir que Read et Grep. Un agent qui fait de la veille n'a besoin que de WebFetch.
Ce que tu ne donnes pas, il ne peut pas l'utiliser.
Trois niveaux de délégation, à garder en tête
Trois niveaux qui ne se remplacent pas, ils s'empilent.
Tu commences toujours par la conversation principale. C'est toi qui pilotes, qui décides quoi déléguer.
Tu sors un sub-agent ad hoc quand tu sens que tu vas charger ton contexte pour rien (10 fichiers à lire, une recherche web large, un audit qui demande un regard frais).
Tu codifies en custom agent quand tu te rends compte que tu refais le même brief deux fois par semaine. Tu en transformes un, pas dix : commence par un seul, vois s'il tient la route, étends ensuite.
Le réflexe à garder
Quand tu hésites entre faire toi-même et déléguer, sors un sub-agent. C'est moins cher en charge mentale qu'en tokens.
La règle qui marche : si la tâche peut tenir dans un brief écrit de cinq lignes, et que la sortie est un livrable que tu peux lire, c'est un job pour un sub-agent. Si tu as besoin d'aller-retours rapides ou de construire une compréhension partagée, tu restes dans la conversation principale.
Les sub-agents ne remplacent pas ta conversation principale. Ils la protègent. Plus tu déportes ce qui peut l'être, plus elle reste claire, courte, précise. Et plus elle est précise, meilleures sont tes décisions.
Identifie une tâche que tu fais deux fois par mois et qui te bouffe une matinée (revue d'un livrable, veille concurrence, audit). Briefe un sub-agent pour cette tâche, exécute-la une fois.
Si ça marche, encapsule le brief dans un custom agent et range-le à côté de tes Skills. Tu viens d'embaucher un membre d'équipe gratuit, qui sera dispo le prochain lundi à 9h.
Au-delà de la productivité, c'est un changement de posture. Le PM qui passe deux jours à compiler avant chaque kick-off ne fait plus le même métier que celui qui en passe deux heures. Pas parce qu'il est moins bon. Parce qu'il fait à la main ce que les autres délèguent. Les sub-agents ne te rendent pas plus rapide. Ils te rendent disponible pour les vraies questions : pourquoi on attaque ce problème, qu'est-ce qu'on tranche, qu'est-ce qu'on assume.
Le bon réflexe, ce n'est pas de tout déléguer. C'est de savoir ce qui mérite de rester dans ta tête, et ce qui peut sortir.
Prochaine étape du parcours : mon setup complet, où on assemble Skills, MCP et sub-agents en un système qui te suit du prompt au produit.
Si cet article t'a fait gagner du temps,
il en fera gagner à quelqu'un dans ton réseau.
Continuer la lecture
Le mur du quota : pourquoi ton forfait craque en milieu de semaine
Gestion du contexte Claude Code : les 4 gestes pour ne plus te faire bloquer en milieu de semaine et garder des réponses précises du lundi au vendredi.
Construire sa bibliothèque de Skills
Organiser, nommer, imbriquer et maintenir ses Skills Claude Code. Le guide pour passer de 3 Skills en vrac à une bibliothèque structurée.
L’AI.ssentiel, chaque vendredi
Les signaux IA qui comptent. Pour les pros qui utilisent déjà l'IA.