Guide7 min de lecture

Partager un projet v0 avec un client

Donnez à un client une preuve fiable sans lien de prévisualisation à ouvrir.

Transformez une prévisualisation v0 en une vidéo qu'un client non technique regardera réellement, plutôt qu'un lien sur lequel il ne cliquera 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

Choisir le parcours demandé par le client

Choisissez le parcours qu'un relecteur non technique peut juger sans ouvrir l'application.

Le confirmer avant que quiconque d'autre ne le voie

Ouvrez l'URL de prévisualisation v0 et confirmez que le parcours fonctionne avant que quiconque d'autre que vous ne le voie.

Rédiger l'indication et envoyer le fichier

Rédigez l'indication, relisez le candidat, puis envoyez le fichier plutôt que le lien.

Un client qui a commandé un petit build veut rarement cliquer sur un lien, attendre le chargement d'une page, et deviner où cliquer ensuite. Il veut savoir si la chose pour laquelle il a payé fonctionne. Envoyer une URL de prévisualisation v0 brute lui demande de faire un travail pour lequel il ne s'est pas engagé, et cela reporte la charge de la preuve sur sa patience plutôt que sur le résultat. Une courte vidéo supprime cette friction. Le client appuie sur lecture, regarde la tâche s'accomplir, et prend une décision sans jamais toucher à l'application.

GogoScreen prend l'URL d'une application web et une indication d'une ligne sur ce qu'il faut montrer, puis renvoie un fichier MP4 narré et monté avec des zooms sur les clics, un lissage du curseur, la suppression des temps morts et des sous-titres incrustés. Pour une passation client, la valeur n'est pas la finition, c'est que la narration est écrite pour correspondre à ce qui s'est réellement passé à l'écran, de sorte que le client regarde un enregistrement du build réel plutôt qu'une description de ce qu'il est censé faire.

Pourquoi un lien de prévisualisation échoue t il avec ce public ?

Un build v0 est généré à partir d'une invite et déployé via Vercel, donc la version fonctionnelle se trouve généralement à une URL de prévisualisation sur un sous-domaine généré plutôt que sur un domaine terminé que le client reconnaît. Pour un développeur, cette adresse est banale. Pour un client qui ne développe pas de logiciels lui même, un sous-domaine inconnu peut sembler suspect, ou simplement être une chose de plus entre lui et la réponse à la question qu'il a réellement, qui est de savoir si le travail est terminé. Certains clients ne cliqueront pas du tout dessus, et une vidéo qui ne leur a jamais demandé de cliquer sur quoi que ce soit contourne entièrement la question.

Le guide pour choisir la route d'une application web pour une vidéo de démo couvre le choix du bon écran quand l'application a plusieurs routes candidates, ce qui compte ici parce qu'une passation client a généralement besoin d'exactement un parcours, pas d'un menu de parcours. Le guide sur l'enregistrement d'une démo sans logiciel de capture d'écran est pertinent pour la même raison qu'un lien échoue : mettre en place un enregistreur d'écran est une étape de plus entre la fin du travail et sa présentation, et une URL avec une indication remplace entièrement cette mise en place.

Ceci n'est pas propre à v0. Le guide de la vidéo de démo d'une application Lovable couvre le même écart de confiance pour un build généré différent, parce que le problème sous-jacent n'est pas l'outil qui a produit l'application, c'est qu'un client qui évalue un travail terminé par e-mail ou par fil de discussion n'a aucune raison de faire confiance à une adresse qu'il n'a jamais vue auparavant. Quel que soit le générateur qui a produit le build, la correction est la même : remplacer le lien par quelque chose que le client peut regarder sans quitter la conversation dans laquelle il se trouve déjà.

Ce que le client veut réellement	Ce qu'un lien l'oblige à faire	Ce qu'une vidéo lui donne à la place
La confirmation que la tâche est terminée	Cliquer, charger une page, trouver le parcours	Regarder la tâche s'accomplir à l'écran
Un résultat qu'il peut juger rapidement	Naviguer dans une interface inconnue	Voir le résultat dans son contexte, immédiatement
La confiance que c'est le build réel	Prendre le développeur au mot	Regarder l'application réelle en fonctionnement, pas une maquette

Comment choisir le parcours à montrer à un client ?

Choisissez le parcours qu'un relecteur non technique peut juger sans ouvrir l'application. Partez de ce que le client a réellement demandé, pas de ce que le build inclut par hasard. S'il a commandé un formulaire d'inscription, montrez quelqu'un en train de le remplir et d'atteindre une confirmation, pas une visite du tableau de bord derrière. Un client juge par rapport à la demande, et un parcours qui répond à une autre question, aussi impressionnant soit il, se lit comme évasif plutôt que rigoureux.

Gardez le vocabulaire de l'indication assorti à ce que le client a appelé la fonctionnalité en premier lieu. Si le brief disait « formulaire de contact », ne laissez pas la narration l'appeler « parcours de capture de prospects » simplement parce que c'est ce que l'interface étiquette. Un client devrait entendre ses propres mots décrire sa propre demande, confirmés par ce qui est à l'écran.

Résistez à l'envie de montrer plus que ce qui a été demandé, même quand le travail supplémentaire est terminé et que vous en êtes fier. Un client qui regarde une vidéo qui s'égare au delà du parcours défini vers un écran sans rapport se demandera si la demande initiale s'est perdue en chemin. S'il y a un travail supplémentaire qui mérite d'être montré, il a sa place dans un second clip clairement étiqueté plutôt que fondu dans celui que le client utilise pour valider la demande initiale.

Que doit on avoir vérifié sur l'application avant l'enregistrement ?

Ouvrez l'URL de prévisualisation v0 et confirmez que le parcours fonctionne avant que quiconque d'autre que vous ne le voie. Cette étape existe parce qu'un build v0 tout juste sorti de la génération peut avoir des lacunes qu'un développeur néglige mais qu'un client ne manquera pas : un tableau vide, un bouton qui ne mène encore nulle part, un texte provisoire toujours assis dans un champ destiné à un contenu réel. Réparez d'abord ce qui doit l'être.

Chargez la route exacte à partir de laquelle commence le parcours du client et confirmez que rien ne redirige de manière inattendue.
Remplacez le texte provisoire et les listes vides par un contenu qui ressemble au cas d'usage réel du client.
Retirez le nom, les données ou le compte de tout autre client du build avant d'enregistrer quoi que ce soit.
Si le parcours se trouve derrière une connexion, utilisez un compte de démonstration jetable plutôt qu'un compte réel.

Si une connexion fait réellement partie du parcours, 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. Ce détail compte spécifiquement pour une passation client, parce que le client vous confie le résultat de son projet, et être précis sur ce qu'il advient de tout accès impliqué fait partie de la manière de mériter cette confiance.

Comment rédiger l'indication pour que le résultat corresponde à la demande ?

Rédigez l'indication, relisez le candidat, puis envoyez le fichier plutôt que le lien. Énoncez le point de départ, l'action et le résultat en une seule phrase, dans les propres mots du client si possible. « À partir du formulaire de contact vide, remplissez le et montrez le message de confirmation » est assez précis pour produire un résultat utilisable. « Montrez la fonctionnalité de contact » laisse trop de choses ouvertes, et le rendu peut atterrir sur un écran qui répond à une question que le client n'a jamais posée.

Choisissez le parcours qu'un relecteur non technique peut juger sans ouvrir l'application.
Ouvrez l'URL de prévisualisation v0 et confirmez que le parcours fonctionne avant que quiconque d'autre que vous ne le voie.
Rédigez l'indication, relisez le candidat, puis envoyez le fichier plutôt que le lien.

Que faut il vérifier avant de l'envoyer ?

Environ un rendu sur cinq échoue ou nécessite une nouvelle tentative, donc regardez le fichier avant qu'il n'atteigne le client plutôt que de le transférer automatiquement. Confirmez que l'image d'ouverture a du sens sans aucun contexte préalable, puisque le client ne va pas lire un paragraphe d'introduction avant d'appuyer sur lecture. Vérifiez que rien à l'écran ne contredit ce qui a été promis dans le périmètre initial, et qu'aucune donnée sans rapport ni écran inachevé n'apparaît nulle part dans le clip.

Le guide de la vidéo de démo produit pour un README est une comparaison utile ici, puisqu'un lecteur technique et un client non technique ont besoin de la même discipline sous-jacente appliquée à des publics différents. Si le premier candidat ne tient pas la route, le guide sur la nouvelle tentative d'une vidéo de démo produit explique comment changer une seule chose plutôt que de soumettre à l'aveugle. Pour un build v0 avec un public plus large qu'un seul client, le guide de la démo portfolio v0 et le guide de la relecture d'une application v0 couvrent deux usages voisins du même travail de préparation.

Pour un build réalisé dans Cursor plutôt que dans v0, le guide de la vidéo de démo Cursor, le guide de la vidéo de page de destination Cursor et le guide de la vidéo de lancement Product Hunt Cursor parcourent le processus équivalent pour un projet sans URL de prévisualisation intégrée. Pour une comparaison avec un autre outil d'enregistrement d'écran, consultez GogoScreen contre Clueso. Partez de 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 ne pas simplement envoyer le lien de prévisualisation v0 au client ?

Un client qui ne développe pas de logiciels lui même ne cliquera souvent pas sur un lien de prévisualisation inconnu, en particulier sur un sous-domaine généré qu'il ne reconnaît pas. Une vidéo supprime cette barrière de confiance parce qu'il n'y a rien à cliquer et aucune adresse à mettre en question.

Que doit prouver la vidéo à un client ?

Elle doit montrer la seule tâche que le client a demandée, accomplie, sur l'application réelle. Un client juge si le travail fait ce qui a été demandé, pas si l'interface est soignée.

Le client a t il besoin de voir l'URL de prévisualisation v0 ?

Non. L'adresse elle même n'a pas d'importance pour le client et peut être recadrée. Ce qui compte, c'est que le parcours montré soit le build réel en fonctionnement et non une maquette.

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