Voici un résultat qui devrait faire réfléchir tout responsable ingénierie. Une étude rigoureuse menée par l’organisation METR a pris des développeurs open source expérimentés, leur a confié de vraies tâches sur leurs propres projets — des bases de code qu’ils connaissaient intimement — et les a assignés aléatoirement à compléter ces tâches avec ou sans outils IA. Les développeurs utilisant l’IA étaient 19 % plus lents. Pas plus rapides. Plus lents.
Le paradoxe : ces mêmes développeurs avaient prédit qu’ils seraient 24 % plus rapides avec l’IA. Ils se croyaient plus productifs tout en étant mesurément moins productifs. L’écart entre perception et réalité — 43 points de pourcentage — n’est pas une erreur d’arrondi. C’est un malentendu systémique sur la façon dont les outils IA interagissent avec les workflows établis.
Ce résultat ne signifie pas que les outils de codage IA sont inutiles. Il signifie quelque chose de plus nuancé et de plus important : greffer l’IA sur un workflow existant empire les choses avant de les améliorer. Et la plupart des organisations sont coincées dans la phase de « pire » sans s’en rendre compte.
Ce que l’Étude METR a Réellement Mesuré
Le design de l’étude mérite d’être compris parce qu’il corrige les faiblesses de la plupart des recherches sur la productivité IA. Les études antérieures utilisaient souvent des participants auto-sélectionnés, des tâches artificielles, ou des gains de productivité auto-déclarés — autant de biais orientant les résultats vers le positif.
METR a étudié 16 développeurs open source expérimentés. Ce n’étaient pas des étudiants ni des débutants. C’étaient des mainteneurs et contributeurs significatifs à des projets établis, travaillant sur des tâches tirées de leurs propres dépôts. Chaque développeur était assigné aléatoirement à compléter certaines tâches avec des outils IA et d’autres sans. La randomisation est essentielle — elle contrôle la difficulté des tâches, le niveau des développeurs et la complexité des projets.
Le résultat : les tâches assistées par IA prenaient 19 % plus de temps en moyenne. L’effet était statistiquement significatif et persistait à travers différents types de tâches et niveaux d’expérience.
Les chercheurs ont investigué les causes. Plusieurs facteurs se combinaient pour créer le ralentissement :
Temps de formulation des prompts. Traduire un modèle mental de ce que le code devrait faire en un prompt produisant une sortie utile n’est pas gratuit. Les développeurs passaient un temps considérable à rédiger, réviser et clarifier leurs requêtes. Pour des développeurs qui savaient exactement quoi taper, la formulation du prompt était pure surcharge.
Attente de la génération. La génération de code IA n’est pas instantanée. L’attente introduit un temps mort qui n’existait pas quand le développeur tapait simplement. Pour les courtes tâches, le temps de génération dépassait parfois le temps qu’il aurait fallu pour écrire le code manuellement.
Correction du code « presque juste ». C’est le coût le plus insidieux. Le code généré par l’IA est fréquemment proche du correct mais subtilement erroné — un nom de variable qui ne respecte pas les conventions du projet, un cas limite non géré, une fonction de bibliothèque appelée avec des paramètres légèrement incorrects. Identifier et corriger ces quasi-erreurs demande concentration et temps, et la charge cognitive est souvent supérieure à celle qu’aurait représentée l’écriture du code depuis zéro.
Changements de contexte. Travailler avec l’IA introduit une oscillation continue entre le modèle mental du développeur et la sortie du modèle. Le développeur pense au problème, puis bascule vers l’évaluation de l’interprétation de l’IA, puis revient à reconsidérer sa propre approche. Cette alternance a un coût cognitif mesurable.
Débogage d’erreurs subtiles. Le code généré qui semble correct mais contient des erreurs logiques cachées est plus difficile à déboguer que le code écrit par le développeur lui-même, parce que ce dernier n’a pas la « trace mentale » d’avoir construit la logique étape par étape. Il débogue la pensée de quelqu’un d’autre — sauf que cet « autre » est un modèle probabiliste qui ne pense pas de façon que les humains peuvent facilement retracer.
Le Stack Overflow 2025 Developer Survey fournit un contexte corroborant : seulement 29 % des développeurs font confiance à la précision du code généré par l’IA, en baisse par rapport à 40 % en 2024. Et 66 % citent la même frustration : des solutions IA « presque justes, mais pas tout à fait ». L’étude révèle aussi que si 84 % des développeurs utilisent ou prévoient d’utiliser des outils IA, les attitudes positives ont chuté de plus de 70 % à environ 60 %. L’industrie adopte les outils tout en devenant plus sceptique à leur égard.
La Courbe en J de l’Adoption
Les résultats METR s’inscrivent dans un pattern que les chercheurs en adoption appellent la courbe en J. Quand une technologie transformative est introduite dans un système existant, la productivité n’augmente pas linéairement. Elle plonge d’abord. Le plongeon survient parce que le nouvel outil modifie le workflow, mais le workflow n’a pas été reconfiguré autour de cet outil. L’organisation fait tourner un nouveau moteur sur une vieille transmission. Les engrenages grincent.
La courbe en J a été documentée à travers de nombreuses transitions technologiques. Quand les tableurs ont remplacé les grands livres manuels, les premiers adoptants passaient plus de temps à apprendre l’outil qu’ils n’en économisaient à l’utiliser. Quand le courriel a remplacé les mémos, l’adoption initiale en entreprise ralentissait réellement la communication parce que les gens écrivaient les courriels comme des lettres formelles et les consultaient aussi rarement que le courrier physique. La technologie était transformatrice, mais la transformation prenait du temps parce que les workflows environnants devaient rattraper.
Les outils de codage IA se trouvent en début de pente descendante de la courbe en J pour la plupart des organisations. Les outils ont été adoptés. Les workflows ne se sont pas adaptés. Et le plongeon de productivité est réel, mesurable, et mal interprété.
Beaucoup d’organisations voient le plongeon et concluent que les outils sont surévalués. Elles se retirent, réduisent les investissements, et déclarent que le codage IA « ne fonctionne pas pour nous ». C’est la mauvaise conclusion. Le plongeon n’est pas la preuve que l’outil échoue. C’est la preuve que le workflow autour de l’outil n’a pas été reconfiguré.
D’autres organisations voient le plongeon et tentent de le surmonter par la force en imposant davantage d’utilisation des outils IA, en ajoutant plus d’outils, ou en mesurant les développeurs sur des métriques d’adoption IA. C’est également contre-productif. Forcer une adoption plus élevée d’un outil non intégré dans un workflow reconfiguré ne fait qu’approfondir le plongeon.
Publicité
Le Problème « Nouveau Moteur, Vieille Transmission »
Le problème de fond est architectural. La plupart des organisations logicielles sont structurées autour d’un modèle de travail spécifique : les humains écrivent le code, d’autres humains le révisent, les équipes se coordonnent via des stand-ups et des cérémonies de sprint, la qualité est assurée par la revue de code et les tests manuels. Chaque processus, rôle et outil suppose qu’un être humain écrit le code.
Quand les outils de codage IA sont introduits dans cette structure, ils sont traités comme un moyen plus rapide pour les humains d’écrire du code. Le développeur utilise Copilot, Cursor ou Claude Code pour générer un premier jet, puis le révise et l’affine exactement comme il réviserait la pull request d’un autre humain. Le processus de revue de code ne change pas. Les cérémonies de sprint ne changent pas. La structure d’équipe ne change pas. Les critères d’évaluation ne changent pas.
Dans cette configuration, l’IA n’est pas une capacité transformatrice. C’est une autocomplétion sophistiquée. Elle fait gagner du temps sur l’acte mécanique de taper, mais en coûte davantage en formulation de prompts, évaluation des sorties et correction d’erreurs. Pour les développeurs expérimentés qui tapent vite et pensent clairement, l’effet net est neutre ou négatif — exactement ce que l’étude METR a constaté.
Les organisations qui ont réalisé de vrais gains de productivité grâce aux outils de codage IA sont celles qui ont reconfiguré leurs workflows autour des capacités de l’outil. Elles sont passées de « l’humain écrit le code, l’IA assiste » à « l’IA écrit le code, l’humain évalue ». Elles ont modifié leurs processus de revue : de la revue de code ligne à ligne à l’évaluation orientée résultats. Elles ont restructuré leurs équipes : de grands groupes axés sur l’implémentation à de petits groupes axés sur la spécification.
Le cadre des cinq niveaux de maturité du codage IA de Ben Shapiro est utile ici. La plupart des organisations sont au Niveau 2 (itération — l’IA génère des ébauches, les humains les affinent) avec des workflows de Niveau 1 (conçus pour du code écrit par des humains). Le décalage entre la capacité de l’outil et le design du workflow est là où vit la courbe en J. Les organisations qui reconfigurent leurs workflows pour correspondre à l’utilisation des outils de Niveau 2 ou 3 voient des gains de productivité. Celles qui conservent des workflows de Niveau 1 tout en utilisant des outils de Niveau 2 constatent le ralentissement de 19 %.
Pourquoi la Perception Diverge de la Réalité
La découverte la plus troublante de l’étude METR est peut-être l’écart de perception. Les développeurs croyaient être 24 % plus rapides tout en étant réellement 19 % plus lents. Ce n’est pas un excès de confiance modéré. C’est une méperception systémique.
Plusieurs facteurs l’expliquent. Les outils IA créent un sentiment de productivité qui ne correspond pas à la production réelle. Voir du code apparaître à l’écran plus vite donne l’impression d’être productif, même si le temps total jusqu’à un code fonctionnel augmente. Le coup de dopamine procuré par la génération de 50 lignes de code en quelques secondes est réel, même si les 15 minutes suivantes sont passées à trouver et corriger les trois bugs subtils dans ces 50 lignes.
Il y a aussi un biais de sélection dans la façon dont les développeurs évaluent leur expérience IA. Ils se souviennent des tâches où l’IA leur a fait gagner beaucoup de temps — générer du code répétitif, structurer du code inconnu, écrire de la documentation. Ils sous-pondèrent les tâches où l’IA leur a coûté du temps — déboguer des erreurs subtiles générées, reformuler des prompts défaillants, annuler du code généré qui a cassé quelque chose en amont. Les expériences positives sont vives et mémorables. Les expériences négatives ressemblent à de la friction normale de débogage et ne sont pas attribuées à l’outil’IA.
Cet écart de perception est dangereux au niveau organisationnel. Si les développeurs se croient plus productifs avec les outils IA, ils plaideront pour plus d’adoption. Les managers qui s’appuient sur les auto-déclarations des développeurs croiront que l’adoption fonctionne. L’organisation continue d’investir dans un outil qui réduit réellement la productivité, parce que personne ne mesure la bonne chose. Les 46 % de développeurs qui déclarent ne pas faire entièrement confiance au code généré par l’IA sont en réalité les plus clairvoyants — ils ont correctement identifié l’écart de qualité même s’ils ne peuvent pas précisément quantifier l’impact sur la productivité.
Comment Gravir la Courbe en J
Reconnaître la courbe en J est la première étape. La deuxième est de reconfigurer délibérément les workflows pour dépasser le plongeon. Plusieurs approches concrètes accélèrent la transition :
Adapter le workflow au niveau de l’outil. Si votre équipe utilise l’IA au Niveau 2 (itération), reconfigurez votre processus de revue de code en conséquence. Au lieu de réviser chaque ligne générée par l’IA comme si elle avait été écrite par un humain, évaluez la sortie par rapport aux exigences. Testez le comportement, pas l’implémentation. Cela seul peut éliminer la surcharge de traiter les sorties IA comme la pull request d’un développeur junior.
Investir dans la qualité des spécifications. Les plus grands gains de productivité surviennent quand la spécification donnée à l’IA est assez précise pour produire une sortie correcte dès la première itération. Des prompts vagues produisent du code vague qui nécessite des corrections extensives. Des spécifications précises produisent du code correct nécessitant peu de révision. Former les développeurs à écrire de meilleures spécifications a un meilleur ROI que les former à utiliser les outils IA plus fréquemment.
Mesurer les résultats, pas l’activité. Les organisations coincées dans la courbe en J mesurent l’adoption de l’IA (combien les développeurs utilisent-ils l’outil ?) plutôt que l’impact de l’IA (l’équipe livre-t-elle plus de logiciel fonctionnel ?). La première métrique encourage un usage performatif de l’outil. La seconde révèle si l’outil améliore réellement la production.
Accepter le plongeon. Pour les organisations en début de parcours d’adoption IA, le plongeon de productivité est normal et attendu. Se précipiter pour l’éliminer en forçant davantage d’utilisation de l’outil l’aggrave. Le plongeon se résout quand les workflows sont reconfigurés, pas quand l’utilisation de l’outil augmente. Donnez aux équipes le temps et la permission d’expérimenter des changements de workflow plutôt que d’imposer des objectifs d’adoption.
Commencer par les bonnes tâches. Les outils IA apportent le plus de valeur sur les tâches bien spécifiées, riches en code répétitif, avec des critères d’acceptation clairs. Ils apportent le moins de valeur sur les tâches complexes et riches en contexte dans des bases de code familières — exactement le scénario mesuré par l’étude METR. Commencer l’adoption IA par les tâches où l’outil excelle construit confiance et habitudes avant de l’appliquer aux tâches où la courbe en J est la plus abrupte.
Questions Fréquemment Posées
Qu’est-ce que why experienced devs get 19% slower with ai ?
Cet article couvre les aspects essentiels de ce sujet, en examinant les tendances actuelles, les acteurs clés et les implications pratiques pour les professionnels et les organisations en 2026.
Pourquoi why experienced devs get 19% slower with ai est-il important ?
Ce sujet est important car il a un impact direct sur la façon dont les organisations planifient leur stratégie technologique, allouent leurs ressources et se positionnent dans un paysage en évolution rapide.
Quels sont les points clés à retenir de cet article ?
L’article analyse les mécanismes clés, les cadres de référence et les exemples concrets qui permettent de comprendre le fonctionnement de ce domaine, en s’appuyant sur des données actuelles et des études de cas.
Sources et lectures complémentaires
- METR Study: Measuring the Impact of Early 2025 AI Models on Experienced Open-Source Developer Productivity — Étude contrôlée randomisée sur 16 développeurs expérimentés montrant un ralentissement de 19 % avec les outils IA, contre une accélération auto-prévue de 24 %.
- Stack Overflow 2025 Developer Survey — AI Section — Enquête industrie montrant 84 % d’adoption des outils IA, une confiance en déclin (29 % de confiance en la précision), et 66 % de frustration face aux sorties « presque justes ».
- StrongDM Five Levels of AI Coding Framework — Le modèle de maturité de Ben Shapiro pour l’adoption du codage IA, de l’autocomplétion à la dark factory.
- GitHub Copilot Productivity Study (2023) — Étude commandée par GitHub montrant une réalisation de tâches 55,8 % plus rapide avec Copilot, bien que limitée à une tâche JavaScript étroite avec des participants recrutés sur Upwork.
- McKinsey: Unleashing Developer Productivity with Generative AI — Analyse McKinsey montrant une accélération de 35 à 45 % de la génération de code mais moins de 10 % d’amélioration sur les tâches de haute complexité.
- Everett Rogers, Diffusion of Innovations (1962) — Théorie fondatrice sur les courbes d’adoption technologique, incluant le plongeon de productivité survenant lors des périodes de transition de workflow.
