● Silicon.fr Télécom 📅 25/03/2026 à 12:09

Intelligence Artificielle 👤 Clément Bohic

🏷️ Tags : assistant ia cert chatgpt rte rust

Au nom de l’assurance qualité logicielle, les assistants de codage IA ont besoin de nouvelles formes d’autodiscipline. Des universitaires de Carnegie Mellon le postulent après avoir examiné l’impact de l’adoption de Cursor sur des projets open source. Leur analyse, conduite en août 2025, a fait l’objet d’un article publié en novembre et actualisé plusieurs fois depuis (dernière version : janvier 2026). Cette analyse s’inscrit dans une littérature foisonnante. En particulier, dans la lignée d’une étude ayant associé l’Université Queen’s (Canada) et le Collège doctoral de sciences et techniques de Nara (Japon). Des centaines de PR GitHub générés par Claude avaient été analysés pour déteminer leur taux d’acceptation. L’expérience menée à Carnegie Mellon est allée au-delà de cet indicateur. Elle a porté sur les effets « longitudinaux » au niveau des projets, à l’appui de métriques de vélocité et de qualité. Une analyse centrée sur Cursor et les projets open source L’usage de Cursor a été considéré exclusivement en mode agentique. Pour déterminer si des projets l’avaient adopté sous cette forme, les chercheurs se sont basés sur la présence de fichiers de configuration .cursorrules dans les dépôts GitHub. La date du premier commit touchant ces fichiers de configuration indique le début probable de l’adoption. Il en a résulté un échantillon de 806 repos ayant adopté Cursor « agentique » entre janvier 2024 et mars 2025. Y a été associé un groupe de contrôle de 1380 repos qui présentaient des caractéristiques similaires avant adoption. Dans chaque groupe, on s'assure de disposer d'au moins 6 mois d'historique avant et après adoption. On collecte, à intervalle mensuel, le nombre de commits et le nombre de lignes ajoutées. Ainsi que, à l'aide d'un serveur SonarQube Community local, trois indicateurs de qualité : Alertes d'analyse statique (nombre de problèmes de fiabilité, de « maintenabilité » et de sécurité) Taux de lignes dupliquées dans la codebase (SonarQube l'estime différemment selon les langages ; un bloc est généralement jugé ainsi s'il contient au moins 10 déclarations consécutives ou au moins 100 tokens doublonnés) Complexité de la codebase (niveau d'interprétabilité du code) Des gains en vélocité... sur les deux premiers mois L'adoption de Cursor engendre, pour reprendre les termes employés, un gain de vélocité « modestement important ». En tout cas si on se réfère au volume de code produit : environ 28,6 % de lignes en plus. Il n'y a en revanche pas d'effet net sur le volume de commits. Dans l'un et l'autre cas, les gains ne sont significatifs que dans les deux mois suivant l'adoption (+ 281,3 % de lignes le premier mois et + 48,4 % le second ; + 54,4 % de commits le premier mois et + 14,5 % le second). Sur l'aspect qualité, le volume d'alertes augmente en moyenne de 30,3 %. La complexité du code, de 41,6 %. Il n'y a pas d'effet significatif sur les lignes en double. Au contraire des gains de vélocité, ces hausses persistent au-delà de la période initiale d'adoption. À assistant IA, codebase plus complexe Sur l'ensemble des dépôts analysés, toutes choses étant égales par ailleurs, une augmentation de la vélocité de développement ne produit pas un effet significatif sur le volume d'alertes et la complexité du code. L'adoption de Cursor n'a pas un effet significatif sur le volume d'alertes. Lorsque celui-ci augmente, la taille de la codebase en est un déterminant majeur. Cependant, même en contrôlant cette dimension, l'effet de Cursor sur la complexité du code demeure important (+ 9 % en moyenne par rapport à des projets aux caractéristiques similaires qui n'utilisent pas l'assistant). En moyenne, là aussi toutes choses étant égales par ailleurs, un doublement de la complexité du code est corrélé à une baisse de 64,5 % du nombre de lignes. Tandis qu'un doublement des alertes est associé à une réduction de 50,3 % du nombre de lignes. L'adoption de Cursor entraînant une augmentation moyenne de 84 % des lignes ajoutées, le gain en vélocité serait complètement annulé par un triplement de la complexité ou par un quintuplement des alertes. Pour résumer, l'adoption de Cursor engendre une codebase intrinsèquement plus complexe, tandis que l'accumulation d'alertes et de complexité réduit la vélocité. Des résultats globalement indépendants du niveau d'utilisation de Cursor La méthodologie adoptée permet de détecter les traces de Cursor, mais pas la manière dont les projets s'en servent. Pour vérifier si leurs constats s'appliquaient autant aux repos utilisant Cursor de manière active qu'à ceux où l'engagement est minimal, les chercheurs ont élaboré un test. Ils ont identifié, sur chaque repo, les contributeurs ayant modifié les fichiers .cursorrules. Et calculé leur part de commits. Les repos où cette part était supérieure ou égale à 80 % ont été considérés comme « à forte adoption » de Cursor. Un deuxième ensemble a été constitué en isolant les commits ayant modifié ces fichiers post-adoption. Les résultats sur les deux ensembles accréditent les conclusions générales. Sur les repos où l'usage de Cursor est plus élevé, l'accumulation des alertes et de la complexité est plus importante. Sur ces mêmes repos apparaît également une augmentation de vélocité. Ce qui semble indiquer que l'abandon de Cursor après adoption annule au moins une partie des gains de vélocité. L'analyse a une autre limite : ellle ne tient pas compte de l'éventuel usage d'autres IA. Y compris des outils qui ne laisseraient pas de traces dans les repos, comme la version web de ChatGPT. Pour identifier ces repos, les chercheurs ont examiné la présence de certains éléments ; par exemple de dossiers .vscode. Sur les 806 repos du groupe principal, 382 sont concernés (345 avec GitHub Copilot, 63 avec Claude Code, 37 avec Windsurf, etc.). Entre ces repos et ceux n'ayant vraisemblablement eu recours qu'à Cursor, les principaux résultats persistent. Il sont même amplifiés sur les repos où l'usage antérieur d'outils IA est moins probable. L'hypothèse du cycle « excitation-frustration-abandon » L'effondrement des gains de vélocité après les deux premiers mois contraste avec les améliorations de productivité dont certaines études témoignent au niveau des tâches. Comme on l'a vu, l'accroissement de la vélocité est corrélé à l'accroissement de la taille de la codebase... et donc potentiellement de la dette technique. L'effet négatif de cette dette ne suffit toutefois sans doute pas à expliquer l'effondrement en question, suggèrent les chercheurs. Il faudrait effectivement, comme susmentionné, que la complexité triple - ou que les alertes quintuplent - pour annuler complètement le gain de vélocité, ce qui semble peu probable. Une autre explication plausible réside dans le cycle « excitation-frustration-abandon ». L'effet « tout beau, tout neuf » de Cursor et Cie pousserait à expérimenter sur les tâches où l'IA excelle, contribuant ainsi à la hausse de la vélocité. Mais lorsqu'on arrive sur des scénarios où l'IA est plus limitée, peut survenir de la frustration. Associée à la charge cognitive qu'induit la vérification de ce que produit l'IA, elle est susceptible de réduire l'usage des assistants de codage, voire d'en entraîner l'abandon. En tout cas au sein des projets open source, qui sont le point focal de l'analyse. Les chercheurs sont formels à ce sujet : il faut interpréter leurs conclusions dans le contexte de ces projets. Qui, par rapport aux projets d'entreprise, ont leurs spécificités. Notamment des niveaux de collaboration variables qui réduisent potentiellement les revues de code. Et des contraintes de ressources qui peuvent limiter les tests et l'assurance qualité indépendamment de la vitesse de développement. Des facteurs qui amplifient probablement le cycle excitation-frustration-abandon. Avec ou sans IA, aligner l'assurance qualité sur la vélocité L'analyse révèle une relation nuancée la vélocité de production du code et sa qualité. Si les niveaux absolus d'alertes augmentent après l'adoption de Cursor, l'effet est en grande partie attribuable à l'accroissement de la vélocité, qui elle-même accroît la taille de la codebase, qui elle-même accroît la dette technique. Si les assistants IA de codage permettent de produire du code plus rapidement, ils n'introduisent pas forcément davantage de problèmes de qualité qu'au sein des projets « sans IA » ayant la même vélocité. Une telle relation plaide pour un passage à l'échelle de l'assurance qualité en fonction de la vélocité. La complexité du code mérite une attention particulière, en ce qu'elle est distincte des problèmes de qualité. Elle augmente même en tenant compte des dynamiques de vélocité. Ce qui tend à prouver que le code que génère Cursor est intrinsèquement plus complexe que celui qu'écrit l'humain*. La dette créée peut en être d'autant plus lourde. Une autre raison potentielle du gain très éphémère de vélocité. Envisager un mécanisme de bridage Si l'adoption de Cursor n'engendre pas de changements importants sur la duplication des lignes, le phénomène est un peu plus net chez les « gros » utilisateurs de l'assistant. Pour le passage à l'échelle de l'assurance qualité, les chercheurs suggèrent notamment des sprints de refactoring déclenchés par l'atteinte de seuils. Ils estiment que ces seuils pourraient aussi guider le comportement des assistants. Lesquels pourraient, par exemple, se mettre à produire moins dès lors que la codebase franchirait un niveau de complexité et/ou de dette, forçant les développeurs à optimiser avant de continuer. De manière moins « agressive », ils pourraient aussi suggérer des tests et recommander des pistes de refactoring. * Cet écart tient peut-être aux objectifs d'entraînement des modèles sous-jacents. En l'occurrence, une priorisation de la réussite aux tests par rapport à la satisfaction des exigences non fonctionnelles comme la lisibilité du code. Illustration principale générée par IA

🔗 Lire l'article original 👁️ 1 lecture