Pratiques d’équipe

Les deux Étapes précédentes ont équipé la machine : des agents bordés par des garde-fous, un pipeline qui tient leur cadence. Reste l’organisme qui les emploie.

Et c’est là que ça se complique, parce qu’une équipe n’est pas une somme de développeurs assistés. Tant que les pratiques restent individuelles — prompts personnels, conventions implicites, sessions privées — la montée en échelle amplifie les écarts au lieu des acquis.

---

Pourquoi le dossier de contexte devient un bien commun ?

Parce qu’il ne programme plus votre agent : il programme ceux de tout le monde. En solo, le dossier de contexte est votre affaire. En équipe, une ligne ajoutée au fichier d’instructions modifie le comportement de chaque session de chaque membre, dès le prochain pull.

J’aime bien le dire comme ça : une ligne ajoutée au fichier d’instructions, c’est un déploiement. Ce n’est plus une note personnelle, c’est un changement d’outillage collectif — donc ça se modifie par PR, ça se relit, ça se justifie, exactement comme du code. Une consigne que personne n’a validée gouverne pourtant toute la production.

Ce statut clarifie d’ailleurs le sort des conventions. À l’échelle d’une équipe assistée, une convention n’a que trois états possibles :

• Encodée dans un verdict (lint, types, tests) : elle s’applique, aux agents comme aux humains, sans dépendre de la vigilance de qui que ce soit.
• Écrite dans le dossier de contexte : elle se lit à chaque session, et sa violation devient un écart constatable contre un texte.
• Dans la tête d’un membre : elle n’existe pas. L’Étape précédente l’a posé pour les agents ; la croissance de l’équipe le pose pour les humains. Le savoir tribal ne survit ni aux uns ni à l’autre.

Le partage a quand même une frontière nette. Ce qui relève du confort individuel (alias, réglages d’éditeur, prompts d’exploration) reste personnel. Ce qui prétend gouverner la production de l’équipe vit dans le repo, versionné.

Et l’entretien devient collectif : chaque déviation d’un agent, chez n’importe quel membre, est un rapport de bug contre le dossier commun. La correction profite à toutes les sessions de tous les postes. C’est exactement ce qui en fait un actif qui s’apprécie, au lieu de pourrir.

Qui est responsable du code généré ?

L’auteur de la PR. Pas l’agent, pas le modèle, pas l’éditeur de l’outil. C’est la seule réponse compatible avec une équipe qui fonctionne.

« C’est l’agent qui l’a écrit » n’est pas une provenance, c’est une abdication. Je l’ai lu une fois dans un commentaire de PR, et une équipe où cette phrase passe une seule fois vient d’inventer du code dont personne ne répond.

Le standard reste celui que Relire du code qu’on n’a pas écrit impose déjà à l’individu : vous soumettez ce que vous pouvez défendre, ligne à ligne, devant l’équipe. Une PR d’agent arrive donc en revue déjà relue une fois, par son auteur.

La provenance, elle, s’annonce sans détour. Deux lignes suffisent :

> PR produite par un agent autonome à partir de l'issue #412.
> Relue intégralement avant ouverture.

Signaler qu’une PR sort d’un agent n’est pas un aveu, c’est une information de revue : ça dit où porter l’attention. Mais ça ne crée jamais un régime de responsabilité séparé — ni, l’envers du même piège, un standard de qualité au rabais « parce que c’est généré ».

Il y a une raison très concrète à cette intransigeance : le code mergé d’aujourd’hui est le contexte des sessions de demain. Les agents prolongent ce qu’ils lisent, et chaque complaisance intégrée devient le motif que les prochaines générations de code imiteront. Une équipe qui tolère un standard inférieur pour le code généré programme sa propre dérive.

Comment onboarder quand l’équipe est assistée ?

Avec le même document, et sur deux volets. L’arrivée d’un nouveau collègue et le démarrage d’une session d’agent, c’est le même événement : un esprit compétent, ignorant de votre projet, qui lit votre dossier de contexte avant de toucher au code.

Tout investissement dans l’un sert l’autre. Et le nouveau venu est votre meilleur test d’intégration : là où il bute, l’agent butait déjà, silencieusement, à chaque session.

Le deuxième volet est plus neuf, et beaucoup moins bien fait : la transmission du savoir-faire d’assistance lui-même. Spécifier, conduire une session, borner une délégation, relire une sortie — tout ça s’apprend, et ça ne s’apprend pas tout seul. Concrètement :

• des sessions menées en binôme ;
• la relecture des issues écrites pour les agents, au même titre que celle des diffs ;
• un dépôt d’exemples (bonnes spécifications, sessions commentées) qui transforme l’intuition des seniors en matériau transmissible.

LE CRAFTOMANCER

Le raccourci le plus coûteux d’une équipe assistée : laisser les juniors déléguer ce qu’ils ne savent pas encore faire. La délégation repose sur le jugement (spécifier, borner, relire), et ce jugement se construit en faisant. Un junior qui n’a jamais écrit de test ne reconnaîtra pas un test décoratif : il l’approuvera. Réservez à l’apprentissage une part du travail que l’agent aurait pu faire. C’est le prix de vos relecteurs de demain.

Comment répartir la revue sans user l’équipe ?

En l’étageant, et en budgétant l’attention humaine comme la ressource rare qu’elle est. L’Étape précédente a placé l’avis machine dans le pipeline, « La posture » a armé le relecteur individuel. Reste la répartition.

Pour une PR d’agent, trois étages, dont aucun ne remplace les autres :

• L’auteur, premier relecteur, avant même d’ouvrir la PR.
• Le modèle, première passe et tri d’attention, dans les limites que l’Étape sur la CI a posées : il informe, il ne juge pas.
• Un pair humain, qui approuve. Parce qu’approuver engage, et que l’engagement ne se délègue à personne, machine comprise.

Tenir cet étagement à la cadence des agents exige des normes d’équipe, pas des préférences individuelles :

• Des PR petites. La taille d’une PR est une décision collective, et c’est elle qui rend la relecture honnête possible.
• Des refus rapides. Régénérer coûte toujours moins cher que polir en revue une production mal partie.
• Une rotation des relecteurs, pour que la charge ne s’use pas toujours sur les mêmes et que le muscle de revue ne s’atrophie chez personne.

Le risque terminal, c’est le tampon. Une équipe submergée approuve sans lire, et une approbation sans lecture est pire qu’aucune revue : elle fabrique de la confiance sans fabriquer de la vérification.

Savoir si votre revue tient encore ou si elle tamponne, c’est déjà une question de mesure. Elle attendra l’Étape suivante.

En pratique

• Traitez le dossier de contexte comme un bien commun : modifié par PR, relu, justifié. Et corrigé à chaque déviation d’agent, sur n’importe quel poste.
• Une convention est encodée (verdict), écrite (dossier de contexte), ou n’existe pas. Le savoir tribal ne survit ni aux agents ni à la croissance de l’équipe.
• L’auteur d’une PR en répond intégralement, code généré compris. La provenance s’annonce comme information de revue, jamais comme excuse, et jamais comme standard au rabais.
• Onboardez les humains avec le dossier qui onboarde déjà les agents, et transmettez le savoir-faire d’assistance : binômes de session, relecture des spécifications, exemples archivés.
• Gardez aux juniors du travail qui forme le jugement, pas seulement du travail qui supervise.
• Trois étages de relecture (l’auteur, le modèle, un pair) ; des PR petites, des refus rapides, une rotation des relecteurs.

Ces pratiques posées, une question demeure : est-ce qu’elles tiennent ? Cadence soutenable, qualité du code généré, revue qui lit encore. Tout ça prétend s’améliorer, encore faut-il le constater honnêtement. C’est l’objet de l’Étape suivante : mesurer sans se mentir.