Le mur des 10 % : pourquoi la productivité de l'IA plafonne

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 gagner 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 a laissé croire qu’il suffisait d’essayer l’IA pour que les bénéfices arrivent automatiquement. »³

Le rapport DORA 2025 a mis en évidence la divergence. Les organisations dotées de pratiques d’ingénierie solides ont vu l’IA amplifier leurs forces existantes. Les organisations aux pratiques défaillantes ont vu l’IA amplifier leurs dysfonctionnements existants. Mêmes outils. Résultats opposés. Le rapport concluait : « 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 qui peinent. »⁴

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 complémentaires à celui-ci décrivent l’architecture : Anatomy of a Claw explique la couche d’orchestration, The Fabrication Firewall explique la porte de sortie des résultats, et Context Is Architecture explique le système d’injection de contexte. L’article ci-dessous explique pourquoi ces systèmes existent.

En bref

121 000 développeurs interrogés, 92,6 % d’adoption, productivité bloquée à 10 %. Trois causes profondes expliquent ce plafond : la famine contextuelle (l’IA devine faute de connaissance du projet), le vide de vérification (le code est livré plus vite que la revue ne s’adapte) et le déficit de gouvernance (l’IA contourne les standards que les humains appliquent). DORA a constaté que l’IA amplifie aussi bien les forces que les dysfonctionnements selon l’infrastructure qui l’entoure.⁴ Percer le mur exige une infrastructure autour de l’IA, pas une meilleure IA. Cet article documente une tentative N=1 de construction de cette infrastructure, avec des chiffres concrets issus d’un système exécutant 84 hooks, 43 skills et 19 agents.

Ce que révèle l’enquête

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 Stack Overflow 2025 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é a calé. DX a mesuré en moyenne quatre heures gagnées par semaine, inchangé 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 par une production supplémentaire.^{1 2} Laura Tacho a posé le calcul : les développeurs consacrent 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 a 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é des livraisons de 7,2 %.⁵ Le rapport DORA 2025 a observé que la relation IA-débit est passée de la corrélation négative de 2024 à une corrélation positive, mais la stabilité des livraisons restait négativement associée à l’adoption de l’IA.⁴ L’adoption de l’IA continuait 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 problèmes réels 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 portant sur 96 ingénieurs a révélé une amélioration de la vitesse de 21 %, mais le résultat n’était pas statistiquement significatif (IC à 95 % traversant zéro).¹⁰

McKinsey a trouvé des gains de 35 à 50 % sur les tâches simples mais moins de 10 % sur les tâches à haute complexité, et les développeurs juniors utilisant l’IA étaient 7 à 10 % plus lents dans une étude portant sur 40 de ses propres développeurs.¹¹ Le schéma : l’IA accélère les aspects du développement qui n’ont jamais constitué le goulot d’étranglement.

Les entreprises qui ont percé le mur n’utilisaient pas de meilleurs modèles. Elles ont construit une infrastructure qui rattrapait 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 pas percer.

La famine contextuelle

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 pas vos décisions architecturales, vos contrats d’API, 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 qui n’existent pas. Il génère des appels API vers des endpoints qui correspondent à des patterns courants mais pas aux vôtres. Il suggère des imports de packages 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 présentent une surface d’exposition 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 comportement n’est pas un problème d’hallucination au sens de la sécurité des modèles. Le modèle fait exactement ce pour quoi il est conçu : prédire le code probable en fonction du 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.

Le 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 supplémentaires et fusionnent 98 % de pull requests en plus, mais le pipeline de revue est dimensionné pour un débit humain.¹²

L’étude de Stanford sur le code non sécurisé a quantifié la dimension sécurité. Les chercheurs ont confié à 47 développeurs des tâches de codage 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 assistés par l’IA étaient plus enclins à 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 fossé de vérification que la revue manuelle ne peut pas combler à grande échelle.

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

Le 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, exécuter le linter, mettre à jour le changelog et informer 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 organisationnels » constitue la gouvernance.

Les chercheurs de McKinsey ont attribué le ralentissement des développeurs juniors à 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 le résultat 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, le résultat de l’IA se propage en aval sans contrôle.

Le déficit de gouvernance se cumule entre les équipes. 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 minime. L’effet cumulé est un codebase qui s’éloigne de ses propres conventions plus vite que la revue ne peut le corriger.

Ce qu’il y a de l’autre côté du mur

La conclusion du DORA décrit deux populations utilisant des outils identiques. Les organisations dotées de pratiques solides ont vu l’IA amplifier leurs forces. Les organisations aux pratiques défaillantes ont vu l’IA amplifier leurs dysfonctionnements.⁴ La variable qui les distingue 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 issue d’un système que j’ai construit et documenté dans les articles complémentaires. L’exemple 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 les informations spécifiques au projet à chaque prompt. Un hook de dispatching déclenche neuf gestionnaires séquentiels qui injectent la date du jour, la branche Git, le répertoire de travail, les conventions du projet, le contexte de la tâche en cours 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 parce qu’on lui a communiqué les chemins réels.¹⁵

La vérification indépendante comble le 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, exécute 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 son propre résultat. Cette séparation reflète la conclusion de l’étude de Stanford selon laquelle le groupe assisté par l’IA était plus confiant dans du code non sécurisé : l’auto-vérification est peu fiable, que l’auteur soit humain ou artificiel.¹³

La gouvernance automatisée comble le déficit en encodant les standards d’équipe sous forme de vérifications exécutables. Le Fabrication Firewall classifie chaque action sortante comme locale, partagée ou externe, en différant la publication externe à la revue humaine. Les portes de qualité bloquent les rapports de complétion qui utilisent un langage évasif (« devrait fonctionner », « semble correct ») au lieu de citer les résultats de 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 vault répartis dans 15 800 fichiers pour la mémoire persistante, et une suite de tests qui s’exécute automatiquement avant que tout changement ne soit signalé comme terminé.¹⁵ 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 répartit par fonction : 35 hooks de jugement qui décident si quelque chose doit se produire, 44 hooks d’automatisation qui exécutent des actions prédéterminées, et 5 hooks utilitaires (dispatchers, gestion d’état). Le ratio de gouvernance est de 4:5. Il a démarré à 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 les sorties. Journaliser l’utilisation. Ces hooks capturent les 10 % que tout le monde obtient. Ils automatisent les aspects mécaniques du développement qui étaient déjà partiellement automatisés avant l’IA. Les données de DX le confirment : les quatre heures gagnées par semaine proviennent de la génération de code et de la réduction du code passe-partout, des tâches qui étaient déjà les plus rapides du cycle de développement.¹

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

L’enquête McKinsey 2025 portant sur près de 300 entreprises cotées en bourse a révélé que les plus performantes constataient des améliorations de productivité de 16 à 30 % et des améliorations de qualité de 31 à 45 %.¹⁶ Ces organisations affichaient 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 10 % de gains 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 les performances sans s’attaquer à 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 ? Ce résultat contient-il 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. Ce déséquilibre est en soi un diagnostic : toute couche d’orchestration où les hooks d’automatisation surpassent en nombre les hooks de jugement a une marge de progression.

Ce que vous devez réellement construire

Le système décrit dans les articles complémentaires compte 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 du jour, la branche et le répertoire de travail dans chaque prompt IA. L’injection élimine toute une catégorie 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 fonctionner » au lieu de citer les résultats de tests, la porte bloque. La porte comble le 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 test runner indépendant. Un hook qui exécute 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 workflow. 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 le test runner. 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 supervision. »¹⁷ 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. Famine contextuelle, vide de vérification et 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 toute é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 ses résultats.

Points clés à retenir

Pour les développeurs individuels. Commencez par un hook d’injection de contexte. Cinq lignes de bash qui injectent la date, la branche et le répertoire de travail éliminent toute une catégorie d’hallucinations de l’IA. Le mur commence à céder quand le modèle connaît vos vrais chemins de fichiers au lieu de les deviner.

Pour les responsables d’équipe. Mesurez votre ratio de gouvernance : combien de vos hooks IA vérifient les résultats versus automatisent des tâches. Si les hooks d’automatisation surpassent en nombre les hooks de jugement, votre équipe ne capture que les premiers 10 %. Les données de DX confirment que les quatre heures gagnées par semaine proviennent de la génération de code, des tâches qui étaient déjà les plus rapides du cycle de développement.¹

Pour les ingénieurs plateforme. Construisez la couche de vérification avant de passer l’adoption de l’IA à l’échelle. DORA a constaté que les organisations déployant l’IA sans infrastructure d’ingénierie voyaient l’instabilité croître avec l’adoption.^{4 5} Les trois causes profondes correspondent à trois solutions d’infrastructure. Commencez par celle qui génère le plus de friction dans votre pipeline.

Sources