Sous-agents en fan-out : paralléliser sans exploser le contexte

Ton agent tourne depuis quarante minutes. Il a lu trente fichiers, lancé douze commandes, corrigé trois erreurs. Et depuis dix minutes, il tourne en rond : il redemande des choses qu’il a déjà vues, il oublie une consigne donnée au début, il refait une modification qu’il avait déjà faite.

Ce n’est pas le modèle qui a baissé de niveau. C’est son contexte qui est devenu un dépotoir, et un contexte pollué produit des réponses dégradées, quelle que soit la qualité du modèle.

TL;DR

• Le contexte est une ressource critique, pas un réservoir infini. Ce qu’il contient détermine la qualité de chaque réponse.
• Le fan-out consiste à confier des sous-tâches indépendantes à des sous-agents, chacun avec son propre contexte propre. L’agent principal ne reçoit que les conclusions.
• La condition d’efficacité, c’est l’indépendance : si les sous-tâches doivent se coordonner, la délégation coûte plus qu’elle ne rapporte.
• Nettoyer plutôt que compacter : quand une tâche est terminée, repartir d’un contexte vide avec un état écrit vaut mieux qu’un résumé de l’historique.

Pourquoi le contexte se dégrade

Trois phénomènes distincts, qui s’additionnent.

La dilution des instructions. Une règle donnée au premier tour concurrence, au quarantième, des milliers de tokens de code et de sorties de commandes. Elle n’a pas disparu, mais son poids relatif s’est effondré.

L’accumulation d’informations mortes. Le contenu d’un fichier lu il y a trente minutes et modifié depuis est toujours dans le contexte. L’agent peut s’y référer comme s’il était à jour. C’est une source d’erreur silencieuse, et particulièrement vicieuse.

Le coût. À chaque appel, tout le contexte est renvoyé et refacturé. Un agent qui accumule paie de plus en plus cher pour un résultat de moins en moins bon, le mécanisme est détaillé dans l’article sur le coût réel de l’IA.

Le point clé : la qualité d’un agent ne dépend pas seulement du modèle, mais de ce qu’il a sous les yeux au moment de répondre. Gérer le contexte est un travail d’ingénierie à part entière.

Le fan-out : déléguer pour préserver le contexte principal

Le principe est simple : plutôt que de tout traiter dans une seule conversation, l’agent principal confie des sous-tâches indépendantes à des sous-agents. Chacun démarre avec un contexte vierge, fait son travail, et ne renvoie que sa conclusion.

L’agent principal reçoit trois lignes de synthèse là où il aurait absorbé quinze fichiers.

Le bénéfice réel n’est pas la vitesse, c’est la propreté. Le parallélisme est un bonus appréciable ; l’essentiel est que le contexte principal reste concentré sur la décision, pas sur l’exploration.

Les principes d’orchestration, de découpage et de remontée de résultats sont formalisés dans la documentation Anthropic sur l’orchestration multi-agents.

Quand déléguer, et quand surtout pas

C’est là que se joue la différence entre un gain réel et une usine à gaz. Chaque délégation a un coût fixe : le sous-agent doit être briefé, il doit redécouvrir son terrain, et son rapport doit être relu.

Délègue quand :

• Les sous-tâches sont réellement indépendantes, explorer cinq modules, vérifier dix fichiers, tester trois hypothèses sans lien entre elles.
• La tâche est coûteuse en lecture mais produit une conclusion courte. C’est le cas idéal : le sous-agent absorbe le volume, l’agent principal reçoit la réponse.
• Le résultat est vérifiable indépendamment, sans avoir à reconstituer le raisonnement.

Ne délègue pas quand :

• La tâche se règle en quelques opérations. Le briefing coûtera plus que le travail.
• Les sous-tâches doivent se coordonner. Deux sous-agents qui modifient des zones liées produisent des conflits que personne ne voit venir.
• Le sous-agent aurait besoin de tout le contexte de l’agent principal pour travailler. Tu n’as alors rien économisé, tu as juste ajouté un intermédiaire.

Le test rapide : si tu peux écrire le brief du sous-agent en cinq lignes et qu’il n’a besoin de rien d’autre, la délégation est pertinente. Si le brief exige de recopier tout l’historique, elle ne l’est pas.

Ce qui rend le fan-out possible : des frontières dans le code

Faire travailler plusieurs agents en parallèle sur une base non découpée est une garantie de collision. Deux agents modifient le même fichier, l’un écrase l’autre, et le résultat final ne correspond à aucune des deux intentions.

La condition préalable est structurelle : une architecture modulaire en silos, où chaque module possède ses données et expose un contrat. Un agent par module, des périmètres qui ne se recouvrent pas, aucune collision possible.

L’architecture n’est pas un prérequis esthétique du fan-out : c’est ce qui le rend praticable.

Nettoyer plutôt que compacter

Quand le contexte devient trop lourd, deux stratégies s’offrent à toi, et elles ne se valent pas.

Compacter : produire un résumé de la conversation et continuer avec ce résumé. Pratique, mais imparfait : le résumé est lui-même généré par un modèle, il perd des détails, et personne ne sait lesquels avant qu’ils ne manquent.

Nettoyer : repartir d’un contexte vide, avec uniquement l’état utile, écrit dans un fichier. C’est plus brutal et beaucoup plus fiable.

Le critère de choix :

Situation	Stratégie
Milieu d’une tâche, le fil du raisonnement compte	Compacter
Tâche terminée, on passe à la suivante	Nettoyer
L’agent commence à dériver ou à se répéter	Nettoyer immédiatement
L’historique contient surtout des explorations infructueuses	Nettoyer

Ce qui rend le nettoyage possible, c’est l’écrit. Si l’état d’avancement, les décisions prises et les points en suspens sont dans un fichier du projet, repartir de zéro ne coûte rien, l’agent relit le fichier et sait où il en est. Si tout est uniquement dans la conversation, nettoyer signifie perdre.

La règle qui en découle : tout ce qui compte doit finir dans un fichier, pas dans un message. C’est aussi ce qui permet de reprendre le travail le lendemain, ou de le confier à quelqu’un d’autre.

L’interruption qui ne casse pas le travail en cours

Détail pratique, effet disproportionné : quand tu veux poser une question à un agent en plein travail, tu as deux mauvaises options, l’interrompre et perdre son fil, ou attendre.

Une troisième existe : poser la question en marge du travail en cours, via une commande dédiée, /btw dans l’outil utilisé en live. L’agent répond, puis reprend là où il en était, sans que la question ne pollue sa tâche.

L’intérêt dépasse le confort. Sans ce mécanisme, on prend l’habitude de ne pas poser de questions pour ne pas casser le flux, et on laisse l’agent partir dans une mauvaise direction qu’on aurait pu corriger en dix secondes.

Que doit contenir un bon brief de sous-agent

Un sous-agent démarre sans mémoire du projet. Son brief détermine à 90 % la qualité de ce qu’il renverra. Cinq éléments, et rien de plus :

1. L’objectif, en une phrase. Pas le contexte du projet : ce qu’il doit produire.
2. Le périmètre exact. Quels fichiers, quel module, quelles limites. Ce point évite les collisions.
3. Le format de retour attendu. « Une liste de fichiers concernés avec, pour chacun, une ligne d’explication » est exploitable ; « un rapport » ne l’est pas.
4. Ce qu’il ne doit pas faire. Typiquement : ne rien modifier s’il s’agit d’une exploration.
5. Le critère d’arrêt. Quand considère-t-il avoir terminé ?

Ces cinq points sont le contrat du sous-agent, exactement au même sens que le contrat d’interface d’un module. Cette logique de rôles définis et de responsabilités bornées est le socle d’une organisation d’agents structurée par des boucles ITIL.

Checklist : mettre en place un fan-out utilisable

• Le code est découpé en modules aux frontières explicites.
• Chaque sous-tâche déléguée est réellement indépendante des autres.
• Le brief de chaque sous-agent tient en cinq lignes.
• Le format de retour attendu est spécifié, pas laissé libre.
• Deux sous-agents ne peuvent pas modifier les mêmes fichiers.
• L’état d’avancement du travail est écrit dans un fichier, pas seulement dans la conversation.
• Je nettoie le contexte entre deux tâches distinctes plutôt que de compacter.
• Je dispose d’un moyen de poser une question sans interrompre le travail en cours.

FAQ

Combien de sous-agents lancer en parallèle ?

Le nombre n’est pas la bonne variable : ce qui compte est le nombre de sous-tâches réellement indépendantes. S’il y en a trois, lance-en trois. S’il n’y en a qu’une, la délégation n’apporte rien. Multiplier les sous-agents sur une tâche qui n’était pas divisible produit des rapports redondants que l’agent principal doit ensuite réconcilier, tu as remplacé un problème de contexte par un problème de synthèse.

Un sous-agent peut-il modifier du code, ou seulement explorer ?

Les deux, mais l’exploration est le cas le plus rentable : elle consomme beaucoup de lecture et produit une conclusion courte, ce qui est exactement le profil idéal. Pour la modification, la condition est stricte : des périmètres qui ne se recouvrent pas, garantis par l’architecture. Sans cette garantie, deux sous-agents qui écrivent en parallèle finiront par se contredire.

Comment savoir qu’il est temps de nettoyer le contexte ?

Trois signaux fiables : l’agent redemande une information qu’il a déjà obtenue, il refait une modification déjà effectuée, ou il oublie une consigne donnée en début de session. Dès qu’un de ces signes apparaît, le nettoyage est déjà en retard. Le mieux est de ne pas attendre le symptôme et de nettoyer systématiquement au changement de tâche.

Le fan-out coûte-t-il plus cher qu’une session unique ?

En volume de tokens, souvent oui : chaque sous-agent recharge son propre contexte de départ. Mais la comparaison honnête ne se fait pas à travail égal : une session unique très longue coûte cher elle aussi, puisque tout l’historique est refacturé à chaque tour, et elle produit un résultat de moins bonne qualité. Le fan-out est généralement gagnant dès que la tâche implique beaucoup de lecture pour une conclusion courte.

Conclusion

Un agent efficace n’est pas un agent qui pense fort, c’est un agent qui regarde au bon endroit. Tout ce qui pollue son contexte dégrade directement ce qu’il produit.

Le fan-out est le principal outil pour tenir cette discipline : les sous-agents absorbent le volume, l’agent principal garde la vue d’ensemble. Et il ne fonctionne qu’à deux conditions, des frontières nettes dans le code, et un état écrit ailleurs que dans la conversation.

La prochaine fois que ton agent commence à se répéter, ne relance pas la même demande : nettoie, écris l’état dans un fichier, et repars propre. Le gain est immédiat.

Ces méthodes sont montrées en direct dans les lives Team Studio, notamment sur le travail en sous-agents parallèles et l’architecture modulaire associée.