Module 7 — Subagents et partitionnement — Context Engineering — le pack Praktik

Objectif

À la fin de ce module, tu sauras quand et comment splitter ton travail en subagents pour isoler le contexte.

Pourquoi les subagents ?

Les subagents ne servent pas à “jouer à la maison” ou anthropomorphiser des rôles. Ils servent à une chose : le contrôle du contexte.

Le cas d’usage le plus courant : laisser un subagent faire la recherche/summarization avec un contexte frais, pendant que l’agent parent garde un contexte propre pour l’implémentation.

Quand partitionner

Situation	Partitionner ?	Raison
Contexte estimé > 60% de la fenêtre	Oui	Éviter la compaction agressive
Tâches indépendantes	Oui	Isoler le raisonnement
Recherche dans un gros codebase	Oui	Le subagent explore, le parent décide
Bugfix simple (< 5 fichiers)	Non	Overhead non justifié
Tâches fortement couplées	Non	Coordination coûte plus cher

Règle : Moins de 3 sous-tâches indépendantes = l’overhead de coordination dépasse souvent les économies.

Le subagent idéal

Le subagent idéal retourne un résultat structuré que l’agent parent peut utiliser sans re-explorer :

## Recherche : Authentification JWT

### Fichiers pertinents
- src/auth/controller.ts : génération du token (ligne 45-67)
- src/middleware/auth.ts : validation (ligne 12-34)
- src/config/jwt.ts : configuration (ligne 8-15)

### Flow d'information
1. Requête → middleware/auth.ts (validation)
2. → auth/controller.ts (génération)
3. → config/jwt.ts (paramètres)

### Hypothèses de cause
1. Regex email trop stricte (probabilité : haute)
2. Parsing du payload incorrect (probabilité : moyenne)

### Recommandation
Vérifier la regex dans middleware/auth.ts ligne 23

Types d’architecture multi-agent

Pattern	Quand	Structure
Orchestrateur	Tâches complexes, multi-étapes	1 coordonnateur + N workers
Peer-to-peer	Collaboration égale	Agents qui se passent le contexte
Hiérarchique	Équipes structurées	Manager → Leads → Workers

Pour le code : Orchestrateur est le plus courant. Le parent garde le plan, les subagents exécutent.

Exemple dans Claude Code

# 1. Lancer un subagent pour la recherche
/claude subagent research "Trouve tous les usages de la fonction auth()"

# 2. Le subagent retourne un résumé structuré
# (pas les raw outputs de grep)

# 3. L'agent parent utilise ce résumé pour planifier

# 4. Lancer un subagent pour l'implémentation
/claude subagent implement "Applique le plan phase 1"

Handoff propre

Le handoff entre agents est le point de fragilité. Structure toujours le résultat d’un subagent avec :

Intent : Ce que la tâche devait accomplir
Findings : Ce qui a été découvert
Decisions : Ce qui a été décidé
State : L’état actuel (tests, fichiers modifiés)
Next : Ce qui reste à faire

Checklist de validation

Je sais quand partitionner (>60% fenêtre, tâches indépendantes)
Je sais quand NE PAS partitionner (<3 sous-tâches, couplage fort)
Mes subagents retournent des résultats structurés
J’ai un format de handoff standardisé
Je compte l’overhead de coordination avant de partitionner

Partitionner trop tôt. → Pour un bugfix de 3 fichiers, lancer 3 subagents crée plus d’overhead qu’il n’économise de tokens. Chaque subagent a son propre system prompt, ses tool definitions, et ses messages de coordination. Seuil de rentabilité : typiquement 3+ sous-tâches indépendantes de taille significative.

Prochaine étape

→ Module 8 (Workflow Research → Plan → Implement) pour la méthode de production complète