Aller au contenu principal
Toutes les ressources
Méthodologie2 min de lecture8 août 2026

Mesurer le ROI de Cursor et Claude Code : 4 indicateurs qui tiennent

Oubliez les '70 % plus vite'. Cycle time, rework, revue, incidents. Quatre métriques pour savoir si l'IA accélère vraiment votre équipe.

« On gagne 30 % de temps » n'est pas un ROI. C'est un slogan. Les directions qui achètent une formation Cursor ou un coaching squad veulent savoir, à 30 et 90 jours, si le lead time a bougé, si la revue a tenu, si les incidents n'ont pas explosé.

Voici quatre indicateurs qu'on pose avant l'intervention. Pas après, quand on cherche un chiffre présentable.

1. Cycle time (commit → prod)

Pas les story points. Pas le nombre de PR. Le temps médian entre le premier commit d'une branche et le déploiement. Si Cursor accélère l'écriture et que la revue / la CI / les qa manuelles n'ont pas bougé, le cycle time ne bouge pas. Vous avez juste déplacé le goulot.

Mesurez 4 semaines avant, 4 semaines après. Même équipes, mêmes services. Un seul chiffre : médiane, pas moyenne (les outliers mentent).

2. Taux de rework

Part des PR qui reviennent en « changes requested » plus de deux fois, ou qui sont revert dans les 7 jours. L'IA augmente souvent le volume de diff. Si le rework monte, vous payez l'accélération en revue et en hotfixes.

Le piège du vibe coding se lit ici, pas dans un sondage « est-ce que tu te sens plus productif ».

3. Latence de revue

Temps médian avant le premier review humain. Si les PR gonflent, les reviewers saturent. Cursor n'a rien accéléré : il a transféré la charge. Un label ai-generated + une checklist de revue (secrets, tests, périmètre) diminue cette latence. C'est du process, pas de l'outil. Voir Cursor en équipe.

4. Incidents liés à du code récent

Bugs en prod dont le commit a moins de 14 jours, avant / après. Pas « tous les bugs ». Le sous-ensemble qui trahit une génération non relue : nil unchecked, mauvaises migrations, permissions trop larges.

Si ce chiffre monte, vous arrêtez d'élargir l'usage agent et vous revenez à l'autocomplete + revue stricte. La gouvernance sert à ça : un palier d'usage qu'on peut baisser, pas seulement monter.

Ce qu'on ne mesure pas

  • Tokens consommés. Coût réel, ROI non.
  • « Satisfaction » à chaud le vendredi de la formation. Elle est toujours haute.
  • Nombre de lignes générées. C'est un vanity metric, parfois inversement corrélé à la qualité.

Comment en faire un rituel

Une revue de 30 minutes, mensuelle, tech lead + un sponsor. Quatre courbes, une décision : on continue, on resserre les rules, on forme un sous-groupe qui décroche, on arrête l'agent sur un repo critique.

C'est le livrable de fin d'un Devcraft Audit : les quatre compteurs branchés sur votre outillage (GitHub, GitLab, Linear, Datadog — ce que vous avez déjà). On ne vous revend pas une plateforme de « AI productivity ».

Sans baseline avant, il n'y a pas de ROI après. Seulement des impressions. Les impressions ne passent pas un COMEX, et elles ne vous disent pas si Claude Code ou Cursor est le bon levier chez vous.

Passer de la lecture à la pratique ?

Devcraft — définir vos 4 indicateurs au cadrage