Un article arXiv recalcule l'étude METR : l'IA a ralenti les développeurs de 19–24%

Combien de temps un assistant IA fait-il réellement gagner ? Dans un article de 18 pages publié sur arXiv (cs.AI, 23 octobre 2026), Solomon Shalom Lijo soutient que la lecture du chronomètre ne suffit pas pour répondre. L'auteur a recalculé les données de l'étude METR, estimé le plafond d'accélération de GPT-5 dans le benchmark GDPval et mené sa propre expérience avec des relecteurs IA. Sur les mêmes 246 tâches, les développeurs se sont révélés plus lents de 19% ou de 24%, selon ce que l'on compte comme effet. Et lorsqu'on a indiqué au relecteur que le brouillon était rédigé par un modèle quasiment infaillible, il a vérifié moins et laissé passer un chiffre erroné dans 22,5% des briefs.

Chronomètre contre livre de comptes

L'auteur distingue deux lectures. Dans l'approche « chronomètre », le temps économisé correspond à ce que l'horloge a enregistré. Dans l'approche « livre de comptes », il s'agit d'une grandeur contrefactuelle : le temps qu'aurait pris le travail sans IA, à lire à côté des erreurs que ce travail a laissé passer. Lijo défend la seconde.

Pour cela, il introduit deux grandeurs indépendantes du modèle concerné : le temps économisé et les défauts excédentaires non détectés. Elles se combinent en un seul chiffre destiné à la décision, le seuil de rentabilité du coût d'un défaut. Si une erreur coûte plus cher que ce seuil dans votre processus, l'accélération n'est pas rentable.

Le modèle de base de la vérification aboutit à trois conclusions. Tant que le modèle n'est pas assez bon pour se passer totalement de vérification, la part de défauts non détectés chez un travailleur bien calibré ne dépend pas de la qualité du modèle. Le temps de vérification croît avec le logarithme du taux d'erreur du modèle. Et la confiance excessive fait gagner des minutes au chronomètre au prix d'un nombre encore plus grand de minutes perdues au bilan global.

Le recalcul de METR et le plafond de GDPval

Lijo a reproduit l'étude METR sur les développeurs à partir des données publiques. Le résultat dépend du choix de la grandeur estimée :

• ralentissement de 19% ou de 24% sur les mêmes 246 tâches, selon l'estimand ;
• ralentissement de 34% si l'on ne corrige pas le déséquilibre aléatoire entre les groupes ;
• l'IA a aidé sur environ 3–82% des tâches. Un intervalle aussi large montre que l'étude randomisée répond à la question de l'effet moyen et ne dit presque rien de l'effet sur une tâche prise isolément.

Dans le processus GDPval, où chaque résultat est vérifié, le seul temps de relecture limite l'accélération de GPT-5 à 3,6x. Les consultants qui ne faisaient pas partie de la « frontière » travaillaient plus vite, mais se trompaient plus souvent. Ici, l'auteur pose des bornes explicites plutôt que d'importer des hypothèses ponctuelles.

Les relecteurs qui ont cru en leur auteur

Lijo a testé deux prédictions de son modèle dans une petite expérience préenregistrée. Des relecteurs IA vérifiaient des brouillons de briefs standardisés rédigés par IA, constitués à partir de documents de la SEC déposés après la collecte des données d'entraînement des modèles, de sorte que la mémoire du modèle ne pouvait pas suggérer la réponse.

Lorsqu'on indiquait au relecteur le taux d'erreur réel de l'auteur, il vérifiait davantage à mesure que ce taux montait. Mais selon une logique de tout ou rien : le basculement se produisait autour du point où les coûts se rejoignaient dans son prompt. Il n'y avait pas d'ajustement progressif de l'effort.

Lorsqu'on lui disait que l'auteur se trompait dix fois moins souvent qu'en réalité, il vérifiait 7 chiffres sur 9 en moins. Un chiffre erroné passait dans 22,5% des briefs, alors que sans cette tromperie, il ne passait dans aucun. Le travail devenait plus rapide et moins bon, entièrement à cause de la baisse de l'effort.

Que changer dans les métriques d'adoption

Si vous évaluez un assistant IA dans votre équipe, une seule métrique de vitesse ne suffit pas. Il faut au moins trois chiffres :

• le temps économisé par rapport au processus contrefactuel sans IA ;
• le nombre de défauts excédentaires non détectés par unité de travail ;
• le coût d'un défaut dans votre processus et sa comparaison avec le seuil de rentabilité.

Il faut aussi surveiller séparément ce que vous dites aux relecteurs de la fiabilité du modèle. Une évaluation surestimée de la qualité réduit le volume de vérification plus vite que le modèle ne s'améliore réellement. En coût de tokens et d'heures d'ingénieurs, cela ressemble à une économie, jusqu'à ce que le défaut atteigne le client. L'auteur a publié le code et les données sur Zenodo : les calculs peuvent donc être reproduits sur vos propres logs.