Avant d’évaluer l’impact des assistants de code IA (Cursor, Claude Code, etc.) sur la productivité des développeurs, il faut d’abord préciser ce que recouvre réellement cette notion. Cette mise au point permettra ensuite de mieux lire les travaux de recherche, notamment les différentes façons dont la “productivité” y est mesurée.
Définition de la productivité des développeurs selon le framework SPACE et les DORA metrics
Dans la littérature en génie logiciel, la “productivité” est rarement traitée comme une grandeur directement observable : c’est un construit qui doit être opérationnalisé via des indicateurs mesurables (des proxys). Le risque, si l’on retient un seul proxy, est de restreindre la mesure de la productivité à une seule dimension, et donc de la mesurer imparfaitement.
Le cadre SPACE formalise cette idée en proposant une mesure multidimensionnelle de la productivité, structurée en cinq dimensions : Satisfaction & bien-être, Performance, Activité, Communication & collaboration, Efficacité & flux. Il insiste sur le fait qu’aucune métrique isolée ne peut, à elle seule, rendre compte de la productivité des développeurs.
Dans les environnements qui intègrent les pratiques DevOps, où la valeur se matérialise en production, un autre cadrage fréquemment mobilisé est celui des métriques DORA (DevOps Research and Assessment). Elles décrivent la performance de delivery via des mesures de vélocité (par exemple : fréquence de déploiement, lead time des changements) et de stabilité (par exemple : taux d’échec des changements, temps de restauration). Ces métriques illustrent le fait que livrer plus vite n’est pas suffisant pour mesurer la productivité des développeurs : la stabilité en production est une composante indissociable de la performance globale.
Productivité et qualité : trade-off ou complémentarité ?
Un gain de productivité peut ainsi se traduire par davantage de changements utiles livrés sur une même période : plus de fonctionnalités, plus d’itérations produit, davantage d’expérimentations (A/B tests), correction de bugs plus rapide, ou réduction du time-to-market. Dit simplement : on augmente le rythme de livraison.
Le point critique est que ce bénéfice “quantitatif” n’est durable que si la qualité reste sous contrôle. Sinon, l’augmentation du débit produit surtout du travail futur : reprise du code généré, régressions, incidents, dette technique, ralentissements de la maintenance. Le bon indicateur est donc celui de la productivité nette :
- Gain net si le débit augmente sans faire exploser le coût de vérification/correction (ou si ces coûts augmentent moins que le débit).
- Gain illusoire si le débit augmente mais que la qualité se dégrade au point que la reprise du code et les interruptions annulent (ou dépassent) l’avantage initial.
La question de la qualité du code produit est en effet primordiale. À long terme, la qualité n’augmente pas la productivité d’un point de vue de la quantité de code produit ; mais un code maintenable et fiable permet de continuer à livrer vite (reviews plus fluides, tests plus efficaces, moins de surprises en production). Autrement dit, la quantité livrée n’est bénéfique que si elle respecte les standards de qualité.
L’opérationnalisation de la productivité dans les études expérimentales sur l’impact des assistants de code IA
Le framework SPACE et les métriques DORA permettent de distinguer le concept de “productivité des développeurs” des opérationnalisations retenues dans les études empiriques portant sur les assistants de code IA.
Ces études cherchent en effet à évaluer l’impact des assistants de code IA tel Cursor sur la productivité des développeurs et mesurent rarement en pratique la productivité “au sens large” : elles privilégient des proxys observables qui capturent une ou deux dimensions seulement. Par exemple :
- Becker et al. (2025) opérationnalisent la productivité en s’intéressant uniquement au temps de réalisation des tâches et, plus finement, évaluent le temps alloué à chaque activité nécessaire à la complétion de cette tâche (écriture, prompting, test, etc.), ce qui renseigne surtout sur l’efficacité immédiate.
- Kumar et al. (2025) adoptent quant à eux une opérationnalisation de la productivité multi-dimensionnelle, donc plus complète. Ils s’intéressent à l’impact des assistants de code IA sur le temps de revue de code, le volume de lignes de code livré en production, mais aussi à la qualité du code, en mesurant le nombre de lignes générées par IA acceptées en production, tout en s’intéressant également à la satisfaction des utilisateurs.
- Cui et al. (2025) utilisent des proxys d’activité (tâches, commits, compilations), qui décrivent l’intensité de production mais pas nécessairement la qualité.
- Enfin, Rasheed et al. (2025) se situent davantage du côté de la satisfaction et de l’utilité perçue (via une enquête menée auprès des développeurs), c’est-à-dire des conditions d’acceptabilité plutôt que d’une mesure d’impact direct sur des métriques d’activité ou de qualité du code.
Cette hétérogénéité d’opérationnalisation éclaire une partie des divergences de résultats : mesurer l’activité, le delivery ou la perception ne revient qu’à mesurer un aspect du concept de productivité.
Conclusion
La productivité des développeurs ne se réduit pas à une métrique unique, mais est un construit multidimensionnel qui nécessite des choix d’indicateurs explicites.
Dans ce contexte, les études sur les assistants de code IA (Cursor, Claude Code, etc.) ne parlent pas toujours de la même “productivité” : certaines mesurent surtout l’efficacité immédiate (temps, quantité de code produite), d’autres intègrent la qualité, le delivery, ou encore la satisfaction. Comprendre ces opérationnalisations est indispensable pour interpréter correctement les résultats, comparer les travaux entre eux, et éviter les conclusions hâtives.
