Comment Cursor a produit en trois jours, pour 180 dollars, un prototype qui a divisé une équipe de développement

Dans une grande entreprise informatique, une expérience avec Cursor a vite tourné au débat sur ce qui compte le plus : la vitesse de livraison ou la maîtrise du code. Un architecte système a dépensé 180 dollars en trois jours et montré au métier un résultat cliquable, pendant que l'équipe passait trois mois à construire un module typé et couvert par des tests.

Trois jours contre trois mois

Tout a commencé comme un pilote ordinaire d'outil d'IA. L'équipe comptait cinq développeurs, et l'entreprise avait accepté de rembourser à chacun un abonnement Cursor à 20 dollars par mois. Au bout d'un mois, les chiffres semblaient rassurants : trois employés avaient dépensé 60 dollars à eux tous. Mais on a ensuite découvert que l'architecte système avait consommé 180 dollars en seulement trois jours.

Il a utilisé le mode Agent, chargé dans l'éditeur une maquette Figma, un ancien composant et un prompt textuel, puis n'a presque plus écrit de code à la main. Cursor générait lui-même les interfaces, lisait les erreurs du terminal, les corrigeait et relançait la compilation.

À l'autre bout, l'équipe a passé trois mois à construire son module selon les règles classiques. Elle disposait de TypeScript, de code review, de Storybook, de JSDoc et d'environ 300 tests unitaires avec une couverture d'au moins 85 %. Dans le même temps, l'architecte a obtenu un prototype cliquable plus riche en fonctions, mais en Vanilla JS et avec environ cinq tests.

Quand les deux versions ont été placées côte à côte, le métier n'a pas vu de la discipline d'ingénierie, mais deux rythmes de livraison : lent et fiable contre rapide et spectaculaire.

Pourquoi le prototype l'a emporté

La décision a été prise lors d'une réunion avec des analystes métier et la direction. Pour l'équipe d'ingénierie, sa version paraissait aboutie : elle respectait la stack et les standards, et n'importe quel développeur pouvait la maintenir. Mais, pour le métier, un autre critère a été décisif : un résultat visible tout de suite.

Le prototype de l'architecte se cliquait, se faisait défiler et pouvait être présenté comme un produit presque fini. Le module de l'équipe était meilleur à l'intérieur, mais moins impressionnant à l'extérieur, car l'essentiel de l'effort était allé aux fondations et non aux fonctions de démonstration.

«

Les tests, on pourra les ajouter plus tard, le marché n'attendra pas. »

Cette logique a marqué le point de rupture. L'équipe n'a pas voulu transférer son travail vers la solution de l'architecte : autre stack, quasiment pas de documentation et trop peu de vérifications. L'architecte, lui, estimait que ses collègues compliquaient le processus et perdaient du temps alors qu'une version fonctionnelle existait déjà.

Résultat : un même projet compte désormais deux solutions parallèles à la même tâche. Sur le papier, il y a des progrès, mais l'entreprise n'a plus d'architecture unique ; elle a un conflit entre vitesse, standards et responsabilité de la maintenance future.

Le revers de la vitesse de l'IA

Le principal risque de cette histoire n'est pas seulement la dette technique, mais ce que les auteurs appellent la dette d'IA. Dans la précipitation ordinaire, l'équipe sait au moins ce qu'il faudra réécrire plus tard. Ici, le problème est plus profond : le code est généré si vite que son auteur peut ne pas comprendre les détails de l'implémentation. Si un bug apparaît plus tard ou si une règle métier change, la maintenance devra de nouveau être confiée au modèle, en espérant qu'il reconstitue correctement le contexte et ne se mette pas à halluciner par-dessus du code déjà généré.

• Il n'y a ni stack ni typage communs sur lesquels l'équipe puisse compter
• Les tests et la documentation sont quasi absents, donc les changements deviennent moins prévisibles
• Le bus factor tend vers un : la maintenance dépend d'un seul auteur et du même outil
• Chaque nouvelle exigence accroît le risque de casser un code que personne ne comprend vraiment

Les auteurs du cas n'appellent pas à interdire Cursor. Leur conclusion est pragmatique : le problème ne vient pas de l'outil, mais de l'absence de règles avant le début du travail. Si l'équipe avait fixé à l'avance une stack obligatoire, un jeu minimal de tests et un format de revue pour le code généré par IA, la dispute aurait pu ne pas éclater. Cursor peut servir à accélérer la recherche de solutions, les brouillons et les prototypes, mais pas à remplacer la réflexion d'ingénierie. Sinon, le développeur cesse d'écrire un système et se contente de regarder le système s'écrire tout seul.

Ce que cela signifie

L'affaire Cursor montre que l'IA ne change pas seulement la vitesse du développement, mais aussi la politique interne des équipes. Dans ces débats, l'emporteront non pas ceux qui ont le modèle le plus puissant, mais ceux qui s'accorderont les premiers sur les limites : où un prototype rapide est acceptable, et où un code sans tests, sans typage et sans stack commune ne peut tout simplement pas être considéré comme terminé.