L'IA ralentit-elle les développeurs ? Dans les coulisses de l'essai randomisé sur le ralentissement de 19 %

La sensation la plus séduisante du travail logiciel moderne, c'est de voir cinquante lignes de code répétitif apparaître en quelques secondes. Cette synthèse instantanée crée une impression puissante de vélocité, et la vidéo la traduit en chiffres : les chercheurs en apprentissage automatique prédisaient un gain de vitesse de 38 %, les économistes 39 %, les développeurs eux-mêmes 24 %. L'essai contrôlé randomisé de METR a inversé le signe. Les tâches réalisées avec l'assistance de l'IA ont pris en moyenne 19 % plus de temps. L'explication avancée est une heuristique cognitive : les développeurs se souviennent vividement des secondes passées à solliciter un modèle, mais sous-estiment systématiquement les trente minutes qui suivent, consacrées à auditer les cas limites, traquer les hallucinations et réparer les tests unitaires cassés. Juger selon le flux ou la vitesse de frappe masque l'endroit où se produit la véritable hémorragie de productivité dans les contextes professionnels complexes.

L'étude a été délibérément menée sur un terrain difficile. Entre février et juin 2025, 16 mainteneurs seniors, forts d'environ cinq ans d'historique sur leurs propres dépôts, ont réalisé 246 tickets réels du backlog. La scène : 14 dépôts open source matures et emblématiques comme scikit-learn et transformers, totalisant en moyenne plus d'un million de lignes de code, environ dix ans d'historique et près de 23 000 étoiles. Chaque ticket n'était assigné aléatoirement à la condition « IA autorisée » ou « IA interdite » qu'après que le développeur avait estimé sa difficulté, et la condition « IA autorisée » reposait principalement sur Cursor Pro avec Claude 3.5 et 3.7 Sonnet. Pour isoler l'effet causal, l'analyse a utilisé une régression log-linéaire contrôlant ces prédictions préalables à l'assignation, absorbant l'énorme variance entre un correctif de cinq minutes et un changement d'architecture de dix heures, et laissant le ralentissement de 19 % comme estimation causale. La familiarité n'était pas en cause : 44 % des participants utilisaient déjà régulièrement l'EDI propulsé par l'IA, et les enregistrements d'écran ont montré que les outils étaient utilisés dans plus de 83 % des tâches avec IA autorisée.

Le plus frappant, c'est la ténacité de la perception. Avant de commencer, les développeurs prédisaient un gain de temps de 24 % grâce à l'IA ; après avoir terminé, ils estimaient toujours un gain de 20 %. En réalité, ils étaient 19 % plus lents. Les experts extérieurs étaient encore plus optimistes, prédisant des durées réduites de 39 % en économie et de 38 % en apprentissage automatique. Cela ne signifie pas que les prédictions étaient inutiles. La corrélation de Pearson entre durée prévue et durée réelle était de 0,59 à 0,64 : les développeurs savaient quels tickets étaient plus difficiles ; ils s'étaient simplement trompés sur le signe de la contribution de l'IA. L'erreur de prédiction était collective, non idiosyncratique, et elle a survécu à l'expérience directe.

Pour voir où le temps s'en allait, les chercheurs ont annoté à la main 143 heures d'enregistrements d'écran à une résolution d'environ dix secondes, soit environ 29 % du temps total sur tâche. La référence sans IA pour les experts : 41 % de codage actif et 36 % de lecture et de recherche d'information. Dans la condition IA, cette base productive se réduit. Six pour cent du temps total partent dans la formulation de requêtes, quatre pour cent dans l'attente des générations, et neuf autres pour cent dans la relecture, le débogage et la réparation des sorties du modèle. Ce fardeau d'audit reflète une faible fiabilité : les développeurs ont dû retravailler substantiellement ou rejeter purement et simplement 56 % des suggestions de l'IA, moins de 44 % ont été acceptées telles quelles, et 75 % ont déclaré lire chaque ligne du code généré. Les petites économies de temps d'écriture ont été plus que compensées par la boucle de relecture, réallouant l'effort cognitif de la réflexion constructive sur le système vers une vérification épuisante.

Pourquoi les dépôts matures résistent-ils à l'aide ? C'est l'argument central de la vidéo. À cette échelle, l'ingénierie consiste surtout à lire : parcourir des architectures complexes, repérer les couplages délicats entre sous-systèmes, et respecter des invariants non écrits qui maintiennent le système stable. Ces projets dépendent d'un contexte implicite du dépôt, d'idiomes stylistiques et de règles propres au domaine qui vivent dans la tête des mainteneurs et ne sont pas explicitement spécifiés pour qu'un modèle puisse les analyser. Les fenêtres de contexte locales peinent avec de telles dépendances non locales, si bien que même des modèles de pointe comme Claude 3.7 échouent souvent à rester idiomatiques sur une base de code d'un million de lignes. Le modèle tend à produire du code d'apparence plausible qui ignore comment un changement dans un module déclenche des défaillances en cascade le long du graphe de dépendances. La vidéo résume cela en un développeur junior qui tape à une vitesse surhumaine mais avec une insouciance totale, forçant les seniors à dépenser plus d'énergie à corriger l'hallucination qu'il n'en aurait fallu pour écrire depuis zéro.

Situer ce résultat dans le corpus de preuves plus large éclaire quand le ralentissement s'applique. Un document de travail du NBER de mai 2026 suivant plus de 100 000 développeurs GitHub constate que l'autocomplétion augmente les commits d'environ 40 %, les agents interactifs jusqu'à un cumul de 140 %, et les agents autonomes jusqu'à 180 %, mais les gains s'atténuent fortement en remontant la hiérarchie de production : 50 % pour les projets et 30 % pour les releases, avec des lignes de code en hausse de 741 % mais des releases en hausse de seulement 20 %. Ce schéma correspond à un modèle du maillon faible avec une élasticité de substitution de 0,25 entre l'effort de l'IA et l'effort humain. Une étude observationnelle dose-réponse sur 16 223 ingénieurs de Microsoft estime 40,5 % de pull requests en plus durant les semaines les plus intenses d'utilisation de Copilot, à temps de codage équivalent. Une étude de cas longitudinale en entreprise portant sur 802 développeurs soumis à une directive de mi-2025 visant à doubler les pull requests fusionnées par ingénieur a bien atteint 2,09 fois la référence antérieure à la directive en avril 2026, mais la charge par relecteur a environ doublé et la couverture de relecture automatisée est passée d'environ 19 % à environ 84 % tandis que la relecture humaine s'amincissait. La télémétrie de JetBrains sur deux ans avec 800 développeurs montre que les utilisateurs d'IA ajoutent 587 caractères par mois contre 75 pour les non-utilisateurs, accompagnés de plus de suppressions et de plus de changements de contexte. Le ralentissement observé par METR occupe donc un coin spécifique : de réels gains de vitesse existent pour le travail routinier et le code vierge, mais pour la maintenance à forte familiarité et à hauts standards, le gain de vitesse se transforme en dette de relecture.

La leçon de la vidéo est de redéfinir la vélocité professionnelle comme vitesse de vérification plutôt que vitesse de rédaction. Dans les systèmes matures, le goulot d'étranglement n'est pas la rapidité de production du texte mais la rapidité avec laquelle la justesse peut être établie ; les futurs outils devraient donc aller au-delà de la complétion vers une vérification autonome en bac à sable local et des interfaces qui minimisent l'effort de relecture humaine au lieu de maximiser le volume généré. L'illusion est persistante ; même après des centaines d'heures, les développeurs croyaient toujours être 20 % plus rapides. Un suivi de février 2026 utilisant la même méthodologie laisse entrevoir un apprentissage, avec le sous-groupe des participants d'origine estimé à moins 18 % et un intervalle large englobant zéro, tandis que les développeurs nouvellement recrutés se situent autour de moins 4 %. La conclusion demeure : le progrès viendra moins d'une machine qui écrit plus vite que d'un système qui aide les humains à prouver que le code fonctionne.