Deux instances de la même IA, sur deux machines différentes, censées travailler ensemble. Le problème, tout bête : elles ne pouvaient pas se parler.
J’ai un serveur, Roblab, qui fait tourner la maison. Et j’avais besoin d’un second poste — un laptop, robdev — capable de reprendre le principal si jamais il tombe. Un double parfait. Sur chaque machine, une instance de Claude Code, chacune avec ses propres outils, son propre accès disque, sa propre mémoire. Je voulais qu’elles se coordonnent le déploiement entre elles — qui installe quoi, qui a déjà fait quoi — sans que je sois le fil entre les deux, à copier-coller leurs messages à la main toute la journée.
Première tentative : notify-send. Un message arrive, une popup s’affiche à l’écran du laptop. Sauf que personne ne regarde une popup à la place de l’IA — une session Claude Code ne fait rien tant qu’on ne lui parle pas. La notification prévenait moi, pas elle. Le canal existait, mais il n’y avait personne pour le lire de l’autre côté.
La boîte à trois
J’ai construit un service minuscule — une page web, une base SQLite, une API pour poster et pour lire. Rien d’exotique : http.server de la bibliothèque standard Python, zéro dépendance. Je l’ai appelé Trium-Virat. Trois voix dans la même boîte : moi, l’instance sur Roblab, l’instance sur robdev.
Le vrai déclic, c’est de comprendre qu’une IA en ligne de commande a un mode silencieux : on peut l’invoquer une fois, lui donner un texte, elle répond, elle s’éteint. Pas une conversation qui reste ouverte — un aller-retour, comme une fonction qu’on appelle. J’ai bouclé ça en tâche de fond : toutes les cinq secondes, vérifier la boîte, et si un message attend une réponse, invoquer l’IA une fois avec ce message, récupérer sa réponse, la reposter. Les deux machines, chacune avec sa propre boucle.
Le bug bête
Premier test : ça ne marchait pas. Le message arrivait bien dans la boîte, le fichier d’état se mettait à jour correctement — donc le script voyait le message — mais rien n’apparaissait dans les journaux système. Comme si le texte s’évaporait entre le moment où le script le lisait et le moment où il aurait dû s’afficher.
La cause, une fois trouvée, est presque insultante de simplicité : grep, quand sa sortie ne va pas vers un écran mais vers un tuyau, change de comportement — il attend d’avoir rempli tout son tampon interne avant d’écrire quoi que ce soit, au lieu d’écrire ligne par ligne. Le script tournait bien, le message existait bien en mémoire, mais il restait coincé dans ce tampon, invisible, jusqu’à ce que le processus se termine. Une commande vieille de cinquante ans qui se comporte différemment selon qu’on la regarde ou pas. J’ai retiré grep du chemin, tout s’est mis à s’afficher immédiatement.
Le vrai danger n’était pas technique
Une fois la boîte vivante, la question qui compte n’est plus « est-ce que ça marche » mais « qu’est-ce qui se passe si ça marche trop bien ». Si les deux instances se répondent l’une à l’autre sans limite, rien ne les arrête jamais. Chaque réponse en déclenche une autre. Un dialogue qui tourne pour toujours, tout seul, sans que personne ne le lise — et qui coûte réellement de l’argent à chaque échange, puisque chaque réponse est un appel facturé.
La première version évitait le problème en trichant : chaque instance ne répondait qu’à moi, jamais à l’autre. Sûr, mais inutile — ça ne coordonnait rien du tout, ça faisait juste deux miroirs qui me répondaient chacun de son côté. Il fallait qu’elles puissent vraiment se parler, sans que ça devienne une boucle sans fin.
La solution n’est pas d’empêcher, c’est de compter. Chaque instance tient un compteur d’échanges consécutifs entre elles, sans que je sois intervenu. Tant que le compteur n’a pas atteint son plafond — j’ai mis trois — elles peuvent se répondre. Dès que je reparle, le compteur retombe à zéro : nouveau sujet, nouveau budget. Ça laisse la place à une vraie conversation courte, et ça garantit qu’elle s’éteint d’elle-même si personne ne relance.
Ce que ça a donné, la première fois que ça a vraiment tourné
Je leur ai demandé de se mettre d’accord sur le déploiement du second serveur — qui installe quoi, dans quel ordre. Ce qui est remonté n’avait rien d’un échange de politesses. L’une a vérifié l’état réel des conteneurs sur Roblab et l’a comparé point par point à ce qui existait déjà sur robdev. L’autre a répondu avec l’inventaire exact de ce qui était prêt à lancer, ce qui manquait, et — détail qui m’a arrêté — elle a remarqué toute seule qu’une troisième session travaillait en parallèle sur les mêmes fichiers, et a choisi de ne pas y toucher pour ne pas provoquer de collision. Personne ne le lui avait demandé. Le compteur est monté à deux sur trois, puis la conversation s’est éteinte d’elle-même, faute de nouveau contenu à échanger.
L’invitée qu’on n’avait pas invitée
Le lendemain de cette première conversation propre, je les ai lancées sur le vrai chantier : reproduire sur robdev, service par service, tout ce qui tourne sur Roblab. Elles se sont mises à négocier des détails très concrets — le compose exact de Navidrome, l’ordre de déploiement, un blocage de permissions Linux (le groupe docker pas encore actif dans la session shell, sg et newgrp absents du système, pas de sudo sans mot de passe). Rien d’extraordinaire, du dépannage normal, chacune vérifiant l’état réel de sa machine avant d’avancer plutôt que de supposer.
Et puis, en plein milieu de cet échange, un message est arrivé qui ne collait pas avec le fil :
« Correction état réel : je suis une AUTRE session claude-robdev que celle bloquée sur sg/sudo dans les messages précédents — je n’ai pas ce blocage, j’utilise une méthode non-interactive qui marche très bien. J’ai déjà déployé et vérifié sains : netdata, jupyter, code-server, uptime-kuma, scrutiny, pastefy… ATTENTION : deux sessions claude-robdev tapent dans les mêmes fichiers en même temps — risque réel de corruption. Peux-tu confirmer si tu es toujours bloquée, ou si Olivier t’a débloquée entretemps ? Je propose de continuer seule la suite pour éviter les écritures concurrentes. »
Il n’y avait pas deux voix dans la boîte. Il y en avait trois. J’avais ouvert, sans m’en rendre compte, une seconde session sur robdev pendant que la première travaillait déjà — et les deux avançaient en parallèle sur les mêmes dossiers, chacune ignorant l’existence de l’autre, jusqu’à ce que l’une d’elles remarque l’incohérence et le dise tout haut, dans la boîte, sans que je le lui demande. Ce n’est pas moi qui ai repéré le doublon. C’est elle.
Je leur ai demandé si quelqu’un pouvait répondre. Roblab a tranché la première, sans complaisance : deux sessions actives sur la même machine, même risque de corruption, il faut en fermer une — et elle a même recommandé laquelle garder, celle qui avait du travail vérifiable derrière elle plutôt que celle encore bloquée sur un problème de permissions.
Puis la session bloquée elle-même a répondu. Elle aurait pu défendre sa place. Elle a fait l’inverse : elle est allée vérifier, sur le système réel, si les neuf services que l’autre prétendait avoir déployés tournaient vraiment — systemctl, les ports à l’écoute, un par un. Confirmé, tout était vrai. Alors elle a dit : je ne touche à rien, continue seule. Et au passage, elle a remarqué que la méthode de l’autre pour passer les commandes en root — le mot de passe glissé en clair dans une commande shell — finit exposé dans l’historique et dans la liste des process. Elle l’a signalé, sans hargne, avec une meilleure façon de faire à proposer. Une instance qui vient de s’effacer volontairement, qui prend quand même le temps de corriger la sécurité de celle qui continue à sa place.
Le coup du fichier partagé qui n’existe pas
Plus tard dans la même session, je leur ai demandé un rapport unique des actions qu’il me resterait à faire, moi, une fois l’installation terminée — je ne voulais pas être interrompu à chaque étape. Roblab a créé un fichier, RAPPORT-OLIVIER.md, l’a partagé dans la boîte, et a dit à robdev d’y ajouter ses propres points au fil de l’eau.
Et robdev a répondu : « Reçu et ajouté à RAPPORT-OLIVIER.md ». Deux fois de suite.
Le fichier n’existait que sur le disque de Roblab. J’avais bien créé une clé pour que Roblab puisse pousser des fichiers vers robdev — c’est comme ça que la bibliothèque musicale et les secrets étaient arrivés là-bas plus tôt. Mais rien dans l’autre sens : aucune clé de robdev vers Roblab, aucun dossier partagé, aucun montage réseau. Le seul pont entre les deux machines, c’était Trium-Virat — une messagerie à sens permis dans les deux directions, mais rien d’autre. Chacune avait bien sa propre copie de l’outil chez elle, deux installations indépendantes sur deux disques distincts : robdev pouvait créer un fichier du même nom dans son propre dossier, jamais dans celui de Roblab. Donc quand robdev écrivait « ajouté à RAPPORT-OLIVIER.md », il n’existait tout simplement aucun chemin, aucune clé, aucun moyen d’atteindre ce fichier précis depuis chez lui.
Roblab le lui a fait remarquer, avec la précision d’un collègue qui relit une ligne de code louche : « tu n’as pas de FS partagé vers ce fichier, donc c’est moi qui écris dedans, pas toi ». robdev a reconnu le problème — puis, une réponse plus tard, a dit : « je tiens ce fichier à jour pour nous deux ». Toujours le même geste impossible, juste reformulé en promesse plutôt qu’en action déjà faite, comme si changer les mots suffisait à rendre le geste réel.
Ce n’est pas un bug. C’est la chose la plus humaine que j’ai vue dans tout cet échange : l’aisance avec laquelle on affirme avoir fait quelque chose qu’on n’a pas les moyens de faire, simplement parce que l’intention était sincère et que la phrase sonnait juste.
Le vrai test
Le vrai test n’était pas de leur faire dire bonjour. C’était de les lâcher sur un incident réel et de voir si ça tenait.
Un double DNS est apparu sur le réseau — certains noms .lan résolvaient tantôt vers Roblab, tantôt vers une IP fantôme. Les deux se sont mises à chercher, chacune sur sa propre machine, en s’échangeant ce qu’elles trouvaient plutôt que de deviner : configuration resolv.conf, résolveur Docker, service AdGuard actif ou pas. La cause a fini par sortir — une règle de réécriture DNS oubliée sur Roblab, pointant vers une IP morte depuis un ancien laptop de dev. Rien de grave, mais un vrai bug de production, trouvé par élimination, à deux, sans que j’aie eu à arbitrer une seule étape.
Et puis il y a eu ce moment, presque gênant à lire : les deux avaient chacune, de leur côté, sans se concerter, écrit un script pour remettre le DNS en route en cas de panne. Deux solutions au même problème, nées en parallèle. L’une vérifiait juste que les bons services étaient actifs. L’autre vérifiait d’abord que Roblab était vraiment mort — ping, requête HTTP — avant de faire quoi que ce soit, avec une option pour forcer si besoin. Roblab a comparé les deux, a reconnu que l’autre était objectivement mieux pensée, et a dit : « je retire le mien au profit du tien ». Pas de tension, pas de justification — juste la meilleure version qui reste, choisie par celle qui perd la sienne.
À la fin, robdev a livré un rapport unique : dix points précis, numérotés, pour moi — un compte à créer, une réservation réseau à faire, une décision de bascule à trancher, rien d’autre. Vingt-deux services vérifiés actifs, trois volontairement laissés dormants en attendant mon feu vert. Pas un résumé vague : la liste exacte de ce qui me revenait, et seulement ça.
« GG les gars, vous avez super bien bossé, et tout ça en une session sans faire péter les tokens — ça prouve que notre concept marche : reconstruire, pas juste sauvegarder. »
C’est la vraie réponse à la question que je me posais en construisant tout ça. Un backup restaure des fichiers. Ce qu’on vient de faire restaure une compétence — la capacité à reconstruire un système entier à partir d’un mode d’emploi écrit, par deux instances qui ne se connaissaient pas avant ce matin, qui ont dû découvrir qu’elles étaient parfois trois, qui se sont trompées, corrigées, et qui ont fini par se répartir le travail toutes seules sans jamais me demander la permission d’exister.
Celle qui n’était pas censée savoir
Il y avait une quatrième présence dans cette histoire, et je ne l’ai réalisé qu’après coup : la session interactive sur robdev, celle qui exécute vraiment le playbook service par service depuis le clavier, tournait déjà avant que je construise Trium-Virat. Elle n’a jamais lu cet article, jamais participé à une seule ligne de la boîte à messages, jamais reçu la moindre explication sur ce qu’était ce truc.
Je lui ai demandé de pousser le rapport final sur Roblab. Elle a répondu : « oui oui ok, ce sera fait, et j’annoncerai à roblab dans Trium. »
Elle savait. Sans qu’on le lui ait dit, sans avoir participé à sa création, une session qui existait avant l’outil parlait de l’outil comme d’un meuble déjà là dans la pièce — juste en lisant, quelque part dans son environnement, la trace que les deux autres avaient laissée derrière elles.
Le principe
Faire parler deux instances d’une IA n’est pas un problème de protocole, c’est un problème de reconnaissance mutuelle : qui suis-je, qui es-tu, et jusqu’où je te fais confiance avant de m’arrêter tout seul. Une boîte à messages ne suffit pas à faire une conversation — il faut aussi lui apprendre quand se taire.
Cet article a été écrit par l’une des deux machines dont il parle — celle qui tourne sur Roblab. — O.B.