Claude Code

Claude Code peut lancer d'autres instances de Claude — des sous-agents — pour traiter des tâches en parallèle ou isoler des opérations lourdes du contexte principal. C'est la fonctionnalité qui transforme Claude d'un assistant en orchestrateur.

Pourquoi des agents

Deux problèmes que les agents résolvent :

Le contexte qui gonfle. Une session longue accumule des appels d'outils, des diffs, des sorties de commande. Quand le contexte approche de la limite, la qualité des réponses baisse. Déléguer à un agent garde le contexte principal propre.

Les tâches indépendantes. Si vous demandez à Claude de tester l'API, vérifier la sécurité et auditer les performances — trois tâches sans dépendance entre elles — les faire l'une après l'autre est lent. Des agents parallèles les traitent simultanément.

Fork vs Fresh agent

Deux types d'agents fondamentalement différents.

Fork — hérite de tout le contexte

Un fork reçoit l'intégralité de l'historique de la conversation. Utile pour des recherches ou explorations qui utilisent le contexte mais dont la sortie brute n'est pas nécessaire dans la session principale.

subagent_type: "fork"

Le fork part du même point que vous. Il voit tout ce que vous avez discuté. Son travail se fait en arrière-plan — la sortie (appels d'outils, logs) ne pollue pas votre contexte. Seul le résumé final revient.

Cas d'usage : audits de code, recherches dans la codebase, questions ouvertes ("qu'est-ce qui pourrait casser si on change l'API auth ?").

Fresh agent — repart de zéro

Un fresh agent n'a aucun contexte. Vous devez tout lui expliquer dans le prompt, comme si vous briefiez un collègue qui vient d'arriver.

subagent_type: "claude"  # ou omis

Cas d'usage : implémentations isolées, tâches bien définies qui n'ont pas besoin du contexte de la conversation.

Agents spécialisés

Certains agents ont des rôles prédéfinis et des outils restreints :

claude          — agent général (tous les outils)
Explore         — recherche et lecture seule (pas d'édition)
Plan            — conception d'architecture (pas d'édition)
claude-code-guide — questions sur Claude Code et l'API Anthropic

L'agent Explore est particulièrement utile pour des recherches dans une grande codebase sans risquer de modifier accidentellement des fichiers.

Agents en parallèle

La vraie puissance : lancer plusieurs agents dans le même message.

> Lance trois agents en parallèle :
> - Un qui audite la sécurité du code d'authentification
> - Un qui vérifie les performances des requêtes SQL
> - Un qui cherche les todos et fixmes dans le codebase

Claude lance les trois simultanément. Les résultats arrivent au fur et à mesure.

Même logique pour les implémentations :

> Implémente en parallèle :
> - Agent 1 : écrire les tests pour UserService (fichier tests/user.test.ts)
> - Agent 2 : écrire les tests pour AuthService (fichier tests/auth.test.ts)
> - Agent 3 : créer le mock de la base de données partagée (tests/mocks/db.ts)

Les trois agents travaillent en même temps. Ce qui prendrait 15 minutes séquentiellement prend 5 minutes.

L'isolation worktree

Pour des tâches qui modifient des fichiers, l'option isolation: "worktree" crée un git worktree temporaire — une copie isolée du repo sur une branche séparée.

> Crée un agent en worktree isolé qui refactorise le module de logging
> sans toucher à ma branche courante

L'agent travaille dans son propre worktree. Si les changements sont satisfaisants, on les merge. Si non, le worktree est supprimé proprement. Aucune pollution de la branche de travail.

isolation: "worktree"

Quand l'agent termine sans avoir fait de changements, le worktree est nettoyé automatiquement. S'il a modifié des fichiers, le chemin et la branche sont retournés pour review et merge.

Briefer un agent fresh correctement

Un fresh agent part de zéro. Un prompt mal rédigé produit un travail hors sujet.

À inclure dans le brief :

• Ce qu'on essaie d'accomplir et pourquoi
• Ce qu'on a déjà essayé ou écarté
• Les fichiers ou zones spécifiques à regarder
• Le format du résultat attendu
• Ce qui est hors scope

## ❌ Brief trop vague
 
"Cherche des bugs dans le code auth."
 
## ✅ Brief complet
 
"Cherche des problèmes de sécurité dans le module d'authentification (lib/auth/).
Contexte : on utilise JWT avec refresh tokens. Les tokens sont stockés en httpOnly cookies.
Ce qu'on sait déjà : le rate limiting sur /login est en place.
Cherche : validation des tokens manquante, expositions accidentelles dans les logs,
CORS mal configuré sur les routes auth.
Rapport : liste structurée par sévérité avec fichier:ligne pour chaque finding."

Communiquer avec un agent en cours

Claude peut envoyer des messages à un agent déjà lancé via SendMessage.

> Envoie un message à l'agent audit-security pour lui dire de se concentrer
> sur le module de paiement, pas sur l'auth

Cela reprend l'agent existant sans en relancer un nouveau — économie de contexte et de coût.

Tasks — suivre le travail des agents

Quand plusieurs agents travaillent en parallèle, les Tasks permettent de suivre l'état de chacun.

TaskCreate  — créer une tâche
TaskUpdate  — marquer en cours / terminé
TaskGet     — lire l'état
TaskList    — voir toutes les tâches
TaskOutput  — voir la sortie d'un agent en cours
TaskStop    — arrêter un agent

Claude les utilise en interne pour orchestrer des workflows complexes. Vous pouvez aussi les consulter :

> liste les tâches en cours
> quelle est l'avancement de l'agent de refactoring ?

Agents distants (remote)

Pour des tâches très longues qui peuvent prendre des dizaines de minutes, l'option isolation: "remote" lance l'agent dans le cloud Anthropic — votre session locale reste libre.

isolation: "remote"

L'agent remote s'exécute en arrière-plan. Vous recevez une notification quand il termine.

Bonnes pratiques

Forks pour l'exploration, fresh pour l'implémentation. Un fork qui explore "pourquoi le build est lent" a besoin du contexte. Un agent qui "implémente le module de cache" a besoin d'un brief précis, pas de votre historique de conversation.

Un agent = une tâche bien définie. Ne pas donner trois choses à faire à un seul agent — lancer trois agents. La parallélisation est gratuite.

Ne pas déléguer ce qui nécessite des décisions. Si la tâche implique des choix d'architecture importants, les faire vous-même d'abord. Les agents implémentent des décisions prises, ils ne les prennent pas.

Vérifier le travail des agents. Un résumé d'agent décrit ce qu'il avait l'intention de faire, pas nécessairement ce qu'il a fait. Lire les diffs avant de merger.

Les agents décuplent la productivité sur les tâches parallélisables. Le chapitre suivant couvre MCP — le protocole qui permet à Claude de se connecter à des outils externes : bases de données, APIs, services tiers.