- Alors que les outils de codage IA connaissent une adoption massive et que les coûts augmentent, les grandes entreprises technologiques structurent de manière multicouche la façon dont elles quantifient concrètement l’utilité de l’IA
- L’idée centrale est une approche hybride consistant à suivre à la fois les indicateurs fondamentaux d’ingénierie existants (ex. : débit des PR, taux d’échec des changements) et des indicateurs propres à l’IA (ex. : taux d’utilisation de l’IA, gain de temps, CSAT)
- Mise en avant d’un état d’esprit expérimental permettant de dégager des tendances et corrélations via une décomposition selon le niveau d’usage de l’IA par équipe, individu et cohorte, ainsi que par comparaison avant/après
- Il faut une conception équilibrée qui surveille en permanence la qualité, la maintenabilité et l’expérience développeur en parallèle des indicateurs de vitesse, afin d’éviter l’accumulation de dette technique et les effets pervers des bénéfices de court terme
- À long terme, l’extension des mesures à la télémétrie distante des agents et aux domaines de travail non liés au code est annoncée, et la question se résume à : « l’IA améliore-t-elle ce qui compte déjà — qualité, vitesse de mise sur le marché, expérience développeur ? »
Le discours sur l’impact de l’IA et l’écart de mesure
- Comme on le voit souvent sur LinkedIn et ailleurs, les affirmations selon lesquelles l’IA transforme la manière dont les entreprises développent des logiciels abondent
- Les médias simplifient l’impact de l’IA à « combien de code a été écrit », mais ce faisant, le secteur s’expose au risque d’accumuler la plus grande dette technique de son histoire
- Bien qu’il existe un consensus sur le fait que les LOC (lignes de code) sont inadéquates comme indicateur de productivité, elles reviennent au premier plan en raison de leur facilité de mesure, occultant des valeurs essentielles comme la qualité, l’innovation, la vitesse de mise sur le marché et la fiabilité
- Aujourd’hui, de nombreux responsables engineering prennent des décisions majeures sur les outils d’IA sans savoir clairement ce qui fonctionne ou non
- Selon le LeadDev 2025 AI Impact Report, 60 % des dirigeants citent « l’absence de métriques claires » comme principal défi
- Sur le terrain, les managers expriment leur frustration, pris entre la pression sur les résultats et des dirigeants obsédés par les LOC, tandis que l’écart entre les informations nécessaires et les mesures réellement disponibles ne cesse de se creuser
- L’auteur étudie les outils pour développeurs depuis plus de dix ans et, depuis 2021, conseille sur l’amélioration de la productivité et la mesure de l’impact de l’IA
- Depuis son arrivée comme CTO chez DX, il a collaboré avec plusieurs centaines d’entreprises en pilotant des analyses sur la DevEx, l’efficacité et l’impact de l’IA
- Début 2025, il a coécrit l’AI Measurement Framework sur la base de données issues de plus de 400 entreprises
- Il s’agit d’un ensemble de métriques recommandées pour mesurer l’adoption et l’impact de l’IA, construit à partir de recherches de terrain et d’analyses de données
- Dans cet article, il examine comment 18 entreprises tech mesurent réellement l’impact de l’IA, et partage
- des exemples concrets de métriques chez Google, GitHub, Microsoft et d’autres
- des façons de les exploiter pour comprendre ce qui fonctionne
- une méthodologie de mesure de l’impact de l’IA
- des définitions et guides pour les métriques d’impact de l’IA
1. Les métriques réellement utilisées par 18 entreprises
- Des cas de 18 entreprises comme Google, GitHub, Microsoft, Dropbox, Monzo, Atlassian, Adyen, Booking.com et Grammarly sont partagés sous forme d’image
- Même si les entreprises adoptent des approches différentes, elles se concentrent en commun sur quelques grandes familles de métriques
-
1. Métriques d’usage (Adoption & Usage)
- DAU/WAU/MAU : presque toutes les entreprises suivent les utilisateurs actifs quotidiens, hebdomadaires et mensuels des outils IA
- Intensité d’usage / événements d’utilisation : Google, eBay et d’autres détaillent jusqu’à l’écriture de code, les réponses dans le chat et les agentic actions
- CSAT des outils IA : Dropbox, Webflow, Grammarly et beaucoup d’autres complètent cela par des enquêtes de satisfaction
-
2. Métriques de productivité (Throughput & Time Savings)
- Débit des PR (PR throughput) : suivi de manière récurrente par GitHub, Dropbox, Webflow, CircleCI et de nombreuses autres entreprises
- Gain de temps (Time savings) : mesure du temps économisé chaque semaine par ingénieur (Dropbox, Monzo, Toast, Xero, etc.)
- Temps de cycle des PR : utilisé chez Microsoft, CircleCI, Xero, Grammarly et d’autres
-
3. Métriques de qualité / stabilité (Quality & Reliability)
- Change Failure Rate : l’indicateur qualité le plus fréquent chez GitHub, Dropbox, Adyen, Booking.com, Webflow, etc.
- Maintenabilité du code / perception de la qualité : évaluées chez GitHub, Adyen, CircleCI et d’autres en lien avec la DevEx
- Taux de bugs / de rollback : Glassdoor (nombre de bugs), Toast (PR revert rate)
-
4. Métriques d’expérience développeur (Developer Experience)
- Satisfaction développeur / enquêtes (DevEx, DXI) : utilisées chez Atlassian, Webflow, CarGurus, Vanguard et d’autres
- Bad Developer Days (BDD) : Microsoft mesure de façon originale les frictions via le concept de « mauvaise journée de développeur »
- Charge cognitive et developer friction : chez Google, eBay et d’autres
-
5. Métriques de coûts et d’investissement (Spend & ROI)
- Dépenses IA (total & par développeur) : certaines entreprises, comme Dropbox, Grammarly et Shopify, suivent les coûts
- Capacity worked (taux d’utilisation) : Glassdoor mesure à quel point l’outil est utilisé par rapport à son potentiel maximal
-
6. Métriques d’innovation / expérimentation (Innovation & Experimentation)
- Innovation ratio / velocity : GitHub, Microsoft, Webflow et d’autres cherchent à quantifier la vitesse d’innovation
- Nombre de tests A/B : Glassdoor en fait une métrique clé mensuelle
- Des indicateurs de résultats comme le gain de temps, le débit des PR, le taux d’échec des changements, les utilisateurs engagés et le taux d’innovation sont suivis en parallèle avec des indicateurs de comportement d’usage
- La composition des métriques varie selon les priorités organisationnelles et le contexte produit ; il n’existe pas de métrique universelle
2. Une base solide : le cœur de la mesure de l’impact de l’IA
- Le fait d’écrire du code avec l’IA ne change pas les critères d’un bon logiciel. La qualité, la maintenabilité et la vitesse restent essentielles
- Par conséquent, des métriques existantes comme le Change Failure Rate, le débit de PR, le temps de cycle des PR et l’expérience développeur (DevEx) restent importantes
- Il n’est pas nécessaire d’inventer des métriques entièrement nouvelles
- La vraie question est : « L’IA permet-elle de mieux faire ce qui était déjà important ? »
- Si l’on s’en tient à des métriques superficielles comme le LOC ou le taux d’acceptation, on ne peut pas mesurer correctement l’impact de l’IA
- De nouvelles métriques cibles sont nécessaires pour comprendre précisément ce qui se passe dans l’usage de l’IA
- Elles permettent d’identifier où, à quel niveau et de quelle manière l’IA est utilisée, afin d’éclairer les décisions sur les budgets, le déploiement des outils, la sécurité et la compliance
- Les métriques IA montrent des éléments comme :
- Combien de développeurs adoptent des outils d’IA, et quels profils ils ont
- Dans quelle mesure l’IA influence le volume et les types de tâches
- Quel en est le coût
- Les métriques d’ingénierie clés montrent des éléments comme :
- Si les équipes livrent plus vite
- Si la qualité et la fiabilité progressent ou régressent
- Si la maintenabilité du code se dégrade
- Si les outils d’IA réduisent les frictions dans le workflow des développeurs
-
En prenant l’exemple de Dropbox
- Métriques IA
- DAU/WAU (utilisateurs actifs quotidiens et hebdomadaires)
- CSAT des outils d’IA (satisfaction)
- Temps économisé par ingénieur
- Dépenses liées à l’IA
- Métriques cœur (avec le Core 4 Framework)
- Change Failure Rate
- Débit de PR
- Résultats
- Les utilisateurs réguliers hebdomadaires de l’IA représentent 90 % de l’ensemble des ingénieurs, au-dessus de la moyenne du secteur de 50 %
- Les utilisateurs réguliers de l’IA affichent 20 % de PR fusionnées en plus ainsi qu’une baisse du Change Failure Rate
- L’essentiel n’est pas le taux d’adoption en soi, mais de vérifier si cela contribue réellement à la performance de l’organisation, des équipes et des individus
3. Décomposer les métriques selon le niveau d’usage de l’IA
- Réaliser différentes analyses comparatives pour comprendre comment l’IA change la manière de travailler des développeurs
- Comparer les utilisateurs de l’IA aux non-utilisateurs
- Comparer les métriques d’ingénierie clés avant et après l’adoption d’outils d’IA
- Suivre le même groupe d’utilisateurs (cohort analysis) pour observer les changements après l’adoption de l’IA
- Segmenter les données (slicing & dicing) pour faire émerger des patterns
- Analyse par attributs comme le rôle, l’ancienneté, la région ou le langage principal
- Exemple : les juniors rédigent davantage de PR, tandis que les seniors ralentissent en raison d’une part plus importante consacrée à la review
- Cela permet d’identifier les groupes qui ont besoin de formation ou de soutien supplémentaire et ceux pour lesquels l’effet de l’IA est le plus fort
- Exemple de Webflow
- Chez les développeurs ayant plus de 3 ans d’ancienneté, le gain de temps lié à l’IA était le plus important
- L’utilisation d’outils comme Cursor et Augment Code a entraîné une hausse de 20 % du débit de PR (comparaison entre utilisateurs de l’IA et non-utilisateurs)
- La nécessité d’une baseline solide
- Les organisations qui ne disposent pas de base en matière de métriques de productivité développeur ont du mal à mesurer l’impact de l’IA
- Le Core 4 Framework (utilisé par Dropbox, Adyen, Booking.com, etc.) permet d’établir rapidement une baseline
- Utiliser conjointement les données système, les données d’échantillonnage d’expérience et des enquêtes régulières permet d’effectuer des comparaisons fiables
- Le suivi continu et un état d’esprit expérimental sont essentiels
- Une mesure ponctuelle n’a pas beaucoup de sens ; il faut un suivi dans le temps pour identifier les tendances et les patterns
- Point commun des entreprises qui réussissent : elles définissent des objectifs concrets et valident leurs hypothèses à l’aide des données
- Sans dépendre aveuglément des données, elles conservent un état d’esprit expérimental centré sur les objectifs
4. Vigilance sur la maintenabilité, la qualité et l’expérience développeur
- Le développement assisté par IA reste un domaine encore nouveau
- Les données manquent encore pour prouver son impact sur la qualité du code et la maintenabilité à long terme
- Le principal enjeu est de trouver l’équilibre entre les gains de vitesse à court terme et le risque de dette technique à long terme
- Il faut suivre ensemble des métriques qui se contrebalancent
- La plupart des entreprises suivent à la fois le Change Failure Rate et le débit de PR
- Si la vitesse augmente mais que la qualité baisse, cela devient immédiatement un signal de problème
- Métriques supplémentaires pour surveiller la qualité et la maintenabilité
- Change confidence : niveau de confiance des développeurs dans la stabilité du code lors du déploiement
- Code maintainability : facilité à comprendre et modifier le code
- Perception of quality : perception par les développeurs de la qualité du code et des pratiques de l’équipe
- La combinaison de métriques système et auto-déclarées est nécessaire
- Données système : débit de PR, fréquence de déploiement, etc.
- Données auto-déclarées : confiance dans les changements, maintenabilité, etc. → des signaux clés pour prévenir les effets négatifs à long terme
- Des enquêtes régulières sur l’expérience développeur (DevEx) sont recommandées
- Le modèle d’enquête permet de suivre la corrélation entre qualité, maintenabilité et usage de l’IA
- Les retours non structurés sont aussi utiles pour identifier les problèmes existants et discuter des solutions
- Ce que signifie réellement l’expérience développeur (DevEx)
- Il ne s’agit pas d’avantages de type « ping-pong et bière », mais de réduire les frictions tout au long du processus de développement
- L’objectif est d’améliorer l’efficacité sur l’ensemble du cycle : planification → développement → test → déploiement → exploitation
- Les outils d’IA peuvent réduire les frictions dans l’écriture du code et les tests, tout en risquant d’en ajouter de nouvelles dans la review, la réponse aux incidents et la maintenance
- Retour du terrain (Shelly Stuart, CircleCI)
- Les métriques de sortie (débit de PR) montrent ce qui se passe, tandis que la satisfaction des développeurs montre la durabilité
- L’adoption de l’IA peut entraîner des inconforts initiaux ; suivre la satisfaction est donc un outil clé pour distinguer frictions à court terme et valeur à long terme
- 75 % des entreprises suivent aussi le CSAT/la satisfaction des outils d’IA, avec un focus non pas sur la vitesse mais sur une culture de développement durable
5. Métriques atypiques et tendances intéressantes
- Microsoft : Bad Developer Day (BDD)
- Un concept qui mesure en temps réel les frictions et la fatigue dans le travail quotidien
- La réponse aux incidents et le traitement de la conformité, le coût de bascule entre réunions et e-mails, ainsi que le temps consommé par les systèmes de gestion du travail sont autant de facteurs qui rendent une journée mauvaise
- En l’équilibrant avec l’activité PR (un indicateur indirect du temps de codage), une journée est considérée comme bonne si un certain temps a pu être réservé au codage, même en présence de tâches à faible valeur
- Objectif : vérifier si les outils d’IA réduisent la fréquence et la gravité des BDD
- Glassdoor : mesure de l’expérimentation et du taux d’usage des outils
- Suivi, via le nombre mensuel de tests A/B, de la capacité de l’IA à accélérer l’innovation et le rythme d’expérimentation
- Une stratégie parallèle consiste à faire des power users des évangélistes internes de l’IA
- Capacity worked (taux d’utilisation) : mesure de l’usage réel par rapport au potentiel d’utilisation d’un outil afin de déterminer le point de saturation de l’adoption et de décider d’une réallocation budgétaire
- Baisse de l’Acceptance Rate
- Autrefois un indicateur clé de l’IA, mais son périmètre est étroit car il ne regarde que le moment où une suggestion est acceptée
- Il ne reflète ni la maintenabilité, ni l’apparition de bugs, ni les retours arrière sur le code, ni la productivité perçue par les développeurs
- Il n’est aujourd’hui plus beaucoup utilisé comme indicateur principal, avec quelques exceptions :
- GitHub : l’utilise pour améliorer Copilot et orienter les décisions produit
- T-Mobile : l’utilise pour estimer dans quelle mesure le code IA est réellement intégré en production
- Atlassian : l’utilise comme indicateur complémentaire de la satisfaction des développeurs et de la qualité des suggestions
- Analyse des coûts et des investissements
- La plupart des entreprises ne suivent pas activement les coûts d’usage afin d’éviter de freiner les développeurs
- Shopify a adopté une approche qui consiste à féliciter, via un AI Leaderboard, les développeurs qui consomment le plus de tokens
- ICONIQ 2025 State of AI Report : les budgets de productivité IA en entreprise devraient doubler en 2025 par rapport à 2024
- Certaines organisations évoluent vers une réduction du budget de recrutement au profit d’une réallocation vers les outils d’IA
- Absence de télémétrie des agents
- Il n’existe presque pas encore de mesure aujourd’hui, mais une adoption dans les 12 prochains mois est probable
- À mesure que les workflows d’agents autonomes se diffusent, la nécessité de mesurer des éléments comme les comportements, la précision et le taux de régression va croître
- Manque de mesure des activités non liées au codage
- Pour l’instant, la mesure se limite à l’aide à l’écriture de code ; des sessions de planification sur ChatGPT ou le traitement d’issues Jira sont rarement inclus
- En 2026, l’usage de l’IA devrait s’étendre à l’ensemble des étapes du SDLC, ce qui nécessitera aussi une évolution des méthodes de mesure
- Les activités concrètes comme la revue de code ou l’analyse de vulnérabilités sont faciles à mesurer, tandis que les tâches abstraites le sont difficilement
- Un élargissement du périmètre des mesures auto-déclaratives (« Combien de temps l’IA vous a-t-elle fait gagner cette semaine ? ») est attendu
6. Comment mesurer l’impact de l’IA ?
- AI Measurement Framework
- Développé avec Abi Noda, co-auteur du DevEx Framework
- Élaboré à partir de données de terrain issues de plus de 400 entreprises et de plus de dix ans de recherche sur la productivité des développeurs
- Il combine des indicateurs IA et des indicateurs cœur afin d’évaluer ensemble la vitesse, la qualité, la maintenabilité et l’expérience développeur (DevEx)
- Un indicateur unique (par exemple la part de code généré par l’IA) convient aux gros titres, mais n’est pas un moyen suffisant de mesurer la performance
- Nécessité de combiner données qualitatives et quantitatives
- Il faut collecter à la fois des indicateurs système (débit des PR, DAU/WAU, fréquence de déploiement, etc.) et des indicateurs auto-déclarés (CSAT, gain de temps, perception de la maintenabilité, etc.) pour obtenir une compréhension multidimensionnelle
- De nombreuses entreprises utilisent DX pour la collecte et la visualisation des données, mais il est aussi possible de construire un système sur mesure
- Méthodes de collecte des données
- Données système (quantitatives) : API d’administration des outils d’IA (usage, dépenses, tokens, taux d’acceptation) + indicateurs issus de SCM, JIRA, CI/CD, build et gestion des incidents
- Enquêtes régulières (qualitatives) : enquêtes trimestrielles ou semestrielles pour suivre des tendances de long terme, comme la DevEx, la satisfaction, la confiance dans les changements ou la maintenabilité, difficiles à obtenir via les seuls indicateurs système
- Échantillonnage d’expérience (qualitatif) : insertion de courtes questions au cours du workflow (par exemple juste après la soumission d’une PR : « Avez-vous utilisé l’IA ? », « Ce code était-il facile à comprendre ? »)
- Priorités d’exécution
- Les enquêtes régulières sont le point de départ le plus rapide : il est possible d’obtenir des données initiales en 1 à 2 semaines
- De même que l’on n’exige pas la même précision pour poser des rideaux que pour lancer une fusée, des décisions d’ingénierie peuvent être utiles avec un niveau de précision simplement suffisant pour donner une direction
- La fiabilité augmente ensuite si l’on complète avec d’autres méthodes de collecte de données pour effectuer des validations croisées
- Ressources supplémentaires
- Points à considérer pour une application en interne
- Il ne faut pas chercher le taux d’adoption ou un indicateur unique, mais vérifier si la capacité à livrer rapidement aux clients un logiciel de haute qualité s’améliore
- Question centrale :
> « L’IA améliore-t-elle ce qui compte déjà vraiment (qualité, vitesse de mise sur le marché, expérience développeur) ? »
- Questions à traiter en réunion de direction :
- Quelle est la définition de la performance d’ingénierie dans notre organisation ?
- Dispose-t-on de données de performance antérieures à l’adoption des outils d’IA ? Sinon, comment établir rapidement une baseline ?
- Sommes-nous en train de confondre activité IA et impact de l’IA ?
- Trouvons-nous un équilibre entre vitesse, qualité et maintenabilité ?
- Observe-t-on un impact sur l’expérience développeur ?
- Exploitons-nous une approche de mesure multicouche qui inclut à la fois les données système et les données auto-déclarées ?
7. La méthode de Monzo pour mesurer l’impact de l’IA
- Début de l’adoption
- Le premier outil a été GitHub Copilot. Inclus dans la licence GitHub, il s’est naturellement intégré à VS Code, ce qui a permis à tous les ingénieurs de commencer à l’utiliser
- Ensuite, divers outils comme Cursor, Windsurf et Claude Code ont été testés en parallèle, tout en poursuivant les investissements autour de Copilot
- Philosophie d’évaluation des outils IA
- Dans un écosystème d’outils qui évolue rapidement, l’expérience directe est indispensable
- Pour en connaître réellement les performances, les membres de l’équipe doivent appliquer l’IA chaque jour sur du vrai code, et aller jusqu’à créer eux-mêmes et utiliser les fichiers de configuration des agents
- L’évaluation combine des indicateurs objectifs (usage, performances) et des enquêtes subjectives (satisfaction DX)
- Effets et valeur perçue
- Les ingénieurs estiment que l’IA facilite la recherche et le résumé de documentation, ainsi que la compréhension du code, et réduit la charge cognitive
- Sur un marché des talents concurrentiel, ne pas fournir les meilleurs outils augmente le risque de départ des développeurs → fournir ces outils constitue en soi une stratégie de rétention des talents
- Difficultés de mesure
- Les chiffres fournis par les éditeurs se limitent à des indicateurs restreints comme le taux d’adoption, et il est difficile d’identifier le véritable impact business
- Il est aussi irréaliste de le valider précisément par des tests A/B
- Il est difficile d’agréger les données d’usage de différents outils (GitHub, Gemini, Slack, Notion, etc.) → les limites de télémétrie et le vendor lock-in sont des obstacles majeurs
- En conséquence, le ressenti des développeurs reste aujourd’hui le principal signal
- Domaines où cela fonctionne bien
- Les migrations donnent de très bons résultats : une réduction perçue de 40 à 60 % des tâches de modification de code
- Pour des tâches répétitives et manuelles comme l’annotation de modèles de données, les LLM produisent un premier brouillon, puis les ingénieurs corrigent → forte économie de travail à grande échelle
- Leçons inattendues
- Manque de perception du coût des LLM : voir la facture liée à l’usage réel des tokens ferait davantage prendre conscience du besoin d’optimisation
- Exemple : la revue de code automatique de Copilot consomme beaucoup de tokens pour peu de résultats, elle est donc désactivée par défaut et bascule en mode opt-in si nécessaire
- Domaines où l’IA n’est pas utilisée
- Données client : interdiction d’appliquer l’IA aux données brutes comme aux données désidentifiées
- Dans les zones impliquant des données sensibles, la priorité absolue est d’éviter les risques de fuite de données
- Philosophie de l’équipe plateforme
- Fournir des garde-fous : mettre en place un environnement d’utilisation sûr, notamment pour la protection des données
- Partager les cas d’usage : rendre publics de manière transparente les exemples de réussite et d’échec, ainsi que les retours d’expérience sur l’usage des prompts
- Mettre en avant la dualité : partager à la fois le positif et le négatif afin de conserver une vision équilibrée
- Rappeler les limites des LLM : l’IA a des limites, comme les humains, et il ne faut pas lui accorder une confiance excessive
Conclusion et enseignements
- La mesure de l’impact de l’IA reste un domaine très nouveau
- Il n’existe pas de « meilleure méthodologie » reconnue dans le secteur
- Même des entreprises de taille et de marché comparables, comme Microsoft et Google, utilisent des indicateurs différents
- Chaque entreprise a donc sa propre approche et sa propre « flavor »
- Mesurer simultanément des indicateurs contradictoires est une pratique courante
- Exemple représentatif : suivre à la fois le taux d’échec des changements (fiabilité) et la fréquence des PR (vitesse)
- Déployer rapidement n’a de sens que si cela ne dégrade pas la fiabilité ; il faut donc mesurer ces deux axes de manière équilibrée
- Mesurer l’impact des outils IA pose des difficultés similaires à celles de la mesure de la productivité des développeurs
- La mesure de la productivité est un problème avec lequel le secteur se débat depuis plus de dix ans
- Aucun indicateur unique ne peut expliquer la productivité d’une équipe, et optimiser un indicateur donné n’augmente pas nécessairement la productivité réelle
- En 2023, McKinsey a affirmé avoir « résolu » la question de la mesure de la productivité, mais Kent Beck et l’auteur se montrent sceptiques à ce sujet → article de réponse
- Il n’existe pas encore de solution claire, mais il faut expérimenter
- Tant que la mesure de la productivité ne sera pas pleinement résolue, il sera difficile de résoudre complètement aussi la mesure de l’impact des outils IA
- Malgré cela, il faut continuer à expérimenter et à tenter de nouvelles approches pour répondre à la question : « Comment les outils de coding IA changent-ils l’efficacité quotidienne et mensuelle des individus, des équipes et des entreprises ? »
Aucun commentaire pour le moment.