Multi-agents et multi-staging : pourquoi l'un ne va pas sans l'autre

Le parallélisme, d'abord. Pendant qu'un agent corrige un bug, un autre rédige une page, un troisième met à jour une dépendance. Tant que ces tâches ne touchent pas les mêmes fichiers, le temps total se rapproche de celui de la tâche la plus longue, pas de leur somme.

Un contexte propre par tâche, ensuite. La fenêtre de contexte d'un agent se dégrade à mesure qu'elle se remplit. Trois agents qui portent chacun une tâche travaillent mieux qu'un seul agent qui en enchaîne trois dans la même conversation.

Un regard neuf, enfin. Séparer l'agent qui écrit de celui qui relit reproduit ce qu'on fait entre collègues : la relecture vient de quelqu'un qui n'a pas pris les décisions et n'a pas de raison de les défendre.

Les chiffres publiés vont dans ce sens, avec leur prix. Anthropic a décrit en juin 2025 son système de recherche multi-agents : un agent principal (Claude Opus 4) qui délègue à des sous-agents (Claude Sonnet 4) a dépassé un agent seul de 90,2 % sur son évaluation interne de recherche. Le même article précise qu'un tel système consomme environ 15 fois plus de jetons qu'une conversation, et que la plupart des tâches de code se prêtent moins au parallélisme que la recherche.

Plusieurs agents dans le même dossier se marchent dessus. L'un modifie un fichier pendant que l'autre le lit, l'un change de branche sous les pieds de l'autre, deux serveurs de développement se disputent le même port, deux jeux de tests écrivent dans la même base. Le résultat n'est pas une erreur franche : c'est du code qui a l'air de marcher, mais pas pour la raison que l'on croit.

Les décisions implicites se contredisent. Cognition, l'éditeur de Devin, l'a formulé en juin 2025 dans un article au titre sans détour, « Don't Build Multi-Agents » : chaque action porte des décisions implicites, et des décisions qui se contredisent donnent de mauvais résultats. Deux agents qui construisent chacun une moitié de la même fonctionnalité, sans voir le travail de l'autre, choisissent deux conventions différentes.

La vérification devient le goulot. Un humain relit un diff à la fois. Si cinq agents produisent cinq diffs, et que la seule façon de les voir tourner est de les fusionner un par un dans un staging partagé, le gain de vitesse s'arrête à la porte du staging, ou pire, on fusionne sans avoir vu.

L'isolation du code, d'abord, avec les worktrees git : des copies de travail séparées du même dépôt, chacune sur sa branche, qui partagent l'historique. Claude Code les crée lui-même (claude --worktree nom-de-la-tâche, ou isolation: worktree pour un sous-agent), sous .claude/worktrees/, et bloque les modifications qui viseraient la copie principale. Un worktree est une copie neuve : les dépendances s'y installent, et un fichier .worktreeinclude permet d'y recopier les fichiers non versionnés comme .env.local.

L'isolation de l'exécution, ensuite, avec un environnement de prévisualisation par branche. Sur Vercel, où ce site est hébergé, chaque push sur une branche autre que la branche de production crée un déploiement de prévisualisation, avec deux adresses : une URL de branche, qui suit le dernier commit, et une URL de commit, figée. Chaque branche d'agent a donc son site en fonctionnement, que l'on ouvre sans rien installer, et que Vercel n'expose pas aux moteurs de recherche par défaut.

L'isolation des données et des secrets, enfin. Les variables d'environnement se définissent par environnement, et même par branche pour la prévisualisation : une branche d'agent pointe vers une base de test et des clés de test, jamais vers celles de la production. Certaines bases de données gérées savent créer une copie de données par branche ; à défaut, une base de recette commune, réinitialisable, suffit pour la plupart des PME.

Au-dessus des prévisualisations, un staging partagé garde son rôle : vérifier que les branches fusionnées tiennent ensemble. Vercel le permet sur tous les plans avec une branche staging dotée de son domaine, ou, sur les plans Pro et Enterprise, avec un environnement personnalisé (un inclus par projet sur Pro). Et pour le dernier contrôle, un déploiement de production peut être construit puis promu à la main, sans reconstruction.

Voici le chemin que nous utilisons, et qu'a suivi cet article. Un ticket décrit le résultat attendu et ses critères d'acceptation, dont une commande de test. Un agent rédacteur reçoit ce ticket dans son worktree, sur une branche qui porte le numéro du ticket.

L'agent travaille, puis lance lui-même la vérification : sur ce site, npm test enchaîne la vérification des types et le build complet. Tant qu'elle échoue, il corrige ; au bout d'un nombre d'essais fixé à l'avance, il s'arrête et passe la main à un humain plutôt que de tourner en rond.

La branche poussée produit sa prévisualisation. Un second agent, ou une personne, relit le diff et ouvre l'URL de la branche : la page s'affiche-t-elle, le lien fonctionne-t-il, le texte dit-il ce qu'il doit dire ? Ce relecteur n'a pas écrit le code, et il juge un site qui tourne, pas une description.

La fusion dans la branche principale reste une décision humaine, et c'est elle seule qui déclenche le déploiement en production. Pendant ce temps, d'autres agents ont fait la même chose sur d'autres tickets, chacun dans son couloir. Le staging partagé ne voit que ce qui a déjà passé ces étapes.

Un agent, une tâche, une branche. Pas deux agents sur la même branche, pas une tâche découpée entre agents qui devraient se mettre d'accord en cours de route. Si deux parties d'une fonctionnalité dépendent l'une de l'autre, elles vont au même agent, ou elles se font l'une après l'autre.

Des droits plus étroits que ceux d'un développeur. Un agent ne pousse jamais sur la branche principale, ne déploie jamais en production, n'écrit jamais dans une base autre que de test. Ces interdits s'écrivent dans les permissions et la protection de branche du dépôt, pas seulement dans une consigne.

Un critère de fin qui ne vient pas de l'agent. Les critères d'acceptation sont fixés dans le ticket avant le travail, et la prévisualisation montre le résultat. « Terminé » veut dire que les tests passent et que quelqu'un a vu la page, pas que l'agent l'affirme.

Pas plus d'agents que de capacité de relecture. Le bon nombre d'agents en parallèle n'est pas celui que la machine supporte, c'est celui dont l'équipe peut relire les diffs dans la journée. Au-delà, les branches s'accumulent, divergent de la branche principale, et les conflits de fusion mangent le temps gagné.

Du ménage. Les worktrees, les branches et les déploiements de prévisualisation s'accumulent vite. Supprimez la branche après la fusion, et laissez les outils retirer les worktrees propres.

Si vous n'avez pas encore un agent qui travaille bien seul. Plusieurs agents multiplient ce qu'un agent fait : de bonnes habitudes comme de mauvaises. Le CLAUDE.md, le plan avant l'écriture et le test que l'agent exécute lui-même viennent d'abord.

Si les tâches ne sont pas indépendantes. Une refonte qui touche le même composant partout, une migration de schéma suivie de son code d'accès : c'est un seul fil, et le découper crée exactement les décisions contradictoires décrites plus haut. Un agent, longtemps, avec un bon plan, fait mieux.

Si personne ne peut relire. Une PME avec un seul développeur gagne déjà beaucoup avec un agent et une prévisualisation par branche. Le multi-staging lui sert dès le premier agent ; le multi-agents, quand la file de tickets indépendants devient plus longue que sa journée.

Et si le coût n'est pas regardé. Chaque agent consomme ses propres jetons, et les environnements personnalisés au-delà de celui inclus se paient par lots. Ce n'est pas un frein, mais un coût à mettre en face du temps gagné, mesuré sur vos tickets.

Anthropic, « How we built our multi-agent research system », 13 juin 2025 : agent principal Claude Opus 4 et sous-agents Claude Sonnet 4, +90,2 % face à un agent seul sur l'évaluation interne, environ 15 fois plus de jetons qu'une conversation, moins de tâches parallélisables en code qu'en recherche. Article Anthropic.

Cognition, Walden Yan, « Don't Build Multi-Agents », 12 juin 2025 : partager le contexte complet, et le principe selon lequel les actions portent des décisions implicites. Article Cognition.

Documentation Claude Code : sessions parallèles avec worktrees (--worktree, .claude/worktrees/, isolation des sous-agents, .worktreeinclude, nettoyage, blocage des modifications de la copie principale). Worktrees, Flux de travail courants.

Documentation Vercel, Environments (mise à jour du 17 septembre 2026) : environnements Local, Preview et Production, déploiement de prévisualisation par branche, URL de branche et URL de commit, variables par environnement et par branche, staging par branche sur tous les plans, environnements personnalisés sur Pro et Enterprise (un inclus par projet sur Pro), promotion manuelle d'un déploiement de production. Environments.

Le flux décrit dans la quatrième section est le nôtre ; ce n'est pas une recommandation d'éditeur.