Le chiffre le plus célèbre vient de GitHub : les devs avec Copilot terminent une tâche 55% plus vite. C'est un vrai essai randomisé, 95 développeurs, publié en 2022. Il est vrai, il est propre, et il ne prouve rien pour ton équipe.

Pourquoi : une seule tâche algorithmique (un serveur HTTP), des devs juniors sur du JS, un outil d'autocomplete, et un vendeur qui vend le produit qu'il mesure. Le +55% mesure la vitesse d'écriture d'une tâche isolée. Pas la productivité d'une équipe qui maintient un produit.

La contre-étude est plus instructive. METR, un labo indépendant, a randomisé 246 issues réelles sur les repos open source de 16 développeurs expérimentés (22k étoiles de moyenne, un million de lignes, 5 ans de contribution). Résultat juillet 2025 : les tâches avec IA ont pris 19% de temps en plus. Pendant que les devs eux-mêmes prévoyaient 24% de temps en moins.

L'écart entre perception et réalité : 40 points. C'est ça, le problème de mesure. Personne dans ton équipe ne le résoudra en consultant son ressenti.

La net productivity tient en une ligne : gain de vitesse, moins les coûts que la vitesse fait apparaître.

Trois études la mesurent, et elles convergent :

DORA 2025 (5 000 professionnels enquêtés) : l'adoption de l'IA améliore le throughput de livraison. Mais elle continue de dégrader la delivery stability. Livrer plus vite, casser plus souvent. Et 30% des devs disent avoir peu ou pas confiance dans le code généré.

GitClear (623 millions de changements de code analysés, 2023-2026) : la duplication a bondi de 81%, le refactoring s'est effondré de 21% à 3,8% des changements (cinq fois plus de copier-coller que de refactorisation), et la maintenance du code existant a chuté de 74%. Leur formule est la meilleure définition du problème : le workflow IA par défaut taxe "l'invisible et le différé", ce qui détermine combien coûte une codebase en année trois.

Faros AI (télémétrie de 22 000 devs sur 2 ans) : +66% d'épics complétés, mais +242% d'incidents par PR, temps de revue multiplié par 5, code churn multiplié par 10. Précaution honnête : c'est un vendeur d'outils d'observabilité, les données sont corrélationnelles. Mais c'est de la télémétrie, pas du ressenti.

Le tableau est cohérent : la vitesse monte, la qualité absorbe. La productivité nette peut être négative pendant que tout le monde se sent plus productif.

Ton CTO ne te demande pas une étude académique. Il demande "ça vaut quoi ?". Trois métriques suffisent, toutes mesurables avec tes outils existants.

1. Le gain de délai, sur tes tickets à toi.

Pas le +55% de GitHub. Le tien : story points livrés par sprint avant/après, sur le même type de tickets. Attention au piège : un sprint qui livre 30% de points en plus peut cacher 15% de rework en plus. Mesure les points re-ouverts, pas seulement les points livrés.

2. Le coût qualité du code IA, sur tes PRs.

Deux chiffres : le taux de bugs post-merge sur les PRs IA-assistées vs les autres, et le temps de revue moyen des PRs IA. Si tes PRs IA prennent 2x plus de temps en revue, le gain d'écriture est déjà mangé. C'est le chiffre que GitClear rend invisible : la dette ne paie pas aujourd'hui, elle paie en année trois.

3. Le taux de non-confiance, sur tes devs.

30% des devs DORA n'ont pas confiance dans le code IA. Dans ton équipe, qui relit quoi ? Si personne ne sait, tu n'as pas une politique de revue, tu as une loterie. Le chiffre à présenter : le pourcentage de code IA relu par un humain, et les critères de la relecture.

Avec ces trois chiffres, tu peux répondre "l'IA nous coûte X et nous rapporte Y, sur ces tickets" avec des données, et décider où elle aide vraiment : le boilerplate oui, la logique critique à re-évaluer.

La plus grosse erreur de mesure est gratuite : demander aux devs. METR l'a prouvé dans les deux sens : les devs pensaient gagner 24% de temps, ils en perdaient 19. Perception +20%, réalité -19%.

Pire : METR a répliqué l'étude en 2026 avec 57 devs et 800 tâches, et ils déclarent eux-mêmes leurs chiffres non fiables, parce que 30 à 50% des devs refusaient de rendre certaines tâches "qu'ils ne voulaient pas faire sans IA". Quand la mesure devient impossible à biaiser par l'usage, c'est le signal que le ressenti ne peut pas servir de métrique.

Le ressenti est un indicateur d'adoption, pas de productivité. Il mesure ce que tes devs pensent de l'outil, pas ce que l'outil fait à ta capacité de livraison.

L'export d'analytics de ton gestionnaire de tickets. Il est déjà payé, déjà branché, et il suffit pour les 3 chiffres : vélocité par sprint (points livrés vs re-ouverts), temps de revue par PR (branche du code IA vs le reste), taux de ré-ouverture post-merge. Zéro outil nouveau, zéro budget : deux heures d'export et un graphique à montrer en next sprint planning. Le vrai outil de la semaine, c'est la question que tu poses en sprint review : "sur les tickets IA, on a livré quoi, cassé quoi, relu quoi ?"

Réponds-moi. Et si tu ne sais pas, tu as trouvé ton premier chantier de mesure : les trois chiffres ci-dessus, sur un sprint, avant le prochain budget IA.