Générer 200 lignes de code en quelques secondes, puis passer dix minutes à vérifier qu’elles ont réellement leur place dans la codebase.

Si vous utilisez beaucoup l’IA pour développer, la situation vous est probablement familière.

Depuis deux ans, la question de la productivité avec l’IA est souvent résumée assez simplement : l’IA écrit du code plus vite, donc les développeurs doivent forcément travailler plus vite eux aussi. Dans sa version la plus enthousiaste, le métier disparaît au passage. Sauf qu’écrire du code n’est qu’une partie du boulot.

Il faut encore comprendre ce qu’on doit construire, travailler dans une architecture existante, relire le diff, tester, déboguer, reviewer et décider si on est suffisamment confiant pour envoyer tout ça en production.

Et dès qu’on mesure cette boucle plutôt que le nombre de lignes produites, ça devient un peu plus compliqué.

L’étude où les développeurs étaient 19 % plus lents

Début 2025, METR a mené une expérience avec 16 développeurs open source expérimentés sur 246 tâches réelles.

Pas des débutants en train de demander à ChatGPT une TODO app. Les participants travaillaient sur des dépôts qu’ils connaissaient depuis plusieurs années.

Pour chaque tâche, l’utilisation de l’IA était autorisée ou interdite aléatoirement. Avant l’expérience, les développeurs pensaient gagner environ 24 % de temps. Ils ont finalement été 19 % plus lents avec l’IA. C’est le chiffre qui a été retenu, alors que le contexte est quand même important.

L’expérience a eu lieu début 2025. Cursor est beaucoup utilisé, principalement avec Claude 3.5 et 3.7 Sonnet, et le workflow ressemble encore beaucoup à : générer, lire, corriger, reprompter, recommencer.

Domenic Denicola, l’un des participants, expliquera ensuite qu’il n’avait mis en place ni Cursor Rules spécifiques au projet ni serveur MCP personnalisé. Pour neuf tâches avec IA, investir du temps dans toute cette infrastructure ne lui paraissait simplement pas rentable. Ce qui est parfaitement logique dans le contexte de l’expérience.

Mais ça signifie aussi que cette étude mesure quelque chose de très précis : des développeurs experts, sur leur propre codebase, utilisant les outils disponibles début 2025.

Pas un workflow Codex ou Claude Code de 2026 avec des instructions du dépôt, des skills, du MCP, des tests, des outils de débogage et des agents qui travaillent plusieurs minutes seuls. METR insiste sur ce point.

Pourquoi ralentir quelqu’un qui connaît déjà son projet ?

C’est probablement la partie de l’étude la plus intéressante. Ces développeurs possédaient énormément de contexte implicite.

Ils connaissaient l’architecture, les conventions du projet, les parties fragiles, certains choix historiques et probablement pas mal de petits trucs jamais écrits nulle part. Le modèle, lui, arrivait sans tout ça. Lui demander de participer pouvait donc commencer par créer du travail supplémentaire.

Moins de 44 % des générations Cursor étaient acceptées. Et accepter une génération ne voulait même pas dire la prendre telle quelle : 75 % des participants déclaraient relire chaque ligne et 56 % devaient régulièrement modifier fortement le résultat. Pisser du code plus vite reste assez peu intéressant si quelqu’un doit tout vérifier derrière.

C’est aussi quelque chose que je retrouve de plus en plus dans mon utilisation des agents : le problème n’est pas forcément que le modèle ne sait pas coder. Il faut déjà qu’il sache comment ce projet doit être codé, et ce contexte ne tombe pas du ciel.

Toutes les tâches ne se valent pas

Tous les participants de METR n’ont pas non plus été ralentis.

Quentin Anthony, qui participait à l’étude, expliquera ensuite que certaines tâches fonctionnaient plutôt bien avec l’IA : la documentation, les tests, certains refactorings. D’autres beaucoup moins.

Sa règle était assez simple : si après une dizaine de minutes le modèle ne tend toujours pas vers une solution correcte, autant reprendre la main.

Ce qui évite un phénomène que je connais un peu trop bien : le modèle est presque arrivé au bon résultat. Encore un prompt, puis un autre. Vingt minutes plus tard, je ne débogue plus vraiment mon code. Je débogue ma conversation avec l’agent.

Savoir quand utiliser l’IA, et surtout quand arrêter de l’utiliser, fait aussi partie du boulot.

METR recommence en 2026

METR a ensuite lancé une expérience plus large.

En février 2026, elle regroupait 57 développeurs, 143 dépôts et plus de 800 tâches. Le participant médian avait environ dix ans d’expérience.

Cette fois, les estimations allaient dans une direction beaucoup plus positive : environ 18 % de gain pour les personnes ayant déjà participé à la première expérience et 4 % pour les nouveaux participants.

Donc l’IA est passée de −19 % à +18 % en un an ?

Pas vraiment. METR explique justement que les données ne permettent pas de tirer cette conclusion. Les intervalles de confiance sont larges et, surtout, la manière d’utiliser l’IA avait commencé à changer.

Certains développeurs ne voulaient plus participer s’ils devaient réaliser la moitié de leurs tâches sans IA. D’autres évitaient de proposer certaines tâches importantes de peur de tomber dans le groupe sans IA.

Et plusieurs faisaient maintenant tourner des agents en parallèle ou faisaient autre chose pendant qu’un agent travaillait.

À ce stade, mesurer le temps devient déjà bizarre.

Si Codex travaille sur une feature pendant que Claude Code en traite une autre et que je review le diff d’un troisième agent, combien de temps ai-je réellement passé sur chacune de ces tâches ?

Alors METR a fini par revoir son protocole.

Plus vite, oui. Plus productif ?

METR a essayé une autre approche en analysant 5 305 transcripts Claude Code produits par sept membres techniques de l’organisation en janvier 2026.

Selon la méthode utilisée, certaines tâches semblaient être réalisées entre environ 1,5 et 13 fois plus vite. Ça ferait une très jolie miniature YouTube.

Mais même METR explique qu’il ne faut surtout pas traduire ça par « les développeurs sont treize fois plus productifs ».

Les utilisateurs choisissent naturellement les tâches où ils pensent que l’IA sera utile. Et une tâche devenue très peu coûteuse peut maintenant être réalisée alors qu’elle aurait simplement été abandonnée avant. On fait donc potentiellement plus de choses. Ça ne veut pas dire que l’organisation produit treize fois plus de valeur.

L’analyse reste aussi limitée : sept personnes, un mois de données et une estimation du temps sans IA qui repose en partie sur un LLM judge.

C’est surtout un bon exemple du problème que j’avais en tête en commençant cet article.

On mesure quoi exactement quand on parle de productivité ? Le temps pour produire le code ? Le temps avant d’avoir une PR mergeable ? Le temps avant que la feature soit en production ?

Parce qu’on peut très bien implémenter quelque chose cinq fois plus vite et rester bloqué exactement autant de temps sur la spec, la review ou la QA.

Le travail se déplace

Le rapport DORA 2025 arrive à une observation assez proche par un autre chemin.

Près de 5 000 professionnels de la tech ont été interrogés. Environ 90 % déclaraient utiliser l’IA au travail et plus de 80 % estimaient qu’elle améliorait leur productivité.

Une analyse DORA publiée en 2026 à partir de réponses ouvertes d’ingénieurs Google nuance pas mal cette impression.

L’IA accélère notamment la génération initiale et facilite le démarrage d’une tâche. Puis une partie du temps gagné revient ailleurs : prompting, vérification, audit du code. DORA parle de verification tax.

Et surtout, la charge peut simplement se déplacer. Un développeur peut maintenant générer beaucoup plus de code. Le reviewer, lui, n’a pas soudainement obtenu quatre cerveaux et deux heures supplémentaires dans sa journée : la PR arrive juste plus vite.

DORA observe également qu’une adoption plus importante de l’IA est associée à davantage de débit de livraison, mais aussi à davantage d’instabilité. Leur idée est que l’IA agit plutôt comme un amplificateur.

Une équipe avec de bons tests, des API claires, une architecture compréhensible et de bons outils peut produire plus vite.

Une codebase mal documentée avec peu de tests peut aussi produire sa dette technique beaucoup plus vite.

Et c’est là que la question du harness commence à devenir nettement plus intéressante que celle du modèle utilisé.

Il y a quand même de vrais gains

Tout n’est heureusement pas une longue histoire de développeurs passant leur temps à vérifier les hallucinations de Claude.

Une étude publiée dans Management Science regroupe trois expériences randomisées chez Microsoft, Accenture et une entreprise du Fortune 100, pour un total de 4 867 développeurs.

L’accès à GitHub Copilot était associé à 26,08 % de tâches terminées en plus dans l’analyse combinée.

Les développeurs les moins expérimentés semblaient également obtenir davantage de gains. C’est une donnée importante : dans de vrais environnements professionnels, l’assistance par IA peut bien augmenter la quantité de travail réalisée. Mais l’étude mesure principalement l’utilisation d’un assistant de complétion de code.

Elle ne dit pas que les releases sont sorties 26 % plus vite ou que la qualité du logiciel a augmenté de 26 %. Encore cette histoire de ce qu’on choisit de mesurer.

Il faut également garder en tête que deux auteurs étaient affiliés à Microsoft Research et que Microsoft possède GitHub et Copilot. Ça n’annule évidemment pas les résultats d’une expérience randomisée, mais autant savoir qui finance et produit les recherches que l’on cite.

Et parfois, il ne se passe rien

Uplevel a publié en 2024 une étude portant sur environ 800 développeurs utilisant GitHub Copilot.

Cette fois, aucun gain notable n’apparaissait sur plusieurs indicateurs d’efficacité. L’entreprise rapportait même une augmentation de 41 % du taux de bugs dans le groupe ayant accès à Copilot.

Sauf qu’il ne s’agissait pas d’une expérience randomisée comme chez METR ou dans l’étude précédente. Uplevel comparait notamment des données avant et après l’adoption de Copilot et différents groupes de développeurs. On ne peut donc pas conclure que Copilot a causé 41 % de bugs supplémentaires.

L’étude mesure également l’accès à l’outil, pas précisément son utilisation. Bref : résultat intéressant, conclusion beaucoup plus limitée que le joli « +41 % de bugs avec l’IA ».

Quand on mélange toutes les études

Une méta-analyse publiée en préprint en mai 2026 a regroupé 23 études menées entre 2019 et 2025.

L’effet global sur la productivité était positif, avec un g de Hedges de 0,33. Ce n’est pas « +33 % de productivité ».

Le g de Hedges mesure une taille d’effet standardisée. Avec les repères couramment utilisés, 0,33 correspond plutôt à un effet positif modeste.

Surtout, les résultats différaient énormément d’une étude à l’autre. Les gains étaient généralement plus élevés dans les expériences contrôlées et plus faibles dans les environnements professionnels ou open source. Ce qui n’est pas très étonnant.

« Implémente cette fonction » est une tâche assez facile à isoler. « Trouve pourquoi cet écran conserve parfois un état obsolète après un retour depuis l’arrière-plan, comprends qui possède cet état, corrige-le sans casser les autres flows et prépare une PR que l’équipe acceptera » l’est un peu moins. Les deux finissent pourtant dans la même catégorie : « développement ».

Tests verts, PR refusée

METR a aussi publié en mars 2026 une expérience que je trouve particulièrement intéressante.

Ils ont pris des PR générées par IA qui réussissaient SWE-bench Verified puis les ont confiées à de vrais mainteneurs.

Quatre mainteneurs provenant de trois projets ont participé.

L’évaluation automatisée était en moyenne 24,2 points de pourcentage plus optimiste que les mainteneurs sur la possibilité de merger les changements.

Environ la moitié des PR qui passaient le benchmark n’auraient pas été mergées telles quelles.

Ça ne veut pas dire que les agents étaient incapables de terminer le travail. Ils n’avaient notamment pas la possibilité de modifier leur PR après le feedback du mainteneur.

Mais ça rappelle quelque chose de basique :

Tests verts ≠ travail terminé.

Le code peut fonctionner et rester mauvais pour le projet : mauvaise abstraction, API étrange, duplication.

Alors, plus productifs ?

Oui, non, ça dépend.

L’effet moyen des outils IA semble aujourd’hui plutôt positif. Certaines tâches peuvent même être accélérées de manière assez spectaculaire. Mais plus les études se rapprochent du vrai travail sur une codebase, plus les résultats deviennent variables.

Ce qui m’intéresse surtout, c’est ce qui se trouve autour du modèle.

Quelle connaissance avons-nous du projet ? Quelles instructions lui avons-nous données ? Les tests sont-ils réellement capables de détecter une mauvaise modification ? L’agent peut-il builder, lancer l’app, lire les logs, comprendre une erreur ?

Est-ce qu’on lui demande de modifier 80 fichiers d’un coup ou est-ce qu’on lui donne une tâche suffisamment petite pour qu’un humain puisse encore comprendre ce qui s’est passé ?

En gros : est-ce qu’on utilise juste un très bon modèle ou est-ce qu’on lui a construit un environnement dans lequel il peut réellement travailler ?

C’est aussi pour ça que comparer directement Cursor début 2025 et un workflow agentique de 2026 commence à avoir ses limites. Les modèles ont changé, mais surtout, tout ce qu’on construit autour d’eux a changé.

L’expérience que j’aimerais voir maintenant

Si je pouvais choisir l’expérience suivante, je reprendrais des développeurs expérimentés sur leurs propres dépôts et de vraies tâches.

Mais au lieu de comparer « IA / pas IA », je comparerais deux manières de l’utiliser. D’un côté, un assistant de code classique ; de l’autre, un agent actuel avec des instructions propres au dépôt, des skills adaptés au projet, éventuellement du MCP, les outils de build et de débogage, les tests, la CI et une vraie boucle de review.

Et surtout, je ne mesurerais pas uniquement le temps nécessaire pour produire un patch.

Je regarderais le temps avant qu’une PR soit réellement acceptée, l’effort de review, les régressions et les bugs apparus ensuite. Parce qu’au fond, c’est peut-être là que notre manière de mesurer l’IA commence à être en retard sur notre manière de l’utiliser.

Je peux aujourd’hui générer beaucoup plus de code qu’il y a deux ans. La partie difficile reste de savoir si j’aurais dû générer ce code-là.

Sources