Seize développeurs open-source chevronnés ont accepté, début 2025, de se faire chronométrer sur 246 tâches réelles dans leurs propres dépôts. La moitié avec assistant IA, l'autre sans. Ils étaient convaincus d'aller plus vite avec la machine. Les mesures ont dit l'inverse.
C'est le résultat le plus dérangeant publié à ce jour sur le développement assisté par IA, et il vient d'un laboratoire qui n'avait aucun intérêt à le produire. Le métier de bâtir des logiciels traverse une décennie de promesses : générer une application en une après-midi, supprimer le besoin d'ingénieurs, transformer une idée lâchée à l'oral en produit livrable. La réalité de terrain, elle, ressemble à un paradoxe que ni les éditeurs d'outils ni leurs détracteurs ne formulent volontiers. L'IA abaisse spectaculairement le coût d'entrée du prototype. Elle ne touche presque pas au coût réel du produit fini.
Le chronomètre contre l'intuition
L'étude vient de METR, une organisation de recherche à but non lucratif spécialisée dans l'évaluation des modèles d'IA. Publiée le 10 juillet 2025, elle a suivi seize contributeurs expérimentés de grands projets open-source, équipés de Cursor Pro et de Claude 3.5 puis 3.7 Sonnet, sur des tâches piochées dans des bases de code qu'ils maîtrisaient déjà. Avant l'expérience, ces développeurs anticipaient un gain de temps de 24 %. Après l'avoir vécue, ils estimaient encore avoir gagné environ 20 %. Le chronomètre, lui, indiquait qu'ils avaient mis 19 % de temps en plus.
L'écart entre le ressenti et la mesure est le vrai sujet. METR le résume sans détour : « anecdotal reports/estimates of speed-up can be very inaccurate. » Autrement dit, l'auto-évaluation des gains de productivité est un instrument cassé. On se sent fluide parce que l'outil produit du texte en continu, parce qu'on ne reste jamais bloqué devant un écran vide. Cette sensation de mouvement permanent est confondue avec de l'avancement.
Deux précautions s'imposent avant d'ériger ce chiffre en vérité. Il porte sur des modèles du début 2025, déjà dépassés par les versions actuelles, et sur un échantillon réduit. Le −19 % n'est pas une loi permanente. Il documente un instant et un contexte précis : des experts, sur des dépôts matures qu'ils connaissent par cœur, où chaque suggestion de l'IA doit être relue, corrigée, recontextualisée. Dans cette configuration, le coût de vérification mange le gain de génération.
Pourquoi Copilot disait l'inverse
Deux ans plus tôt, une autre étude affichait des chiffres opposés. En 2023, GitHub publiait les travaux de Peng et ses coauteurs : un groupe équipé de Copilot avait codé un serveur HTTP en JavaScript en une heure onze, contre deux heures quarante et une pour le groupe sans assistance. Soit 55,8 % plus rapide. Ce résultat circule encore comme preuve massue de l'accélération promise.
Les deux études ne se contredisent pas. Elles ne mesurent pas le même objet. L'expérience GitHub portait sur une tâche unique, isolée, partant de zéro — exactement le terrain où l'IA excelle : un problème bien cadré, sans dette technique, sans contexte à charger, sans intégration à respecter. METR observait des experts plongés dans des systèmes existants, complexes, où l'essentiel du travail consiste à comprendre l'invisible avant d'écrire une ligne. Ajoutons que GitHub était juge et partie de sa propre démonstration.
| Critère | Copilot (2023) | METR (2025) |
|---|---|---|
| Terrain | Serveur HTTP, problème cadré, parti de zéro | Tâches dans des dépôts matures et complexes |
| Résultat mesuré | +55,8 % de vitesse | −19 % de vitesse réelle |
| Dette technique | Aucune | Élevée — relire et recontextualiser coûte cher |
| Indépendance | GitHub, juge et partie | Laboratoire à but non lucratif |
La leçon de ce contraste tient en une phrase : la performance de l'IA s'effondre à mesure que le contexte se complexifie. Le serveur HTTP de démonstration n'a ni utilisateurs réels, ni historique, ni cas limites, ni contraintes de sécurité héritées. Une application en production n'est faite que de cela. C'est précisément l'écart documenté dans Le mythe de l'app en un jour.
Le « problème des 70 % »
Addy Osmani, qui dirige l'expérience développeur de Chrome chez Google, a donné en 2025 le nom le plus juste à ce phénomène. Il l'appelle le « problème des 70 % ». Sa formule : « AI can get you 70% of the way there surprisingly quickly, but that final 30% — edge cases, security, production integration — remains as challenging as ever. »
Les premiers 70 % sont enivrants. L'écran se remplit, l'interface prend forme, la démo fonctionne. C'est exactement ce que vend la promesse de l'app en une journée. Mais les 30 % restants — les cas limites, la gestion des erreurs, la sécurité, l'intégration à l'existant, la montée en charge — n'ont pas bougé d'un pouce en difficulté. Ils concentrent l'essentiel du temps d'ingénierie et la quasi-totalité du risque. C'est là que les semaines se logent. C'est là, aussi, que se cache la dette décrite dans Le code IA qui revient vous hanter.
Osmani ajoute un constat qui déplace le goulot d'étranglement : « code review is becoming the new bottleneck. » Quand la génération de code devient quasi gratuite, le facteur limitant n'est plus l'écriture mais la relecture. Or relire du code que l'on n'a pas écrit, comprendre ses intentions, repérer ce qu'il fait de travers, demande au moins autant d'expertise que de l'avoir produit. Souvent davantage.
Ce que disent les chiffres de livraison
Le programme de recherche DORA de Google, qui mesure depuis des années la performance de livraison logicielle, a apporté en 2024 une donnée contre-intuitive. Sur l'année, 75,9 % des équipes utilisaient déjà l'IA, et 39 % déclaraient n'avoir que peu ou pas confiance dans le code qu'elle génère. Surtout, une hausse de 25 % de l'adoption de l'IA s'accompagnait d'une baisse de 1,5 % du débit de livraison et de 7,2 % de sa stabilité.
L'édition 2025 nuance ce tableau. Avec une adoption désormais proche de 90 %, le débit redevient positivement corrélé à l'usage de l'IA — un possible renversement, que DORA présente comme une hypothèse de « courbe en J » : les équipes traversent un creux d'apprentissage avant de remonter. À manier avec prudence, ce n'est pas une loi établie. Mais un signal résiste, têtu : la corrélation négative avec la stabilité persiste. On livre peut-être plus, on livre toujours moins solidement.
L'expertise comme amplificateur, pas comme béquille
Simon Willison, développeur et observateur attentif de ces outils, a forgé en octobre 2025 une expression utile : le « vibe engineering », par opposition au « vibe coding » qui consiste à accepter les suggestions sans les comprendre. Sa thèse tient en une idée : « AI tools amplify existing expertise. » Plus on a d'expérience d'ingénieur, meilleurs et plus rapides sont les résultats. L'IA ne remplace pas le jugement, elle le démultiplie — y compris dans le mauvais sens quand le jugement manque.
Tout ce que j'écris qui touche de près ou de loin à la sécurité, je le relis. Il n'est pas responsable de déléguer cela entièrement aux agents.
— Simon Willison — Co-créateur de Django — octobre 2025
C'est l'exact contraire de la promesse qui voudrait que l'IA dispense d'apprendre le métier. Un senior sait quelle question poser, quelle réponse de l'IA est plausible et laquelle sent l'hallucination, quel raccourci coûtera cher dans six mois. Un débutant équipé du même outil produira plus de code, plus vite — et plus de problèmes, sans savoir les voir. L'écart entre les deux ne se réduit pas avec l'IA. Il s'élargit.
Rachel Laycock, directrice technique de Thoughtworks, observait en novembre 2025 un basculement de l'industrie : « En début d'année, le secteur ne parlait que de vibe coding. C'est pratiquement passé ; on voit maintenant un effort concerté et sérieux pour penser les problèmes de contexte, d'infrastructure et de sécurité. » Le Technology Radar de son cabinet a même nommé un antipattern : la « complaisance face au code généré par l'IA » — « il est trop tentant de relâcher sa vigilance après quelques expériences positives ».
Le paradoxe de productivité, formulé
Tout converge vers un point que l'étude METR isole mieux que les autres : se sentir plus rapide n'est pas l'être. La fluidité de l'expérience — du texte qui se génère sans friction, aucun moment de blocage — est confondue avec de la vélocité. L'instrument de mesure le plus répandu dans l'industrie, le ressenti du développeur, surestime systématiquement les gains.
On entend parfois le ratio illustratif de « quatre heures pour un prototype assisté par IA contre trois semaines pour un développement traditionnel ». Présenté comme une victoire de la vitesse, il dit en réalité l'inverse : les quatre heures et les trois semaines ne produisent pas la même chose. L'une accouche d'une maquette qui impressionne en réunion. L'autre, d'un système qui encaisse des utilisateurs, des pannes, des attaques et des évolutions. Confondre les deux, c'est confondre un croquis d'architecte avec un immeuble habitable.
Ce que devient le métier
L'ingénierie logicielle assistée par IA ne ressemble pas à ce que la promesse de l'app en un jour laissait imaginer. Elle ressemble à ce qu'elle a toujours été — spécification claire, architecture pensée, tests, revue de sécurité, humain dans la boucle — avec un outil de plus pour générer des brouillons plus vite. L'outil déplace le travail vers l'amont, savoir quoi demander, et vers l'aval, savoir vérifier. Il évide le milieu, la frappe au clavier, qui n'a jamais été le cœur du métier.
Pour un dirigeant ou un porteur de projet, la conséquence est nette. La question n'est plus « combien de temps pour coder ? » mais « qui relit, qui décide, qui répond quand ça casse ? ». L'avantage durable, dans un monde où générer du code coûte presque rien, appartient à ceux capables de juger ce code. Cette compétence-là ne se télécharge pas. Elle s'acquiert sur des années, sur des systèmes réels, sur des erreurs payées comptant. L'IA l'amplifie ; elle ne la fabrique pas.
Le métier ne disparaît pas sous l'automatisation. Il se concentre sur ce que l'automatisation ne sait pas faire : porter la responsabilité de ce qui part en production. C'est cette responsabilité, et non la vitesse de frappe, qui s'achète en semaines.
Sources
- METR, « Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity » (10 juillet 2025) : https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- Peng et al. / GitHub, « The Impact of AI on Developer Productivity: Evidence from GitHub Copilot » (2023) : https://arxiv.org/abs/2302.06590
- Google, DORA 2024 Accelerate State of DevOps Report : https://dora.dev/research/2024/dora-report/
- Google Cloud, Annonce du rapport DORA 2025 : https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
- Addy Osmani, « The 70% problem: Hard truths about AI-assisted coding » (2025) : https://addyo.substack.com/p/the-70-problem-hard-truths-about
- Simon Willison, « Vibe engineering » (7 octobre 2025) : https://simonwillison.net/2025/Oct/7/vibe-engineering/
- Thoughtworks, Technology Radar — antipattern « Complacency with AI-generated code » : https://www.thoughtworks.com/en-us/radar/techniques/complacency-with-ai-generated-code
