Cursor AI : guide pratique pour développer avec l’IA

Cette différence a une conséquence pratique immédiate : la qualité de ce que produit l’outil dépend d’abord de ce qu’il a vu de votre projet. Un développeur qui obtient de mauvais résultats a rarement un problème de modèle. Il a un problème de contexte.

Comme l’écosystème évolue vite, ce guide s’en tient aux mécanismes stables — contexte, règles, mode agent, revue — et renvoie à la documentation officielle de Cursor pour tout ce qui touche à l’interface et aux fonctionnalités récentes.

Un modèle de langage travaille dans une fenêtre de contexte limitée. Votre dépôt fait plusieurs dizaines de milliers de lignes ; cette fenêtre n’en contient qu’une fraction à un instant donné. Cursor sélectionne donc ce qu’il envoie : fichiers ouverts, fichiers que vous référencez explicitement, résultats de recherche dans le projet, sorties de commandes.

Trois conséquences en découlent. D’abord, un fichier que vous n’avez pas mentionné peut être ignoré, même s’il contient la convention que vous vouliez voir appliquée. Ensuite, une conversation longue finit par être compressée : les éléments donnés au début perdent en précision. Enfin, plus vous envoyez de contexte inutile, plus la réponse se dilue — et plus elle coûte cher.

Le réflexe professionnel consiste donc à cadrer explicitement : désigner les fichiers de référence, indiquer où se trouve le code similaire déjà écrit, et recommencer une conversation propre quand le sujet change. Une session qui traîne depuis deux heures sur trois sujets différents produit des résultats plus faibles qu’une session neuve correctement cadrée.

Répéter à chaque demande « utilise TypeScript strict, pas de composant client inutile, nos tests sont en Vitest » n’a aucun sens. C’est le rôle des règles : des instructions persistantes, versionnées avec le dépôt, que l’outil applique à chaque génération. Cursor les lit dans le répertoire `.cursor/rules` du projet, et prend également en compte le fichier `AGENTS.md` devenu une convention partagée par plusieurs outils.

Une bonne règle est courte, impérative et vérifiable. « Écrire du code propre » ne sert à rien. « Les composants React de ce projet sont des Server Components par défaut ; ajouter “use client” uniquement en cas d’état local ou de gestionnaire d’événement » produit un effet mesurable dès la première génération.

Le contenu qui mérite d’être écrit une fois : structure du projet et rôle des répertoires, conventions de nommage, bibliothèques imposées et bibliothèques interdites, façon d’écrire les tests, commandes de build et de vérification, et ce qui ne doit jamais être modifié sans validation — migrations, schémas, fichiers de configuration sensibles.

L’ordre d’application compte lorsque plusieurs sources de règles coexistent : règles d’équipe, règles de projet et règles utilisateur se combinent, et la documentation officielle précise laquelle prime en cas de conflit. En pratique, mieux vaut éviter les contradictions plutôt que de compter sur cette hiérarchie.

C’est l’usage le plus sous-estimé, et probablement celui qui fait gagner le plus de temps à l’arrivée sur un projet existant. Plutôt que de demander une modification, demandez une explication : par où passe une requête d’authentification, quels fichiers sont impliqués dans le calcul d’un prix, où se trouve la logique qui produit ce champ dans la réponse d’API.

La méthode utile consiste à faire produire une carte avant de toucher au code : les fichiers concernés, l’ordre d’appel, les effets de bord. Vous vérifiez ensuite cette carte en ouvrant deux ou trois fichiers. En vingt minutes, vous obtenez une compréhension qui demandait une demi-journée de lecture.

La limite est réelle : l’outil décrit ce qu’il a lu, pas ce qui se passe en production. Il ne connaît ni la charge, ni les cas particuliers de vos données, ni l’historique des décisions. Une explication cohérente peut être partiellement fausse, notamment lorsqu’il existe du code mort qui ressemble au code actif.

Le mode agent est le changement de nature le plus important : au lieu de proposer un bloc de code que vous copiez, l’outil enchaîne des actions — lire des fichiers, en modifier plusieurs, exécuter des commandes, lire le résultat, corriger. Sur une tâche bien bornée, le résultat est impressionnant. Sur une tâche floue, vous obtenez vingt fichiers modifiés que personne ne veut relire.

La discipline qui fonctionne tient en trois points. Premièrement, faire produire un plan avant l’exécution et le corriger : c’est le moment le moins cher pour rectifier une mauvaise direction. Deuxièmement, borner explicitement le périmètre — quels fichiers peuvent être modifiés, ce qui est hors sujet, quelles commandes sont autorisées. Troisièmement, travailler sur une branche dédiée avec un état propre au départ, pour que le diff soit lisible.

Un point mérite une attention particulière : l’exécution automatique de commandes. Laisser un agent lancer les tests est utile ; le laisser exécuter n’importe quelle commande sans confirmation sur un poste connecté à des environnements réels ne l’est pas. Réservez l’exécution large aux environnements où une erreur reste sans conséquence.

Le refactoring mécanique — renommer un concept dans tout le projet, extraire un module, remplacer une bibliothèque par une autre, homogénéiser un pattern répété — est le terrain où le rapport gain/risque est le meilleur. La transformation est répétitive, le résultat attendu est clair, et les tests existants font office de filet.

Sur les tests, l’usage le plus fiable n’est pas « écris les tests de ce module » mais « voici les cas que je veux couvrir, écris-les ». Un modèle qui écrit à la fois le code et ses tests a une tendance documentée à produire des tests qui valident le comportement obtenu, y compris quand ce comportement est faux. Les cas limites doivent venir de vous.

Pour un bug, la demande efficace décrit les symptômes plutôt que la solution : comportement attendu, comportement observé, message d’erreur complet, contexte de reproduction. Demandez plusieurs hypothèses classées par probabilité, avec pour chacune la vérification à faire — plutôt qu’un correctif immédiat. Le premier correctif proposé traite souvent le symptôme.

Travailler avec un outil capable de modifier dix fichiers en une minute impose une hygiène Git plus stricte que d’habitude, pas moins. Partez toujours d’un état propre : un diff mêlant vos modifications manuelles et celles de l’agent est ingérable à relire.

Commitez court et souvent, avec des messages qui décrivent l’intention. Sur une tâche agentique longue, un commit par palier fonctionnel permet de revenir en arrière sans tout perdre lorsque la troisième étape part dans une mauvaise direction.

Enfin, relisez le diff en entier avant de pousser. C’est le point de contrôle non négociable : le volume de code généré ne change rien à la responsabilité de celui qui l’intègre au dépôt.

Trois limites structurelles méritent d’être connues avant un déploiement en équipe. La première concerne les données : le code envoyé au modèle quitte votre poste. Sur un dépôt soumis à des contraintes contractuelles ou réglementaires, la question doit être tranchée avec les réglages d’entreprise appropriés, avant l’usage et non après.

La deuxième concerne les dépendances et le code suggéré : un modèle peut proposer une bibliothèque inadaptée, obsolète, voire inexistante, ou reproduire un pattern de sécurité douteux vu ailleurs. Toute nouvelle dépendance doit être vérifiée comme si elle venait d’un inconnu — parce que c’est le cas.

La troisième est la plus insidieuse : la baisse de vigilance. Relire du code que l’on n’a pas écrit demande plus d’effort que d’en écrire, et la fatigue de revue s’installe vite. C’est ce qui explique que des équipes produisent davantage tout en dégradant leur qualité. Le rapport DORA 2025 sur le développement assisté par l’IA formule ce constat de manière plus générale : l’IA amplifie les forces et les faiblesses déjà présentes dans une équipe, elle ne corrige pas un processus défaillant.

Semaine 1 : utilisez Cursor comme un IDE et prenez l’habitude de désigner explicitement le contexte. Objectif : comprendre ce que l’outil voit.

Semaine 2 : écrivez vos règles projet, en partant des remarques que vous faites le plus souvent en revue de code. C’est le meilleur point de départ, parce que ces remarques décrivent déjà vos conventions réelles.

Semaines 3 et 4 : passez aux tâches agentiques, en commençant par du refactoring couvert par les tests, puis par des tâches de bout en bout sur une branche dédiée. À ce stade, la compétence qui fait la différence n’est plus la formulation de la demande, mais la relecture. C’est aussi l’étape où il devient utile de comparer avec les agents de coding en terminal, dont le paradigme diffère.