Statistiques sur la vitesse du développement logiciel en entreprise (2026)

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Les statistiques sur la vitesse du développement logiciel en entreprise sont faciles à trouver et difficiles à vérifier. La plupart des compilations mélangent tailles de marché et promesses commerciales, et disent rarement à quelle vitesse de vraies équipes font passer le code de l’idée à la production. Cette page ne rassemble que des données liées à la vitesse — benchmarks de livraison, cycle times, expériences contrôlées sur l’IA, dépassements de projets et études sur l’emploi du temps — et indique la source et l’année de chaque chiffre.

Elle s’adresse aux responsables technologiques qui ont besoin d’une base défendable : un CTO qui prépare un point pour son conseil d’administration, un VP Engineering qui fixe les objectifs de l’année suivante ou une équipe achats qui compare des prestataires promettant une « livraison deux fois plus rapide ». Si vous préparez un grand projet et souhaitez voir comment ces benchmarks se traduisent en plan de livraison, notre page consacrée aux services de développement logiciel d’entreprise montre comment nous organisons équipes, pipelines et jalons autour d’eux.

Lisez ces chiffres avec une réserve en tête : les métriques de vitesse n’ont de sens qu’associées à la stabilité. Une équipe qui déploie dix fois par jour et casse la production chaque semaine n’est pas rapide, elle est bruyante. C’est pourquoi chaque section ci-dessous associe des chiffres de débit à des chiffres de qualité, exactement comme les KPI de développement logiciel devraient être associés dans votre propre tableau de bord.

Quelles sont les principales statistiques sur la vitesse du développement logiciel en entreprise en 2026 ?

Les principales statistiques sur la vitesse du développement logiciel en entreprise en 2026 couvrent quatre domaines : la fréquence de déploiement, le temps nécessaire pour qu’une modification atteigne la production, l’effet de l’IA sur ces délais et la fréquence des dérapages des grands programmes. Ces douze chiffres sont les plus cités dans les discussions de planification ; chacun est détaillé plus bas.

1. 19 % des équipes étaient des performeurs d’élite dans l’étude State of DevOps 2024 de DORA, avec des déploiements à la demande et des délais inférieurs à un jour ; 25 % étaient peu performantes et livraient entre une fois par mois et une fois tous les six mois.
2. Moins de 25 heures : c’est le cycle time d’élite (du premier commit à la production) dans les benchmarks LinearB 2026, fondés sur 8,1 millions de pull requests de 4 813 équipes.
3. Moins d’1 heure de prise en charge et moins de 3 heures de revue caractérisent un flux de pull requests d’élite dans le même jeu de données.
4. 90 % des professionnels de la tech utilisaient l’IA au travail selon le rapport DORA 2025, et plus de 80 % estimaient qu’elle augmentait leur productivité.
5. 55,8 % plus rapides : c’est le gain mesuré pour les développeurs utilisant GitHub Copilot dans une expérience contrôlée de 2023.
6. Environ 21 % plus rapides : c’est le gain mesuré pour 96 ingénieurs de Google utilisant l’IA dans un essai randomisé de 2024.
7. 19 % plus lents : des développeurs open source expérimentés ont mis plus de temps sur de vraies tâches avec des outils d’IA dans l’étude METR de 2025, tout en pensant avoir été 20 % plus rapides.
8. 91 % de temps de revue en plus et 98 % de pull requests fusionnées en plus ont été mesurés par Faros AI en 2025 dans les équipes très utilisatrices d’IA.
9. 10 à 15 % de gain de productivité grâce aux seuls assistants de code IA, et 25 à 30 % avec une refonte complète des processus, selon le Bain Technology Report 2025.
10. 16 % du temps des développeurs est consacré à l’écriture de code selon l’Atlassian State of Developer Experience 2025 ; la moitié des développeurs perdent 10 heures ou plus par semaine à cause des frictions organisationnelles.
11. 45 % de dépassement budgétaire et 7 % de retard en moyenne pour les grands projets informatiques, avec 56 % de valeur en moins que prévu (McKinsey et Université d’Oxford).
12. 80 % des grandes organisations d’ingénierie logicielle devaient disposer d’équipes de platform engineering d’ici 2026 selon une prévision de Gartner, contre 45 % en 2022.

À quelle vitesse les équipes d’entreprise livrent-elles ? Benchmarks DORA

Les équipes d’entreprise livrent à des vitesses très différentes : dans l’étude DORA 2024, le cinquième le plus rapide déploie à la demande avec un délai inférieur à un jour, tandis que le quart le plus lent a besoin d’un à six mois pour qu’une modification arrive en production. DORA (DevOps Research and Assessment, aujourd’hui intégré à Google Cloud) mène cette enquête depuis plus de dix ans, ce qui en fait le benchmark public de performance de livraison le plus utilisé.

DORA mesure la vitesse avec deux métriques — la fréquence de déploiement et le délai de mise en production des changements — et la stabilité avec deux autres : le taux d’échec des changements et le temps de rétablissement après un déploiement raté. Voici les clusters de performance 2024 :

Source : DORA, Accelerate State of DevOps Report 2024. Les pourcentages sont des parts de répondants, pas d’entreprises.

Deux détails comptent pour les lecteurs en entreprise. D’abord, vitesse et stabilité évoluent ensemble : les équipes d’élite ont à la fois les délais les plus courts et les taux d’échec les plus bas, ce qui contredit l’idée répandue qu’aller plus vite signifie casser davantage. Ensuite, le cluster moyen a un taux d’échec plus faible (10 %) que le cluster élevé (20 %). DORA l’explique par le fait que certaines équipes achètent leur stabilité en livrant moins souvent, un compromis qui tient rarement à mesure que les systèmes grandissent.

Qu’est-ce qui a changé dans le rapport DORA 2025 ?

Le rapport DORA 2025, publié en septembre 2025 sous le titre State of AI-assisted Software Development, a remplacé les quatre clusters classiques par sept archétypes d’équipes, à partir de près de 5 000 réponses et de plus de 100 heures d’entretiens. Le plus grand changement concerne l’IA : pour la première fois, son adoption était positivement liée au débit de livraison, tout en restant négativement liée à la stabilité de livraison.

Pour les entreprises, les archétypes « freinés par les processus » et « goulet d’étranglement legacy » représentent ensemble 28 % des répondants. Ce sont les deux endroits où la vitesse se perd à cause de l’organisation et de l’architecture plutôt que des compétences des ingénieurs, et tous deux sont typiques des grandes entreprises dotées de systèmes cœur anciens.

Qu’a constaté DORA en 2024 sur l’IA et la vitesse de livraison ?

En 2024, DORA a constaté qu’une hausse de 25 % de l’adoption de l’IA s’accompagnait d’une baisse de 1,5 % du débit de livraison et de 7,2 % de la stabilité, alors même que cette adoption augmentait la productivité individuelle de 2,1 %, la satisfaction au travail de 2,6 % et la qualité de la documentation de 7,5 %. L’explication : l’IA facilite la production de lots de modifications plus volumineux, et DORA associe depuis toujours les gros lots à une livraison plus lente et plus risquée. En 2025, l’effet sur le débit est devenu positif, mais la pénalité sur la stabilité est restée.

Qu’est-ce qu’un bon cycle time ? Benchmarks d’ingénierie

Un bon cycle time pour une équipe d’entreprise est inférieur à une semaine de travail, et les équipes d’élite passent sous les 25 heures du premier commit à la production selon les Software Engineering Benchmarks 2026 de LinearB. Le jeu de données couvre 8 109 244 pull requests de 4 813 équipes et 163 820 contributeurs dans 42 pays, ce qui en fait l’une des plus grandes sources publiques de données de vitesse au niveau des pull requests.

Le cycle time se décompose en étapes, et chaque étape a son propre benchmark. Les examiner séparément est le moyen le plus rapide de voir où une équipe d’entreprise perd des jours :

Source : LinearB, 2026 Software Engineering Benchmarks Report (seuils P75 du niveau élite).

Ce tableau explique pourquoi les petites modifications comptent autant. La prise en charge et la revue sont les étapes où les pull requests attendent, et l’attente augmente avec la taille : un changement de 100 lignes se relit en quelques minutes, un changement de 1 000 lignes attend qu’un collègue ait un après-midi libre. Les équipes qui réduisent leur cycle time le font généralement en réduisant la taille des pull requests et en protégeant le temps de revue, pas en demandant aux ingénieurs de taper plus vite. Notre guide sur le CI/CD en développement logiciel traite le versant pipeline du même problème : l’étape de déploiement.

Comment le code généré par l’IA modifie-t-il la vitesse des pull requests ?

Le code généré par l’IA rend les pull requests plus volumineuses et plus lentes à fusionner, selon les données LinearB 2026. Les pull requests assistées par l’IA comptaient 408 lignes au 75e centile contre 157 sans IA, et seulement 32,7 % des pull requests générées par l’IA étaient fusionnées en 30 jours, contre 84,4 % des pull requests manuelles. Dans le même temps, 88,3 % des organisations utilisaient des outils d’IA tous les jours ou plusieurs fois par semaine, et 44,7 % n’en mesuraient pas formellement l’impact.

Jellyfish a observé le versant plus optimiste de la même tendance dans son bilan 2025 : quand l’adoption de l’IA dans une équipe passait de 0 % à 100 %, le cycle time médian baissait de 16,7 à 12,7 heures (24 % plus rapide) et les pull requests par ingénieur passaient de 1,36 à 2,9. L’adoption d’agents de revue de code IA est passée de 14,8 % à 51,4 % des entreprises entre janvier et octobre 2025. Les deux jeux de données sont compatibles : les équipes qui adoptent pleinement l’IA et adaptent leur processus de revue accélèrent, tandis que celles qui ajoutent simplement du code IA à un processus inchangé créent une file d’attente de revue.

Les grandes entreprises livrent-elles plus lentement que les start-up ?

Les grandes entreprises livrent du logiciel de manière mesurablement plus lente que les start-up, mais l’écart est plus faible qu’on ne le pense et provient de la charge organisationnelle plutôt que du niveau des ingénieurs. Les données LinearB analysées par DevPro Journal (3,6 millions de pull requests) situaient le cycle time d’élite à moins de 29 heures en grande entreprise, contre moins de 27 heures pour les scale-up et moins de 21 heures pour les start-up.

Source : DevPro Journal, « A Quantitative (and Actionable) Analysis of Enterprise Software Delivery Speed », janvier 2024, d’après des données LinearB.

La même analyse montre que les équipes d’entreprise ne partagent qu’environ 70 % de leurs heures de travail, car elles sont réparties sur plusieurs fuseaux horaires. Cela suffit à allonger les temps de prise en charge et de revue. Ajoutez les comités de validation des changements, les revues de sécurité, les trains de release partagés et les dépendances entre des dizaines de services, et les huit heures supplémentaires de cycle time d’élite s’expliquent facilement.

DORA identifie deux autres freins propres aux grandes entreprises. Des priorités organisationnelles instables étaient associées en 2024 à un risque d’épuisement professionnel 40 % plus élevé, et les équipes contraintes d’utiliser une plateforme interne ont vu leur débit baisser de 8 % et leur stabilité de 14 %. Autrement dit, les structures que les entreprises ajoutent pour aller plus vite peuvent les ralentir lorsqu’elles sont imposées plutôt qu’adoptées.

L’IA accélère-t-elle le développement logiciel ? Ce que montrent les études

L’IA accélère les tâches de codage isolées dans les expériences contrôlées, généralement de 20 à 55 %, mais son effet sur la livraison de bout en bout en entreprise est plus faible, et il peut même être négatif pour des développeurs expérimentés travaillant sur des bases de code complexes. La réponse dépend de ce que l’on mesure : une tâche unique et bien définie, la semaine d’un développeur ou le parcours d’une équipe de l’idée à la production.

Pourquoi les gains sur les tâches ne se traduisent-ils pas par une livraison plus rapide ?

Les gains de l’IA sur les tâches ne se répercutent pas un pour un sur la livraison, car l’écriture du code n’est qu’une petite partie du cycle de livraison. Bain estime que l’écriture et le test du code ne représentent que 25 à 35 % du temps entre l’idée et le lancement ; le reste est consacré à la découverte, à la conception, à la revue, à l’intégration, aux validations et à la mise en production. Une étape de codage 50 % plus rapide dans une tranche de 30 % du calendrier fait gagner au mieux environ 15 %, et seulement si les étapes suivantes suivent le rythme.

Faros AI parle de « paradoxe de productivité de l’IA » : la production individuelle augmente fortement, mais les indicateurs à l’échelle de l’entreprise bougent à peine, car le code supplémentaire s’accumule en revue et en test. Faros n’a trouvé aucune corrélation significative entre l’adoption de l’IA et l’amélioration de la livraison au niveau de l’entreprise dans ses données 2025. L’enquête de Bain va dans le même sens : trois entreprises sur quatre jugent que le plus difficile dans l’adoption de l’IA est de changer la façon de travailler, pas de déployer les outils.

Où l’IA fait-elle gagner le plus de temps ?

L’IA fait gagner le plus de temps sur les tâches bien définies et peu complexes, comme la documentation, le code standard et l’ossature des tests, et le moins sur la conception complexe et le débogage dans de grandes bases de code peu familières. Ce schéma traverse toutes les études ci-dessus : l’expérience Copilot portait sur une petite tâche partant de zéro, alors que METR utilisait de grands dépôts matures que les développeurs connaissaient déjà bien. Pour les équipes d’entreprise, cela invite à cibler d’abord l’IA sur la documentation, les migrations, la génération de tests et le code d’intégration répétitif. Notre article sur la façon dont les équipes développent réellement avec l’IA détaille ces flux de travail.

Statistiques d’adoption et de confiance envers l’IA dans les équipes logicielles

L’IA fait désormais partie du quotidien de presque tous les développeurs, mais la confiance dans ses résultats est faible, ce qui limite le gain de vitesse réel. Ces chiffres d’adoption et de confiance expliquent pourquoi la revue et la vérification sont devenues le nouveau goulet d’étranglement :

• 84 % des développeurs utilisent ou prévoient d’utiliser des outils d’IA, contre 76 % en 2024, et 51 % des développeurs professionnels les utilisent quotidiennement (Stack Overflow Developer Survey 2025).
• Seuls 3,1 % des développeurs font fortement confiance à la précision de l’IA, tandis que 45,7 % s’en méfient activement ; l’opinion favorable est tombée à 60 % (Stack Overflow 2025).
• 66 % citent comme principale frustration des réponses de l’IA « presque justes, mais pas tout à fait », et 45,2 % disent que déboguer du code généré par l’IA prend plus de temps (Stack Overflow 2025).
• 30 % des répondants du rapport DORA 2025 avaient peu ou pas confiance dans le code généré par l’IA, et l’utilisateur médian travaillait environ 2 heures par jour avec l’IA.
• 99 % des développeurs disent que l’IA leur fait gagner du temps et 68 % gagnent plus de 10 heures par semaine (Atlassian State of Developer Experience 2025).
• 90 % des ingénieurs logiciels en entreprise devraient utiliser des assistants de code IA d’ici 2028, contre moins de 14 % début 2024 (prévision Gartner).

Le contraste entre « 99 % gagnent du temps » et « 3,1 % font fortement confiance aux résultats » résume la situation en 2026. Le temps gagné à l’écriture est en partie reperdu à la vérification, et cette vérification a lieu en revue de code, l’étape qui limite déjà le cycle time.

Combien de temps les développeurs en entreprise consacrent-ils réellement au code ?

Les développeurs en entreprise ne consacrent que 11 à 16 % de leur temps de travail à l’écriture de code selon deux des grandes études les plus récentes, si bien que les gains de vitesse les plus importants viennent généralement de la réduction des frictions autour du code plutôt que d’un codage plus rapide. L’Atlassian State of Developer Experience 2025, mené auprès de 3 500 développeurs et managers dans six pays, situe la part du codage à 16 %.

Source : Microsoft Research, « Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era », ICSE SEIP 2025, enquête auprès de 484 développeurs de Microsoft. Le reste du temps se répartit entre d’autres activités.

Les frictions sont la principale raison de cette faible part de codage. Dans l’étude d’Atlassian, 50 % des développeurs perdaient 10 heures ou plus par semaine à cause d’inefficacités organisationnelles et 90 % au moins 6 heures ; les causes principales étaient la recherche d’informations, l’adaptation aux nouvelles technologies et les changements de contexte. 63 % estimaient que leurs dirigeants ne comprenaient pas ces difficultés, contre 44 % un an plus tôt.

La dette technique est la version au long cours du même problème. L’étude Developer Coefficient de Stripe a montré que, sur une semaine moyenne de 41,1 heures, les développeurs passaient 17,3 heures en maintenance, dont 13,5 heures sur la dette technique, et 52 % citaient les systèmes hérités et la dette technique comme principal frein à la productivité. Le chiffre date de 2018, mais il reste la mesure la plus citée de la capacité absorbée par le code ancien, et il concorde avec les 11 % de répondants que DORA 2025 classe en « goulet d’étranglement legacy ».

À quelle fréquence les projets logiciels d’entreprise sont-ils en retard ou hors budget ?

Les grands projets logiciels d’entreprise sont plus souvent en retard ou hors budget qu’à l’heure : une étude de McKinsey et de l’Université d’Oxford portant sur plus de 5 400 projets informatiques de plus de 15 millions de dollars a mesuré en moyenne 45 % de dépassement budgétaire, 7 % de retard et 56 % de valeur en moins que prévu. Environ 17 % de ces projets ont si mal tourné qu’ils ont menacé l’existence même de l’entreprise.

• 45 % de dépassement budgétaire moyen, 7 % de retard et 56 % de valeur en moins que prévu pour les grands projets informatiques (McKinsey et Université d’Oxford).
• Chaque année supplémentaire de projet ajoutait environ 15 % au dépassement de coûts dans la même étude : les projets longs sont donc disproportionnellement risqués.
• 31 % des projets logiciels étaient réussis, 50 % en difficulté et 19 % en échec selon les données CHAOS 2020 du Standish Group ; le taux de réussite était de 16,2 % en 1994 et de 37 % en 2012.
• Les petits projets réussissent dans environ 90 % des cas selon les données CHAOS, contre moins de 10 % pour les très grands.
• 73,8 % des projets atteignaient en moyenne leurs objectifs métier selon le PMI Pulse of the Profession 2024.
• Les projets menés par des professionnels dotés d’un fort sens des affaires atteignaient leurs objectifs dans 83 % des cas, respectaient le calendrier dans 63 % et le budget dans 73 % des cas, selon l’enquête PMI 2025 menée auprès de près de 3 000 répondants.

Le dénominateur commun est la taille. Les dépassements augmentent avec la durée et le périmètre, et les projets les plus performants sont découpés en petites versions ayant chacune leur valeur propre — la même leçon que tirent DORA et LinearB à l’échelle d’une modification. Notez aussi que les 7 % de retard sous-estiment le délai ressenti par les utilisateurs : les projets tiennent souvent leurs dates en réduisant le périmètre, d’où un manque de valeur (56 %) bien supérieur au retard. Pour dimensionner un projet avant son lancement, consultez notre guide d’estimation des projets logiciels.

Platform engineering, low-code et autres leviers de vitesse : statistiques

Le platform engineering est le levier de vitesse le plus largement adopté par les entreprises : Gartner prévoit que 80 % des grandes organisations d’ingénierie logicielle disposeront d’équipes plateforme d’ici 2026, contre 45 % en 2022. Les données DORA montrent que le bénéfice est réel, mais qu’il dépend de la manière dont la plateforme est introduite.

Le schéma est constant : les outils accélèrent la livraison lorsqu’ils suppriment l’attente et les étapes manuelles, et la ralentissent lorsqu’ils ajoutent des processus obligatoires. Une plateforme « golden path » qui rend la bonne pratique la plus simple aide ; une plateforme imposée à toutes les équipes quel que soit leur besoin nuit. Il en va de même pour l’automatisation du cloud, c’est pourquoi nous considérons l’ingénierie cloud et DevOps comme une composante de la vitesse de livraison et non comme un chantier d’infrastructure séparé.

Comment mesurer la vitesse de livraison de votre entreprise ?

Pour mesurer votre vitesse de livraison, relevez les quatre métriques DORA et les étapes du cycle time sur vos propres données pendant au moins un trimestre, puis comparez les médianes aux benchmarks publics présentés plus haut. Les moyennes du secteur ne sont utiles qu’une fois votre propre référence connue. Voici une démarche pratique :

1. Définir le périmètre. Commencez par trois à cinq équipes responsables de services déployables, plutôt que par toute l’organisation ; les portefeuilles mixtes masquent les goulets d’étranglement.
2. Collecter les quatre métriques DORA. La fréquence de déploiement et le délai de mise en production viennent de votre système CI/CD, le taux d’échec et le temps de rétablissement de vos données d’incidents.
3. Décomposer le cycle time. Mesurez séparément le temps de codage, de prise en charge, de revue et de déploiement à partir de votre gestionnaire de versions ; l’étape la plus lente est votre première cible.
4. Suivre la taille des pull requests. La médiane et le 75e centile des lignes modifiées par pull request prédisent mieux les retards de revue que tout autre indicateur isolé.
5. Ajouter un regard IA. Étiquetez les pull requests assistées par l’IA et comparez leur taille, leur temps de revue et leur taux de fusion avec les autres, comme le fait LinearB.
6. Interroger sur les frictions. Demandez aux développeurs combien d’heures par semaine ils perdent en attente, en recherche et en changements de contexte ; les chiffres d’Atlassian servent de point de comparaison.
7. Faire le point chaque trimestre et ne changer qu’une chose à la fois. Traitez chaque amélioration comme une expérience et surveillez les métriques de stabilité aussi attentivement que celles de vitesse.

Évitez de transformer ces chiffres en objectifs individuels. DORA et le framework SPACE rappellent tous deux que les métriques de livraison décrivent des systèmes, pas des personnes ; dès que les ingénieurs sont jugés sur leur nombre de pull requests, ce nombre augmente, mais pas la vitesse de livraison. Notre guide sur le DevOps en développement logiciel présente les pratiques qui font progresser ces métriques durablement.

Que signifient ces statistiques pour les acheteurs de logiciels d’entreprise en 2026 ?

Pour les entreprises qui achètent ou commandent un logiciel d’entreprise en 2026, les statistiques mènent à une conclusion : la vitesse de livraison dépend bien davantage de la taille des lots, du flux de revue et des frictions organisationnelles que de l’effectif ou des outils. Lorsque vous évaluez un plan interne ou un partenaire externe, voici les questions que les données invitent à poser :

• Quelle cadence de mise en production est prévue ? Un plan avec une seule grande livraison finale porte le risque de dépassement de 45 % des grands projets ; des livraisons mensuelles ou plus fréquentes le réduisent.
• Comment le délai de mise en production et le taux d’échec seront-ils suivis ? Un prestataire incapable de montrer les métriques DORA de ses projets en cours vous demande de croire une promesse.
• Comment le code généré par l’IA est-il relu ? Les pull requests plus volumineuses et les revues plus longues liées à l’IA sont bien documentées ; une équipe crédible a une règle pour les deux.
• Quelle part du calendrier est de l’attente ? Validations, environnements et demandes d’accès consomment souvent plus de temps calendaire que le développement lui-même.
• Comment le périmètre est-il découpé en versions ? Selon les données CHAOS, les petits projets réussissent environ neuf fois plus souvent que les très grands ; demandez comment le périmètre sera découpé en incréments ayant chacun leur valeur.
• Que mesure l’équipe avant la première livraison ? Une référence établie dès le premier sprint rend vérifiables les promesses de vitesse ultérieures et révèle tôt les environnements lents et les étapes de validation.
• Comment l’intégration des systèmes existants est-elle gérée ? Les goulets d’étranglement legacy touchent environ une équipe sur neuf dans DORA 2025, et c’est à l’intégration que les calendriers d’entreprise dérapent le plus souvent.

Ces critères s’appliquent qu’il s’agisse d’une nouvelle plateforme, d’un programme de modernisation ou d’un projet fortement intégré. Ils expliquent aussi pourquoi le marché du développement logiciel sur mesure continue de se tourner vers des partenaires capables de montrer des données de livraison plutôt que de simples taux horaires, et pourquoi les tendances du développement logiciel en 2026 sont dominées par le platform engineering et la gouvernance de l’IA plutôt que par de nouveaux langages.

FAQ

Publié le 25 octobre 2026. Sources : DORA, Accelerate State of DevOps Report 2024 ; DORA, State of AI-assisted Software Development 2025 ; LinearB, 2026 Software Engineering Benchmarks ; DevPro Journal, analyse de la vitesse de livraison en entreprise (2024) ; Faros AI, The AI Productivity Paradox (2025) ; Jellyfish, 2025 AI metrics in review ; Peng et al., The Impact of AI on Developer Productivity (2023) ; Google, How much does AI impact development speed? (2024) ; METR (2025) et mise à jour METR (2026) ; Stack Overflow Developer Survey 2025 ; Bain Technology Report 2025 ; Atlassian State of Developer Experience 2025 ; Microsoft, Time Warp (2025) ; Stripe, The Developer Coefficient (2018) ; McKinsey et Université d’Oxford, Delivering large-scale IT projects on time, on budget, and on value (2012) ; Standish Group CHAOS 2020 ; PMI Pulse of the Profession 2024 et 2025 ; prévisions Gartner sur les assistants de code IA, le platform engineering et le low-code. Les prévisions sont des projections, pas des mesures.