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, ne pas enregistrer
Les enregistrements d'écran sont contraignants. La latence réelle est du temps mort. Les reprises coûtent cher. Vous ne pouvez pas figer une image, ralentir un mouvement et en accélérer un autre, ni recadrer serré sans obtenir une compression pixelisée.
Reconstruisez donc l'interface utilisateur sous forme de composants React animés avec Remotion. Chaque élément visuel est une fonction pure de useCurrentFrame(). Le texte apparaît sur une courbe précise, un état de chargement se résout en rythme, et une reprise ne coûte qu'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 classes, les vraies couleurs, le vrai contenu. La reconstruction doit être impossible à distinguer d'un enregistrement, puis meilleure.
Quand enregistrer plutôt : 3D lourde, contenu vidéo intégré au produit, surface Canvas/WebGL, ou 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. Il 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 :
- Si vous avez une URL : naviguez dessus. La page d'accueil d'abord (elle vous dit comment le produit se positionne), puis l'application elle-même. Déterminez quel travail le produit fait pour qui.
- Si vous avez un dépôt/serveur de développement local : lisez le code. Beaucoup plus riche — vous obtenez les vrais composants, les vrais tokens de thème, les vraies données de test.
- Faites le tri des pages. La plupart des produits ont 20 écrans et 3 qui importent. Authentification, paramètres, facturation, confidentialité, compte, onboarding générique — ce n'est presque jamais l'histoire. Trouvez l'écran où le produit fait la chose que lui seul peut faire.
- Si le contenu intéressant est derrière une connexion, demandez d'abord — identifiants de test ou compte pré-rempli dans leur environnement de développement local. Si rien n'est disponible, n'abandonnez pas et n'inventez pas une session que vous n'avez jamais vue : passez à la forme chapitrée et construisez à partir des cartes de fonctionnalités de la page d'accueil, du contenu et des composants.
discovery.mdcontient la procédure de récolte et les règles d'honnêteté.
Confirmez ensuite votre compréhension avec l'utilisateur avant de construire — une mauvaise interprétation 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 montrer, le scénario principal, la liste des plans et la question sur 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 valeur par défaut. Un utilisateur qui fait un travail et obtient un artefact. Pas un tour de fonctionnalités.
| temps | action |
|---|---|
| Accroche (0–5s) | Énoncez le problème dans les mots du spectateur. Pas d'interface encore. |
| Demande (5–12s) | L'utilisateur demande la chose. Gros plan sur l'entrée. |
| Travail (12–25s) | Le produit fait visiblement quelque chose de difficile. Montrez les preuves. |
| Artefact (25–35s) | Le résultat, en entier, à taille lisible. |
| Contrôle (35–45s) | L'utilisateur le modifie et reste maître. |
| Générique (45–50s) | Logo, une ligne, domaine. |
Les étapes 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 faire facilement elle-même, et rendez le résultat concret et visible — un document généré, un graphique créé, un bug corrigé, un site déployé. Les artefacts concrets sont ce dont les gens se souviennent.
Forme B — le film à chapitres. Trois fonctionnalités, chacune présentée 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 pas vraiment un parcours utilisateur, ou lorsque vous voulez trois clips 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 produisent l'une après l'autre dans une seule session (recherche → brouillon → édition), c'est un seul workflow, et l'étiqueter comme trois fonctionnalités combat le matériel. Si quelqu'un demande des chapitres sur un produit séquentiel, proposez plutôt la voie du milieu : gardez le récit unique et placez les étiquettes sur l'action à mesure que chaque capacité apparaît. Même lisibilité, mêmes limites de clips, pas de coût en 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 ; volez les mots du produit lui-même), 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 l'esprit du lecteur.
Tirez la vraie chose du dépôt, de l'API, des données de test 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 peuvent être inventés — ceux-ci 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. Le futur vous en remerciera.
Phase 4 — Construire
Exécutez le scaffold, qui épingle 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'outils vidéo au dépôt du produit sauf demande expresse), copie useCamera.ts, et vous laisse un module de timeline à remplir.
Ensuite, dans l'ordre :
-
src/timeline.ts— calculs d'images et limites de plans. Choisissez un BPM dont le temps est un nombre entier d'images (à 60fps : 120 BPM = 30 images, 90 BPM = 40). Placez chaque limite de plan sur un temps. Même sans musique, cela donne au montage un rythme interne, et cela signifie qu'un fond musical peut être ajouté plus tard sans ré-éditer. -
src/data/script.<lang>.ts— chaque chaîne, chaque nombre, chaque élément de contenu de document, dans un seul fichier avec des commentaires de provenance. Rien n'est codé en dur dans les composants. Le ré-étalonnage temporel et la traduction deviennent tous deux triviaux. -
Composants — recréez l'interface utilisateur du produit. Copiez les vrais noms de classes. Si le produit utilise Tailwind, importez sa configuration et son CSS de thème ; s'il utilise des variables CSS pour les couleurs, vous devez les importer sinon tout s'affiche en noir et blanc.
-
src/scenes/ProductScene.tsx— un objetBexporté contenant chaque temps comme un numéro d'image absolu. Tout en dépend : 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 a généralement besoin de 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 a bougé.
python3 <skill-dir>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
Musique — references/music.md. Demandez avant d'en créer une. La plupart des gens ont un avis et beaucoup ont déjà un morceau ; demander coûte une phrase et peut économiser tout l'effort :
Voulez-vous un fond musical ? Si vous avez un morceau, envoyez-le et je calerai le montage dessus. Sinon, je peux en synthétiser un — énergique, calme, cinématique, minimal, chaleureux ou tendu ?
S'ils ont un morceau, calez le montage dessus : trouvez son BPM, réglez la timeline pour correspondre, déplacez les limites de plans sur ses mesures. Sinon, synthétisez un fond dont les changements d'arrangement tombent exactement sur vos coupes :
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
Placez une entrée sections sur chaque limite de plan réelle, une entrée hits sur votre coupe la plus importante, et une entrée ducks sous toute ligne soutenue que vous souhaitez lue plutôt que ressentie. Musique à ~0.30 de pic, effets à ~0.62. Choisissez l'ambiance en fonction de ce qu'est le produit — un sujet sérieux nécessite un fond plus calme, et un montage rapide nécessite un fond plus clairsemé.
Phase 6 — Vérifier avec des images fixes, avant de rendre
C'est la boucle serrée, et sauter cette étape 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 }) afin que les images fixes n'aient pas besoin du fichier audio pour exister.
Ajustez numériquement partout où vous le pouvez. Les courbes d'assouplissement, les distances de défilement, le 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 juste.
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 autour de 4 sur une machine de 16 Go — Remotion lance un onglet Chrome par emplacement et la valeur par défaut (nombre de cœurs) entraînera du swap.
Phase 7 — Remettre en toute honnêteté
Envoyez le fichier. Ensuite, dites clairement :
- Ce que vous n'avez pas pu vérifier. Vous pouvez lire les 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é — en particulier sur un produit verrouillé. Listez-les, et proposez de refaire ces temps s'ils partagent l'accès.
- Où vous avez fait un choix subjectif avec lequel ils pourraient être en désaccord.
- Comment changer la musique : déposez n'importe quel WAV ou MP3 dans
public/music.wavet relancez le rendu. - Tout ce que vous avez trouvé dans leur produit pendant la construction — un bug d'affichage, 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 à tous les charger d'un coup.
| fichier | quand |
|---|---|
references/discovery.md | Phase 1 — navigation, tri de 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 de cartes de chapitre, rédaction d'étiquettes de fonctionnalités, transitions, ordre |
references/camera.md | Construction des plans — espace de mise en page, caméra point focal, coupe 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, la retenue, la synthèse de clavier et de clics |
references/music.md | Trouver vs synthétiser un fond, choisir une ambiance, aligner les sections sur les coupes, mixer sous les effets |
references/pitfalls.md | Lisez ceci avant votre premier rendu. Bugs qui coûtent des heures réelles, chacun avec la correction. |
Scripts fournis
<skill-dir> ci-dessous est le répertoire de cette compétence elle-même — le chemin qui vous est donné lorsque la compétence est chargée. Ne supposez pas un emplacement d'installation fixe ; la compétence peut être installée personnellement, comme 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 un fond musical dans l'une des six ambiances, avec son arrangement aligné sur vos coupes. 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 du domaine. Les images sont l'unité de tout. Isolez un composant plutôt que de recadrer la page. L'animation d'interface utilisateur dure 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.