Cursor, l'éditeur de code avec IA et son vrai prix

Cursor est un fork de VS Code dans lequel un modèle de langage n'est pas une extension greffée sur le côté, mais une partie de l'éditeur lui-même. La différence se situe dans l'accès au contexte : l'assistant voit les fichiers ouverts, l'historique des changements, les résultats de recherche dans le projet et les erreurs du terminal, pas seulement le fragment que tu lui colles.

En juin 2026, l'entreprise derrière le produit, jusque-là connue pour un rythme de croissance de revenus record, a signé un accord de rachat par SpaceX dans une transaction entièrement en actions valorisée à soixante milliards de dollars, avec une clôture prévue pour le troisième trimestre. Deux jours plus tard, elle a racheté l'équipe de Continue et mis fin à ce projet open source.

Ce que change le passage d'une extension à un éditeur

La plus grande différence ne tient pas à la qualité du modèle, puisque les modèles sont les mêmes qu'ailleurs. Elle tient à la quantité de contexte qui atteint la requête sans ton intervention.

Une extension voit généralement le fichier courant et ce que tu sélectionnes. Un éditeur construit autour d'un modèle indexe le dépôt, donc une question sur l'endroit où sont gérés les paiements trouve une réponse sans que tu aies à fournir de chemins. Ça paraît mineur, et pourtant ça décide si l'outil répond à des questions d'architecture ou se contente de compléter des lignes.

La deuxième différence, c'est le travail sur plusieurs fichiers à la fois. Renommer un champ dans un type, corriger chaque utilisation de ce champ et mettre à jour les tests, c'est une seule instruction plutôt que vingt modifications séparées.

La troisième, c'est la boucle de retour. L'éditeur voit les erreurs du compilateur et les résultats des tests, donc il peut corriger son propre changement sans qu'un humain ne relaie le message.

Mode Auto et choix du modèle

La chose la plus importante pour la facture, et celle qu'on oublie le plus souvent. Le mode Auto choisit lui-même un modèle pour la tâche et, sur les forfaits payants, ne puise pas dans la réserve de crédits : il devrait donc rester le réglage par défaut.

Tu choisis un modèle à la main quand une tâche est difficile et que tu sais que le moins cher n'y arrivera pas. Tu te tournes alors vers un raisonnement plus puissant et tu paies depuis la réserve. L'ordre inverse, fixer le modèle le plus cher pour tout, est la cause la plus courante de mauvaise surprise sur la facture.

Le fournisseur développe aussi son propre modèle pensé pour le code, moins cher que les modèles de pointe à qualité comparable sur les tâches d'édition courantes. Teste-le sur ton propre dépôt, car les différences entre modèles dépendent fortement du langage et du style du projet.

La règle pratique : commence en mode Auto et passe à un modèle de pointe de façon délibérée, sur les tâches qui touchent de nombreux fichiers ou qui demandent de raisonner sur l'architecture.

Règles de projet

C'est la fonctionnalité la plus sous-estimée, et celle qui améliore le plus la qualité des suggestions. Les règles sont des fichiers du dépôt qui décrivent les conventions du projet, attachés automatiquement au contexte.

---
description: Conventions frontend
globs: ["src/**/*.tsx"]
alwaysApply: false
---

- Composants fonctionnels avec des props typées, pas de React.FC
- Stylisation uniquement avec des classes Tailwind, pas de styled-components dans le nouveau code
- Appels API uniquement via `src/api/client.ts`
- Pas de commentaires dans le code généré

Une règle associée à des chemins ne s'attache que lorsque tu travailles sur des fichiers correspondants, donc le contexte ne gonfle pas avec des règles qui ne s'appliquent pas pour l'instant. Trois modes d'attachement valent la peine d'être compris, car les mélanger est la cause la plus courante de règles qui ne se déclenchent jamais.

alwaysApply: true          # toujours dans le contexte, à utiliser avec parcimonie
globs: ["src/**/*.tsx"]    # seulement en travaillant sur des fichiers correspondants
description: "..."         # le modèle décide seul s'il y recourt

Une règle réglée sur toujours s'applique entre dans chaque requête, donc trois règles de ce genre, de cent lignes chacune, consomment le contexte avant même que le modèle ne voie ton code. Une règle avec une description et sans glob est parfois ignorée, car la décision de l'utiliser appartient au modèle.

Une bonne règle dit ce qu'il ne faut pas faire, pas seulement ce qu'il faut faire. Un modèle se tourne par défaut vers les solutions les plus populaires plutôt que vers celles que tu as adoptées, donc la différence entre deux formulations du même principe peut être considérable.

Faible :
- On écrit du code propre et lisible

Mieux :
- On n'utilise pas moment.js, le nouveau code utilise date-fns
- On n'appelle pas fetch directement dans un composant, seulement via src/api/client.ts
- On n'ajoute pas de nouvelle dépendance sans demander
- Les tests sont écrits pour le comportement, pas pour l'implémentation

La première formulation ne change rien, puisque le modèle croit déjà écrire de façon lisible. La seconde lui retire des choix précis qu'il aurait sinon faits de son propre chef.

Garde les règles dans le dépôt plutôt que dans les réglages de l'éditeur. Elles s'appliquent alors à toute l'équipe et passent en revue comme n'importe quel autre code.

.cursor/rules/frontend.mdc
.cursor/rules/api.mdc
.cursor/rules/tests.mdc
.cursorignore

Ce dernier fichier a un rôle différent : il exclut des chemins nommés de l'indexation. Les répertoires de dépendances, le code généré et les fixtures de test ne font que diluer la recherche, et les fichiers contenant des secrets ne devraient jamais atteindre l'index.

node_modules/
.next/
dist/
*.generated.ts
.env*
infra/secrets/

Travailler sur plusieurs fichiers à la fois

Le mode agent applique des changements dans tout le projet, lance des commandes et lit leurs résultats. C'est la partie la plus puissante de l'outil, et la plus risquée.

Trois habitudes séparent un travail utile du nettoyage qui suit. La première, c'est un dépôt dans un état propre avant de commencer, pour que les changements du modèle restent distinguables des tiens et s'annulent en une seule commande. La deuxième, ce sont des tâches de la taille d'un seul commit, car un agent à qui l'on demande de reconstruire la moitié d'une application produit un diff que personne ne relira. La troisième, c'est la relecture des changements avant de les accepter, exactement comme pour le code de quelqu'un d'autre.

Limite aussi les autorisations d'exécution de commandes. Un agent qui lance tout ce qu'il juge nécessaire finira par exécuter une migration de base de données ou une commande qui supprime des fichiers. Une liste de commandes exigeant une confirmation règle ce problème sans retirer son utilité à l'outil.

Tarifs

La facturation annuelle réduit le tarif d'environ un cinquième, ramenant le forfait de base à environ seize dollars par mois. Le forfait d'équipe a changé en juin 2026, avec des limites relevées et l'ajout d'un palier de postes séparé pour les personnes qui s'appuient fortement sur les modèles de pointe. Deux paliers de postes dans une même équipe, c'est un point à noter pour la planification d'un budget : les deux personnes qui confient des tâches à l'agent toute la journée obtiennent les postes plus chers, tandis que le reste de l'équipe reste sur les postes de base, au lieu d'augmenter le tarif pour tout le monde. Le palier le plus haut est facturé au cas par cas, sans tarif dans la grille de prix.

Trois choses déterminent si tu restes dans les limites du forfait. La première, c'est la part de ton travail quotidien qui tourne en mode Auto, puisqu'il ne puise pas dans la réserve. La deuxième, c'est la longueur du contexte : travailler avec vingt fichiers ouverts coûte bien plus cher qu'avec trois. La troisième, c'est la répétition de tâches que le modèle ne comprend pas par manque de règles de projet, si bien que le même changement part trois fois vers le modèle.

Le contexte, ou comment le modèle sait ce que tu demandes

La qualité de la réponse dépend presque entièrement de ce qui a atteint la requête. Ça vaut le coup de connaître les voies par lesquelles le contexte y entre, car chacune se comporte différemment.

Nommer un fichier ou un répertoire attache son contenu directement. C'est la voie la plus fiable, à utiliser quand tu sais où se trouve le cœur du problème. Référencer les changements du dépôt attache le diff courant, ce qui convient pour demander une relecture de ton propre travail avant de valider.

La recherche dans le projet tourne sur l'index et convient aux questions exploratoires, quand tu ne sais pas où chercher. Elle est moins fiable dans les grands dépôts, car elle renvoie des fragments proches par le sens, pas forcément les bons.

Référencer de la documentation externe récupère une page et l'ajoute à la requête. Ça résout le problème le plus courant avec les bibliothèques dont l'interface a changé après la date de coupure des connaissances du modèle.

La conclusion pratique va à l'encontre de l'intuition : plus de contexte ne veut pas dire mieux. Vingt fichiers ouverts distraient le modèle et coûtent bien plus cher que les trois bons fichiers. Fermer les onglets inutiles avant une question difficile est l'une des choses les plus simples qui améliorent les résultats.

Travailler sur un grand projet existant

Les outils de ce genre donnent le meilleur résultat sur du code neuf, et on les utilise le plus souvent sur du vieux code. Quelques éléments font pencher cette balance favorablement.

Le premier, c'est une description du projet dans les règles : ce que fait l'application, quels sont ses principaux répertoires, et où se trouvent les points d'entrée. Sans cette connaissance, le modèle commence chaque tâche en devinant la structure.

Le deuxième, c'est formuler les tâches par référence à du code existant. Demander « ajoute la gestion des factures sur le même modèle que le module de commandes dans src/orders » donne des résultats conformes à la convention du projet, tandis que demander « ajoute la gestion des factures » donne du code de tutoriel.

Le troisième, c'est le travail incrémental. Dans un grand dépôt, une grosse instruction donne presque toujours un résultat pire que cinq petites, car chaque étape peut être vérifiée avant que d'autres ne s'accumulent par-dessus.

Le quatrième, ce sont les tests comme point de référence. Si le projet a des tests, l'agent peut les lancer après chaque changement et corriger ses propres erreurs. S'il n'en a pas, commence par écrire des tests pour la partie que tu comptes modifier.

Cursor face aux alternatives

Ces outils ne s'excluent pas, et de nombreuses équipes en font tourner deux à la fois : un éditeur pour le travail interactif et un assistant en terminal pour les tâches longues. Ce second outil est parfois le terminal lui-même : Warp a un agent intégré au shell et peut faire tourner des assistants CLI côte à côte, donc déboguer un déploiement ne demande aucun changement de fenêtre. La facturation s'y fait néanmoins en crédits aux tarifs de l'API, et le forfait gratuit ne contient aucune réserve de crédits, donc sans ta propre clé chez un fournisseur de modèle, les fonctionnalités agentiques sont payantes dès le premier jour. Le coût de cet arrangement est souvent plus bas qu'un seul forfait du plus haut niveau, car chaque outil fait ce pour quoi il est le moins cher.

Il existe un troisième mode de facturation, différent à la fois d'un abonnement et des crédits d'un fournisseur d'outil. Cline tourne comme une extension d'éditeur, mais facture directement ton propre compte API de modèle, sans aucun frais d'intermédiaire. Utilisé avec parcimonie, il coûte moins cher qu'un abonnement fixe ; sollicité toute la journée sur un gros contexte, il peut le dépasser plusieurs fois, et la facture n'apparaît que chez le fournisseur du modèle.

Plus loin sur le même axe se trouve OpenHands, où il n'y a aucun humain dans la boucle : l'agent reçoit une tâche, travaille dans un conteneur et revient avec un changement terminé. L'avantage sur le travail répétitif est évident, et le prix à payer aussi : sans validation de chaque étape, tu ne vois pas à quel moment l'agent est parti dans la mauvaise direction, et la facture de tokens grossit pendant tout le temps où il travaille, pas seulement quand tu regardes.

L'éditeur sous-jacent est une question séparée. Zed a été écrit depuis zéro en Rust avec son propre moteur d'interface, et la différence de fluidité se voit sur les gros fichiers. Le prix se paie dans l'écosystème : il n'a qu'une fraction des extensions disponibles dans l'éditeur sur lequel Cursor est construit, donc l'outillage pour un langage de niche ou un plugin interne à l'entreprise peut simplement ne pas exister.

En comparant, retiens que les différences entre ces outils sont plus petites que la différence entre les utiliser avec des règles de projet et sans. Le même modèle dans le même éditeur donne des résultats incomparables selon qu'il sait à quoi ressemblent les conventions de ton code. Donc avant de changer d'outil parce que les suggestions sont mauvaises, vérifie si le dépôt contient quoi que ce soit qui les décrit.

La deuxième chose qui vaut la peine d'être vérifiée avant de changer d'outil, c'est la façon de formuler les tâches. Des demandes générales donnent des résultats généraux, quelle que soit la qualité du modèle de l'autre côté.

Confidentialité et données de l'entreprise

Par défaut, le code atteint les fournisseurs de modèles, donc un déploiement en entreprise demande une configuration délibérée. Le mode confidentialité désactive la conservation du code côté service, et un fichier d'exclusion garde certains répertoires hors de l'index.

.env*
secrets/
**/*.pem
infrastructure/production/

Configure les exclusions dès le premier jour, car l'index se construit à la première ouverture du projet. Ajouter une règle plus tard ne rappelle pas ce qui est déjà parti.

Pour les données qui ne peuvent pas quitter ton infrastructure, aucun réglage ne remplace un modèle local. Le bon choix est alors un éditeur avec un modèle qui tourne sur tes propres machines, au prix de la qualité des suggestions. Le produit prêt à l'emploi dans cette niche est Tabnine, qui, en plus d'un déploiement en cloud privé, propose une variante entièrement coupée du réseau et ne conserve aucun code envoyé. Ça se paie au sens littéral : les forfaits individuels ont été retirés, et les tarifs démarrent à 39 dollars par poste et par mois avec un engagement annuel.

Erreurs courantes

La première, c'est de travailler sans règles de projet. Le modèle suggère alors des solutions populaires plutôt que celles adoptées dans ton code, et chaque suggestion demande une correction.

La deuxième, c'est de fixer le modèle le plus cher en permanence. Le mode Auto gère la plupart des tâches sans puiser dans la réserve, et la différence ne se voit que sur un raisonnement difficile.

La troisième, ce sont des tâches trop grosses pour l'agent. Un diff qui couvre quarante fichiers ne sera pas relu, donc il entre dans le dépôt sur la foi du modèle.

La quatrième, c'est l'absence d'état propre avant de lancer l'agent. Mélanger tes propres changements avec ceux du modèle veut dire démêler à la main une tentative ratée.

La cinquième, c'est l'indexation de répertoires contenant des secrets. Un fichier d'environnement dans l'index est une fuite qu'on ne peut pas annuler.

La sixième, c'est de traiter les tests générés comme une preuve de justesse. Un test écrit par un modèle pour du code écrit par un modèle confirme généralement ce que fait le code, pas ce qu'il devrait faire.

FAQ

Combien coûte Cursor ?

Le forfait gratuit permet d'essayer l'outil, et le choix typique pour le travail quotidien est le forfait à 20 dollars par mois. Les paliers supérieurs, à 60 et 200 dollars, augmentent la réserve d'usage des modèles de pointe. La facturation annuelle réduit le tarif d'environ un cinquième.

Cursor est-il meilleur que Copilot ?

Pour le travail sur l'ensemble d'un projet, généralement oui, car il voit plus de contexte et agit sur plusieurs fichiers à la fois. GitHub Copilot gagne sur le prix et sur le fait de rester dans ton éditeur habituel. Pour la simple complétion de code, la différence est légère.

Que signifie le rachat par SpaceX ?

L'accord a été signé le 16 juin 2026, avec une clôture prévue pour le troisième trimestre, sous réserve de l'approbation des autorités de régulation. Rien ne change immédiatement pour les utilisateurs, mais en planifiant sur plusieurs années, ça vaut le coup de supposer des changements possibles de tarifs et d'orientation produit, tous deux typiques après un changement de propriétaire.

Le code atteint-il les fournisseurs de modèles ?

Par défaut, oui. Le mode confidentialité limite la conservation du code côté service, et un fichier d'exclusion garde certains répertoires hors de l'index. Une exigence de localité totale demande un modèle qui tourne sur ta propre infrastructure.

Vaut-il le coup d'utiliser Cursor avec un assistant en terminal ?

De nombreuses équipes font exactement ça. L'éditeur convient au travail interactif et à la relecture des changements, tandis qu'un assistant en terminal convient aux tâches longues et au travail sur un serveur. Séparer les rôles coûte souvent moins cher qu'un seul forfait du plus haut niveau.

La documentation se trouve sur le site du produit, et la transaction a été couverte par TechCrunch.