Déléguer à des sous-agents
Quand un sous-agent fait gagner du temps, quand il en fait perdre, et comment en écrire un qui rend une réponse utilisable.
Un sous-agent est une seconde instance de Claude, lancée avec sa propre fenêtre de contexte, à qui on confie une tâche précise et qui rend un résultat. Le bénéfice n'est pas la vitesse : c'est que le bruit de sa recherche ne remonte pas dans ta conversation.
Bien utilisé, ça change tout sur les gros dépôts. Mal utilisé, ça ajoute une couche d'indirection qui coûte plus qu'elle ne rapporte.
Quand ça vaut le coup
| Situation | Sous-agent ? |
|---|---|
| « Où est géré l'envoi d'e-mails dans ce dépôt ? » | Oui. Il va lire vingt fichiers, tu veux la réponse, pas les vingt fichiers |
| Trois tâches indépendantes à faire | Oui. Elles avancent en parallèle |
| « Renomme cette variable » | Non. Le coût de lancement dépasse la tâche |
| « Corrige ce bug » alors que tu as déjà tout le contexte | Non. Tu perdrais ce contexte |
| Auditer une dimension précise sur tout le code | Oui. Un agent par dimension, résultats agrégés |
La règle courte : un sous-agent sert quand la recherche est plus volumineuse que la réponse.
Le contexte ne se partage pas
Le sous-agent ne voit rien de ta conversation. Tout ce dont il a besoin doit tenir dans la consigne que tu lui donnes. C'est la première cause de résultat décevant.
Avant de commencer
- Claude Code installé
- Un dépôt assez gros pour que la recherche coûte quelque chose
- Un quart d'heure
1Déléguer une exploration
Le cas le plus rentable, et celui qui ne demande aucune configuration :
Cherche dans tout le depot comment sont envoyes les e-mails transactionnels :
quel service, quels modeles, ou sont definis les destinataires. Rends-moi
seulement la synthese avec les chemins de fichiers, pas le contenu des fichiers.
La dernière phrase est celle qui compte. Sans elle, l'agent te recrache le code qu'il a lu et tu perds le bénéfice.
2Paralléliser ce qui est indépendant
Deux tâches sont parallélisables si aucune n'a besoin du résultat de l'autre, et si elles ne touchent pas aux mêmes fichiers.
Trois taches independantes, lance-les en parallele :
1. Liste les endpoints sans test d'integration.
2. Trouve les dependances non utilisees dans package.json.
3. Repere les composants qui ne sont importes nulle part.
Rends-moi trois listes separees.
Si elles écrivent toutes dans le code au même endroit, ne parallélise pas : tu récolteras des conflits.
3Écrire un sous-agent réutilisable
Quand la même délégation revient, elle mérite un fichier. Dans
.claude/agents/relecteur-securite.md :
---
name: relecteur-securite
description: Relit un diff a la recherche de failles d'injection, de secrets en dur et de controles d'acces manquants. A utiliser avant d'ouvrir une pull request.
tools: Read, Grep, Glob
---
Tu relis du code avec un seul objectif : trouver ce qui peut etre exploite.
Procedure :
1. Lire le diff en entier avant de conclure.
2. Chercher, dans cet ordre : entrees non validees qui atteignent une requete
ou un shell, secrets en dur, controle d'acces absent sur une route.
3. Ignorer le style, la performance et la lisibilite.
Rends une liste, du plus grave au moins grave. Pour chaque point : fichier,
ligne, ce qu'un attaquant en ferait, et la correction en une phrase.
Si tu ne trouves rien, dis-le franchement au lieu d'inventer.
Trois choses rendent ce fichier utile :
toolslimité en lecture. Un relecteur qui peut écrire finit par « corriger » au lieu de signaler.- Un périmètre exclusif. Dire ce qu'il doit ignorer évite les rapports fourre-tout.
- Un format de sortie imposé. Sans ça, chaque exécution rend une forme différente.
4Demander des faits, pas des impressions
Un sous-agent qui rend « le code est globalement propre » a coûté pour rien. Impose la forme de la réponse dans la consigne :
Rends un tableau : fichier, ligne, probleme, gravite (haute/moyenne/basse).
Pas de paragraphe d'introduction ni de conclusion.
Si un point n'est pas certain, marque-le comme a verifier plutot que de l'affirmer.
La dernière phrase compte
Autoriser explicitement le doute réduit beaucoup les résultats inventés. Un agent qui n'a pas le droit de dire « je n'ai rien trouvé » trouvera quelque chose.
Ce qui fait rater une délégation
- Consigne trop courte. L'agent ne voit pas ta conversation. « Continue ce qu'on faisait » ne veut rien dire pour lui.
- Tâche trop vague. « Améliore le code » produit un résultat inutilisable. « Trouve les fonctions de plus de 80 lignes dans src/api » produit une liste.
- Écriture en parallèle. Deux agents qui modifient le même fichier se marchent dessus. Parallélise la lecture, sérialise l'écriture.
- Trop d'agents. Au-delà de quelques agents simultanés, tu passes plus de temps à agréger qu'à avancer.
Quelques prompts pour aller plus loin
| Objectif | Prompt à adapter |
|---|---|
| Cartographier | Explore [DOSSIER] et rends-moi une carte : quels modules, quelles dependances entre eux, ou entre une requete. Chemins seulement. |
| Auditer en parallèle | Lance un agent par dimension : securite, performance, tests manquants. Un tableau chacun, puis une synthese des recouvrements. |
| Vérifier un doute | Verifie de facon independante l'affirmation suivante en lisant le code : [AFFIRMATION]. Essaie de la refuter. |
| Créer un agent | Transforme les consignes que je te repete a chaque relecture en un sous-agent dans .claude/agents/. |
Tu as d’autres ressources comme ça ?
Ce que tu viens de lire est entièrement gratuit. Une nouvelle ressource part chaque semaine dans la newsletter : guides, modèles à copier et liens triés, sans compte à créer.
Me contacter
Une question, un projet, une envie de collaborer ? Écris-moi.
Cette page est en accès libre, n’hésite pas à la partager.