Fin novembre de l'année dernière, j'étais trois semaines dans un développement WooCommerce pour un client grossiste. Une trentaine de types de contenu personnalisés, un moteur de tarification sur mesure, et un flux de paiement avec plus de logique conditionnelle que je ne veux m'en souvenir. J'étais le seul développeur dessus. Et je perdais des jours juste à basculer le contexte entre la couche plugin, les surcharges de thème et les points de terminaison API REST.
C'est à ce moment que je me suis réellement engagé à exécuter des subagents Claude Code en parallèle. Pas en expérimentant. En restructurant réellement la façon dont je décompose le travail pour que plusieurs agents puissent avancer simultanément sans se marcher sur les pieds.
Voici ce que j'ai appris, y compris où je me suis trompé au départ.
---
Ce que « Subagents » signifie réellement dans Claude Code
Les gens utilisent le terme à la légère. Dans le framework agentic de Claude, un subagent est simplement une instance Claude qui reçoit une tâche ciblée d'un orchestrateur, l'exécute et retourne le résultat. L'orchestrateur (qui peut lui-même être une session Claude) décide comment répartir le travail, quels subagents lancer et comment combiner les résultats.
En pratique, pour la plupart d'entre nous qui construisons des sites et des applications, cela signifie exécuter plusieurs sessions terminales, chacune avec un contexte Claude Code focalisé, contre la même base de code. Parfois l'orchestration est automatisée via un script. Souvent, honnêtement, c'est juste moi qui coordonne manuellement ce sur quoi chaque agent travaille à partir d'un doc de planification dans Notion.
La différence entre séquentiel et parallèle
Le travail agentic séquentiel est ce par défaut la plupart des développeurs : demander à Claude de faire la tâche A, attendre, puis demander de faire la tâche B. Ça va pour les trucs simples. Mais si A et B ne dépendent pas du résultat l'un de l'autre, tu laisses du temps sur la table.
Les subagents parallèles s'exécutent simultanément sur des flux de travail indépendants. Le projet WooCommerce dont j'ai parlé : j'avais un agent qui refactorisait la logique du moteur de tarification tandis qu'un autre générait des commentaires PHPDoc dans les contrôleurs API REST. Zéro chevauchement. Les deux terminés dans le temps qu'il aurait fallu pour en faire un.
---
Comment je structure réellement la répartition du travail
C'est la partie dont personne ne parle assez clairement. La configuration de l'agent est la partie facile. La partie difficile est de figurer quoi répartir.
J'utilise une règle simple que j'ai mise au point après un incident douloureux de fusion de code en 2022 : deux agents ne doivent jamais toucher au même fichier pendant la même session. Pas de négociation. Si je ne peux pas le garantir, les tâches ne s'exécutent pas en parallèle.
Mon étape de planification avant tout run parallèle
Avant de lancer quoi que ce soit, j'écris un court manifeste de tâche. Rien de fantaisiste, juste un fichier texte brut ou une page Notion avec :
- Nom de la tâche et une description en une phrase
- Fichiers en scope (liste explicite)
- Fichiers hors scope (tout ce qui est adjacent et qui pourrait tenter un agent à s'égarer)
- Format de résultat attendu
- Tout contexte dont l'agent a besoin et qui ne figure pas dans la base de code
Cela me prend peut-être 15 minutes. Ça m'a épargné un nombre véritablement embarrassant de conflits.
---
Les trois types de flux de travail que je divise le plus souvent
Après 12 000+ constructions de sites chez Seahawk, et mon propre travail de client solo en parallèle, j'ai remarqué que les mêmes catégories reviennent régulièrement comme bons candidats à la parallélisation.
1. Génération de documentation et de code
Un agent écrit ou refactorise du code. Un autre écrit de la documentation, des tests, ou des commentaires pour un module différent. Ceux-ci ne sont presque jamais en conflit et les deux sont vraiment fastidieux à faire manuellement. Sur le projet de vente en gros WooCommerce, j'avais un sous-agent générant des stubs de test PHPUnit pour les fonctions de tarification tandis qu'un autre construisait les colonnes d'administration personnalisées. Les stubs de test ont pris environ quatre minutes. Les colonnes d'administration ont pris douze minutes. Je n'ai perdu aucune de ces quatre minutes en attente.
2. Isolation frontend et backend
Si votre frontend et backend résident dans des répertoires clairement séparés (ce qu'ils devraient être, mais c'est un autre sujet), c'est une division naturelle. J'ai exécuté un sous-agent construisant des composants React dans /resources/js tandis qu'un autre câblait les contrôleurs Laravel dans /app/Http. Le seul point de coordination était de s'entendre sur le contrat API avant que l'un ou l'autre agent ne commence. Je l'ai écrit dans un fichier AGENTS.md à la racine du projet. Les deux agents l'ont référencé.
3. Refactorisation module par module
Les gros refactors sont misérables quand on les fait séquentiellement. Si vous avez, disons, huit modules de fonctionnalités qui ont tous besoin du même type de changement (mise à jour d'une méthode dépréciée, migration vers un nouvel assistant, peu importe), divisez-les entre les agents. J'ai une fois exécuté quatre agents simultanés migrant un plugin hérité des boucles WP_Query vers un modèle de dépôt. Chaque agent a obtenu deux modules. Fait en moins d'une heure. De manière séquentielle, c'était une demi-journée.
---
Configuration des outils : ce que j'utilise réellement
Je ne vais pas prétendre avoir une infrastructure élaborée. Ma configuration réelle est :
- Claude Code s'exécutant dans plusieurs volets
tmuxsur un seul MacBook Pro M3 - Un fichier
AGENTS.mdpartagé à la racine du projet qui définit les conventions, la propriété des fichiers, et le contrat API entre les flux de travail - Des branches Git par agent. Toujours. Même si la branche n'existe que vingt minutes
- Un rapide
git diff --statavant toute fusion pour détecter les surprises
Le fichier AGENTS.md est probablement la chose la plus utile que j'ai ajoutée à mon flux de travail cette année. C'est un fichier markdown simple qui dit à tout agent (ou humain, d'ailleurs) quelles sont les conventions du projet, quels fichiers appartiennent à quel flux de travail, et ce qu'il faut éviter de toucher. Pensez-y comme un CONTRIBUTING.md mais écrit pour les fenêtres de contexte de l'IA.
Sur la gestion de la fenêtre de contexte
C'est là que les gens deviennent paresseux et puis confus. Chaque sous-agent a son propre contexte. Cela signifie que si l'agent B a besoin de savoir ce que l'agent A a décidé, vous devez le lui dire explicitement. Il ne le saura pas simplement.
Je gère cela en gardant un SESSION_LOG.md que je mets à jour manuellement après que chaque agent ait complété un bloc. C'est trois à cinq points max : ce qui a été fait, ce qui a changé, ce que le prochain agent doit savoir. L'overhead est faible. L'alternative est qu'un agent fasse des suppositions qui cassent votre code, et cet overhead est bien plus élevé.
---
Là où ça tourne mal (d'après l'expérience douloureuse)
Seahawk avait un projet de tableau de bord fintech le printemps dernier où nous avons essayé d'exécuter des sous-agents sur un monorepo sans propriété de fichier correctement définie. Deux agents ont tous deux décidé de mettre à jour le fichier utils/formatters.ts partagé. Aucun ne savait l'existence de l'autre. La fusion qui en a résulté était techniquement correcte, mais nous avons passé 40 minutes à réconcilier les intentions. Complètement évitable.
Les modes de défaillance que je vois régulièrement :
- Les fichiers utilitaires partagés. C'est un piège. Verrouillez-les. Si un sous-agent a besoin de mettre à jour un utilitaire partagé, cette tâche devrait s'exécuter seule, pas en parallèle.
- Descriptions de tâches vagues. Un agent à qui on dit « nettoie le module auth » l'interprétera très différemment selon ce qui se trouve dans son contexte. Soyez précis. « Refactorise
AuthController.phppour utiliser l'interfaceUserRepositorydéjà définie dansapp/Repositories/UserRepository.php. Ne modifie pas l'interface elle-même. » Voilà un prompt sûr. - Pas d'isolation de branche. Exécuter tous les agents sur
main, c'est comment tu crées des vendredis après-midi excitants. Les branches ne coûtent rien. - Sauter le manifest. Je sais, je sais. Ça ressemble à de la surcharge. Fais-le quand même. Chaque fois que j'ai sauté cette étape, je l'ai regretté en moins d'une heure.
---
Une vraie exécution parallèle, étape par étape
Voici à quoi ressemblait à peu près la session de mardi dernier pour un projet de migration Shopify vers WooCommerce (anonymisé, mais la structure est exacte).
- J'ai écrit le manifest des tâches dans Notion. Quatre tâches identifiées comme parallélisables.
- Créé quatre branches git : agent/product-import, agent/tax-logic, agent/rest-endpoints,
agent/admin-ui. - Ouvert quatre panes
tmux, une session Claude Code chacun. - Collé la section pertinente d'
AGENTS.mdau début de chaque session comme contexte. - Donné à chaque agent son prompt de tâche, en référençant des fichiers spécifiques.
- Exécuté les quatre simultanément. Me préparé un café. L'ai vraiment bu pendant qu'il était encore chaud, ce qui semblait miraculeux.
- Révisé la sortie de chaque branche. Exécuté
phpcssur le PHP,eslintsur tout JS touché. - Fusionné en séquence : import produit d'abord (les autres avaient des dépendances légères à son schéma), puis logique fiscale, puis endpoints REST, puis interface admin.
- Mis à jour
SESSION_LOG.mdavec ce qui a changé.
Temps total pour les quatre tâches combinées : environ 35 minutes. Mon estimation pour une exécution séquentielle était 90 minutes à 2 heures. Je prendrais ça.
---
Ce que cela remplace (et ne remplace pas)
Les sous-agents parallèles ne remplacent pas la réflexion. Cette étape de planification de 15 minutes, c'est vraiment toi qui fais le travail d'architecture. Les agents exécutent. Tu dois toujours savoir quoi construire, comment les pièces s'assemblent, et si la sortie est vraiment correcte.
Je relis la sortie de chaque agent avant qu'elle ne touche main. Chaque fois. J'ai attrapé un sous-agent qui écrivait avec confiance une couche de cache qui aurait causé des problèmes de données obsolètes sur une installation multisite. Le code semblait bon. C'était logiquement faux pour ce contexte spécifique. Je ne l'ai attrapé que parce que j'ai lu le code.
La propre orientation d'Anthropic sur les tâches agentic signale spécifiquement l'importance des points de contrôle humains avant les actions irréversibles. Ce n'est pas du baratin corporate. C'est vraiment un conseil important, particulièrement quand les agents ont accès en écriture à des bases de données ou exécutent des migrations.
L'autre chose que cela ne remplace pas : la communication avec les clients. Un agent peut construire une fonctionnalité. Il ne peut pas dire à un client pourquoi une deadline a changé ou gérer les attentes autour du scope creep. Cette partie est toujours la tienne.
---
FAQ
Ai-je besoin d'un accès API spécial ou d'outils pour exécuter des sous-agents Claude Code ?
Aucune configuration exotique requise. Claude Code est l'outil de codage basé sur terminal d'Anthropic, et tu peux exécuter plusieurs instances dans des sessions de terminal séparées (j'utilise tmux). Tu as besoin d'une clé API Claude avec des limites de taux suffisantes si tu accèdes l'API directement. Pour les charges de travail parallèles lourdes, vérifie ton tier de limite de taux avant de commencer pour ne pas être limité en cours de session.
Comment j'empêche les agents de conflictuer sur des fichiers partagés ?
Définissez la propriété des fichiers avant de commencer. La convention AGENTS.md que j'ai décrite fonctionne bien. Si deux tâches ont besoin de modifier un même fichier utilitaire partagé, ne les paramétrises pas en parallèle. Exécute d'abord le changement du fichier partagé, valide-le, puis lance les autres tâches en parallèle à partir de cette base propre.
Cela n'est utile que sur les gros projets ?
Honnêtement, non. Je l'ai utilisé sur des sites monopages où je voulais générer de la documentation aux côtés du code des nouvelles fonctionnalités. Le surcoût de la planification est assez faible pour que même des économies de temps modestes le justifient. Cela dit, si un projet a moins de peut-être cinq tâches parallélisables distinctes, le temps de configuration commence à dépasser le bénéfice. Utilise ton jugement.
Que se passe-t-il si un agent produit un mauvais résultat ?
Tu le détectes à la revue, tu jettes la branche et tu réessaies avec un prompt plus précis. C'est tout l'intérêt de l'isolation des branches. Un mauvais résultat d'agent te coûte le temps de revue et de re-prompt. Ça ne devrait pas te coûter une codebase cassée si tu suis la règle une-branche-par-agent.
Peux-je automatiser l'orchestration au lieu de la faire manuellement ?
Oui, et pour les workflows répétitifs, c'est worth it. J'ai écrit de simples scripts Bash qui lancent des appels Claude Code séquentiels avec des prompts et du contexte prédéfinis. Pour une orchestration parallèle entièrement automatisée, tu construirais une couche orchestrateur qui lance les agents par programme, collecte la sortie et gère les dépendances. C'est un investissement d'ingénierie plus important. Pour la plupart des freelances et petites agences, une coordination manuelle avec tmux et un manifeste de tâches, c'est largement suffisant.
---
La vérité honnête, c'est que les sous-agents parallèles ne m'ont pas rendu dramatiquement meilleur développeur. Ils m'ont rendu plus rapide, sur la classe spécifique de tâches où le goulot d'étranglement était l'exécution plutôt que la réflexion. La réflexion, c'est toujours moi. Les décisions d'architecture, les appels clients, la revue de code. Tout ça, c'est toujours moi.
Mais les parties d'exécution fastidieuses ? Je reprendre chaque minute que je peux.