Cursor Build Live Apps : Postgres, SSO et contrôles avant déploiement, ce que ça change pour un freelance

En une phrase : Le 5 novembre 2026, Cursor a ouvert « Build Live Apps » : un agent cloud peut créer une appli web, un Postgres et une auth SSO, puis publier un lien — pour un indépendant en France, la vraie question est le plan minimum, les garde-fous et ce que l'hébergement Cursor ne promet pas.

Cette actualité de la rubrique Freelances s'adresse aux développeurs indépendants et aux petites équipes qui utilisent déjà Cursor pour coder, et qui se demandent s'ils peuvent s'en servir pour mettre en ligne un outil interne sans passer par un autre hébergeur.

Ce que Cursor a annoncé le 5 novembre

Dans son changelog du 5 novembre 2026, Cursor décrit le problème : les agents ont baissé le coût d'écrire du code, mais « la plupart des apps et outils que les utilisateurs construisent ne quittent jamais localhost » (traduction Le Latent). La réponse s'appelle Build Live Apps : on décrit ce qu'on veut, l'agent cloud scaffold l'appli web, monte une base Postgres si besoin, configure l'authentification derrière le SSO Cursor, et provisionne l'hébergement. Au moment de publier, on choisit un domaine unique et on reçoit un lien en ligne.

La documentation Apps précise le mode d'emploi : il faut dire explicitement à l'agent qu'on veut construire une appli, et utiliser un agent cloud — « cette fonction n'est pas prise en charge en local ». On peut partir de zéro (nouveau dépôt sur Cursor Origin) ou déployer un dépôt GitHub existant. Le changelog ajoute que GitLab « arrive bientôt », donc pas encore.

Chez Cursor, des équipes ventes, opérations, juridique, finance et ingénierie construiraient déjà des outils internes (inscriptions d'événements, tableaux de bord commerciaux, portails de services), selon le même changelog. Ce sont des cas cités par l'éditeur, pas des mesures indépendantes.

Seuils de plan et partage : ce que dit la grille tarifaire

Le changelog et la doc affirment que Apps est « disponible sur tous les plans payants avec accès aux agents cloud ». La page Pricing de Cursor, consultée le 6 novembre 2026, montre où tombe ce seuil :

D'après la grille tarifaire Cursor consultée le 6 novembre 2026 (prix hors taxes), Free (0 $/mois) et Plus (8 $/mois) n'ont pas les agents cloud. Premium (30 $/mois), Super (100 $/mois) et Ultra (200 $/mois) les ont, tout comme Teams (à partir de 30 $ par utilisateur et par mois) et Enterprise (sur devis). Un freelance encore sur Free ou Plus n'a donc pas, d'après cette grille, l'accès aux agents cloud requis pour Apps.

Une fois l'appli publiée, trois niveaux de visibilité figurent dans la doc Apps :

Le partage public est désactivé par défaut pour Teams et Enterprise ; un administrateur peut l'activer. Sur un plan individuel, le partage public est prévu et « n'exige pas d'auth Cursor ». Pour un script ou un bot (la doc cite Grok Bot), une clé API Cursor se passe en en-tête HTTP x-cursor-app-token — pas en paramètre d'URL ni en cookie.

Contrôles avant mise en ligne, et ce qui reste hors promesse

Avant chaque publication, quatre contrôles déterministes tournent toujours, même si la revue de sécurité est coupée, selon la doc Apps :

1. bloquer les secrets écrits dans les fichiers de l'appli ;
2. bloquer les fichiers d'identifiants (clés privées, comptes de service, jetons) ;
3. ne jamais publier les fichiers .env ;
4. ne jamais publier les source maps.

S'y ajoute une revue de sécurité par IA. Les admins d'équipe peuvent ajouter leurs propres règles à cette revue, approuver une publication bloquée (sauf code malveillant, secrets en dur ou identifiants exposés), voir toutes les apps et secrets, et dépublier n'importe quelle app. Rien ne part en ligne tant que les contrôles n'ont pas passé et que tu n'as pas publié explicitement — point répété dans le changelog comme dans la doc.

Deux limites à lire telles quelles. D'abord, l'hébergement : chaque appli part dans un compte dédié isolé des autres équipes, mais la doc Apps écrit que l'hébergement est « séparé » des services Cursor, fourni « as is » et « as available », sans engagement de responsabilité sur tes apps. Ensuite, la localisation des données Postgres, le pays du compte d'hébergement et un éventuel SLA ne sont pas détaillés dans ces pages : pour un client français soumis au RGPD ou à une obligation de résidence des données, ce silence compte autant que les contrôles listés.

Pour qui ça vaut le coup, pour qui non

Ça colle si tu as déjà Premium (ou Teams), un besoin d'outil interne (tableau de bord, portail, microsite) et que le SSO Cursor suffit pour tes collaborateurs. L'intérêt n'est pas d'éviter d'écrire du code : c'est d'éviter d'enchaîner à la main Postgres, auth et hébergement pour un outil qui restait sur localhost.

Ça ne colle pas si ton dépôt est sur GitLab (pas encore supporté), si tu dois rester sur Free/Plus, ou si tu as besoin d'un contrat d'hébergement, d'une région EU explicite ou d'un contrôle total du runtime — cas où un hébergeur classique reste le chemin documenté. Les chiffres de performance, de coût d'hébergement Cursor et de quotas Apps ne figurent pas dans le changelog ni dans la doc consultés le 6 novembre 2026 : on ne les invente pas.

En résumé : Build Live Apps déplace la frontière du « ça tourne sur ma machine » vers « un lien partageable derrière Cursor », avec des garde-fous concrets et un plan minimum clair. Ce qu'il ne déplace pas, c'est ta responsabilité sur le contenu publié et le choix d'un hébergeur quand les exigences de conformité dépassent ce que Cursor documente au 6 novembre 2026.