Recalcul de l'expérience METR : sur les tâches complexes et la relecture, les développeurs assistés par IA perdent 24 % de temps

En 2025, le centre de recherche indépendant METR a mesuré le travail de 16 développeurs open source expérimentés sur 246 tâches réelles issues de leurs propres dépôts : avec des assistants IA, un ticket typique était résolu 19 % plus lentement qu'à la main. Dans son article « Counting the Bandages: On measuring the time that AI saves » (publié sur arXiv le 23 octobre 2026), le chercheur indépendant Solomon Shalom Lijo a recalculé, à partir des journaux publics de METR, la consommation totale d'heures de l'équipe. En tenant compte des blocages prolongés sur les tâches complexes, les développeurs assistés par IA ont en réalité perdu 24 % de temps de travail (et jusqu'à 34 % sans correction de la taille initiale des tâches), la correction des remarques issues de la relecture de code demandant en moyenne 14,9 minutes par ticket, contre 9,7 minutes sans IA.

L'auteur a ensuite examiné le benchmark GDPval d'OpenAI et, à partir de 540 sessions Claude Code, montré pourquoi arrêter le chronomètre au moment de la remise du brouillon n'a aucun sens : les minutes gagnées lors de la génération se traduisent par des bugs non détectés et des heures de reprise.

D'où viennent 19 %, 24 % et 34 % dans les mêmes journaux

Lijo a reproduit les calculs à partir du dépôt public de METR et montré que les mêmes 246 tâches closes donnent trois chiffres différents selon la méthode de calcul du temps d'équipe :

• Les +19 % proviennent de la moyenne géométrique des logarithmes, mise en avant par les auteurs de METR dans leur titre. Ce chiffre reflète l'écart typique sur une tâche individuelle.
• Les +24 % apparaissent lorsqu'on divise l'ensemble des heures réellement consacrées avec IA par les heures sans IA. Avec l'IA, la dispersion du temps est nettement plus large : lorsqu'un développeur s'enlise dans des itérations de prompting infructueuses sur un ticket volumineux, ces longues traînes pèsent plus lourd sur le total d'heures que ne le laisse supposer la moyenne logarithmique.
• Les +34 % correspondent aux heures brutes, sans correction du biais initial de l'échantillon. Lors du tirage au sort, le groupe assisté par IA s'est vu attribuer, par hasard, des tickets plus volumineux : avant même de commencer, les développeurs les estimaient en moyenne à 116 minutes, contre 106 minutes dans le groupe témoin.
• Les corrections post-relecture ont été mesurées sur 230 des 246 tickets : retravailler un code renvoyé par le relecteur prenait 14,9 minutes avec IA, contre 9,7 minutes à la main. Les bornes statistiques de Makarov, appliquées aux mêmes données, laissent cependant un large éventail : l'IA a réellement accéléré le travail sur une fraction des tâches individuelles comprise entre 2,6 % et 82,1 %. Un seul chiffre moyen masque donc les tickets sur lesquels l'outil fait gagner du temps et ceux sur lesquels il en fait perdre.

Pourquoi l'accélération par 100 de GPT-5 se réduit à un facteur de 1,1 à 3,6

Il y a cent ans, l'ingénieur Frank Gilbreth essayait de se raser avec deux rasoirs à la fois : il gagnait 44 secondes devant le miroir, mais perdait deux minutes à poser des pansements sur ses coupures. Les benchmarks d'IA actuels reproduisent la même erreur lorsqu'ils excluent la vérification du résultat de la mesure.

Le test applicatif GDPval d'OpenAI en est un exemple frappant. Dans son annonce, l'entreprise affirmait que ses modèles phares résolvent les tâches de spécialistes sectoriels environ 100 fois plus vite et moins cher : GPT-5 génère une réponse en 4,5 minutes, contre 404 minutes de travail humain. Mais l'article scientifique de GDPval lui-même intègre un circuit de travail avec validation obligatoire de chaque réponse :

• la lecture et la vérification d'un brouillon par un spécialiste humain prennent 109 minutes (27 % du temps de travail manuel total) ;
• selon la loi d'Amdahl, même avec un modèle sans erreur, l'accélération de l'ensemble du processus plafonne à `404 / (4,5 + 109) = 3,56x`, soit un maximum de 3,6 fois ;
• les réponses de GPT-5 n'ont surpassé celles des experts que dans 39 % des tâches ; en tenant compte de la reprise des brouillons médiocres, les auteurs de l'article GDPval eux-mêmes estiment le gain réel à seulement 1,12–1,39 fois.

Le même type de bascule apparaît dans l'expérience de terrain menée avec des consultants en entreprise (Dell'Acqua et al., 2026) sur des tâches situées hors de la zone de fiabilité du modèle. Avec GPT-4, les participants remettaient leur solution en 26,2 minutes au lieu de 37,7 minutes pour le groupe témoin, mais la proportion de réponses correctes chutait de 84,5 % à 60,0 %. Selon la formule du seuil de rentabilité du défaut introduite par Lijo, les 11,5 minutes gagnées ne sont rentables que si la détection et la correction d'une erreur parvenue au client coûtent moins de 47 minutes de travail du consultant.

Expérience sur 540 sessions

Claude Code : comment une confiance excessive désactive la vérification

Pour mesurer concrètement l'influence de la réputation de l'auteur d'un brouillon sur la rigueur de la relecture, Lijo a mené une série de tests contrôlés sur des agents IA. Les données de base sont des rapports trimestriels d'entreprises américaines, au format 10-Q, issus de la base de la Securities and Exchange Commission (SEC), portant sur la période antérieure au 30 juin 2026. Ces rapports étant publiés après le 1er juillet 2026 — soit après la date limite d'entraînement des modèles — il était impossible que le réseau de neurones se souvienne des chiffres grâce à ses poids.

L'agent auteur (`claude-haiku-5-5`) élaborait une synthèse de 9 indicateurs (chiffre d'affaires, bénéfice net et marge opérationnelle pour trois entreprises), dans laquelle une erreur unique était délibérément introduite dans 30 % des cas : une ligne provenant d'un autre document, un trimestre erroné ou des chiffres intervertis. Le document était ensuite vérifié par un agent relecteur (`claude-sonnet-5-5`, dans une session Claude Code isolée) disposant d'un outil de vérification ligne par ligne avec la source SEC. Selon les consignes du prompt, vérifier un chiffre coûtait 3 minutes (soit 27 minutes pour les 9 lignes), tandis qu'une erreur non détectée transmise au client était sanctionnée de 10 heures (600 minutes).

Une vérification systématique était rentable dès que le taux d'erreur dépassait 4,5 %.

L'expérience a mis en évidence trois effets précis :

• Mode « tout ou rien ». Lorsque le relecteur recevait une information honnête sur le taux d'erreur élevé (entre 10 % et 30 %), il vérifiait systématiquement les 9 lignes dans les 40 tests appariés et corrigeait 100 % des erreurs. Mais il n'existait aucune gradation dans la vérification sélective : autour du seuil de 4,5 %, le modèle basculait brutalement entre vérification complète et absence totale de consultation de la source.
• Aveuglement en cas de sous-estimation du taux d'erreur. Sur les mêmes brouillons contenant en réalité 30 % d'erreurs, le relecteur était informé, dans le prompt, d'un taux d'erreur dix fois plus faible (3 %). Dans 29 des 40 sessions, `Sonnet 5.5` n'a même pas ouvert le rapport source, ne vérifiant en moyenne que 2 chiffres sur 9. La relecture a permis d'économiser 21 minutes, mais un chiffre erroné s'est retrouvé dans le rapport remis au client dans 22,5 % des synthèses, au lieu de zéro — soit une perte nette de 135 minutes par document.
• L'inutilité des mises en garde dans le prompt. Dans une variante distincte, une exigence explicite précisait, en plus du chiffre de « 3 % d'erreurs », que cette estimation devait être considérée comme non vérifiée. Dans 26 des 40 essais, le modèle reconnaissait, dans son raisonnement, qu'il ne fallait pas se fier à ce chiffre — et remettait quand même sa synthèse sans effectuer la moindre vérification. L'ancrage numérique l'emportait sur l'avertissement textuel.

Comment mesurer l'apport de l'IA en équipe sans se tromper soi-même

Plutôt qu'un chronomètre unique arrêté « au premier commit », l'auteur propose de suivre trois indicateurs lors du déploiement d'outils d'IA (code et journaux bruts disponibles sur GitHub dans le dépôt `tsb-bench` et sur Zenodo) :

1. Le nombre total d'heures consacré par l'équipe à une tâche de bout en bout, relecture de code et correction des pull requests renvoyées incluses. 2. Le nombre d'erreurs supplémentaires qui passent dans le résultat final — évalué via une réception en aveugle, dans les groupes avec et sans IA. 3. Le coût d'un bug au-delà duquel le gain de vitesse ne devient plus rentable, et le moment à partir duquel le contrôle manuel peut être désactivé : pour retirer la relecture obligatoire avec un niveau de confiance de 95 % et un taux d'erreur toléré de 0,85 %, l'outil doit d'abord enchaîner 352 tâches vérifiées sans le moindre échec.