Utiliser Cursor

Cursor acceptera volontiers une demande d'une ligne et réécrira une douzaine de fichiers en un seul tour. Cette rapidité est le but, et c'est aussi exactement là où ça se gâte. L'agent ne comprend pas votre intention. Il prévoit des modifications plausibles à partir de ce qui se trouve dans son contexte, et plausible est le genre dangereux, car un code plausible compile, se lit bien, et fait tranquillement la mauvaise chose.

Imaginez la version coûteuse. Un développeur ouvre le chat de l'Agent et tape « nettoyez le flux d'inscription et corrigez la validation ». Pas de plan, pas de fichiers joints. L'agent cherche dans l'index, décide que le flux d'inscription inclut les utilitaires de formulaire partagés, et les refactorise aussi. Il renomme une prop utilisée dans quatre autres formulaires, met à jour ceux qu'il a trouvés, et manque les deux qu'il n'a pas. La différence est de 340 lignes à travers neuf fichiers. Le développeur la parcourt, voit des tests verts (l'agent ne les a pas touchés), et accepte l'ensemble complet. Deux jours plus tard, une autre page d'inscription génère une erreur à l'exécution, et maintenant la cause est enfouie dans un gros commit accepté que personne n'a lu attentivement.

Rien de tout cela n'est un échec de Cursor. C'est l'absence des trois leviers. Le développeur n'a fourni aucune limite de contexte, n'a pas convenu d'un plan, et n'a pas examiné la différence fichier par fichier. Chaque levier correspond à une surface intégrée de Cursor : les règles et les mentions @ pour le contexte, le mode Plan pour le plan, et la différence par fichier mise en scène plus les points de contrôle pour l'examen. L'avantage de les utiliser est concret. Les ingénieurs de Cursor rapportent que la plupart des nouvelles fonctionnalités commencent maintenant avec l'agent écrivant un plan, et que la discipline améliore significativement le code généré. Le mécanisme derrière chaque levier est ce que la section suivante décompose.

Cursor est VS Code avec une boucle d'agent intégrée. L'agent lit, recherche, édite et exécute des commandes à chaque tour, et les surfaces que vous contrôlez se trouvent à chaque étape de cette boucle.

• L'index. Lorsque vous ouvrez un espace de travail, Cursor divise le code en morceaux (fonctions, classes, blocs), convertit chacun en un vecteur d'intégration et les stocke pour que l'agent puisse rechercher par signification. L'indexation démarre automatiquement et la recherche sémantique devient disponible à 80 % de complétion. L'agent combine cela avec un simple grep, ce qui permet de répondre aux questions sur la base de code environ 12,5 % plus précisément que le grep seul, avec le plus grand gain sur les dépôts de plus de 1 000 fichiers.
• @-mentions. @Files et @Folders épinglent le contexte exact dans le prompt, @Code extrait un extrait spécifique, et @Codebase recherche dans tout l'index. L'épinglage est la façon de corriger une mauvaise supposition de récupération avant qu'elle ne se produise.
• Règles. Les fichiers .mdc sous .cursor/rules/ portent vos conventions. Chacun a un en-tête avec trois champs : alwaysApply, une description pour une sélection intelligente, et globs pour la correspondance de fichiers. Cela donne quatre comportements : Toujours (chaque chat), Auto Attaché (lorsqu'un fichier correspondant est dans le contexte), Demandé par l'agent (l'agent le récupère par description) et Manuel (vous le mentionnez avec @).
• Mode Plan et Agent. Le Mode Plan est uniquement pour lire et rechercher; l'Agent est le mode qui écrit et exécute.
• Points de contrôle. Cursor prend un instantané de l'état avant chaque opération de l'Agent, et les modifications sont mises en scène comme un seul diff avec acceptation et rejet par fichier.

La distinction qui décide du succès est Mode Plan versus sauter directement à l'Agent. Le Mode Plan recherche dans la base de code, pose des questions de clarification et produit un plan Markdown avec de vrais chemins de fichiers et une liste de tâches que vous pouvez éditer directement. Comme le dit Cursor, planifier oblige à réfléchir clairement à ce que vous construisez et donne à l'agent des objectifs concrets vers lesquels travailler. Pour une modification de routine sur un seul fichier, vous pouvez l'ignorer. Pour tout ce qui a plus d'une approche raisonnable, ou tout ce qui s'étend sur plusieurs systèmes, planifiez d'abord pour négocier l'approche en prose simple avant que tout code n'existe.

La deuxième distinction est objectifs vérifiables versus vagues. L'agent s'auto-corrige en fonction des signaux qu'il peut lire : un test échoué, une erreur de type, un avertissement de linter. Les conseils de bonnes pratiques de Cursor sont clairs : les agents ne peuvent pas corriger ce qu'ils ne connaissent pas, donc un langage typé, un linter et des tests donnent à la boucle une cible. "Rendre ça plus propre" ne lui donne rien à vérifier, et il déclarera la victoire sur une supposition. Avec les parties nommées, la section suivante montre un changement de bout en bout.

Maya, une développeuse sur une petite application web, doit ajouter une limitation de débit côté serveur au point de terminaison de connexion. Le dépôt a un module d'authentification dont elle se souvient à moitié et un dossier de middleware qu'elle ne connaît pas. Elle ouvre Cursor et résiste à l'envie de taper "ajouter une limitation de débit" dans l'Agent.

1. Définir le contexte. Elle attache ce qu'elle sait être important : @Files login.ts authMiddleware.ts et @Folders src/middleware. Cela épingle les vrais fichiers au lieu de faire confiance à l'index pour deviner quel "auth" elle veut dire.
2. Entrer en Mode Plan. Elle appuie sur Shift+Tab et écrit "Ajouter une limitation de débit au point de terminaison de connexion : 5 tentatives par IP toutes les 15 minutes, retourner 429 avec un en-tête Retry-After." L'agent pose deux questions de clarification : en mémoire ou avec Redis, et si les connexions réussies existantes doivent réinitialiser le compteur. Elle répond Redis et oui.
3. Lire et éditer le plan. L'agent écrit un plan Markdown touchant quatre fichiers, avec une tâche à faire pour ajouter un middleware rateLimiter.ts. Le plan propose également de modifier userRoutes.ts, ce que Maya ne veut pas changer, alors elle supprime cette tâche directement dans le plan et l'enregistre dans l'espace de travail sous .cursor/plans/.
4. Exécuter avec l'Agent. Elle passe à l'Agent et le laisse construire à partir du plan édité. Le diff en direct met en scène 78 lignes à travers trois fichiers. Le nouveau rateLimiter.ts semble correct; la modification de login.ts l'intègre proprement.
5. Vérifier contre un signal réel. Elle exécute la suite de tests plus un nouveau test ajouté par le plan pour le cas 429. Le test 429 passe, mais le linter signale une importation non utilisée laissée par l'agent. Elle accepte rateLimiter.ts et login.ts, rejette le changement erroné du troisième fichier et corrige l'importation elle-même.
6. Committer petit. Elle commit "ajouter une limitation de débit IP à la connexion (5/15min, 429 + Retry-After)" comme une étape révisable et réversible.

Le changement complet a pris un plan, une exécution et une révision ciblée. Parce que le plan était un artefact Markdown qu'elle a édité d'abord, l'agent n'a jamais approché userRoutes.ts, et parce que le diff était par fichier, elle a gardé les deux bons fichiers et éliminé le bruit. Maya passe aux pièges ci-dessous, où la même tâche montre comment chaque raccourci se brise discrètement.

Chaque piège donne l'impression de progresser sur le moment, ce qui est exactement pourquoi cela vous coûte plus tard.

• Sauter le plan sur un changement multi-fichiers. Aller directement à l'Agent sur une demande floue laisse l'agent décider de la portée pour vous. La solution est le Mode Plan pour tout ce qui dépasse un fichier évident, et éditer ses tâches pour éliminer le travail que vous n'avez pas demandé, comme Maya l'a fait avec userRoutes.ts.
• Faire confiance aveuglément à la récupération. L'index est une supposition, et il manque des fichiers qui sont renommés, nouveaux ou uniquement accessibles via des imports dynamiques. Lorsqu'un changement dépend d'un fichier spécifique, attachez-le avec @Files plutôt que d'espérer que la recherche le trouve.
• Le fichier .cursorrules obsolète. Le fichier unique .cursorrules est remplacé par .cursor/rules/ : une fois que des règles .mdc existent, elles prennent le pas sur lui, donc une équipe qui a migré à moitié voit l'agent briser des conventions qu'elle pense encore appliquées. Déplacez-les dans des fichiers .mdc ciblés sous .cursor/rules/.
• Accepter tout le diff d'un coup. Un gros "Accepter tout" est la façon dont une mauvaise modification se glisse à côté de neuf bonnes. Lisez par fichier et acceptez par fichier; rejetez tout ce qui devine l'intention.
• Lutter contre la dérive avec plus de prompts. Lorsqu'un tour dérape, empiler des instructions de suivi aggrave généralement le désordre. Restaurez le point de contrôle et affinez le plan, ce que Cursor recommande explicitement comme plus rapide et plus propre que d'itérer en cours de tour.

Deux véritables cas limites se cachent sous les règles. La sélection des règles est elle-même une supposition. Une règle Demandée par l'Agent ne se charge que si l'agent juge sa description pertinente, donc une description vague signifie que la règle ne s'applique pas silencieusement. Pour les conventions qui doivent toujours être respectées, définissez alwaysApply: true ou ciblez-les avec un glob précis plutôt que de compter sur la description.

Le piège de la révision de gros diff est une réalité en 2026. L'agent peut générer plus de changements qu'un humain ne peut soigneusement réviser, et les propres conseils de Cursor avertissent que plus l'agent travaille vite, plus votre processus de révision est important. Un diff de 400 lignes de l'agent qui semble raisonnable peut encore reposer sur une supposition que vous n'avez jamais vérifiée. Gardez les tours petits, préférez plusieurs plans ciblés à un seul plan global, et traitez la taille du diff comme un signal pour ralentir. Cette habitude ne fait que devenir plus difficile lorsqu'une équipe entière partage le dépôt, c'est là que l'échelle entre en jeu.

Un développeur solo peut garder les leviers en tête. Dès qu'une équipe partage le dépôt, les leviers doivent devenir des artefacts versionnés, sinon ils cessent discrètement de se produire et les habitudes de l'agent divergent selon les personnes.

L'artefact durable est le répertoire des règles. Versionnez .cursor/rules/*.mdc avec le dépôt pour que l'agent de chaque développeur lise les mêmes conventions, ciblées sur les bons fichiers par glob. Gardez chaque règle concise et ajoutez-en une seulement lorsque vous remarquez que l'agent répète la même erreur, ce que Cursor recommande comme discipline plutôt que d'écrire un fichier de règles géant dès le départ. Pour les conventions qui devraient également s'appliquer dans d'autres outils d'IA, un simple AGENTS.md à la racine fonctionne à la fois avec Cursor et Claude Code, et Cursor lit maintenant les fichiers AGENTS.md imbriqués pour qu'un sous-répertoire puisse porter ses propres instructions.

Les plans deviennent également un artefact d'équipe. Lorsqu'une fonctionnalité commence avec le Mode Plan, l'enregistrement dans l'espace de travail sous .cursor/plans/ transforme le plan en documentation révisable : un coéquipier peut lire l'approche avant que tout code n'atterrisse, et un futur agent reprenant le travail hérite du contexte. C'est la même habitude de planification que Cursor crédite pour un meilleur code généré, rendue partageable.

La révision est là où une équipe ressent la charge. Priya, une responsable de l'équipe de Maya, établit deux normes. Premièrement, gardez les PR de l'agent petites, idéalement sous 400 lignes, car la capacité de révision, et non le volume de code, est maintenant le goulot d'étranglement du travail assisté par IA. Deuxièmement, la description du PR enregistre que l'agent a écrit le changement, le plan qu'il a suivi et le prompt, pour qu'un réviseur lise le diff en sachant qu'il provient d'un prédicteur et puisse demander "sur quelle supposition repose-t-il ?" plutôt que "cela semble-t-il correct ?".

Le principe durable à garder, quelle que soit la taille de l'équipe : Cursor avance rapidement précisément parce qu'il prédit, donc votre travail est de maintenir les trois leviers stables. Fournissez le contexte, convenez du plan, révisez le diff. Commencez par une petite chose cette semaine. Déplacez vos conventions d'un fichier de configuration obsolète vers une règle .mdc ciblée, et voyez combien moins l'agent doit deviner.