Imaginez Claude Code comme un consultant disposant d’une petite équipe. Vous ne parlez qu’au consultant. Il confie des tâches partielles à des spécialistes et vous transmet le résultat à la fin.
C’est exactement cela, les sub-agents. Pas de battage, mais un outil pratique de répartition du travail. Cet article montre quand ils valent la peine — et quand ils ne la valent pas.
Ce qu’est un sub-agent
La session principale est l’orchestrateur. C’est l’instance avec laquelle vous parlez. Elle lance des sub-agents autonomes et leur attribue des tâches.
Chaque sub-agent travaille dans son propre contexte, vierge. Il ne renvoie qu’un résultat compact. Les sub-agents parlent à la session principale, jamais entre eux.
Pourquoi ils valent la peine
Quatre raisons rendent les sub-agents utiles.
- Un contexte propre. La recherche, les longs journaux et les gros rapports restent hors du chat principal.
- Le travail en parallèle. De nombreuses tâches indépendantes s’exécutent en même temps plutôt qu’à la suite.
- Des modèles peu coûteux. Un petit modèle se charge du travail de fourmi, un modèle puissant assure la direction.
- Des relectures honnêtes. Un agent nouveau n’est pas conditionné à vous donner raison.
Intégrés ou construits soi-même
Claude Code fournit des sub-agents génériques. À côté de cela, vous construisez vos propres agents spécialisés. Un sub-agent n’est rien d’autre qu’un fichier Markdown.
En haut se trouve le frontmatter YAML : nom, description, modèle et outils autorisés. La description est le levier le plus important. C’est elle qui décide si l’agent correspond à la tâche.
Une erreur fréquente en pratique est un guillemet oublié. La structure se casse alors, et l’agent ne démarre jamais.
Projet ou global
Les agents liés au projet se trouvent dans le dépôt et voyagent avec lui. Les agents globaux se trouvent dans votre dossier utilisateur et n’appartiennent qu’à vous.
Règle empirique : si l’équipe doit s’en servir, cela a sa place dans le projet. Le déplacement est trivial, puisqu’il ne s’agit que d’un fichier.
Quand un sub-agent — et quand pas
Toutes les tâches n’ont pas besoin d’un sub-agent. Trop de sub-agents mènent souvent à de moins bons résultats. Une question simple aide.
Est-ce que cela va déverser d’un coup une montagne d’informations dans mon chat, que je ne relirai jamais ? Si oui, déléguez. Si non, cela reste dans la session principale.
Utilisez des sub-agents lorsque de nombreux fichiers doivent être lus, lorsque des tâches s’exécutent en parallèle ou lorsque vous voulez une relecture impartiale.
Renoncez-y pour de petites modifications, pour des étapes qui dépendent les unes des autres, ou lorsque l’agent devrait poser une question en retour.
Workflows dynamiques et « ultra code »
Depuis Opus 4.8, il existe des workflows dynamiques. La session principale lance alors automatiquement de nombreux sub-agents en parallèle. C’est puissant, mais cela consomme vite votre limite de session.
C’est pourquoi le mot déclencheur est passé de « workflow » à « ultra code ». Ainsi, aucun gros workflow ne démarre par inadvertance. Utilisez cet outil de manière délibérée.
Prendre les autorisations au sérieux
Si un agent peut lire ou modifier des données, vous devez partir du principe qu’il le fera un jour. N’autorisez donc que les outils dont il a réellement besoin.
Pour les agents de recherche et de vérification, cela veut généralement dire : lecture seule. Pour des fichiers d’agents d’origine externe, vérifiez au préalable les injections de prompt possibles.
Ma promesse
Les sub-agents ne sont pas une fin en soi. Ce sont des outils de répartition du travail. Le gain, c’est moins de bruit dans le chat, des coûts plus bas et un regard impartial sur votre travail.
Ma promesse : je ne recommande les sub-agents que là où ils aident de façon mesurable. L’automatisation, c’est plus que le battage autour de l’IA.
Remarque : cet article résume les idées principales d’une vidéo YouTube en anglais consacrée aux sub-agents de Claude Code et les replace dans une perspective de conseil. Source : youtube.com/watch?v=e18sdZLwP7o.