Étude de cas · équipe produit

Des agents qui livrent sous preuve

Des agents de code écrivent chaque jour dans le dépôt d'une équipe produit. Mon rôle : faire en sorte que rien ne fusionne sans preuve, et que la preuve ne dépende jamais de ce que l'agent affirme.

1. Le problème

Un agent écrit vite. Une équipe ne relit pas plus vite pour autant. Trois risques apparaissent dès les premières semaines :

1. 1.1

   La revue devient le goulot

   Plus de PR, plus grosses, relues moins bien.

2. 1.2

   L'affirmation remplace la preuve

   Un agent peut écrire « tests OK » dans sa PR sans que la CI l'ait confirmé.

3. 1.3

   Le statut ment

   Une PR fusionnée n'est pas un ticket terminé : des validations restent à faire après la fusion.

2. Le dispositif

Cinq règles, chacune avec son état réel. Aucune ne demande de faire confiance à un agent.

1. 2.1

   Une PR à la fois, prouvée sur son commit final

   En place · déclaré

   Revue, correction bornée, preuve, approbation, fusion. La preuve est liée au dernier commit : si la branche de base avance, la CI, la revue et la preuve sont à refaire.

2. 2.2

   L'auteur n'accepte jamais son propre travail

   En place · déclaré

   Un agent reçoit un lot de travail borné ; un autre, qui n'a pas écrit le code, l'accepte ou le refuse. Des tests verts écrits par l'auteur ne valent pas acceptation.

3. 2.3

   Une règle de preuve ne se valide pas elle-même

   En place · déclaré

   Toute modification de la CI, des tests ou des règles de revue passe par un auditeur neuf, en lecture seule, qui vérifie qu'une erreur plantée exprès est bien refusée.

4. 2.4

   La CI fait foi, pas le texte de l'agent

   En cours · déclaré

   Une PR produite par un agent reste en brouillon tant que sa CI n'est pas verte ; le lien du contrôle sert de preuve. Les tests ajoutés sont vérifiés contre les états impossibles en production.

5. 2.5

   Des statuts honnêtes

   En place · déclaré

   Les validations après fusion restent ouvertes jusqu'à leur preuve, y compris quand c'est un agent qui met à jour le ticket.

3. Ce que ça change

Ce qui est en place : une file de fusion où chaque PR porte sa preuve, liée à son commit final, et une délégation où l'auteur n'accepte jamais son propre travail.

Les chiffres avant/après (délai de revue, taille des PR, reprises après fusion) sont en cours de mesure. Ils seront publiés ici avec leur limite, quand ils tiendront.

4. Outils

Claude Code et Codex pour écrire et relire, Cursor en CI, des serveurs MCP pour le contexte, et la CI comme seule source de vérité.

Hors de cette équipe, j'ai publié une partie de cette discipline en open source : semctx, qui calcule ce qu'un diff met en risque avant la fusion.

5. Votre équipe vit la même chose ?

Décrivez votre setup d'agents et ce qui coince. Point d'entrée : le Diagnostic Agents, cinq jours, prix fixe.

Toutes les réalisations