Les subagents Claude Code : forker plutôt que déléguer
Quand une tâche devient trop volumineuse pour tenir confortablement dans une seule conversation, deux mécanismes existent pour la déporter : lancer un agent frais, ou forker l'agent en cours. Ils se ressemblent en surface (les deux tournent en tâche de fond, les deux rendent un résultat), mais ils ne résolvent pas le même problème, et les confondre coûte du temps à reconstruire un contexte qui existait déjà.
Le problème que la délégation ne résout pas#
Un agent frais démarre à zéro : aucun historique de la conversation en cours, aucune décision déjà prise, aucun fichier déjà lu. Pour lui confier une tâche, il faut tout réexpliquer dans le prompt : ce qu'on essaie de faire, ce qui a déjà été tenté, pourquoi. Sur une tâche vraiment indépendante (chercher un package, résumer une doc externe), ce n'est pas un problème : l'agent frais n'a besoin de rien d'autre que la question. Sur une tâche qui prolonge un travail déjà engagé, chaque réexplication est du temps perdu à reconstruire ce que la conversation savait déjà.
Le fork : hériter du contexte, pas le reconstruire#
Un fork part du principe inverse : il hérite de l'intégralité de la conversation en cours au moment où il est lancé, fichiers déjà lus, décisions déjà prises, raisonnement déjà fait. Le prompt qu'on lui donne n'est plus une explication de situation, c'est une directive : quoi faire ensuite, pas ce qui s'est passé avant.
agent frais : contexte vide -> tout réexpliquer d'abord
fork : contexte hérité -> reprendre où le fil s'est arrêté
Pourquoi forker plutôt que continuer dans la conversation principale#
Si le fork hérite déjà de tout, la question devient : pourquoi ne pas simplement continuer dans la conversation principale ? La réponse tient à ce que produit une tâche exploratoire : des dizaines d'appels d'outils, des lectures de fichiers qui ne servent qu'à écarter une piste, des résultats intermédiaires qu'on n'a plus besoin de revoir une fois la synthèse faite. Faire cette exploration dans la conversation principale la remplit d'un bruit qui ne sert plus à rien après coup. La faire dans un fork isole ce bruit : seul le résultat final remonte, le raisonnement intermédiaire reste dans la tâche de fond.
Un exemple concret#
Comparer deux approches architecturales sur un même repo est une tâche exploratoire typique : beaucoup de lecture de fichiers, peu de contenu à garder au final. Lancer un fork pour cette exploration, en recevoir un verdict de quelques phrases, et garder la conversation principale focalisée sur la décision plutôt que sur le chemin qui y a mené : c'est exactement le genre de tâche où forker change la donne. Reposer la même question à un agent frais obligerait à réexpliquer le repo, la question précise, le contexte de la décision, avant même de commencer à chercher la réponse.
Ce que ça ne remplace pas#
Un fork n'est pas gratuit : il tourne en tâche de fond, avec son propre budget de tokens, et il ne remplace pas un agent frais quand la tâche est réellement indépendante du fil en cours. Lancer un fork pour une question qui n'a aucun rapport avec la conversation en cours revient à traîner tout un historique inutile derrière soi. Le critère qui tranche n'est pas la taille de la tâche, c'est sa dépendance au contexte déjà accumulé : dépendante, forker ; indépendante, agent frais.
