Les subagents forkés dans Claude Code : pourquoi j’ai abandonné les subagents classiques

Les subagents forkés dans Claude Code : pourquoi j’ai abandonné les subagents classiques

Il était 1h47 du matin lorsque j’ai réalisé que je déboguais le mauvais problème depuis quatre heures.

J’étais plongé dans une longue session Claude Code — peut-être 180 000 tokens déjà consommés — en train de mettre en place un flux de paiement pour un SaaS client. J’ai lancé un sous-agent normal pour qu’il aille examiner un contrôleur spécifique et me dire si ma logique de validation appliquait bien ce que je pensais. Le sous-agent m’est revenu, sûr de lui. « Ça semble correct. La vérification à la ligne 47 empêche la condition de course que vous avez décrite. »

Sauf que ce n'était pas du tout le cas. Le garde qui m’inquiétait n’était même pas dans le contrôleur. Il se trouvait dans un middleware que le sous-agent n’avait jamais vu, car son résumé contextuel compressé avait écrasé ce middleware en une ligne disant, à peu près : « le projet utilise la pile de middlewares standard de Laravel ». La subtilité — le middleware personnalisé qui faisait toute la différence — s’était évaporée durant la compression.

C’est à ce moment-là que j’ai commencé à m’intéresser aux sous-agents forkés dans Claude Code. Et après deux semaines passées à revoir en profondeur ma façon de déléguer le travail dans de longues sessions, je ne compte pas revenir en arrière.

Cet article, c’est ce que j’aurais aimé qu’on me donne le premier jour où j’ai activé /fork. Ce n’est pas un communiqué officiel : c’est le retour d’expérience réel de mes tests sur du client, là où la taxe de compression fait vraiment mal, et où même les sous-agents forkés ne font pas toujours ce qu’il faudrait.

La taxe de compression dont personne ne parle

Voilà le problème avec les sous-agents classiques dans Claude Code : ils n’héritent pas de votre conversation. Ils héritent d’un résumé de votre conversation — une compression contextuelle intégrée signée Anthropic qui passe en revue tout ce que vous avez dit jusque-là, condensé au format le plus petit possible pour tenir dans la fenêtre de contexte du sous-agent, aux côtés de sa tâche.

Cette compression est toujours avec pertes. Inévitablement.

Le modèle mental que j’avais était erroné. Je m’imaginais qu’un sous-agent, c’était comme un collègue auquel je pourrais envoyer un Slack : « Salut, petite question, voilà sur quoi on bosse, va jeter un œil. » Mais ce que je faisais réellement, c’était plutôt remettre à ce collègue un rapport exécutif d’une page résumant une réunion de trois heures, et lui demander de statuer sur une décision qui dépendait d’un commentaire spécifique, lâché à la 47e minute.

Le résumé donne la forme. Il perd le détail. Or, pour le travail sur le code, le détail fait tout.

On voit cette réalité dans les issues GitHub maintenus par l’équipe Anthropic. Une requête active — issue #6825 — réclame une inheritance configurable du prompt système et de la mémoire pour les sous-agents, précisément parce que l’héritage par défaut est soit trop riche soit trop pauvre selon ce que vous faites. On retrouve une préoccupation parallèle dans l’issue #4908 à propos du passage de contexte scoped : c’est la même problématique, vue sous un autre angle. Les développeurs veulent le contrôle sur ce que le sous-agent est réellement capable de voir.

La tension est là : une fenêtre de contexte complète dégrade, avec le temps, la qualité de la prise de décision de Claude Code — dans mes propres tests, la précision chute au-delà de 200k tokens, et la documentation d’Anthropic sur la gestion du contexte pour la fenêtre 1M reconnaît cette limite. Une session principale doit donc rester légère. Mais un sous-agent privé de contexte prend de mauvaises décisions. La compression est le compromis, et tout compromis a un prix.

Les sous-agents forkés cassent ce compromis. Ils héritent de toute l’historique de conversation de la session principale, octet par octet, et partagent le prompt-cache avec cette session pour que vous ne payiez pas le prix fort sur les tokens. Voilà l’idée. Ma question, testée pendant deux semaines : est-ce que ça tient la route ?

Ce que fait réellement /fork (et pourquoi c’est différent)

La commande /fork crée un sous-agent qui démarre avec l’intégralité de l’historique de conversation chargé dans sa fenêtre de contexte. Pas un résumé. Pas un plan compressé. Les véritables messages, les véritables appels d’outils, les véritables lectures de fichiers — tout ce que vous avez accumulé jusqu’au moment où vous avez créé le fork.

Point crucial, le fork partage le cache de prompt avec la session principale. C’est bien plus important que ça n’en a l’air. Sans cache partagé, un sous-agent forké serait d’un coût prohibitif — vous paieriez deux fois pour les mêmes jetons hérités, une fois dans la session principale, une fois dans le fork. Le billet d’Anthropic sur l’ingénierie de contexte pour LMCache indique un taux de réutilisation des prompts de 92 % sur les phases Claude Code, et il est encore supérieur dans les boucles de sous-agents à la ReAct. Le forking exploite pleinement cette réutilisation.

Voici le profil de coût effectif. Si votre session principale est à 180k jetons et que vous forkez, le fork démarre lui aussi à 180k jetons. Mais comme ces jetons sont déjà mis en cache, la tarification réelle s’approche des taux de lecture du cache — environ 10 % du prix d’entrée habituel sur les offres Sonnet. Donc un fork qui coûterait nominalement le prix d’un prompt de 180k jetons vous revient en fait quasiment au prix d’un prompt de 18k jetons au premier tour, avant de se comporter comme une conversation normale par la suite.

C’est ce point qui change la donne sur le moment où déléguer.

Il y a un détail subtil mais important dans la conception du fork. Une optimisation récente de l’infrastructure interne du /fork écrit un pointeur, au lieu de la conversation parente complète, sur le disque pour chaque fork, avec hydratation lors de la lecture. C’est purement du back-end, pas du visible pour l’utilisateur, mais c’est la raison pour laquelle vous pouvez générer plusieurs forks sans saturer votre disque. Cette fonctionnalité a désormais une forme de production, ce n’est plus une expérimentation.

Pour activer les sous-agents forkés sur des builds externes, il suffit de définir la variable d’environnement CLAUDE_CODE_FORK_SUBAGENT=1 ou d’activer l’option correspondante dans votre settings.json. Une fois activée, /fork devient disponible comme commande slash dans n’importe quelle session, et vous pouvez vous adresser au fork généré directement pour les relances sans revenir au fil principal.

Le premier fork auquel j’ai vraiment fait confiance

Je vais être honnête — je ne faisais pas confiance à /fork dès le premier jour. J’avais été échaudé trop souvent par des fonctionnalités qui semblaient impeccables sur une landing page et qui s’effondraient face à du vrai code client, au point que mon réflexe était la méfiance.

Voilà ce qui m’a fait changer d’avis.

Je travaillais sur un projet de design system — un tableau de bord avec un board Kanban, une vue calendrier et un panneau de paramètres, tous nécessitant une cohérence visuelle parfaite. J'étais à environ 140k tokens dans une session où j’avais déjà pris une douzaine de décisions sur les composants, établi un système de couleurs, choisi une échelle typographique et écrit trois composants. J’avais besoin de générer deux variantes de carte Kanban — une plus dense, l’autre plus aérée — pour déterminer laquelle s’intégrait le mieux au reste du système.

Avec un sous-agent classique, cela aurait été un désastre. Le sous-agent aurait reçu un résumé compressé du genre « le projet utilise Tailwind, le design system est sombre avec des accents violets, la typo est Inter. » Ce n’est pas suffisant pour générer des variantes réellement cohérentes avec le reste du système. La moitié des subtilités — l’échelle d’espacement exacte que j’utilisais, les traitements précis des ombres, la gestion des tailles d’icônes — aurait été perdue.

J’ai donc préféré forker. Deux forks, en fait, lancés en parallèle. L’un avec le prompt « génère une variante de carte Kanban plus dense — conserve tous les aspects du système existant, mais compresse l’espacement vertical d’environ 25 % et réduis l’échelle typographique d’un cran. » Le second : « génère une variante de carte Kanban plus aérée — conserve le système, agrandis les paddings et donne plus de respiration à la carte. »

Les deux forks sont revenus avec des variantes qui avaient vraiment l’air de provenir du même design system, parce qu’ils avaient tout le système chargé, pas juste un résumé. L'ensemble. Les tokens de couleur que j’avais sélectionnés, les patterns de composants établis, la logique d’espacement peaufinée pendant deux heures : tout y était.

C’est à ce moment-là que j’ai arrêté de discuter avec cette fonctionnalité, et que j’ai commencé à l’utiliser.

Où le Forking Prend Tout Son Sens

Après deux semaines d’utilisation intensive, j’ai pu esquisser une taxonomie claire des contextes où les sous-agents forkés font réellement la différence, et où les sous-agents classiques restent l’outil adéquat. Voici les schémas qui se sont révélés payants.

Parallélisation des Travaux de Conception

C’est le cas d’usage qui m’a convaincu. Quand vous prenez des décisions visuelles ou structurelles qui s’appuient sur un système déjà élaboré au fil de la session, perdre ce système à cause de la compression plombe la qualité des livrables. En forçant, on le préserve.

J’ai maintenant l’habitude de lancer deux ou trois forks en parallèle dès que j’ai besoin d’évaluer des variantes — designs de composants, structures d’API, schémas de base de données, alternatives de textes. Chaque fork dispose du contexte complet ainsi que d’une consigne spécifique pour la variation. Je compare ensuite les résultats côte à côte. La comparaison n’a de valeur que parce que chaque fork dispose de la même base de départ.

Consolidation et Récapitulatif de la Mémoire

Si vous avez déjà utilisé la commande /bytheway de Claude Code, ou les fonctions de consolidation de la mémoire, vous manipulez déjà des sous-agents forkés — ils opèrent en arrière-plan. Pour que ces tâches aient de la valeur, il leur faut l’intégralité de la conversation. Un récap généré à partir d’un résumé compressé n’est en fait qu’un résumé de résumé, équivalent à une photocopie d’une photocopie.

En comprenant ce qui se passe dans les coulisses, j’use aujourd’hui de ces fonctions de façon bien plus stratégique. Dès que je sens que j’approche d’une limite de contexte lors d’une session que je veux préserver, je déclenche un /bytheway pour consigner en mémoire les décisions importantes avant de compacter ou de redémarrer.

Vérification Parallèle Multi-Outillage

J’ai développé une routine qui s’est avérée très utile pour moi. Quand je viens de générer un bloc de code non trivial, je crée immédiatement deux forks :

1. Fork A : « Génère un diagramme Mermaid illustrant comment les modifications du code traversent le cycle de requêtes. Mets en évidence tout ce qui a changé dans une couleur différente. »

2. Fork B : « Fais une recherche web pour vérifier que les patterns API utilisés dans ces modifications sont réellement considérés comme les meilleures pratiques sur [framework] en 2026. Signale tout ce qui paraît obsolète. »

Les deux forks bénéficient du contexte complet de la session ; ils savent donc exactement de quel code il s’agit. Le fork diagramme me fournit une vérification visuelle. Le fork de vérification détecte les cas où ma mémoire musculaire aurait répliqué un motif idiomatique il y a trois ans, mais dépassé aujourd’hui. J’obtiens ainsi deux angles indépendants sur la même modification, générés en parallèle, sans polluer la session principale avec aucune de ces tâches.

Contention des Dérives

Cet usage est plus discret mais crucial pour la gestion mentale. Parfois, j’ai une question de côté, intéressante mais hors sujet. « Attends — si on avait choisi un autre pattern ORM ici, tout ce flow ne serait-il pas plus simple ? » Normalement, ce genre de parenthèse interrompt mon fil principal vingt minutes, ou bien passe à la trappe parce que je n’ai pas envie de me disperser.

Les sous-agents forkés apportent une solution élégante. On fork, on pose la question tangentielle, on explore le contre-factuel. Si la réponse est intéressante, je ramène l’insight dans le fil principal. Si c’est une impasse, /rewind et le fork disparaît. La conversation principale ne saura jamais ce qui s’est passé.

Cela change ma façon d’utiliser Claude Code. Ce n’est pas qu’une fonctionnalité : je creuse beaucoup plus de questions annexes depuis que le coût de l’exploration est tombé de « risque de digression » à « tangent gratuit, jetable si inutile ».

Quand le fork n’est pas la bonne option

Le fork n’est pas toujours le bon choix. Il y a un véritable piège à croire que plus de contexte est toujours mieux, et je l’ai rencontré dès la deuxième semaine d’utilisation de la fonctionnalité.

Le piège, c’est le biais. Un sous-agent forké a vu tout ce que vous avez fait durant la session — y compris le code que vous venez d’écrire, les choix d’architecture que vous avez posés, les bibliothèques que vous avez sélectionnées. Quand vous demandez à un fork de relire ce code, vous n’obtenez pas un regard neuf. Vous retrouvez simplement votre propre point de vue, exécuté en tant que nouveau processus. Le fork se souvient pourquoi vous avez fait chaque choix, et le biais de confirmation s’installe.

Pour les revues de code, cela a une vraie importance. Une bonne review repère ce à quoi vous n’avez pas pensé, ce qui signifie qu’elle doit venir d’un esprit qui n’a pas suivi les mêmes raisonnements que vous.

J’ai testé cela directement. J’ai écrit un lot de code lié à l’authentification et j’ai demandé à un sous-agent forké de le relire. Le fork m’a remonté des suggestions cosmétiques — nommage de variables, modification d’une docstring, léger refactoring. Ensuite, j’ai demandé à un sous-agent normal (contexte vierge, sans historique) d’examiner le même code. Le sous-agent normal a immédiatement identifié que je ne comparais pas un token en temps constant, un vrai défaut de sécurité que le fork avait laissé passer parce que, dans son contexte, le code « semblait cohérent avec les patterns établis ».

Voilà la règle empirique à laquelle je me tiens désormais :

• Utilisez le fork lorsque le contexte est un atout. Cohérence de conception, consolidation de mémoire, workflows multi-étapes qui nécessitent de l’historique, exploration de tangentes.
• N’utilisez pas le fork lorsque le contexte est un handicap. Revues de code, audits de sécurité, tests adverses, toute situation où un regard neuf et des hypothèses vierges sont nécessaires.

Les sous-agents normaux ont toujours leur place dans le workflow. Leur rôle est simplement différent.

La comparaison entre Forked et Normaux

Voici le tableau comparatif que j’aurais aimé avoir dès le premier jour, condensé pour être vraiment utile lors d’une prise de décision rapide.

La ligne déterminante est celle des « Idéal pour ». N’utilisez pas /fork simplement parce que c’est une nouveauté. Utilisez-le quand la tâche bénéficie vraiment de la continuité contextuelle, sinon, vous payez une taxe de biais sans retour sur investissement.

L’activation et l’utilisation concrète

Si vous n’avez pas encore activé les sous-agents forkés, voici le chemin le plus court.

Ouvrez votre settings.json de Claude Code — généralement situé dans ~/.claude/settings.json pour la configuration utilisateur, ou dans .claude/settings.json à la racine de votre projet. Soit vous définissez la variable d’environnement CLAUDE_CODE_FORK_SUBAGENT=1 dans le profil de votre shell, soit vous ajoutez le drapeau équivalent dans votre JSON de paramètres. Le nom de la clé exacte a changé entre différentes versions, donc consultez les notes de version actuelles de Claude Code si la variable d’environnement seule ne suffit pas à activer la fonction.

Une fois activée, la commande /fork devient disponible comme commande-slash dans n’importe quelle session. Saisissez-la, ajoutez votre prompt, et vous obtenez un fork. Vous pouvez vous adresser directement au fork pour les tours suivants en préfixant vos messages, et vous pouvez utiliser /rewind pour supprimer un fork qui n’a pas abouti.

Quelques conseils opérationnels, issus de deux semaines d’usage intensif :

Forkez de façon intentionnelle, pas systématique. La première semaine, je forkais tout. Erreur. Le forkage implique un biais implicite lors de tâches de type revue, et ajoute de la charge mentale car vous suivez alors deux ou trois fils à la fois. J’ai trouvé mon rythme à environ trois ou quatre forks par session sérieuse — aux moments où la tâche bénéficie vraiment du contexte complet.

Utilisez des forks parallèles pour converger. En cas d’hésitation devant une décision, faites naître deux forks avec des hypothèses contraires et comparez. Je l’ai fait récemment pour trancher entre composants serveur ou client sur une page Next.js. Deux forks, deux raisonnements, résultats côte à côte. La réponse était évidente après cinq minutes de lecture croisée.

Gardez un œil sur l’usage de /rewind. /rewind est la sortie de secours qui rend l’exploration peu coûteuse. Si vous ne l’utilisez pas régulièrement, c’est probablement que vous ne forkez pas assez pour explorer. Les forks qui s’avèrent être des impasses doivent être remontés, pas regrettés.

Combinez des forks avec des sous-agents normaux pour des vérifications adversariales. Après qu’un fork ait produit une solution, soumettez le même problème à un sous-agent normal, sans contexte. En cas d’accord, votre niveau de confiance augmente. S’ils divergent, cette divergence est une information précieuse : creusez pour comprendre ce que le regard neuf aperçoit, passé sous silence par le fork chargé de contexte.

Ce que j'ai mal fait la première semaine

Je veux être transparent sur les erreurs commises, car la fonctionnalité est suffisamment puissante pour donner envie de la survendre.

Première erreur : j’ai trop forké. J’ai forké pour les revues de code, ce qui était absurde. Le fork, qui se souvenait de chaque morceau de code que je venais d’écrire, ne faisait que valider mécaniquement mon travail. La présentation de Boris Cherny sur le workflow Claude Code souligne que le contexte neuf est parfois tout l’intérêt d’un sous-agent, et j’ai négligé ce conseil dès le départ.

Deuxième erreur : je n’avais pas réalisé à quel point le préchauffage du cache comptait. Le premier fork d’une session paie réellement le coût de la mise en cache du contexte hérité. Les forks suivants coûtent peu. Si vous faites un seul fork pour une petite tâche, vous n’amortissez pas vraiment le cache comme la fonctionnalité l’exige. Regroupez vos forks quand c’est possible — si vous savez que vous allez devoir explorer trois pistes en parallèle, lancez vos forks les uns à la suite des autres.

Troisième erreur : je me suis laissé aller sur la longueur des sessions. Les sous-agents forkés ne résolvent pas le problème de fond : une session principale de 400k tokens reste une session au raisonnement embrumé. Les forks déplacent seulement une partie du travail hors de la session principale. Si votre session principale est surchargée, les forks issus de cette session seront eux-mêmes volumineux. À un moment, il faut toujours compacter, établir un checkpoint ou repartir de zéro. Mon analyse détaillée sur la gestion du contexte 1M dans Claude Code détaille davantage l’aspect élagage.

Cette fonctionnalité n’excuse pas une mauvaise hygiène de session. Elle récompense une bonne hygiène : la délégation devient réellement efficace dans des sessions bien gérées.

Le schéma qui s’est imposé

Parmi tous les workflows que j’ai testés, un seul s’est imposé et il est devenu réflexe.

Quand je suis plongé dans un développement et que je dois prendre une décision structurelle — « dois-je utiliser cette bibliothèque ou coder la mienne ? », « cette API doit-elle être REST ou autre chose ? », « cette architecture de composant est-elle généralisable ou suis-je en train de m’enfermer ? » — je fais un double fork. Deux forks en parallèle, chacun défendant une option différente, chacun exposant ses arguments en s’appuyant sur tout le contexte de la session.

Cinq à dix minutes plus tard, j’ai deux courtes notes de synthèse. Je lis les deux. La bonne réponse saute presque toujours aux yeux, et surtout, le raisonnement saute aux yeux. Je n’obtiens pas juste une recommandation — j’ai le cas pour chaque option, évalué selon le contexte spécifique de ce que j’ai déjà construit.

Cela a remplacé mon ancienne habitude de solliciter un ami développeur pour réfléchir à mes choix. L’ami était parfois indisponible, ignorait souvent le contexte du projet, avait ses propres biais. Les deux forks sont toujours disponibles, connaissent exactement le contexte du projet puisqu’ils sont ce contexte, et leurs biais sont transparents puisque c’est moi qui ai rédigé les prompts.

Ce n’est pas un changement anodin. C’est un vrai tournant dans ma façon de prendre des décisions techniques sur des projets solo.

Le test que je lancerais ce soir

Si vous avez lu jusqu’ici et que vous n’avez pas encore activé /fork, voici ce que je ferais avant d’aller me coucher.

Ouvrez les paramètres de Claude Code, activez CLAUDE_CODE_FORK_SUBAGENT=1, puis relancez la session. Choisissez un projet sur lequel vous avez travaillé quelques heures aujourd’hui — idéalement avec plus de 80k tokens de contexte. Pensez à une question qui vous tracasse à propos de ce projet, quelque chose à laquelle vous n’avez pas répondu parce que cela vous semblait trop hors-sujet.

Tapez /fork, posez la question, et regardez la réponse.

Comparez ensuite ce que vous avez obtenu à ce qu’un subagent normal aurait rendu — vous pouvez en fait lancer la même invite via un subagent normal juste après, et comparer les deux résultats côte à côte. Remarquez ce que le fork a capté que le subagent classique a laissé passer. Notez aussi là où la perspective neuve du subagent normal s’est révélée plus précieuse que la mémoire longue du fork.

Après votre deuxième ou troisième fork, vous saurez instinctivement dans quels cas cette fonctionnalité vaut son pesant d’or, et dans quels cas non. C’est précisément cet instinct que vous êtes en train d’aiguiser. La commande est simple. La vraie compétence, c’est de juger quand l’utiliser.

Travaillons ensemble

Vous cherchez à développer des systèmes d’IA, automatiser vos workflows ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous accompagner.

• Fiverr (créations & intégrations sur mesure) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions pour entreprises) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io