Workflows pro et coups de maître

Avancé

What you'll learn

Orchestrer des sous-agents en parallèle — et savoir quand passer à un workflow dynamique piloté par script
Faire des hooks la colle déterministe : lint à l'enregistrement, verrouiller l'arrêt, bloquer les écritures interdites
Transformer vos prompts récurrents en slash-commandes personnalisées, skills et un style de sortie
Construire une stack MCP et des pipelines headless (claude -p) qui tournent sans surveillance en CI
Dérouler la boucle explorer → planifier → exécuter → réviser avec discipline, et garder le contexte allégé
Traiter CLAUDE.md comme du code : court, élagué et à fort signal

C'est la page où les primitives cessent d'être des fonctionnalités isolées pour devenir un workflow. Si vous savez déjà ce qu'est un sous-agent ou un hook, l'effet de levier réside dans la façon dont vous les empilez : une slash-commande qui lance une passe en mode plan, des sous-agents qui répartissent le travail, un hook qui empêche le tour de se terminer tant que les tests ne passent pas, et une invocation headless qui exécute le tout en CI. Câblons tout cela ensemble.

Le modèle mental : qui détient le plan ?

Chaque coup de maître ci-dessous est une réponse différente à une seule question — qui détient le plan et les résultats intermédiaires ? Le cadre proposé par Anthropic pour la nouvelle fonctionnalité de workflows dynamiques l'explique clairement :

Outil	Qui décide de ce qui s'exécute ensuite	Où vivent les résultats	Échelle
Sous-agents	Claude, tour par tour	La fenêtre de contexte de Claude	Quelques-uns par tour
Skills	Claude, en suivant le prompt	La fenêtre de contexte de Claude	Comme les sous-agents
Équipes d'agents	Un agent chef, tour par tour	Une liste de tâches partagée	Une poignée de pairs longs
Workflows dynamiques	Le script	Des variables de script	Des dizaines à des centaines

La progression est tout l'enjeu : commencez avec un seul Claude, déléguez aux sous-agents pour protéger le contexte, et ne déplacez le plan dans du code que lorsqu'une tâche exige plus d'agents qu'une seule conversation ne peut en coordonner.

Coup 1 — Sous-agents en parallèle, puis passer à un workflow

Un sous-agent est un Claude distinct doté de sa propre fenêtre de contexte et d'un outillage restreint ; il renvoie un résultat, pas sa transcription. L'habitude de l'utilisateur avancé est de répartir le travail indépendant :

Répartir une revue sur plusieurs modules

Review the changes in auth/, billing/, and api/ — use the code-reviewer
subagent on each, in parallel. Report only correctness bugs and missing tests.

Trois réviseurs tournent en même temps, chacun consommant son propre contexte sur les diffs, et votre session principale voit trois rapports bien rangés au lieu de trois diffs brutes. Le hic : le parallélisme n'aide que pour des sous-tâches indépendantes. Si l'étape B a besoin de la sortie de l'étape A, exécutez-les en séquence ; si elles écrivent dans les mêmes fichiers, isolez-les dans des worktrees git.

Quand la tâche dépasse une seule conversation — une migration de 500 fichiers, une chasse aux bugs à l'échelle du dépôt, une recherche recoupée sur de nombreuses sources — passez à un workflow dynamique. Claude écrit un script d'orchestration JavaScript (répartir → réduire → synthétiser), un runtime l'exécute en arrière-plan avec jusqu'à 16 agents concurrents, et seule la réponse finale atterrit dans votre contexte. Déclenchez-en un avec le mot-clé ultracode ou demandez simplement en langage clair :

Lancer un workflow dynamique

ultracode: audit every API endpoint under src/routes/ for missing auth checks,
then cross-check each finding with a second agent before reporting

La fonctionnalité déterminante n'est pas seulement plus d'agents — c'est qu'un script peut appliquer un schéma de qualité reproductible, comme faire réviser de façon contradictoire les conclusions des uns par les autres avant qu'aucune ne soit rapportée. Essayez le /deep-research <question> fourni pour voir le schéma en action : il vote sur chaque affirmation et filtre celles qui ne survivent pas au recoupement.

Pro tip

Sauvegardez un bon workflow comme commande : ouvrez /workflows, sélectionnez l'exécution, appuyez sur s. Elle devient /votre-nom dans toutes vos sessions futures.
Évaluez le coût sur une tranche d'abord — un seul répertoire, pas tout le dépôt. Une exécution peut engendrer bien plus d'agents (et de tokens) qu'une seule conversation.

Coup 2 — Hooks : la colle déterministe

Les instructions de CLAUDE.md sont indicatives — Claude les suit généralement. Les hooks sont déterministes — ils exécutent un script à un point fixe de la boucle, garanti, à chaque fois. Optez pour un hook quand quelque chose doit se produire sans aucune exception.

Les trois schémas de hooks à plus fort effet de levier :

Guided walkthrough1 of 3

Après que Claude a édité un fichier, exécutez automatiquement votre formateur ou votre linter afin que le code ne dérive jamais. Le retour remonte aussi à Claude, qui s'auto-corrige.

Vous n'avez pas à écrire le JSON à la main. Demandez à Claude de rédiger le hook pour vous :

Faire écrire un hook par Claude

Write a hook that runs eslint --fix after every file edit, and a second hook
that blocks any Write or Edit to the db/migrations/ folder. Add them to
.claude/settings.json and show me the config.

Watch out

Un hook Stop qui bloque en continu sera outrepassé après plusieurs blocages consécutifs pour que la session ne puisse pas se figer — votre verrou est un garde-fou, pas une boucle infinie.
Les hooks s'exécutent avec les permissions de votre shell. Relisez tout script de hook avant de le committer, exactement comme vous le feriez pour une configuration CI.

Coup 3 — Slash-commandes personnalisées, skills et styles de sortie

Tout ce que vous saisissez deux fois devrait devenir une primitive. La décision est simple : les skills sont de la connaissance, les hooks des garanties, MCP de l'action, les slash-commandes des points d'entrée.

Une slash-commande (ou une skill avec disable-model-invocation: true) encapsule un workflow reproductible que vous déclenchez à la main. $ARGUMENTS la rend paramétrable :

.claude/skills/fix-issue/SKILL.md

---
name: fix-issue
description: Triage and fix a GitHub issue end-to-end
disable-model-invocation: true
---
Fix GitHub issue $ARGUMENTS:
1. gh issue view to read the issue
2. Search the codebase for the relevant files
3. Write a failing test that reproduces the bug
4. Implement the fix, then run tests and lint until green
5. Commit with a descriptive message and open a PR

Lancez-la avec /fix-issue 1234. Utilisez disable-model-invocation: true pour tout ce qui a des effets de bord que vous voulez déclencher délibérément plutôt que de laisser Claude y recourir de lui-même.

Les styles de sortie changent la manière dont Claude communique sur toute la session — laconique pour un expert, détaillé avec explications pour l'apprentissage, ou un format structuré que votre outillage peut parser. Associez une slash-commande personnalisée (le quoi) à un style de sortie (le comment) et vous avez façonné les deux extrémités de l'interaction.

Le coup de maître le plus sous-utilisé de la documentation officielle : laissez Claude vous interroger avant une grosse fonctionnalité, puis démarrez une session neuve pour construire à partir de la spec écrite.

Spec par entretien, puis construire dans un contexte propre

I want to build [brief description]. Interview me in detail using the
AskUserQuestion tool — technical implementation, UI/UX, edge cases, tradeoffs.
Dig into the hard parts I might not have considered. When we've covered
everything, write a complete, self-contained spec to SPEC.md.

Coup 4 — Construire une stack MCP

Les serveurs MCP sont des processus exécutables que Claude appelle via JSON-RPC pour réellement faire des choses — interroger votre base de données, lire Sentry, récupérer un design Figma, ouvrir un ticket Linear. Une « stack » d'utilisateur avancé est un ensemble petit et réfléchi, pas tout ce que vous pouvez trouver :

Ajouter des serveurs à votre stack

claude mcp add --transport stdio sentry -- npx -y @sentry/mcp-server
claude mcp add --transport http linear https://mcp.linear.app/sse

Deux principes gardent une stack MCP rapide :

Préférez un CLI quand il en existe un. gh, aws, gcloud et sentry-cli sont la façon la plus économe en contexte de parler à un service — Claude les connaît déjà, et ils ne chargent pas de schéma d'outil à chaque tour. Réservez MCP aux services sans bon CLI, ou lorsque vous voulez un accès structuré et typé.
Gardez la liste des serveurs allégée. Les définitions d'outils de chaque serveur connecté consomment du contexte dès le départ. Élaguez les serveurs que vous n'utilisez pas activement ; les listes d'outils surchargées évincent vos véritables instructions.

Pour le pourquoi plus profond, voir Ingénierie du contexte — la même logique de budget attentionnel qui régit CLAUDE.md régit votre liste d'outils.

Coup 5 — Pipelines headless et Agent SDK

claude -p "prompt" exécute Claude de façon non interactive — pas de session, sortie parsable — ce qui ouvre la porte à la CI, aux hooks pre-commit et aux jobs batch. C'est la surface headless / Agent SDK.

Le schéma classique de répartition sur les fichiers, tiré du guide officiel des bonnes pratiques :

Migration batch headless

# 1. Have Claude generate the work list first, then loop:
for file in $(cat files.txt); do
claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
  --allowedTools "Edit,Bash(git commit *)"
done

Deux flags font le gros du travail : --output-format json (ou stream-json --verbose) rend les résultats lisibles par machine, et --allowedTools cadre exactement ce à quoi Claude peut toucher quand personne ne surveille. Redirigez-le n'importe où :

Claude comme étape de pipeline

cat error.log | claude -p "Cluster these errors by root cause, output JSON" \
--output-format json | jq '.[] | select(.severity=="high")'

Watch out

Testez toujours le prompt sur 2–3 éléments avant de lâcher la boucle sur 2 000. Affinez, puis passez à l'échelle.
Les exécutions sans surveillance ont besoin d'une vérification intégrée — un hook Stop ou une étape de test dans le prompt — sinon vous venez juste d'automatiser la production, à grande échelle, de résultats plausibles mais faux.

Coup 6 — Discipline du mode plan et ingénierie du contexte

Le levier de qualité le plus fiable est de séparer la recherche de l'exécution. La boucle en quatre phases du guide des bonnes pratiques d'Anthropic :

Guided walkthrough1 of 4

Entrez en mode plan. Claude lit les fichiers et répond aux questions mais ne modifie rien. Pointez-le vers les répertoires exacts : « lis /src/auth et explique comment fonctionnent les sessions. »

Voir Mode plan pour la discipline, et sautez-le quand le diff tient en une phrase — planifier a un coût. La raison pour laquelle cela marche, c'est l'économie de contexte : la performance se dégrade à mesure que la fenêtre se remplit, donc une instruction de 50 tokens dans un contexte de 2 000 tokens frappe bien plus fort que la même instruction enfouie dans 50 000 tokens. Habitudes pratiques :

/clear entre des tâches sans rapport ; une session propre avec un meilleur prompt vaut mieux qu'une longue session polluée.
Après deux corrections infructueuses, cessez de corriger — /clear et réécrivez le prompt avec ce que vous avez appris.
Déléguez la recherche à des sous-agents pour que la lecture des fichiers se fasse dans leur contexte, pas le vôtre.

Le parcours « montez votre setup en gamme »

Si vous ne faites rien d'autre, faites ceci dans l'ordre :

Guided walkthrough1 of 6

Lancez /init pour un point de départ, puis coupez chaque ligne qui échoue au test : « la supprimer amènerait-elle Claude à faire une erreur ? » Un fichier surchargé fait ignorer à Claude les règles qui comptent.

Maîtrise de CLAUDE.md

CLAUDE.md se charge au début de chaque conversation, c'est donc le contexte à plus haute fréquence que vous contrôlez — et par conséquent le plus facile à gâcher en le surchargeant.

À mettre dans CLAUDE.md	À laisser dehors
Les commandes Bash que Claude ne peut pas deviner	Tout ce que Claude trouve en lisant le code
Les règles de style qui diffèrent des valeurs par défaut	Les conventions standard que Claude connaît déjà
Le lanceur de tests + comment lancer un seul test	La doc d'API complète (mettez plutôt un lien)
L'étiquette du dépôt (nommage des branches/PR)	Les infos qui changent fréquemment
Les pièges non évidents et les particularités d'environnement	Les platitudes du genre « écris du code propre »

Traitez-le comme du code : relisez-le quand le comportement dérape, élaguez régulièrement, et utilisez les imports @path/to/file plus des fichiers CLAUDE.md par répertoire afin que chaque partie d'un monorepo ne reçoive que ce qui est pertinent. Déplacez les connaissances parfois pertinentes dans des skills pour qu'elles se chargent à la demande au lieu de taxer chaque tour.

Testez-vous

0/4

Vous avez besoin d'une migration de 500 fichiers coordonnée avec un recoupement contradictoire. Quel outil convient le mieux ?
Quelle est la différence clé entre un hook et une instruction de CLAUDE.md ?
Quel flag cadre ce que Claude peut faire pendant une exécution batch `claude -p` sans surveillance ?
Pourquoi élaguer CLAUDE.md améliore-t-il l'adhérence ?

Rappel des coups de maître — retournez chaque carte

Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.

1 / 5

Key takeaways

La progression est la compétence : un seul Claude → sous-agents en parallèle → workflows dynamiques pilotés par script, choisis selon qui doit détenir le plan.
Les hooks sont la colle déterministe — lint à l'enregistrement, verrouiller l'arrêt, bloquer les écritures interdites — pour ce qui doit arriver à chaque fois.
Encapsulez les prompts récurrents en slash-commandes/skills, façonnez la restitution avec un style de sortie, et gardez une stack MCP allégée (préférez les CLI).
claude -p en headless avec --allowedTools transforme Claude en étape de CI/pipeline ; intégrez toujours une vérification pour les exécutions sans surveillance.
La discipline du mode plan plus une économie de contexte agressive (/clear, recherche déléguée aux sous-agents, un CLAUDE.md élagué) est le levier de plus haute fiabilité dont vous disposez.

Sources et pour aller plus loin

Bonnes pratiques pour Claude Code — le guide officiel d'Anthropic : la boucle explorer→planifier→exécuter, les règles de CLAUDE.md, les hooks, les sous-agents, la répartition headless et la vérification.
Orchestrer des sous-agents à grande échelle avec les workflows dynamiques — doc officielle sur les workflows dynamiques, le mot-clé ultracode, /deep-research et le tableau comparatif « qui détient le plan ».
Ingénierie efficace du contexte pour les agents IA — Anthropic Engineering sur le contexte comme budget fini et la récupération juste-à-temps.
hesreallyhim/awesome-claude-code — vaste liste communautaire de skills, hooks, slash-commandes, orchestrateurs d'agents et plugins.
qdhenry/Claude-Command-Suite — une bibliothèque bien connue de slash-commandes et d'agents professionnels (p. ex. /dev:code-review).
GWUDCAP/cc-sessions — un ensemble d'extensions opinioné démontrant des hooks pour l'application des workflows plus la gestion des tâches/git.
VoltAgent/awesome-claude-code-subagents — une grande collection communautaire de définitions de sous-agents spécialisés.

Le modèle mental : qui détient le plan ?​

Coup 1 — Sous-agents en parallèle, puis passer à un workflow​