Cursor Build Live Apps : ce qui est livré, le prix et les limites

Le pari de Cursor avec Build Live Apps, lancé le 5 novembre, est simple : la plupart des applications ne dépassent jamais le stade de localhost. Après lecture du changelog, de la documentation et des premières questions d’utilisateurs, le verdict est assez clair : l’outil est convaincant pour des outils internes et des prototypes protégés par le SSO de Cursor, mais il n’est pas encore prêt pour des backends de production complexes ou soumis à de fortes exigences de conformité.

Ce que propose réellement Build Live Apps

Build Live Apps est un workflow d’agent cloud qui transforme une demande en langage naturel en application web déployée. Cursor a annoncé la fonctionnalité le 5 novembre 2026 dans son changelog. La documentation Apps décrit le même parcours : donner une consigne à l’agent cloud, prévisualiser le résultat dans un panneau, choisir une URL, passer les contrôles de sécurité, puis publier l’application sur un lien accessible en ligne.

La consigne doit être explicite : la documentation de Cursor recommande de demander à l’agent de construire une application. Le projet peut partir de zéro avec Cursor Origin, qui crée un nouveau dépôt, ou d’un dépôt GitHub existant que Cursor déploie. Seuls les agents cloud sont capables de construire des applications.

Si l’application a besoin de stockage, Cursor provisionne une base PostgreSQL. L’hébergement repose sur un compte dédié et isolé pour chaque utilisateur ou équipe. L’authentification des applications d’équipe passe par le SSO Cursor : les destinataires doivent donc se connecter à Cursor avant d’ouvrir l’application. Les utilisateurs d’un abonnement individuel peuvent aussi publier des applications publiques sans connexion obligatoire.

Plusieurs limites sont à garder en tête dès le départ. La prise en charge de GitLab est prévue, mais pas encore disponible. Les domaines personnalisés ne sont pas confirmés. Cursor indique que l’éditeur choisit un domaine unique et précise dans sa documentation que l’URL peut être modifiée ultérieurement, mais aucune des deux pages ne décrit de procédure pour associer son propre domaine.

Aucune page ne précise les frameworks, les runtimes, les régions d’hébergement, la version de Postgres, les sauvegardes, le comportement en cas de montée en charge, les quotas de bande passante, le nombre de connexions simultanées ou le SLA. L’hébergement est juridiquement distinct des services Cursor et fourni « en l’état » et « selon les disponibilités ». Cursor se réserve par ailleurs le droit de révoquer ou de suspendre un sous-domaine ou une application.

Publication : 4 contrôles obligatoires, complétés par une analyse IA

Rien n’est mis en ligne sans une publication déclenchée explicitement par l’utilisateur. Le simple fait de préparer l’application ne la rend pas accessible. Chaque publication passe par quatre contrôles obligatoires, qui restent actifs même si l’équipe désactive l’analyse IA distincte :

• Bloquer la publication si les fichiers de l’application contiennent une clé API ou un jeton d’accès.
• Bloquer les fichiers contenant des identifiants, comme les clés privées ou les clés de comptes de service.
• Exclure les fichiers .env du paquet publié.
• Retirer les source maps afin d’empêcher les visiteurs de reconstituer le code source original depuis le navigateur.

Si un contrôle échoue, Cursor affiche le problème. L’utilisateur peut alors demander à l’agent de le corriger, puis relancer la publication.

L’analyse de sécurité IA supplémentaire examine les fichiers de l’application et peut bloquer les problèmes graves avant la mise en ligne. Les administrateurs d’équipe peuvent ajouter des consignes propres à leur organisation dans le prompt d’analyse. Ces instructions peuvent ajouter des règles, mais pas supprimer ni affaiblir les contrôles intégrés de Cursor. Les administrateurs peuvent passer outre certains blocages de publication, mais pas ceux liés au code malveillant, aux secrets intégrés en dur ou aux identifiants exposés. Les modifications de ces paramètres apparaissent dans le journal d’audit de l’équipe.

Ce que le système ne garantit pas est au moins aussi important que ce qu’il détecte :

« Le problème, c’est que passer les contrôles de sécurité ne prouve pas que les bonnes personnes ont accès aux bonnes données. » — @0node0, utilisateur réel

Cursor cite les secrets et les identifiants exposés comme exemples. En revanche, Cursor n’affirme pas que chaque application bénéficie de tests d’autorisation, de vérifications des permissions au niveau des lignes, d’une couverture contre les injections SQL, d’une analyse des dépendances ou d’un examen de la logique métier. L’analyse publiée par TechRepublic le 6 novembre arrive à la même conclusion : il faut tester l’application avec plusieurs comptes disposant de niveaux d’autorisation différents. Le fait qu’un utilisateur authentifié puisse lire les données d’un autre n’est pas présenté comme un cas couvert par les contrôles.

Les trois questions qui reviennent : coût, alternative à Vercel et secrets

L’hébergement coûte-t-il plus cher ? Cursor n’a publié aucun tarif distinct pour l’hébergement ou la base de données. Build Live Apps ne dispose pas non plus d’un abonnement séparé : la fonctionnalité est incluse dans les forfaits payants qui donnent accès aux agents cloud. Les chiffres concrets proviennent du tableau tarifaire de TechRepublic, et non des pages produit de Cursor :

Cursor fonctionne avec une enveloppe hebdomadaire d’utilisation IA partagée (décryptage des forfaits par TechRepublic), mais ces pages ne donnent aucun volume de tokens, de requêtes ou de calcul par niveau d’abonnement. Les modèles tiers peuvent entraîner des frais supplémentaires (TechRepublic). Les limites liées à la base de données, au stockage, au trafic et à la concurrence ne sont pas précisées. Voyez donc les 30 $ comme un ticket d’entrée, pas comme le coût total d’exploitation, et vérifiez les quotas avant de confier une charge destinée à des clients à l’hébergement intégré.

Build Live Apps peut-il remplacer Vercel ? Pas encore pour les backends de production complexes ou soumis à des exigences de conformité. Le parcours intégré convient à une application avec Postgres, SSO et lien de partage. Le parcours traditionnel, de GitHub vers Vercel, Netlify, Railway, Render ou un VPS, reste préférable pour les architectures personnalisées et les données réglementées ; le tableau ci-dessous détaille les cas de figure. Les discussions sur Reddit consacrées à l’hébergement reviennent au même critère : c’est le caractère stateful ou la durée d’exécution de la charge qui déterminent le bon hébergeur.

« La plupart des démos Cursor que je vois passer sur mon fil se concentrent sur l’interface… rares sont celles qui sont déployées pour de vrais utilisateurs payants. » — @mayowaoshin, utilisateur réel

Où sont stockés les secrets, et l’agent peut-il les voir ? La documentation de Cursor indique que l’agent de programmation ne voit jamais les valeurs des secrets. Les applications qui ont besoin d’un entrepôt de données ou d’une API externe demandent les secrets à l’utilisateur. Dans une équipe, les secrets sont généralement créés par un administrateur dans le tableau de bord Apps ou ajoutés ultérieurement depuis ce même tableau de bord.

Les administrateurs d’équipe peuvent voir chaque application de l’équipe ainsi que chaque secret associé. C’est un mécanisme de gouvernance, mais aussi une frontière de confiance à prendre en compte avant de coller des clés de production. Les clients automatisés, comme les scripts, les jobs CI et Grok Bot, accèdent aux applications protégées via une clé passée dans un en-tête (x-cursor-app-token), et non via des cookies ou des paramètres d’URL.

Utilisez le parcours intégré ici, gardez le parcours classique pour le reste

Le parcours classique conserve ses propres contraintes : configuration MCP, identifiants d’hébergement, variables d’environnement et renforcement des RLS. Le parcours de quatre semaines d’un développeur, de la landing page à Vercel puis à l’authentification Supabase, l’illustre bien.

Avant de partager l’application : checklist de préparation à la production

Les contrôles de Cursor repèrent les secrets et fichiers d’identifiants qui auraient fuité. Les risques restants concernent les permissions, la configuration de l’environnement, les effets asynchrones et le code que personne n’a lu. Passez cette liste en revue avant le premier partage, y compris pour un outil interne.

1. Repartez d’un environnement propre, puis lisez le diff. Demandez à l’agent d’exécuter le vrai build de production, pas le serveur de développement. Ouvrez chaque fichier modifié autour des paiements, de l’authentification et des écritures en base. Si le projet a déjà grossi au point que le diff n’est plus vérifiable, restaurez un point de contrôle et découpez la tâche au lieu d’ajouter des prompts par-dessus le désordre.
2. Testez les permissions avec deux comptes. Connectez-vous comme administrateur, puis comme membre restreint. Créez un enregistrement avec l’utilisateur A et tentez de le lire, de le modifier et de le supprimer avec l’utilisateur B. La réussite du rapport de sécurité ne prouve pas que la propriété des lignes est correctement protégée.
3. Vérifiez les secrets de bout en bout. Assurez-vous qu’aucune clé n’est intégrée au code frontend, qu’aucun fichier .env n’a été publié et que chaque identifiant externe dispose du périmètre minimal nécessaire. Retirez les URL directes des bases de production de l’environnement accessible à l’agent. Un témoignage sur r/cursor décrit un déploiement direct de Cursor vers Supabase en production, sans passer par GitHub.
4. Faites travailler les parcours asynchrones. Déclenchez un vrai webhook, rejouez-le et interrompez-le en cours d’exécution. Vérifiez le comportement du pool de connexions en cas d’utilisation simultanée. Les échecs silencieux de webhooks et les pools épuisés font partie des problèmes que des utilisateurs disent ne découvrir qu’après le lancement.
5. Définissez les mises à jour et le retour arrière. Identifiez qui peut publier, qui peut passer outre un blocage, qui peut dépublier et où se trouve le journal d’audit. Documentez la façon d’annuler une mauvaise publication et d’exécuter une migration de schéma : la documentation décrit la publication, mais pas l’historique des versions ni le rollback.

« Dès qu’une application quitte localhost, ses secrets l’accompagnent. » — @1PasswordDev, utilisateur réel à propos de l’isolation des secrets par application

Si l’une de ces étapes reste sans réponse — pas de projet de staging, pas de second compte de test ou pas de procédure de rollback, par exemple — gardez l’application sur un lien réservé à l’équipe ou sur la stack traditionnelle jusqu’à ce que le problème soit réglé.

FAQ

Build Live Apps nécessite-t-il un forfait Cursor payant ?

Oui. Build Live Apps fonctionne uniquement avec les forfaits payants qui activent les agents cloud. Le forfait Plus à 8 $/mois n’est pas éligible. Premium à 30 $/mois est le premier forfait individuel compatible.

Cursor peut-il construire une application depuis mon dépôt existant ?

Oui, depuis un dépôt GitHub existant ou en partant de zéro avec Cursor Origin. GitLab est prévu, mais indisponible pour le moment, et les agents locaux ne peuvent pas construire d’applications.

Une application d’équipe peut-elle être publique ?

Les forfaits Team et Enterprise désactivent le partage public par défaut. Un administrateur peut l’activer dans le tableau de bord Apps. Les forfaits individuels permettent de publier directement des applications publiques.

Cursor prend-il en charge les domaines personnalisés ?

Cursor indique que l’éditeur choisit un domaine unique et peut le modifier ultérieurement, mais ni le changelog ni la documentation ne confirment l’association d’un domaine personnalisé. Considérez donc que l’URL sera gérée par Cursor jusqu’à nouvel ordre.

Comment les scripts et les bots accèdent-ils à une application privée ?

Il faut créer une clé API Cursor et l’envoyer à chaque requête dans l’en-tête x-cursor-app-token. Les clés personnelles donnent accès à tout ce que leur propriétaire peut ouvrir. Les clés d’équipe ne permettent d’ouvrir que les applications d’équipe qui leur ont été explicitement attribuées.

Que se passe-t-il après la dépublication d’une application ?

Les administrateurs peuvent dépublier n’importe quelle application d’équipe. Désactiver les applications publiques ramène les applications déjà publiques à une visibilité limitée à l’équipe. Cursor ne documente ni la durée de conservation, ni les sauvegardes, ni l’export des données après une dépublication.

Build Live Apps supprime la configuration d’hébergement qui séparait jusqu’ici un prototype fonctionnel d’un lien utilisable. Il ne supprime pas le travail de revue, de test des permissions et de prise en charge qui détermine si d’autres personnes peuvent utiliser le résultat en toute sécurité.

À lire également : Meilleur LLM pour les agents de programmation en 2026 · Test de Cursor Projects Beta · Cursor Router expliqué