Quand la plupart des commits sont écrits avec un agent, le travail du lead change de nature. Il écrit moins. Il décide, il fixe les règles, et il vérifie.
Sur la plateforme où je travaille, c'est le cas depuis 2026. Ce qui manque alors n'est pas la vitesse : c'est le cadre. Cette note dit lequel, et présente l'outil qui en tient une partie : gwm, écrit par mon collègue Kylian Bardini.
Des règles écrites
Un agent ne devine pas ce qu'une équipe tient pour acquis. Les règles qui comptent sont donc écrites, et non négociables : ce qu'on ne fait jamais, et pourquoi.
Elles sont rédigées pour être lues par l'agent comme par un nouveau collègue. Une règle qu'un nouveau venu ne comprendrait pas, l'agent l'appliquera mal.
Un rôle par agent
Un agent qui fait tout fait tout à moitié. Un agent cherche les pannes silencieuses, celles qui ne lèvent aucune erreur ; un autre relit. Chacun a sa consigne, et son travail se juge sur ce qu'il trouve.
Un espace de travail par agent
Plusieurs agents qui travaillent dans le même dossier se marchent dessus. La réponse tient en un mot de Git : le worktree, une copie de travail du même dépôt, sur une autre branche, dans un autre dossier.
Encore faut-il que chaque copie soit prête à servir. C'est ce que fait gwm.
L'outil : gwm, un espace de travail par tâche
gwm est un gestionnaire de worktrees Git écrit en Rust par Kylian Bardini (GitHub), sous licence libre. Sa documentation est complète ; voici ce qui compte quand on encadre des agents.
| Ce qu'il fait | Pourquoi ça compte quand on encadre des agents |
|---|---|
| Crée le worktree, la branche, et lance l'installation du projet | L'agent démarre dans un environnement qui fonctionne |
| Copie les fichiers nécessaires, avec des règles de garde | Un fichier de secrets ne suit pas dans chaque copie |
| Relie le worktree à son ticket ou à sa demande de fusion | Chaque travail d'agent a un sujet et une trace |
| Montre quel agent travaille dans quel worktree | Le lead voit d'un coup qui fait quoi |
| Permet d'annuler une suppression | Une erreur de ménage ne coûte pas une journée |
Sa documentation raconte que les règles de garde viennent d'un incident réel : des identifiants de base de données partis dans un .env copié. C'est le même genre de règle que celles de l'article Trois pannes qui ne disaient rien : elle existe parce que quelque chose a mal tourné une fois.
Premier usage : ce site
J'ai installé gwm sur le dépôt de ce site le 6 octobre 2026 (version 1.10.0, le binaire Windows publié avec la version). Sans aucune configuration, le premier gwm list voyait déjà quel agent travaillait dans quel dossier.
La configuration a révélé un risque que je n'avais pas vu : le .env local pointe vers la base de production, et le préréglage Laravel de gwm copie ce fichier dans chaque worktree. Une règle de quelques lignes l'arrête : si le fichier contient l'adresse de la base distante, gwm repart du modèle .env.example, qui pointe vers une base SQLite locale. Un agent qui travaille dans un worktree ne peut plus écrire sur le site en ligne.
Ensuite, une vraie tâche : une page du site faisait trente requêtes à la base, dont la moitié en double. gwm create a ouvert le worktree, installé les dépendances et rempli la base locale à partir des contenus, en un peu plus de trois minutes, sans intervention. Le correctif et ses tests sont partis de là ; la page est passée à seize requêtes. gwm pr a rédigé le corps de la demande de fusion à partir des commits, et gwm remove a rangé le worktree une fois la fusion faite.
Deux choses à savoir sous Windows : les commandes de préparation passent par sh, il faut donc lancer gwm depuis Git Bash ; et dans la configuration, les expressions régulières s'écrivent entre apostrophes. gwm doctor a signalé la seconde erreur tout de suite.
Des tests qui disent non
Un agent ne sait pas ce qu'il a cassé ailleurs. Les tests le savent pour lui. Sur la plateforme, ils tournent une fois par maison : un agent ne peut pas casser un site en en corrigeant un autre.
Ce site en a donné un exemple le jour même. La première version du correctif gardait en mémoire une liste déjà lue ; un test qui dépubliait un article la retrouvait inchangée. Le test a refusé, et le correctif a été repris avant d'arriver en ligne.
Des décisions écrites
Personne ne se souviendra de ce qui a été tranché en séance, et un agent encore moins : il repart de zéro à chaque session. Les notes de décision deviennent la mémoire de l'équipe, et la première chose qu'un agent lit.
Ce que le lead garde
Un agent propose ; il ne décide pas seul de ce qui engage. Sur ce site, l'agent a ouvert la demande de fusion ; c'est moi qui l'ai fusionnée. Le lead garde ce qui part en production, ce qui touche aux données, et les règles elles-mêmes.
Soutenir l'outil
gwm est libre et fait sur du temps personnel. J'ai défendu dans Le logiciel libre au travail qu'une entreprise qui se sert d'un logiciel libre devrait le financer. gwm accepte les dons via GitHub Sponsors ; signaler un bogue ou proposer une correction aide autant.
Ce que j'en retiens
- Encadrer des agents, c'est écrire : les règles, les rôles, les décisions.
- Un agent par espace de travail, et un espace de travail qui ne voit jamais la production.
- Les tests disent non à la place du lead ; le lead garde ce qui engage.