Ton agent de code IA a tourné toute la nuit. Tu ouvres le dashboard lundi matin et il brille : 14 pull requests créées, 2 000 lignes modifiées, trois features scaffoldées. Tu sirotes ton café en te disant que tu viens d'embaucher un dev junior gratos.
Puis tu lis vraiment le code. La moitié de ces PRs contiennent des correctifs pour des bugs que l'agent a lui-même introduits deux commits plus tôt dans la même session. Une fonction a été écrite, cassée, réécrite, re-cassée, et a finalement atterri à la cinquième tentative. Le dashboard a compté chaque tentative comme du travail productif.
Bienvenue dans le rework ratio — la métrique dont personne, parmi ceux qui te vendent des outils de code IA, ne veut parler.
Dans les entrailles d'une session agent
Ce dernier mois, tous les grands outils de code ont sorti leurs agents autonomes. GitHub Copilot et Cursor 3 ont lancé les leurs début avril ; Claude Code Routines a suivi le 14 avril ; OpenAI Codex s'est étendu aux workflows multi-agents le 16 avril. Chaque outil exécute des boucles d'itération sans supervision — l'agent écrit du code, vérifie si ça marche, et réessaie si ce n'est pas le cas.
C'est ce "réessaie" qui fait dérailler la comptabilité. Voici une session condensée mais représentative d'un agent chargé d'ajouter un endpoint d'authentification utilisateur. Quarante-trois minutes. Douze commits :
| # | Message de commit | Type |
|---|---|---|
| 1 | Add auth route handler | Nouveau |
| 2 | Add JWT token generation | Nouveau |
| 3 | Fix import error in auth.py | Rework |
| 4 | Add password hashing | Nouveau |
| 5 | Fix type error in hash function | Rework |
| 6 | Rewrite auth route to fix 500 error | Rework |
| 7 | Add input validation | Nouveau |
| 8 | Fix validation regex causing test failure | Rework |
| 9 | Fix test broken by commit 6 | Rework |
| 10 | Add rate limiting middleware | Nouveau |
| 11 | Fix rate limiter config path | Rework |
| 12 | Clean up unused imports from iterations | Rework |
Cinq commits font avancer la feature. Sept corrigent des problèmes que l'agent a créés dans la même session. Ça donne un rework ratio de 58 % — plus de la moitié de l'effort de l'agent passé à corriger sa propre production.
Le dashboard a affiché 12 commits, 847 lignes modifiées, une feature terminée. Tout techniquement vrai. Tout trompeur.
Comment calculer le rework ratio
Ce n'est pas théorique. Tu peux l'extraire de n'importe quel dépôt où des agents opèrent :
Rework Ratio = (commits modifiant du code écrit plus tôt dans la même session agent) ÷ (total des commits de la session)
Lance git log --diff-filter=M sur une branche générée par un agent. Repère chaque commit qui modifie un fichier que l'agent a déjà touché dans la même session. Sépare les extensions légitimes (ajouter une nouvelle fonction dans un fichier existant) des corrections (réparer ce qui vient de casser). Le ratio est là, dans l'historique des diffs.
Le rapport qualité code d'avril 2026 de GitClear a mesuré un signal similaire — le code churn dans les 72 heures suivant l'écriture — et l'a trouvé à 7,1 % pour les projets assistés par IA contre 3,2 % pour les projets 100 % humains. Mais ça capture le churn après le merge — du code qui est livré puis réécrit. Le churn intra-session, où l'agent casse et répare son propre code avant même que tu voies la pull request, reste invisible pour tous les outils de mesure existants.
C'est là le trou béant. GitClear mesure le churn post-merge. Les dashboards des éditeurs mesurent l'activité. Personne ne mesure le rework qui se passe à l'intérieur de la boucle de l'agent.
Le mensonge du dashboard
Suis le calcul pour une vraie équipe. Disons que tes agents exécutent 50 sessions par semaine pour 10 ingénieurs, avec une moyenne de 12 commits par session. Si le rework ratio typique est de 55 % :
- 50 sessions × 12 commits = 600 commits/semaine (ce que le dashboard affiche)
- 600 × 0,55 = 330 commits qui n'ont rien produit de livrable
- 330 commits de rework × ~0,15 $ de coût moyen en tokens = ~50 $/semaine cramés dans l'équivalent IA de la touche retour arrière
Extrapolons. Une boîte de 100 ingénieurs utilisant les agents à fond crâme entre 2 000 et 5 000 $ par mois en tokens qui génèrent zéro ligne de code net. Le dashboard appelle ça du "développement assisté par IA". Le compte de résultat appelle ça du gaspillage.
Comme plusieurs analyses l'ont confirmé cette année — le code généré par IA traîne environ 1,7× plus de problèmes par PR que le code humain, les incidents grimpent proportionnellement à la production IA, et la fiabilité des agents progresse deux fois moins vite que leurs capacités. Le rework ratio explique en partie le mécanisme : du code qui a survécu à cinq réécritures internes porte les cicatrices architecturales des quatre premières tentatives. Les fonctions sont façonnées par l'historique de débogage, pas par l'intention de conception.
Ce qui survit après le rework
Si tu retires les boucles d'auto-correction, les gains de productivité réels tournent autour de 1,5 à 2× pour la plupart des équipes. Les benchmarks de productivité Q1 2026 de Larridin ont constaté que l'utilisation de l'IA dans les équipes d'ingénierie a bondi de 65 %, mais le débit de PRs n'a progressé que d'environ 10 %. L'écart entre l'adoption et la production s'explique en partie par le rework qui bouffe la différence.
Le coût caché ne se limite pas aux tokens. Chaque cycle de correction ajoute de la complexité défensive au code final. Les noms de variables reflètent l'historique de débogage plutôt que les concepts du domaine. Les abstractions accumulent des guard clauses issues des tentatives ratées précédentes. Le code fonctionne, mais il se lit comme s'il avait été écrit par quelqu'un qui changeait d'avis en permanence — parce que c'est exactement ce qui s'est passé.
La métrique qui changerait les achats
Pose une seule question à ton éditeur d'outils de code IA avant le prochain sprint planning : quel pourcentage des actions de l'agent dans une session corrige la propre production antérieure de l'agent ?
J'ai vérifié chaque dashboard, chaque page analytics, chaque rapport d'intelligence engineering des principaux outils livrant des agents ce mois-ci. Aucun ne sépare "nouveau travail utile" de "l'agent qui se dispute avec lui-même".
Le premier éditeur qui affichera cette métrique — en séparant honnêtement le nouveau travail de l'auto-correction — raflera les contrats enterprise. Pas parce que le chiffre sera flatteur (il ne le sera pas), mais parce que ça démontrerait quelque chose qu'aucun éditeur n'a encore offert : de l'honnêteté sur ce que le coding autonome produit réellement.
Pas besoin d'attendre. Clone n'importe quelle branche générée par un agent. Lis les commits dans l'ordre. Compte ceux qui réparent ce que l'agent vient de casser.
Ton dashboard dit 10×. Ton git log dit autre chose. Crois le git log.
