Faire tourner 3 à 8 agents de code en parallèle sans perdre le fil

Lancer deux agents en même temps, tu y arrives en cinq minutes. Tu ouvres deux terminaux, tu donnes une tâche à chacun, et tu regardes le texte défiler.

Le problème arrive au quatrième.

Tu ne sais plus lequel attend une review, lequel a fini, lequel s'est planté il y a dix minutes pendant que tu regardais ailleurs. Tu scrolles dans le mauvais terminal. Tu relances une tâche déjà faite. Et au bout d'une heure, tu fais le travail de trois agents toi-même, à la main, juste pour t'y retrouver.

C'est pas un problème de puissance machine. C'est un problème de visibilité.

Le vrai goulot, c'est ta tête

Un agent qui code en autonomie, ça produit du résultat par à-coups. Il réfléchit 40 secondes, il écrit, il s'arrête, il attend ta validation. Pendant ces 40 secondes, tu peux suivre un deuxième agent. Pendant que le deuxième écrit, tu valides le premier.

Jusqu'à 3 agents, ton cerveau tient le rythme. À partir de 5, tu décroches.

Anthropic a publié un chiffre intéressant dans sa doc : les tentatives non encadrées réussissent environ une fois sur trois. La différence entre les gens qui sortent du volume et les autres, ce n'est pas le modèle. C'est la structure qu'ils mettent autour avant de lancer.

Donc avant de scaler, tu structures.

Règle numéro un : un agent, un workspace isolé

L'erreur classique, c'est de faire bosser trois agents sur la même copie du repo. Ils se marchent dessus. L'un modifie package.json, l'autre aussi, et tu te retrouves avec un merge impossible.

La parade tient en deux mots : git worktree.

git worktree add ../projet-auth feature/auth
git worktree add ../projet-billing feature/billing
git worktree add ../projet-export feature/export

Chaque agent travaille dans son propre dossier, sur sa propre branche, avec ses propres fichiers. Zéro collision. Tu reviews chaque branche séparément et tu merges quand c'est prêt.

C'est la base de ce que les chercheurs appellent la délégation isolée : un manager central découpe le boulot, chaque sous-tâche tourne dans son coin, et l'intégration se fait après, avec des tests pour valider.

Règle numéro deux : ne donne jamais deux fois le même fichier central

Avant de répartir le travail, repère les fichiers que plusieurs features vont devoir toucher. Le routeur. Le schéma de base. Le fichier de config des routes API.

Ces fichiers-là, un seul agent y touche. Les autres attendent ou contournent.

Si tu donnes le même routes.ts à deux agents en parallèle, tu paies en merge conflicts ce que tu croyais gagner en parallélisme. Le calcul est perdant à tous les coups.

Règle numéro trois : un tableau, pas dix terminaux

Voilà le moment où la plupart des gens abandonnent le multi-agent. Ils ouvrent huit onglets de terminal, ils perdent le fil, ils reviennent au mono-agent.

Tu as besoin d'une vue unique qui répond à trois questions, en un coup d'œil :

• Qui code en ce moment ?
• Qui attend ma review ?
• Qui a fini ou planté ?

Sans cette vue, le multi-agent te coûte plus cher en charge mentale qu'il ne te fait gagner en vitesse. Avec, tu peux vraiment tenir 6 ou 8 chantiers en parallèle.

C'est exactement le trou qu'AgentsRoom remplit. Chaque agent a sa tuile, son statut, sa couleur. Un agent qui attend ta réponse passe en rouge et te notifie. Tu ne scrolles plus dans le mauvais terminal, tu regardes le board et tu sais où aller.

La cadence qui marche en pratique

Voici le rythme que je conseille quand tu démarres.

Commence à deux agents, sur deux features qui ne partagent aucun fichier. Prends l'habitude du cycle review puis merge. C'est ce cycle, pas le code, qui devient ton métier.

Quand ce cycle est fluide, monte à quatre. Garde une liste priorisée de tâches à fort impact, et utilise le plan mode à fond : tu valides le plan de l'agent avant qu'il écrive une ligne. Un plan validé en amont t'évite une review douloureuse en aval.

Le point d'équilibre se situe entre 3 et 8 features sur le même repo, avec une supervision visuelle. Au-delà, même avec un bon board, la review devient le goulot et tu perds le bénéfice.

Ce que tu gagnes vraiment

Le multi-agent n'a aucun intérêt pour 95% des petites tâches. Pour corriger un typo ou ajouter un bouton, un seul agent suffit, et c'est même plus rapide.

Là où ça change ton quotidien, c'est sur les gros chantiers. Tu lances trois refactors indépendants un soir, tu reviews au fur et à mesure, et le lendemain matin tu as l'équivalent de trois jours de boulot prêt à merger.

Le secret, ce n'est pas le nombre d'agents. C'est de toujours savoir lequel a besoin de toi, maintenant. Règle ça, et le reste suit.