Guide6 min de lecture

Partager un projet Cursor avec un client

Montrez à un client la build en fonctionnement, sans lui demander d'ouvrir un lien.

Donnez à un client non technique la preuve qu'une build Cursor fonctionne, en partant d'un vrai déploiement plutôt que d'un lien qu'il n'ouvrira pas.

Voir comment ça marcheLes 60 premières secondes de vidéo sont gratuites, avec un filigrane.
Vérifiez votre adresse e-mail pour la télécharger.

gogoscreen.com

Confirmer le déploiement que le client verra

Confirmez que le déploiement est en direct et stable avant d'enregistrer quoi que ce soit qui sera montré au client.

Choisir le flux que le client a réellement demandé

Choisissez l'unique flux qui correspond exactement à ce que le client a demandé, pas une visite plus large de la build.

Rédiger l'indication et envoyer le fichier

Rédigez une indication nommant le début, l'action et le résultat, puis envoyez le fichier terminé plutôt qu'un lien.

Un client qui a commandé un travail sur un projet Cursor n'a aucun intérêt pour l'éditeur, le langage, ou la manière dont le code est organisé. Il veut savoir si la chose pour laquelle il a payé est terminée. Lui envoyer un lien lui demande de faire confiance à une adresse qu'il n'a jamais vue, de naviguer dans une interface qu'il ne connaît pas, et de trouver la partie pertinente lui même. Une courte vidéo élimine chacune de ces étapes. Il appuie sur lecture et regarde le travail demandé se produire.

GogoScreen prend une URL d'application web et une indication d'une ligne sur ce qu'il faut montrer, puis renvoie un MP4 narré et monté avec zooms sur les clics, lissage du curseur, suppression des temps morts et sous-titres incrustés. Pour une build Cursor précisément, il y a une étape avant tout cela : l'application doit être déployée quelque part d'accessible d'abord, puisque Cursor lui même ne génère pas de lien de prévisualisation. Une fois ce déploiement existant, l'outil fonctionne de la même façon que contre n'importe quelle autre URL.

Pourquoi une passation Cursor nécessite t elle une étape supplémentaire ?

Confirmez que le déploiement est en direct et stable avant d'enregistrer quoi que ce soit qui sera montré au client. Une plateforme qui arrive avec un lien de prévisualisation automatique rend cette étape invisible. Un projet Cursor ne le fait pas, donc elle doit être traitée délibérément, généralement en déployant vers l'hébergeur que l'équipe utilise déjà pour le projet, ou en mettant en place un déploiement spécifiquement pour soutenir la passation. Faites cela avant de rédiger l'indication, pas en parallèle, parce que le déploiement peut prendre plus de temps que prévu s'il n'a pas déjà été fait.

Vérifiez que le déploiement est celui qui sera encore en direct quand le client regardera réellement la vidéo, pas un environnement temporaire qui sera démantelé le lendemain. Un client qui revient avec une question de suivi une semaine plus tard et trouve le lien mort y verra la preuve que le travail n'a jamais vraiment été terminé, même si le flux enregistré était exact au moment de l'enregistrement.

Cette passation est différente du guide de la démo de portfolio Cursor, écrit pour un public général qui décide si le développeur mérite d'être engagé, et du guide de la visite de relecture d'application Cursor, écrit pour un relecteur qui vérifie une build par rapport à un brief écrit. Une passation client se situe entre les deux : le public a déjà commandé le travail, donc la seule question ouverte est de savoir si la chose précise demandée existe maintenant et fonctionne.

Ce que le client juge	Ce qu'un lien de prévisualisation brut lui demande	Ce que la vidéo élimine
Le travail demandé est il terminé	Cliquer, naviguer, trouver l'écran pertinent	Il regarde le flux exact accompli
Est ce que cela paraît fiable	Évaluer une adresse jamais vue	Rien à cliquer, rien à questionner
Est ce que cela correspond à ce qui a été demandé	Comparer l'application à son souvenir du brief	La narration peut nommer la demande directement

Comment choisir le flux à montrer ?

Choisissez l'unique flux qui correspond exactement à ce que le client a demandé, pas une visite plus large de la build. Revenez à la demande d'origine plutôt qu'à l'état actuel du code. Si le brief demandait un formulaire de commande qui envoie un email de confirmation, montrez précisément cela, accompli, plutôt qu'un regard plus large sur le panneau d'administration derrière. Un client qui compare la vidéo à son souvenir de la demande remarquera si les deux ne correspondent pas.

Confirmez la route exacte depuis laquelle le flux demandé commence.
Utilisez des données d'exemple plausibles plutôt que des tableaux vides ou du texte de remplissage.
Retirez toute information d'un autre client de l'environnement avant l'enregistrement.
Si une connexion protège le flux, prévoyez un compte de démonstration plutôt qu'un compte réel.

Parce que les builds Cursor ont tendance à inclure une logique backend authentique plutôt qu'une maquette rapide, cette étape de préparation compte plus qu'elle ne le ferait pour un prototype léger. Testez le flux à la main immédiatement avant l'enregistrement pour que l'état capturé dans la vidéo corresponde à ce qui a été vérifié en dernier comme fonctionnel.

Résistez à la tentation de montrer plus que ce que le client a demandé, même quand d'autres parties de la build se trouvent être terminées et impressionnantes. Un client qui regarde un clip qui dérive au delà de la demande cadrée vers un territoire sans lien peut se demander si la demande d'origine s'est perdue quelque part dans le processus. S'il y a un travail terminé supplémentaire qui vaut la peine d'être mentionné, soulevez le séparément, après que le client a confirmé que le flux demandé est exactement ce qu'il voulait.

Comment gérer une vraie connexion pour cet enregistrement ?

Si une connexion protège le flux, un compte de démonstration peut être fourni via le processus approuvé, et sur GogoScreen les identifiants sont chiffrés, utilisés pour un seul rendu, puis supprimés. Si un storyboard est planifié en premier, les identifiants restent chiffrés pendant cette session et sont supprimés au plus tard deux heures après leur dernière utilisation. N'utilisez pas le compte ou les identifiants propres du client pour cela, même si c'était le moyen le plus rapide de montrer exactement les données qu'il attend. Un compte de démonstration dédié garde le processus d'enregistrement séparé de tout compte important pour quiconque, et cela signifie que le client n'a jamais à se demander ce qui est arrivé à sa propre connexion après coup.

Rédigez une indication nommant le début, l'action et le résultat, puis envoyez le fichier terminé plutôt qu'un lien. Formulez la avec les mots propres du client autant que possible, en correspondant à la façon dont le brief d'origine décrivait la demande plutôt qu'à la façon dont le code base étiquette les choses en interne.

Confirmez que le déploiement est en direct et stable avant d'enregistrer quoi que ce soit qui sera montré au client.
Choisissez l'unique flux qui correspond exactement à ce que le client a demandé, pas une visite plus large de la build.
Rédigez une indication nommant le début, l'action et le résultat, puis envoyez le fichier terminé plutôt qu'un lien.

Que devez vous vérifier avant de l'envoyer ?

Environ un rendu sur cinq échoue ou nécessite une nouvelle tentative, donc regardez le candidat avant qu'il n'atteigne le client. Le guide de la vidéo de démo produit pour un readme est une comparaison utile ici, puisque les deux publics ont besoin que la vidéo tienne debout seule sans exiger d'explication séparée en plus. Si l'application inclut un style de narration fortement basé sur la voix off, le guide de la voix off pour une vidéo de démo produit couvre comment s'assurer que la narration correspond précisément au flux plutôt que de se lire comme un texte marketing générique.

Si le produit du client est encore avant lancement, le guide de la vidéo de démo pour une liste d'attente SaaS couvre un cas d'usage lié pour créer de l'anticipation avant que l'application ne soit pleinement publique. Si la build en question a été faite dans v0 plutôt que Cursor, le guide de la vidéo de démo d'application v0 couvre la même discipline de passation pour un projet avec un point de départ différent. Pour un contexte de lancement plus large au delà d'un seul client, la liste de vérification de lancement d'un agent IA couvre l'ensemble plus large d'étapes dont un lancement a généralement besoin.

Pour le même travail sur les autres pages Cursor, voir le guide de la vidéo de démo Windsurf, le guide de la vidéo de page de destination Windsurf et le guide de la vidéo de lancement Product Hunt Windsurf, qui couvrent la passation équivalente pour un autre éditeur assisté par IA. Pour une comparaison directe des outils d'enregistrement, consultez GogoScreen contre Demosmith. Commencez depuis la page d'accueil pour le flux de travail de l'URL et de l'indication, parcourez les guides pour le reste de la série, consultez les comparaisons avec d'autres outils, et vérifiez les tarifs avant de soumettre un rendu pour un client.

Précisions

Avant de commencer

Pourquoi une vidéo vaut elle mieux qu'un lien pour une passation client Cursor ?

Un client qui ne construit pas de logiciel régulièrement ne cliquera souvent pas sur un lien inconnu, et un projet Cursor n'a de toute façon pas d'URL de prévisualisation automatique vers laquelle le diriger. Une vidéo élimine les deux problèmes en montrant le travail directement.

Le client a t il besoin de savoir comment l'application a été construite ?

Non. Le client juge si le travail demandé est terminé, pas quel éditeur ou outillage l'a produit. Gardez la narration centrée sur le flux, pas sur le processus de construction.

Que faire si l'application exige une vraie connexion ?

Utilisez un compte de démonstration jetable plutôt que les identifiants du client ou un compte personnel. Sur GogoScreen, les identifiants fournis sont chiffrés, utilisés pour un seul rendu, puis supprimés. Si un storyboard est planifié en premier, les identifiants restent chiffrés pendant cette session et sont supprimés au plus tard deux heures après leur dernière utilisation.

Collez une URL, décrivez un parcours et obtenez une vidéo de démonstration de votre application web.

Les 60 premières secondes de vidéo sont gratuites, avec un filigrane. Vérifiez votre adresse e-mail pour télécharger la vidéo.

Voir les tarifs Lire les guides