Compétence : Vidéo de Fonctionnalité Produit

Planifiez et construisez une vidéo de démo/fonctionnalité pour un produit réel en cours d'exécution — capturée sur des écrans réels via Playwright, narrée avec une vraie TTS, accompagnée d'une vraie musique de fond (open-source, licence propre) et assemblée dans Remotion. Il s'agit d'une discipline différente d'une bande-annonce synthétique en motion design : les séquences existent déjà et ne peuvent pas être redessinées pour s'adapter à un plan, donc le plan doit s'adapter aux séquences.

La différence clé avec une bande-annonce synthétique en motion design

De nombreux workflows vidéo Remotion supposent que vous contrôlez chaque pixel et pouvez tout retimer — car la vidéo entière est construite de zéro : maquettes, arrière-plans générés, UI inventée. Cette hypothèse ne tient pas ici. Un enregistrement d'écran réel suit son propre rythme ; un clic réel se produit sur une image spécifique, pas quand un storyboard le souhaite ; certains moments (une fenêtre OS native, la barre d'outils d'un navigateur, une interaction qui se termine en une demi-seconde) ne peuvent pas être re-filmés pour s'adapter à un plan. Cette compétence est construite autour de cette contrainte dès le départ — le savoir-faire en motion design (easing, transitions, densité de mouvement) compte toujours et est couvert dans la Phase 8, mais la véritable colonne vertébrale du pipeline est ce qu'exige spécifiquement une vidéo basée sur des séquences réelles : un audit des alternatives de prototype pour les moments impossibles à capturer, un ciblage stabilisé pour les zooms et les emphase de clics sur des séquences réelles, et un timing dicté par les durées réelles des assets plutôt que par un plan.

Principe central : séquences réelles d'abord, prototype ensuite, illustration en dernier

Pour chaque scène, privilégiez dans cet ordre :

Séquences réelles — un véritable enregistrement Playwright de l'application en cours d'exécution.
Un prototype HTML révisé, capturé de la même manière, pour tout ce que les séquences réelles ne peuvent pas montrer structurellement (voir Phase 2).
Un espace réservé honnête et clairement illustré — seulement lorsqu'aucune des deux options ci-dessus n'est réalisable, et uniquement s'il ne prétend pas être réel.

Ne simulez jamais l'option 1 avec l'option 3 déguisée pour paraître réelle. Un spectateur fait confiance à une vidéo de démonstration précisément parce qu'elle est réelle ; un seul moment fabriqué compromet tous les moments authentiques.

Phase 0 : Brief

Demandez une fois, ensemble, avant toute autre chose :

Produit et dépôt — nom, description en une ligne, URL/chemin local vers l'application ou le dépôt en cours d'exécution.
Public et ton — qui regarde, et que doivent-ils ressentir (impressionné / rassuré / excité) ?
Durée — teaser de 30s, présentation de 60 à 90s, ou visite plus complète de 2 à 3 min ? Les séquences réelles s'allongent vite ; soyez honnête sur la portée.
Le moment qui doit marquer — si le spectateur se souvient exactement d'une chose, quelle est-elle ? Cela devient le temps fort / climax.
Connexion / compte de test — la capture de l'application nécessite-t-elle un compte ? Un compte de démonstration jetable peut-il être créé, ou en existe-t-il déjà un ?
Contexte de publication — page d'accueil, YouTube, flux social (la lecture automatique en mode muet influence beaucoup les décisions concernant les sous-titres / texte à l'écran).

Si le produit est une extension de navigateur, demandez également si Manifest V3 est en jeu (cela modifie la stratégie de lancement de Playwright — voir Phase 6).

Phase 1 : Reconnaissance — extrayez le vrai système de design, n'en inventez pas

Avant toute décision esthétique, lisez le produit réel :

Récupérez les véritables tokens de couleur, la pile de polices et l'échelle d'espacement à partir du fichier CSS/theme de l'application. Utilisez-les tels quels, même si la couleur d'accentuation ressemble à un cliché « SaaS IA générique » (l'indigo/violet sur fond presque noir est extrêmement courant dans les palettes de produits réels aussi — ce n'est un drapeau rouge que lorsqu'il s'agit d'un défaut inventé, pas lorsque c'est le produit réel). L'authenticité prime sur la nouveauté ici.
Notez le texte réel de l'interface utilisateur du produit, sa terminologie et son architecture de l'information — les légendes et la voix off de la vidéo doivent utiliser les propres mots de l'application, pas une paraphrase marketing.
Exécutez l'application une fois, de bout en bout, comme le ferait un utilisateur. Identifiez : quelle est la meilleure interaction « phare » ? Qu'est-ce qui est vraiment difficile à démontrer en direct (voir Phase 2) ?

Enregistrez les tokens extraits (couleurs, polices) dans un fichier tokens.ts/tokens.css que l'ensemble du projet vidéo importe depuis un seul endroit — chaque scène, réelle ou générée par code, doit visiblement appartenir au même produit.

Phase 2 : Audit des Alternatives de Prototype (faites-le avant le storyboard)

Parcourez la liste des fonctionnalités planifiées et identifiez tout ce que Playwright ne peut structurellement pas capturer :

Chrome du navigateur au niveau OS — l'icône de la barre d'outils de l'extension, chrome://extensions, les menus contextuels du bouton droit, les sélecteurs de fichiers natifs, les boîtes de dialogue OS natives. Le recordVideo de Playwright ne capture que le contenu de la page, jamais l'interface utilisateur du navigateur lui-même.
Shells de bureau natifs (Tauri, Electron une fois packagé, Qt, etc.) — ce ne sont pas des pages web auxquelles Playwright peut se connecter du tout.
Interactions trop rapides ou trop petites pour être présentées de manière fiable — un basculement qui se termine en moins d'une demi-seconde de séquence réelle est une mauvaise cible pour un zoom ou un cercle d'emphase de clic ; les deux nécessitent une fenêtre stable de plusieurs images pour atterrir (voir le motif ZoomCue/ClickRing de la Phase 8 et sa règle de stabilité).

Pour chaque moment identifié, décidez : séquence réelle avec une solution de contournement (par exemple, définir l'état via un appel API au lieu d'un clic réel, selon la Phase 6), un prototype HTML révisé (Phase 7), ou une illustration honnêtement étiquetée (dernier recours, et mentionnez-le dans un commentaire de code).

Faire cet audit avant le storyboard, pas après, empêche le storyboard de s'engager sur un timing et une couverture que l'étape de capture réelle ne peut pas fournir — c'était la source la plus importante de reprise dans les versions v1 à v3 de TabNemo.

Phase 3 : Storyboard et Plan de Scènes

Arc narratif

La même structure fonctionne, que les séquences soient réelles ou synthétiques :

Acte	Objectif	Part du temps total
Accroche	Ouverture à froid — le problème, ou un moment frappant, avant l'apparition du nom du produit	5-8%
Révélation	Le nom de la marque/produit atterrit	8-10%
Démonstration	3 à 5 fonctionnalités réelles, un temps fort chacune	45-55%
Climax	Le moment phare identifié dans la Phase 0 — accordez-lui le plus grand soin visuel	8-12%
Clôture	Logo, slogan, CTA	8-10%

Spécifications par scène

Pour chaque scène, décidez à l'avance et notez :

Source : clip réel / capture de prototype / b-roll généré par code (selon l'audit de la Phase 2).
Narration : texte exact, ou null. La longueur de la narration est une contrainte réelle — la durée audio TTS devient la durée minimale de la scène (voir Phase 4).
Les séquences réelles suivent leur propre rythme — la durationInFrames d'une scène est max(durée du clip réel, durée de la narration), déterminée à partir des assets réellement rendus, jamais supposée à partir d'un plan. Lorsque la narration dépasse le clip, maintenez la dernière image du clip plutôt que de boucler ou de couper la ligne.
Plan de caméra : tout zoom ou emphase de clic, avec des coordonnées réelles — décidées à partir d'images réelles, non devinées (Phase 8).

Point de contrôle de révision

Montrez la liste des scènes + le texte de narration avant d'enregistrer un seul clip ou de générer une note audio. Un plan basé sur des hypothèses erronées concernant les séquences disponibles est coûteux à défaire une fois que les scripts TTS et Playwright existent.

Phase 4 : Voix off — script et génération

Écrivez deux documents, pas un :

Un script de révision — un bloc par scène, avec son timecode prévu, afin qu'un humain puisse lire l'ensemble de l'arc de narration et approuver le rythme avant la génération.
Un script d'entrée TTS — les mêmes lignes, divisées une par fichier de scène, le rythme porté uniquement par la ponctuation (ou les balises SSML <break>/<emphasis> si le moteur les prend en charge), afin que chaque scène devienne son propre clip audio positionnable à son propre décalage.

Outils de génération

ttsmp3.com — gratuit, sans inscription, basé sur Amazon Polly. Pas d'API publique, donc la génération se fait un clip à la fois via l'interface du navigateur — prévoyez une session dédiée pour tous les faire, et nommez les fichiers de sortie par scène (scene-03.mp3, pas tts_export_1.mp3).
Pour un pipeline qui doit fonctionner sans surveillance (CI, un agent sans navigateur dans la boucle), privilégiez une option open-source/locale réellement scriptable : Piper (totalement hors ligne, licence MIT, rapide, voix décentes) ou edge-tts (encapsule les voix de lecture à voix haute de Microsoft Edge, gratuit, sans clé, scriptable, mais dépend d'un service externe restant disponible). Gemini TTS et ElevenLabs sont de solides alternatives non open-source si le coût de l'API est acceptable. Quel que soit le moteur, s'il ne garantit pas la cohérence vocale entre les appels séparés, générez tous les segments dans une seule requête avec des marqueurs de pause entre eux, puis divisez sur le silence détecté — cette astuce résout le problème de « voix différente par ligne » quel que soit le moteur.

Après la génération — l'audio est la source de vérité

Mesurez la véritable durée de chaque fichier généré (ne faites pas confiance à une estimation). Reportez les durées réelles dans le timing du plan de scènes. Cette seule étape a évité tous les bugs de timing dans la construction de TabNemo — la narration est ce que l'oreille du spectateur utilise pour mesurer une scène, donc c'est elle, pas le plan, qui fixe le rythme.

Phase 5 : Musique de fond — trouvez-en une accrocheuse sans piège de licence

Une boucle de nappes plates et de drones ressemble à une musique d'ascenseur, pas à une bande-son « accrocheuse » — la différence est presque toujours un motif mélodique répété, pas seulement des nappes harmoniques. Trois options réelles, par ordre de « licence la plus sûre » à « la plus fiablement accrocheuse » :

Option A — Synthèse procédurale (risque de licence zéro, nécessite un réel effort pour ne pas sonner plat)

Générez un WAV stéréo court et parfaitement bouclable en Node/Python simple — pas de modèles, pas de dépendances, aucune question de licence, car vous avez écrit chaque échantillon. La recette concrète qui a fonctionné :

Une courte boucle d'accords (8 à 16 mesures) utilisant des oscillateurs simples (sinus/triangle) avec des enveloppes d'attaque/relâchement lentes — cela seul est le piège de la « musique d'ascenseur » ; ce N'EST PAS l'accroche.
L'accroche réelle : une mélodie de cordes pincées Karplus-Strong par-dessus, dans un motif rythmique répété fixe, une octave au-dessus de la nappe — c'est ce qui rend une boucle synthétisée mémorable plutôt qu'un fond d'ambiance. Ne sautez pas cette couche.
Une pulsation de kick doux + hat en dessous pour un mouvement vers l'avant, suffisamment silencieuse pour se situer sous la narration.
Normalisez pour laisser de la marge, choisissez la longueur de la boucle pour que toute la progression se termine sur une limite de mesure (pas de couture audible).

C'est totalement sûr à expédier commercialement, mais la couche d'accroche mélodique est ce qui sépare « accrocheur » de « générique » — prévoyez une véritable itération dessus, et obtenez une écoute et confirmation de l'utilisateur avant de l'intégrer dans un rendu complet (régénérer une boucle de 15 à 20 secondes est bon marché ; re-rendre toute la vidéo pour auditionner une boucle différente ne l'est pas).

Option B — Modèles de musique générative à poids ouverts (plus « produit », vérifiez la licence à chaque fois)

Stable Audio Open de Stability AI — poids ouverts, guidé par texte, produit véritablement des arrangements complets avec un contenu mélodique réel. Les conditions de licence sont plus permissives que la plupart des modèles audio génératifs mais comportent des conditions basées sur les revenus — relisez la licence actuelle avant toute utilisation commerciale, car ces conditions évoluent.
MusicGen de Meta (via la bibliothèque audiocraft) — excellente qualité, mais ses poids de modèle musical sont généralement sous licence CC-BY-NC (non commercial) — n'utilisez pas la sortie générée dans une vidéo de lancement d'un produit monétisé sans l'avoir autorisée séparément.
Les deux peuvent fonctionner localement (GPU recommandé) ou via un point de terminaison d'inférence hébergé (Replicate, Hugging Face Spaces) si le calcul local n'est pas disponible.

Option C (recommandée par défaut) — utilisez B pour l'idée, expédiez A pour l'actif

Incitez un modèle à poids ouverts localement pour l'inspiration uniquement (« accroche synth-pop accrocheuse, ~110bpm, ambiance produit tech chaleureuse et optimiste »), écoutez quelques générations, retenez un motif ou un mood qui vous plaît, puis synthétisez procéduralement un équivalent bouclable sans licence à l'aide de la recette de l'Option A. Cela vous donne une idée mélodique validée sans aucun risque de licence dans le produit final.

Phase 6 : Capture Playwright — enregistrement réel, pas maquette

Écrivez un script Playwright (.spec.ts ou .mjs) pour chaque scène marquée comme séquence réelle dans le storyboard. Chaque script doit :

Démarrer Chromium avec recordVideo activé.
Accorder du temps mort à l'application pour charger les assets et la navigation.
Effectuer les étapes réelles de l'utilisateur : clics, ajouts de texte, navigation.
Ne pas fermer le navigateur pendant 2 à 3 secondes après la dernière action — cela garantit que le dernier état est visible suffisamment longtemps pour un rendu stable.
Enregistrer dans un dossier raw-clips/ avec un nom descriptif (par exemple, scene-04-add-widget.mp4).

Solutions pour les moments structurellement impossibles (de l'audit de la Phase 2)

Pour les États Dépendant du Chrome du Navigateur (icône d'extension, menus contextuels) : utilisez la vue chrome-extension://<id> ou injectez directement les styles/popups dans la page. Si cela échoue, passez à l'Option 2 (prototype HTML).
Pour les Interactions Trop Rapides (bascules, animations de 200 ms) : pré-conditionnez l'état via l'API avant l'enregistrement — appelez l'API pour activer le paramètre, puis enregistrez uniquement l'état résultant. Cela évite le problème de minuterie d'image de Playwright où un clic et un changement d'interface utilisateur peuvent se produire dans la même image.

Vérification de cohérence

Avant de passer à la Phase 7, lisez chaque clip et comparez-le au storyboard : le clip montre-t-il exactement ce que la scène décrit ? Si non, re-enregistrez (les scripts Playwright sont bon marché à réexécuter ; les compositions Remount ne le sont pas).

Phase 7 : B-roll Généré par Code — éléments dans le navigateur et composants Remotion

Pour les moments d'illustration (Option 3, ou transitions / arrière-plans), construisez de petits composants Remotion :

Écran de chargement stylisé — un spinner ou une barre de progression aux couleurs du produit (tokens de la Phase 1).
Superposition d'icône de fonctionnalité — l'icône de la fonctionnalité actuelle (par exemple, une icône d'engrenage pour « paramètres ») apparaît brièvement avant que le clip réel ne commence.
Animation de point d'emphase de clic — un cercle qui se dilate brièvement à l'endroit du clic, avec un fondu (utilisez les coordonnées exactes de l'image de la Phase 8).

Tous ces composants importent tokens.ts pour garantir une cohérence visuelle. Aucun d'eux ne simule l'interface utilisateur réelle du produit — ils embellissent la présentation, pas la remplacent.

Phase 8 : Montage dans Remotion — la composition finale

Structure de la composition

Créez un unique <Sequence> racine qui importe tous les assets de scène :

Clips vidéo (de raw-clips/) — importés via @remotion/player ou en tant que <Video> sources.
Fichiers audio (de voiceover/) — chaque scène a son propre <Audio> avec le décalage de début calculé à partir de la durée des scènes précédentes.
Fichier de musique de fond — une seule boucle audio (de la Phase 5) qui traverse toutes les scènes, avec un crossfade d'entrée/sortie de 1 à 2 secondes.
Composants de b-roll (de la Phase 7) — superposés comme calques, pas comme remplacement de séquence.

Motifs de mouvement : ZoomCue et ClickRing

Deux motifs de mouvement standard pour les vidéos basées sur des séquences réelles :

ZoomCue : un zoom avant lent (échelle 1.0 → 1.15-1.2) sur une région d'intérêt, avec un easing en douceur (cubic-bezier de easeInOutCubic). La règle de stabilité : l'image de zoom doit commencer et se terminer sur des images qui diffèrent d'au moins 15 images (0.5s à 30fps), sinon le zoom semble saccadé. Appliquez-le avec un style={{ transform: scale }} avec un point de transformation défini sur les coordonnées de la région.
ClickRing : un petit cercle (échelle 0 → 1.2, opacité 1 → 0) à la position du clic, durant 12 à 15 images, synchronisé avec l'image réelle du clic. Déterminez la position du clic à partir de l'image réelle (lisez le clip dans un moniteur, mettez en pause sur l'image du clic, notez les coordonnées x,y).

Règle de superposition de texte

Pour les publications sur les réseaux sociaux (flux, lecture automatique muette), les légendes doivent être intégrées — pas de formats de sous-titres séparés. Remotion peut les générer en natif en tant que calques de texte. Pour YouTube, les sous-titres séparés sont acceptables, mais la vidéo doit toujours être compréhensible sans audio (le texte à l'écran pour les titres de fonctionnalités, les labels, etc.).

Phase 9 : Export — la dernière exécution

Avant l'export final, exécutez cette liste de contrôle :

Tous les clips sont-ils lisibles ? — Playwright produit parfois des fichiers .webm corrompus ou tronqués ; lisez chaque clip une fois dans Remotion avant un rendu complet.
La narration est-elle synchronisée ? — Le décalage de début de chaque scène est-il calculé par rapport à la durée réelle de l'audio (de la Phase 4), pas à partir d'une estimation ?
La musique de fond est-elle trop forte ? — Normalisez la musique de fond à -18dB à -24dB par rapport à la narration. Testez sur un haut-parleur de téléphone et des écouteurs.
Les couleurs correspondent-elles au produit ? — Tous les éléments générés par code (b-roll, texte, arrière-plans) utilisent-ils les tokens de la Phase 1 ?
Le plan de licence est-il documenté ? — Dans un fichier LICENSE-NOTES.md, notez : la source de la musique de fond et sa licence, les voix TTS et leurs conditions d'utilisation, tous les assets tiers et leurs attributions.

Commande d'export

npx remotion render src/index.ts video output.mp4

Ajoutez --concurrency=8 ou plus si votre machine le supporte. Pour les vidéos longues (plus de 2 minutes), un rendu avec un GPU dédié est fortement recommandé.

Conseils Finaux

Commencez petit : Une vidéo de 30 secondes avec 2 fonctionnalités est meilleure qu'une vidéo de 3 minutes jamais terminée. Validez le pipeline avec une courte vidéo d'abord.
L'authenticité prime : Les spectateurs pardonnent une qualité de production imparfaite si l'application est réelle et utile. Ne sacrifiez pas la réalité pour la perfection.
Itérez sur la musique : La musique de fond est ce qui donne le ton émotionnel ; passer 30 minutes à la peaufiner peut transformer une vidéo de « acceptable » à « convaincante ».
Documentez les licences : Gardez la trace de toutes les licences des assets — cela évite les maux de tête juridiques plus tard.

Basé sur l'expérience de construction de vidéos pour TabNemo, une extension de navigateur open-source. Adapté aux workflows Playwright + Remotion.

akmishra56/product-video-skill

Qu'est-ce que product-video-skill ?

Demander à votre IA préférée

Documentation