Les cloud agents Cursor construisent, hébergent et publient des apps live

Le 5 novembre 2026, Cursor a annoncé « Build Live Apps in Cursor » : les cloud agents peuvent scaffolder une app web, provisionner Postgres si besoin, placer l'auth derrière le SSO Cursor, provisionner l'hébergement, et renvoyer une URL partageable. L'entreprise pose le problème en une phrase — les agents ont facilité l'écriture de code, mais la plupart des apps ne quittent jamais localhost (changelog).

Le même parcours est documenté dans les docs Apps de Cursor. The New Stack (6 novembre 2026) indique que Vercel a déclaré sur X que la fonctionnalité repose sur Vercel for Platforms — le changelog Cursor ne nomme pas l'hébergeur.

Comment ça marche

On démarre un cloud agent et on lui dit explicitement qu'on veut construire une app. Les agents locaux ne sont pas pris en charge (docs).

Ensuite, Cursor (changelog, docs) :

• scaffold l'app web ;
• démarre une base Postgres si l'app en a besoin ;
• configure l'authentification derrière le SSO Cursor pour les apps privées et d'équipe ;
• provisionne l'hébergement dans un compte dédié et isolé par équipe ou par individu ;
• demande les secrets quand l'app doit se brancher sur vos systèmes (par exemple un data warehouse) — l'agent ne voit jamais les valeurs des secrets.

Quand l'app est prête, Cursor affiche un plateau de prévisualisation. Pour publier, on choisit un domaine / une URL unique. Cursor lance des contrôles de sécurité déterministes et agentiques ; rien ne passe en ligne tant que ces contrôles ne sont pas verts et qu'on n'a pas publié explicitement (docs).

On peut déployer depuis un nouveau dépôt (créé sur Cursor Origin) ou depuis un dépôt GitHub existant. Le support GitLab est annoncé comme à venir (changelog).

Contrôles de sécurité avant publication

Quatre contrôles tournent toujours avant chaque publish, même si la revue de sécurité IA est désactivée (docs) :

• bloquer les secrets écrits dans les fichiers de l'app ;
• bloquer les fichiers d'identifiants (clés privées, clés de compte de service, fichiers de tokens d'auth) ;
• ne jamais publier les fichiers .env ;
• ne jamais publier les source maps.

Par-dessus, une revue de sécurité IA lit les fichiers de l'app et peut bloquer des problèmes graves. Les admins d'équipe peuvent ajouter des règles de revue personnalisées dans le tableau de bord Apps ; ces règles peuvent ajouter des contraintes mais ne peuvent pas retirer les contrôles intégrés de Cursor (docs).

Les admins d'équipe peuvent aussi voir chaque app et chaque secret de l'équipe, dépublier n'importe quelle app, activer ou désactiver Apps, autoriser ou interdire les apps publiques et l'accès par clé API, et approuver des publishes bloqués par la revue — sauf code malveillant, secrets en dur ou identifiants exposés (docs).

Partage et accès API

Après publication, on partage avec (docs) :

• des personnes ou groupes précis (connexion Cursor) ;
• toute l'équipe (connexion Cursor) ;
• en public, sur les plans individuels.

Le partage public est désactivé par défaut pour Teams et Enterprise ; un admin d'équipe peut l'activer. Interdire le public ramène les apps publiques existantes en visibilité équipe (docs).

Les apps privées et d'équipe sont derrière la connexion Cursor, que les scripts ne peuvent pas franchir. Des clés API Cursor permettent à Grok Bot, à des scripts ou à la CI d'appeler une app comme un utilisateur connecté, via l'en-tête x-cursor-app-token à chaque requête — en-tête uniquement, pas de paramètre de requête ni de cookie (docs).

Hébergement sous le capot

Cursor déploie chaque app dans un compte dédié qu'il crée pour l'équipe (ou pour l'individu sur un plan individuel). Chaque compte d'hébergement est isolé de ceux des autres équipes et utilisateurs (docs).

The New Stack rapporte que Vercel a déclaré sur X que la nouvelle fonctionnalité repose sur Vercel for Platforms, ce qui permet de déployer sans créer de compte Vercel séparé ni configurer l'hébergement soi-même. Cette affirmation sur l'hébergement vient du reporting New Stack sur le post de Vercel, pas du changelog Cursor.

Pour qui, et disponibilité

Cursor liste des exemples internes déjà utilisés en sales, operations, legal, finance et engineering (changelog) :

• outils ops (inscriptions à des événements, assignations de comptes, places de bureau) ;
• présentations multimédia clients (slides, vidéo, démos interactives) ;
• formation, enablement et onboarding des nouvelles recrues ;
• tableaux de bord sales live et outils de pipeline ;
• portails pour gérer des services engineering.

La fonctionnalité est disponible sur tous les plans payants avec cloud agents activés (changelog, docs).

Pourquoi ça compte pour le vibe-coding et les surfaces IA

Le vrai changement, c'est le dernier kilomètre : le même cloud agent qui écrit l'app peut maintenant monter Postgres, le SSO Cursor, un hébergement isolé et une porte de publish avec des contrôles secrets/identifiants fixes. Pour les équipes déjà dans Cursor, cela retire un compte d'hébergement séparé et une checklist de déploiement manuelle pour beaucoup d'outils internes — avec les limites que Cursor publie lui-même (cloud agent uniquement, plan payant, contrôles admin pour le partage public et les clés API).

À mesure que plus de ce travail glisse dans des UIs d'agents et des écrans d'attente, les annonceurs continueront de tester ces surfaces comme n'importe quel nouveau canal : petit budget, créa claire, mesurer si les gens s'engagent vraiment. Idlen se place sur cette couche wait-time / native ads pour les produits IA ; Cursor Live Apps rappelle encore que la boucle build-and-share se raccourcit, et que les surfaces où l'utilisateur attend un agent vont continuer de se multiplier.

À retenir des matériaux Cursor : cloud agent uniquement, Postgres + SSO Cursor + hébergement isolé au publish, quatre contrôles de publish toujours actifs plus revue IA, partage public désactivé par défaut pour Teams/Enterprise, plans payants avec cloud agents, et (via New Stack) Vercel for Platforms sous le capot. À vérifier sur le changelog et les docs avant de s'en servir sur des données internes de production.