Avec Cursor, un tableau commercial devient une application. Qui est responsable du lien ?
Cursor Live Apps prend en charge l’hébergement, la connexion et, au besoin, Postgres. Un tableau de bord commercial et un portail d’intégration montrent ce qui reste à organiser dans l’équipe.
Le lundi matin, la responsable commerciale veut une seule page pour voir quels comptes demandent son attention. Les chiffres sont dans un tableur, les règles d’attribution dans un autre onglet, et chacun a une version légèrement différente du fichier. Un développeur peut monter un tableau de bord utile en un après-midi. La première question délicate vient lorsque la responsable demande le lien.
Anysphere, l’entreprise qui édite l’environnement de programmation Cursor, a lancé Live Apps le 5 novembre 2026. Vous demandez une application web à un agent cloud Cursor. Cursor peut préparer l’hébergement, la connexion et, si l’application en a besoin, une base Postgres. Après une revue de sécurité et une publication explicite, l’application dispose d’une URL accessible. La fonction est disponible dans les offres payantes où les agents cloud sont activés. Le code peut provenir d’un dépôt neuf ou existant sur Cursor Origin ou GitHub. Annonce de Cursor
Une application interne devient donc envisageable pour des tâches jusqu’alors gérées au moyen de copies de tableurs et de messages hebdomadaires. Le passage du prototype à un outil dont une autre personne dépend est tout aussi rapide. Un tableau de bord commercial et un portail d’intégration permettent de voir à quel moment le prototype est prêt et qui peut consulter les données, les modifier ou en couper l’accès.
Le bouton de déploiement termine une tâche et en ouvre une autre
Cursor demande de préciser qu’il s’agit d’une application et de passer par un agent cloud. Une session de programmation locale peut aider à travailler sur le code source, tandis que le parcours Apps décrit par Cursor passe par l’agent cloud. Un nouveau projet peut créer un dépôt sur Cursor Origin. Si l’équipe possède déjà une application dans un dépôt pris en charge, elle peut partir de ce code. Cursor met les ressources à disposition. La personne qui publie choisit l’URL et décide quand la partager. Configuration et déploiement d’une application
Du code source à l’URL accessible. Le public et la source de données sont représentés séparément. Illustration originale de Telli.sh.
Cursor décrit deux types de contrôle avant publication. Des vérifications déterministes repèrent des problèmes connus, comme un secret écrit dans un fichier. Une revue de sécurité par IA examine le code source pour y trouver des failles graves. Selon Cursor, les administrateurs peuvent ajouter leurs propres règles, voir les applications et les secrets de leur équipe et retirer des applications. Ils peuvent aussi autoriser certaines publications bloquées par la revue IA. Cursor maintient le blocage en présence de code malveillant, de secrets inscrits dans le code ou d’identifiants exposés. Le responsable de l’application doit toujours décider de quels identifiants celle-ci a réellement besoin. Annonce de Cursor · Sécurité et administration des applications
Imaginez une application dont l’accueil présente les totaux commerciaux et dont un point d’accès aux détails renvoie tous les comptes. La page peut paraître correctement limitée après la connexion d’une responsable commerciale. Un collègue pourrait pourtant ouvrir une URL de détail devinée ou demander au serveur les données d’un secteur invisible dans le tableau. La revue de déploiement peut repérer un défaut d’implémentation. La règle applicable aux secteurs reste celle de l’équipe, et le test de mise en service doit l’exercer avec les rôles concernés.
Ces décisions ont des conséquences dès que l’URL circule. Une fois le lien ajouté aux favoris, un rapport en panne peut retarder la réunion du matin. Si l’application devient le seul endroit où consigner une décision ou une validation, sa base de données entre dans le processus métier. Même une petite application a besoin d’une personne qui saura expliquer une anomalie dans les chiffres.
Commencer par un tableau de bord en lecture seule
Prenons une équipe chargée des opérations commerciales qui veut suivre ses opportunités dans deux secteurs. Une première application utile affiche le nombre d’opportunités par étape, la date de la dernière mise à jour et un lien vers la fiche CRM pour les détails. Elle fonctionne d’abord avec des comptes fictifs. Une fois l’affichage validé, son compte technique peut lire un rapport limité ou une vue de base de données qui contient uniquement les champs utiles au tableau de bord. Le CRM garde la responsabilité des attributions et des notes. La première version ne modifie ainsi aucune donnée métier, et une source indépendante permet de rapprocher les totaux.
La documentation Apps indique que les secrets d’accès à un entrepôt de données ou à une autre ressource externe peuvent être renseignés pendant la configuration ou depuis le tableau de bord Apps. Selon Cursor, l’agent ne voit pas leurs valeurs. Ils redeviennent déterminants quand l’application publiée envoie une requête. Conservez la connexion dans le code côté serveur, limitez les requêtes permises et inspectez la page livrée ainsi que ses réponses réseau pour repérer les champs qui devaient rester côté serveur. Un secret en lecture seule aide si le compte sous-jacent dispose effectivement de droits de lecture seuls sur les données voulues. Secrets dans Cursor Apps
| Décision pour la première version | Tableau des opportunités commerciales | Portail d’intégration des nouvelles recrues |
|---|---|---|
| Public visé | Groupe nommé des opérations commerciales | Salariés invités et responsables de l’intégration |
| Données de référence | CRM ou vue de rapport à accès restreint | Guide interne approuvé et liste des étapes d’intégration |
| État utile dans l’application | Filtres et préférences d’affichage | Étapes validées par la personne connectée |
| Contrôle avant partage | Rapprocher deux secteurs et essayer une URL de détail interdite | Vérifier que personne ne peut consulter ou modifier la liste d’un collègue |
| Responsable en exploitation | Opérations commerciales avec un contact de secours | Ressources humaines avec une personne responsable du contenu |
Testez le tableau de bord de trois points de vue. La personne attendue doit voir le bon total et l’heure de mise à jour. Un collègue d’un autre secteur doit voir seulement les lignes autorisées par l’application, même s’il modifie le lien ou la requête. Une personne exclue du partage doit être arrêtée avant de recevoir une seule donnée. La deuxième vérification est particulièrement utile, car le défaut est facile à manquer quand seul le développeur teste.
Effectuez le rapprochement à partir d’un instantané fixe du système de référence. Notez la période, le fuseau horaire, les critères d’inclusion et le total exact attendu pour chaque secteur. Un graphique qui semble oublier les opportunités du lundi peut simplement lire autrement la période du rapport. Testez dès le départ un résultat vide, un délai dépassé dans le système amont et un rafraîchissement trop ancien. L’heure de la dernière mise à jour réussie et un message d’erreur explicite permettent de distinguer une panne d’une véritable baisse du nombre d’opportunités.
Dans un portail d’intégration, chaque champ doit justifier la base de données
Un portail qui se contente de renvoyer aux procédures existantes peut se passer d’une nouvelle base. Une liste interactive doit conserver un état. Cursor peut fournir Postgres lorsque l’application en a besoin, ce qui facilite la construction de cette deuxième version. Avant de le faire, recensez ce qui doit réellement être conservé. L’identifiant d’une étape, l’heure de sa validation et un identifiant stable de la personne connectée peuvent suffire. Copier des notes managériales, un numéro de pièce d’identité ou l’adresse d’un salarié augmente le risque sans améliorer la liste. Ressources des applications Cursor
Séparez les données qui aident le salarié à suivre son parcours de celles qui servent à l’organiser. Une personne peut marquer comme terminée sa propre lecture obligatoire. Le responsable de l’intégration peut avoir besoin de voir les étapes en retard à l’échelle d’un groupe. Donnez une règle d’autorisation distincte à cette vue et examinez sa requête séparément. Un écran de connexion commun donne aux deux vues une apparence cohérente, alors que leurs besoins d’accès restent différents.
Trois contrôles d’accès distincts pour une même application interne. Illustration originale de Telli.sh.
Un pilote peut utiliser un salarié fictif et un compte de coordination de test avant de stocker de vraies données d’intégration. Définissez un test négatif clair qui conditionne la mise en service. Un salarié doit être incapable d’écraser l’état d’un collègue même en changeant un identifiant dans la requête du navigateur. Ensuite, vérifiez qu’un deuxième essai sur la même étape donne le même état sans créer de doublon. Le pilote rend ainsi le comportement observable sans demander à quelqu’un d’exposer de vraies informations.
Ce type d’application gagne à disposer d’une liste de points à transmettre. Précisez comment le nouveau responsable obtient l’accès, où le guide est modifié, qui peut révoquer les droits d’un salarié parti et ce qui advient des validations existantes. Décidez comment récupérer l’état utile si une modification échoue. Cursor peut fournir une base. L’équipe doit déterminer ce que restauration et conservation impliquent pour cette liste.
Une invitation et une clé d’intégration remplissent des fonctions différentes
La documentation actuelle de Cursor Apps distingue trois options de partage. Une application réservée aux invités peut être ouverte au propriétaire et à des personnes ou groupes connectés expressément désignés. Le partage en équipe peut l’ouvrir à toute l’équipe Cursor connectée. Une application publique est accessible à toute personne qui a l’URL. Dans les offres Teams et Enterprise, le partage public est désactivé par défaut jusqu’à ce qu’un administrateur l’autorise. L’annonce de lancement met en avant le partage public dans les offres individuelles. Une URL fonctionnelle dit donc peu du public réel tant que la visibilité n’a pas été vérifiée dans le tableau de bord Apps. Partage dans Cursor Apps
La même documentation décrit les clés API pour les requêtes automatisées. La clé est transmise dans un en-tête HTTP et la requête est identifiée comme automatisée, sans être rattachée à une personne. C’est utile si un script doit appeler l’application. Cela change aussi la manière d’examiner une requête inattendue. Si l’application accepte à la fois des sessions humaines et une clé API, vérifiez que l’automatisation n’a que les droits dont elle a besoin. Notez où la clé est utilisée et qui la remplacera. Si chaque action importante commence quand un collègue ouvre le lien, le pilote peut se limiter aux connexions humaines. Clés API de Cursor Apps
Une application qui lit un entrepôt de données met en jeu trois frontières. Cursor contrôle le public du lien. L’application détermine les actions et les lignes que ce public peut atteindre. Le système amont décide ce que le compte de service peut lire. Les autres couches peuvent limiter les effets d’un mauvais choix à un niveau donné. Quand le tableau de bord ne demande que des comptes agrégés, un identifiant autorisé à interroger toutes les fiches CRM peut rendre coûteuse une petite erreur d’application.
Les tests peuvent rester simples. Ouvrez le lien dans une nouvelle session du navigateur en tant qu’invité, en tant que collègue connecté sans accès, puis sans vous connecter. Dans la session autorisée, demandez une fiche qui doit être accessible et une autre d’un secteur différent. Si un script utilise une clé, vérifiez qu’une requête sans son en-tête échoue et qu’une clé révoquée est refusée. Chaque contrôle permet de repérer une erreur différente.
Une première version bien circonscrite se vérifie plus vite
- Choisissez une tâche et un public nommé. Pour le tableau de bord, demandez des totaux hebdomadaires par étape avec des données fictives, un horaire de rafraîchissement visible et un retour vers le CRM. Pour un portail, demandez une petite liste d’intégration avec des comptes de salariés fictifs.
- Lancez un agent cloud et demandez explicitement une application. Utilisez un dépôt accessible à la future personne responsable. Limitez le premier changement de code pour qu’elle puisse expliquer les routes, le modèle de données et le traitement des erreurs.
- Définissez ce qui peut persister et quelles requêtes peuvent écrire. Ajoutez un secret à portée étroite dans les réglages quand le parcours sur les données fictives fonctionne. Faites préciser où le secret est utilisé et à quel endroit les contrôles d’audience s’appliquent.
- Lancez la revue de publication et examinez son résultat. Choisissez l’URL, publiez explicitement et partagez avec le plus petit groupe adapté. Testez les requêtes autorisées et refusées sur le lien déployé avant de demander à quiconque de s’y fier.
- Notez qui gère l’application, quel service amont elle appelle et qui peut la retirer. Refaites une courte vérification après un changement de visibilité, de connecteur ou d’identifiants. Gardez un lien ou un processus de secours en cas d’indisponibilité temporaire.
La première version peut être plus étroite que ce que l’agent est capable de produire. Un tableau affichant chaque matin un chiffre fiable peut servir davantage qu’un espace à six vues dont les calculs sont contestés. Un portail d’intégration dont la liste est bien entretenue peut éviter des messages répétés même si la vue de coordination vient plus tard. Une version plus petite permet aussi au responsable d’observer les changements, les demandes d’accès et les questions d’assistance qui se présentent réellement.
Évaluez le résultat au cours d’une semaine ordinaire. Regardez à quelle fréquence les collègues ouvrent l’application d’eux-mêmes, s’ils peuvent retrouver la source d’un chiffre qui les surprend et combien de temps il faut pour corriger un problème. Une application qui fait gagner quelques minutes par jour peut se justifier. Si les collègues reviennent au tableur pour vérifier le résultat, cherchez à savoir quel chiffre du nouvel outil ne leur inspire pas encore confiance.
Les changements de Cursor rendent cet essai plus facile à lancer. Dans l’annonce du 5 novembre, la création, la base, la connexion, l’hébergement et le lien de partage font partie du même parcours. Auparavant, le projet pouvait s’arrêter pendant que son auteur cherchait une personne chargée de l’hébergement ou tentait d’organiser la connexion. Quand ces éléments sont en place, la difficulté se déplace vers la définition claire du public, des données et des conditions de mise en service. Le résultat utile est un lien que quelqu’un sait utiliser et dont une autre personne sait s’occuper. Annonce de Cursor
Sources
- Lancement de Cursor Live Apps le 5 novembre 2026
- Documentation Cursor Apps sur la configuration, le partage et l’administration
Pour conserver les échanges et les décisions d’un projet d’outil interne dans des notes faciles à retrouver, créez un compte Telli.sh.