L’IA accélère-t-elle vraiment le travail des développeurs ? Ce que mesure une étude de productivité

Un assistant peut raccourcir la rédaction d’un morceau de code sans réduire le temps nécessaire pour livrer une tâche complète. Pour évaluer ce que l’IA change réellement, il faut regarder ce qui est mesuré, quelles tâches entrent dans l’expérience et qui accepte d’y participer. La comparaison des études de METR montre pourquoi un résultat sur la durée des tâches ne se transpose pas automatiquement à la productivité globale d’une équipe.

Dans sa mise à jour sur la conception de son expérience de productivité, METR explique que son étude ultérieure fournit un signal peu fiable sur l’effet actuel des outils d’IA. Ce constat ne prouve ni que l’IA ralentit les développeurs, ni qu’elle les accélère dans une proportion déterminée. Il révèle surtout les difficultés à comparer des tâches réalisées avec ou sans assistance lorsque les outils et les choix des participants évoluent.

Deux estimations qui ne racontent pas la même chose

Le premier essai de METR, fondé sur des données recueillies de février à juin 2025 auprès de développeurs open source expérimentés, estimait que les tâches prenaient 19 % plus longtemps avec les outils d’IA. L’intervalle de confiance rapporté allait de +2 % à +39 %. Ce résultat concerne les tâches de l’étude et son protocole : il ne constitue pas une mesure universelle de la productivité des développeurs.

Une seconde étude a commencé en août 2025. Elle réunissait dix développeurs de l’étude initiale et 47 nouveaux participants, issus d’un ensemble plus diversifié de projets open source. Pour les dix participants repris de la première étude, METR rapporte une estimation de speedup de -18 %, avec un intervalle de confiance de -38 % à +9 %. Pour les nouvelles recrues, l’estimation est de -4 %, avec un intervalle de -15 % à +9 %. Dans les deux cas, les intervalles incluent des effets qui ne correspondent pas à une accélération mesurable avec assurance.

Ces estimations ne suffisent donc pas à conclure que la productivité s’est inversée ou qu’elle a progressé d’une quantité précise. METR estime que les biais de sélection rendent probablement ses résultats inférieurs à l’effet réel pour les développeurs et les tâches les plus favorables à l’IA, mais précise que ses données donnent peu d’indications solides sur l’ampleur de cet effet.

Pourquoi les tâches observées peuvent fausser la comparaison

Le protocole demandait aux développeurs de choisir une tâche, de la décrire, puis de la faire attribuer aléatoirement à une condition où l’IA était autorisée ou interdite. Cette méthode permet de comparer des tâches proches de leur travail réel, plutôt que de leur imposer un exercice identique. Mais elle dépend de ce que les participants acceptent de soumettre.

Dans l’étude ultérieure, 30 à 50 % des développeurs interrogés ont déclaré écarter certaines tâches parce qu’ils ne souhaitaient pas les effectuer sans IA. METR indique aussi que certains développeurs ne voulaient pas participer à une étude qui leur imposait de travailler sans ces outils. L’échantillon peut alors perdre des personnes et des tâches pour lesquelles l’assistance semble particulièrement utile. C’est un biais de sélection : le résultat observé porte sur ce qui reste dans l’expérience, pas nécessairement sur l’ensemble du travail concerné.

• Recrutement : des développeurs qui préfèrent travailler avec l’IA peuvent refuser l’expérience.
• Choix des tâches : certaines tâches jugées plus pénibles sans assistance peuvent ne pas être proposées.
• Type de travail : des participants ont indiqué qu’ils ne choisissaient pas toujours les mêmes tâches avec des outils agentiques.
• Mesure du temps : travailler sur une autre tâche pendant qu’un agent répond complique le relevé du temps consacré à la tâche initiale.

Ces limites ne signifient pas que l’expérience ne sert à rien. Elles changent la portée de sa conclusion : une durée moyenne mesurée sur des tâches soumises volontairement ne suffit pas à décrire toutes les tâches, tous les développeurs ou la valeur du travail livré. METR signale également des différences possibles de qualité du code, de documentation et de tests entre les conditions. Le temps seul ne capture pas ces dimensions.

La productivité ne se résume pas au temps d’exécution

Une tâche plus rapide n’est pas nécessairement un résultat équivalent livré plus tôt. Si le périmètre change, si la quantité de tests diffère ou si une partie du temps d’attente est consacrée à un autre travail, la comparaison des durées devient moins directe. C’est une distinction importante pour les équipes : le temps passé à produire une modification, le temps nécessaire pour vérifier cette modification et la valeur du résultat sont des questions liées, mais différentes.

Pour interpréter une étude ou préparer une évaluation interne, il est donc utile de séparer au moins trois niveaux :

1. La tâche : quel travail a été choisi, et les tâches comparées sont-elles suffisamment comparables ?
2. Le processus : comment le temps, l’usage des agents et les interruptions sont-ils enregistrés ?
3. Le résultat : le code, les tests et la documentation répondent-ils aux mêmes attentes dans les deux conditions ?

Cette grille ne remplace pas un protocole d’évaluation. Elle évite surtout de transformer un indicateur partiel en verdict général. Pour construire un test reproductible sur son propre dépôt, une équipe peut consulter notre méthode de benchmark reproductible pour les agents de code : l’objectif est alors de définir ses tâches et ses critères, pas de prétendre reproduire les résultats de METR.

Ce que les études permettent de retenir

La comparaison de METR apporte un enseignement méthodologique plutôt qu’un chiffre définitif sur le gain de productivité. Son premier essai estimait un ralentissement sur les tâches étudiées ; le suivant rapportait des estimations différentes, mais l’organisme juge que ses biais de sélection et ses difficultés de mesure empêchent une interprétation fiable de l’effet actuel. Les résultats ne permettent pas d’affirmer une accélération générale, pas plus qu’ils ne démontrent que l’IA réduit la productivité.

Pour les développeurs et les responsables techniques, la question utile n’est donc pas seulement « l’IA écrit-elle ce code plus vite ? ». Il faut aussi demander si la tâche soumise représente le travail réel, si la comparaison tient compte des tâches écartées et si le résultat final est évalué au-delà du chronomètre. Sans ces précautions, une mesure précise en apparence peut répondre à une question beaucoup plus étroite que celle que l’équipe cherche à trancher.