Cette analyse approfondie explore comment 18 grandes entreprises tech, dont Google, GitHub, Microsoft et Dropbox, mesurent l'impact de l'IA sur le développement logiciel, face au défi de justifier des investissements croissants dans les outils de codage IA. Rédigé par Gergely Orosz et Laura Tacho (CTO de DX), l'article souligne que si 85 % des ingénieurs utilisent des outils IA, beaucoup de leaders d'ingénierie peinent à en évaluer la valeur réelle, faute de métriques claires au-delà de mesures superficielles comme les lignes de code (LOC).
Message central : combiner les métriques
le plus gros tas de dette technique
Une mesure efficace de l'impact de l'IA exige de combiner les métriques d'ingénierie « core » existantes et de nouvelles métriques spécifiques à l'IA. Les entreprises ne doivent pas abandonner les métriques traditionnelles comme le Change Failure Rate, le débit de PR, le temps de cycle des PR et l'expérience développeur, car l'objectif ultime de l'IA est précisément d'améliorer ces fondamentaux de la livraison logicielle. Ces métriques core doivent être suivies conjointement avec les taux d'adoption IA, la satisfaction (CSAT) vis-à-vis des outils, le temps gagné par ingénieur et la dépense IA. Dropbox, par exemple, a atteint 90 % d'adoption IA et vu ses ingénieurs fusionner 20 % de pull requests en plus avec un taux d'échec de changement réduit.
Segmentation et état d'esprit expérimental
Un aspect crucial est la ventilation des métriques par niveau d'usage de l'IA : comparer utilisateurs IA et non-IA, et analyser les tendances dans le temps. Ce découpage par rôle, ancienneté ou langage de programmation aide à identifier les groupes qui bénéficient le plus de l'IA ou nécessitent une formation supplémentaire. L'article insiste sur l'état d'esprit expérimental, où les données servent à répondre à des questions précises et à tester des prédictions sur l'influence de l'IA.
Qualité, maintenabilité, expérience développeur
La vigilance sur la qualité du code, la maintenabilité et l'expérience développeur est primordiale. Les auteurs avertissent que le développement assisté par IA peut créer « le plus gros tas de dette technique » s'il n'est pas géré avec soin. Il est essentiel de suivre des métriques qui se contrôlent mutuellement, comme la vitesse avec la qualité (débit de PR et CFR). Au-delà des métriques système, les données auto-déclarées sur la « confiance dans les changements », la « maintenabilité du code » et la « perception de la qualité » sont vitales pour capturer les impacts de long terme. L'expérience développeur, souvent réduite à tort à des avantages superficiels, est critique pour réduire la friction sur tout le cycle de développement.
Tendances émergentes et défis
Microsoft utilise les « bad developer days » (BDD) pour évaluer l'impact de l'IA sur la pénibilité quotidienne, tandis que Glassdoor mesure les résultats d'expérimentation (tests A/B). Le taux d'acceptation des suggestions IA, autrefois métrique de référence, décline car trop étroit : il ne capture ni la maintenabilité, ni l'introduction de bugs, ni la productivité globale. L'analyse des coûts, encore peu pratiquée pour ne pas décourager l'usage, devrait être davantage scrutée à mesure que les budgets IA croissent. La télémétrie d'agents et la mesure au-delà de l'écriture de code sont identifiées comme des domaines appelés à évoluer fortement.
AI Measurement Framework et couches de données
L'article introduit l'AI Measurement Framework, ensemble recommandé de métriques mêlant métriques IA et métriques d'ingénierie core, avec l'expérience développeur au centre. Il préconise une collecte de données en couches : données système quantitatives (outils IA, GitHub, JIRA, CI/CD), enquêtes périodiques qualitatives et échantillonnage d'expérience sur le moment. L'expérience de Monzo Bank sert d'étude de cas : la mesure objective est difficile (rétention des données par les fournisseurs), mais le ressenti subjectif des ingénieurs et des cas d'usage précis comme les migrations de code démontrent une valeur claire.