← Tous les articles
Méthode avant Outil

Mesurer l'impact réel de l'IA sur le produit (au-delà des métriques vanity)

Article 09/10·~9 min·Grégoire Sentis

Le trompe-l'œil du tableau de bord vert

Votre équipe a adopté GitHub Copilot. Le nombre de PRs par semaine a grimpé. Les développeurs déclarent se sentir plus productifs. Le management sourit. Tout va bien.

Sauf que le tableau ne dit pas tout.

Voilà le point de vigilance du moment : de nombreuses équipes produit adoptent des outils d'IA de code, mesurent leur impact avec les métriques qu'elles avaient déjà, vélocité des PRs, lignes de code produites, temps de complétion de tâches, et concluent que l'IA "fonctionne". Ce faisant, elles passent à côté de la vraie question : est-ce que la valeur produit livrée s'améliore, ou est-ce qu'on génère juste plus d'output ?

Ce n'est pas une question rhétorique. Les données sont là, elles se contredisent, et c'est précisément pour ça qu'elles valent le coup d'être lues honnêtement.

Ce que disent les études, et leurs limites

L'étude GitHub : 55 % plus rapide (dans un lab)

L'étude fondatrice de GitHub (2022, publiée sur le GitHub Blog) [1] a recruté 95 développeurs professionnels et les a chronométrés sur une tâche de création d'un serveur HTTP en JavaScript. Le groupe utilisant Copilot a complété la tâche 55,8 % plus vite en moyenne (1h11 vs 2h41), avec une différence statistiquement significative (p=0,0017).

C'est le chiffre le plus cité dans les decks commerciaux de GitHub. C'est aussi l'étude la plus contestée méthodologiquement.

Problème central : la tâche était isolée, bien bornée, sans contexte de codebase existant, sans revue de code, sans documentation à maintenir. Ce n'est pas la réalité du développement en startup ou scaleup. BlueOptima, qui a analysé les données de plus de 218 000 développeurs en entreprise avec une méthodologie de détection automatique du code AI-généré, ne retrouve qu'un gain de productivité de 4 à 5,4 % en moyenne, montant à 20 % pour les utilisateurs les plus actifs [2]. Loin des 55 %.

L'étude Microsoft/Accenture (publiée sur mit-genai.pubpub.org, portant sur 1 974 développeurs dans un RCT en conditions réelles) donne un chiffre intermédiaire : 7,5 à 21,8 % de PRs supplémentaires par semaine selon les organisations [3]. Plus réaliste. Mais une PR supplémentaire n'est pas un feature livré, c'est un output, pas un outcome.

L'étude METR : les développeurs expérimentés vont 19 % plus lentement

En juillet 2025, METR (Model Evaluation and Threat Research), une organisation à but non lucratif financée par des dons, a publié les résultats d'un RCT sur 16 développeurs open-source expérimentés contribuant à leurs propres repositories (22 000+ étoiles GitHub en moyenne, 1M+ lignes de code) [4].

Le protocole : 246 tâches réelles (bugs, refactors, features), réparties aléatoirement entre deux conditions, avec ou sans outils IA (principalement Cursor Pro avec Claude 3.5/3.7 Sonnet). Résultat : lorsqu'ils utilisent l'IA, les développeurs prennent 19 % de temps supplémentaire pour compléter leurs tâches.

Ce qui rend ce résultat particulièrement frappant, c'est le gap de perception : avant chaque tâche, les développeurs anticipaient un gain de vitesse de 24 %. Après l'avoir accomplie, ils estimaient avoir été accélérés de 20 %. La réalité mesurée était l'inverse exact.

METR précise les limites de son étude avec une rigueur exemplaire : ces résultats ne s'appliquent pas nécessairement à des développeurs moins expérimentés, à des codebases moins matures, ou à des outils plus récents. Une mise à jour de février 2026 signale que les outils de fin 2025 montrent des résultats différents pour ce même groupe [4]. L'écosystème évolue vite.

Mon point de vue : L'étude METR est le signal le plus honnête disponible à ce jour. Non pas parce qu'elle prouve que l'IA est inutile, elle ne le dit pas, mais parce qu'elle révèle l'écart systématique entre la perception subjective et la réalité mesurée. C'est exactement le terrain des métriques vanity : les gens croient aller plus vite parce qu'ils tapent moins, mais la charge cognitive de revue, de vérification et de correction du code AI-généré annule le gain et plus. Si ton équipe te dit "on est plus productifs avec l'IA" sans télémétrie objective, prends le chiffre avec prudence.

DORA 2024-2025 : l'IA comme amplificateur, pas comme solution

Le rapport DORA 2024 (Google Cloud, basé sur des milliers de réponses) a produit un résultat contre-intuitif : pour chaque augmentation de 25 points de pourcentage d'adoption de l'IA, le débit de livraison de logiciels baissait de 1,5 % et la stabilité de livraison baissait de 7,2 % [5]. Les développeurs déclaraient être plus productifs. Les métriques de livraison allaient dans l'autre sens.

Le rapport DORA 2025 (State of AI-Assisted Software Development, publié en septembre 2025, basé sur 5 000 répondants et 100+ heures d'entretiens) [6] apporte une nuance importante : la corrélation entre adoption de l'IA et débit de livraison est devenue positive, signe que les équipes apprennent à mieux intégrer les outils. Mais l'adoption de l'IA continue d'avoir une relation négative avec la stabilité de livraison.

La conclusion centrale du rapport 2025 est structurelle : "L'IA n'améliore pas une équipe. Elle amplifie ce qui est déjà là." Les équipes avec des pratiques de test automatisé solides, une architecture découplée et des boucles de feedback rapides tirent profit de l'IA. Les autres trouvent que l'IA intensifie leurs problèmes existants.

Le problème des métriques vanity dans le contexte IA

PRs, lignes de code : output sans outcome

Uplevel Data Labs a analysé les données de ~800 développeurs (351 utilisateurs Copilot, 434 groupe contrôle) sur une période avant/après adoption [7]. Résultat : pas d'amélioration statistiquement significative du temps de cycle de PR (1,7 minutes d'écart), mais une augmentation de 41 % du taux de bugs pour le groupe Copilot.

GitClear a analysé 211 millions de lignes de code modifiées entre 2020 et 2024, provenant de repositories de Google, Microsoft, Meta et d'entreprises privées [8]. Les données montrent que :

  • La proportion de code refactorisé est passée de 25 % des lignes modifiées en 2021 à moins de 10 % en 2024
  • La proportion de code dupliqué (clones) est passée de 8,3 % à 12,3 % sur la même période
  • La "code churn" (code écrit puis supprimé rapidement, signal d'instabilité) a fortement progressé

Ces chiffres dessinent un pattern cohérent : l'IA génère plus de code, plus vite, mais ce code est moins réutilisable, moins bien structuré, et plus souvent jeté. La vélocité mesurée par le volume de code ou le nombre de PRs est donc une métrique vanity dans le contexte IA : elle monte, pendant que la qualité baisse.

Mon point de vue : Dans une startup ou scaleup, la dette technique finit par éroder la vélocité à 12-18 mois d'horizon. Si votre mesure de l'impact IA se limite à "combien de PRs en plus ?", vous pilotez à court terme avec le rétroviseur. La vraie question n'est pas "est-ce qu'on ship plus ?" mais "est-ce que le produit qu'on ship tient dans 6 mois ?"

L'écart perception/réalité comme risque systémique

L'un des enseignements transversaux de ces études est le gap de perception. Les développeurs se sentent plus productifs avec l'IA dans pratiquement toutes les études, y compris dans l'étude METR où ils étaient objectivement plus lents. Le rapport DORA 2025 note que plus de 80 % des répondants estiment que l'IA a amélioré leur productivité.

Ce gap n'est pas anodin pour un PM. Si les signaux qualitatifs de l'équipe sont systématiquement biaisés vers le positif, et que vous n'avez pas de contre-mesures objectives, vous pilotez sur des intuitions. Et des intuitions qui, dans ce cas précis, semblent statistiquement inversées.

Vers une mesure honnête : ce qui compte vraiment

Les métriques DORA restent pertinentes, mais insuffisantes seules

Les quatre métriques DORA (fréquence de déploiement, lead time, taux d'échec des changements, temps de récupération) restent une base solide parce qu'elles mesurent des outcomes systémiques, pas des outputs individuels. Dans le contexte IA, elles révèlent quelque chose que les métriques d'équipe ne voient pas : si l'accélération des développeurs individuels se traduit par une meilleure livraison système, ou si elle crée de l'instabilité en aval.

Mais elles ont leurs angles morts. En particulier, elles ne distinguent pas la dette technique accumulée, et ne capturent pas l'érosion de la qualité avant qu'elle devienne visible en production.

Ce qu'il faut ajouter au tableau de bord

Les travaux de GitClear, Uplevel et DORA convergent vers une même conclusion : il faut mesurer le rapport output/qualité, pas l'output seul. Concrètement, cela signifie :

  • Taux de bugs par PR (pas seulement le nombre de PRs), signal direct de qualité
  • Code churn (proportion de code écrit puis supprimé dans les 2 semaines), signal d'instabilité et de travail gâché
  • Taux de duplication de code, signal de maintenabilité long terme
  • Proportion de refactoring dans les commits, signal de santé architecturale
  • Taux de réversion des PRs, signal d'urgence qualité

Pour l'outcome produit, la question reste celle du lien entre livraison technique et valeur utilisateur : est-ce que les features livrées plus vite aboutissent à une meilleure adoption, une meilleure rétention, moins de support ? C'est le territoire que les métriques techniques seules ne couvrent pas.

Mon point de vue : Ce que j'appelle "Architecture Humain-IA" dans le PM Pathfinder Framework n'est pas une question de stack technologique. C'est une question de qui mesure quoi, avec quelle fréquence, et qui a le droit de dire que quelque chose ne fonctionne pas. L'IA dans les équipes produit crée une pression implicite à l'optimisme, tout le monde veut croire que l'investissement paie. La mesure honnête est un acte de courage organisationnel avant d'être un problème technique.

Ce que les résultats contradictoires nous disent vraiment

La tension entre l'étude GitHub (55 % plus rapide) et l'étude METR (19 % plus lent) n'est pas un problème à résoudre par arbitrage, c'est une information à interpréter dans son contexte. METR elle-même propose trois hypothèses pour réconcilier ces résultats [4] : soit son RCT sous-estime les capacités réelles (biais de sélection des tâches), soit les benchmarks et études internes surestiment l'impact (biais de conception), soit les deux méthodologies mesurent des sous-ensembles différents de la distribution réelle des tâches.

La lecture la plus honnête en mi-2026 est probablement la troisième : l'IA accélère certains types de tâches dans certains contextes (tâches bien bornées, développeurs moins expérimentés, codebases jeunes, problèmes avec beaucoup de code boilerplate) et ralentit dans d'autres (tâches complexes dans des codebases matures, avec des standards de qualité élevés, impliquant beaucoup de contexte implicite).

Pour un PM, cela signifie que la question pertinente n'est pas "l'IA est-elle productive ?" mais "pour quelles tâches, dans quel contexte, avec quels garde-fous, l'IA apporte-t-elle de la valeur mesurable ?"

C'est exactement le travail de méthode avant outil.

Sources

[1] Research: quantifying GitHub Copilot's impact on developer productivity and happiness, GitHub Blog (2022, mis à jour 2024), Étude fondatrice avec 95 développeurs, 55,8 % de gain de vitesse sur tâche isolée.

[2] Debunking GitHub's Claims: A Data-Driven Critique of Their Copilot Study, BlueOptima, Analyse de 218 000+ développeurs, gain réel de 4 à 5,4 %.

[3] The Productivity Effects of Generative AI: Evidence from a Field Experiment with GitHub Copilot, MIT GenAI, RCT sur 1 974 développeurs (Microsoft + Accenture), +7,5 à 21,8 % de PRs/semaine.

[4] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR (juillet 2025), RCT sur 16 développeurs, 246 tâches réelles : ralentissement de 19 %, gap de perception de 39 points.

[5] Announcing the 2024 DORA Report, Google Cloud, Corrélation négative entre adoption IA et débit/stabilité de livraison.

[6] Announcing the 2025 DORA Report: State of AI-Assisted Software Development, Google Cloud (septembre 2025), 5 000 répondants, 100+ heures d'entretiens ; l'IA comme amplificateur systémique, stabilité toujours négativement corrélée.

[7] Gen AI for Coding Research Report, Uplevel Data Labs, Analyse de ~800 développeurs, +41 % de bugs pour les utilisateurs Copilot, gain de cycle negligeable.

[8] AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones, GitClear (2025), 211 millions de lignes analysées (2020-2024) : duplication +48 %, refactoring -60 %.