Au cours des deux dernières années, la question de la productivité des développeurs avec l’IA a souvent été résumée à une idée simple : l’IA écrit du code plus vite, donc les développeurs doivent forcément être plus rapides eux aussi, ou être totalement remplacés, pour les plus extrêmes.
Mais est-ce vraiment le cas ?
Écrire du code ne représente qu’une partie du développement logiciel. Il faut toujours comprendre le problème, travailler dans une architecture existante, relire le code généré, lancer les tests, déboguer, merger et décider si l’on est suffisamment confiant pour mettre le tout en production.
Dès que l’on commence à mesurer cette boucle dans son ensemble, les résultats deviennent beaucoup moins évidents.
En 2026, nous disposons désormais de suffisamment d’études pour voir apparaître une tendance : l’IA peut rendre les développeurs plus rapides, mais pas dans toutes les situations. Le gain dépend fortement du développeur, de la tâche et de l’environnement technique dans lequel l’IA est utilisée : qualité des tests, documentation, tooling, instructions, architecture du projet ou encore organisation du workflow agentique.
L’étude où les développeurs étaient 19 % plus lents
Le résultat le plus discuté vient probablement de METR, une organisation de recherche à but non lucratif qui étudie notamment les capacités et l’impact des systèmes d’IA avancés.
Le papier de 2025 ne déclare pas de financeur spécifique pour cette étude. METR indique aujourd’hui ne pas accepter de financement des entreprises développant les principaux modèles d’IA, même si certaines lui fournissent gratuitement des tokens pour ses travaux de recherche et d’évaluation. Cette politique est clairement documentée en 2026, mais elle ne permet pas à elle seule de déterminer précisément comment cette étude particulière de 2025 a été financée.
Pour les prochaines études citées, je préciserai également leur financement, leur origine et leurs conditions lorsque ces informations sont disponibles. C’est important dans un domaine où les investissements se comptent en milliards et où les résultats de recherche peuvent avoir des enjeux économiques importants.
Début 2025, METR a mené un essai contrôlé randomisé avec 16 développeurs open source expérimentés travaillant sur des projets qu’ils connaissaient déjà très bien. L’étude couvrait 246 tâches réelles. Pour chaque tâche, l’utilisation de l’IA était autorisée ou interdite de manière aléatoire.
Les développeurs pensaient que l’IA les rendrait environ 24 % plus rapides. Le résultat mesuré est pourtant allé dans la direction opposée : avec l’IA, les tâches prenaient 19 % de temps supplémentaire.
Ce chiffre est intéressant, mais le contexte compte énormément.
Il ne s’agissait pas de débutants demandant à ChatGPT de créer une TODO app en vibecodant sauvagement. C’étaient des mainteneurs expérimentés travaillant sur des dépôts qu’ils connaissaient depuis environ cinq ans.
Leur workflow IA était également très différent de ce que nous appelons aujourd’hui un workflow agentique avancé. Les participants pouvaient utiliser les outils de leur choix, mais Cursor était largement utilisé, principalement avec Claude 3.5 et 3.7 Sonnet. Le développeur restait très impliqué dans la boucle : générer, lire, corriger, refaire un prompt, puis recommencer.
L’un des participants, Domenic Denicola, ancien Senior Staff Software Engineer de l’équipe Chrome chez Google et mainteneur de jsdom, a expliqué par la suite qu’il n’avait ajouté ni Cursor Rules spécifiques au projet ni serveur MCP personnalisé.
Il avait volontairement choisi de ne pas investir du temps dans cette infrastructure pour les neuf tâches avec IA qu’il devait réaliser pendant l’expérience : le coût de mise en place lui paraissait supérieur au bénéfice potentiel.
Et c’est important.
Cette expérience nous apprend quelque chose d’utile sur le développement assisté par IA au début de l’année 2025. Elle ne nous dit pas que tous les développeurs utilisant des agents, des skills, des MCP, des tests automatisés et un harness bien construit en 2026 seront 19 % plus lents.
Les modèles et les outils ont fortement évolué depuis.
METR présente d’ailleurs lui-même cette étude comme une photographie d’un contexte et d’un moment particuliers, pas comme un état des lieux pérenne du développement avec l’IA.
Pourquoi l’IA pouvait-elle ralentir un expert ?
La partie la plus intéressante de l’étude METR n’est pas seulement le chiffre final. Les chercheurs ont examiné une vingtaine d’explications possibles et trouvé des éléments allant dans le sens de plusieurs d’entre elles.
Les développeurs possédaient déjà énormément de contexte implicite sur leurs projets : architecture, conventions, parties fragiles du code, tests importants ou historique de certaines décisions.
Cette connaissance avait été accumulée pendant plusieurs années.
Le modèle, lui, n’avait pas directement accès à tout ce contexte. Demander de l’aide à l’IA pouvait donc ajouter du travail au lieu d’en supprimer.
Moins de 44 % des générations Cursor étaient acceptées. Et même lorsqu’une génération était acceptée, cela ne voulait pas dire qu’elle était utilisée telle quelle : 75 % des participants déclaraient lire chaque ligne du code généré et 56 % indiquaient devoir souvent y apporter des modifications importantes.
La vitesse de génération, à elle seule, est donc un très mauvais indicateur de productivité.
Pisser du code n’est toujours pas une valeur en soi, et ça ne va pas changer avec l’IA.
Une IA peut produire 200 lignes de code en quelques secondes. Vous pouvez ensuite passer dix minutes à vérifier que ces 200 lignes ont réellement leur place dans le dépôt.
Tout le monde n’est pas devenu plus lent
Un autre détail reçoit beaucoup moins d’attention : certains participants ont réellement bénéficié de l’IA.
Quentin Anthony, l’un des développeurs de l’étude, a ensuite parlé de son expérience dans une interview avec DX. Sa conclusion était davantage liée à l’adéquation entre la tâche et l’outil qu’à un simple « IA bonne » ou « IA mauvaise ».
La documentation, les tests et certains refactorings étaient de bons candidats. D’autres tâches beaucoup moins.
Son approche pratique était simple : limiter le temps accordé à l’IA.
Si le modèle ne converge pas vers une solution après une dizaine de minutes, mieux vaut arrêter d’essayer de sauver l’interaction et faire le travail soi-même.
Cela paraît évident, mais cela répond à un vrai problème du développement avec l’IA : le biais des coûts irrécupérables.
Vous passez dix minutes à essayer de faire comprendre quelque chose à l’agent. Il est presque correct, alors vous essayez encore. Vingt minutes plus tard, vous êtes toujours en train de déboguer l’agent au lieu de déboguer le code.
Savoir reconnaître les situations où l’IA est réellement utile pourrait donc devenir une compétence à part entière pour les développeurs.
Si vous utilisiez déjà beaucoup les modèles début 2025, cette situation vous est probablement familière : continuer à reformuler un problème parce que le modèle semble toujours être à deux prompts de comprendre ce que vous voulez réellement.
Une deuxième expérience
METR a lancé une nouvelle expérience plus large en août 2025.
En février 2026, l’organisation disposait de données provenant de 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 centrales étaient plus positives :
- Développeurs ayant déjà participé à l’étude précédente : environ 18 % de gain de vitesse.
- Nouveaux participants : environ 4 %.
Il serait tentant d’écrire :
L’IA est passée de 19 % plus lente en 2025 à 18 % plus rapide en 2026.
Mais METR précise explicitement qu’il ne faut pas tirer cette conclusion.
Les intervalles de confiance sont larges et restent compatibles avec une amélioration faible, voire inexistante. Les données sont aussi affectées par plusieurs problèmes méthodologiques.
Le premier est intéressant : les développeurs avaient changé leur manière de travailler.
Certains ne souhaitaient plus participer à une expérience qui leur imposait de réaliser environ la moitié de leurs tâches sans IA.
D’autres évitaient de soumettre certaines tâches pour lesquelles ils souhaitaient particulièrement utiliser l’IA, de peur qu’elles soient assignées au groupe sans IA.
Certains faisaient également tourner plusieurs agents en parallèle ou réalisaient autre chose pendant que l’agent travaillait.
À partir de là, même mesurer le « temps passé sur une tâche » devient compliqué.
Si Codex implémente une modification pendant que Claude Code en traite une autre et que vous relisez le diff d’une troisième, quel est exactement le temps humain nécessaire pour terminer chacune de ces tâches ?
Il existe aussi un autre biais important : la rémunération proposée aux participants est passée de 150 dollars de l’heure à 50 dollars de l’heure, ce qui a pu modifier le profil des développeurs acceptant de participer.
METR a donc décidé de revoir son protocole : les usages avaient suffisamment changé pour rendre la mesure traditionnelle du temps passé sur une tâche beaucoup moins fiable.
Vitesse ou productivité ?
METR a essayé une autre méthode en 2026 en analysant 5 305 transcripts Claude Code produits par sept membres techniques de l’organisation pendant le mois de janvier.
Selon la méthode d’estimation utilisée, les tâches assistées par IA semblaient permettre un gain de temps allant d’environ 1,5 à 13 fois.
Cela paraît spectaculaire.
Mais METR insiste immédiatement sur le fait qu’il ne faut surtout pas traduire ce résultat par :
« Les développeurs sont désormais 13 fois plus productifs. »
Les utilisateurs choisissent naturellement les tâches sur lesquelles ils pensent que l’IA sera utile.
Si une tâche prenait auparavant une demi-journée et que Claude Code permet désormais de la réaliser en vingt minutes, vous pouvez décider de la faire. Sans IA, vous ne l’auriez peut-être simplement jamais commencée.
Le coût de la tâche a diminué. Cela ne signifie pas nécessairement que la valeur produite par l’organisation a augmenté dans les mêmes proportions.
Cette analyse possède aussi d’importantes limites : elle ne porte que sur sept personnes pendant un mois, et l’estimation du temps qu’aurait nécessité une tâche sans IA repose en partie sur un LLM judge validé sur un petit nombre d’exemples.
METR présente donc lui-même ces résultats comme une sorte de borne haute exploratoire, pas comme une mesure définitive de la productivité.
Cette distinction est importante bien au-delà de leurs recherches.
Un développeur peut terminer une tâche de code cinq fois plus vite alors que la fonctionnalité complète prend toujours autant de temps à être livrée, parce que les décisions produit, la code review, la QA ou le déploiement restent les principaux goulots d’étranglement.
Et plus l’exécution devient rapide, plus une autre question prend de l’importance : est-ce que nous avons correctement défini ce que nous demandons à l’agent de construire ?
Accélérer une mauvaise spécification produit simplement une mauvaise solution plus rapidement.
Même problème, autre angle
Le rapport DORA 2025 permet d’observer le sujet sous un autre angle.
DORA, pour DevOps Research and Assessment, est un programme de recherche de Google Cloud. Il étudie depuis plusieurs années les pratiques des équipes de développement et leurs performances.
Les travaux sont conséquents, mais Google commercialise également Gemini, Google Cloud et différents produits IA destinés aux développeurs.
Cela ne suffit évidemment pas à rejeter leurs recherches, mais Google n’est pas non plus un observateur économiquement désintéressé sur la question.
Le rapport DORA 2025 a interrogé près de 5 000 professionnels de la technologie. Environ 90 % déclaraient utiliser l’IA au travail et plus de 80 % estimaient qu’elle avait amélioré leur productivité.
Pris isolément, ces résultats semblent très positifs.
Mais une analyse DORA publiée en mars 2026 apporte davantage de nuances. Elle repose notamment sur 1 110 réponses ouvertes d’ingénieurs logiciels travaillant chez Google, recueillies en 2025.
Ce n’est donc pas exactement le même échantillon que celui du rapport DORA.
Cette analyse décrit l’impact de l’IA sur le cycle de développement logiciel comme un ensemble de compromis plutôt que comme une amélioration linéaire.
L’IA accélère la génération initiale de code et réduit le coût du démarrage d’une tâche, mais une partie du temps économisé est réinvestie dans le prompting, l’audit et la vérification.
DORA parle même d’une forme de verification tax.
L’étude retrouve aussi un problème dont beaucoup de développeurs parlent aujourd’hui : celui du déplacement de la charge vers le reviewer.
Si un développeur peut produire beaucoup plus de code beaucoup plus rapidement, le développeur chargé de relire la PR ne bénéficie pas automatiquement du même multiplicateur.
Autrement dit, la génération devient moins coûteuse, mais une partie du travail se déplace vers la vérification.
DORA observe également qu’une adoption plus importante de l’IA est associée à la fois à un plus grand débit de livraison logicielle et à une plus grande instabilité des livraisons.
Leur interprétation est intéressante : l’IA fonctionne davantage comme un amplificateur que comme un multiplicateur universel de productivité.
- Si une équipe dispose déjà de bonnes API, de tests solides, d’une plateforme interne claire et de workflows fiables, l’IA peut amplifier ce système.
- Si l’outillage est fragmenté, que les tests sont faibles et que l’architecture est mal documentée, l’IA peut aussi permettre de produire de la dette technique plus rapidement.
Nous nous rapprochons ici beaucoup de l’idée de harness engineering.
Le modèle compte, mais l’environnement construit autour du modèle compte tout autant.
D’autres résultats positifs
Une étude publiée en 2026 dans Management Science, une revue scientifique internationale évaluée par les pairs, a regroupé trois expériences randomisées menées chez Microsoft, Accenture et dans une entreprise du Fortune 100 spécialisée dans la fabrication électronique dont l’identité n’a pas été rendue publique.
Au total, l’étude porte sur 4 867 développeurs.
L’accès à GitHub Copilot était associé à une augmentation de 26,08 % du nombre de tâches terminées dans l’analyse combinée.
Les développeurs moins expérimentés avaient tendance à obtenir des gains plus importants. Ils adoptaient aussi davantage Copilot et continuaient plus souvent à l’utiliser.
Les auteurs ne démontrent cependant pas précisément pourquoi ce groupe semble davantage bénéficier de l’outil, et les estimations obtenues dans chacune des entreprises prises séparément restent assez bruitées.
C’est néanmoins une preuve solide que l’assistance au code par IA peut augmenter la production dans de véritables environnements professionnels.
Mais, encore une fois, ce que l’on mesure est important.
L’étude portait sur un assistant IA principalement utilisé pour la complétion de code. Elle ne démontre pas que les releases sont devenues 26 % plus rapides, que la valeur métier a augmenté de 26 %, ou que la qualité en production s’est améliorée dans les mêmes proportions.
Concernant les possibles conflits d’intérêts : deux auteurs de l’étude, Sonia Jaffe et Sida Peng, étaient affiliés à Microsoft Research. Microsoft faisait également partie des organisations étudiées, possède GitHub et Copilot et dispose donc d’intérêts économiques importants dans ce domaine.
Deux autres auteurs, Mert Demirer et Tobias Salz, déclarent un financement de la MIT GenAI Initiative.
Cela n’invalide évidemment pas une expérience randomisée, mais ce contexte mérite d’être connu.
Enfin un peu de contradiction
Uplevel, une entreprise qui commercialise des outils d’engineering intelligence et de mesure de la performance des équipes, a publié en 2024 une étude portant sur environ 800 développeurs dans de grandes organisations ayant adopté GitHub Copilot.
L’entreprise n’a constaté aucune amélioration notable sur plusieurs indicateurs d’efficacité et a rapporté une augmentation de 41 % du taux de bugs dans le groupe ayant accès à Copilot.
Cela semble spectaculaire, mais cette étude nécessite davantage de prudence.
Il ne s’agissait pas d’une expérience contrôlée randomisée comparable à celles de METR ou de Management Science.
Uplevel a comparé les données avant et après adoption de Copilot ainsi qu’un groupe ayant accès à l’outil avec un groupe de développeurs similaires n’y ayant pas accès.
Nous ne pouvons donc pas affirmer que Copilot a causé cette augmentation de 41 %.
Un autre détail est important : l’étude mesure l’accès à Copilot, pas précisément la fréquence à laquelle chaque développeur l’utilisait.
Il existe également un contexte commercial : Uplevel vend justement des outils permettant aux entreprises de mesurer ce genre de performance.
Cet intérêt ne pousse cependant pas nécessairement vers un résultat positif pour l’IA : leur étude conclut précisément à une absence de gain notable.
La bonne approche n’est donc pas « étude d’une entreprise = étude fausse », mais simplement de comprendre la méthodologie et les intérêts possibles derrière chaque publication.
Combiner les recherches
Une méta-analyse mise en ligne sous forme de prépublication sur arXiv en mai 2026 permet de prendre du recul par rapport aux résultats individuels les plus médiatisés.
Une méta-analyse consiste à regrouper plusieurs études sur un même sujet afin d’estimer un effet global.
Les chercheurs ont ici combiné 23 études et 27 tailles d’effet provenant de travaux publiés entre 2019 et 2025 sur la programmation assistée ou non par IA.
L’effet global sur la productivité était positif mais relativement modeste : g de Hedges = 0,33, avec un intervalle de confiance à 95 % allant de 0,09 à 0,58.
Le g de Hedges permet de comparer la taille d’un effet entre différentes études. Les repères souvent utilisés sont environ 0,2 pour un petit effet, 0,5 pour un effet moyen et 0,8 pour un effet important.
Un score de 0,33 indique donc un effet positif, mais plutôt modeste.
Et non, cela ne signifie pas « +33 % de productivité ».
Plus important encore, les résultats étaient très hétérogènes.
Les gains avaient tendance à être plus importants dans les expériences contrôlées et plus faibles dans les environnements open source ou en entreprise.
Une explication possible est simplement que les tâches très contrôlées sont généralement plus faciles à isoler que le travail réel sur une codebase complexe.
« Implémente cette fonction » est beaucoup plus simple à accélérer que :
Trouve pourquoi cet écran affiche parfois un état obsolète après un retour depuis l’arrière-plan, comprends quelle couche possède cet état, vérifie que la correction ne casse pas un autre flow et prépare une PR que l’équipe pourra réellement merger.
Dans les deux cas, on parle pourtant de « programmation ».
Tests passés ≠ prêts à être mergés
Une autre research note publiée par METR en mars 2026 s’est précisément intéressée à cet écart.
Les chercheurs ont pris des pull requests générées par IA qui réussissaient SWE-bench Verified, un benchmark basé sur de vrais bugs et demandes d’évolution provenant de projets open source, puis ont demandé à de vrais mainteneurs de projets de les examiner.
Quatre mainteneurs provenant de trois projets ont participé à cette évaluation.
L’évaluateur automatisé était, en moyenne, 24,2 points de pourcentage plus optimiste que les mainteneurs concernant la possibilité de merger les modifications.
Environ la moitié des PR qui passaient le benchmark n’auraient pas été mergées telles quelles.
Cela ne signifie pas que les agents étaient incapables de corriger ces PR.
METR précise lui-même qu’ils n’avaient pas la possibilité d’itérer après avoir reçu le feedback d’un mainteneur, alors qu’un contributeur humain ferait normalement la même chose.
Mais cela montre pourquoi :
« Les tests sont verts »
n’est pas équivalent à :
« Le travail est terminé. »
C’est précisément dans cet écart que la connaissance de l’architecture, la compréhension du contexte et le jugement humain continuent de jouer un rôle essentiel.
La vraie question sur la productivité en 2026
Alors, est-ce que l’IA rend les développeurs plus rapides ?
Parfois.
Je pense que vous aviez déjà deviné la réponse si vous n’avez pas scrollé directement jusqu’à la fin de cet article.
La question la plus intéressante devient plutôt : qu’est-ce qui fait que certains développeurs et certaines tâches bénéficient beaucoup plus de l’IA que d’autres ?
Quel était leur environnement ?
Quelle connaissance avaient-ils du projet ?
Quels outils avaient-ils mis autour du modèle ?
Quelle qualité avaient leurs tests et leur documentation ?
Et surtout : lorsque l’exécution devient plus rapide, que faisons-nous réellement du temps gagné ?
Le rôle du développeur se déplace progressivement vers la spécification, l’orchestration, la vérification et la review.
Il devient donc de plus en plus difficile de comparer directement un workflow Cursor de début 2025 avec un workflow Codex ou Claude Code construit autour d’un harness complet en 2026.
Les modèles ont changé.
Les outils ont changé.
Le contexte accessible aux agents a changé.
Et surtout, le rôle du développeur dans la boucle change lui aussi.
L’expérience idéale
L’expérience que j’aimerais voir aujourd’hui serait donc différente.
Prenons les mêmes développeurs, sur les mêmes dépôts réels, avec les mêmes tâches.
Donnons à un groupe un assistant de programmation IA basique.
Donnons à l’autre :
- un agent de programmation frontier actuel ;
- des instructions de dépôt correctement maintenues ;
- des skills spécifiques au projet ;
- un accès MCP lorsque cela est utile ;
- des outils de build et de débogage ;
- des tests automatisés et des vérifications CI ;
- de la review agentique ;
- une observabilité structurée ;
- la possibilité de faire fonctionner plusieurs agents en parallèle.
Puis mesurons non seulement le temps d’implémentation, mais aussi le temps nécessaire pour obtenir une PR acceptée, l’effort de review, les régressions, les bugs en production et la valeur métier réellement livrée.
Cela nous en apprendrait beaucoup plus sur la productivité des développeurs en 2026 qu’un nouveau benchmark mesurant simplement la vitesse à laquelle un modèle peut produire un patch ou une fonctionnalité.
Pour l’instant, les données soutiennent une réponse moins spectaculaire.
Les outils de programmation basés sur l’IA semblent globalement aider. L’effet moyen paraît positif.
Mais les gains varient énormément et, plus on se rapproche du véritable travail d’ingénierie logicielle, plus l’environnement construit autour de l’IA semble important.
Générer du code plus rapidement ne signifie pas livrer du logiciel plus rapidement.
En 2026, la productivité des développeurs avec l’IA ressemble de plus en plus à un problème d’ingénierie à part entière.
Sources
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
METR Funding Update, August 2026
Thoughts on METR's AI productivity study
Unpacking METR's findings: Does AI actually make developers faster?
We are Changing our Developer Productivity Experiment Design
Analyzing coding agent transcripts to upper bound productivity gains from AI agents
Balancing AI tensions: Moving from AI adoption to effective SDLC use
2025 DORA Report: State of AI-Assisted Software Development
The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers
The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers
Does GenAI Improve Software Developer Productivity?
A meta-analysis of the effect of generative AI on productivity and learning in programming
Many SWE-bench passing PRs would not be merged into main
Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity