Deux Claude qui se parlent

Ce que c'est et pourquoi ça compte

Chaque fenêtre de Claude Code est une session, avec sa propre tête. Elle a sa propre conversation et ne sait que ce que vous lui avez dit dedans. Si vous en ouvrez deux, au départ elles ne savent rien l'une de l'autre.

Le problème, c'est que le messager, c'est vous. Une session renomme un champ dans l'app, vous copiez, vous collez dans l'autre fenêtre, vous réexpliquez tout et vous oubliez peut-être un morceau. Avec deux chantiers en parallèle, ça arrive sans arrêt.

Claude Code a une fonction faite pour ça : les messages entre sessions. Une session peut voir les autres ouvertes sur votre ordinateur et envoyer un message texte à l'une d'elles. Celle qui le reçoit le lit et continue en en tenant compte.

Pourquoi ça compte : vous pouvez répartir le travail comme vous le feriez entre deux personnes. Dans l'une, vous faites construire quelque chose, dans l'autre, vous demandez de vérifier ce que fait la première. Ou bien l'une travaille sur l'app et l'autre sur le site, et quand la première a fini, elle prévient la seconde. Vous restez celui qui décide, pas le facteur.

Comment l'activer

Ouvrez deux sessions de Claude Code sur le même ordinateur, une par tâche (par ex. une dans le dossier de l'app, une dans celui du site).

Il n'y a rien à allumer : si Claude Code est à jour, les messages entre sessions fonctionnent déjà.

Claude a deux outils pour ça : un pour voir les autres sessions ouvertes (ListAgents) et un pour envoyer un message à l'une d'elles (SendMessage). Pas besoin de taper des commandes : vous lui demandez en français, tout simplement, par exemple « envoie un message à la session du site ». Parfois, Claude en envoie même un de lui-même, quand il remarque qu'une de ses modifications touche au travail de l'autre session.

Donnez un nom à chaque session

Les sessions se retrouvent par leur nom. Claude Code en choisit un tout seul, mais c'est plus pratique de le décider vous-même, comme ça vous savez toujours qui est qui.

1. Dans la fenêtre de l'app, tapez /rename app. Le nom apparaît sur la barre où vous écrivez.
2. Dans la fenêtre du site, tapez /rename site.
3. Dans l'une des deux, tapez /list-agents : vous voyez les sessions que Claude peut joindre, avec le nom à utiliser pour chacune.

Quand vous écrivez à Claude, vous pouvez aussi taper @ et les premières lettres du nom, par exemple @site, et choisir la session dans le menu. Comme ça, il sait exactement à qui envoyer le message.

Si votre Claude Code ne voit pas les autres sessions, mettez-le à jour vers la dernière version et réessayez. Le test le plus rapide : si /list-agents n'est pas reconnu, votre version n'a pas encore cette fonction.

Les trois façons dont je m'en sers chaque jour

1. L'un construit, l'autre vérifie

Dans la session 1, je fais construire la fonctionnalité. Dans la session 2, j'écris :

Regarde ce que fait la session 1. Lis les modifications qu'elle a faites, essaie de les casser, et si tu trouves une erreur, écris-la-lui et à moi aussi. Ne touche pas aux fichiers.

Ce qui compte, c'est « Ne touche pas aux fichiers ». Celle qui vérifie lit, teste et signale, mais ne corrige pas. Si les deux corrigeaient, elles finiraient par modifier les mêmes choses et vous ne sauriez plus qui a fait quoi. L'erreur est corrigée par celle qui l'a faite, dès qu'elle reçoit le message.

2. Le passage de relais entre l'app et le site

Ici, les deux sessions travaillent dans des dossiers différents, une sur l'app et une sur le site. Dans la session de l'app, j'écris :

Quand tu as fini et que les tests passent, envoie un message à la session du site avec ce qui a changé (noms des champs, adresses, textes), pour qu'elle mette à jour ses pages.

Le message, c'est juste du texte. L'autre session ne voit ni la conversation ni les fichiers de la première : elle lit ce qu'on lui écrit. C'est pour ça que je demande des choses précises, comme les noms des champs, les adresses et les textes, et pas un vague « j'ai changé des trucs ».

Pas besoin de rester là à jouer le réveil. Si la session du site est à l'arrêt, le message la relance. Si elle travaille, elle le lit dès qu'elle a fini l'étape en cours, sans être coupée en plein milieu.

3. L'une cherche, l'autre décide

Dans la session 1 :

Cherche dans le projet tous les endroits où le login est géré et envoie la liste à la session 2.

Dans la session 2 :

Attends la liste de la session 1, puis propose un plan en 5 points. N'écris pas de code tant que je n'ai pas dit ok.

Comme ça, la session qui décide reste propre : elle ne se remplit pas de fichiers lus et de résultats de recherche, elle reçoit seulement la liste. Et ce « N'écris pas de code tant que je n'ai pas dit ok » vous laisse le dernier mot sur le plan.

En plus : faites-vous prévenir quand l'autre a fini

Si vous attendez un long travail dans une autre session, inutile d'aller vérifier toutes les cinq minutes. Dans la session où vous êtes, écrivez :

Préviens-moi quand la session de l'app aura fini ce qu'elle est en train de faire.

Claude demande à l'autre session d'envoyer un avis quand elle s'arrête, et vous le rapporte là où vous êtes.

La règle d'or

Une session, une tâche. Deux sessions sur le même fichier se marchent sur les pieds : si elles doivent toucher aux mêmes fichiers, utilisez une copie du projet pour chacune (ça s'appelle des worktrees, j'en parle dans une autre vidéo).

Un worktree est une copie du projet dans son propre dossier, avec sa propre branche. Chaque session modifie sa copie et ne touche pas à celle des autres. Il faut que le projet soit sous git.

Pour en créer un, il suffit de le demander, en tout premier dans la session :

Travaille dans un nouveau worktree appelé [nom]. Ne touche pas au projet principal.

Depuis le terminal, vous pouvez aussi ouvrir la session directement dans une copie, avec claude --worktree suivi du nom. Et les messages servent justement à ça : quand une session a fini sa partie, elle dit aux autres ce qui a changé.

Les erreurs les plus courantes

• Deux sessions qui modifient les mêmes fichiers dans le même dossier : donnez à chacune son worktree, ou laissez une seule des deux écrire.
• Demander à la session qui vérifie de corriger les erreurs : demandez-lui de les signaler, c'est la session qui a écrit le code qui les corrige.
• Des messages vagues du genre « j'ai changé des trucs » : demandez à Claude d'écrire ce qui a changé avec des noms précis, car l'autre session ne voit que ce texte.
• Des sessions sans nom clair : donnez un nom à chacune avec /rename avant de commencer, pour ne pas écrire à la mauvaise.
• Croire qu'un message peut dire oui à votre place : un message d'une autre session n'approuve rien, les demandes d'autorisation arrivent quand même chez vous.
• Accuser Claude quand il ne trouve pas l'autre session : essayez /list-agents et, s'il n'est pas reconnu, mettez Claude Code à jour.

Check-list

• Deux sessions ouvertes, une par tâche
• Chaque session a un nom, donné avec /rename
• /list-agents affiche l'autre session
• La session qui vérifie a pour consigne de ne pas toucher aux fichiers
• Chaque message dit ce qui a changé, avec des noms précis
• Si elles touchent aux mêmes fichiers, un worktree pour chacune

Questions fréquentes