Mesurer l'impact de l'IA sur les équipes IT

Le sujet n'est pas de savoir si l'IA aide les équipes IT. Sur ce point, la question est réglée : le DORA Report 2025, construit sur environ 5 000 professionnels, mesure 90 % d'adoption chez les développeurs contre 76 % un an plus tôt, une médiane d'usage de deux heures par jour, et plus de 80 % de déclarations de gains de productivité. Le sujet est de savoir ce que ces gains deviennent une fois remontés au niveau d'une DSI, et comment on le prouve à un comité d'investissement qui a déjà signé le chèque et qui attend la démonstration.

Le point de départ honnête, c'est de reconnaître que la mesure la plus répandue est la moins fiable. La quasi-totalité des chiffres de gains qui circulent en 2026 sont déclaratifs : on demande à un développeur s'il se sent plus productif, il répond oui. La télémétrie, elle, raconte une histoire plus nuancée, et l'expérimentation contrôlée une histoire carrément différente. Ce dossier trie ces trois familles de preuves, parce que la crédibilité d'un business case se joue exactement là. Google Cloud a posé la thèse dès l'annonce du rapport : ce qui fait le rendement, c'est le système organisationnel, pas l'outil.

Ce dossier est le jumeau de notre dossier sur le coût réel de l'usage de l'IA. Celui-là traite du dénominateur, celui-ci du numérateur, et les deux se lisent ensemble. Un ROI sans TCO complet au dénominateur est un chiffre de commercial ; un TCO sans mesure de valeur au numérateur est un argument de renoncement. Rappel de cadrage pour ne pas se croire en retard sur le marché : selon l'INSEE, 10 % seulement des entreprises françaises de 10 salariés ou plus déclaraient utiliser au moins une technologie d'IA en 2024.

L'étude qui a le plus déplacé le débat vient de METR, et sa force tient à son protocole : un essai randomisé, pas un sondage. Seize développeurs expérimentés, cinq ans d'ancienneté moyenne sur des dépôts open source matures, 246 tâches réelles (bugs, refactorings, évolutions), l'autorisation d'utiliser l'IA tirée au sort tâche par tâche. Résultat mesuré au chronomètre : 19 % de temps en plus quand l'IA est autorisée. Le papier complet est public sur arXiv.

Ce qui rend l'étude décisive n'est pas le signe du résultat, c'est l'écart avec la perception. Avant l'essai, les participants anticipaient 24 % d'accélération. Après, alors qu'ils venaient d'être 19 % plus lents, ils estimaient avoir été 20 % plus rapides. Environ 39 points d'écart entre le ressenti et la mesure, sur la même population et les mêmes tâches. Deux précautions de lecture s'imposent, et METR les pose lui-même : l'échantillon est petit, il porte sur des experts travaillant sur du code qu'ils connaissent par cœur avec des standards élevés (le contexte le moins favorable à un assistant), et les modèles testés datent du début 2025. L'équipe a d'ailleurs revu son protocole en février 2026. Notre lecture : ce chiffre ne condamne pas l'IA, il démontre que le déclaratif ne vaut rien comme instrument de mesure.

La contradiction se rejoue à l'échelle des éditeurs, et elle mérite d'être regardée en face. GitHub avance historiquement + 55 % de vitesse de codage avec Copilot sur son étude interne ; l'étude Uplevel, menée sur 800 développeurs pendant trois mois, ne décèle aucune amélioration significative du cycle time des PR et mesure + 41 % de bugs. Capgemini rapporte que 49 % des organisations constatent une amélioration de la qualité logicielle sur un panel de 1 000 dirigeants, mais ce constat est déclaratif là où GitClear mesure un doublement du taux de réécriture du code, de 3,3 % à une fourchette de 5,7 à 7,1 %. Ces sources ne se contredisent pas vraiment : elles ne mesurent pas la même chose, l'une demande une opinion quand l'autre lit un dépôt Git.

Signal complémentaire à ne pas balayer : la mesure déclarative elle-même commence à corriger le tir. Le Stack Overflow Developer Survey 2025, sur plus de 70 000 répondants, enregistre un recul des avis favorables aux outils IA de 72 % à 60 %, seulement 33 % de confiance dans la précision des sorties contre 46 % de méfiance active, et 66 % de développeurs citant comme problème numéro un des solutions « presque bonnes mais pas tout à fait ». Quand le déclaratif et la télémétrie convergent enfin, c'est rarement bon signe.

Le DORA Report 2025 apporte la meilleure explication disponible, et elle tient en une formule : l'IA est un amplificateur. Le rapport identifie sept profils d'équipes par analyse de clusters, des équipes performantes et sereines à celles en mode survie ou coincées dans un goulet d'étranglement legacy. Sur chacun de ces profils, l'IA amplifie ce qui est déjà là. Une équipe avec une plateforme interne saine, des workflows clairs et un flux de valeur géré convertit ses gains locaux en performance produit ; une équipe sans ces fondations produit des îlots de productivité que le chaos aval annule. Le blog Google en donne la lecture accessible, et le Lean Enterprise Institute fait le même constat depuis l'angle lean : sans cartographie du flux de valeur, l'accélération locale ne va nulle part.

La mécanique de cette annulation porte un nom chez les praticiens : l'acceleration whiplash. La télémétrie 2026 de Faros AI en donne les chiffres : + 441 % sur le temps médian passé en revue de code, + 51,3 % sur la taille des pull requests, + 31 % de PR mergées sans revue, + 54 % de bugs par développeur et + 242,7 % d'incidents par PR. Le goulot ne disparaît pas, il se déplace de l'écriture vers la relecture, et il se déplace vers un humain qui, lui, n'a pas été augmenté. Ce n'est pas un phénomène neuf : le DORA Report 2024 mesurait déjà qu'une hausse de 25 % de l'adoption IA s'accompagnait de 1,5 % de throughput en moins et de 7,2 % de stabilité de livraison en moins. Ce que 2026 ajoute, c'est l'échelle et la constance du signal.

La confirmation la plus récente vient du rapport State of AI Impact in Engineering de DX, publié le 22 juillet 2026 sur plus de 500 organisations. Plus de 50 % du code y est désormais généré par IA, contre 34 % au trimestre précédent, et les utilisateurs économisent 4 à 6 heures par semaine. Et pourtant : la taille médiane des pull requests a quasiment doublé, l'indice d'expérience développeur DXI recule de 67 à 65 sur quatre trimestres, la confiance dans les changements perd 6,1 % (la maintenabilité du code, elle, gagne 3,8 %), et surtout le ratio d'innovation reste plat. Le temps gagné existe, il est mesuré, mais il ne se convertit pas en fonctionnalités nouvelles pour les utilisateurs. C'est exactement le diagnostic DORA, vérifié par la donnée : sans gestion du flux de valeur, la productivité locale ne devient pas performance produit.

Les quatre métriques DORA historiques, plus le Rework Rate ajouté en 2024, restent le meilleur cadre de comparaison disponible. Les benchmarks 2025 donnent les positions : 16 % des équipes déploient à la demande quand 24 % déploient moins d'une fois par mois, 9 % ont un lead time inférieur à une heure quand 43 % dépassent la semaine, 8,5 % tiennent un taux d'échec des changements sous 2 %, et 21 % récupèrent d'un déploiement raté en moins d'une heure. C'est la baseline sectorielle contre laquelle se lit tout le reste, et RedMonk en propose une relecture critique qui vaut le détour.

Le problème n'est pas que ces métriques deviennent fausses, c'est qu'elles deviennent ininterprétables sans une information supplémentaire : la part de code générée par IA. Deployment Frequency monte quand l'IA produit du boilerplate et des tests, sans qu'un utilisateur ait reçu quoi que ce soit de nouveau. Lead Time for Changes s'améliore sur la phase de génération pendant que la part de revue dans le lead time total explose : le chiffre agrégé bouge peu, il masque une redistribution complète. Change Failure Rate ne capte pas le code qui passe les tests puis se fait réécrire trois semaines plus tard. MTTR reste solide et utile, mais un MTTR stable avec une fréquence d'incidents multipliée par trois est un mauvais résultat déguisé en bon.

Les analyses convergentes de Larridin sur la rupture des métriques DORA, de son cadre AI-native, du Journal du Net sur l'obsolescence des KPI IT et d'Oobeya proposent le même jeu d'extensions, et on le retient dans cet ordre de priorité. D'abord l'AI Code Share, la part de code commité générée par IA, sans laquelle rien d'autre n'est lisible. Ensuite le Code Turnover Rate à 14 ou 30 jours, qui capte la qualité réelle que le Change Failure Rate laisse passer. Puis le PR Review Time médian, qui détecte l'engorgement humain, et l'Incident Frequency mesurée séparément du MTTR. Enfin le Complexity-Adjusted Throughput, qui évite l'inflation par le boilerplate, et l'Innovation Rate, le point aveugle que DX vient de chiffrer.

La conclusion pratique tient en une contrainte de format. Un cockpit tenable pour une DSI, c'est trois blocs et pas davantage : DORA Core en comparaison aux benchmarks, extensions IA, et bloc valeur (coût unitaire de traitement, taux d'automatisation, satisfaction des équipes IT, ROI cumulé). Cinq à sept indicateurs pilotés en boucle mensuelle, avec un responsable nommé par indicateur. Au-delà, on ne pilote plus, on documente.

C'est la nouveauté qui manquait au printemps. Le rapport ROI of AI-Assisted Software Development, produit par l'équipe DORA de Google Cloud avec sa practice delta et couvert par InfoQ le 11 mai 2026, pose un modèle chiffré public. Sur une organisation type de 500 développeurs à 176 000 $ de salaire annuel moyen, il modélise 8,4 M$ d'investissement en première année (licences, mais aussi apprentissage, adaptation des processus, accompagnement) contre 11,6 M$ de valeur générée : 39 % de ROI la première année, un point mort atteint autour du huitième mois, et un retour de 727 % sur trois ans dans le scénario Google Cloud.

Deux enseignements de méthode valent plus que ces chiffres, qu'il ne faut surtout pas transposer tels quels. 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, pas le résultat. Le second est la thèse centrale, cohérente avec le DORA 2025 : le rendement vient du système organisationnel, la qualité de la plateforme interne et la clarté des workflows, pas de l'outil lui-même.

Pour le calcul, on garde une structure simple. Au numérateur, trois familles : le temps libéré converti en coût évité (heures économisées multipliées par le coût horaire chargé), les erreurs évitées converties en coût de non-qualité évité, et la valeur d'opportunité des heures réaffectées à des tâches à plus fort rendement. Au dénominateur, le TCO complet et pas seulement les licences, et c'est là que le dossier jumeau sur le coût sert de garde-fou. Le Stanford AI Spend Index situe la médiane à 86 $ par développeur et par mois sur les seuls outils de code, avec un quartile supérieur au-delà de 195 $, et l'enquête DX auprès de 275 responsables budget pose 1 000 $ par développeur et par an comme cible réaliste pour 2026. Ajoutez la formation, l'administration et la surcharge de revue, et le dénominateur double sans effort.

Ordre de grandeur pour se situer, à manier avec prudence : les analyses de terrain situent un ROI sain entre 2,5 et 3,5 fois en moyenne, et entre 4 et 6 fois pour le quartile supérieur, à condition que le dénominateur inclue les coûts réels d'usage et pas seulement les sièges. En France, la difficulté est d'abord de savoir : Deloitte mesure que 18 % des entreprises françaises constatent déjà un ROI, avec un délai moyen de 2 à 4 ans par cas d'usage, très au-delà des 7 à 12 mois habituels des technologies classiques. Et l'étude Deloitte State of AI confirme que la contrainte numéro un reste le manque de compétences, pas la technologie.

Le facteur discriminant n'est ni l'outil ni le budget, c'est la discipline de mesure, et les chiffres sont sans appel. L'étude de DécisionIA avec France IA et la FIF, sur 500 entreprises françaises, mesure que 17 % seulement définissent des objectifs quantifiés avec des délais avant le lancement, que 34 % n'établissent aucune baseline, et que 69 % démarrent sans plan de mesure. À l'autre bout, celles qui combinent KPIs définis et gouvernance affichent 56 % de taux de succès sur leurs projets IA, quand Palmer Consulting attribue 40 % des échecs à l'absence pure et simple d'indicateurs.

Quatre pièges reviennent systématiquement en mission, et ils sont tous évitables à coût nul. Ne pas poser de baseline sur deux à quatre semaines avant le déploiement, ce qui rend toute mesure de progrès impossible. Lancer l'IA en même temps qu'une autre transformation, ce qui rend l'attribution ininterprétable. Mesurer trop tard, deux ou trois mois après le lancement, quand la trajectoire n'est plus corrigeable et, avec la courbe en J, au pire moment possible. Mesurer sans mécanisme de décision associé, c'est-à-dire produire un tableau de bord que personne n'est mandaté pour actionner. Le guide KPI de DécisionIA les documente en détail, et le hub de mesure de DX donne l'équivalent côté ingénierie.

Le levier le plus rentable est aussi le plus négligé : la formation. DataCamp et YouGov, sur 500 dirigeants américains et britanniques, mesurent que 21 % des organisations obtiennent un ROI significatif, et que ce taux passe à 42 % quand un programme structuré de montée en compétences existe. Un facteur deux, sur le seul critère de l'enablement. Croisé avec la thèse DORA (l'IA amplifie l'existant) et avec la courbe en J (le creux d'apprentissage se paie de toute façon), le message est cohérent : l'investissement formation n'est pas un poste annexe du budget IA, c'est le principal déterminant de son rendement.

Reste la question qui décide de tout, celle de savoir qui porte le chiffre. La pression monte côté finance : CIO.com documente le durcissement des exigences sur les budgets d'agents en 2026, et Dataiku résume l'attente des directions financières : l'efficacité opérationnelle n'est pas un résultat métier tant qu'elle n'est pas reliée au compte de résultat. Notre lecture, sans s'emballer : les DSI qui passeront l'exercice budgétaire 2027 seront celles qui auront une baseline datée, un cockpit de cinq à sept indicateurs, un TCO honnête au dénominateur, et l'honnêteté de dire ce qu'elles ne savent pas encore mesurer.