L’IA accélère le code, et ralentit les développeurs.

L’IA rend les développeurs plus productifs. GitHub annonce +55 % avec Copilot. Les conférences tech applaudissent. Vos propres ingénieurs confirment.

Sauf que lorsqu’on chronomètre, le résultat s’inverse. Un essai contrôlé randomisé. Seize développeurs expérimentés ; 246 tâches sur leurs propres projets open source. Résultat : 19 % plus lents avec l’IA. Et quand on leur demande après coup, ils sont convaincus d’avoir gagné 20 %.

L’écart entre ce qu’ils perçoivent et ce que le chronomètre mesure atteint 39 points.

Des développeurs expérimentés sont 19 % plus lents avec l’IA, et convaincus d’avoir gagné 20 %. L’IA réduit l’effort ressenti, pas l’effort réel (d’où la surconfiance). La rapidité de génération masque l’accumulation de défauts (d’où la dette). Et personne ne sait quoi mesurer pour le voir : le même problème que l’informatique posait à Solow en 1987.

Ce que dit le chronomètre

En juillet 2025, l’organisation METR publie un essai contrôlé randomisé. Pas un benchmark synthétique : un protocole clinique. Seize développeurs expérimentés travaillent sur 246 tâches, sur leurs propres dépôts open source. Les modèles utilisés sont ceux du moment : Cursor couplé à Claude 3.5 et 3.7 Sonnet.

L’échantillon est petit. Un premier année de licence d’économie le verra immédiatement : seize personnes, pas seize mille. La limite est réelle. Mais l’approche clinique compense le volume par la profondeur. Vrais développeurs, vrai code, conditions réelles. Enregistrements d’écran, randomisation, mesure objective du temps. C’est l’étude la plus contrôlée à ce jour sur l’usage de l’IA en développement.

Le résultat : +19 % de temps avec l’IA. Plus lents, pas plus rapides.

Avant l’expérience, ces développeurs prédisaient un gain de 24 %. Après, ils estimaient avoir gagné 20 %. Le chronomètre dit le contraire. L’écart entre prédiction initiale et réalité : 43 points.

En face, les chiffres de l’industrie disent autre chose. GitHub annonce +55 % de productivité avec Copilot. Mais les benchmarks vendeurs mesurent la vélocité de génération de code (combien de lignes produites en combien de temps), pas la qualité livrée, pas le coût de maintenance. Quand le vendeur de l’outil finance l’étude qui en mesure l’impact, le conflit d’intérêts est structurel.

Les enregistrements d’écran révèlent où le temps se perd. Selon ces enregistrements, les développeurs passent 9 % du temps total à relire du code IA qu’ils finissent par rejeter (le taux d’acceptation ne dépasse pas 44 %). L’alternance constante entre rédiger du code et rédiger des prompts fragmente l’état de concentration profonde (flow). Et sur des codebases matures (dix ans d’historique, un million de lignes, des conventions jamais documentées), l’IA n’a pas accès au contexte implicite que le développeur porte en tête. Le résultat : un outil rapide sur les mauvaises tâches, lent sur les bonnes.

Le chiffre le plus troublant n’est pas le -19 %. C’est le 43.

Pourquoi les développeurs se croient-ils plus rapides avec l’IA ?

Le psychologue Albert Bandura a formalisé en 1977 le concept d’auto-efficacité : la croyance d’un individu en sa capacité à accomplir une tâche. Ce n’est pas la compétence réelle, c’est le sentiment de compétence. Et ce sentiment a des conséquences mesurables.

Une auto-efficacité élevée pousse à réduire l’effort et l’attention. Quand les exigences de la tâche sont mal définies (le cas du développement sur une codebase complexe), cette réduction se transforme en surconfiance (Bandura, 2012). Vancouver et al. (2002) documentent le mécanisme expérimentalement : plus le sentiment de compétence est élevé, plus les erreurs logiques augmentent.

L’IA amplifie ce biais. Elle réduit l’effort cognitif perçu. Le code sort vite, la friction initiale disparaît. Le sentiment de fluidité s’installe.

Les enregistrements d’écran de l’étude METR révèlent un phénomène inattendu : du temps d’inactivité. Pas l’attente du modèle, du zoning out pur. Les développeurs décrochent mentalement. Moins d’effort ressenti, impression de vitesse. Ce zoning out est le point pivot de toute l’étude. Un mauvais choix d’outil produirait de la frustration, pas de la distraction. La distraction est le signe que l’outil altère la perception de l’effort lui-même.

L’objection la plus solide contre cette lecture vient d’Ethan Mollick, via l’étude BCG/Harvard. Pour des tâches situées dans la zone où l’IA performe réellement, les consultants sont 40 % plus productifs. Le résultat METR ne révélerait qu’un mauvais matching (adéquation tâche/outil) : les développeurs auraient utilisé l’IA sur des tâches inadaptées.

L’argument est sérieux. Mais il n’explique pas le delta de 43 points. Un mauvais matching ne produit pas du zoning out, il produit de la frustration. Et surtout : les développeurs surestiment leur vitesse après avoir utilisé l’outil. Ils ont vu le résultat, constaté leur performance, et maintiennent l’illusion. Ce n’est pas un problème de matching. C’est une altération de la perception.

Les données macro confirment cette dissonance. L’enquête Stack Overflow (2025) mesure une chute de la confiance des développeurs dans la précision de l’IA : de 40 % à 29 %. ManpowerGroup (2026) quantifie la même tendance : +13 % d’usage, -18 % de confiance. Les développeurs utilisent davantage un outil auquel ils font de moins en moins confiance. Le Thoughtworks Technology Radar a nommé le phénomène : complacency with AI-generated code (la vigilance du relecteur s’érode après une série d’expériences positives avec les suggestions IA).

Le biais d’auto-efficacité explique pourquoi les développeurs ne voient pas le ralentissement. Il n’explique pas pourquoi le ralentissement existe.

La vélocité comme poison et remède

Bernard Stiegler a forgé, et actualisé, le concept de pharmakon pour penser la technique : ce qui est simultanément poison et remède, non pas selon l’usage, mais par nature. L’idée n’est pas « l’outil est neutre, tout dépend de l’utilisateur ». L’idée est que la propriété qui fait la valeur de l’outil est la même qui produit la perte.

Appliqué à l’IA de code, le mécanisme est observable.

La vélocité. L’IA génère du code en quelques secondes. C’est le gain : prototypage rapide, réduction de la friction initiale, livrables standards accélérés. C’est aussi la perte.

CodeRabbit a analysé 470 pull requests en décembre 2025, comparant code humain et code assisté par IA. Le code IA contient 1,7 fois plus de défauts, 75 % d’erreurs logiques supplémentaires, environ huit fois plus d’opérations d’entrée-sortie excessives. Les vulnérabilités de sécurité sont 1,5 à 2 fois plus fréquentes. CodeRabbit vend de la revue de code — le biais potentiel est symétrique à celui des benchmarks Copilot. La même exigence critique s’applique. Le rapport Veracode (2025) pointe dans la même direction : 2,74 fois plus de vulnérabilités dans le code IA. Veracode vend de la sécurité applicative — même réserve, même convergence.

J’ai vécu ce mécanisme à mon échelle. Avant d’imposer un TDD strict à mes workflows Claude Code, la première version générée impressionnait. Le code sortait vite, ça compilait, ça semblait fonctionner. Puis deux gouffres de temps apparaissaient. Le premier : des régressions incompréhensibles. Le code semblait tourner, mais des fonctionnalités plantaient. Le second : un chaos documentaire (fichiers créés n’importe où, noms farfelus, architecture fantaisiste, absence d’horodatage…). Le temps « gagné » était absorbé, dépassé ?, par le debug et le ménage. Je l’exprime de façon interrogative : quiconque s’est déjà laissé prendre dans les joies du débuggage, à l’orée de la nuit, ignore le temps qui passe…

C’est ce que CodeRabbit appelle la fausse vélocité (false velocity) : l’illusion de progrès qui masque l’accumulation de défauts. Le rythme apparent accélère pendant que la dette technique s’empile en silence. Niki Lauda ne gagnait pas ses Grands Prix en appuyant plus fort sur l’accélérateur. Il les gagnait en passant du temps sur les menus réglages. La fausse vélocité, c’est le pilote qui enfonce la pédale sans avoir réglé ses suspensions.

La plasticité est le second bras du pharmakon. Les modèles évoluent, les comportements dérivent, les capacités se transforment d’une version à l’autre. Le harness (le cadre qui entoure le modèle) doit évoluer avec eux. Mais cette instabilité décourage beaucoup de l’investissement : « à quoi bon configurer mon workspace, si tout change dans trois mois ? » Et c’est quand l’IA sort du cadre qu’on perd le plus de temps. Vous avez peut-être vu cette publicité en ligne : « imaginez développer n’importe quoi, rien qu’en y pensant… » (c’est d’ailleurs ça le problème).

Le TDD (Test-Driven Development), le Specification-Driven Development, l’isolation de la logique métier : autant d’approches qui ralentissent à court terme et structurent la qualité à long terme. L’IA les rend apparemment inutiles. Le prototypage rapide crée l’illusion que ces cadres sont du formalisme superflu. Jusqu’au premier incident en production.

Et la dépendance s’installe avant la preuve. En février 2026, METR tente un suivi de l’étude initiale. Les développeurs refusent de travailler sans IA, même rémunérés pour le faire. Ce refus dit quelque chose que les métriques de productivité ne captent pas : le pharmakon a produit l’accoutumance avant même de démontrer son efficacité. L’outil dont on ne peut plus se passer n’a pas encore prouvé qu’il nous rend meilleurs.

Ce qui nous amène à une question rarement posée : si l’on ne peut pas prouver le gain, c’est peut-être parce qu’on ne sait pas quoi mesurer.

Ce que personne ne surveille : la crise de la mesure

« Les ordinateurs sont partout, sauf dans les statistiques de productivité. » Robert Solow, 1987. Prix Nobel d’économie. Le paradoxe qu’il nommait n’a jamais été résolu de manière consensuelle mais dépassé par la transformation des processus qui a fini par absorber l’informatique dans les organisations (ou l’inverse 🤔).

Quarante ans plus tard, l’histoire se répète. Torsten Slok, économiste en chef d’Apollo, écrit en 2026 : « L’IA est partout sauf dans les données macroéconomiques. » Et 374 entreprises du S&P 500 mentionnent l’IA dans leurs annonces de résultats financiers (Fortune, février 2026). Aucune donnée macro ne capture un gain de productivité significatif. L’économiste Daron Acemoglu, prix Nobel 2024, estime le gain à +0,5 % de productivité sur dix ans. Modeste comparé aux promesses, mais pas nul.

Dans Power and Progress (2023), Acemoglu et Simon Johnson posent la thèse qui manque à ce débat : le progrès technologique ne profite à la majorité que s’il est délibérément orienté vers elle. Les gains ne sont pas un sous-produit automatique de l’adoption : ils sont un choix de direction. La question n’est pas « l’IA améliore-t-elle la productivité ? » mais « qui décide ce que productivité veut dire, et pour qui ? ».

Le problème n’est pas que la mesure est fausse. Le problème est qu’on ne sait pas quoi mesurer.

Points de fonction ? Lignes de code ? Business value ? Taux de refactoring ? Qualité du code ? Nombre de Pull Requests ? Chaque métrique raconte une histoire différente. L’absence de consensus permet à chaque acteur de choisir l’indicateur qui le flatte. L’écosystème mesure la vélocité, pas le coût total de possession.

Et des coûts entiers échappent à toute mesure. Le temps que je passe à faire de la veille, à ajuster mon workspace, à optimiser mon setup (alertes sonores, écran splitté en quatre, paramétrages reconfigurés à chaque évolution du modèle) ne figure dans aucune métrique de productivité. L’IA crée une charge de maintenance cognitive permanente qui cannibalise le deep work. Personne ne la mesure parce que personne ne sait où la comptabiliser.

La littérature sur le paradoxe de Solow (Brynjolfsson, 1993) montre que les gains d’une technologie ne se matérialisent qu’après une réorganisation des processus. Les hypothèses de l’époque — erreurs de mesure, délais d’apprentissage, nécessité de refondre les processus — restent pertinentes pour l’IA. On ne « déploie pas mal » l’IA. On la superpose aux processus existants et on attend le gain. Les gains exigent une refonte. Pas une superposition.

On ne mesure pas mal la productivité IA. On ne sait pas quoi mesurer.

Pourquoi ça vous concerne

Si vous êtes DSI, vos KPIs mesurent peut-être la vélocité de vos sprints agiles, pas si facilement la valeur livrée. Le delta de 43 points entre perception et réalité existe dans vos équipes, invisible avec les métriques en place. Si vos dashboards affichent des PRs mergées sans capturer le temps de debug post-merge, le paradoxe METR vous concerne.

Si vous êtes consultant, le cadrage triple (cognitif, pharmacologique, métrologique) est une grille réutilisable. La prochaine fois qu’un CODIR affiche un tableau de bord « productivité IA », vous avez trois angles pour déconstruire le récit.

Si vous êtes tech lead, la fausse vélocité est votre risque principal. Le test : mesurez le temps de debug sur le code généré par l’IA et comparez-le au temps « gagné » à le générer. Si le ratio dépasse 1, vous perdez du temps sans le savoir.

Si vous enseignez, l’étude METR est un cas pédagogique sur les biais cognitifs et la mesure de productivité. Le delta perception/réalité de 43 points illustre le biais d’auto-efficacité de Bandura en conditions réelles, pas un protocole de laboratoire.

Ce que j’en retiens

Le paradoxe METR n’est pas un verdict contre l’IA. C’est un diagnostic d’immaturité collective.

Trois dysfonctionnements. Un biais cognitif qui empêche de percevoir le ralentissement. Un mécanisme pharmacologique où la propriété qui fait la valeur de l’outil (la vélocité, la plasticité) est celle qui produit la perte. Et une crise métrologique où personne ne sait vraiment ce qu’il faudrait mesurer.

La conclusion n’est pas « l’IA ne marche pas » (il y a un vrai gap qualitatif entre Sonnet 3.5 et Sonnet 4.6), la conclusion serait plutôt : on est encore en train d’apprendre à travailler avec elle. La première étape est de cesser de croire qu’on sait déjà le faire.

Le diagnostic est posé. Reste maintenant à construire.