Cursor AI est-il sûr ? L’éditeur, le code et l’appli publiée

Vous avez construit quelque chose dans Cursor, ça marche, et vous êtes sur le point d’y mettre de vraies personnes. Quelque part dans cette semaine, vous avez tapé « cursor ai est-il sûr » dans un moteur de recherche, et ce qui est revenu, c’est une page sur les réglages de confidentialité de Cursor, une page sur la qualité du code écrit par une IA, et une page proposant des curseurs de souris personnalisés à télécharger. Aucune n’a dit un mot de l’appli que vous allez publier.

Voici ce que la plupart de ces réponses ratent : « Cursor AI est-il sûr ? », ce sont trois questions dans une seule phrase, et elles ont trois réponses différentes. Deux portent sur Cursor et les modèles derrière lui. La troisième porte sur ce que vous avez publié, et c’est elle qui décide si un inconnu peut lire les données de vos utilisateurs.

Voyez Cursor comme un entrepreneur que vous avez engagé pour bâtir une maison. S’il garde une copie de vos plans est une question. Si ce qu’il construit est aux normes en est une deuxième. Si les portes ferment à clé une fois que vous avez emménagé est la troisième, et elle reste votre question aussi longtemps que vous y habitez.

Cursor AI est-il sûr ?

En tant qu’éditeur, c’est un outil cloud ordinaire : un interrupteur de confidentialité, une page sécurité publiée et une attestation SOC 2 Type II. Cela répond à l’une des trois questions, et pas à celle qui décide si des inconnus peuvent lire les données de vos utilisateurs.

1. L’éditeur. Cursor garde-t-il votre code, s’entraîne-t-il dessus, le transmet-il à quelqu’un d’autre. C’est la copie des plans chez l’entrepreneur.
2. Le code. Ce que l’IA écrit est-il sûr. C’est la question de savoir si la maison est aux normes, et personne ne l’inspecte à l’entrée.
3. L’appli que vous avez publiée. Ce qu’un inconnu peut atteindre depuis la rue : une clé dans le code qu’un navigateur télécharge, une base de données qui répond sans connexion, un fichier qui n’aurait jamais dû avoir d’URL. Ce sont les portes.

Rien du côté de Cursor ne peut répondre à la troisième. Rien du nôtre ne peut répondre aux deux premières.

Cursor garde-t-il mon code ?

Le temps de vous répondre, oui. Ensuite, cela dépend d’un interrupteur.

Cursor est un outil cloud. Quand vous lui demandez quoi que ce soit, les parties pertinentes de votre projet quittent votre ordinateur, vont sur les serveurs de Cursor et sont transmises à un fournisseur de modèles (OpenAI, Anthropic, Google, selon le modèle choisi) pour être traitées. C’est ainsi que le produit fonctionne. Les plans doivent parvenir à l’entrepreneur.

Ce qui se passe ensuite, c’est l’interrupteur, et la page sur l’usage des données de Cursor met les deux positions dans un même paragraphe. Avec le Privacy Mode activé, « les données clients ne seront pas utilisées par Cursor pour l’entraînement » et Cursor « maintient des accords de rétention zéro (ZDR) avec tous les fournisseurs », c’est-à-dire que les entreprises qui font tourner les modèles s’engagent à ne rien garder non plus. Désactivé, Cursor « peut utiliser et stocker les données de la base de code, les prompts, les actions dans l’éditeur, les extraits de code et d’autres données et actions liées au code pour améliorer nos fonctions d’IA et entraîner nos modèles ».

L’interrupteur existe dans tous les forfaits, gratuit compris, et un administrateur d’équipe ou d’entreprise peut l’activer pour tout le monde et empêcher les membres de le désactiver. Le propre guide de durcissement de Cursor dit qu’il est activé par défaut sur les comptes Enterprise. Dans un forfait individuel, c’est un réglage, et ce réglage mérite d’être trouvé aujourd’hui.

Une chose de plus à son sujet, parce que quelqu’un s’y est déjà fait prendre. Depuis la mi-2025, il en existe deux versions : « Privacy Mode », qui laisse Cursor stocker certaines données pour des fonctions comme ses agents cloud et ses mémoires, et « Privacy Mode (Legacy) », qui ne stocke rien. En juillet 2026, un utilisateur sur Hacker News a raconté s’être connecté à l’appli iOS et avoir trouvé son compte basculé du réglage Legacy vers l’actuel. Un employé de Cursor a répondu que l’invite d’activation des agents cloud avait fait la bascule « sans dire clairement ce que cela signifiait ni que c’est difficile à annuler », et que revenir en arrière n’était pas possible dans l’appli. Si vous aviez choisi la plus stricte, vérifiez qu’elle est toujours sélectionnée.

Les certificats répondent à une question plus étroite qu’il n’y paraît. La page sécurité de Cursor liste une attestation SOC 2 Type II, ISO/IEC 27001 et ISO/IEC 42001. Elles signifient qu’un auditeur externe a vérifié que Cursor a des contrôles sur la façon dont il traite les données qu’il détient, comme l’attestation d’assurance d’un entrepreneur dit que l’entrepreneur est assuré. Elles ne disent rien du code qu’il écrit ni de l’appli que vous déployez avec.

Qu’envoie l’indexation du code ?

Un index de votre projet, conservé sur les serveurs de Cursor, avec les chemins de fichiers chiffrés et le code lui-même jamais stocké en texte lisible.

L’indexation est ce qui permet à Cursor de répondre à une question sur tout votre projet plutôt que sur le fichier ouvert. Il découpe vos fichiers en morceaux, les envoie sur les serveurs de Cursor pour en faire des embeddings (un résumé numérique de ce dont chaque morceau parle), et garde ces embeddings pour que, quand vous demandez « où gère-t-on les remboursements », il trouve les bons morceaux. La documentation de Cursor dit : « Les chemins de fichiers sont chiffrés avant d’être envoyés aux serveurs de Cursor. Le contenu du code n’est jamais stocké en clair. » Ce qui reste de leur côté est une carte de votre code, et c’est autre chose qu’une copie.

Deux choses valent d’être sues sur cette carte.

Certains fichiers sont exclus par défaut, et vous pouvez en ajouter. Cursor saute tout ce qui figure dans votre .gitignore et une liste par défaut qui comprend .env*, le fichier où vivent d’ordinaire vos clés secrètes. Un fichier .cursorignore à la racine du projet, écrit dans la même syntaxe que .gitignore, tient tout ce que vous y nommez hors de l’index et hors de ce qui est montré à l’IA.

Le terminal de l’agent ne lit pas cette liste. C’est la réserve qui compte pour les clés. La page sur les fichiers d’exclusion de Cursor dit que « les outils de terminal et de serveur MCP utilisés par l’Agent ne peuvent pas bloquer l’accès au code régi par .cursorignore », et qu’« une protection complète n’est pas garantie en raison de l’imprévisibilité des LLM ». Quand l’agent exécute une commande sur votre machine, il peut lire .env comme n’importe quelle commande le peut. Le fichier est hors de l’index et toujours à portée. Si une clé se trouve dans le dossier de projet que vous avez ouvert dans Cursor, traitez-la comme une clé que l’agent peut voir.

Le code que Cursor écrit est-il sûr ?

Pas par défaut, et c’est mesuré, même si la mesure porte sur les modèles que Cursor utilise et non sur Cursor lui-même.

Veracode, une entreprise qui vend des tests de sécurité du code, a fait passer plus de 150 modèles par les mêmes 80 tâches de programmation, dans quatre langages, chaque tâche offrant une façon sûre et une façon non sûre de faire le travail. Sa mise à jour de printemps 2026, publiée le 24 mars 2026, a trouvé que seuls 55 % des résultats étaient sûrs, un chiffre que Veracode qualifie de « pratiquement identique à celui d’il y a deux ans », tandis que la part qui compilait dépassait 95 %. Sur deux des quatre types de failles, les modèles n’ont presque jamais choisi la version sûre : le cross-site scripting, qui laisse le texte d’un visiteur s’exécuter comme du code dans le navigateur d’un autre, a été réussi 15 % du temps, et l’injection de logs 13 %.

Le propre résumé de Veracode est que les modèles « sont devenus excellents pour écrire du code qui compile. Ils ont échoué à écrire du code qui est sûr. »

Pour vous, la personne qui n’a pas écrit le code, l’écart entre ces deux nombres est tout le constat. Le test que vous faites sur un projet Cursor, c’est de savoir s’il fonctionne : vous cliquez à travers l’appli et les bonnes choses apparaissent. C’est le 95 %. Le test que personne ne fait, c’est de savoir si le code a décidé qui a le droit de voir quoi, et le 55 % dit que cette décision a été prise environ une fois sur deux. Une appli peut réussir entièrement le premier test et échouer au second, parce qu’une page qui vous montre vos commandes et une page qui montre à n’importe qui les commandes de tout le monde ont exactement la même allure pour la personne qui possède le compte.

Où cette décision doit vivre, et pourquoi « charge les commandes » ne la prend jamais tout seul, c’est le milieu du guide Cursor.

L’injection de prompt, en langage clair

Le modèle traite les instructions comme des instructions partout où il les trouve, y compris dans des choses qu’il était seulement censé lire.

Vous dites à Cursor « résume ce fil » ou « range ce fichier », et pour cela il lit le fil ou le fichier. Si le fil contient une phrase écrite pour ressembler à une instruction destinée à une IA, le modèle peut la suivre, parce qu’il n’a aucun moyen fiable de distinguer votre voix de celle de la page. C’est l’injection de prompt, et dans un agent de programmation, qui peut modifier des fichiers et exécuter des commandes sur votre machine, les conséquences vont au delà d’un mauvais résumé.

Deux cas nommés, tous deux contre Cursor. En mars 2025, Pillar Security a publié « Rules File Backdoor » : des instructions cachées à l’aide de caractères Unicode invisibles dans un fichier .cursor/rules, le fichier de configuration qui dit à Cursor comment vous voulez que votre code soit écrit. Le fichier paraissait propre dans l’éditeur et dans un diff GitHub, et il disait en silence à l’IA d’ajouter à chaque page générée un script venant du domaine d’un attaquant, et de ne jamais le mentionner. La réponse de Cursor a été que ce n’était pas une vulnérabilité de sa plateforme et que la responsabilité revient à l’utilisateur. En août 2025, Aim Security a révélé CVE-2025-54135, qu’ils ont baptisée CurXecute : un message dans un canal Slack public, lu par Cursor à travers un serveur MCP (une extension qui permet à l’agent d’atteindre des outils externes), pouvait amener l’agent à écrire une entrée dans sa propre configuration mcp.json, et Cursor lançait cette entrée, exécutant la commande de l’attaquant, avant que vous ayez approuvé la modification. Cursor l’a corrigée dans la version 1.3 le 29 juillet 2025, et chaque modification de ce fichier attend désormais votre approbation.

Ce qui en découle pour vous est court. Un fichier de règles que vous avez copié d’un dépôt ou d’un billet de blog est du code, et il oriente tout ce que l’agent écrit ensuite, alors lisez-le comme du code. Gardez Cursor à jour, puisque le correctif de CurXecute était un numéro de version. Et chaque serveur MCP que vous branchez et qui lit du texte venu de l’extérieur, une boîte de réception, une file de tickets, une recherche, remet à l’agent des phrases que vous n’avez pas écrites.

Ce qu’une analyse de 30 998 applis en ligne dit de la troisième question

Que rien de l’éditeur n’atteint l’appli que vous avez publiée. Nous ne savons pas distinguer depuis l’extérieur une appli faite avec Cursor d’une autre, et c’est cela, le constat.

Entre le 12 et le 14 août 2026, nous avons passé les neuf vérifications externes que n’importe qui peut lancer gratuitement sur notre page d’accueil sur 30 998 applis en ligne. Nous les avons trouvées par l’endroit où elles étaient publiées : 18 554 sur le domaine de Lovable, 5 438 sur celui de Base44, 3 042 sur celui de Replit, et ainsi de suite. Un projet Cursor se déploie là où vous le mettez, sur Vercel, sur Netlify, sur un domaine que vous avez acheté, et la page qu’un visiteur télécharge ne porte aucune marque de l’éditeur qui l’a écrite. Il n’y a donc pas de colonne Cursor dans le rapport, et il ne peut pas y en avoir.

Ce qu’il y a, sur chaque builder que nous avons mesuré, c’est la même courte liste de choses qu’un propriétaire a laissées ouvertes, et aucune n’est décidée par l’éditeur. Chaque part ci-dessous porte sur les applis pour lesquelles la vérification a répondu, parce qu’une vérification qui n’a pas pu aboutir est inconnue et non réussie. Aucune appli n’est nommée ici ni nulle part ailleurs chez nous.

La première ligne est mesurée sur les 3 680 applis qui nommaient un projet Supabase et dont la base de données a répondu à la question, d’où sa base plus petite ; ce que cette vérification lit et ne lit pas donne toute l’échelle. La cinquième ligne est celle qui coûte de l’argent à elle seule : une clé secrète OpenAI, Anthropic, AWS ou Stripe, ou une clé service_role Supabase, dans le code qu’un navigateur télécharge.

La dernière colonne est ce qui change avec Cursor. Sur le domaine propre d’un builder, deux de ces lignes appartiennent à l’hébergeur : les en-têtes sont envoyés par ce qui sert la page, et les source maps suivent les réglages de build du builder. Un projet Cursor, c’est votre dépôt, votre build et votre déploiement, si bien que chaque ligne de ce tableau est à vous, y compris les deux qu’un propriétaire Lovable ne contrôle pas. C’est plus de contrôle et plus à vérifier, et c’est pourquoi le guide Cursor passe son temps sur la sortie de votre build et votre base de données plutôt que sur l’éditeur. Le billet sur Replit pose les mêmes trois questions à une plateforme qui héberge l’appli et vous laisse en même temps livrer un serveur à vous.

La vérification de cinq minutes depuis l’extérieur

Utilisez une fenêtre privée pour les trois premières, afin que votre propre connexion ne réponde pas à la place d’un inconnu.

1. Ouvrez votre adresse publiée avec /.env à la fin, puis avec /.git/config. Les deux doivent échouer. Si l’une affiche du texte, faites tourner aujourd’hui chaque clé qu’elle contient, puis corrigez le déploiement pour que ce fichier ne soit jamais servi.
2. Ouvrez de la même façon l’une de vos propres routes d’API, une que vous ne voudriez pas voir lue par un inconnu. Si elle répond avec des données, cette route a besoin d’une vérification de connexion.
3. Ouvrez votre appli en ligne, puis l’onglet Sources des outils de développement de votre navigateur. Si vous pouvez lire vos fichiers d’origine avec leurs commentaires, les source maps sont activées dans votre build de production.
4. Si vos données sont dans Supabase, la moitié intérieure de la vérification est dans le guide Cursor : cherchez service_role et sk_live_ dans la sortie du build, puis ouvrez la page des politiques.
5. Ou laissez l’analyse s’en charger. Elle lance celles-ci et le reste des neuf depuis l’extérieur, prend une vingtaine de secondes, ne demande aucun compte et affiche « Impossible de vérifier » pour tout ce à quoi elle n’a pas pu répondre, plutôt qu’une coche : analysez votre appli.

Qu’est-ce qui change après le prochain push ?

N’importe quoi. Un projet Cursor part en ligne quand vous le poussez, et rien entre votre éditeur et internet ne relit l’appli à la recherche d’une route qui a perdu sa vérification de connexion, d’une clé collée à minuit pour passer un build qui échouait, ou d’une source map revenue avec un changement de configuration. Le chiffre de Veracode est la raison pour laquelle cela compte davantage ici que sur un builder : chaque session avec l’agent est du code neuf qui compile et n’est peut-être pas sûr, et une analyse faite le mois dernier décrit l’appli du mois dernier.

Reeve Monitor est construit pour cela. Il relance les neuf vérifications toutes les heures sur trois applis au plus, surveille la disponibilité toutes les 60 secondes, vous prévient quand un résultat change au lieu d’attendre que vous alliez voir, et envoie un rapport mensuel. Il coûte €12 par mois au tarif de base, avec sept jours gratuits avant de vous facturer ; la page des tarifs est parfois en dessous du chiffre donné ici et jamais au-dessus. Monitor surveille et rien de plus. Si votre appli Cursor garde ses données dans Supabase, Care est la formule qui conserve en plus une copie de cette base de données, et de vos fichiers téléversés une fois que vous connectez un identifiant Storage. Si les données vivent ailleurs, Monitor est la moitié qui convient.

À faire cette semaine

La moitié intérieure de tout cela, la sortie du build et la base de données, c’est le guide Cursor. La checklist de sécurité en 10 minutes couvre ce qui mérite d’être confirmé sur toute appli fraîchement lancée, quel que soit ce qui l’a écrite.