Le schéma qui fait rêver
Tu as sûrement vu passer le schéma : un agent principal découpe la tâche, il envoie des subagents travailler chacun sur un morceau, puis il recolle les résultats. Un agent pour le front, un pour le back, un pour les tests, un pour la doc. Sur un tableau blanc, c’est magnifique. On dirait une vraie équipe.
En pratique, c’est souvent moins bien qu’un seul agent qui fait tout, du début à la fin.
Le problème, c’est le contexte
Un subagent démarre avec une fenêtre de contexte presque vide. Il reçoit un résumé de ce qu’on attend de lui, pas tout ce qui s’est dit avant : les échanges avec toi, les fichiers déjà lus, les essais ratés, les petites décisions prises en route. Tout ça reste dans la tête de l’agent principal. Même si tu donnes la tâche complète à chaque subagent, ils ne voient pas ce que fait l’autre. Chacun fait des choix de style, de structure, de nommage, et ces choix se contredisent.
Même Anthropic le dit
Ce qui m’a fait écrire cet article, c’est qu’Anthropic vient de publier à peu près la même chose. Leur équipe a comparé plusieurs déploiements en entreprise : un seul agent avec des skills fait souvent mieux qu’une architecture à subagents, en qualité, et souvent pour moins cher et plus vite. Un client a mesuré un temps d’exécution à peu près deux fois plus court avec un seul agent.
Ils pointent aussi un travers que je trouve très drôle : chaque équipe de l’entreprise veut son propre subagent, et l’architecture finit par copier l’organigramme. Des centaines de subagents qui se chevauchent, un prompt système où chaque équipe a ajouté sa phrase, et des infos qui se perdent à chaque passage d’un agent à l’autre, comme au jeu du téléphone.
Leur solution, c’est la divulgation progressive. L’agent voit une courte description de chaque skill et de chaque outil, et ne charge le détail que quand il en a besoin. On évite de saturer le contexte, ce qui était la principale raison de découper le travail en subagents. Et les modèles récents tiennent beaucoup plus de choses dans une seule boucle qu’on ne le pensait.
Comment je travaille, moi
Un agent principal, une seule conversation par morceau de travail. Il lit le code, il le modifie, il lance les tests, il corrige. Tout ce qu’il apprend pendant ce morceau reste au même endroit. Quand je reviens sur un détail une demi-heure plus tard, il sait encore pourquoi on a fait tel choix, parce que c’est lui qui l’a fait.
Je n’ai pas de « subagent revieweur », pas de « subagent planificateur », pas de « subagent doc ». Je n’en ai jamais ressenti le besoin.
Une conversation par morceau
Ça ne veut pas dire qu’un projet entier tient dans le même chat. Quand je développe de gros projets, j’ouvre une nouvelle conversation pour chaque morceau. Je reste dedans jusqu’à ce que le morceau soit fini, puis je repars à neuf.
Si un morceau s’étire et que la conversation devient lourde, je demande à l’agent d’écrire un AVANCEMENT.md avec mon prompt de fichier d’avancement : ce qui est décidé, ce qui est réglé, ce qui reste en plan. La conversation suivante reprend là où l’autre s’est arrêtée, sans que j’aie à tout réexpliquer. Une fois la partie terminée, je supprime le fichier.
Mais la vraie recette, c’est d’avancer par petits bouts. Une petite tâche tient sans problème dans une seule conversation, et l’agent garde tout son contexte du début à la fin.
Mon seul cas : plusieurs projets en même temps
Là où les subagents me servent, c’est quand je travaille sur plusieurs projets à la fois. Je ne les configure pas et je ne leur donne pas de rôle. C’est mon agent principal qui décide de lui-même d’en créer un quand il doit envoyer quelqu’un travailler ailleurs pendant qu’il continue de son côté.
Et ça marche bien, justement parce que c’est le cas idéal : les tâches sont indépendantes, dans des dépôts différents, elles ont très peu de contexte en commun, et chacune rend un résultat court. Il n’y a pas deux agents qui prennent des décisions contradictoires sur le même code. C’est du vrai parallélisme, pas une équipe qui se marche dessus.
Quand ça vaut quand même le coup
Je ne dis pas que les subagents sont inutiles. Anthropic donne trois cas où ils ont leur place, et je suis plutôt d’accord :
- quand un seul agent perd en qualité de façon mesurable parce que son contexte déborde ;
- quand plusieurs tâches indépendantes peuvent tourner en parallèle, avec un contexte neuf qu’on jette une fois le travail fini ;
- quand un seul agent n’arrive plus à choisir les bons outils, ou que son prompt contient des consignes qui se contredisent.
Si tu dois découper, découpe par contexte et pas par métier : donne à chaque subagent un morceau qui a besoin de très peu du reste, et demande-lui un résultat compact. Une recherche isolée ou une vérification à l’aveugle, oui. « L’agent du front » et « l’agent du back » qui doivent se mettre d’accord, non.
En bref
Commence avec un seul agent, et avance par petits bouts pour qu’il garde tout son contexte. Ajoute un subagent quand tu as une raison mesurable, pas parce que le schéma est joli. Dans mon cas, cette raison n’existe que quand je jongle entre plusieurs projets, et même là, je laisse l’agent décider.
