Pratiques d'équipe

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

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 plutôt que les acquis. Ce guide pose les quatre chantiers du passage à l’équipe : un contexte commun, une responsabilité fixée, une transmission organisée, une revue qui se partage.

---

Le contexte du projet est un bien commun

En solo, le dossier de contexte est votre affaire. En équipe, il programme les agents de tout le monde. Une ligne ajoutée au fichier d’instructions modifie le comportement de chaque session de chaque membre, dès le prochain pull. Ce n’est plus une note personnelle, c’est un changement d’outillage collectif. Et il se traite comme tel : le dossier se modifie par PR, se relit, se justifie, exactement comme du code. Une consigne que personne n’a validée gouverne pourtant toute la production. C’est trop de pouvoir pour un commit silencieux.

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

• Encodée dans un verdict (lint, types, tests) : elle s’applique, aux agents comme aux humains, sans dépendre de la vigilance de quiconque.
• Écrite dans le dossier de contexte : elle se lit à chaque session, et sa violation est un écart constatable contre un texte.
• Dans la tête d’un membre : elle n’existe pas. Le guide précédent 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 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 précisément ce qui en fait un actif qui s’apprécie au lieu de pourrir.

Le code généré a un auteur : celui qui le soumet

La question « qui est responsable du code généré ? » n’admet qu’une réponse compatible avec une équipe qui fonctionne : l’auteur de la PR. Pas l’agent, pas le modèle, pas l’éditeur de l’outil. « C’est l’agent qui l’a écrit » n’est pas une provenance, c’est une abdication. Une équipe où elle passe une seule fois vient d’inventer du code dont personne ne répond.

Le standard est 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 : signaler qu’une PR sort d’un agent autonome n’est pas un aveu, c’est une information de revue, qui dit où porter l’attention. Mais elle 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é ».

Ce refus du double standard n’est pas une posture. Le code mergé d’aujourd’hui est le contexte des sessions de demain. Les agents prolongent ce qu’ils lisent ; 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.

Onboarder : les humains comme les agents

L’arrivée d’un nouveau collègue et le démarrage d’une session d’agent sont 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.

Mais l’onboarding d’une équipe assistée a un deuxième volet, plus neuf : la transmission du savoir-faire d’assistance lui-même. Spécifier, conduire une session, borner une délégation, relire une sortie : ces pratiques s’apprennent, et elles ne s’apprennent pas seules. 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, et un dépôt d’exemples (bonnes spécifications, sessions commentées) qui transforme l’intuition des seniors en matériau transmissible.

Le tips 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.

La revue croisée : organiser l’attention

Le guide précédent a placé l’avis machine dans le pipeline ; « Garder le craft » a armé le relecteur individuel. Reste la répartition. Parce que l’attention humaine est la ressource la plus rare du système, et à l’échelle d’une équipe elle se budgète. Pour une PR d’agent, trois étages de relecture, dont aucun ne remplace les autres :

• L’auteur, premier relecteur, avant même d’ouvrir la PR. C’est la condition du chapitre précédent.
• Le modèle, première passe et tri d’attention, dans les limites que le guide 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, c’est elle qui rend la relecture honnête possible. Des refus rapides : régénérer coûte moins cher que polir en revue une production mal partie, le refus est redevenu bon marché. 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 a un nom : 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 ou si elle tamponne, c’est déjà une question de mesure ; elle attendra le guide suivant.

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 : tiennent-elles ? 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 du guide suivant : mesurer sans se mentir.