METR 2025 : l’essai randomisé montre que les outils d’IA ont ralenti de 19 % des développeurs open source expérimentés — analyse

De quoi il s’agit

METR a mené un essai contrôlé randomisé de février à juin 2025, examinant les effets des outils d’IA sur du travail réel :

• 16 développeurs open source expérimentés se sont attaqués à des problèmes issus de dépôts qu’ils maintenaient activement depuis environ 5 ans, avec en moyenne 1 500 commits chacun. Les projets étaient conséquents : environ 23 000 étoiles et 1,1 million de lignes de code, avec des processus de relecture rigoureux.
• 246 problèmes réels issus de ces bases de code ont été intégrés à l’étude — des bugs et fonctionnalités nécessitant typiquement environ 2 heures de travail.
• La randomisation par tirage à pile ou face déterminait si l’IA était autorisée (principalement Cursor Pro avec Claude 3.5/3.7 Sonnet) ou interdite. Les développeurs enregistraient leurs sessions et consignaient le temps investi.

Le protocole de l’étude comportait un élément important : avant la randomisation, les développeurs prédisaient le temps d’achèvement de chaque problème, à la fois avec et sans assistance de l’IA. Cette double prévision servait de référence de difficulté indépendante de l’assignation au traitement, et capturait les attentes de départ. Le résultat mesuré — le temps d’achèvement réel — était établi avant le traitement, empêchant l’IA de gonfler les métriques par de la verbosité ou une fragmentation artificielle des tâches.

Le résultat principal

Trois comparaisons essentielles révèlent le cœur du constat :

L’erreur de direction était systématique dans tous les groupes de prévision. Fait le plus frappant : les développeurs ont terminé l’étude convaincus que l’IA avait accéléré leur travail de 20 %, alors que les mesures montraient l’inverse. Fait intéressant, les développeurs ont montré des prévisions précises sur la durée des tâches elle-même (corrélation d’environ 0,6 avec les temps réels), mais leur évaluation de la contribution spécifique de l’IA était inversée.

Où est passé le temps

L’analyse de 143 heures d’enregistrements d’écran, à une granularité de 10 secondes, a révélé que lorsque l’IA était disponible, les développeurs passaient moins de temps à écrire et à chercher du code. Ils consacraient à la place des heures supplémentaires à « la formulation des prompts, l’attente de la génération, l’évaluation du résultat » — et, fait notable, les périodes d’inactivité augmentaient. L’outil a redistribué le travail plutôt que de l’éliminer, créant un échange défavorable entre le temps de codage et les activités de supervision.

Pourquoi ? L’analyse des facteurs

L’examen de 21 mécanismes potentiels a identifié quatre regroupements catégoriels. Cinq facteurs ont montré une contribution significative au ralentissement :

1. Le biais de surconfiance — les développeurs conservaient leur confiance dans l’assistance de l’IA même quand son utilité avait diminué, perpétuant une dépendance continue.
2. L’expertise sur le dépôt — ces développeurs possédaient une connaissance approfondie de leurs bases de code exactes ; l’IA peinait à rivaliser avec quelqu’un qui détenait déjà un contexte aussi complet. Les effets négatifs étaient plus importants pour les tâches familières.
3. L’échelle et la complexité de la base de code — la performance de l’IA se dégradait dans les dépôts d’un million de lignes, comparés aux projets récents.
4. La fiabilité de la génération — les développeurs acceptaient moins de 44 % des résultats de l’IA ; 75 % relisaient chaque ligne générée ; 56 % nécessitaient fréquemment une révision substantielle. Environ 9 % du temps assisté par l’IA était consacré à l’évaluation et à la correction du résultat.
5. Les lacunes de connaissance contextuelle — l’IA fonctionnait comme un contributeur non familier, ignorant des contraintes non documentées, des exigences historiques de compatibilité et des emplacements optimaux pour les modifications.

Six facteurs ont montré des indices allant à l’encontre d’une contribution au ralentissement, tandis que dix sont restés non concluants. Les chercheurs ont reconnu ne pas pouvoir exclure totalement des artefacts expérimentaux, bien que le ralentissement ait persisté à travers les analyses de sensibilité.

La réserve sur laquelle ils insistent

Les résultats ne concluent pas que « l’IA n’apporte aucun gain de vitesse aux développeurs ». Ils indiquent plutôt que, pour des experts sur des bases de code profondément connues et avec des standards de qualité élevés, l’IA du début 2025 a introduit des retards. L’article lui-même note que les résultats concordent avec des gains potentiellement substantiels sur du développement greenfield ou du code non familier — l’annexe documente des développeurs trouvant l’IA la plus bénéfique précisément sur des tâches nouvelles : « première fois avec des Git hooks, l’IA m’a fait gagner 3 heures ».

Pistes de discussion ouvertes

1. La divergence de perception — les développeurs sont sortis de l’étude convaincus d’avoir gagné 20 % de vitesse, alors qu’ils en avaient réellement perdu. Pourquoi un outil qui ralentit donne-t-il une sensation de bénéfice ? Explication possible : « échanger de la vitesse contre un effort réduit » — distinguer les métriques temporelles de la difficulté subjective.
2. L’application personnelle — pour les personnes qui utilisent régulièrement des outils d’IA : travaillez-vous généralement dans des domaines familiers ou non familiers, et tenez-vous compte de la surcharge de relecture et de correction dans votre flux de travail ?
3. Les limites méthodologiques — l’étude portait sur 16 développeurs, avec des tâches plafonnées à environ 2 heures. Quelles populations et quels types de travail sortent de ce périmètre ?