Puis-je lancer deux sessions Claude Code dans le même dossier ?

Oui, Claude Code démarre, mais les deux sessions modifient les mêmes fichiers et voient les changements inachevés l’une de l’autre. Donnez à chaque session son propre worktree git, ou au minimum une frontière de dossier stricte.

Combien d’agents Claude Code puis-je lancer en même temps ?

Claude Code lui-même n’impose pas de plafond strict. En pratique, deux à quatre, c’est ce qu’une personne peut suivre ; les limites et le temps de relecture sont le vrai plafond.

Comment fusionner le travail d’agents Claude Code parallèles ?

Traitez chaque worktree comme une branche normale : lancez-y les tests, poussez-la et ouvrez une pull request, ou fusionnez-la en local. Fusionnez une branche à la fois et relancez les tests après chacune.

Lancer plusieurs agents Claude Code en parallèle

Q: Plusieurs agents Claude Code partagent-ils une même limite d’usage ?

Oui. Chaque session connectée au même compte puise dans les mêmes limites de 5 heures et hebdomadaire : quatre agents les consomment donc environ quatre fois plus vite.

Une session Claude Code traite une tâche étape par étape. Pendant qu’elle lit des fichiers et lance des tests, vous attendez. Lancer plusieurs agents Claude Code en parallèle transforme ce temps d’attente en travail : un agent construit l’API, un autre écrit les tests, un troisième corrige un bug sans rapport avec les deux.

Cet article va de la configuration la plus simple à la plus confortable : terminaux ordinaires, tmux, worktrees git, sessions parallèles propres à Claude Code et enfin AgentVera. Chaque étape ajoute ce qui manquait à la précédente. À la fin, une liste des pièges qui mordent d’habitude : conflits de fusion, limites et tokens.

Peut-on lancer plus d’un agent Claude Code à la fois ?

Oui. Claude Code est une CLI ; chaque fois que vous lancez claude, vous démarrez une session indépendante avec sa propre conversation et son propre contexte. Rien ne vous empêche d’en démarrer cinq. Ce qui peut mal tourner, ce n’est pas de les démarrer mais de les coordonner : deux sessions dans le même dossier modifieront volontiers le même fichier, et toutes les sessions connectées à un même compte partagent ses limites.

La vraie question est donc de savoir comment les garder séparées et comment les suivre.

Option 1 : des fenêtres de terminal séparées

La configuration la plus rapide est un onglet de terminal par agent :

# tab 1
cd ~/code/acme-web && claude
# tab 2
cd ~/code/acme-web && claude

Cela marche pour des tâches petites et bien séparées. Indiquez à chaque agent, dans son premier message, quels dossiers il peut toucher (« uniquement src/api/ », « uniquement tests/ »).

Les inconvénients apparaissent vite : vous ne voyez pas quel onglet attend une approbation, les deux sessions partagent une copie de travail, et quand un agent lance git checkout, l’autre se retrouve soudain sur une autre branche.

Option 2 : tmux

tmux garde les sessions en vie quand vous fermez le terminal et permet de voir plusieurs panneaux à la fois :

tmux new-session -d -s agents -c ~/code/acme-web
tmux split-window -h -t agents -c ~/code/acme-web
tmux send-keys -t agents:0.0 'claude' Enter
tmux send-keys -t agents:0.1 'claude' Enter
tmux attach -t agents

Les deux agents sont maintenant visibles côte à côte et survivent à un capot d’ordinateur fermé (tant que la machine reste allumée). tmux résout la visibilité, pas l’isolation : les deux panneaux modifient toujours le même dossier.

Option 3 : un worktree git par agent

Les worktrees git sont la réponse standard à « deux agents, un dépôt ». Un worktree est un second dossier de travail sur sa propre branche, partageant le même historique .git :

cd ~/code/acme-web
git worktree add ../acme-web-api -b feat/api
git worktree add ../acme-web-tests -b feat/tests

cd ../acme-web-api && claude     # agent 1
cd ../acme-web-tests && claude   # agent 2

Chaque agent a désormais ses propres fichiers et sa propre branche. Le git checkout ou le fichier à moitié écrit d’un agent n’affecte pas l’autre. Quand un agent a fini, sa branche est fusionnée comme n’importe quelle branche de fonctionnalité.

Quelques notes pratiques :

Installez les dépendances par worktree. node_modules, environnements virtuels et sorties de build ne sont pas partagés. Lancez pnpm install (ou équivalent) dans chaque nouveau dossier.
Copiez la config locale. Les fichiers .env sont généralement ignorés par git, ils n’apparaissent donc pas dans un nouveau worktree.
Les ports entrent en collision. Deux serveurs de dev sur le port 3000 ne démarreront pas ; donnez à chaque worktree son propre port.
Nettoyez. git worktree remove ../acme-web-api une fois la branche fusionnée, et git worktree prune pour les dossiers supprimés à la main.

Les détails sont dans les worktrees git pour agents parallèles.

Option 4 : les sessions parallèles de Claude Code lui-même

L’app de bureau Claude Code d’Anthropic peut lancer des sessions Claude parallèles, chacune dans son propre worktree, sans que vous tapiez les commandes git. Si vous n’utilisez que Claude et voulez l’outil officiel, c’est une étape raisonnable. Elle couvre l’isolation et une vue d’ensemble basique.

Ce qu’elle ne cherche pas à faire : lancer d’autres CLI comme Codex ou Gemini CLI à côté de Claude, passer automatiquement la sortie d’un agent à un autre, ou basculer un agent sur un autre compte quand une limite est épuisée. C’est là qu’intervient une app multi-agents dédiée. Pour comparer les options, voir les meilleurs outils pour lancer plusieurs agents de code IA en parallèle.

Option 5 : AgentVera

AgentVera ouvre la commande claude de votre machine dans de vrais terminaux et dispose les agents en grille par projet. Il utilise la connexion propre de Claude Code, votre offre Pro ou Max fonctionne donc telle quelle. Voici comment les problèmes précédents correspondent à ses fonctions :

Problème	Dans AgentVera
On ne voit pas quel agent a besoin de vous	Grille de 1×1 à 5×4 ; chaque panneau affiche son état et la taille de contexte en direct ; les agents en attente d’approbation sont listés dans la barre d’état
Les agents modifient les mêmes fichiers	Panneau de worktrees : créez un worktree à partir d’une branche et démarrez-y directement un agent
Deux agents touchent quand même un fichier	Un avertissement de conflit de fichier : quand deux agents modifient le même fichier dans le même dossier, l’agent comme vous en êtes informés ; rien n’est bloqué
La sortie doit être copiée à la main	Les flows envoient la réponse d’un agent à un autre via un modèle
La limite s’épuise en pleine tâche	La bascule de comptes fait passer l’agent au compte Claude suivant et copie la conversation
Le contexte grossit à chaque tour	`/compact` automatique à un seuil que vous définissez, plus des profils de contexte

Pas à pas

Ajoutez le dossier du projet. Choisissez-le depuis l’écran des projets. Un dépôt Git est recommandé.
Créez des worktrees. Dans le panneau de droite, ouvrez la liste des worktrees et créez-en un par tâche à partir d’une nouvelle branche, par exemple feat/api et feat/tests.
Ouvrez les agents. Sous « New agent », choisissez Claude Code, sélectionnez le worktree et donnez à l’agent un nom, un modèle, un niveau d’effort et un court rôle :
```
Work only under src/api/. Don't change tests.
Run pnpm test api after each change.
Finish with a bullet list of what you changed.
```
Disposez la grille. Une disposition 2×2 convient à deux agents Claude, un relecteur Codex et un terminal qui lance le serveur de dev.
Connectez-les si besoin. Un flow peut envoyer le résumé final de l’agent API à l’agent de test quand son tour se termine. Une limite de tours évite que deux agents bouclent.
Relisez et fusionnez. La revue de code automatique contrôle chaque tour terminé. Le panneau Git montre les changements de chaque worktree et son avance sur main ; fusionnez une branche à la fois.

La grille, les worktrees et la revue de code sont inclus dans l’offre gratuite. Les flows et la bascule de comptes sont dans Pro.

Pièges et comment les éviter

Conflits de fusion

Les worktrees empêchent les agents de s’écraser mutuellement pendant qu’ils travaillent ; ils n’empêchent pas les conflits à la fusion. Deux agents qui modifient tous deux src/routes.ts sur des branches différentes entreront quand même en conflit à la fin.

Répartissez les tâches par dossier ou module, pas seulement par branche.
Confiez les fichiers partagés (tables de routes, schémas, lockfiles) à un seul agent.
Fusionnez d’abord la plus petite branche, puis faites un rebase de l’autre worktree sur main et laissez son agent résoudre le conflit : git rebase main dans ce worktree, puis demandez à l’agent de résoudre et de relancer les tests.

Limites d’usage

Toutes les sessions d’un même compte partagent les mêmes limites de 5 heures et hebdomadaire. Quatre agents n’obtiennent pas quatre fois le quota ; ils atteignent la limite quatre fois plus vite. Consultez régulièrement /usage dans Claude Code et planifiez les grosses sessions parallèles tôt dans une fenêtre de limite. Si vous avez légitimement plus d’un compte (personnel et professionnel, par exemple) et que les conditions du fournisseur l’autorisent, la bascule de comptes maintient une tâche en cours quand l’un s’épuise. Plus de détails dans les limites d’usage de Claude Code.

Consommation de tokens

Chaque agent porte son propre contexte : prompt système, définitions d’outils, CLAUDE.md, serveurs MCP et chaque fichier lu. Cette base est relue à chaque tour, par agent.

Donnez aux agents des tâches étroites et concrètes pour qu’ils lisent moins de fichiers.
Lancez /compact avant qu’une longue conversation ne devienne coûteuse, ou laissez-le s’exécuter automatiquement à un seuil.
Désactivez les serveurs MCP dont un agent n’a pas besoin.
Quand vous passez une sortie d’un agent à l’autre, envoyez le résumé, pas toute la transcription.

Des chiffres mesurés figurent dans réduire la consommation de tokens de Claude Code.

Approbations qui bloquent

Un agent qui attend une permission s’arrête pendant que les autres continuent. Avec cinq panneaux, il est facile d’en manquer un. Gardez un œil sur l’état, utilisez les notifications, ou autorisez les actions sûres (lire des fichiers, lancer des tests) dans les réglages de permissions de Claude Code pour que les agents demandent moins.

Trop d’agents, trop tôt

Le goulot d’étranglement passe des agents à vous. Relire quatre branches prend plus de temps qu’en relire une. Commencez avec deux agents sur des tâches clairement séparées, et ajoutez un troisième quand cela fonctionne.

Une checklist minimale

Un worktree par agent susceptible de toucher du code partagé
Dépendances installées et .env copié dans chaque worktree
Le rôle de chaque agent nomme ses dossiers et son objectif
Des ports séparés pour les serveurs de dev
Un plan de fusion : quelle branche d’abord, qui résout les conflits
Un œil sur /usage et la taille du contexte

Pour conclure

Lancer plusieurs agents Claude Code en parallèle, c’est surtout une affaire d’isolation et d’attention. Les worktrees donnent à chaque agent ses propres fichiers ; tmux ou une grille vous permet de tous les voir ; des rôles courts et un plan de fusion gardent le résultat relisible. Des terminaux ordinaires et des worktrees suffisent pour commencer. Quand vous voulez une grille, des flows entre agents et de l’aide avec les limites, téléchargez AgentVera gratuitement et ouvrez vos deux premiers agents Claude Code. Pour la méthode générale, voir les agents de code en parallèle.