Le tableau de bord vous ment : comment mesurer l'impact réel de l'IA sur le développement ?

Plus de jetons = plus d'impact ? Eh bien, non. Il n'y a pas si longtemps, une grande entreprise de logiciels était convaincue d'avoir enfin résolu l'une des questions brûlantes de l'année dernière : quel est l'impact réel des outils d'IA sur les performances de sa R&D. Les tableaux de bord semblaient excellents, les graphiques grimpaient, les taux d'adoption augmentaient et une mesure revenait sans cesse dans les présentations à la direction : le pourcentage de code IA (AI Code Percentage) — une mesure conçue pour montrer quelle part du code entrant dans le système a été écrite avec l'aide de l'intelligence artificielle. En apparence, cela ressemble à un excellent KPI : si le chiffre augmente, il est clair que l'adoption augmente. Mais qu'est-ce que cette utilisation a réellement changé ?

C'est là que le problème commence. Les responsables du développement, les vice-présidents et les CTO ne veulent pas vraiment savoir seulement combien de code a été écrit avec l'IA. Ils doivent comprendre si le développement est devenu plus rapide, si la qualité du code est maintenue, si la charge de test a changé et si l'investissement dans les nouveaux outils génère de la valeur pour l'organisation. La mesure du pourcentage de code IA reflète le degré d'utilisation, mais elle ne peut pas répondre seule à la question de l'impact.

La solution parfaite pourrait vous mentir

Lorsqu'ils cherchent à résoudre ce problème de visibilité, l'instinct initial de la plupart des organisations est de s'appuyer sur les données analytiques et les outils prêts à l'emploi fournis par les fabricants d'IA eux-mêmes. Cela ressemble à la solution parfaite : prendre une activité de développement complexe et la distiller en un chiffre unique et sans ambiguïté de pourcentage d'utilisation. Ces tableaux de bord présentent une image détaillée de la télémétrie des outils : combien de fois un développeur a activé un plugin dans l'IDE, combien de suggestions de code ont été acceptées, combien de prompts ont été envoyés et combien de temps a duré une session active.

Ces tableaux de bord peuvent être très précis pour décrire l'activité au sein de l'outil, mais cette information est limitée à la question de savoir combien l'IA a été utilisée. Elle n'explique pas nécessairement ce qui est arrivé à la vitesse de livraison, à la charge de revue, à la qualité du code ou au coût total du travail. Le pourcentage de code IA est une mesure utile pour comprendre l'ampleur de l'adoption, mais il ne peut pas tirer de conclusions sur la productivité, la qualité et la valeur commerciale.

Alors, comment mesurer l'attribution du code en pratique ?

Avant même d'aborder une solution, il faut comprendre qu'aujourd'hui, il existe deux mondes d'information totalement distincts dans l'organisation. D'un côté, il y a cette télémétrie des outils d'IA et des divers agents qui sont lancés sur le marché à un rythme effréné. De l'autre côté, il y a les données de développement réelles de l'organisation, celles qui se trouvent dans les plateformes de développement classiques comme GitHub et Jira.

Lorsque le système de mesure tente d'estimer l'efficacité sans lien direct entre les mondes, il est contraint de faire des estimations approximatives. Il voit qu'un certain développeur a utilisé Cursor ou Claude Code ce jour-là, et il voit qu'il a téléchargé trois Pull Requests. Sans la capacité de croiser directement les données, le système pourrait attribuer l'impact de l'IA à toute l'activité effectuée dans ce laps de temps. Ainsi, un écart d'attribution (Attribution Gap) est créé, où nous savons qu'il y a eu utilisation de l'IA et nous savons que nous avons obtenu un résultat, mais nous basons par erreur le lien entre eux sur une déduction indirecte au lieu d'une attribution fiable au produit final.

Alors, comment mesurer correctement ? La transition de la mesure de l'utilisation (Usage) à l'attribution du code (Attribution) n'est pas une idée théorique, et elle nécessite une ingénierie des données totalement différente. Une solution pratique nécessite la mise en place d'une infrastructure qui connecte directement le lac de données GenAI (GenAI Data Lake) de l'organisation à l'activité Git réelle des développeurs et analyse les changements dans le code en temps réel.

Au lieu de regarder la durée de l'activité dans l'outil, le système analyse le produit au niveau de la ligne de code individuelle. Par exemple, lorsqu'un développeur termine une tâche complexe provenant d'un ticket spécifique dans Jira, le système identifiera que sur les 120 nouvelles lignes de code créées dans ce Pull Request, la source d'environ 50 lignes provient de suggestions de code directes de l'agent, et les lignes restantes sont le résultat d'une architecture humaine.

À partir du moment où le système effectue cette association, il est possible d'examiner l'impact des modèles d'IA en utilisant trois familles de mesures : la stabilité du code, la friction dans le processus de test et la qualité après la mise en production :

Mesure de survie du code (Code Survival) : Le système vérifie combien de code créé avec l'IA survit dans la base de code (Codebase) après deux semaines ou un mois. Si un pourcentage élevé est supprimé ou réécrit encore et encore par des développeurs humains dans les jours qui suivent, c'est le signe qu'une adoption rapide crée une dette technique plutôt qu'une productivité réelle.
Mesure de friction de revue (Review Friction) : Au lieu de supposer que le développement a été raccourci, on mesure le temps nécessaire pour qu'un Pull Request soit approuvé et le nombre de cycles de révision qu'il nécessite. De cette façon, il est possible d'identifier les cas où le code créé rapidement avec l'IA raccourcit l'étape d'écriture mais augmente la charge de test et de vérification pour les autres développeurs.
Mesure des bugs échappés (Escaped Bugs) : Le croisement des données d'IA avec les rapports de bugs permet de comparer le taux de bugs, de régressions et de réouverture de tickets dans le travail influencé par l'IA avec un travail similaire qui n'a pas été influencé par celle-ci.

Leçons et recommandations pratiques

Passer à une mesure basée sur l'attribution fait émerger des vérités organisationnelles complexes et oblige les responsables du développement à prendre des décisions basées sur des données fiables. Voici trois recommandations pratiques :

Ne mesurez pas l'activité, mesurez les résultats : Le suivi du nombre de licences actives ou du volume de jetons dans l'organisation donne une indication de l'ampleur des dépenses financières, mais pas de la productivité. Commencez à lier les signaux d'IA directement au code réellement écrit au niveau du Commit.
Identifiez les nouveaux goulots d'étranglement : Les outils d'IA raccourcissent effectivement le temps d'écriture initial du code, mais ils peuvent déplacer la charge vers l'étape de revue de code (Code Review). Si même les petits Pull Requests, qui devraient être relativement simples à vérifier, attendent plus longtemps pour être revus ou nécessitent plus de cycles de révision lorsqu'ils incluent une contribution de l'IA — il est possible que l'équipe ait déplacé le goulot d'étranglement de l'étape d'écriture à l'étape de vérification.
Adoptez un compromis entre transparence et commodité : Passer à une mesure précise nécessite une infrastructure de données plus complexe et peut révéler que les outils coûteux que vous avez achetés ne fournissent pas l'impact souhaité. Les responsables du développement doivent être prêts à abandonner les tableaux de bord « verts » et rassurants au profit de données de vérité qui peuvent complètement changer les décisions budgétaires et les plans d'adoption de l'organisation.

Le monde du développement est en plein milieu d'une transition accélérée vers un travail natif à l'IA (AI-native). La question centrale n'est plus de savoir dans quelle mesure les développeurs utilisent l'IA ou quel pourcentage de code a été écrit avec son aide, mais comment cette utilisation change tout le système de développement : vitesse de livraison, charge de test, qualité du code, coûts de main-d'œuvre et capacité des humains, des outils, des modèles et des agents à agir ensemble. Tant que nous continuerons à mesurer l'utilisation au lieu de l'impact, les tableaux de bord seront peut-être parfaitement précis, mais ils nous mèneront à une conclusion erronée.