Étude : Cursor accélère le démarrage du développement, puis alourdit la dette technique de l'équipe

Une étude sur Cursor met en lumière un scénario peu réjouissant pour le marché de l'AI coding : l'outil accélère d'abord la production de code, puis la hausse de la complexité et la dette technique accumulée absorbent ce gain. Pour les équipes, c'est une mauvaise nouvelle non pas parce que l'IA serait inutile, mais parce que la vitesse locale masque facilement les coûts à venir.

Le coup de fouet initial

Les auteurs ont comparé 807 dépôts open source présentant des signes d'adoption de Cursor à 1380 projets similaires sans cet outil. Ils ont employé une approche de différences de différences (difference-in-differences) et ont examiné non pas le ressenti des développeurs, mais l'évolution des commits, des lignes de code et des métriques de qualité avant et après l'adoption. Le point compte : il ne s'agit pas d'un test de laboratoire sur une seule tâche, mais d'une tentative de comprendre comment un assistant d'IA se comporte dans des bases de code réelles.

Au départ, l'effet est convaincant. Le premier mois après l'adoption, le nombre de commits a augmenté de 55,4 % et le volume de lignes ajoutées de 281,3 %. Le deuxième mois, la hausse persistait, mais nettement plus faible : les commits ont progressé de 14,5 % et les lignes de 48,4 %. Ensuite, les chercheurs n'ont plus observé d'avantage durable. Autrement dit, Cursor peut bel et bien faire grimper rapidement la production, mais ce coup d'accélérateur ne se traduit pas par une accélération stable du développement sur la durée.

Le prix de la vitesse

Parallèlement à la vitesse, l'étude a relevé une montée des problèmes dans la base de code. Le nombre d'alertes d'analyse statique a augmenté de 29,7 % après l'adoption de Cursor, et la complexité globale du code de 40,7 %. La densité de duplication de lignes, elle, n'a pas connu de bond significatif. La conclusion est importante : il ne s'agit pas seulement, ni même principalement, de copier-coller, mais d'un système qui devient plus lourd, plus embrouillé et plus coûteux à maintenir.

Pour une équipe, cela implique généralement plusieurs choses :

• la revue demande plus de temps face à de gros changements générés par l'IA
• les tests et les linters détectent davantage de problèmes après la génération, et non avant
• les décisions d'architecture se prennent trop à la légère et atteignent plus vite la branche principale
• un code pratique localement se lit moins bien et se modifie plus difficilement après quelques semaines

C'est pourquoi les auteurs parlent d'un cycle qui s'auto-entretient. Cursor accélère la production de code, la dette technique grandit avec elle, puis cette dette se met à freiner concrètement les changements suivants. Si une équipe a des revues faibles, un refactoring rare et une couverture de tests insuffisante, le gain des premières semaines se mue assez vite en nouvelle source de ralentissement. Le goulot d'étranglement se déplace : écrire du code devient plus facile, mais le comprendre, le vérifier et le simplifier devient plus difficile.

Les réserves

L'étude ne doit pas être lue comme un verdict définitif. Les auteurs ont considéré qu'un dépôt avait adopté Cursor si des fichiers comme .cursorrules ou un dossier .cursor apparaissaient dans son historique. C'est un indicateur indirect utile, mais grossier. Il ne dit pas à quel point l'équipe a réellement utilisé l'outil, qui l'a utilisé, ni si Cursor a servi au développement principal plutôt qu'à de petites retouches ou à la documentation. Cela limite la portée de la conclusion causale.

Il y a une seconde réserve : la qualité a été évaluée avec les métriques de SonarQube, dont les alertes d'analyse statique et la complexité cognitive. Ces indicateurs sont utiles, mais ils ne mesurent pas toute la réalité de l'ingénierie. Ils perçoivent moins bien le couplage architectural, l'éparpillement de la logique métier entre les couches et le coût réel de la maintenance. La conclusion honnête est donc la suivante : l'étude ne prouve pas que chaque commit d'IA dégrade le code, mais elle met en évidence, avec assurance, un schéma inquiétant à l'échelle des projets.

Ce que cela signifie

Pour les entreprises et les équipes d'ingénierie, ce n'est pas un argument contre l'AI coding en tant que tel, mais un signal pour repenser le processus autour de lui. Si Cursor n'est utilisé que comme accélérateur de génération, sans revue plus stricte, refactorings rapides et quality gates renforcés, un bref pic de vitesse tourne facilement à la dette technique. La leçon principale est simple : l'IA supprime la friction à l'écriture du code, mais elle n'annule pas le coût des mauvaises décisions et ne rend pas la maintenance gratuite.