Le mur des 10 % : pourquoi la productivité de l'IA plafonne et comment le franchir

DX a interrogé 121 000 développeurs dans 450 entreprises. 92,6 % utilisent des assistants de codage IA au moins une fois par mois. Le code généré par l’IA représente désormais 26,9 % des fusions en production. Les développeurs déclarent économiser environ quatre heures par semaine.¹ La productivité n’a pas dépassé les 10 %.

Ce chiffre est resté stable pendant trois trimestres consécutifs.^{1 2} L’adoption a grimpé. Le volume de code a grimpé. Les outils se sont améliorés. Les gains, non. Laura Tacho, CTO chez DX, a formulé le constat sans détour : « C’est vraiment un problème de management. Le battage médiatique laissait croire qu’il suffisait d’essayer l’IA pour que ça paie automatiquement. »³

Le rapport DORA 2025 a mis en évidence la divergence. Les organisations dotées de solides pratiques d’ingénierie ont vu l’IA amplifier leurs forces existantes. Les organisations aux pratiques fragiles ont vu l’IA amplifier leurs dysfonctionnements existants. Mêmes outils. Résultats opposés. Le rapport conclut : « Le rôle principal de l’IA dans le développement logiciel est celui d’un amplificateur. Elle amplifie les forces des organisations performantes et les dysfonctionnements de celles en difficulté. »⁴

Le mur n’est pas un problème de modèle. C’est un problème d’infrastructure. De meilleurs modèles ne franchiront pas un mur bâti sur l’absence de vérification, l’absence de contexte et l’absence de gouvernance. Les articles compagnons de celui-ci décrivent l’architecture : Anatomy of a Claw explique la couche d’orchestration, The Fabrication Firewall explique le filtre de sortie, et Context Is Architecture explique le système d’injection de contexte. Cet article explique pourquoi ces systèmes existent.

TL;DR

121 000 développeurs interrogés. 92,6 % d’adoption. Productivité bloquée à 10 %. Le mur existe parce que l’IA génère du code plus vite que les organisations ne peuvent le vérifier, le contextualiser ou le gouverner. Trois causes profondes : la famine de contexte (l’IA hallucine sans connaissance spécifique du projet), le vide de vérification (le code est livré plus vite que les processus de revue ne s’adaptent) et le déficit de gouvernance (l’IA contourne les standards de qualité que les humains appliquent). Franchir le mur nécessite une infrastructure autour de l’IA, pas une meilleure IA. La preuve : les organisations qui ont construit une infrastructure de vérification et de gouvernance ont réduit les incidents de moitié ; celles qui ont adopté l’IA sans infrastructure les ont doublés.^{4 5} Ceci est une tentative N=1 de construction de cette infrastructure, documentée avec des chiffres précis. Elle ne peut pas prouver la généralisabilité. Elle peut montrer à quoi ressemble l’autre côté du mur.

Ce que disent les données

Le jeu de données DX couvre 4,2 millions de développeurs observés entre novembre 2025 et février 2026, avec un panel détaillé de 121 000 développeurs dans 450 entreprises.¹ Les chiffres racontent deux histoires.

L’histoire de l’adoption est sans ambiguïté. Les assistants de codage IA ont atteint une pénétration quasi universelle. DX a mesuré 92,6 % d’adoption mensuelle et environ 75 % d’utilisation hebdomadaire.¹ L’enquête 2025 de Stack Overflow a révélé que 84 % des développeurs utilisent ou prévoient d’utiliser des outils d’IA.⁶ JetBrains a mesuré 85 % d’utilisation régulière auprès de 24 534 développeurs dans 194 pays.⁷ Le plafond d’adoption est proche.

L’histoire de la productivité stagne. DX a mesuré une moyenne de quatre heures économisées par semaine, inchangée par rapport aux 3,6 heures du trimestre précédent.^{1 2} Le code généré par l’IA est passé de 22 % à 26,9 % du code fusionné, mais le volume supplémentaire ne s’est pas traduit en production supplémentaire.^{1 2} Laura Tacho a identifié le calcul : les développeurs passent environ 20 % de leur temps à écrire du code. Une amélioration de 10 % sur 20 % de la journée de travail représente une amélioration globale de 2 %. « La vitesse de frappe n’a jamais été le goulot d’étranglement. »⁸

La ligne critique est la dernière. Le rapport DORA 2024 a interrogé 39 000 professionnels et constaté que pour chaque augmentation de 25 % de l’adoption de l’IA, le débit de livraison diminuait d’environ 1,5 % et la stabilité de livraison de 7,2 %.⁵ Le rapport DORA 2025 a constaté que le débit s’est rétabli (la relation est passée de négative à positive) mais la stabilité est restée négative.⁴ L’adoption de l’IA a continué de corréler avec une instabilité accrue même lorsque le débit s’améliorait.

La divergence compte plus que les moyennes. METR a étudié 16 développeurs open source expérimentés travaillant sur 246 vrais problèmes de dépôts et a constaté qu’ils mettaient 19 % plus de temps avec les outils d’IA que sans.⁹ L’essai contrôlé randomisé de Google sur 96 ingénieurs a révélé une amélioration de vitesse de 21 %, mais le résultat n’était pas statistiquement significatif (IC à 95 % franchissant zéro).¹⁰ McKinsey a trouvé des gains de 35 à 50 % sur les tâches simples mais moins de 10 % sur les tâches de haute complexité.¹¹ Le schéma : l’IA accélère les parties du développement qui n’ont jamais été le goulot d’étranglement.

Les entreprises qui ont franchi le mur n’ont pas utilisé de meilleurs modèles. Elles ont construit une infrastructure qui captait ce que les modèles manquaient.

Pourquoi le mur existe

Trois causes profondes expliquent le plateau. Chacune opère indépendamment. Ensemble, elles forment un plafond que de meilleurs modèles ne peuvent percer.

Famine de contexte

Les assistants de codage IA opèrent sur le code visible dans le fichier courant et le contexte qui tient dans la fenêtre de prompt. Ils ne connaissent ni vos décisions d’architecture, ni vos contrats d’API, ni vos contraintes de déploiement, ni les conventions de nommage de votre équipe — à moins que quelqu’un n’injecte ces informations.

Sans contexte spécifique au projet, le modèle devine. Il hallucine des chemins de fichiers qui suivent des conventions plausibles mais n’existent pas. Il génère des appels d’API vers des endpoints qui correspondent à des schémas courants mais pas aux vôtres. Il suggère des imports de paquets que votre projet n’utilise pas.¹²

Faros AI a analysé la télémétrie de 10 000 développeurs dans 1 255 équipes et a constaté que les pull requests assistées par l’IA sont 154 % plus volumineuses que celles non assistées.¹² Des PR plus volumineuses offrent une surface plus grande aux erreurs dépendantes du contexte. L’IA génère du code avec assurance. Le code compile. Le code ne tient pas compte de la contrainte documentée dans une page Confluence que l’IA n’a jamais vue.

Ce n’est pas un problème d’hallucination au sens de la sûreté des modèles. Le modèle fonctionne exactement comme prévu : il prédit du code probable étant donné le contexte disponible. Le problème est que le contexte disponible exclut la majeure partie de ce qui compte pour la justesse dans un codebase spécifique.

Vide de vérification

L’IA génère du code plus vite que les processus de revue existants ne peuvent l’absorber. Faros a constaté que les PR assistées par l’IA prennent 91 % plus de temps à examiner.¹² Les développeurs accomplissent 21 % de tâches en plus et fusionnent 98 % de pull requests en plus, mais le pipeline de revue est calibré pour un rythme humain.¹²

L’étude de Stanford sur le code non sécurisé a quantifié la dimension sécurité. Les chercheurs ont confié des tâches de programmation à 47 développeurs, avec et sans assistance IA. Le groupe assisté par l’IA a écrit des solutions non sécurisées plus souvent dans quatre tâches sur cinq. Sur la tâche d’injection SQL, 36 % du groupe IA a écrit du code vulnérable contre 7 % du groupe témoin. Les participants avec assistance IA étaient plus susceptibles de croire qu’ils avaient écrit du code sécurisé alors que ce n’était pas le cas.¹³ La combinaison d’une production plus rapide et d’une fausse confiance accrue crée un déficit de vérification que la revue manuelle ne peut combler à grande échelle.

GitClear a analysé 153 millions de lignes de code modifiées et a constaté que le taux de réécriture (code réécrit dans les deux semaines suivant sa rédaction) devait doubler en 2024 par rapport aux niveaux de référence pré-IA.¹⁴ L’augmentation de volume due aux outils d’IA crée du retravail qui annule partiellement les gains de productivité. L’enquête 2025 de Stack Overflow confirme cette friction : 66 % des développeurs déclarent passer plus de temps à corriger du code IA « presque correct ».⁶

Déficit de gouvernance

Le code généré par l’IA contourne les mécanismes de gouvernance que les développeurs humains ont intériorisés. Un développeur senior sait qu’il faut vérifier le guide de style, lancer le linter, mettre à jour le changelog et prévenir le responsable technique des changements d’architecture. Un assistant IA génère une solution qui satisfait le prompt. L’écart entre « compile et passe les tests » et « répond aux standards de l’organisation » relève de la gouvernance.

L’étude McKinsey de 2023 a constaté que les développeurs juniors utilisant l’IA étaient 7 à 10 % plus lents, pas plus rapides.¹¹ Les chercheurs ont attribué cela à l’écart entre le code généré et le contexte organisationnel. Les développeurs juniors n’ont pas le recul nécessaire pour évaluer si la production de l’IA respecte des standards qu’ils n’ont pas encore intériorisés. Sans infrastructure de gouvernance encodant ces standards sous forme de vérifications automatisées, la production de l’IA s’écoule en aval sans contrôle.

Le déficit de gouvernance se compose d’une équipe à l’autre. L’utilitaire généré par l’IA d’un développeur duplique le module existant d’un autre développeur. Deux endpoints générés par l’IA utilisent des formats d’erreur différents pour la même API. Les migrations générées par l’IA suivent une convention de nommage différente du standard de l’équipe. Chaque violation est mineure. L’effet cumulé est un codebase qui dérive de ses propres conventions plus vite que la revue ne peut corriger.

À quoi ressemble l’autre côté

La conclusion de DORA décrit deux populations utilisant des outils identiques. L’une a réduit les incidents de moitié. L’autre les a doublés.⁴ La variable entre les deux n’est pas l’IA qu’elles utilisent. C’est l’infrastructure autour de l’IA.

Chaque cause profonde correspond à une solution d’infrastructure. Le tableau ci-dessous trace la chaîne du problème à la solution, avec une implémentation concrète tirée d’un système que j’ai construit et documenté dans les articles compagnons. C’est une tentative avec des chiffres précis, pas une prescription universelle.

L’injection de contexte répond à la famine en s’assurant que le modèle reçoit des informations spécifiques au projet à chaque prompt. Un hook de dispatch déclenche neuf gestionnaires séquentiels qui injectent la date courante, la branche Git, le répertoire de travail, les conventions du projet, le contexte de la tâche active et les contraintes architecturales. Le modèle reçoit 200 à 400 tokens de contexte d’ancrage avant de traiter la requête de l’utilisateur. Latence mesurée : 200 ms au total pour les neuf hooks. Le modèle cesse de deviner les chemins de fichiers car il connaît les chemins réels.¹⁵

La vérification indépendante répond au vide en retirant les humains du goulot d’étranglement de la vérification pour les contrôles de routine. La boucle de développement autonome (documentée dans Anatomy of a Claw) génère du code, lance la suite de tests complète et soumet les résultats à trois agents de revue qui opèrent indépendamment. L’agent d’implémentation ne revoit jamais sa propre production. Cela reflète la conclusion selon laquelle le groupe assisté par l’IA dans l’étude de Stanford était plus confiant dans du code non sécurisé : l’auto-vérification n’est pas fiable, que l’auteur soit humain ou artificiel.¹³

La gouvernance automatisée répond au déficit en encodant les standards de l’équipe sous forme de vérifications exécutables. Le Fabrication Firewall classe chaque action sortante comme locale, partagée ou externe, reportant la publication externe à la revue humaine. Les portes de qualité bloquent les rapports de complétion qui utilisent un langage évasif (« devrait marcher », « semble correct ») au lieu de citer la sortie des tests et les chemins de fichiers. Le système applique les standards que les développeurs humains appliqueraient s’ils avaient le temps de relire chaque ligne. À la vitesse de génération de l’IA, ce n’est pas le cas.

Le système combiné produit des résultats mesurables sur son propre codebase : 4 518 fragments de code indexés pour la recherche sémantique, 49 746 fragments de mémoire répartis sur 15 800 fichiers pour la mémoire persistante, et une suite de tests qui s’exécute automatiquement avant que tout changement ne déclare sa complétion.¹⁵ Ces chiffres décrivent l’infrastructure d’un seul développeur. Ils ne peuvent pas prouver que l’approche se généralise. Ils peuvent démontrer que le mur est perméable avec les bons outils de l’autre côté.

Le ratio de gouvernance

Le système de hooks décrit dans Anatomy of a Claw contient 84 hooks. Un décompte vérifié les sépare par fonction : 35 hooks de jugement qui décident si quelque chose doit se produire, et 44 hooks d’automatisation qui exécutent des actions prédéterminées. Le ratio est de 4:5. Il a commencé à 1:6.¹⁵

Le ratio initial reflète ce que la plupart des équipes construisent en premier : l’automatisation. Injecter du contexte. Enregistrer des métriques. Formater la sortie. Journaliser l’utilisation. Ces hooks captent les 10 % que tout le monde obtient. Ils automatisent les parties mécaniques du développement qui étaient déjà partiellement automatisées avant l’IA. Les données de DX le confirment : les quatre heures économisées par semaine proviennent de la génération de code et de la réduction du code répétitif, des tâches qui étaient déjà la partie la plus rapide du cycle de développement.¹

Le glissement vers les hooks de jugement reflète d’où viennent les gains supplémentaires.

L’enquête McKinsey 2025 auprès de près de 300 entreprises a constaté que les plus performantes ont vu des améliorations de productivité de 16 à 30 % et des améliorations de qualité de 31 à 45 %.¹⁶ Ces organisations avaient une adoption développeur de 80 à 100 % combinée à une intégration organisationnelle. Le facteur différenciant n’était pas le taux d’adoption (qui corrèle avec des gains de 10 % dans tous les cas) mais l’infrastructure et les processus construits autour de cette adoption.

Le cadrage de Laura Tacho s’applique ici : « Je suis sceptique quant à la promesse de toute technologie d’améliorer la performance sans traiter ces contraintes sous-jacentes. »³ Les contraintes sous-jacentes sont des contraintes de jugement. Ce code respecte-t-il nos standards ? Ce changement casse-t-il quelque chose en aval ? Cette sortie contient-elle une fabrication ? Les hooks d’automatisation ne peuvent pas répondre à ces questions. Les hooks de jugement le peuvent, imparfaitement, en encodant les critères que les développeurs expérimentés appliquent mentalement.

Le ratio n’a pas encore atteint la parité. Le système automatise encore plus qu’il ne gouverne. C’est en soi un diagnostic : toute couche d’orchestration où les hooks d’automatisation dépassent en nombre les hooks de jugement a une marge de progression.

Ce qu’il faut réellement construire

Le système décrit dans les articles compagnons comporte 84 hooks, 43 skills, 19 agents et 15 000 lignes d’infrastructure. Vous n’avez pas besoin de 15 000 lignes. Vous avez besoin de trois choses.

Un hook d’injection de contexte. Cinq lignes de bash qui injectent la date courante, la branche et le répertoire de travail dans chaque prompt IA. Cela élimine une catégorie entière d’hallucinations : le modèle cesse d’inventer des chemins de fichiers et des noms de branches parce qu’il dispose des vrais.

#!/bin/bash
# inject-context.sh — minimum viable context injection
echo "Date: $(date +%Y-%m-%d)"
echo "Branch: $(git branch --show-current 2>/dev/null || echo 'not a git repo')"
echo "Directory: $(pwd)"

Une porte de qualité. Quinze lignes qui recherchent dans les rapports de complétion un langage évasif. Si l’agent dit « devrait marcher » au lieu de citer la sortie des tests, la porte bloque. Cela répond au vide de vérification au point d’entrée le moins coûteux.¹⁵

#!/bin/bash
# quality-gate.sh — minimum viable verification
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output instead."}'
else
  echo '{"decision":"allow"}'
fi

Un exécuteur de tests indépendant. Un hook qui lance la suite de tests du projet après chaque modification de code et échoue bruyamment si les tests cassent. L’implémentation varie selon le projet. Le principe, non : l’agent qui écrit le code ne doit pas être le seul juge de ce code.

Commencez par ce qui casse le plus dans votre flux de travail. Si votre IA hallucine des chemins de fichiers, construisez d’abord le hook de contexte. Si votre IA livre du code non testé, construisez d’abord l’exécuteur de tests. Si votre IA écrit « terminé » sans preuve, construisez d’abord la porte de qualité.

Karpathy a décrit l’évolution du vibe coding vers l’ingénierie agentique : « orchestrer des agents qui font [le travail] et agir en tant que superviseur ».¹⁷ Les trois hooks ci-dessus constituent la supervision minimale viable. Ils ne produiront pas des gains de 30 %. Ils vous feront passer de 10 % vers 15 %, et chacun que vous ajoutez révèle la prochaine contrainte à traiter.

Le mur est réel. Il est aussi spécifique. La famine de contexte, le vide de vérification et le déficit de gouvernance sont des problèmes d’ingénierie avec des solutions d’ingénierie. Les modèles continueront de s’améliorer. Le mur restera à 10 % pour chaque équipe qui traite l’IA comme un générateur de code plutôt que comme un système nécessitant une infrastructure pour gouverner sa production.

Sources