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

Un agent de code, ça se surveille dans un terminal. Deux, ça se fait à l'onglet. À partir de trois, quelque chose se casse — et ce n'est pas la puissance de votre machine, c'est votre attention. Voici les quatre problèmes qui apparaissent dans cet ordre, et les manières connues de les traiter.

Pourquoi trois est le seuil

Avec un seul agent, vous lisez sa sortie en direct : vous êtes son fil d'exécution. Avec deux, vous alternez, et vous perdez déjà des choses — mais vous les rattrapez en remontant le scrollback. 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. C'est ce dernier point qui coûte le plus cher : un agent bloqué depuis dix minutes sur une question de permission, c'est dix minutes de fenêtre d'abonnement gaspillées et une pile de travail qui ne s'est pas faite.

Problème 1 — Savoir qui est bloqué, sans regarder

La question à laquelle il faut répondre en un coup d'œil est ternaire : il travaille, il vous attend, il a fini. Trois approches existent, par ordre de fiabilité :

• Les hooks du CLI — la plupart des agents modernes savent signaler leur état (ligne de statut, événement de permission, fin de tour). C'est la seule source qui affirme au lieu de deviner. À privilégier partout où c'est disponible.
• Le titre de la fenêtre — beaucoup de CLIs écrivent leur état dans le titre du terminal (séquence OSC). Gratuit, standard, souvent suffisant.
• La lecture du tampon — regarder si l'écran change encore. Ça marche pour distinguer « ça bouge » de « ça ne bouge plus », mais ça ne distingue pas « il réfléchit » de « il attend une réponse ». À garder comme repli, jamais comme vérité principale.

Le piège classique : traiter « plus rien ne bouge » comme « c'est fini ». Un agent qui affiche une question et attend ne bouge pas non plus. Si votre tableau de bord vous dit « terminé » pour les deux cas, il vous ment une fois sur deux.

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 s'arrêtent en vous attendant. Ces deux exigences ne sont contradictoires que si la validation est synchrone.

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

• Refus par défaut sur l'irréversible. Supprimer, pousser sur la branche principale, redémarrer un service : si vous ne répondez pas, la réponse est non.
• Le refus l'emporte sur l'approbation globale. « Tout approuver sauf X » doit exclure X, même si X a été ajouté à la file entre-temps.

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. Beaucoup de gens la font au chronomètre : on revient dans dix minutes, on regarde, on copie-colle. Un enchaînement correct se déclenche sur l'état réel de l'agent (voir problème 1), pas sur une minuterie, et il doit être :

• visible — vous devez pouvoir lire la liste des enchaînements en attente ;
• annulable — vous changez d'avis plus souvent que vous ne le croyez ;
• persistant — il survit à un redémarrage, sinon il vous trahira exactement le jour où ça compte.

Problème 4 — Se souvenir d'un jour sur l'autre

C'est le trou qu'un agent ne peut pas boucher pour 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-là 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 notes réinjectées au tour suivant ;
• les procédures répétées, écrites au format SKILL.md — un standard ouvert que plusieurs écosystèmes lisent déjà.

Un détail qui compte : une procédure écrite par un agent devrait rester désactivée jusqu'à ce que vous la lisiez. Sinon vous vous retrouvez avec un outil qui apprend tout seul des habitudes que vous n'avez jamais validées.

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, c'est ajouter du travail, pas en enlever.