Cursor publie les applications créées par ses agents : ce qu'il faut regarder avant de s'en servir

Cursor est un éditeur de code construit autour d'agents IA. Jusqu'ici, ces agents écrivaient du code ; à l'équipe de se charger ensuite de l'hébergement. Depuis le 5 novembre 2026, l'éditeur prend aussi en charge la dernière étape : mettre l'application en ligne et la partager par un lien.

Ce que fait la nouveauté

Le constat de départ de Cursor est simple : les agents ont rendu l'écriture de code moins coûteuse, mais la plupart des petites applications ainsi produites ne quittent jamais le poste de leur auteur.

Le parcours décrit est le suivant :

• on lance un agent cloud en lui disant explicitement que l'on veut construire une application ;
• l'agent prépare l'application web, crée une base de données Postgres si nécessaire, place l'authentification derrière la connexion unique de Cursor et s'occupe de l'hébergement ;
• si l'application doit se brancher sur un système de l'entreprise, par exemple un entrepôt de données, l'agent demande les secrets (clés, mots de passe) dont il a besoin ;
• au moment de publier, on choisit un nom de domaine et on obtient un lien.

Cursor cite ses propres usages internes : outils d'inscription à des événements, tableaux de bord commerciaux, parcours d'accueil des nouveaux salariés, portails pour des services d'ingénierie.

Les garde-fous annoncés

Avant toute mise en ligne, Cursor indique lancer deux types de contrôles de sécurité, les uns fondés sur des règles fixes, les autres confiés à un agent. Ils cherchent des erreurs courantes, comme des secrets écrits en clair dans les fichiers. En cas d'échec, l'agent indique ce qu'il faut corriger. Rien n'est publié tant que les contrôles ne passent pas et que l'utilisateur n'a pas explicitement validé.

Les administrateurs d'équipe peuvent :

• voir toutes les applications et tous les secrets de l'équipe ;
• ajouter leurs propres règles à la revue de sécurité ;
• approuver une publication bloquée par la revue ;
• dépublier n'importe quelle application.

Le partage se fait avec des personnes précises, des groupes ou toute l'équipe, toujours derrière la connexion Cursor. Les offres individuelles peuvent aussi partager publiquement. Une clé d'API peut être créée pour qu'un script utilise l'application.

Disponibilité

La fonction est proposée sur toutes les offres payantes dont les agents cloud sont activés. Le code peut venir d'un dépôt neuf ou existant, hébergé sur Cursor Origin ou sur GitHub. GitLab est annoncé pour plus tard, sans date.

Ce que l'annonce ne dit pas

Plusieurs points manquent, et ce sont justement ceux qui comptent pour une entreprise française :

• la localisation des données : la page ne précise ni où sont hébergées l'application et sa base, ni où sont stockés les secrets ;
• le prix et les plafonds : aucun tarif, aucune limite sur le nombre d'applications ou la taille des bases ;
• la sortie : rien sur la façon de déplacer plus tard l'application vers un autre hébergeur ;
• la portée réelle des contrôles : une revue automatique repère des erreurs classiques, elle ne remplace pas un regard humain sur les droits d'accès et les données manipulées.

Notre lecture

Pour une PME, l'intérêt est réel sur un périmètre précis : de petits outils internes, sans données sensibles, qu'un salarié non développeur peut obtenir sans mobiliser l'équipe technique. Le risque est connu : une multiplication d'applications que personne ne maintient, branchées sur les systèmes de l'entreprise avec des secrets confiés à un tiers.

Avant d'ouvrir la fonction, trois vérifications s'imposent : demander à Cursor où sont hébergées les données, désigner un administrateur qui suit réellement la liste des applications et des secrets, et interdire par règle interne d'y placer des données personnelles tant que la question de l'hébergement n'a pas reçu de réponse écrite.