Écrire du code vs. livrer du code : le goulot d'étranglement de l'IA

S’il fallait résumer l’essor de l’IA dans le développement en un seul chiffre, la plupart des entreprises choisiraient le plus gros. « 240 % de commits en plus. » Ce chiffre est réel. C’est aussi le moins utile disponible.

Un working paper NBER de 2026 — Writing Code vs. Shipping Code de Mert Demirer, Leon Musolff et Liyuan Yang (Working Paper 35275) — a utilisé les données de télémétrie de plus de 500 000 développeurs GitHub pour suivre l’effet des outils IA sur toute la chaîne de production. Le résultat oblige à refaire la façon dont vous mesurez tout investissement IA.

L’atténuation est le vrai sujet

Le développement logiciel traverse six étapes : écrire des lignes de code, les organiser en fichiers, les committer, soumettre des pull requests, fusionner, et publier. Les chercheurs ont suivi chacune.

Trois générations d’outils IA ont été mesurées :

Génération	Exemple	Effet cumulatif sur les commits
Autocomplétion	suggestions dans l’éditeur	+30 %
Agents synchrones	Claude Code, en binôme	+180 %
Agents asynchrones	OpenAI Codex, exécuté à distance	+240 %

Regardez maintenant ces mêmes 240 % se dissiper en aval :

+240 %  commits
  +80 %  projets
  +30 %  livraisons réelles

Il ne survit qu’un huitième du gain au niveau des commits jusqu’aux livraisons. Les sept huitièmes s’évaporent avant qu quoi que ce soit n’atteigne un utilisateur.

Les auteurs ont confirmé ce résultat sur quatre grandes places de marché d’applications : l’adoption a produit une hausse modérée du nombre de nouvelles applications, mais aucune hausse de l’usage total. Plus de logiciels livrés. Pas plus de logiciels utilisés.

Pourquoi : le maillon faible

Les auteurs appellent cela l’hypothèse du maillon faible. L’IA est très productive sur des tâches précises, mais la production globale est plafonnée par des tâches complémentaires encore assurées par des humains dont la productivité n’a pas changé.

Leur estimation de l’élasticité de substitution entre l’effort IA et l’effort humain est de 0,23 — autrement dit, l’effort IA ne remplace qu’environ un quart de l’effort humain qu’il se substitue à. Les deux sont complémentaires, pas substituables. Chaque ligne écrite par l’IA demande toujours à quelqu’un de décider si elle est correcte.

C’est le chiffre le plus important de l’article. C’est pourquoi « nous avons ajouté l’IA » et « nous livrons plus vite » sont deux affirmations distinctes.

Là où la pression est réellement apparue

Des travaux convergents rendent le mécanisme concret — mais les deux jeux de données les plus cités proviennent de rapports différents, et les lire comme une seule histoire produit des chiffres qui ne peuvent pas être tous vrais en même temps.

Le rapport AI Productivity Paradox 2025 de Faros AI (plus de 10 000 développeurs, 1 255 équipes, analyse arrêtée à juin 2025) a constaté que les équipes utilisant intensivement l’IA accomplissaient 21 % de tâches en plus et fusionnaient 98 % de pull requests en plus — tandis que le temps de revue des pull requests bondissait de 91 %, et que les indicateurs de livraison au niveau de l’organisation restaient plats.

Le rapport Faros AI de 2026, Acceleration Whiplash, est un jeu de données distinct — 22 000 développeurs dans 4 000 équipes, données de mars 2026 — et ses chiffres divergent nettement : les tâches progressent de 33,7 %, le taux de fusion de seulement 16,2 % contre 98 %, et la durée médiane de revue de 441,5 % contre 91 %. Addy Osmani a analysé ce second jeu de données pour O’Reilly Radar en juin 2026 :

Métrique	Variation
Churn du code	+861 %
Incidents par PR	+242,7 %
Bugs par développeur	+54 % (contre 9 % dans le jeu de données 2025)
Durée médiane de revue	+441,5 %
PR fusionnées sans aucune revue	+31,3 %

La ligne sur les bugs par développeur est une comparaison entre deux jeux de données distincts, pas une hausse à l’intérieur d’une seule période — et Faros la présente elle-même ainsi.

Un bon processus ne les a pas protégés. Le volume l’a simplement dépassé.

CodeRabbit a séparément étudié 470 pull requests open source de décembre 2025 — 320 co-écrits par IA contre 150 considérés comme purement humains — et a trouvé que les modifications IA portaient environ 1,7 fois plus de problèmes. Limite à signaler : le statut « purement humain » a été inféré de l’absence de signaux de co-écriture IA, et non vérifié.

Les recherches de GitClear (2 172 semaines-développeur, septembre–décembre 2025) poses le plus brutalement l’écart entre volume et valeur. Les utilisateurs quotidiens les plus intensifs écrivent entre 4× et 10× plus de travail que les non-utilisateurs. Le gain de productivité qui résiste à l’examen est bien plus faible — et contesté jusque par les auteurs : GitClear rapporte une hausse médiane de Diff Delta de 12 % pour les utilisateurs réguliers, tandis que le rapport de GitKraken publié conjointement sur les mêmes données situe les utilisateurs réguliers à 25 %. Le PDG de GitClear concède qu’une partie de ce résidu tient à un biais de sélection, les meilleurs performants se concentrant dans les cohortes IA.

L’enquête développeur 2025 de Stack Overflow montre la même fracture entre gains individuels et gains organisationnels. Environ 69 % des utilisateurs d’agents·sont d’accord pour dire que les agents ont augmenté leur productivité, et environ 70 % pour dire qu’ils ont réduit le temps passé sur des tâches précises. Mais seulement 17 % s’accordent à dire que les agents ont amélioré la collaboration au sein de leur équipe — Stack Overflow qualifie elle-même cela de l’impact le plus bas, et de loin. En parallèle, 66 % se plaignent de solutions IA « presque correctes, mais pas tout à fait », et 45,2 % disent que le débogage du code généré par IA prend plus de temps.

Ce que personne n’a chiffré

Il y a un second coût, et ce n’est pas un chiffre. Une prépublication de juillet 2026, (Im)Paired Programming, a fait produire un site web à 54 étudiants — 59 recrutés, 5 écartés pour avoir échoué aux tests d’attention — soit avec un agent de code, soit avec un agent conversationnel ne fournissant que de courts extraits génériques.

Les agents ont amélioré l’achèvement initial de la tâche. Ils ont nui à la compréhension du code, les modes d’interaction à faible effort — copier-coller des invites, accepter automatiquement les modifications — étaient associés à une compréhension plus faible, et ils n’ont pas amélioré la tâche d’extension ultérieure. Ce qui a empiré les choses : les participants préféraient quand même les agents, parce qu’ils sont rapides et faciles.

Plus de vitesse, moins de compréhension, moins de supervision. Tel est le mouvement si personne ne modifie le flux de travail.

Ce qu’il faut vraiment mesurer

Arrêtez de compter les commits. Suivez :

1. Le débit de livraison — pas les commits. Travail livré par cycle.
2. La charge de revue — temps médian jusqu’à la première revue, et temps d’attente en file.
3. Le taux de reprise — quelle part du travail fusionné est rouverte ou annulée.
4. Le taux de défauts par modification — l’écart de bugs par développeur entre les jeux de données Faros 2025 et 2026 est le chiffre qui prédit votre page d’incidents.
5. Le temps de compréhension — un humain peut-il encore raisonner sur le code après le départ de l’agent ?

La version honnête

Les outils de code IA sont un vrai levier. Ce n’est pas le levier que vous pensiez. Ils compriment l’étape la moins chère du développement et laissent les étapes coûteuses intactes — puis y ajoutent de la charge.

Le goulot d’étranglement n’a jamais été la vitesse de frappe. C’était la décision de savoir si le travail était correct. Cette étape reste humaine, reste lente, et reste la seule à déterminer si vous avez un produit ou un dépôt de code.

📖 À lire aussi : The Toggle Tax décrit la même atténuation hors du logiciel.

Sources : Demirer, Musolff & Yang, Writing Code vs. Shipping Code (NBER Working Paper 35275, rév. septembre 2026) · Faros AI, rapport AI Productivity Paradox 2025 · Faros AI, comparaison des données 2025 et 2026 · MIT Sloan, septembre 2026 · O’Reilly Radar, Agentic Code Review (Addy Osmani, juin 2026) · Stack Overflow Developer Survey 2025 · (Im)Paired Programming (arXiv:2607.26375, juillet 2026)