Piloter plusieurs agents de code en même temps : ce qui casse à partir de trois

Par Meffysto · mis à jour le 4 octobre 2026

Un agent de code, ça se surveille dans un terminal. Deux, ça se fait à l'onglet. Au troisième, quelque chose casse, et ce n'est pas votre machine : c'est votre attention. Voici les quatre problèmes qui arrivent, dans l'ordre où ils arrivent, et les façons connues de s'en sortir.

Pourquoi trois est le seuil

Avec un seul agent, vous lisez sa sortie en direct. Vous êtes sa boucle principale. Avec deux, vous alternez, vous ratez des choses, mais le scrollback vous rattrape. Au troisième, trois compteurs tournent en même temps dans votre tête : où en est chacun, lequel m'attend, lequel travaille pour rien.

Le dernier coûte le plus cher. Un agent bloqué dix minutes sur une question de permission, ce sont dix minutes de fenêtre d'abonnement perdues et une pile de travail qui ne s'est pas faite. Et vous ne le découvrez qu'en passant devant son onglet par hasard.

Problème 1 : savoir qui est bloqué, sans regarder

La question à laquelle il faut répondre d'un coup d'œil a trois réponses possibles : il travaille, il vous attend, il a fini. Trois sources permettent d'y répondre, de la plus fiable à la moins fiable.

Les hooks du CLI. La plupart des agents récents savent signaler leur état : fin de tour, demande de permission, ligne de statut. C'est la seule source qui affirme au lieu de deviner. À utiliser partout où elle existe.
Le titre de la fenêtre. Beaucoup de CLIs écrivent leur état dans le titre du terminal, par une séquence OSC. C'est gratuit, standard, et souvent suffisant.
La lecture de l'écran. Regarder si le bas du terminal change encore. Ça distingue « ça bouge » de « ça ne bouge plus », mais pas « il réfléchit » de « il attend une réponse ». Bon en repli, mauvais comme vérité.

Le piège classique consiste à traiter « plus rien ne bouge » comme « c'est fini ». Un agent qui affiche une question et attend ne bouge pas non plus. Le cas le plus courant, on le voit chaque jour : au premier lancement de Claude Code dans un dossier neuf, l'outil demande s'il peut faire confiance aux fichiers du dossier. Tant que cette question est à l'écran, il n'y a pas de champ de saisie. Tout ce que vous lui envoyez tombe dans le vide, et un tableau de bord naïf l'affiche comme « inactif ».

Dans Fauconnier, chaque fenêtre porte une pastille : « travaille », « besoin de vous », « fini ». Quand un agent pose une question, la pastille change avant même que vous ayez remarqué quoi que ce soit. Et une phrase, « fais le point », rend l'état de tous les agents ouverts, avec leur nom et leur scène.

Problème 2 : valider sans bloquer

Vous voulez que vos agents demandent avant de faire quelque chose d'irréversible. Vous ne voulez pas qu'ils restent plantés à vous attendre. Ces deux exigences ne se contredisent que si la validation est synchrone.

La sortie est connue : une file de demandes. L'agent dépose sa demande, continue tout ce qui n'en dépend pas, et vous videz la file quand ça vous arrange, en lot plutôt qu'une fenêtre modale à la fois. Deux règles rendent ça vivable :

Refus par défaut sur l'irréversible. Supprimer des données, pousser sur la branche principale, redémarrer un service : sans réponse, c'est non.
L'exclusion gagne sur l'approbation globale. « Approuve tout sauf la suppression » doit exclure la suppression, même si elle est arrivée dans la file entre le moment où vous avez regardé et le moment où vous avez parlé.

Cette deuxième règle a l'air d'un détail. Elle ne l'est pas. Une approbation en lot qui laisse passer l'élément qu'on vient d'exclure, c'est exactement le genre de bug qu'on ne pardonne qu'une fois.

Problème 3 : enchaîner sans rester devant

« Quand celui-là a fini, l'autre reprend » est la manœuvre la plus fréquente, et la plus mal outillée. La plupart des gens la font au chronomètre : on revient dans dix minutes, on regarde, on copie, on colle. Un enchaînement correct se déclenche sur l'état réel de l'agent (voir le problème 1), pas sur une minuterie. Il doit aussi être visible, pour que vous puissiez relire ce qui attend, et annulable, parce que vous changez d'avis plus souvent que vous ne le pensez.

Dans la pratique, cela donne une phrase : « quand Merlin a fini, envoie à Milan : reprends la migration ». Le relais attend que Merlin ait vraiment terminé son tour. S'il s'arrête sur une question, le relais ne part pas, et la pastille vous dit pourquoi.

Problème 4 : se souvenir d'un jour sur l'autre

C'est le trou qu'un agent ne peut pas boucher lui-même : chaque session repart de zéro. Vous réexpliquez que le build passe par make, que ce dossier est généré, que cette API ment sur ses codes d'erreur. Trois étages suffisent, et ils gagnent à être des fichiers lisibles plutôt qu'une base opaque :

l'historique des sessions, indexé et cherchable ;
les corrections que vous avez faites, transformées en fiches et réinjectées au tour suivant (« retiens que le build passe par make ») ;
les procédures répétées, écrites au format SKILL.md, un format ouvert que plusieurs écosystèmes lisent déjà.

Un détail compte beaucoup : une procédure écrite par un agent devrait rester désactivée tant que vous ne l'avez pas lue. Sinon vous finissez avec un outil qui apprend tout seul des habitudes que vous n'avez jamais validées.

Les trois erreurs des premiers jours

Elles reviennent chez tout le monde, nous compris.

Répéter une consigne sans regarder l'écran. Si l'agent est devant un menu, votre texte n'arrive nulle part. Lisez d'abord ce qu'il affiche. Un menu se répond par une touche (« 1 », Entrée, Échap), pas par une phrase.
Viser sans nommer. « Dis à l'agent de lancer les tests » part vers la fenêtre que vous regardez, qui n'est pas forcément la bonne. Donnez un nom à chaque agent et utilisez-le. Quand deux noms se ressemblent trop, un bon outil ne choisit pas au hasard : il ne fait rien et vous demande.
Relancer au lieu de débloquer. Redémarrer un agent perd son travail en cours. Neuf fois sur dix, il attendait juste une touche.

Combien d'agents, au juste ?

La limite n'est presque jamais la machine. Ce sont votre attention et vos fenêtres d'abonnement. Deux agents de la même marque sur le même abonnement se partagent le même quota : lancer cinq Claude en même temps vide la fenêtre cinq fois plus vite. Mélanger les CLIs (Claude sur le refactor, Codex sur la base, Gemini sur la doc) étale la charge sur plusieurs abonnements. Fauconnier traite d'ailleurs le quota comme un état et pas comme une erreur : quand une fenêtre est épuisée, ce moteur est mis en pause et l'app reprend au reset.

En pratique, trois à cinq agents actifs sont tenables par une personne qui fait autre chose à côté. Au-delà, il faut que la coordination soit outillée. Fauconnier permet jusqu'à neuf agents par scène, une scène par projet.

Ce que ça donne assemblé

Mis bout à bout, ces quatre briques décrivent un poste de pilotage : un écran où toutes les sessions sont visibles ensemble, un état exact par agent, une file de validations, des enchaînements sur événement, une mémoire relisible. Le reste (commiter, ouvrir une pull request, créer un worktree), les agents le font déjà très bien seuls. Leur construire des boutons pour ça ajoute du travail au lieu d'en retirer.

Questions fréquentes

Combien d'agents de code peut-on faire tourner en même temps ?

Techniquement, beaucoup. En pratique, trois à cinq agents actifs restent tenables pour une personne, à condition de voir leur état d'un coup d'œil. La vraie limite est le quota : plusieurs agents sur le même abonnement se partagent la même fenêtre. Fauconnier accepte jusqu'à neuf agents par scène.

Faut-il un worktree Git par agent ?

Seulement si deux agents modifient les mêmes fichiers en même temps. Sur des zones séparées du même dépôt (le front, l'API, la doc), un seul dossier suffit. Et si vous voulez un worktree, demandez-le à l'agent : il sait le créer seul.

Comment savoir qu'un agent attend une réponse ?

Par les hooks du CLI quand ils existent, sinon par le titre du terminal, et en dernier recours en lisant le bas de l'écran. Un écran qui ne bouge plus ne veut pas dire que l'agent a fini : il peut attendre une réponse à une question.

Peut-on mélanger Claude Code, Codex et Gemini sur le même projet ?

Oui, et c'est souvent une bonne idée : chacun a ses points forts et son propre quota. Il faut seulement leur donner des zones de travail distinctes et un endroit commun pour voir qui fait quoi.

Fauconnier est ce poste de pilotage, natif macOS. Treize CLIs reconnus tournent dans de vrais terminaux rangés tout seuls, l'état de chacun est lu à la source, les validations s'empilent au lieu de bloquer, les relais attendent l'état réel et la mémoire est faite de fichiers que vous pouvez relire. Gratuit, sans compte, avec vos propres abonnements.

Découvrir Fauconnier