Les 19 % — le chiffre que ses propres auteurs ont cessé de défendre

Le chiffre, et ce qu'on en fait

Depuis juillet 2025, une même statistique circule dans toutes les discussions sur l'IA et le développement logiciel : les développeurs à qui l'on donne des outils d'IA mettent 19 % de temps en plus pour terminer leurs tâches. Elle apparaît en commentaire de billets enthousiastes, en réponse à un dirigeant qui annonce des gains de productivité, dans les fils où quelqu'un ose dire qu'il code plus vite qu'avant.

Le chiffre est réel. Il vient d'un essai contrôlé randomisé sérieux, publié par un laboratoire sérieux, et il n'a pas été rétracté. Ce n'est pas un faux comme le minimum de 72 cœurs de VMware qui continuait de circuler des mois après avoir été retiré.

Il est simplement utilisé pour répondre à une question que l'étude ne posait pas, dans un contexte qu'elle excluait explicitement, et son propre laboratoire a publié depuis une mise à jour que presque personne ne cite. Cet article n'est pas écrit contre les sceptiques. Il est écrit contre l'usage d'un chiffre unique pour trancher une question qui n'en accepte pas.

L'expérience, telle qu'elle a été faite

L'étude s'intitule Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Elle est signée Joel Becker, Nate Rush, Elizabeth Barnes et David Rein, du laboratoire METR, et a été mise en ligne le 10 juillet 2025, avec une préversion déposée sur arXiv le 12 juillet.

Le protocole mérite d'être décrit précisément, parce que c'est là que tout se joue :

• 16 développeurs. Pas 16 débutants : des contributeurs expérimentés de très gros projets libres, sur des dépôts dépassant les 22 000 étoiles et le million de lignes de code. Des gens qui connaissent leur base de code depuis des années.
• 246 tâches réelles. Corrections de bugs, ajouts de fonctionnalités, refactorisations — pas des exercices, des tickets qu'ils auraient traités de toute façon. Durée moyenne autour de deux heures.
• Une assignation aléatoire, tâche par tâche. C'est ce qui fait la valeur de l'étude : pour chaque ticket, un tirage au sort décidait si le développeur avait le droit d'utiliser l'IA ou non. Le même développeur, sur le même dépôt, dans les deux conditions. C'est le protocole le plus propre qu'on puisse monter sur ce sujet, et il est rare.
• Les outils de l'époque. Essentiellement Cursor Pro avec Claude 3.5 et 3.7 Sonnet, sur la période février-juin 2025.

Résultat : lorsqu'ils avaient le droit d'utiliser l'IA, ces développeurs mettaient 19 % de temps en plus.

Le vrai résultat

Ce n'est pas le ralentissement. C'est que personne ne l'avait vu venir.

Si l'étude n'avait dit que « l'IA ralentit de 19 % », elle serait une étude parmi d'autres. Ce qui la rend inconfortable, c'est la série de prévisions qui l'accompagne. Avant de commencer, on a demandé à tout le monde d'estimer ce qui allait se passer.

C'est ce point-là, et non le chiffre de 19 %, qui devrait retenir l'attention de quiconque pilote une équipe. Il ne dit pas que l'IA est mauvaise. Il dit que l'introspection ne fonctionne pas sur cette question. Le ressenti de vitesse et la vitesse réelle peuvent diverger de quarante points sans que la personne concernée s'en aperçoive.

On sait pourquoi, à peu près. L'IA supprime la friction du démarrage — la page blanche, la commande qu'on ne se rappelle plus, la fonction qu'il faut aller relire. Ce sont les moments désagréables, et ils disparaissent. Le temps, lui, se déplace ailleurs : lire la proposition, vérifier qu'elle est juste, corriger ce qui ne l'est pas, recommencer. Ces minutes-là sont plus confortables, donc moins visibles. On se souvient d'avoir moins souffert, et on le traduit en « j'ai été plus rapide ».

Conséquence pratique immédiate : si votre seule source d'information sur les gains de l'IA dans votre équipe est ce que l'équipe vous en dit, vous ne savez rien. Ce n'est pas un procès en malhonnêteté. Les développeurs de METR étaient volontaires, conscients d'être mesurés, et ils se sont trompés quand même.

Ce que les auteurs ont écrit eux-mêmes

Les réserves étaient dans le texte dès le premier jour

Une habitude utile, quand un chiffre circule : aller lire la section des limites. Les auteurs de METR n'ont pas attendu qu'on les contredise, ils ont posé eux-mêmes les bornes de ce qu'ils avaient mesuré.

Sur la généralisation, d'abord :

« We do not claim that our developers or repositories represent a majority or plurality of software development work. »

« Nous ne prétendons pas que nos développeurs ou nos dépôts représentent la majorité, ni même la plus grande part, du travail de développement logiciel. »

C'est une phrase qu'il faut relire en pensant à son propre contexte. Le développeur médian ne travaille pas sur un projet libre d'un million de lignes qu'il connaît par cœur. Il travaille sur une application métier moyennement documentée, souvent écrite par quelqu'un d'autre, dans un langage qu'il maîtrise inégalement. Sur ce terrain-là, l'aide d'un modèle qui a lu beaucoup de code n'a aucune raison d'avoir le même effet. Elle pourrait être meilleure — le développeur a plus à apprendre de la machine — ou pire, faute de pouvoir juger ce qu'on lui propose.

L'étude ne tranche pas. Elle ne le prétend pas.

Sur l'effet d'apprentissage, ensuite :

« It may be the case that there are strong learning effects for AI tools like Cursor that only appear after several hundred hours of usage. »

« Il se peut qu'il existe, pour des outils comme Cursor, de forts effets d'apprentissage qui n'apparaissent qu'après plusieurs centaines d'heures d'utilisation. »

Autrement dit : il est possible qu'on ait mesuré le coût de la prise en main, pas le régime de croisière. C'est une hypothèse, pas un fait — mais elle est posée par les auteurs, pas par un commentateur agacé.

Sur le calendrier, enfin :

« Progress is difficult to predict, and there has been substantial AI progress over the past five years. »

« Le progrès est difficile à prédire, et il y a eu des avancées substantielles ces cinq dernières années. »

Le titre de l'étude contient d'ailleurs sa propre date de péremption : Early-2025 AI. Les auteurs ont daté leur objet dans le titre. C'est cette précision-là que l'usage courant a effacée.

La suite, que personne ne cite

Février 2026 : METR change de protocole et relativise son propre résultat

Le 24 février 2026, METR a publié une mise à jour sur son programme de mesure. Elle est passée à peu près inaperçue, alors qu'elle change la lecture qu'on doit faire du chiffre de 19 %.

Deux choses y sont dites.

La première est un problème de méthode, et il est savoureux. Reproduire l'expérience devient difficile parce que les développeurs refusent de participer s'ils ne peuvent pas utiliser l'IA. Le tirage au sort qui faisait la rigueur du protocole est devenu son talon d'Achille : accepter de renoncer à ses outils pendant plusieurs semaines n'est plus une contrainte neutre, c'est un filtre. Ceux qui acceptent ne ressemblent plus à la population qu'on veut mesurer. Un biais de sélection s'est installé là où il n'y en avait pas.

Il y a quelque chose d'instructif dans ce détail : en un an et demi, l'outil est passé du statut d'objet qu'on teste à celui d'outil dont on ne se sépare pas. Ce fait sociologique en dit peut-être autant que la mesure elle-même.

La seconde est une prise de distance explicite avec le résultat de 2025. Les auteurs écrivent que leurs nouvelles données donnent :

« … an unreliable signal of the current productivity effect of AI tools. »

« … un signal peu fiable de l'effet actuel des outils d'IA sur la productivité. »

Et, plus directement encore :

« We believe it is likely that developers are more sped up from AI tools now — in early 2026 — compared to our estimates from early 2025. »

« Nous pensons qu'il est probable que les développeurs soient davantage accélérés par les outils d'IA aujourd'hui — début 2026 — que ne l'indiquaient nos estimations de début 2025. »

Le contre-champ

Une autre mesure, beaucoup plus large, dit autre chose — et les deux peuvent être vraies

Le 24 septembre 2025, l'équipe DORA de Google Cloud publiait son rapport annuel sur l'état du développement logiciel assisté par l'IA. Le contraste de méthode avec METR est total, et c'est précisément ce qui rend la comparaison utile.

DORA n'est pas un essai randomisé : c'est une enquête déclarative auprès de près de 5 000 professionnels dans le monde, complétée par plus de cent heures d'entretiens qualitatifs. On ne chronomètre personne. On mesure des corrélations à grande échelle, sur des contextes hétérogènes — exactement ce que METR ne faisait pas.

Les résultats, dans le désordre :

• 90 % des répondants déclarent utiliser l'IA au travail.
• Plus de 80 % estiment qu'elle a augmenté leur productivité.
• 30 % déclarent avoir peu ou pas confiance dans le code que l'IA produit — une proportion en légère baisse par rapport à l'année précédente.
• Contrairement à l'édition précédente, l'adoption de l'IA entretient désormais une relation positive avec le débit de livraison et avec la performance du produit.
• Mais elle continue d'entretenir une relation négative avec la stabilité de la livraison.

Arrêtons-nous sur la troisième et la deuxième lignes, prises ensemble. Plus de 80 % des gens pensent que l'IA les rend plus productifs, et 30 % n'ont pas confiance dans ce qu'elle écrit. Ces deux populations se recouvrent largement. On peut donc trouver, dans la même personne, la conviction d'aller plus vite et la méfiance envers le résultat. Ce n'est pas incohérent : c'est ce qui arrive quand le gain de temps se situe à la production et la perte à la vérification.

Et c'est exactement ce que dit le couple débit/stabilité. Plus de changements partent en production, et une part plus grande d'entre eux se passe mal. Le rapport le formule en une phrase qui vaut d'être citée telle quelle :

« AI doesn't fix a team; it amplifies what's already there. Strong teams use AI to become even better and more efficient. Struggling teams will find that AI only highlights and intensifies their existing problems. »

« L'IA ne répare pas une équipe ; elle amplifie ce qui est déjà là. Les équipes solides s'en servent pour devenir meilleures encore. Les équipes en difficulté découvriront qu'elle ne fait que mettre en évidence et intensifier leurs problèmes existants. »

Les deux études ne se contredisent pas

La tentation est de choisir son camp : METR pour les sceptiques, DORA pour les enthousiastes. C'est une lecture paresseuse. Les deux mesurent des choses différentes, sur des populations différentes, à des dates différentes, avec des méthodes qui n'ont pas les mêmes forces.

METR a la rigueur causale — le tirage au sort permet de dire que c'est bien l'IA qui a produit l'effet — et une portée très étroite : seize experts, leurs propres dépôts, début 2025.

DORA a la portée — cinq mille personnes, tous contextes — et aucune rigueur causale : une corrélation entre adoption de l'IA et instabilité ne dit pas dans quel sens va la flèche. Il est parfaitement possible que les équipes qui livrent beaucoup et cassent souvent soient aussi celles qui adoptent l'IA le plus vite, sans que l'une cause l'autre.

Un lecteur honnête garde les deux : un effet mesuré proprement mais sur un cas particulier, et une tendance large mais dont on ne connaît pas le sens de causalité. C'est moins confortable qu'un chiffre unique. C'est aussi tout ce dont on dispose.

La question mal posée

« Est-ce que l'IA accélère les développeurs ? » n'a pas de réponse

Pas parce que le sujet serait trop complexe, mais parce que la question omet toutes les variables qui déterminent la réponse. Quatre au moins :

• Qui. Un expert de son propre code n'a presque rien à apprendre d'un modèle sur ce code précis — il connaît déjà la réponse, et lire une proposition lui coûte plus cher que de l'écrire. Quelqu'un qui découvre une base de code, un langage ou une bibliothèque est dans la situation inverse.
• Sur quoi. Écrire une fonction isolée bien spécifiée, et modifier un comportement subtil dans un système dont dix modules dépendent, ne sont pas la même tâche. Les études qui mesurent la première et celles qui mesurent la seconde n'ont aucune raison de converger.
• Avec quel filet. C'est le point que DORA met en avant. Le surcroît de changements produits n'est un gain que s'il existe des tests automatisés, un contrôle de version discipliné et des retours rapides. Sans cela, ce n'est pas de la vitesse, c'est de la dette qui s'accumule plus vite.
• Quand. Le titre de l'étude METR le dit : Early-2025. Entre les modèles de février 2025 et ceux d'aujourd'hui, il s'est passé dix-huit mois. Un chiffre de productivité en IA n'a pas une durée de vie de chiffre — il a une durée de vie de version.

Quand quelqu'un vous cite un pourcentage sans préciser ces quatre points, il ne vous transmet pas une information. Il vous transmet sa position, habillée en mesure.

Le conseil qui change le dossier

Le seul chiffre qui vous concerne, c'est le vôtre — et il est mesurable

Sources, vérifiées le 15 septembre 2026 : METR, « Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity », 10 juillet 2025 — protocole, résultat de 19 %, prévisions à 24 %, 38 % et 39 %, estimation rétrospective à 20 %, et les citations des limites ; la préversion correspondante est déposée sur arXiv le 12 juillet 2025 (Becker, Rush, Barnes, Rein). METR, « We are Changing our Developer Productivity Experiment Design », 24 février 2026 — biais de sélection, « unreliable signal », « more sped up now » et « only very weak evidence ». Google Cloud, annonce du rapport DORA 2025, 24 septembre 2025 — échantillon de près de 5 000 professionnels, 90 % d'adoption, plus de 80 % de gain perçu, 30 % de défiance envers le code produit, relations au débit et à la stabilité, et la citation sur l'amplification ; le rapport complet est publié sur dora.dev. Les traductions des citations sont les miennes. Aucun des deux travaux n'a été rétracté ni corrigé : la mise à jour de METR est une évolution de programme, pas un erratum, et c'est ainsi qu'elle est présentée ici.