Douze accords de travail pour le code écrit par machine

La rétro était la partie facile.

Votre équipe a organisé la rétro de la gueule de bois du vibe-coding. Les données de churn étaient au tableau, la salle s'est entendue sur le fait que la file de révision s'était discrètement rationnée, et tout le monde est parti avec ce rare sentiment post-rétro d'avoir décidé quelque chose. Deux sprints plus tard, les accords vivent dans un document récapitulatif que personne n'ouvre, et le graphique de churn n'a rien remarqué.

Ce mode d'échec est bien documenté : environ deux tiers des actions de rétrospective meurent sans rien changer. Les accords de travail meurent plus vite, parce qu'un accord est une norme, et une norme n'obtient ni numéro de ticket ni responsable à moins que vous ne lui en donniez un.

Voici la moitié règlement de la rétro de la gueule de bois. Douze accords de travail pour les équipes qui livrent du code écrit par machine, construits à partir de la même recherche publique qui a nommé le problème. Les trois exemples du billet original sont ici, rejoints par neuf autres, tous dans le même format : une règle que l'équipe peut énoncer en une phrase, le chiffre qui bouge quand la règle est suivie, et le point de contrôle où vous regardez.

Qu'est-ce qu'un accord de travail pour le code écrit par machine ?

Un accord de travail pour le code écrit par machine est une règle qu'une équipe s'écrit à elle-même sur la façon dont les changements générés par IA sont produits, révisés et appropriés. Il diffère d'une politique à la fois par son origine et son application : une politique est imposée d'en haut et auditée, tandis qu'un accord de travail est négocié lors d'une rétrospective, vérifié par rapport aux propres données de livraison de l'équipe, et réécrit quand ces données disent qu'il ne fonctionne pas.

L'argument de recherche en leur faveur est direct. Le rapport 2025 de DORA a révélé que 90 % des développeurs utilisent maintenant l'IA au travail, avec une adoption positivement liée au débit et négativement liée à la stabilité de livraison. Son modèle de capacités IA identifie ce qui sépare les équipes que l'IA amplifie des équipes qu'elle déstabilise, et chaque capacité de la liste est organisationnelle : une position IA claire et communiquée, de petits lots, de solides pratiques de contrôle de version. Un accord de travail est la plus petite unité de position organisationnelle — une phrase sur laquelle toute l'équipe a accepté d'être tenue.

Une règle, un chiffre, un point de contrôle

La plupart des accords de travail échouent structurellement, pas culturellement. Il leur manque l'une des trois parties.

La règle doit tenir en une phrase qu'un coéquipier peut énoncer à froid. Si ça prend un paragraphe, c'est de l'orientation, et l'orientation perd face à une échéance à chaque fois.

Le chiffre rend la règle falsifiable. La vérification est exactement là où l'intuition induit en erreur : l'enquête 2025 de Stack Overflow auprès de 49 000+ développeurs a révélé que la principale frustration avec les outils IA, citée par 45 %, est le code qui est « presque correct, mais pas tout à fait » — et le code presque-correct semble bien jusqu'à ce que la production ne soit pas d'accord. Les sentiments n'arbitrent pas ça. Les chiffres le font.

Le point de contrôle donne au chiffre une date et un lieu, généralement les cinq premières minutes de la prochaine rétro. Une règle sans chiffre est une opinion. Un chiffre sans point de contrôle est du papier peint.

Les Douze

Volez librement. Les chiffres dans les règles (400 lignes, 90 jours, deux tâches) sont des points de départ à ajuster, pas des lois.

La Revue Se Rationne Elle-Même. Rationnez-la Intentionnellement.

La télémétrie 2026 de Faros AI sur 22 000 développeurs a révélé un temps médian jusqu'à la première revue en hausse de 156,6 % et des PR fusionnées sans aucune revue en hausse de 31,3 %. Quand la capacité de revue s'épuise, les équipes ne décident pas de sauter la revue — elle se décide elle-même, un « ça a l'air correct » à la fois.

1. « Rien ne fusionne sans une approbation humaine, CI vert ou pas. » L'accord de base. Près d'un tiers de changements supplémentaires atteignent maintenant la production sans qu'un seul humain ne les lise, et le code presque-correct est précisément le type qui passe la CI. Vérification : nombre de fusions sans revue, hebdomadaire.

2. « Les PR générées par machine de plus de 400 lignes sont divisées avant la revue. » Les petits lots sont la capacité la plus porteuse dans le modèle DORA, et la taille des lots est l'entrée qu'une équipe contrôle le plus directement. Un réviseur peut tenir 400 lignes honnêtement ; personne ne tient 2 000. Vérification : distribution de la taille des PR, prochaine rétro.

3. « Les changements touchant l'auth, les paiements ou les migrations de données obtiennent un deuxième réviseur, quel que soit l'auteur. » Adaptez la vérification au rayon d'impact, pas à la confiance dans l'outil. Les chemins critiques sont là où vos incidents se regroupent déjà ; nommez-les explicitement dans l'accord. Vérification : taux de double approbation sur les PR de chemins critiques, prochaine rétro.

L'Ownership Survit à l'Autocomplétion

Le module que personne ne veut toucher a un auteur qui ne peut pas l'expliquer. Ces deux accords maintiennent la paternité significative.

4. « Si vous ne pouvez pas expliquer le diff, vous ne pouvez pas le fusionner. » L'explication est la vérification la moins chère disponible : elle coûte dix minutes et attrape la classe de bug que la revue survole. Si expliquer un changement prend plus de temps que de le régénérer, c'est une information sur le changement. Vérification : à la préparation de démo, une PR fusionnée générée par machine par ingénieur est expliquée à voix haute, chaque sprint.

5. « La description de la PR enregistre ce que l'humain a vérifié, pas ce que le modèle a généré. » « Migration exécutée localement, rollback testé, plan de requête vérifié » indique au réviseur où l'attention humaine s'est portée. Le rapport ROI 2026 de DORA appelle le coût de vérification de la sortie machine la taxe de vérification ; ce poste rend la taxe visible au lieu d'ambiante. Vérification : part des PR fusionnées avec une note de vérification, prochaine rétro.

Le Churn Est la Métrique de Vitesse Honnête

Le churn de code est en hausse de 861 % dans les données Faros. Une fonctionnalité livrée deux fois n'était pas rapide la première fois, peu importe ce que le rapport de sprint disait.

6. « Une réécriture en moins de 90 jours est du retravail, et le retravail obtient un ticket. » La fenêtre de 90 jours vient du pattern qu'Autonoma appelle le règlement de comptes de 90 jours : la vitesse du mois un devenant la dette du mois trois. Le retravail qui n'apparaît jamais dans le tracker est un coût que l'équipe paie mais ne compte jamais. Vérification : tickets de retravail et taux de churn par module, prochaine rétro.

7. « Le code jetable est déclaré jetable à sa naissance. » Les spikes et prototypes sont une utilisation légitime de la vitesse IA. Étiquetez-les lors de leur création, pour que les stats de churn restent honnêtes et qu'aucun spike ne soit promu en production parce que tout le monde a oublié ce que c'était. Vérification : part du churn provenant de spikes étiquetés, mensuel.

Les Incidents Sont Là Où la Taxe Est Payée

Ratio incidents-PR : en hausse de 242,7 %. Bugs par développeur depuis l'adoption : en hausse de 54 %. La vérification que vous sautez au moment de la revue est effectuée en production, au pire taux horaire possible.

8. « Chaque revue d'incident demande si le changement déclencheur était généré par machine, et nous suivons le ratio. » Pas pour blâmer — le ratio remplace l'anecdote la plus bruyante dans la pièce par le propre nombre de l'équipe, et c'est le nombre qui vous dit si les accords 1 à 5 fonctionnent. Vérification : champ de modèle de postmortem ; ratio révisé mensuellement.

9. « Un humain possède l'assertion de chaque test. » L'IA écrit des tests plausibles comme elle écrit du code plausible, et un test qui n'affirme rien est pire que pas de test, parce qu'il achète de la confiance sans acheter de vérification. Rédiger des tests est délégable. Décider ce qui doit être vrai ne l'est pas. Vérification : nombre de bugs échappés, prochaine rétro.

N'Inondez Pas la File

10. « Deux tâches d'agent en cours par personne, maximum. » La vitesse de frappe était autrefois une limite naturelle de travail en cours ; les agents l'ont supprimée. Un ingénieur peut maintenant ouvrir des PR plus vite que trois ne peuvent les réviser, et le débordement devient soit de la latence de revue soit des fusions non révisées — les deux mêmes nombres déjà en mouvement dans le mauvais sens. Une limite WIP sur la délégation maintient le budget de vérification humaine solvable. Vérification : PR ouvertes par auteur, hebdomadaire.

Accords Sur les Accords

Les deux derniers existent parce que les dix premiers rejoindront sinon les deux tiers d'actions qui meurent.

11. « Chaque accord porte une date d'expiration. » Trois sprints est une valeur par défaut sensée. À l'expiration, l'équipe revote : conserver, réécrire ou retirer. Un accord qui se renouvelle automatiquement pour toujours est une politique déguisée, et une liste pleine de règles mortes enseigne à l'équipe que la liste est décorative. Vérification : la liste active et ses âges, chaque rétro.

12. « La rétro commence par le tableau de bord. » Cinq premières minutes, avant les nouveaux sujets : chaque accord actif, son nombre, et s'il a bougé. C'est la boucle livrer et tenir au lieu de livrer et s'évaporer. Vérification : c'est le premier point à l'ordre du jour, chaque rétro.

Étiqueter le code, jamais le codeur

Plusieurs de ces ententes suivent si un changement a été écrit par une machine. Aucune ne suit qui s'est appuyé sur le modèle, et cette distinction soutient tout le système. Les données au niveau des changements décrivent comment le processus de l'équipe gère un nouveau type de code. Les données au niveau des personnes deviennent un classement, et un classement corrompt chaque chiffre qu'il affiche : dès que les ingénieurs soupçonnent que le ratio d'incidents alimente une évaluation de performance, ils cessent d'étiqueter honnêtement, et la rétro revient à fonctionner sur des impressions.

C'est le même argument que nous avons fait concernant mesurer l'impact de l'IA en général : mesurer les résultats au niveau de l'équipe, jamais l'activité au niveau de la personne. Les ententes ci-dessus ne fonctionnent que parce que tout le monde dans la salle sait que les chiffres jugent le processus, pas les gens.

Comment adopter ces ententes sans les tuer

Adoptez-en deux ou trois, pas douze. Une équipe qui détient douze nouvelles règles n'en vérifie aucune ; le menu existe pour que vous puissiez faire correspondre les ententes à vos propres pires chiffres.

• Partez de vos données, pas de cet article. Si le churn est stable mais que les incidents augmentent, vous voulez 8 et 9, pas 6 et 7. Tirez les chiffres avant la rétro et laissez-les choisir.
• Votez en rétro. Une entente imposée par un gestionnaire est une politique déguisée — elle obtient la conformité, pas l'appropriation. L'équipe qui a écrit la règle est l'équipe qui la défend sous pression.
• Enregistrez la référence à l'adoption. « Fusions sans revue : 14 au dernier sprint » transforme le premier point de contrôle en comparaison plutôt qu'en débat. Pas de référence ? Alors la trouver est le premier action.
• Donnez à chaque entente un responsable. Pas un exécuteur — un rapporteur. Une personne apporte le chiffre à la rétro pour que le tableau de bord ne dépende jamais de la mémoire collective.

FAQ

Combien d'ententes de travail une équipe devrait-elle avoir à la fois ?

Deux ou trois ententes actives à la fois. Chacune nécessite un chiffre tiré, un point de contrôle tenu et un responsable qui rapporte, et ce budget d'attention s'épuise rapidement. Les équipes qui adoptent une longue liste n'en vérifient aucune ; les équipes qui en adoptent trois et les retirent ou les remplacent à l'expiration construisent l'habitude qui rend les trois suivantes faciles.

Les demandes de tirage devraient-elles être étiquetées comme générées par l'IA ?

Oui, au niveau du changement — une étiquette ou une note dans la description de la PR suffit pour rendre les ratios de churn et d'incidents calculables. Jamais au niveau de la personne : le suivi de l'utilisation de l'IA par ingénieur corrompt les données qu'il collecte, parce que les gens manipulent ce qui est surveillé. La question utile est comment le processus gère les changements écrits par machine, pas qui les a produits.

Et si le chiffre ne bouge pas ?

Alors le point de contrôle a fonctionné. Soit la règle n'a pas été suivie, ce qui signifie généralement qu'elle était trop coûteuse telle qu'écrite et nécessite une renégociation, soit elle a été suivie et n'a pas aidé, ce qui signifie la retirer et dépenser l'attention ailleurs. Une entente qui peut échouer visiblement est le seul type qui peut réussir de manière crédible.

Est-ce que cela fonctionne sans sprints ?

Oui. Les points de contrôle s'attachent à n'importe quel rythme de réflexion que l'équipe a — hebdomadaire, par version, ou piloté par événement. La cadence importe moins que le lieu : un moment récurrent où les chiffres sont au tableau et l'équipe est autorisée à changer les règles.

L'essentiel

L'argument de la rétro de la gueule de bois était que la dette de code par impression est un échec de processus, et la rétrospective est l'endroit où le processus est renégocié. Voici l'autre moitié : ce qui sort de cette salle doit être falsifiable, sinon la prochaine rétro le re-débat à partir de zéro. Les équipes qui dépassent la gueule de bois ne sont pas celles avec les règles d'IA les plus strictes ou les plus souples. Ce sont celles qui écrivent des règles qui peuvent perdre un argument avec les données — et les laissent perdre.

Volez-en trois. Fixez l'expiration. Ouvrez la prochaine rétro avec le tableau de bord.

Sources

• Faros AI — « Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash » (avril 2026)
• DORA — State of AI-assisted Software Development 2025 (septembre 2025)
• DORA AI Capabilities Model (2025)
• InfoQ — « New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment » (mai 2026)
• Stack Overflow — 2025 Developer Survey results (décembre 2025)
• Autonoma — « Vibe Coding Technical Debt: The 90-Day Reckoning » (avril 2026)

Lectures complémentaires

• La rétro pour la gueule de bois du code par impression — la rétrospective d'où provient ce guide.
• Pourquoi 2/3 des actions de rétrospective meurent (et comment y remédier) — les mécanismes de suivi derrière les ententes 11 et 12.
• Mesurer ce que l'IA fait réellement à votre équipe — l'argument de mesure au niveau de l'équipe, neutre à l'IA, en entier.
• Livrer et tenir : comment mesurer si l'IA fonctionne vraiment — la norme de résultat sur laquelle le tableau de bord se ferme.