Comment faire tourner plusieurs sessions Claude Code en parallèle (sans perdre le fil)

Faire tourner deux sessions Claude Code à la fois donne l'impression d'un bon petit hack de productivité. En faire tourner cinq, c'est comme rassembler des chats. Un jour client normal chez Techsy, nous gardons trois à quatre sessions Claude Code et OpenAI Codex actives en parallèle : une qui refactore une route Next.js, une qui écrit des tests, une qui attend depuis 20 minutes une validation que personne n'a remarquée. Coder n'est pas la partie difficile. Savoir quel terminal a besoin d'un humain, maintenant, l'est.

Résumé rapide

Pour faire tourner plusieurs sessions de codage IA en parallèle sans chaos : donnez à chaque session une tâche précise et limitée, placez chacune dans son propre git worktree pour qu'elles ne touchent jamais les mêmes fichiers, groupez vos revues au lieu de surveiller chaque session en direct, et utilisez un outil qui suit l'état des sessions pour savoir laquelle est bloquée. Le mode d'échec n'est jamais « trop de sortie ». C'est une session terminée ou bloquée qui reste silencieuse pendant que vous attendez la mauvaise.

Pourquoi une session s'est transformée en quatre

Une session d'agent isolée a des temps morts. Elle planifie, édite, lance une suite de tests, attend une installation lente. Pendant qu'elle travaille, vous attendez. La réaction naturelle est de lancer une deuxième session sur un sujet sans rapport, puis une troisième. Deux choses rendent cela praticable en 2026, alors que c'était pénible il y a un an : les agents conservent le contexte assez longtemps pour porter une tâche entière, et les git worktrees permettent à chaque session de travailler sur sa propre branche, dans son propre répertoire.

Le calcul est simple. Si chaque session est productive 60 % du temps, trois sessions décalées vous rapprochent d'une utilisation complète sans qu'aucune ne bloque les autres. Nous nous sommes arrêtés à trois ou quatre sessions, le point où le coût de coordination commence à manger les gains.

Le vrai problème : les sessions se taisent, elles ne crient pas

Voici l'échec dont personne ne vous prévient. Les sessions en parallèle ne vous submergent pas quand elles échouent. Elles se taisent. Une exécution se termine et attend la prochaine instruction. Une exécution s'arrête pour demander « dois-je supprimer cette migration ? » et se bloque. Une exécution atteint une limite de débit et cale. Aucune de ces situations ne fait de bruit. Vous les découvrez en revenant sur l'onglet 15 minutes plus tard, en réalisant que la session que vous pensiez active était inactive depuis le début.

À partir de trois sessions, la ressource rare n'est pas la puissance de calcul. C'est votre attention, et plus précisément savoir où la diriger ensuite.

Un workflow qui tient au-delà de trois sessions

Voici la configuration que nous utilisons sur de vrais projets :

1. Une tâche par session. « Refactoriser le module d'authentification » est une session. « Améliorer le codebase » n'en est pas une. Un périmètre étroit est ce qui vous permet de laisser une session tranquille et de faire confiance à son résultat plus tard.
2. Un git worktree par session. git worktree add ../feature-x feature-x donne à chaque agent son propre répertoire et sa propre branche. Deux sessions qui modifient le même fichier, c'est le moyen le plus rapide de perdre un après-midi en conflits de fusion.
3. Décalez les démarrages. Lancez les sessions à quelques minutes d'intervalle pour qu'elles atteignent leurs moments « besoin de revue » à des instants différents, pas tous en même temps.
4. Groupez les revues. Ne les surveillez pas en continu. Laissez les sessions tourner, puis passez en revue deux ou trois diffs en une seule passe concentrée. C'est en changeant de contexte à chaque petite étape que la productivité fuit réellement.
5. Connaître l'état des sessions sans avoir à vérifier. C'est l'élément que la plupart des gens sautent, et c'est celui qui permet aux quatre autres de survivre à une journée chargée. Si vous avez déjà écrit un SKILL.md, vous savez déjà que cette discipline paie ; c'est la même chose ici. Consultez notre guide pour écrire un Claude skill pour le workflow complet, et la Techsy library pour les automatisations sur lesquelles nous nous appuyons.

Visualiser l'état des sessions en un coup d'œil

Les étapes une à quatre sont des habitudes. L'étape cinq a besoin d'un outil, parce que vous ne pouvez pas surveiller cinq terminaux à l'œil nu tout en faisant du travail de fond. Il vous faut quelque chose qui observe les sessions et vous dit laquelle a besoin de vous, pour ne pas passer votre temps à recharger des onglets en boucle.

Divulgation : Agent Island est un partenaire de Techsy, et le lien de cette section est sponsorisé.

Agent Island est un compagnon de statut gratuit et open source pour Claude Code et OpenAI Codex, sur macOS et Windows. Il fonctionne en local et affiche, en un coup d'œil, si chaque session prise en charge est en cours d'exécution, en attente d'une saisie, terminée, bloquée ou limitée en débit, et peut vous alerter quand une session a besoin d'une saisie. Il lit l'état des sessions directement sur votre machine : il n'y a pas de compte Agent Island à créer, pas de télémétrie produit, et vos données de session ne sont jamais envoyées vers Agent Island. Le code source est sous licence MIT et disponible sur GitHub. Pour être clair sur son périmètre : ce n'est ni un agent de codage IA, ni un IDE, ni un service de surveillance hébergé. C'est une couche de statut qui se place à côté des outils que vous utilisez déjà et répond bien à une seule question : quelle session a besoin de moi, là, maintenant.

Quand ne pas faire tourner des sessions en parallèle

Le parallélisme n'est pas gratuit. Évitez-le quand :

• Le travail est fortement couplé. Si chaque modification touche les mêmes fichiers centraux, les sessions vont se gêner mutuellement. Lancez-en une seule.
• Vous êtes encore en phase d'exploration. Le travail de conception précoce a besoin de toute votre attention sur un seul fil, pas de quatre pistes à moitié formées.
• Vous ne pouvez pas relire au même rythme que vous générez. Quatre sessions qui produisent des diffs que vous ne lisez jamais, ce n'est pas de la vitesse. C'est un arriéré avec des étapes en plus et plus de risque.

Deux sessions bien menées valent mieux que cinq dont vous avez perdu le fil.

Comment l'équipe Techsy s'organise

Sur les projets clients, nous plafonnons à quatre sessions, une tâche chacune, chacune dans son propre worktree, revues par lots environ toutes les demi-heures. Le changement qui a fait la plus grande différence n'était pas un modèle plus rapide. C'était de supprimer le besoin de vérifier. Une fois qu'une session annonce elle-même son état, « laquelle est bloquée » cesse d'être une question que vous portez en tête, et l'ensemble arrête de ressembler à rassembler des chats. Ce seul changement nous a fait passer de « deux sessions, c'est ma limite » à en faire tourner quatre sans appréhension.

Questions fréquentes

Combien de sessions Claude Code puis-je faire tourner à la fois ?

Techniquement, autant que votre machine et vos limites de débit le permettent. En pratique, la plupart des développeurs plafonnent à trois ou quatre avant que le coût de coordination n'annule le bénéfice. Commencez avec deux, et n'ajoutez une troisième que lorsque relire autant de diffs vous semble confortable.

Les sessions en parallèle partagent-elles le contexte ou la mémoire ?

Non. Chaque session Claude Code ou Codex a sa propre fenêtre de contexte et sa propre conversation. Cette isolation est une fonctionnalité : c'est pour ça que vous pouvez leur confier des tâches sans rapport entre elles. C'est aussi pourquoi un git worktree par session compte, pour que leurs modifications de fichiers restent isolées elles aussi.

À quoi sert un git worktree dans ce contexte ?

Un worktree donne à chaque session son propre répertoire de travail et sa propre branche, issus du même dépôt. Deux agents qui modifient les mêmes fichiers dans le même répertoire vont écraser le travail l'un de l'autre. Les worktrees les gardent physiquement séparés jusqu'à ce que vous fusionniez.

Comment savoir quand une session attend une saisie ?

Sans outillage, vous ne le savez pas, jusqu'à ce que vous vérifiiez. Un compagnon de statut comme Agent Island fait apparaître quelles sessions sont en cours, en attente, terminées, bloquées ou limitées en débit, et peut vous alerter quand l'une a besoin d'une saisie, pour que vous n'ayez pas à faire le tour des terminaux.

Faire tourner plusieurs sessions coûte-t-il plus cher ?

Vous consommez davantage de la capacité de votre forfait et pouvez atteindre les limites de débit plus tôt, ce qui explique en partie pourquoi les sessions calent. Étalez vos démarrages et surveillez les états de limite de débit plutôt que de supposer qu'une session silencieuse est encore en train de travailler.

Faire tourner des agents en parallèle en vaut-il la peine pour un développeur solo ?

Oui, dès lors que votre rythme de relecture suit votre rythme de génération. Un développeur solo avec deux sessions bien cadrées et un moyen de voir leur état obtient la majeure partie du bénéfice, sans la charge de coordination d'une équipe complète.

Est-ce possible sous Windows, ou seulement sous macOS ?

Les deux. Claude Code et Codex fonctionnent sur macOS et Windows, et Agent Island prend en charge les deux plateformes pour le statut des sessions.

Qu'est-ce qui casse en premier quand j'ajoute trop de sessions ?

Votre débit de relecture. Générer des diffs ne coûte rien ; les lire et leur faire confiance, si. Dès que le travail non relu s'accumule, n'ajoutez plus de session et videz d'abord l'arriéré.

À propos de l'auteur

Mert Batur construit chez Techsy, où l'équipe livre des agents IA, des systèmes d'automatisation et des pipelines voix/SDR pour des clients B2B. Il écrit sur la pile d'outils LLM et les Claude Skills que l'équipe Techsy utilise réellement en production. Connectez-vous sur LinkedIn.