04 — Subagents et délégation — Codex — Le guide pratique

Ce que tu vas apprendre

Décider quand déléguer à un subagent et quand garder le travail local
Concevoir une tâche déléguée avec un périmètre clair
Revoir le résultat d’un worker sans tout refaire
Éviter les anti-patterns de délégation

Prérequis

Modules 01 à 03 maîtrisés
Avoir utilisé Codex sur des tâches multi-fichiers
Comprendre la différence entre travail parallèle et travail bloquant

La délégation est puissante quand le travail est parallèle et borné. Elle est nuisible quand elle fragmente le chemin critique ou duplique l’effort. Règle : déléguer le travail latéral, pas le prochain blocage.

Étapes

1. Décider quand déléguer

Délègue quand les trois conditions sont réunies :

La tâche est concrète
Ce n’est pas le blocage immédiat pour ta prochaine étape locale
Son résultat fera avancer la tâche principale

Ne délègue pas quand :

La prochaine action dépend de la réponse
La sous-tâche est couplée au raisonnement local
La portée d’écriture chevauche fortement un autre travail actif

2. Concevoir une tâche déléguée

Une bonne tâche déléguée inclut :

Objectif exact
Fichiers ou responsabilité détenus
Ce qu’il ne faut pas changer
Quel output retourner

Template de brief de tâche :

## Objectif
Qu'est-ce qui doit être vrai quand cette tâche est terminée ?

## Surface
CLI, IDE, web/cloud, GitHub, automation, MCP, connector, ou SDK.

## Contexte
- Repo, branche, issue, PR ou artefact source
- Fichiers ou composants pertinents
- Sources externes à vérifier

## Périmètre
- Modifications autorisées
- Hors périmètre explicite
- Zone de responsabilité pour le travail délégué

## Vérification
- Commandes à lancer
- Captures, logs, commentaires de review ou autre preuve

## Output attendu
- Diff, explication, résumé de PR, réponse à commentaire, rapport

Exemple de forme concise :

- "Tu possèdes `src/api/auth.ts` et `tests/auth.test.ts`."
- "Ne révertis pas les modifications sans rapport."
- "Retourne les fichiers modifiés et les risques de suivi."

3. Revoir le résultat d’un worker

Quand un worker retourne son travail :

@diagram:steps
Scanner le résumé :: Lire ce que le worker affirme avoir fait.
Inspecter les fichiers modifiés :: Ouvrir le diff, pas seulement le résumé.
Vérifier le résultat affirmé :: Relancer la commande de vérification promise.
Intégrer ou affiner :: Merger ou ajuster, sans refaire la tâche aveuglément.

Règle : fais assez confiance au worker pour aller vite, pas assez pour sauter la review.

4. Éviter les anti-patterns

Déléguer le chemin critique → Si tu es bloqué sur la réponse maintenant, garde ce travail local.

Déléguer une exploration floue → Pose des questions bornées au lieu de “regarde autour et dis-moi ce qui compte.”

Déléguer des portées d’écriture qui se chevauchent → Deux agents modifiant le même fichier sans coordination = un problème de merge déguisé en parallélisme.

Vérification

La tâche est concrète et bornée
Ce n’est pas un blocage immédiat pour la suite
Le brief inclut objectif, fichiers, exclusions et output
Les portées d’écriture ne se chevauchent pas avec d’autres travaux
Le résultat a été relu avant intégration
La vérification promise a été effectuée

Pièges courants

Déléguer la prochaine étape bloquante → Garde le chemin critique local
Assigner des tâches vagues → “Améliore le code” n’est pas une tâche déléguable
Attendre les agents par réflexe → La délégation est pour le parallèle, pas la séquentialité forcée
Déléguer sans review → Même un bon worker peut rater un contexte implicite
Déléguer l’exploration → L’exploration nécessite un jugement continu, difficile à déléguer

Récapitulatif

Situation	Action	Exemple
Tâche parallèle et bornée	Déléguer	“Écris les tests pour `auth.ts`”
Prochaine étape bloquante	Garder local	“Déboguer pourquoi `auth.ts` échoue”
Exploration floue	Poser questions bornées	“Liste les 3 risques dans `auth.ts`”
Chevauchement d’écriture	Sérialiser ou découper	Agent A : `auth.ts`, Agent B : `user.ts`

Pour aller plus loin

Inspiré du guide codex-howto de anup4khandelwal (MIT)