Vidéo de lancement pour un produit logiciel
Produisez une vidéo de 30 à 60 secondes qui fait comprendre et désirer le produit.
La décision qui façonne tout : reconstruire, pas enregistrer
Les enregistrements d’écran sont contraignants. La latence réelle est un temps mort. Les reprises coûtent cher. Vous ne pouvez pas figer une image, ni ralentir un temps et en accélérer un autre, et vous ne pouvez pas recadrer serré sans atteindre du flou de compression.
Reconstruisez donc l’interface utilisateur en tant que React piloté par les images dans Remotion. Chaque visuel est une
fonction pure de useCurrentFrame(). La frappe arrive sur une courbe exacte, un
état de chargement se résout sur le temps, et une reprise coûte un nombre.
Ceci n’est raisonnable que parce que vous pouvez lire le code réel du produit (si local) ou son DOM+CSS (si hébergé) et le reproduire fidèlement. Faites cela — reprenez les vrais noms de classe, les vraies couleurs, les vrais textes. La reconstruction doit être indistinguable d’un enregistrement, puis meilleure.
Quand enregistrer à la place : 3D lourde, contenu vidéo dans le produit, une
surface canvas/WebGL, ou une application de bureau native. Si une surface spécifique ne peut pas être
reconstruite, enregistrez uniquement cette surface et composez-la avec <OffthreadVideo>.
Phase 1 — Comprendre le produit
Lisez references/discovery.md avant de commencer cette phase. Elle couvre la
procédure de navigation et de tri, la conversation sur les identifiants, et comment extraire
un système de design d’un site en ligne.
Version courte :
- Étant donné une URL : naviguez. Commencez par la page d’accueil (elle vous dit comment ils se positionnent), puis l’application elle-même. Déterminez quel travail le produit fait et pour qui.
- Étant donné un dépôt local/serveur de développement : lisez le code. Beaucoup plus riche — vous obtenez les vrais composants, les vrais tokens de thème, les vraies données de démonstration.
- Faites le tri des pages. La plupart des produits ont 20 écrans et 3 qui comptent. Authentification, paramètres, facturation, confidentialité, compte, onboarding — ce sont presque jamais l’histoire. Trouvez l’écran où le produit fait la chose que seul lui peut faire.
- Si le contenu intéressant est derrière une connexion, demandez d’abord — identifiants de test, ou un
compte pré-rempli dans leur développement local. Si aucun n’est disponible, n’abandonnez pas
et ne simulez pas une session que vous n’avez jamais vue : passez à la forme chapitrée et
construisez à partir des propres fiches fonctionnalités, textes et composants de la page d’accueil.
discovery.mda la procédure de récolte et les règles d’honnêteté.
Confirmez ensuite votre lecture avec l’utilisateur avant de construire — une lecture erronée du produit coûte toute la construction. Montrez-lui : ce que vous pensez que le produit fait, les 2 à 4 écrans que vous prévoyez de mettre en avant, le scénario principal, la liste des plans, et la question de la musique (voir Phase 4). Un point de contrôle, puis exécutez.
Phase 2 — Choisir la forme
Lisez references/structure.md. Deux formes fonctionnent ; choisir la mauvaise coûte la
construction.
Forme A — le récit unique. La forme par défaut. Un utilisateur effectue un seul travail et obtient un artefact. Ce n’est pas un tour des fonctionnalités.
| temps | tâche |
|---|---|
| Accroche (0–5s) | Énoncez le problème dans les propres mots du spectateur. Pas encore d’interface. |
| Demande (5–12s) | L’utilisateur demande la chose. Serré sur la saisie. |
| Travail (12–25s) | Le produit fait visiblement quelque chose de difficile. Montrez les preuves. |
| Artefact (25–35s) | La sortie, en entier, à une taille lisible. |
| Contrôle (35–45s) | L’utilisateur la modifie et garde le contrôle. |
| Générique (45–50s) | Logo, une ligne, domaine. |
Les temps Travail et Contrôle sont ce qui distingue une vraie démonstration d’une maquette. « Il m’a demandé au lieu de deviner » et « J’ai pu modifier ce qu’il a créé » sont des arguments de confiance, et la confiance est ce que vend réellement une vidéo de lancement.
Choisissez le moment où le produit fait quelque chose qu’une personne ne pourrait pas facilement faire elle-même, et rendez la sortie concrète et visible — un document généré, un graphique construit, un bug corrigé, un site déployé. Les artefacts concrets sont ce dont les gens se souviennent.
Forme B — le film chapitré. Trois fonctionnalités, chacune introduite par une carte d’étiquette en langage simple, puis montrée.
accroche → [01 étiquette → fonctionnalité] → [02 étiquette → fonctionnalité] → [03 étiquette → fonctionnalité] → générique
Utilisez-la lorsque le produit est verrouillé et que vous travaillez à partir de sa page d’accueil, ou lorsque les fonctionnalités ne partagent vraiment pas un parcours utilisateur, ou lorsque vous voulez trois extraits autonomes à partir d’une seule construction. Trois est le nombre — quatre signifie qu’aucune ne marque.
Ne chapitre pas une séquence. Si les capacités se succèdent dans une seule session (recherche → brouillon → édition), c’est un seul workflow, et les étiqueter comme trois fonctionnalités va à l’encontre du matériau. Si quelqu’un demande des chapitres sur un produit séquentiel, proposez la voie du milieu : gardez le récit unique et mettez les étiquettes sur l’action à mesure que chaque capacité apparaît. Même lisibilité, mêmes limites d’extrait, aucun coût de durée, histoire intacte.
structure.md couvre la conception des cartes de chapitre, comment écrire les étiquettes (nommez le
résultat, pas le mécanisme ; reprenez les propres mots du produit), les transitions, et
l’ordre.
Phase 3 — Ancrer tout
Quel que soit le domaine du produit, n’inventez pas son contenu. S’il s’agit d’un produit juridique, la loi doit être réelle. S’il s’agit d’analytique, les chiffres doivent être plausibles et cohérents en interne. S’il s’agit d’un outil de code, le code doit compiler dans la tête du lecteur.
Extrayez la chose réelle du dépôt, de l’API, des données de démonstration ou de la documentation. Les experts du domaine regardent ces vidéos et un seul détail inventé vous coûte tous. Les noms de parties, les dates et les montants en dollars sont acceptables à inventer — ce sont spécifiques à un client, pas des affirmations sur le monde.
Conservez une note de provenance dans le fichier de données indiquant d’où vient chaque fait. Votre futur vous remerciera.
Phase 4 — Construire
Exécutez le squelette, qui fixe les versions qui fonctionnent réellement ensemble et écrit la configuration :
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "product-launch" --fps 60 --seconds 45
Il crée un projet Remotion autonome (son propre dépôt git — n’ajoutez jamais d’outillage vidéo
au dépôt du produit sauf demande expresse), copie useCamera.ts, et
vous laisse un module de chronologie à remplir.
Ensuite, dans l’ordre :
-
src/timeline.ts— calcul des images et limites des plans. Choisissez un BPM dont le temps est un nombre entier d’images (à 60 ips : 120 BPM = 30 images, 90 BPM = 40). Placez chaque limite de plan sur un temps. Même sans musique, cela donne au cut un rythme interne, et cela signifie qu’une bande sonore peut être ajoutée plus tard sans ré-édition. -
src/data/script.<lang>.ts— chaque chaîne, chaque nombre, chaque morceau de contenu de document, dans un seul fichier avec des commentaires de provenance. Rien codé en dur dans les composants. Le ré-étalonnage et la traduction deviennent tous deux triviaux. -
Composants — recréez l’interface utilisateur du produit. Copiez les vrais noms de classe. Si le produit utilise Tailwind, importez sa configuration et son CSS de thème ; s’il utilise des variables CSS pour la couleur, vous devez les reprendre, sinon tout s’affiche sans couleur.
-
src/scenes/ProductScene.tsx— un objetBexporté contenant chaque temps comme un numéro d’image absolu. Tout lit à partir de lui : le DOM, la caméra, le son. Ré-étalonner signifie éditer ce bloc et rien d’autre.
Lisez references/camera.md pour le système de plans, references/motion.md pour
les durées et la typographie.
Phase 5 — Audio
Deux pistes, deux fichiers, deux balises <Audio> : effets et musique. Gardez-les
séparées afin que l’une ou l’autre puisse être remplacée sans régénérer l’autre.
Effets — references/sound.md. La retenue est toute la discipline : une
vidéo de 45 secondes nécessite généralement trois à cinq événements au total. Un pop signifie qu’une chose
est apparue, un swish signifie qu’un élément s’est déplacé dans le plan, un whoosh signifie que le plan
s’est déplacé.
python3 <skill-dir>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
Musique — references/music.md. Demandez avant de construire. La plupart des gens
ont une opinion et beaucoup ont déjà un morceau ; demander coûte une phrase et peut
sauver tout l’effort :
Voulez-vous une bande sonore ? Si vous avez un morceau, envoyez-le et je couperai dessus. Si non, je peux en synthétiser un — énergique, calme, cinématographique, minimal, chaleureux, ou tendu ?
S’ils ont un morceau, coupez dessus : trouvez son BPM, réglez la chronologie pour correspondre, déplacez les limites des plans sur ses mesures. Sinon, synthétisez une bande dont l’arrangement change pour atterrir sur vos cuts à l’image :
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
Placez une entrée sections sur chaque vraie limite de plan, une entrée hits sur votre
plus grand cut, et une entrée ducks sous toute ligne maintenue que vous voulez lire plutôt que
ressentir. Musique au sommet ~0.30, effets à ~0.62. Choisissez l’humeur en fonction de ce que le produit
est — un sujet sérieux nécessite une bande plus calme, et un cut chargé nécessite
une bande plus clairsemée.
Phase 6 — Vérifier avec des images fixes, avant de rendre
C’est la boucle serrée, et la sauter fait perdre des heures.
npx remotion still <CompositionId> out/f0700.png --frame=700
Ensuite, regardez réellement le PNG. Rendez une image fixe par plan, plus une à chaque transition. Vérifiez : le sujet est-il dans le cadre, quelque chose est-il coupé en milieu de mot, y a-t-il de l’espace vide, le texte tient-il.
Ajoutez une composition silencieuse (defaultProps: { withAudio: false }) pour que les images fixes
n’aient pas besoin du fichier audio pour exister.
Réglez numériquement chaque fois que possible. Courbes d’assouplissement, distances de défilement, contenu spectral — tout cela est calculable. Écrivez un script Python jetable qui échantillonne la courbe et imprime ce que vous devineriez autrement. C’est plus rapide qu’un rendu et c’est correct.
Ne rendez la vidéo complète qu’une fois les images fixes correctes.
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
Limitez la concurrence à environ 4 sur une machine de 16 Go — Remotion lance un onglet Chrome par emplacement et la valeur par défaut (nombre de cœurs) provoquera de l’échange.
Phase 7 — Remettre honnêtement
Envoyez le fichier. Puis dites clairement :
- Ce que vous n’avez pas pu vérifier. Vous pouvez lire des images fixes ; vous ne pouvez pas juger comment huit secondes se ressentent, et vous ne pouvez pas entendre l’audio. Dites-le.
- Tout écran que vous avez reconstruit plutôt qu’observé — surtout sur un produit verrouillé. Listez-les, et proposez de refaire ces temps s’ils veulent bien partager l’accès.
- Où vous avez fait un jugement avec lequel ils pourraient ne pas être d’accord.
- Comment changer la musique : déposez n’importe quel WAV ou MP3 dans
public/music.wavet re-rendre. - Tout ce que vous avez trouvé dans leur produit en construisant — un bug de rendu, une étiquette erronée, un état manquant. Vous venez de lire leur interface utilisateur plus attentivement que la plupart des gens ne le feront jamais. Cette observation vaut souvent plus que la vidéo.
Fichiers de référence
Lisez-les lorsque vous atteignez la phase correspondante — ils sont détaillés et il n’y a aucun intérêt à les charger tous d’un coup.
| fichier | quand |
|---|---|
references/discovery.md | Phase 1 — navigation, tri des pages, identifiants, systèmes de design, et construction à partir de la page d’accueil d’un produit verrouillé |
references/structure.md | Phase 2 — récit unique vs chapitres, conception des cartes de chapitre, rédaction des étiquettes de fonctionnalité, transitions, ordre |
references/camera.md | Construction des plans — espace de mise en page, caméra point focal, cut vs poussée vs morphose, isolation des composants |
references/motion.md | Durées d’animation, typographie, motifs d’accroche, le rouleau de questions |
references/sound.md | Conception sonore — le vocabulaire pop/swish/whoosh, retenue, synthèse du clavier et des clics |
references/music.md | Trouver vs synthétiser une bande, choisir une humeur, aligner les sections sur les cuts, mélanger sous les effets |
references/pitfalls.md | Lisez ceci avant votre premier rendu. Bugs qui coûtent de vraies heures, chacun avec le correctif. |
Scripts fournis
<skill-dir> ci-dessous est le propre répertoire de cette compétence — le chemin donné lorsque
la compétence a été chargée. Ne supposez pas un emplacement d’installation fixe ; la compétence peut être
installée personnellement, comme un plugin, ou extraite dans un projet.
| script | quoi |
|---|---|
scripts/scaffold_video.py | Crée le projet Remotion avec des épingles de version fonctionnelles et la configuration |
scripts/make_sfx.py | Synthétise une piste d’effets sonores à partir d’une liste d’événements JSON. Pas d’échantillons, pas de dépendances au-delà de numpy. |
scripts/make_music.py | Synthétise une bande sonore dans l’une des six humeurs, avec son arrangement aligné sur vos cuts. Mêmes dépendances. |
assets/useCamera.ts | Le hook de caméra point focal — copiez dans src/hooks/ |
assets/ChapterCard.tsx | Carte de chapitre pour la forme chapitrée — copiez dans src/components/ |
La version courte
Reconstruisez plutôt que d’enregistrer. Une histoire, un artefact — sauf si le produit est verrouillé ou si ses fonctionnalités sont vraiment séparées, alors trois chapitres avec des étiquettes simples. Ancrez chaque fait de domaine. Les images sont l’unité de tout. Isolez un composant plutôt que de recadrer la page. Les animations UI durent 150–300ms, les mouvements de caméra ~1s. Quatre sons suffisent. Demandez avant de faire de la musique. Regardez les images fixes avant de rendre. Dites ce que vous n’avez pas pu vérifier, et ce que vous avez déduit.