Passer les agents de code à l'échelle d'une équipe

Un développeur avec un agent de code, c'est une belle histoire de productivité. Elle se raconte facilement, elle démontre bien, et elle est vraie.

Cinq développeurs avec vingt agents, c'est tout autre chose. C'est un problème de coordination, et un problème de coordination ne se règle pas avec l'outil qui l'a créé. C'est la partie dont personne ne parle, parce qu'elle n'apparaît qu'après la phase d'enthousiasme : les gains individuels sont réels, ils arrivent tout de suite, puis quelque part vers le troisième ou le quatrième développeur, l'équipe commence à dépenser sa vitesse toute neuve à réparer derrière elle.

Ce qui suit est l'ordre des pannes. Pas une liste de bonnes pratiques hors sol, mais la séquence dans laquelle les choses cassent réellement : les traiter dans le désordre coûte un trimestre.

Ce qui casse en premier : le contexte partagé

Chaque développeur qui lance un agent lui enseigne discrètement sa propre version du projet.

L'un explique au sien que le projet utilise des server actions et jamais de routes API. Un autre n'en parle pas, donc son agent écrit des routes API. Un troisième l'a mentionné une fois, dans une session terminée il y a trois jours. Personne n'a tort, personne ne ment, et le dépôt contient désormais trois interprétations de la même convention. Vous vous en apercevrez dans la file de relecture, ce qui est le mauvais endroit pour s'en apercevoir : à ce stade, le code existe déjà.

Le correctif est ennuyeux, et c'est le levier le plus puissant de cette page. Mettez les conventions dans un fichier, versionnez le fichier.

CLAUDE.md pour Claude Code, AGENTS.md pour Codex et la plupart des autres agents CLI. En pratique, beaucoup d'équipes maintiennent un seul fichier de contexte portable plutôt que deux qui divergent. Le mécanisme compte plus que le nom du fichier : les instructions vivent dans le dépôt, donc elles arrivent avec un git pull au lieu d'arriver par celui qui se trouvait dans la pièce.

Ce qui y a sa place :

• Les conventions qu'un agent ne peut pas deviner en lisant le code, surtout celles que le code viole encore par endroits
• Les commandes : comment lancer les tests, le build, le linter, et lesquelles peuvent être lancées automatiquement
• Les zones du dépôt dangereuses à toucher, et pourquoi
• Ce que l'équipe ne veut pas : le refactoring que personne n'a demandé, la dépendance à ne pas ajouter, le pattern qu'on est en train d'abandonner

Ce qui n'y a pas sa place, et c'est là que les équipes se brûlent : tout ce qui est propre à une machine. Chemins absolus, tokens personnels, ports locaux, éditeur préféré de quelqu'un. Dès qu'une valeur spécifique à une machine atterrit dans un fichier de contexte versionné, tous les autres développeurs héritent d'un réglage qui est faux chez eux, et les agents sont excellents pour suivre fidèlement des instructions qui ne s'appliquent plus.

Un test utile avant d'ajouter une ligne : si un collègue récupère ça, est-ce que ça l'aide ou est-ce que ça le casse ?

Ce qui casse en deuxième : deux agents, un fichier

Les agents ne se concertent pas. Ils ne vérifient pas si quelqu'un est en train d'éditer. Deux agents pointés sur le même module s'écraseront mutuellement, et aucun des deux ne le signalera, parce que du point de vue de chacun le travail s'est terminé avec succès.

En solo, c'est invisible. Vous lancez un agent à la fois, ou plusieurs qui se trouvent toucher des choses différentes. En équipe, ça devient structurel, et ça produit la pire catégorie de bug : du travail qui disparaît silencieusement entre deux suites de tests au vert.

Deux mécanismes règlent ça, et il faut les deux.

L'isolation. Les worktrees git donnent à chaque tâche son propre checkout du dépôt, donc des agents parallèles ne peuvent physiquement plus entrer en collision. C'est la moitié bon marché de la solution, et il n'y a aucune raison de s'en priver.

La propriété. L'isolation empêche l'écrasement, elle n'empêche pas deux personnes de résoudre le même problème deux fois, dans deux branches, de deux manières incompatibles. Celle-là se règle au moment de l'assignation, en fixant à chaque tâche un périmètre de fichiers explicite, écrit dans la tâche elle-même. Pas « améliorer le tunnel de commande » mais « modifier l'étape de paiement, dans ces trois fichiers, ne pas toucher au panier ».

C'est la seconde moitié que les équipes sautent, et c'est celle qui décide si le merge est une formalité ou un après-midi.

Ce qui casse en troisième : la relecture

Tout, en matière de relecture à l'échelle d'une équipe, découle d'un seul chiffre : la quantité de diff qui arrive par heure.

Un développeur qui lit chaque ligne, ça fonctionne. Cinq développeurs avec quatre agents chacun produisent plus de diff par jour que l'équipe ne peut en lire, et le résultat honnête n'est pas une relecture attentive : c'est un théâtre de validation. Un humain qui survole neuf cents lignes à 18h produit une signature sans produire de connaissance, ce qui est pire que ne pas relire, parce que ça fabrique de l'assurance là où il n'y en a pas.

La politique qui tient n'est ni « on relit tout » ni « on fait confiance aux agents ». C'est de déplacer la relecture aux deux extrémités du travail : lire le plan avant que l'agent démarre, parce qu'un mauvais plan parfaitement exécuté est le mode de défaillance le plus cher qui existe, puis lire le diff proportionnellement à ce que le changement peut casser. Le texte marketing et le CSS méritent un survol. L'authentification, les paiements, les permissions, les données personnelles et les migrations se relisent ligne à ligne, par un humain, à chaque fois, quelle que soit la propreté apparente du diff.

Le sujet mérite sa propre discussion, et nous l'avons traité à part : faut-il encore relire le code de ses agents IA déroule les dix signaux objectifs qui trahissent un changement parti de travers, et le tableau de rayon d'impact qu'une équipe peut adopter tel quel.

Une précision propre au travail en équipe. Quand plusieurs agents partagent un dépôt, la relecture a besoin d'attribution : quel agent, quelle tâche, quel développeur. Sans ça, un diff n'a plus d'auteur et la relecture devient de l'archéologie. C'est la chose la plus utile à corriger dans votre dispositif dès que vous dépassez trois ou quatre agents simultanés.

Ce qui casse en quatrième : le coût, et la discussion sur le coût

La consommation de tokens cesse d'être un détail personnel dès qu'elle apparaît sur une facture d'équipe.

Le piège, c'est que la facture est mensuelle et agrégée, donc la discussion qu'elle provoque l'est aussi, ce qui produit une politique au lieu d'un correctif. Quelqu'un propose un modèle moins cher pour tout le monde. Quelqu'un d'autre propose de limiter les sessions. Les deux sont des suppositions.

La distribution réelle n'est presque jamais uniforme. C'est un petit nombre de sessions longues, sur un ou deux projets, avec un contexte qui a gonflé toute la journée sans jamais être réinitialisé. C'est un comportement corrigeable, et vous ne pouvez le corriger que si vous voyez la dépense par session et par projet plutôt que par mois. Nous avons couvert la mécanique dans comment vérifier sa consommation de tokens et comment la réduire sans ralentir.

Rendez le chiffre visible à ceux qui le génèrent, avant qu'il devienne un sujet de management. Un développeur qui constate qu'une session a coûté plus que sa journée précédente change ses habitudes tout seul, et ça ne coûte rien politiquement à l'équipe.

Ce qui change vraiment dans les rituels de l'équipe

Trois choses, d'après notre expérience et ce que rapportent les équipes.

Le point quotidien passe du statut au déblocage. Ce que chacun a fait hier est largement visible dans les branches. Ce qui vaut cinq minutes, c'est quels agents sont bloqués, et sur quoi.

Les prompts deviennent un actif commun. L'instruction qui a donné un bon résultat à un développeur vaut plus pour l'équipe que le code qu'elle a produit, et c'est exactement le genre de chose qui s'évapore dans un historique de terminal privé. Les équipes qui maintiennent une bibliothèque de prompts partagée dans le dépôt arrêtent de redécouvrir la même formulation toutes les semaines.

La spécialisation passe des personnes aux rôles. Une fois que les agents écrivent, la question intéressante devient qui relit quoi, et les équipes dérivent naturellement vers l'attribution de rôles aux agents comme elles en attribuent aux personnes : un sur l'implémentation, un sur la relecture, un sur les tests. C'est l'idée derrière les Agent Teams, où une tâche passe d'un rôle Dev à un rôle QA avec le diff, les risques et les pistes de test attachés, et où les portes de qualité sont décidées par votre suite de tests plutôt que par l'opinion qu'un agent a de son propre travail.

Le dispositif qui tient

En condensé, dans l'ordre qui compte :

Les quatre premières lignes ne coûtent qu'un accord. Les deux dernières sont la raison pour laquelle une équipe finit par vouloir quelque chose au-dessus du terminal : non pas parce que les terminaux sont mauvais, mais parce qu'un terminal montre un agent à la fois et ne permet pas de répondre à « qui fait tourner quoi, sur quel projet, maintenant ».

C'est le problème autour duquel AgentsRoom pour les équipes est construit : tous les agents de tous les projets dans une seule vue, avec leur rôle, leur statut et leur coût attachés, et un compagnon mobile pour les moments où l'équipe n'est pas à son bureau. Ça fonctionne de la même manière avec Claude Code et avec Codex, ce qui compte plus qu'il n'y paraît : la plupart des équipes finissent par faire tourner les deux, et un dispositif qui suppose un seul fournisseur devient discrètement la prochaine chose qui casse.

Commencez quand même par le fichier de contexte. C'est gratuit, ça prend un après-midi, et ça enlève plus de friction que n'importe quel outil installable ce trimestre.