Comment savoir si l'IA rend vos équipes IT plus productives ?

Une large majorité le pense : selon DORA, plus de 80 % des professionnels du logiciel pensent que l'IA les a rendus plus productifs. Les essais contrôlés divergent : 19 % de temps en plus chez METR, 26 % de pull requests en plus dans le plus grand essai mené en entreprise, avec de larges marges d'erreur.

La question n'est plus de savoir si les équipes IT se servent de l'IA. Le rapport DORA 2025, l'enquête annuelle de Google Cloud sur la performance des équipes logicielles, a interrogé près de 5 000 professionnels : 90 % utilisent l'IA au travail, contre environ 76 % un an plus tôt, et plus de 80 % pensent qu'elle a augmenté leur productivité. Reste à savoir ce que ces gains deviennent à l'échelle d'une DSI, et comment le montrer à un comité qui a déjà signé le budget.

Trois familles de preuves circulent, et elles ne disent pas la même chose :

• Le déclaratif : on demande aux développeurs s'ils se sentent plus productifs. C'est la mesure la plus répandue et la moins fiable.
• La télémétrie : on lit ce qu'enregistrent les outils (tickets, pull requests, incidents). Elle compte l'activité plutôt que la valeur, et vient souvent d'éditeurs qui vendent cette mesure.
• L'essai contrôlé : on tire au sort les tâches ou les personnes qui travaillent avec ou sans IA, puis on compare. C'est la plus rigoureuse, et la plus rare.

Ce carnet les trie, parce que la crédibilité d'un dossier d'investissement se joue là. Il se lit avec notre carnet sur le coût de l'IA : celui-là traite de ce que l'IA coûte, celui-ci de ce qu'elle rapporte.

Pas forcément. Dans l'essai contrôlé de METR, des développeurs expérimentés ont mis 19 % de temps en plus avec l'IA, alors qu'ils croyaient avoir gagné 20 %. D'autres études trouvent des gains, sur des tâches artificielles ou en comptant le volume produit, les chiffres d'éditeurs divergent entre eux, et les développeurs eux-mêmes deviennent plus prudents.

L'essai de METR

L'étude qui a le plus déplacé le débat vient de METR, un laboratoire indépendant d'évaluation des modèles d'IA. Seize développeurs expérimentés de logiciels libres ont traité 246 tâches réelles sur des projets auxquels ils contribuaient depuis des années ; pour chaque tâche, l'IA était autorisée ou non par tirage au sort, et chacun déclarait son temps en enregistrant son écran. Avec l'IA, ils ont mis 19 % de temps en plus. Le papier complet est public.

METR pose lui-même les limites : un petit échantillon, des développeurs qui connaissent leur code par cœur et travaillent avec des exigences élevées, des modèles du début 2025. Sa suite de février 2026 (57 développeurs, plus de 800 tâches) trouve un temps réduit de 18 % pour les anciens participants et de 4 % pour les nouveaux, avec des marges d'erreur qui vont jusqu'au ralentissement.

METR juge ce nouveau signal peu fiable : 30 à 50 % des développeurs écartaient les tâches qu'ils ne voulaient pas faire sans IA, ce qui sous-estime probablement le gain. Il change donc de protocole.

D'autres études recensées par METR trouvent des gains de 21 à 65 % : elles portent sur des tâches artificielles, ou comptent le volume produit plutôt que le temps passé. Le plus grand essai contrôlé en entreprise, mené chez Microsoft, Accenture et un industriel du Fortune 100 sur 4 867 développeurs, trouve 26 % de pull requests en plus par semaine chez ceux qui se servent de l'outil (Copilot en complétion de code, 2022-2023), avec une forte marge d'erreur (Cui et al.).

Ce que nous en retenons : le ressenti des développeurs, même experts, ne suffit pas à mesurer un gain, et la mesure rigoureuse devient difficile à tenir quand une partie des développeurs ne veut plus travailler sans IA.

Ce que mesurent les éditeurs et les enquêtes

Les chiffres qui circulent mesurent souvent autre chose que ce qu'on leur fait dire :

• GitHub annonce depuis 2022 des développeurs 55 % plus rapides avec Copilot. Le chiffre vient d'une expérience de GitHub avec Microsoft : 95 développeurs, une seule tâche, écrire un petit serveur web.
• Uplevel, éditeur d'un outil de mesure, a suivi près de 800 développeurs sur deux périodes de trois mois en 2023 et 2024 : l'accès à Copilot n'améliore pas de façon utile le temps de cycle des pull requests, et le taux de bugs augmente de 41 % (CIO Online). C'est une observation, sans preuve de cause.
• Capgemini rapporte que 49 % des dirigeants d'organisations qui pilotent ou déploient l'IA générative en ingénierie logicielle citent une meilleure qualité du logiciel (enquête d'avril 2024, 412 dirigeants). C'est une opinion.
• GitClear, éditeur d'outils d'analyse du code, projetait en janvier 2024, sur 153 millions de lignes, que la part du code réécrit ou supprimé moins de deux semaines après son écriture doublerait en 2024 par rapport à 2021.

Ces sources ne mesurent pas la même chose : une opinion, l'historique d'un dépôt de code, le temps passé sur une seule tâche. Elles se contredisent donc moins qu'il n'y paraît.

Les développeurs eux-mêmes deviennent plus prudents. Dans l'enquête 2025 de Stack Overflow (plus de 49 000 réponses), 60 % ont un avis favorable sur les outils d'IA, contre 72 % en 2024 ; 46 % se méfient de l'exactitude de leurs réponses, quand 33 % leur font confiance, et 66 % citent comme première frustration des solutions « presque justes, mais pas tout à fait ».

Notre lecture : l'IA accélère l'écriture du code, et le travail s'accumule plus loin, en relecture, en bugs, en incidents. DORA y voit un amplificateur de l'organisation qu'elle trouve ; Faros constate la même baisse de qualité chez les plus solides en ingénierie. Chez DX, la part du temps consacrée aux nouveautés ne bouge pas.

L'IA amplifie ce qui existe

Le rapport DORA 2025 en propose une explication : l'IA est un amplificateur. Dans ses données, l'adoption de l'IA va de pair avec un débit de livraison plus élevé et à une meilleure performance des équipes et de l'organisation, mais aussi à plus d'instabilité. Le rapport distingue sept profils d'équipes, des équipes performantes et sereines à celles qui se débattent avec un vieux système. Selon DORA, une équipe qui a une plateforme interne de qualité et des circuits de travail clairs convertit mieux ses gains ; les autres accélèrent par endroits.

Le rapport consacre un chapitre au flux de valeur (le chemin d'une demande jusqu'à sa mise en service) : sans cette vue d'ensemble, l'accélération locale est absorbée par les goulots en aval. Steve Pereira, sur le site du Lean Enterprise Institute, en tire la même leçon. Ce sont des associations tirées d'une enquête : DORA ne mesure pas de cause.

Le goulot passe à la relecture

Faros AI, éditeur d'un outil de mesure des équipes de développement, lit la télémétrie de ses clients. Son rapport 2025, sur plus de 10 000 développeurs et 1 255 équipes, trouvait que les équipes qui utilisent beaucoup l'IA terminent 21 % de tâches en plus et fusionnent 98 % de pull requests en plus, mais que le temps de relecture augmente de 91 %, et aucun effet mesurable au niveau de l'entreprise.

Son rapport d'avril 2026, intitulé « The Acceleration Whiplash » (le contrecoup de l'accélération), porte sur 22 000 développeurs et plus de 4 000 équipes. Il compare, pour chaque équipe, ses trimestres de plus faible et de plus forte adoption de l'IA :

• les tâches terminées par développeur augmentent de 34 % et la taille moyenne des pull requests de 51 % ;
• le temps passé en relecture d'une pull request augmente de 441 % à la médiane, et 31 % de pull requests de plus sont fusionnées sans aucune relecture ;
• les bugs par développeur augmentent de 54 %, et les incidents rapportés aux pull requests de 243 %.

Faros se présente comme un contrepoint direct à DORA : dans sa télémétrie, les organisations qui avaient de solides pratiques d'ingénierie avant l'IA subissent la même baisse de qualité que les autres. DORA s'appuie sur une enquête, Faros sur les données de ses clients ; le débat reste ouvert.

Ces chiffres reposent sur des corrélations, même si Faros les commente parfois comme des causes, et ses rapports de 2025 et de 2026 portent sur des échantillons différents. Notre lecture : le code s'écrit plus vite, et le travail se reporte sur la relecture. DORA notait déjà dans son rapport 2024 que 25 % d'adoption de l'IA en plus allaient de pair avec un débit de livraison estimé 1,5 % plus bas et une stabilité 7,2 % plus basse. En 2025, le lien avec le débit devient positif ; celui avec l'instabilité demeure.

Le temps gagné ne devient pas de l'innovation

Le rapport trimestriel de DX, éditeur d'une plateforme de mesure de l'expérience des développeurs (22 juillet 2026, plus de 500 organisations), va dans le même sens :

• la part du code écrite par l'IA passe de 34 % à 52 % entre le premier et le deuxième trimestre 2026 ;
• la taille médiane des pull requests a presque doublé ;
• l'indice d'expérience des développeurs de DX recule de 67 à 65 sur quatre trimestres, et la confiance des développeurs dans leurs modifications baisse de 6,1 % en un trimestre ;
• les utilisateurs de l'IA gagneraient 4 à 6 heures par semaine, selon une estimation dont DX ne publie pas la méthode, et la part du temps consacrée aux fonctionnalités nouvelles ne bouge pas.

Le temps gagné existe peut-être, mais la part du temps consacrée aux nouveautés ne bouge pas. Notre lecture rejoint celle de DORA : sans travail sur le flux de valeur, la vitesse locale ne devient pas une performance de l'équipe.

Non. Elles restent le cadre commun, mais sans la part de code écrite par l'IA elles se lisent mal : la fréquence de déploiement peut monter sans que l'utilisateur reçoive rien de neuf, et un délai stable peut cacher une relecture qui s'allonge. Il faut leur ajouter quelques indicateurs.

Les métriques DORA mesurent la performance de livraison d'une équipe logicielle : la fréquence de déploiement, le délai entre une modification et sa mise en service, la part de mises en service qui échouent, le temps de rétablissement après un échec et, depuis 2024, la part de déploiements non planifiés faits pour corriger un problème en production (le Rework Rate).

Où en sont les équipes

Les réponses à l'enquête DORA 2025 donnent des repères :

• 16 % des répondants déploient à la demande, quand près d'un quart déploient une fois par mois ou moins ;
• 9 % livrent une modification en moins d'une heure, quand 43,5 % mettent plus d'une semaine ;
• 8,5 % ont moins de 2 % de mises en service qui échouent ;
• 21 % se rétablissent en moins d'une heure.

DORA rappelle que la comparaison la plus utile reste celle d'un même service avec lui-même dans le temps. Rachel Stephens, de RedMonk, en propose une relecture critique : pour elle, la stabilité reste la métrique qui compte.

Ce que l'IA brouille

Selon Larridin, éditeur d'une plateforme de mesure de l'IA, ces métriques restent utiles mais se lisent mal sans une information de plus, la part de code écrite par l'IA :

• la fréquence de déploiement peut monter quand l'IA produit du code de routine et des tests, sans que l'utilisateur reçoive rien de neuf ;
• le délai de livraison s'améliore sur l'écriture pendant que la relecture s'allonge : le chiffre global bouge peu et cache un déplacement du travail ;
• le taux d'échec des mises en service ne voit pas le code qui passe les tests puis se fait réécrire trois semaines plus tard ;
• un temps de rétablissement stable avec trois fois plus d'incidents reste un mauvais résultat.

Les indicateurs à ajouter

Larridin propose d'ajouter aux métriques DORA quatre indicateurs, que nous reprenons dans cet ordre :

1. la part de code écrite par l'IA (AI Code Share), sans laquelle rien d'autre ne se lit ;
2. la durabilité du code (Code Turnover Rate) : la part du code qui tient 14 ou 30 jours sans être réécrite, ce que le taux d'échec laisse passer ;
3. le débit pondéré par la difficulté (Complexity-Adjusted Throughput), qui évite de compter le code de routine comme un progrès ;
4. la part du temps consacrée aux nouveautés (Innovation Rate), que DX vient de chiffrer.

Nous y ajoutons deux indicateurs que les données de Faros rendent nécessaires : le temps médian de relecture des pull requests, qui détecte l'engorgement, et le nombre d'incidents suivi à part du temps de rétablissement, que Larridin recommande aussi. Oobeya, un autre éditeur, retient lui aussi la part de code écrite par l'IA.

Un tableau de bord qui tient

Pour une DSI, nous recommandons un tableau de bord en trois blocs : les métriques DORA suivies dans le temps, avec les repères du secteur pour se situer, les indicateurs propres à l'IA, et un bloc valeur (coût unitaire de traitement, taux d'automatisation, satisfaction des équipes, retour cumulé). Cinq à sept indicateurs, revus chaque mois, avec un responsable nommé pour chacun.

En partant d'un modèle simple : au numérateur, le temps libéré, compté une seule fois, et les pannes évitées ou ajoutées ; au dénominateur, le coût complet. Le modèle public le plus détaillé que nous ayons trouvé, celui de DORA et de Google Cloud, aboutit à 39 % de retour la première année, en supposant 12,5 % de temps gagné.

Le modèle de DORA

Le rapport ROI of AI-assisted Software Development, publié en 2026 par l'équipe DORA et delta, la pratique de conseil de Google Cloud, et présenté par InfoQ le 11 mai 2026, propose un calcul d'exemple. Ses auteurs le présentent comme une estimation très incertaine, faite pour lancer la discussion.

Pour une organisation de 500 personnes du cycle logiciel, à 176 000 dollars de coût complet par personne et par an :

• l'investissement de la première année atteint 8,4 millions de dollars, dont 4,8 millions de formation (9 600 dollars par personne, quand la licence en coûte 250) et 3,3 millions pour le creux de productivité du démarrage (15 % de moins pendant trois mois) ;
• la valeur atteint 11,6 millions, dont 11 millions de temps réinvesti, calculé sur une hypothèse de 12,5 % de temps net gagné, soit une heure par jour ;
• le retour est de 39 % la première année, et l'investissement est remboursé en 0,7 an, environ huit mois.

Deux enseignements de méthode valent plus que ces montants, qu'il ne faut pas transposer. Le premier est la courbe en J : la productivité baisse avant de monter, le temps que les équipes apprennent l'outil, apprennent à vérifier le code généré et adaptent leurs processus. Une DSI qui mesure à trois mois et coupe le budget mesure le creux. Le second : dans ce modèle, presque toute la valeur repose sur le temps gagné supposé, précisément ce que METR montre difficile à mesurer.

Numérateur et dénominateur

Pour le calcul, nous gardons une structure simple :

• au numérateur, le temps libéré, compté une seule fois : soit en coût évité (heures gagnées multipliées par le coût horaire chargé), soit en valeur de ce que ces heures produisent ailleurs ; plus les erreurs et les pannes évitées, ou moins celles que l'IA ajoute (le modèle de DORA retire 344 000 dollars de pannes en plus) ;
• au dénominateur, le coût complet : licences, consommation, formation, administration et surcharge de relecture. Notre carnet sur le coût de l'IA sert ici de garde-fou.

Pour situer le dénominateur : dans un sondage de DX auprès de 50 responsables budget (octobre 2025), 1 000 dollars par développeur et par an revenait comme cible pour 2026 dans beaucoup d'entreprises ; dans un autre sondage cité par DX, auprès de 275 responsables techniques, un sur dix dépensait déjà davantage en 2025. Le modèle de DORA rappelle que la formation peut peser bien plus lourd que les licences.

Un retour qui se fait attendre

En France, Deloitte trouve que 18 % des entreprises constatent déjà un retour sur investissement de l'IA générative (enquête de 2025 auprès de 1 854 dirigeants d'Europe et du Moyen-Orient, dont 249 en France). La plupart des répondants comptent deux à quatre ans pour qu'un cas d'usage rapporte, quand on attend d'habitude sept à douze mois d'une technologie.

En posant la mesure avant de déployer : un point de départ daté, quelques indicateurs suivis, quelqu'un qui décide quand ils dérapent. C'est notre recommandation, car aucune étude solide ne compare les organisations qui y parviennent aux autres. La pression, elle, monte, selon des DSI sondés pour un vendeur de plateforme d'IA.

La pression vient des directions financières et des conseils d'administration. Dans un sondage de Dataiku avec Harris Poll auprès de 600 DSI dans le monde, 98 % disent que la pression de leur conseil d'administration pour démontrer un retour mesurable de l'IA a augmenté depuis 2024, et moins de quatre sur dix savent relier la moitié ou plus de leurs projets d'IA à des économies ou à des revenus mesurables. Dataiku vend une plateforme d'IA.

La formation fait partie du calcul

Dans un sondage de YouGov pour DataCamp, un vendeur de formation, auprès de plus de 500 dirigeants américains et britanniques, 21 % font état d'un retour significatif de l'IA, et 42 % quand leur organisation a un programme mature de montée en compétences. C'est une corrélation déclarée, qui ne prouve aucune cause. L'étude mondiale de Deloitte (3 235 dirigeants) voit aussi le manque de compétences comme le premier frein à l'intégration de l'IA.

Croisés avec la thèse de DORA (l'IA amplifie l'existant) et avec la courbe en J (le creux d'apprentissage se paie de toute façon), ces signaux vont dans le même sens. Nous en tirons que la formation se budgète avec l'outil, dès le départ.

Quatre pièges à éviter

Ils se repèrent avant le déploiement :

1. Ne pas mesurer avant de déployer : sans quelques semaines de mesure de départ sur les indicateurs visés, aucun progrès ne se démontre, il ne reste que des opinions.
2. Lancer l'IA en même temps qu'une autre transformation : on ne sait plus à quoi attribuer ce qui change.
3. Mesurer trop tard, quand la trajectoire ne se corrige plus ; avec la courbe en J, une mesure à trois mois tombe dans le creux.
4. Mesurer sans décider : un tableau de bord que personne n'est chargé d'actionner coûte sans servir.

Notre pari : pour l'exercice budgétaire 2027, les DSI les mieux placées auront une mesure de départ datée, cinq à sept indicateurs suivis, un coût complet au dénominateur, et l'honnêteté de dire ce qu'elles ne savent pas encore mesurer.

Ce que l'IA rapporte vraiment à une organisation entière, mesuré de façon indépendante ; ce que donne la mesure rigoureuse avec les outils de 2026 ; où passe le temps gagné ; et presque tout ce qui concerne la France.

• Aucun essai contrôlé ne porte sur une DSI entière. METR mesure des tâches ; les essais de Cui et al. tirent au sort des développeurs ou des équipes pendant deux à huit mois et comptent leurs pull requests ; Faros et DX lisent la télémétrie de leurs clients. Personne n'a suivi pendant un an ce que livre une DSI entière.
• La mesure rigoureuse devient plus difficile. METR dit ne pas pouvoir se fier à sa suite de 2026, parce qu'une partie des développeurs refuse désormais de travailler sans IA.
• Le retour sur investissement reste modélisé. Le calcul public le plus détaillé que nous ayons trouvé, celui de DORA, repose sur une hypothèse de temps gagné ; les retours chiffrés publiés en entreprise viennent d'études commandées par les éditeurs, et nous n'avons pas trouvé de mesure indépendante.
• On ne sait pas où passe le temps gagné. DX constate que la part du temps consacrée aux nouveautés ne bouge pas ; aucune source ne dit à quoi servent les heures libérées.
• La France est peu mesurée. Les chiffres français les plus repris sur la mesure de l'IA ne tiennent pas (voir les précautions), et les études de télémétrie ne disent pas d'où viennent leurs clients.

Distinguer l'enquête, la télémétrie d'éditeur et l'essai contrôlé, dater chaque chiffre, et ne pas lire deux rapports d'un même éditeur comme une tendance d'une année sur l'autre.

• Une bonne partie des chiffres de ce carnet viennent d'éditeurs qui vendent la mesure qu'ils publient : Faros, DX, Larridin, Oobeya, Uplevel, GitClear, et GitHub pour Copilot. Ils mesurent leurs clients, qui ne représentent pas tout le marché. Le rapport de DORA sur le retour est cosigné par delta, le conseil de Google Cloud, et les essais de Cui et al. ont été menés par Microsoft, Accenture et un industriel dans le cadre de leur activité.
• DORA, Stack Overflow, Capgemini, DataCamp, Dataiku et Deloitte rapportent ce que les gens déclarent. Le sondage de DataCamp est commandé par un vendeur de formation, celui de Dataiku par un vendeur de plateforme d'IA.
• Dans l'essai de METR, le temps est déclaré par les développeurs, qui enregistrent leur écran ; il n'est pas chronométré par un tiers.
• Les chiffres de Faros comparent, pour chaque équipe, ses trimestres de plus faible et de plus forte adoption : ce n'est pas une évolution sur un an. Sa suite de septembre 2026, « The Speed Trap », regarde ce qui se passe quand une adoption déjà forte s'approfondit : les incidents par pull request n'y augmentent que de 14,5 %, mais les incidents mensuels de 125 % et les pull requests fusionnées sans relecture de 76 %.
• Le retour de 39 % de DORA est un exemple de calcul construit sur des hypothèses : ses montants ne se transposent pas. Le rapport cite lui-même, hors de son modèle, un retour de 727 % sur trois ans chez des clients de Google Cloud, tiré d'une étude d'IDC financée par Google Cloud.
• Nous avons retiré de ce carnet les chiffres français les plus repris sur la mesure de l'IA (34 % d'entreprises sans point de départ, 69 % sans plan de mesure, attribués à une étude sur 500 entreprises) : ils viennent du billet d'un organisme de formation qui cite une étude que nous n'avons pas retrouvée. Nous avons retiré aussi un retour « sain » de 2,5 à 3,5 fois, tiré du référentiel interne d'un éditeur, sans méthode publiée.
• Les chiffres décrivent la situation de l'été 2026 et n'ont pas été actualisés.