Il y a un an, mon code IA ne tenait pas. 22 000 développeurs vivent la même chose.
Il y a un an, seul avec 2 agents IA sur ma propre application, je voyais le code se casser à chaque itération. J'en avais tiré une conviction sans pouvoir la chiffrer. L'édition 2026 du rapport Faros, sur 22 000 développeurs, vient de la mesurer. Plus de code que jamais, et de moins en moins qui tient.
Ce que j'ai vu sur mon propre projet
Il y a un an, j'ai construit une vraie application avec des agents IA. Pas une landing page, une application complète comme on en livre dans les DSI : un front, un back, une base de données, des API, de l'authentification et de la sécurité, le genre de système qui mobilise une équipe pendant des semaines ou des mois. MiniMax pour produire le code, GPT-5 pour l'architecture et les arbitrages, moi au pilotage. Le début a tenu ses promesses, une arborescence, des composants, des écrans en quelques heures, ce qu'un prestataire aurait facturé des semaines. Je l'ai documenté à l'époque sur mon blog, un premier retour d'expérience puis un second, plus complet.
Puis la mécanique s'est grippée. À chaque demande, l'agent corrigeait un point et en cassait un autre, ailleurs, sans rapport. Il a supprimé une section entière du footer sans me prévenir. Il a réécrit une page en perdant le header au passage. Il a cassé le menu mobile 3 fois, en changeant de méthode à chaque fois, sans explication. Un bout de code produit en 20 minutes me coûtait ensuite des heures et des heures de stabilisation, parce qu'une fonctionnalité que je croyais finie se remettait à régresser à l'autre bout du projet, pour une raison que je devais à chaque fois reconstituer.
Et c'est là que le métier a parlé. Je code depuis longtemps, et je ne regarde jamais un bout de code seulement pour ce qu'il fait aujourd'hui. Je le lis en me projetant sur sa pérennité, sa maintenabilité, la reprise par quelqu'un d'autre dans 6 mois. Vu sous cet angle, ce que produisaient les agents me posait un problème : ça tournait à l'instant T, mais je pressentais qu'on ne maintiendrait pas ce code au-delà de sa génération express. L'accélération était réelle, mais ce qui sortait n'était pas du code sur lequel on construit dans la durée. C'était du code qu'on rattrape.
À l'échelle d'un seul projet, à la main, je voyais passer chaque régression, sans pouvoir dire si mon cas valait à l'échelle d'une industrie. Un an plus tard, ces questions, la pérennité, la maintenabilité, la dette du code généré, sont au cœur des débats, et j'ai désormais les chiffres.
Le rapport, et ce qu'il mesure
Faros AI a publié l'édition 2026 de son rapport « Acceleration Whiplash », à partir de la télémétrie de 22 000 développeurs répartis sur 4 000 équipes, suivis sur environ 2 ans. J'avais cité l'édition précédente il y a quelques semaines. Celle-ci est plus dure, et elle décrit la mécanique que j'avais sous les yeux sur mon projet, multipliée par des milliers d'équipes.
Le décor d'abord. L'adoption a basculé. 60 % des développeurs utilisent au moins un outil IA chaque semaine, contre 40 % dans le jeu de données précédent. 80 % des équipes dépassent le seuil de 50 % d'utilisateurs actifs. Et surtout, le taux d'acceptation du code généré par l'IA est passé de 20 à 60 %. L'IA n'est plus l'assistant qui propose et l'humain qui tranche. Dans la majorité des cas, c'est elle qui écrit.
Plus de code que jamais
D'abord le débit. Tâches terminées par développeur, plus 34 %. Epics, ces gros morceaux fonctionnels qui courent sur plusieurs sprints, plus 66 % par développeur. Les tâches qui touchent au code, plus de 200 % au niveau des équipes. Sur l'acte d'écrire du logiciel, l'accélération n'est pas un ressenti de manager, elle est dans les données.
C'est la moitié vendeuse du tableau. L'autre moitié, je l'avais déjà vue de près.
Le code ne tient pas
Les bugs par développeur montent de 54 %. Dans l'édition précédente, la même mesure montait de 9 %. La dégradation ne se tasse pas quand l'adoption mûrit, elle s'aggrave. Le ratio d'incidents par pull request a plus que triplé, 243 % de hausse, ce qui veut dire qu'à chaque changement fusionné, la probabilité de déclencher un incident en production a été multipliée. Les incidents mensuels, plus 58 %. Pannes, événements de sécurité, défaillances vues par de vrais utilisateurs, dans la finance, la santé, l'infrastructure.
Et le code churn, le rapport entre les lignes supprimées et les lignes ajoutées peu après avoir été écrites, plus 861 %, près de 10 fois le niveau précédent. C'est mon expérience d'il y a un an mise en chiffres. Du code produit vite, jeté ou réécrit dans la foulée. À l'époque je comptais en heures de stabilisation sur un projet. Faros le compte en multipliant par presque 10 la part de code qui ne survit pas, sur des milliers d'équipes.
Pendant ce temps, la surveillance se relâche, et c'est ce qui m'inquiète le plus. La part de pull requests fusionnées sans aucune revue, ni humaine ni machine, augmente de 31 %. De plus en plus de code part en production sans que personne ne l'ait relu, au moment précis où le volume à relire n'a jamais été aussi élevé. Et quand quelqu'un relit, c'est plus long, le temps de revue médian a été multiplié par 5. Le délai entre le commit et la production réelle, lui, explose là où il est mesuré.
Le chiffre qui confirme le mécanisme
Un chiffre a changé entre les 2 éditions, et c'est celui qui m'a arrêté. L'an dernier, Faros mesurait une hausse du taux de merge de 98 % chez les équipes très exposées à l'IA. Cette année, 16 %. On pourrait croire à un essoufflement des outils. Ce n'est pas ça. Faros le dit franchement : la revue sature et étrangle le débit. On génère plus de code que le système ne sait en relire et en intégrer.
C'est une vieille histoire d'ingénierie, pas une nouveauté IA. La loi de Little, ce principe des files d'attente qui dit que plus vous avez de travail en cours en parallèle, plus chaque élément met longtemps à sortir. La théorie des contraintes, l'idée qu'une chaîne va à la vitesse de son maillon le plus lent, et qu'accélérer ailleurs qu'au goulot n'ajoute pas de la vitesse, ça empile du stock devant le goulot. L'IA a accéléré la production. Le goulot, lui, s'est déplacé vers la revue et l'intégration. Et le stock s'accumule là, visible désormais jusque dans le taux de merge qui ralentit.
Le résultat le plus inconfortable
Il y a un constat qui dérange plus que les autres. La maturité ne protège pas. On aimerait croire que les organisations solides, bonnes pratiques DevOps, scores DORA élevés, discipline de livraison, absorbent l'IA proprement, et que seules les équipes mal tenues souffrent. Les données de Faros ne le confirment pas. Les meilleures avant l'IA se dégradent autant que les autres.
Ça contredit le rapport DORA de Google Cloud, qui concluait fin 2025 que des fondations solides protègent des effets négatifs de l'IA. La différence vient de la méthode. DORA interroge, donc mesure du ressenti, et en ce moment les développeurs se sentent plus productifs, parce qu'individuellement ils le sont. Faros lit la télémétrie, donc l'aval, là où les files s'allongent et où les incidents s'accumulent. La perception est en retard sur la réalité. L'essai randomisé de METR, en 2025, l'avait déjà montré sur des seniors, mesurés 19 % plus lents avec l'IA alors qu'ils se croyaient 20 % plus rapides.
Ce que ces chiffres ne prouvent pas
Un mot de prudence, parce qu'un chiffre cité sans ses limites, c'est du marketing. Faros vend des outils de pilotage de l'ingénierie. Sa conclusion, qu'il faut plus de visibilité et de contrôle, sert son produit. La base est large et la méthode est posée, mais je lis la dernière partie du rapport avec cette réserve en tête.
Le rapport pose d'ailleurs lui-même ses limites. Les 2 éditions sont des coupes transversales du marché, pas un suivi des mêmes équipes dans le temps, donc d'une année sur l'autre on lit une direction, pas une précision au point près. Certaines mesures, le délai de mise en production surtout, ne portent que sur 10 % de l'échantillon avec une forte variance, donc le 480 % de lead time est un ordre de grandeur, pas une valeur exacte. Et ce sont des corrélations, pas des preuves de causalité. Le churn à plus de 800 % en est l'exemple : ça peut être du gâchis, ou au contraire du refactoring vertueux de vieux code que l'IA rend enfin faisable, les 2 lectures tiennent avec les chiffres. Ce qui me convainc, ce n'est donc pas un nombre isolé. C'est que Faros, DORA, METR, Asana, GitClear, par des méthodes différentes, pointent tous le même endroit.
Recommandation pour les COMEX
Si on accepte le diagnostic, le réflexe habituel est le mauvais. Devant la baisse de qualité, on ajoute des relecteurs, on durcit les portes, on allonge la QA. C'est traiter le symptôme. Le code arrive en revue dans un état qu'il n'aurait pas dû avoir, le problème est à l'écriture, pas à la relecture. Empiler des humains en aval ne répare pas ça.
Et le déplacement du goulot a une conséquence que je trouve presque ironique. Toute l'énergie mise depuis des années à augmenter la capacité de production des équipes ne porte plus là où ça compte. Ça compte maintenant dans l'absorption : la coordination, la revue, l'arbitrage de ce qui mérite d'être écrit avant qu'on l'écrive. C'est précisément la couche que beaucoup étaient pressés d'enterrer. Les rôles de coordination, le Scrum Master qui tient un flux, le RTE qui synchronise, le coach qui rend les dépendances visibles, reprennent de la valeur parce que c'est leur étage qui sature.
Un mot sur les effectifs, parce que c'est la décision la plus tentante. Les gains de production poussent à couper. Or ceux qu'on couperait sont souvent ceux qui absorbent l'écart de qualité que l'IA est en train de creuser. On coupe, les incidents montent, on réembauche dans l'urgence quelques mois plus tard. Stabiliser d'abord, décider ensuite.
Au fond, l'enjeu n'est pas la puissance du modèle, elle est réelle. L'enjeu est le pilotage de ce qu'il produit.
La question que je me pose
La question n'est sans doute pas de savoir si l'IA sait écrire du code. Elle sait, vite et beaucoup, les chiffres le montrent. Elle serait plutôt de savoir si votre dispositif sait absorber ce qu'elle produit, et à quelle vitesse la qualité se dégrade pendant qu'on en débat. Moi, je l'ai mesuré sur un projet, en heures de stabilisation. Faros l'a mesuré sur 22 000 développeurs. Les compteurs sont les mêmes, et vous les avez dans vos propres systèmes : incidents par changement, temps passé en revue, part de code fusionné sans relecture, délai réel jusqu'à la production. Reste une question, et c'est celle que je me suis posée sur mon projet avant de tout reprendre en main : une fois que vous avez vu ça dans vos chiffres, qu'est-ce que vous décidez d'en faire ?
Aller plus loin
Je forme les équipes techniques à tirer de l'IA un gain qui tient, pas la dette que ce rapport mesure : cadrage du code généré, revue, intégration, garde-fous posés à la source. Voir les formations IA pour les développeurs et les équipes de delivery, ou réserver un appel de 30 minutes.
Sources citées
- Faros AI, « AI Engineering Report 2026, The Acceleration Whiplash », 2026. 22 000 développeurs, 4 000 équipes, analyse arrêtée à mars 2026. faros.ai/research/ai-acceleration-whiplash
- Faros AI, « AI Productivity Paradox », 2025. Édition précédente, 10 000 développeurs, 1 255 équipes. faros.ai/ai-productivity-paradox
- DORA (Google Cloud), « State of AI-assisted Software Development », 2025. dora.dev/dora-report-2025
- METR, « Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity », essai randomisé, juillet 2025. metr.org. Mise à jour de février 2026 sur cohorte élargie.
- Asana, « AI Super Productivity Paradox », 2025. Plus de 9 000 répondants. asana.com/resources
- GitClear, étude 2025 sur 211 millions de lignes de code. gitclear.com
