Dans certains secteurs, comme le développement informatique, l’IA fait déjà partie des pratiques de travail courantes. L’essor des assistants de code IA (Cursor, Claude Code, etc.), bouleverse en effet les workflows de développement.
Il soulève dès lors une question centrale : dans quelle mesure ces outils transforment-ils la productivité des développeurs, et dans quelles conditions les gains annoncés se matérialisent-ils réellement ?
Pour éclairer cet enjeu, cette revue de littérature vise à recenser et synthétiser les travaux les plus récents sur l’impact de ces assistants sur la productivité, à identifier les effets mis en évidence (gains, limites, effets différenciés selon les tâches et les profils), et à dégager les principaux facteurs explicatifs ainsi que les lacunes de la recherche actuelle.
La « productivité des développeurs » n’est pas mesurée de la même manière dans chacune de ces recherches, ce qui complexifie la comparaison de ces études
La « productivité des développeurs » est un concept multidimensionnel. Pour mesurer l’impact des assistants de code IA sur la productivité, il conviendrait ainsi de tenir compte de plusieurs indicateurs, mesurant aussi bien les effets quantitatifs que qualitatifs ou encore la satisfaction des développeurs. L’opérationnalisation du concept dans les recherches sur ce sujet ne s’intéressent souvent qu’à certaines dimensions, offrant de fait une mesure imparfaite de l’impact sur la productivité. En outre, ces différentes recherches ne s’intéressent pas toutes aux mêmes dimensions, ce qui complexifie leur comparaison.
Si vous souhaitez en plus sur la mesure de la productivité des développeurs, nous avons consacré un article à ce sujet accessible ici.
arXiv.org et revue par les pairs : les limites à garder en tête
L’analyse de cette littérature permet de constater que nombre d’articles sur ce sujet sont publiés sur arXiv.org, une plateforme de prépublication. Ce format a un avantage évident : il accélère la diffusion des résultats et facilite la discussion scientifique. Par ailleurs, les classements de revues académiques et le rang attribué à chaque revue ont eux-mêmes fait l’objet de critiques ; autrement dit, un article publié dans une revue classée n’est pas un gage automatique de qualité.
Mais il faut aussi être clair sur l’autre face de la médaille : sur arXiv, les articles ne sont pas évalués par les pairs avant publication. Cela signifie que certaines contributions peuvent gagner en visibilité avant que leur méthodologie, leurs hypothèses ou leurs résultats aient été réellement éprouvés. Le risque, dans un domaine aussi « à la mode » que les assistants de code IA est que des travaux séduisants ou très partagés puissent gagner en popularité malgré une méthode fragile, des biais non maîtrisés, ou des résultats difficilement généralisables.
Pour éviter cet écueil, nous avons choisi pour chaque article de détailler la méthode, puis de mettre explicitement en évidence ses limites (biais, validité externe, taille d’échantillon, protocole, métriques, reproductibilité, etc.).
L’objectif de cette revue de littérature est ainsi de permettre une lecture utile et éclairée : comprendre ce que chaque étude apporte réellement, et ce qu’elle ne permet pas d’affirmer.
Becker et al., 2025, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. publié sur arXiv.org
Objectif de la recherche
Evaluer l’impact des outils IA sur la productivité des développeurs dans des conditions réelles.
Gap théorique que cette recherche essaye de combler
Jusqu’à présent, l’impact des outils IA était évalué en laboratoire : les tâches utilisées dans les expériences nécessitaient peu de contexte ou de familiarité préalable. Les études en laboratoire présentent le désavantage de limiter la validité écologique de la recherche, c’est-à-dire la transposition à des contextes de développement réels. Par ailleurs, les études existantes mesurent la productivité des développeurs via des indicateurs tels que :
- Nombre de lignes de code ajoutées ;
- Nombre de tâches réalisées. Les auteurs indiquent que ces indicateurs mesurent néanmoins imparfaitement la productivité des développeurs :
- Un code peut être plus verbeux sans apporter de gain fonctionnel ;
- Une tâche peut être divisée en plusieurs sous-tâches sans que la quantité réelle de travail n’augmente.
Méthodologie
- Essai contrôlé randomisé en conditions réelles.
- L’échantillon est constitué de 16 développeurs expérimentés, mais ayant une expérience modérée avec l’IA.
- Il est demandé aux développeurs de l’échantillon, de réaliser 246 tâches sur des projets matures auxquels ils contribuent depuis en moyenne 5 ans.
- Chaque tâche est assignée aléatoirement à un groupe autorisant ou interdisant l’usage des outils d’IA récents (entre février et juin 2025). Le choix de l’outil d’IA est laissé libre. Lorsque l’usage de l’IA est permis, les développeurs utilisent principalement Cursor Pro et Claude 3.5/3.7 Sonnet.
- Les auteurs demandent aux développeurs de leur échantillon, avant et après l’étude, d’estimer le gain de temps de réalisation des tâches permis par l’IA.
- A partir d’enregistrements d’écran, les chercheurs labellisent manuellement les activités réalisées par les développeurs pour objectiver ce gain de temps.
Quelques remarques sur la méthodologie :
- La permission d’usage d’un assistant de code IA ne signifie pas que les développeurs vont forcément l’utiliser. Ils peuvent choisir de ne pas l’utiliser, ou d’utiliser un autre outil d’IA à la place.
- Cursor et Claude ne semblent pas avoir été configurés exprès pour les projets sur lesquels les développeurs autorisés à utiliser l’IA travaillent. Du moins, la section « 2.2.1 AI Tools and Training » n’en dit rien.
- La majorité des développeurs de l’échantillon n’a pas d’expérience dans l’utilisation de Cursor : « 93% have prior experience with tools like ChatGPT, but only 44% have experience using Cursor »
Résultats
- Estimation des gains de temps permis par l’IA par les développeurs eux-mêmes : o « Avant de commencer, les développeurs estiment que l’IA réduira le temps de réalisation des tâches de 24 %. Après l’étude, ils réévaluent cet effet à une réduction de 20 %. » (Notre traduction) o « De manière surprenante, nous constatons que l’IA augmente en réalité le temps de réalisation de 19 % – les outils d’IA ont ralenti les développeurs. Ce ralentissement va également à l’encontre des prévisions d’experts en économie (réduction de 39 %) et en apprentissage automatique (réduction de 38 %). » (Notre traduction)
- La figure ci-dessous montre le pourcentage de temps que les développeurs passent sur chaque activité, lorsque l’IA est autorisée et lorsqu’elle est interdite.
Pourcentage moyen de temps passé par activité dans les enregistrements d’écran annotés
Les auteurs cherchent à expliquer ces résultats en explorant 21 facteurs potentiels pouvant contribuer au fait que les développeurs passent plus de temps sur certaines tâches lorsque l’IA est autorisée.
Ils expliquent que selon eux, l’effet de ralentissement ne provient probablement pas uniquement de leur protocole expérimental.
Voici ci-dessous les facteurs identifiés par les chercheurs et qu’ils ont classés selon leur probabilité de contribution au ralentissement des développeurs sur certaines tâches lorsqu’ils utilisent l’IA.
Evaluation critique de l’étude
Cette recherche présente plusieurs limites importantes, notamment sur le plan méthodologique :
- L’échantillon est composé de seulement 16 développeurs : la faible taille de l’échantillon ne garantit pas une représentativité, et limite très fortement les possibilités de généralisation des résultats.
- En termes de représentativité de l’échantillon justement, celui-ci comprenait des développeurs expérimentés. Il aurait été pertinent de tenir compte de la variable « expérience du développeurs » dans l’étude de la relation entre « utilisation d’un assistant de code IA » et « évolution de la productivité » et d’inclure des développeurs juniors dans l’échantillon.
- La majorité des développeurs de l’échantillon (56%) n’a pas d’expérience avec Cursor.
- Cursor n’est pas configuré pour les projets spécifiques sur lesquels les développeurs travaillent.
Ces points doivent notamment être discutés au regard de l’étude de Kumar et al. (2025), détaillée plus loin, dont les résultats mènent d’autant plus à questionner les apports de Becker et al. (2025) :
- Tout d’abord, l’étude de Kumar et al. (2025) apparaît plus robuste, puisqu’elle repose sur un échantillon de 300 développeurs, et non de 16.
- Kumar et al. (2025) montrent qu’un usage sporadique d’assistants de code IA ne permet pas de bénéficier de gains de productivité. Ainsi, il s’agit selon nous d’une mise en perspective importante de la recherche de Becker et al. (2025), puisque la majorité des développeurs de l’échantillon n’a pas d’expérience sur les assistants de code, notamment sur Cursor. Il n’est pas ailleurs pas précisé, pour la part des développeurs ayant de l’expérience sur cet assistant de code, quel est justement ce niveau d’expérience (depuis combien de temps l’utilisent-ils, à quelle fréquence, pour quelles tâches, ont-ils suivi une formation spécifique, etc.)
- Kumar et al. (2025) mettent en évidence que les développeurs expérimentés bénéficient moins des avantages des outils d’IA que les développeurs juniors. Dès lors, le choix d’un échantillon composé quasi-exclusivement de développeurs expérimentés tend à mettre en question les résultats de l’étude Becker et al. (2025).
Kumar et al. 2025 Intuition to Evidence: Measuring AI’s True Impact on Developer Productivity, publié sur arXiv.org
Objectif de la recherche
Cette recherche est la première étude compréhensive à grande échelle et en conditions réelles, de la mise en œuvre et des effets d’un environnement de développement assisté par IA en entreprise. Les auteurs analysent sur une période d’un an (de septembre 2024 à août 2025) l’usage et l’impact d’une plateforme interne de génération de code couplée à un système automatisé de revue de code, auprès d’environ 300 développeurs/ingénieurs. L’environnement étudié (DeputyDev) vise à fournir une expérience « de bout en bout » d’assistance au développement : d’un côté, des capacités de génération de code comparables à des outils courants (p. ex. Cursor, Windsurf) ; de l’autre, des fonctionnalités de revue intelligente des pull requests destinées à détecter des bugs et suggérer des améliorations.
À travers ce dispositif, l’étude cherche à répondre à plusieurs questions : l’impact sur la productivité, l’efficacité de la revue de code, les facteurs humains liés à l’adoption, et le retour sur investissement (ROI) de l’adoption d’un tel outil.
Gap théorique que cette recherche essaye de combler
Cette recherche part du constat qu’un écart persiste entre les performances observées grâce à l’utilisation d’assistants de code IA dans le cadre de benchmarks dans des environnements contrôlés, et leurs performances réelles tout au long du cycle de développement logiciel. En effet, l’évaluation des assistants de code dans la littérature repose encore largement sur des benchmarks contrôlés, utilisant des jeux de données standardisés, ou sur des études ciblant une étape précise du développement logiciel.
Si ces approches permettent de mesurer certaines capacités techniques des modèles, elles rendent mal compte des conditions réelles de développement. En pratique, les développeurs travaillent sur des bases de code vastes et évolutives, doivent respecter des standards propres à chaque équipe, s’intégrer dans des chaînes d’outils existantes et composer avec des contraintes organisationnelles et sociales qui influencent l’adoption des outils.
Méthodologie
La méthodologie repose sur une étude menée au sein d’une organisation réelle auprès de 228 développeurs (146 ingénieurs backend, 29 frontend, 31 développeurs Android/iOS et 12 ingénieurs qualité). Les auteurs adoptent un design longitudinal quasi-expérimental visant à évaluer l’impact, en conditions réelles, d’outils de développement assistés par IA à l’échelle d’une grande organisation d’ingénierie. L’étude est dite quasi-expérimentale dans la mesure où elle cherche à estimer un effet causal à partir de groupes non randomisés, formés à partir de variations naturelles d’adoption de l’outil, tout en mettant en place des contrôles méthodologiques pour se rapprocher d’un contrefactuel crédible. Enfin, une enquête est administrée après cinq mois d’utilisation auprès des mêmes 228 développeurs afin de documenter l’expérience, la perception et l’adoption de l’outil.
Résultats
L’analyse des usages montre que l’adoption de l’outil se concentre principalement sur trois types d’activités : le développement d’interfaces et de composants frontend (25,2 % des usages), la correction de bugs et le débogage (21,8 %), ainsi que la génération de code backend (21,1 %). Ces trois catégories représentent près de 70 % des usages observés, ce qui indique que la plateforme est principalement mobilisée pour accélérer les tâches centrales de production de code. D’autres usages existent, mais à moindre fréquence, notamment la gestion de données, la compréhension de code existant ou les activités de test et d’automatisation. En revanche, l’adoption reste marginale pour des tâches comme la documentation, la gestion de projet ou les problématiques de sécurité, que les auteurs identifient comme des axes potentiels de développement futur.
Taux d’utilisation de l’outil DeputyDev selon l’usage
Impacts sur la productivité
De manière générale, l’étude met en évidence des gains de productivité statistiquement significatifs, en particulier une réduction moyenne de 31,8 % du temps de cycle des revues de pull requests. L’adoption par les développeurs apparaît forte, avec un taux de satisfaction élevé pour les fonctionnalités de revue de code et une large majorité souhaitant continuer à utiliser la plateforme. L’usage progresse rapidement au cours des premiers mois, passant d’une adoption marginale au lancement à un pic d’engagement autour du sixième mois, avant de se stabiliser à un niveau d’utilisation soutenu. Les développeurs les plus actifs contribuent également à une hausse notable du volume de code envoyé en production, une part substantielle du code livré transitant désormais par l’outil.
Concernant la revue de code, l’analyse statistique montre des améliorations nettes : le temps total de cycle des pull requests diminue de 33,8 %, tandis que le temps consacré spécifiquement à la revue baisse de 29,8 %, ce qui se traduit par un gain global d’efficacité d’environ 31,8 %. Pour la génération de code, une comparaison entre cohortes d’utilisateurs met en évidence un lien clair entre niveau d’adoption et gains observés. Les 30 développeurs les plus actifs voient le volume de code livré augmenter de 61 % après adoption de l’outil, avec une part importante du code généré effectivement acceptée en production. À l’inverse, les 30 utilisateurs les moins engagés enregistrent une baisse du volume de code livré et une utilisation quasi inexistante du code généré par l’outil.
L’étude conclut ainsi que les gains de productivité dépendent fortement de l’intensité d’utilisation : un usage limité ou sporadique ne produit pas d’effet mesurable, tandis qu’une adoption soutenue s’accompagne d’améliorations marquées.
L’analyse par niveau d’expérience montre également des effets différenciés : le volume de code livré augmente globalement après adoption, mais l’effet est particulièrement marqué chez les ingénieurs les plus juniors, tandis que les profils intermédiaires et seniors enregistrent des gains plus modérés. Une part significative du code généré par l’IA est acceptée par les développeurs et intégrée dans les flux de production, ce qui indique que l’assistance IA s’insère effectivement dans les pratiques de développement quotidiennes.
Ces résultats suggèrent que les bénéfices de productivité sont étroitement liés au niveau d’engagement avec l’outil, ce qui permet aussi de nuancer certaines études antérieures montrant des effets plus limités : l’impact dépend fortement de la manière et de l’intensité avec lesquelles l’outil est utilisé.
Impacts sur la qualité et perception des développeurs
Une enquête menée auprès des développeurs participants montre une perception globalement positive des outils, avec des résultats proches entre la génération de code et la revue assistée, cette dernière suscitant toutefois une intention légèrement plus forte de poursuite d’utilisation.
ne mesure complémentaire de satisfaction, fondée sur un indicateur de type Net Promoter Score, indique une appréciation positive mais mesurée des performances globales de la plateforme, suggérant que si l’outil est jugé utile, des marges d’amélioration restent perçues par les utilisateurs.
Retour sur investissement
Le coût estimé de la solution est d’environ 30 à 34 dollars par mois et par employé, ce qui permet aux auteurs de discuter la rentabilité potentielle de l’outil au regard des gains de productivité observés.
Enseignements opérationnels
Parmi les enseignements tirés du déploiement, les auteurs soulignent notamment que l’adoption efficace de ces outils nécessite un effort de formation et d’accompagnement plus important que prévu initialement. L’usage optimal des assistants de code ne se décrète pas : il suppose un apprentissage progressif et une intégration dans les pratiques de travail existantes.
Comme les auteurs l’indiquent : « This comparative cohort analysis provides strong evidence that DeputyDev’s productivity benefits are directly tied to engagement intensity, with high adoption yielding substantial improvements while minimal usage fails to generate meaningful outcomes. The clear inflection point observed around April 2025 deployment, combined with sustained divergence between cohorts, supports causal attribution of productivity gains to AI tool utilization rather than external factors. » (p.10) et « Training and Onboarding: Effective use of AI tools required more extensive training than initially anticipated » (p.12)
Evaluation critique de l’étude
Plusieurs points invitent néanmoins à interpréter ces résultats avec nuance. L’étude porte sur DeputyDev, un assistant de code IA développé en interne. Même si ses fonctionnalités (génération de code, aide à la revue) s’inscrivent clairement dans la famille des assistants de développement aujourd’hui disponibles, ses choix d’implémentation, son niveau d’intégration à l’environnement de travail et les modalités d’accompagnement peuvent être spécifiques au contexte étudié. Les enseignements restent donc très informatifs, mais leur transposition à d’autres outils ou à d’autres environnements peut dépendre de différences de configuration, d’usage et d’intégration.
Par ailleurs, l’analyse repose sur le déploiement de l’outil au sein d’une seule organisation, avec ses propres pratiques d’ingénierie, sa culture technique et son environnement organisationnel, ce qui limite la portée externe des conclusions. Enfin, la période d’observation reste relativement courte — environ un an — et ne permet pas d’évaluer les effets à plus long terme, notamment sur l’évolution des compétences, la qualité du code dans la durée ou la stabilisation des pratiques d’usage.
Cet article sera progressivement enrichi au fil de nos lectures !
Bibliographie
- Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arXiv preprint arXiv.09089.
- Kumar, A., Khare, V., Sharma, D., Kumar, S., Saini, V., Yadav, A., … & Edubilli, A. (2025). Intuition to Evidence: Measuring AI’s True Impact on Developer Productivity. arXiv preprint arXiv
