Réponses Claude trop longues ? Constituez votre équipe IA avec les Subagents

Quand vous demandez à Claude une revue de sécurité du code, il peut revenir avec des suggestions de refactorisation, d’analyse de performance et des cas de test — 3 000 lignes d’un coup. Le problème n’est pas que l’IA en donne trop, mais qu’on ne peut pas lui dire de se concentrer sur une seule chose.

Les Subagents règlent ce point. Chaque Subagent a sa propre portée de tâches, ses permissions d’outils et son modèle, dans le répertoire .claude/agents/ du projet. Besoin d’une revue de code ? Appelez le Subagent dédié. Besoin de documentation ? Appelez celui des docs. Les limites sont figées dans la config : pas de débordement, pas de digression.

Cet article couvre la configuration des Subagents, les modes d’appel et la collaboration Multi-Agent, avec un cas pratique de système de rédaction de blog.

Qu’est-ce qu’un Subagent

En bref, un Subagent est un assistant sur mesure que vous donnez à Claude. Chacun a sa portée, ses outils, et même un modèle différent.
Ils vivent dans .claude/agents/ : un fichier par assistant. Structure simple : YAML en tête, prompt détaillé en Markdown en dessous.

---

name: code-reviewer
description: Assistant dédié à la revue de qualité et de sécurité du code
tools: [Read, Grep, Glob]
model: haiku

---

Vous êtes un expert en revue de code, focalisé sur :
- failles de sécurité (injection SQL, XSS, etc.)
- goulots d'étranglement de performance
- problèmes de style et de conventions
Signalez les problèmes uniquement ; ne modifiez pas le code.

Par rapport à une conversation Claude classique, trois différences :
Focalisation — il ne fait que ce que vous définissez. Demandez une revue, il ne refactorise pas « en bonus ».
Restrictions — seuls les outils autorisés sont utilisables. Un assistant en lecture seule ne peut pas toucher vos fichiers.
Réutilisabilité — la config vit dans le projet ; toute l’équipe en profite. Un nouvel arrivant peut lancer @code-reviewer tout de suite.

Pourquoi utiliser des Subagents

Au début, j’ai trouvé ça superflu — pourquoi ne pas parler directement à Claude ?
Après quelques semaines d’usage, le gain est réel.

Focalisation

Claude est trop polyvalent : une question code peut dériver vers les bonnes pratiques, des frameworks recommandés, voire de la doc. Utile parfois, souvent du bruit.
Un Subagent reste sur une tâche. L’assistant « revue de code » ne propose pas de refactor ; l’assistant « tests » ne remet pas en cause votre architecture.

Optimisation des coûts

Peu de gens y pensent : toutes les tâches n’ont pas besoin du modèle le plus cher.
Recherche, conversion de format, analyse simple : Haiku suffit, environ un tiers du coût de Sonnet. Sur un mois d’équipe, l’écart se voit.

Traitement parallèle

C’est là que ça devient vraiment intéressant.
Plusieurs tâches en parallèle : après une feature, lancez en même temps les tests unitaires, la revue de code et la doc. En pratique, le gain de temps est net.

Réutilisabilité

Les configs versionnées dans Git deviennent l’expérience du projet, exécutable par tous.

"La valeur des Subagents : focalisation et réutilisabilité. Un généraliste devient une équipe d’experts, chacun sur son domaine."

Configuration YAML en détail

Concrètement, à quoi ressemble un fichier ?
Quelques champs, mais seulement deux obligatoires :

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

---

name: blog-writer          # requis : identifiant unique
description: Expert en rédaction de brouillons de blog  # requis : influence le déclenchement auto
tools: [Read, Write, Grep]  # optionnel : permissions, tout par défaut
model: sonnet              # optionnel : modèle, hérite du dialogue principal par défaut

---

# Le prompt détaillé suit le YAML
Vous êtes un rédacteur de blog professionnel...

name — ID pour l’appel. Préférez des noms explicites : code-reviewer, test-writer.
description — cruciale. Claude s’en sert pour le déclenchement automatique. « Assistant généraliste » ne sera presque jamais choisi.
Mauvais :

description: Un assistant

Bon :

description: Recherche approfondie sur un sujet de blog et production d'un plan de contenu structuré

tools — liste des permissions. Par défaut tout est ouvert ; ce n’est pas idéal (voir plus bas).
model — haiku rapide et économique, sonnet équilibré par défaut, opus le plus qualitatif et le plus cher.

Contrôle des permissions d’outils

J’ai appris à mes dépens.
Au début, full permissions partout. Un jour, un assistant censé n’analyser que le code a modifié des fichiers — à tort.
Depuis : donner uniquement le nécessaire.
Combinaisons courantes :

---

name: code-reviewer
tools: []  # tableau vide = tout, peu sûr

---

Bon : lecture seule

---

name: code-reviewer
tools: [Read, Grep, Glob]

---

Un reviewer en lecture seule ne peut pas casser votre code par erreur. La contrainte protège.

Trois modes d’appel

Config prête — comment l’utiliser ?

Déclenchement automatique

Avec une description claire, Claude choisit seul. Ex. « toutes les demandes liées à la revue de code » → « revois cette PR » déclenche l’agent.

@-mention

Le plus direct :

@code-reviewer Regarde si cette fonction pose problème

Outil Task

Pour les scénarios programmatiques :

Task(subagent_type="code-reviewer", prompt="Revoir tous les fichiers sous src/")

Collaboration Multi-Agent

Au-delà d’un seul assistant, la force est dans l’orchestration.

Mode séquentiel

Mon usage favori pour la création de contenu :

Sujet fourni par l'utilisateur
    |
@blog-planner recherche + plan
    | document de plan
@blog-writer lit le plan, rédige le brouillon
    | brouillon
@blog-editor lit le brouillon, peaufine
    | version finale

Une étape par agent ; sortie N = entrée N+1. Clair, contrôlable, facile à déboguer.

Mode parallèle

Après une feature, en parallèle :

• @test-writer — tests unitaires
• @code-reviewer — revue
• @doc-writer — documentation
  Trois flux indépendants : ~30 min en série → ~10 min en parallèle.

Mode HITL (Human In The Loop)

Pour les décisions sensibles :

@planner génère le plan
    |
Validation ou modification humaine
    |
@executor exécute le plan validé

L’humain garde la main aux points critiques.

Sept astuces de rédaction

Après quelques mois, sept habitudes qui améliorent les configs :

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Astuce 1 : description précise

Elle conditionne le déclenchement automatique.
Trop vague — jamais déclenché :

description: Assistant généraliste

Précise — périmètre clair :

description: Revue des failles de sécurité et des problèmes de performance du code Python

Astuce 2 : prompt concret

Pas seulement « expert en revue de code » — décrivez la méthode.
Trop vague :

Vous êtes expert en revue de code. Aidez l'utilisateur.

Guide détaillé :

Vous êtes expert en sécurité Python.
## Points de contrôle
1. Injection SQL — toutes les opérations base de données
2. XSS — traitement des entrées utilisateur
3. Fuites de données sensibles — logs et messages d'erreur
## Format de sortie
Pour chaque problème :
- Fichier : xxx
- Ligne : xxx
- Gravité : haute / moyenne / basse
- Description : xxx
- Correction suggérée : xxx

Astuce 3 : outils au minimum

Moins de permissions n’affaiblit pas l’assistant ; ça limite ce qu’il peut faire de travers.

Astuce 4 : bon modèle

Haiku pour le simple, Sonnet pour le complexe :

• Haiku : recherche, synthèse, conversion, tri de données
• Sonnet : logique complexe, contenu créatif, génération de code, raisonnement

Astuce 5 : tester largement

Après écriture : auto, @-mention, cas limites.

Astuce 6 : documentation claire

Le prompt est la doc d’équipe : rôle et usage visibles d’un coup d’œil.

Astuce 7 : itérer souvent

Pas besoin de la version parfaite au premier jet ; affinez avec l’usage réel.

Pièges fréquents

Ce que j’ai déjà raté :

Piège 1 : description floue

« Assistant général » — Claude ne sait pas quand l’appeler.
Mauvais :

description: Assistant pour l'utilisateur

Mieux :

description: Quand l'utilisateur mentionne « test » ou « tests unitaires », générer des cas de test

Piège 2 : trop de permissions

Full access par paresse → actions non souhaitées. Surtout Write : à accorder avec réflexion.
Mauvais :

name: format-converter
tools: []  # tout

Mieux :

name: format-converter
tools: [Read, Write]

Piège 3 : prompt trop long

Le prompt consomme des tokens à chaque appel. Restez concis, l’essentiel seulement.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Piège 4 : oublier model

Sans model, héritage de Sonnet — cher pour une tâche simple.
Oubli :

name: text-extractor
tools: [Read]

Corrigé :

name: text-extractor
tools: [Read]
model: haiku

Piège 5 : appels en boucle

A appelle B, B rappelle A → boucle jusqu’au timeout.
Correct : A → B → C
Incorrect : A → B → A

Piège 6 : pas de gestion d’erreur

Les Subagents échouent aussi ; prévoyez la détection dans le workflow.

Piège 7 : pas de versioning

Versionnez dans Git pour pouvoir revenir en arrière si une config casse tout.

Cas pratique : système de rédaction de blog

Exemple concret — mon pipeline actuel, trois Subagents :

Architecture

Sujet fourni
    |
blog-planner : recherche + plan (20 min)
    | sortie : docs/[sujet]-plan.md
blog-writer : brouillon (40 min)
    | sortie : docs/[sujet]-brouillon.md
blog-editor : relecture (20 min)
    | sortie : docs/[sujet]-final.md

blog-planner (planificateur)

---

name: blog-planner
description: Recherche approfondie et création du document de plan de contenu
tools: [Read, Write, Grep, WebSearch, WebFetch]
model: sonnet

---

Vous êtes planificateur de contenu :
1. WebSearch pour les tendances du sujet
2. Analyse audience et pain points
3. Structure de l'article et stratégie SEO
4. Plan écrit dans docs/

blog-writer (rédacteur)

---

name: blog-writer
description: Rédaction du brouillon de blog à partir du plan
tools: [Read, Write, Grep]
model: sonnet

---

Vous êtes rédacteur :
1. Lire le document de plan
2. Rédiger le brouillon complet selon le plan
3. Ton naturel, éviter le style « IA générique »
4. Brouillon dans docs/

blog-editor (éditeur)

---

name: blog-editor
description: Relecture du brouillon et amélioration de la lisibilité
tools: [Read, Edit]
model: haiku

---

Vous êtes éditeur :
1. Lire le brouillon
2. Supprimer les tournures trop « IA »
3. Renforcer humanité et lisibilité
4. Version finale dans docs/

Workflow :

# Étape 1 : plan
@blog-planner Astuces Subagents Claude Code
# Étape 2 : rédaction
@blog-writer
# Étape 3 : édition
@blog-editor

Entrées et sorties explicites à chaque étape — débogage simple.

Conseils d’optimisation des coûts

Haiku coûte environ trois fois moins que Sonnet (tarifs sur le site Anthropic). Un pipeline blog bien dimensionné économise sensiblement.

Stratégie de modèles

Haiku pour

• recherche et synthèse
• conversions de format simples
• tri et classification
• revue de code en lecture seule
  Sonnet pour
• création de contenu (blog, doc)
• génération de code complexe
• analyse nécessitant du raisonnement
• exigence de qualité élevée

Comparaison rapide

Règles d’économie

• Haiku si possible plutôt que Sonnet
• limiter les outils plutôt que All tools
• prompt court plutôt qu’encyclopédique
• borner la sortie plutôt que laisser prolixe

Pour conclure

Les Subagents ne sont pas de la magie : c’est découper les capacités de Claude selon le besoin. Un généraliste devient une équipe, chacun sur son rôle.
Si vous faites encore « un seul Claude pour tout », essayez une demi-heure de config — vous gagnerez des « Claude a encore dérivé » en moins.
Principes clés :

1. un agent, une mission
2. outils strictement nécessaires
3. Haiku pour le simple
4. prompts précis
5. documents comme interface entre agents
   En cas de blocage, revoyez les 7 astuces et 7 pièges ci-dessus.
   Et surtout : lancez-vous, affinez en marchant — pas besoin de la config parfaite dès le jour 1.
   Bonne constitution de votre équipe IA !