Guide7 min de lecture

Présentation guidée de relecture Cursor

Prouvez que la demande a été réalisée sans demander à personne d'exécuter le code.

Remettez à un relecteur une version Cursor avec un seul parcours qui prouve que le changement demandé fonctionne, plutôt que de lui demander d'exécuter le code.

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

Reformuler la demande en un seul parcours

Reformulez la demande en un seul parcours que le relecteur peut regarder du début à la fin.

Atteindre l'état exact qui y répond

Atteignez l'état exact qui y répond, pas un écran voisin qui paraît similaire.

Retirer tout ce que la demande ne mentionnait pas

Retirez tout ce que la demande ne mentionnait pas, même si c'est également terminé.

Une remise pour relecture a un rôle plus restreint qu'une démo, un argumentaire ou une pièce de portfolio. Quelqu'un a demandé une chose précise, qu'il s'agisse d'une correction de bug, d'une nouvelle fonctionnalité ou d'un changement à un parcours existant, et la personne qui relit le travail veut savoir une chose : est-ce arrivé. Elle n'évalue pas l'ensemble du produit et ne veut généralement pas de visite. Une présentation guidée construite pour ce moment doit répondre à la demande initiale aussi directement qu'un oui ou un non, appuyée par des images qui montrent la réponse plutôt que de la décrire.

Cursor est un éditeur de code, et le code qu'il aide à écrire ne devient pas accessible tout seul. Une version réalisée dans Cursor s'exécute sur un serveur de développement local pendant qu'elle est en cours de travail, et elle ne devient quelque chose qu'un relecteur peut voir qu'une fois déployée quelque part, que ce soit un environnement de préproduction partagé, un serveur personnel ou un lien de prévisualisation de l'hébergeur utilisé par le projet. Avant d'enregistrer une présentation guidée de relecture, confirmez laquelle de ces options est réellement active, car un relecteur qui compare la vidéo à un déploiement cassé ou obsolète ne fera confiance ni à la vidéo ni à la version.

Cela compte davantage pour une présentation guidée de relecture que pour presque tout autre type de vidéo de démonstration, car tout l'intérêt de l'enregistrement est qu'il puisse être vérifié. Une vidéo de démonstration destinée à un inconnu est rarement comparée à un parcours actif que le spectateur ouvre lui-même. Une présentation guidée de relecture l'est souvent, parfois quelques minutes après son envoi, et tout écart entre ce que montre la vidéo et ce que le relecteur trouve en regardant lui-même devient l'histoire de la relecture au lieu du changement lui-même.

Que doit réellement voir le relecteur ?

Revenez à la demande initiale et écrivez-la en une seule phrase décrivant un point de départ, une action et un résultat. Si la demande était de corriger un bouton d'envoi cassé, le parcours est : ouvrir le formulaire, le remplir, l'envoyer, voir qu'il réussit. Si la demande était d'ajouter un filtre à une liste, le parcours est : ouvrir la liste, appliquer le filtre, voir la liste changer. Tout ce que le relecteur n'a pas demandé, quel que soit son degré d'achèvement, n'a pas sa place dans cet enregistrement. Une présentation guidée qui s'égare vers des fonctionnalités voisines force le relecteur à faire un travail supplémentaire pour trouver la partie qu'il a réellement demandée.

Type de demande	Le parcours à montrer	Ce qu'il faut laisser de côté
Correction de bug	Les étapes exactes qui échouaient auparavant, se terminant par un succès	Les écrans sans rapport qui n'ont jamais été cassés
Nouvelle fonctionnalité	La fonctionnalité utilisée à partir d'un point de départ réaliste	Une visite de toute la page environnante
Changement visuel ou de texte	Un avant et après clair au même endroit	D'autres changements en attente qui ne font pas partie de cette demande

Comment préparer la version pour la présentation guidée ?

Ouvrez vous-même d'abord le parcours déployé et exécutez les étapes exactes qui importent au relecteur. Confirmez que la correction ou la fonctionnalité est présente dans la version réellement active, pas seulement dans une branche locale qui n'a pas encore été déployée. Cela paraît évident et pourtant c'est constamment sauté, surtout sous la pression des délais, et c'est la raison la plus courante pour laquelle un enregistrement de relecture met dans l'embarras la personne qui l'a fait.

Confirmez que la version déployée correspond au code que vous pensez avoir été fusionné.
Éliminez toute donnée de test issue d'un débogage antérieur qui pourrait dérouter le relecteur.
Configurez un compte de démonstration si le parcours se trouve derrière une connexion, plutôt que de partager un vrai compte.
Chronométrez l'interaction une fois avant l'enregistrement, afin que l'indication corresponde à ce qui se produit réellement.

Si l'application nécessite une authentification pour que le relecteur voie l'écran pertinent, demandez un compte de démonstration via le processus normal plutôt que d'envoyer une connexion personnelle. Sur GogoScreen, les identifiants fournis pour un rendu sont chiffrés, utilisés pour un seul rendu, puis supprimés, ce qui compte lorsque la version en question appartient à un client plutôt qu'à vous. 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. Une situation liée mais différente est la relecture d'une pull request elle-même plutôt que d'une application en cours d'exécution, ce que couvre séparément le guide vidéo de démonstration de PR d'agent IA.

Il est également utile de vérifier la version à un moment proche de celui où le relecteur la regardera réellement. Un déploiement qui paraissait correct une heure auparavant peut dériver si un autre changement arrive sur le même environnement dans l'intervalle, en particulier sur un serveur de préproduction partagé sur lequel plusieurs personnes poussent des changements. Enregistrer immédiatement avant l'envoi, plutôt que de réutiliser un enregistrement plus ancien de la même fonctionnalité, garde ce risque faible.

Comment l'indication de parcours doit-elle être rédigée ?

Reformulez la demande en un seul parcours que le relecteur peut regarder du début à la fin.
Atteignez l'état exact qui y répond, pas un écran voisin qui paraît similaire.
Retirez tout ce que la demande ne mentionnait pas, même si c'est également terminé.

Rédigez l'indication en utilisant les mêmes mots que la demande initiale. Si le ticket disait « le bouton de paiement », l'indication doit dire bouton de paiement, pas action de paiement. Un relecteur qui compare les images à son propre souvenir de la demande remarque les décalages de mots plus vite que la plupart des autres problèmes, et un décalage se lit comme la preuve que la demande a été mal comprise, même quand ce n'est pas le cas.

Où cela se situe-t-il par rapport à une démo ou une vidéo de lancement ?

Une présentation guidée de relecture et une vidéo de démonstration se ressemblent en surface, et il est utile de garder les objectifs séparés. Une présentation guidée produit pour SaaS est construite pour un acheteur potentiel qui décide si le produit vaut la peine d'être essayé, tandis qu'une présentation guidée de relecture est construite pour quelqu'un qui connaît déjà le produit et vérifie une affirmation précise. Si la version a besoin plus tard d'une véritable vidéo d'introduction une fois le travail accepté, un traitement de style vidéo de démonstration Windsurf ou vidéo de page d'accueil Windsurf est la meilleure étape suivante, car les deux sont écrits pour un spectateur découvrant le produit plutôt que pour un relecteur ayant du contexte.

Certaines demandes viennent d'un public plutôt que d'un relecteur privé, comme une vidéo de démonstration Show HN répondant à des commentaires sur un fil de lancement. Ce cas est plus proche d'une présentation guidée de relecture que d'une démo, car il répond aussi à une question précise que quelqu'un a posée, simplement en public plutôt qu'en privé. La même discipline consistant à reformuler la question et à montrer la réponse s'applique dans les deux cas. Un besoin de relecture similaire apparaît aussi sur d'autres plateformes de création IA, notamment le guide vidéo de démonstration pour application v0 et le guide vidéo de démonstration pour application Lovable, tous deux écrits pour le moment qui suit immédiatement une version générée devant être vérifiée par rapport à ce qui était demandé.

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

Repassez l'enregistrement en le comparant au texte de la demande initiale, ligne par ligne si la demande comportait plusieurs parties. Si la relecture est envoyée à quelqu'un qui compare plusieurs créateurs, une entrée de style démo de portfolio Windsurf ou vidéo de lancement Product Hunt Windsurf couvre cette comparaison plus large, mais une présentation guidée de relecture elle-même doit rester restreinte. Si le relecteur doit partager l'enregistrement plus loin, une remise de style partage Windsurf avec un client explique comment la préparer pour quelqu'un qui ne cliquera pas du tout sur un lien de prévisualisation.

Laissez de la place dans votre planning pour une nouvelle tentative, car environ un rendu sur cinq en a besoin. Chaque nouveau compte reçoit 60 secondes de vidéo une seule fois, avec filigrane, ce qui couvre généralement une seule demande confortablement, et ensuite le temps acheté en recharge n'expire jamais et le temps n'est utilisé que lorsqu'un rendu réussit. Comparez les options de capture à Loom si le relecteur attend plutôt un partage d'écran en direct, vérifiez les tarifs pour les forfaits, parcourez plus de guides et de comparaisons, ou revenez à la page d'accueil de GogoScreen pour démarrer un nouveau rendu pour la prochaine demande.

Précisions

Avant de commencer

Que doit prouver une présentation guidée de relecture d'application Cursor ?

Elle doit prouver que la chose précise demandée par le relecteur se produit réellement dans l'application en cours d'exécution. Cela signifie partir de la demande, et non de la base de code, et montrer l'état exact qui y répond.

La présentation guidée doit-elle expliquer comment le code fonctionne ?

Non. Un relecteur qui approuve une version veut généralement savoir que le résultat est correct, pas comment l'implémentation y est arrivée. Réservez l'explication de l'implémentation pour une description de pull request ou un appel séparé.

Que faire si le relecteur ne peut pas accéder à une version protégée par connexion ?

Un compte de démonstration peut être préparé pour le rendu sur GogoScreen, où 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. Cela supprime la nécessité de remettre au relecteur une vraie connexion.

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