Claude Code /batch : la puissance du traitement en masse
Combien de fois avez-vous traité vos fichiers un par un avec Claude Code alors que vous auriez pu tout faire en parallèle ? /batch existe pour ça.
TLDR;
/batchlance plusieurs agents Claude en parallèle, chacun dans un worktree git isolé. Vous définissez les tâches, ils s’exécutent simultanémentChaque agent travaille dans sa propre branche. Pas de conflits. Pas de code écrasé. Isolation totale
Les cas d’usage idéaux : migrations de librairies à grande échelle, refactoring en masse, revue de code parallèle, automatisation CI/CD
Le mode headless de Claude Code (intimement lié à
/batch) permet de déclencher ces workflows dans vos pipelines, sans interface
/batchet/simplifysont complémentaires : simplifiez d’abord, migrez ensuite
Lorsque je regarde autour de moi, je m’aperçois que la plupart des développeurs que je connais (ou non d’ailleurs) travaille toujours de façon séquentielle avec Claude Code : une tâche, quelques fichiers, un agent, puis ils attendent et passent à la tâche suivante.
Et s’ils ont 47 composants React dans lesquelles ils doivent migrer de PropTypes vers les types TypeScript ? Comment font-ils à votre avis ? Eh oui, ils les traitent un par un, ils y passent plusieurs jours.
Après la lecture de cet article, vous ne serez plus comme eux, parce qu’aujourd’hui, on part à la rencontre de 2 commandes qui règlent ce problème, la première étant /batch.
/batch ? Qu’est-ce que c’est ?
L’idée centrale tient en une phrase : au lieu d’un agent qui traite vos tâches une par une, /batch en lance plusieurs en même temps. Chacun reçoit une instruction distincte, s’exécute dans son propre environnement, et vous rend ses résultats quand il a terminé.
Pensez à un chef de projet qui distribue le travail à une équipe plutôt que de tout faire lui-même. Sauf que votre “équipe”, c’est plusieurs instances de Claude qui tournent en parallèle.
La documentation officielle d’Anthropic décrit /batch comme une commande native de Claude Code conçue pour les workflows de traitement en masse. Elle s’appuie sur deux mécanismes : l’orchestration parallèle d’agents, et l’isolation via les git worktrees.
Ce deuxième point mérite qu’on s’y attarde.
Pourquoi les git worktrees changent tout
Chaque agent lancé par /batch travaille dans un git worktree séparé. On en a parlé très récemment, mais pour rappel, si vous n’avez jamais utilisé les worktrees, voici l’essentiel : c’est un mécanisme natif de Git qui permet d’avoir plusieurs copies de travail de votre repo actives simultanément, chacune sur sa propre branche.
Sans cette isolation, deux agents qui modifient le même fichier en même temps seraient une catastrophe garantie avec des conflits, des données écrasées, un historique incohérent et j’en passe.
Avec les worktrees, chaque agent a son espace, sa branche, ses fichiers. Ils ne se voient pas, ils ne se marchent pas dessus.
Quand les agents ont terminé, vous récupérez N branches, soit une par tâche, que vous fusionnez normalement. Le workflow de review ne change pas. Seule la vitesse d’exécution change.
Les cas d’usage où /batch est imbattable
Migration de librairie à grande échelle
Vous passez de moment.js à la nouvelle API Temporal. Vous avez 34 composants qui importent moment. La migration est mécanique : il faut identifier le pattern et remplacer par l’équivalent. Mais c’est fastidieux.
Migre src/components/DatePicker.tsx de moment.js vers date-fns
Migre src/components/EventCalendar.tsx de moment.js vers date-fns
Migre src/hooks/useDateRange.ts de moment.js vers date-fns
[...]Maintenant, imaginez le tableau : 34 agents, 34 branches, 34 migrations en parallèle. Ce qui aurait pris plusieurs jours ne vous prendra qu’une petite heure.
Et c’est la même logique pour n’importe quel refactoring “uniforme” : convertir des class components en functional components, remplacer des callbacks par des async/await, ajouter des types TypeScript sur des interfaces existantes, migrer vers une nouvelle version d’une API. Dès que vous pouvez formuler la tâche de façon identique pour N fichiers différents, vous tenez un candidat parfait pour /batch.
Revue de code parallèle
Nous allons voir la commande /simplify dans un instant. Je ne sais plus malheureusement où, mais j’ai lu qu’un développeur a documenté comment il a accru sa vitesse de code review en combinant /batch et /simplify. Il envoie chaque fichier modifié en revue parallèle, récupère des commentaires structurés pour chaque composant, puis consolide.
Intégration CI/CD
Point important à clarifier ici : /batch est une commande interactive. Elle n’est pas disponible en mode programmatique. Pour les pipelines, c’est claude -p qui prend le relais.
Le flag -p (ou --print) est ce qu’Anthropic appelait autrefois le “headless mode”. Il exécute Claude Code sans interface graphique, piloté par des scripts. Vous l’intégrez directement dans vos workflows GitHub Actions, GitLab CI ou n’importe quel pipeline :
claude -p "Vérifie l'accessibilité des composants modifiés dans cette PR" \ --allowedTools "Read,Bash"La logique reste la même : au lieu de cliquer, vous décrivez la tâche en texte, et Claude l’exécute. Des cas d’usage concrets : générer la documentation à chaque commit, détecter les patterns de dette technique avant qu’ils entrent en production, vérifier des conventions de naming sur les fichiers modifiés... Tout cela sans que personne n’ait appuyé sur un bouton.
Pour les équipes qui veulent aller plus loin, Anthropic propose aussi l’Agent SDK qui donne un contrôle complet : outputs structurés, callbacks d’approbation d’outils, gestion native des messages.
/batch et /simplify : le combo à connaître
Ces deux commandes ont été conçues pour fonctionner ensemble. /simplify identifie et réduit la sur-ingénierie dans votre code : elle supprime les abstractions inutiles, clarifie les patterns complexes. Quant à /batch, elle migre ou refactorise en parallèle.
Mais attention, l’ordre compte : simplifiez d’abord et migrez ensuite.
Ce qu’il faut garder en tête avant de se lancer
La granularité des tâches compte. Des tâches trop larges (“refactore toute l’app”) créent des agents qui se marchent dessus ou produisent des résultats incohérents. Des tâches trop petites (“renomme cette variable”) gaspillent le parallélisme et vos tokens.
Je ne le dirai jamais assez : vérifiez les résultats avant de merger. /batch accélère l’exécution, pas la réflexion. Traitez les branches générées comme n’importe quelle PR de votre équipe. Lisez le diff, faites tourner vos tests. Ça paraît évident dit comme ça, mais l’effet “c’est Claude qui l’a fait, ça doit être bon” est réel, alors résistez-y.
La description des tâches fait 80% du résultat. Un prompt vague donne un résultat vague, même en parallèle. Soyez précis sur le contexte, les conventions attendues, les fichiers adjacents à ne pas modifier.
Par où commencer ?
Pensez à votre prochain chantier de migration, peu importe lequel (mise à jour de dépendance, adoption d’un nouveau pattern, conversion de format). Si vous pouvez décrire la tâche en une phrase et l’appliquer à N fichiers, vous tenez votre premier cas d’usage pour /batch.
Commencez petit avec 3 ou 4 tâches en parallèle. Regardez comment les worktrees se créent, comment les agents progressent, comment les branches se consolident. Vous aurez bien des occasions d’aller plus loin par la suite.
Si cette édition vous a été utile, partagez-la à un collègue qui utilise Claude Code. Et si vous n’êtes pas encore abonné et que vous ne souhaitez pas manquer les prochaines éditions, vous êtes les bienvenus !