Déléguer le bruit & Le flux d'information

Déléguer le travail lourd et bruyant : scraping et documentation en parallèle

L’idée en une phrase

Le scraping web et la lecture de documentation sont le type même du travail lourd et bruyant — beaucoup de tokens bruts, peu réutilisés. Les confier à plusieurs sous-agents lancés en parallèle, chacun dans sa fenêtre isolée (chapitre 6), est un Delegate qui déporte tout ce bruit hors de l’agent principal et ramène le temps d’attente à celui du plus lent des workers, pas à leur somme.

Analogie : plusieurs sondes d’exploration envoyées simultanément sur des terrains différents. Chacune analyse la roche sur place, accumule ses relevés, puis ne transmet qu’un bref rapport radio — jamais les échantillons eux-mêmes, qui restent au sol. On couvre quatre terrains dans le temps d’une seule mission, et la salle de contrôle ne reçoit que quatre synthèses, pas quatre cargaisons de cailloux.

Points clés

• Le scraping et la doc sont massivement bruyants. Une page de documentation ou une page web récupérée via WebFetch pèse couramment ~5 000 à 30 000 tokens de contenu converti ; quelques sources, et l’agent principal a englouti des dizaines de milliers de tokens dont il ne réutilisera qu’une fraction.
• Une fenêtre isolée par source. Confier chaque source — une librairie, une page, une section — à son sous-agent : le HTML ou le Markdown brut vit et meurt dans sa fenêtre ; seule une fiche distillée revient. C’est le researcher du chapitre 6, spécialisé sur le web.
• Le parallélisme est natif. L’agent principal peut lancer plusieurs sous-agents de front ; Claude Code les exécute en parallèle, les tâches au-delà de la limite de concurrence patientant en file. Quatre sources indépendantes traitées de front finissent en ~temps de la plus lente, pas en somme des quatre.
• Les bons outils, en lecture seule. Un sous-agent de veille reçoit WebFetch, WebSearch et rien qui écrive : il récupère, lit, résume. Le --strict-mcp-config du chapitre 4 vaut aussi ici — aucun serveur MCP superflu chargé dans sa fenêtre.
• Indépendance requise. La délégation parallèle ne paie que si les sous-tâches sont indépendantes : chacune se traite sans le résultat des autres. Sinon, il faut les enchaîner plutôt que les paralléliser.

Exemple concret

Tâche : « compare la gestion du rate-limiting de quatre librairies avant de choisir ». Sans délégation, l’agent principal récupère lui-même les quatre pages de doc via WebFetch — 4 × ~20 000 = ~80 000 tokens de contenu brut chargés dans sa fenêtre (~40 % d’une fenêtre de 200k), et en série, l’une après l’autre. Avec quatre sous-agents doc-scraper lancés en parallèle, chaque tranche de ~20 000 tokens vit dans la fenêtre isolée de son sous-agent ; chacun renvoie une fiche de ~500 tokens (API clé, limites, valeurs par défaut). L’agent principal reçoit ~2 000 tokens de fiches au lieu de ~80 000 de doc brute : ~78 000 tokens (~39 % d’une fenêtre de 200k) ne sont jamais entrés dans la fenêtre principale — et le mur du temps tombe à celui de la plus lente des quatre récupérations, pas à leur somme.

Quatre sources : en série chez le parent vs en parallèle chez des sous-agents

Config — un sous-agent doc-scraper, en lecture seule

---
name: doc-scraper
description: >-
  Recupere et distille UNE source de documentation ou une page web. Use
  proactively pour lire une doc de librairie sans inonder la fenetre principale.
tools: WebFetch, WebSearch   # de quoi recuperer et lire — rien qui ecrive
model: haiku                 # la distillation de texte tourne bien sur un petit modele
---
Tu traites UNE seule source (URL ou sujet fourni dans le message de delegation) :
tu la recuperes, tu la lis, puis tu rends une fiche COURTE. Tu ne modifies rien.

# Rapport (obligatoire, 12 lignes max)
- API ou config clef, en `nom(signature)` ou extrait minimal.
- Limites, pieges, valeurs par defaut utiles.
- Aucune recopie de page entiere, aucune digression.

Commande — déclencher les récupérations de front

# Formuler la demande pour que l'agent principal delegue EN PARALLELE :
claude -p "Compare le rate-limiting des librairies A, B, C et D. Delegue chaque
  source a un sous-agent doc-scraper, EN PARALLELE, puis synthetise en un tableau."

Piège courant : croire que « lancer quatre récupérations de doc, c’est quatre fois plus de tokens pour l’agent principal » est inexact quand on délègue. En parallèle, le contenu brut de chaque source reste dans la fenêtre du sous-agent correspondant ; l’agent principal n’additionne que les fiches (~4 × 500 tokens), pas les pages (~4 × 20 000). Le piège inverse guette aussi : paralléliser des sous-tâches dépendantes — chacune, aveugle au résultat des autres, travaille à côté.

Le flux d’information : agent principal → sub-agents → rapport de synthèse

L’idée en une phrase

Déléguer en parallèle dessine un flux d’information en entonnoir : l’agent principal décompose et envoie vers le bas des messages de délégation compacts, les sous-agents traitent le bruit en isolation, et seuls leurs rapports remontent — l’agent principal les synthétise en un résultat unique. Le flux est à double sens mais asymétrique : c’est un Reduce structurel sur ce qui revient.

Analogie : un entonnoir. En haut, large, plusieurs sous-agents brassent en parallèle un grand volume de contenu brut ; au col, resserré, ne passent que des rapports condensés ; en bas, l’agent principal ne recueille qu’une fraction de ce qui a été traité au-dessus. Élargir le col — laisser les sous-agents renvoyer des pavés — et c’est tout le bruit qui redescend d’un coup dans la fenêtre principale.

Points clés

• Trois étages, un seul sens de resserrement. Agent principal (l’orchestrateur) → sous-agents (les workers isolés) → rapport de synthèse. Le contenu brut est brassé tout en bas de l’échelle ; vers le haut ne remonte que du condensé.
• Ce qui descend doit être autoportant. Un sous-agent démarre dans une fenêtre fraîche (chapitre 6) : il ne voit ni l’historique, ni les fichiers déjà lus. Le message de délégation doit donc tout porter — chemins ou URL, question précise, contraintes, format de sortie attendu.
• Ce qui remonte, c’est le message final, uniquement. Les appels d’outils intermédiaires du sous-agent — WebFetch, grep, lectures — ne traversent pas : seul son dernier message revient au parent. Toute l’économie de la délégation tient à cette frontière.
• Aucune communication latérale. Les sous-agents ne se parlent pas entre eux ; chacun ne rend compte qu’à l’agent principal. La mise en commun se fait au niveau du parent, à l’étape de synthèse.
• La synthèse re-concentre la valeur. L’agent principal reçoit N rapports compacts, les dédoublonne, réconcilie et compose en un résultat unique. C’est là que l’information éparse redevient une réponse — sans qu’il ait jamais chargé le brut.

Exemple concret

Reprenons les quatre librairies. L’agent principal écrit 4 messages de délégation de ~150 tokens chacun (« lis la doc rate-limiting de la librairie A à telle URL ; rends API, limites, défauts, 12 lignes max »). Les quatre doc-scraper traitent ~20 000 tokens chacun en parallèle, dans leur fenêtre. Remontent 4 fiches de ~500 tokens = ~2 000 tokens. L’agent principal les synthétise en un tableau comparatif de ~800 tokens. Bilan côté fenêtre principale : ~600 (délégations) + ~2 000 (rapports) + ~800 (synthèse) ≈ ~3 400 tokens — pour un travail qui, non délégué, en aurait chargé ~80 000. Le flux en entonnoir a divisé par ~20 l’empreinte sur l’agent principal, en préservant son attention (lois d’échelle inverses, chapitre 2).

Ce qui circule dans le flux, étage par étage

Config — un message de délégation autoportant

# Cote sous-agent, la fenetre est fraiche (chapitre 6) : il ne voit ni l'historique
# ni les fichiers deja lus. Le message de delegation doit TOUT porter :
Source   : https://exemple.dev/lib-A/rate-limiting   # URL exacte, ou chemin(s) de fichier
Question : quelle API principale ? quelles limites ? quelles valeurs par defaut ?
Format   : fiche de 12 lignes max, `nom(signature)`, aucune recopie de page

Piège courant : croire que « les sous-agents partagent un contexte commun » ou « se transmettent leurs trouvailles » est inexact — chacun est isolé (chapitre 6) et ne rend compte qu’au parent. Autre malentendu : penser que le travail intermédiaire (les WebFetch, les lectures) « remonte » ; non, seul le dernier message traverse. Et négliger l’autoportance du message de délégation reste le vrai piège : un brief trop maigre, et le sous-agent — aveugle à l’historique — part sur une mauvaise piste. Le flux descendant compte autant que le montant.

Fil rouge — Reduce ou Delegate ?

Ce chapitre pousse le Delegate des chapitres 6 et 7 à l’échelle : non plus un worker, mais plusieurs en parallèle. Le travail lourd et bruyant — scraping, lecture de documentation — est brassé simultanément dans des fenêtres isolées ; sur l’exemple, ~80 000 tokens de doc brute restent répartis chez les sous-agents et ne franchissent jamais le col. Le flux d’information en entonnoir ajoute un Reduce structurel sur le retour : ce qui remonte, ce sont des rapports condensés, puis une synthèse — ~3 400 tokens au lieu de ~80 000, l’empreinte sur l’agent principal divisée par ~20 (~39 % d’une fenêtre de 200k épargnés). En prime, le parallélisme ramène le mur du temps à celui du plus lent des workers. L’agent principal orchestre, ne se salit pas les mains, et garde une fenêtre dense — donc une attention intacte (chapitres 1 et 2).

Travaux pratiques

À chaque leçon, un petit artefact à déposer dans ton .claude/ — commande, sous-agent, hook, mémo… — pour te bâtir, au fil du livre, une boîte à outils de context engineering réutilisable.

Une commande maison — /veille

Les chapitres 6 et 7 ont rempli le tiroir des sous-agents (researcher, code-reviewer). On ajoute ici la couche d’orchestration au-dessus d’eux : une commande slash qui matérialise le flux en entonnoir du chapitre. Elle incarne Delegate (une source par doc-scraper, en parallèle) doublé d’un Reduce structurel sur le retour : elle interdit au contenu brut de remonter et impose une synthèse. À déposer dans .claude/commands/veille.md — elle s’appuie sur le sous-agent doc-scraper de la fiche (.claude/agents/doc-scraper.md).

---
description: Documente un sujet en deleguant chaque source a un sous-agent en parallele, puis synthetise
argument-hint: <sujet, ou liste d'URL / de librairies>
---

Tu es l'ORCHESTRATEUR d'une veille documentaire. Sujet : $ARGUMENTS

# Flux impose (agent principal -> sous-agents -> synthese)
1. Decompose le sujet en sources INDEPENDANTES (une librairie / page / section
   par source). Si deux sources dependent l'une de l'autre, traite-les dans une
   meme delegation — ne les parallelise pas.
2. Pour CHAQUE source, delegue a un sous-agent `doc-scraper`, EN PARALLELE
   (lance-les de front, pas l'un apres l'autre). Chaque message de delegation
   doit etre AUTOPORTANT : l'URL ou le chemin exact, la question precise, et le
   format attendu (fiche de 12 lignes max ; API, limites, valeurs par defaut ;
   aucune recopie de page).
3. N'ATTENDS QUE LES RAPPORTS. Ne recupere jamais les pages toi-meme : tout le
   contenu brut doit rester dans la fenetre des sous-agents.
4. SYNTHETISE les fiches recues en UN livrable : un tableau comparatif
   (source, API clef, limites, valeur par defaut) suivi d'une recommandation en
   3 lignes. Dedoublonne, et signale les contradictions entre sources.

# Regle d'or
Le contenu brut ne remonte jamais : seules les fiches, puis ta synthese, occupent
la fenetre principale. Si un rapport arrive verbeux, resume-le avant de continuer.

Invoque /veille compare le rate-limiting de A, B, C, D : la commande délègue une source par doc-scraper en parallèle, ~20 000 tokens de doc restent dans chaque fenêtre isolée, et l’agent principal ne voit que ~4 × 500 tokens de fiches puis sa propre synthèse — soit ~3 400 tokens au lieu de ~80 000 dans la fenêtre principale (empreinte divisée par ~20), le temps d’attente tombant à celui de la plus lente des récupérations. Delegate pour le bruit, Reduce sur le retour : attention préservée pour la vraie tâche — décider.