Vidéo produit en tant que code
Créez des vidéos produit en code : un deck HTML piloté par une timeline déterministe, une voix off IA, de véritables enregistrements d’écran du produit, et un master audio ffmpeg. Tout est reproductible, différentiable et re-rendable, donc les révisions coûtent des minutes au lieu d’une reconstruction.
Ce n’est pas un éditeur vidéo. C’est un pipeline. Le résultat est un MP4.
L’idée clé
L’audio d’abord, puis le timing, puis l’image.
Générez la narration avant de décider combien de temps chaque chose reste à l’écran. Mesurez chaque clip, déduisez les durées des scènes à partir de ces mesures, et ne rendez les images qu’ensuite. Les alternatives – deviner les durées ou écrire une narration pour correspondre à un storyboard fixe – produisent des visuels qui dérivent hors de synchronisation avec la voix et imposent un re-rendu à chaque fois qu’une ligne est reformulée.
script.json ──► TTS ──► mesure ──► timings.json ──► rendu ──► composition ──► mux ──► MP4
▲ ▲ ▲
assemble.py render.py composite.py
Pour une vidéo sans narration (un générique, une boucle silencieuse, un clip social sans son), sautez l’étape 1 et écrivez timings.json à la main. Tout ce qui suit reste inchangé.
Pipeline
| Étape | Script | Produit |
|---|---|---|
| 1. Narration | votre outil TTS préféré | audio/vo_NN.mp3, un par scène |
| 2. Timing + piste vocale | scripts/assemble.py | timings.json, out/voice.wav |
| 3. Image | scripts/render.py | out/silent.mp4 |
| 4. Séquence écran (optionnel) | scripts/capture/tour.py | capture/clips/*.mp4 |
| 5. Composition (optionnelle) | scripts/composite.py | out/composited.mp4 |
| 6. Master audio | scripts/mux.py | MP4 final |
Consultez references/PIPELINE.md pour la procédure détaillée, references/AUDIO.md pour la voix et la musique, references/SCREEN-CAPTURE.md pour les séquences produit, et references/PITFALLS.md avant de déboguer quoi que ce soit – il liste les échecs que ce pipeline a réellement rencontrés.
Types de vidéo
Même pipeline partout ; ce qui change, c’est la structure, le rythme et la part de l’écran occupée par le vrai produit. Identifiez lequel de ces types vous réalisez avant d’écrire une ligne, car cela décide tout le reste.
| Type | Durée typique | Forme | Séquence écran |
|---|---|---|---|
| Vidéo explicative produit | 1-3 min | problème → solution → fonctionnement → preuve → conclusion | peu, comme preuve |
| Lancement de fonctionnalité | 30-90s | ce qui a changé → pourquoi c’est important → voyez-le → comment l’obtenir | moyen |
| Démo / démonstration | 2-5 min | une tâche réelle, du début à la fin | dominant |
| Tutoriel | 3-10 min | étape par étape, chapitré, pauses pour suivre | dominant |
| Notes de version | 30-90s | un élément par temps fort, dense | captures d’écran ou courts clips |
| Intégration / onboarding | 1-3 min | le parcours initial, tel que l’utilisateur le rencontre | dominant |
| Générique / boucle | 5-20s | une idée, souvent silencieuse | aucun |
| Coupe sociale | moins de 60s | accroche d’abord, dérivée d’une version plus longue | court, percutant |
Règles empiriques selon le type :
- Démos et tutoriels sont d’abord centrés sur les séquences. Le deck est un cadre autour du produit – cartes titres, annotations, séparateurs de chapitres. Ne racontez pas ce que l’écran montre déjà.
- Vidéos explicatives et lancements sont d’abord centrés sur la narration. Les séquences apparaissent comme preuve d’une affirmation que vous venez de faire ; c’est cette proximité qui les rend percutantes.
- Les tutoriels nécessitent de l’air. Laissez un temps après chaque étape. Utilisez
--tailgénéreusement ; un spectateur suit, pas regarde passivement. - Les notes de version sont denses. Le texte à l’écran porte le message, la narration résume. Un élément par temps fort, sans traîner.
- Les coupes sociales sont dérivées, jamais écrites deux fois. Construisez-les comme un sous-ensemble de scènes de la version longue pour qu’elles ne puissent pas dériver (voir PIPELINE.md).
Démarrage rapide
Installation, une fois : pip install -r requirements.txt && playwright install chromium. ffmpeg et ffprobe doivent également être dans le PATH.
Silencieux d’abord, pour vérifier que le deck se rend correctement :
cp templates/deck.html .
python3 scripts/render.py --preview 2 8 18 # images fixes
python3 scripts/render.py # -> out/silent.mp4
Puis le pipeline complet une fois la narration générée :
cp templates/script.example.json script.json
# générer audio/vo_01.mp3 ... un par scène, puis :
python3 scripts/assemble.py # timings.json + out/voice.wav
python3 scripts/render.py # out/silent.mp4
python3 scripts/mux.py --final out/final.mp4 # ajoute la voix (+ musique si audio/bed.mp3 existe)
assemble.py est la seule étape qui nécessite de l’audio ; sans lui, render.py utilise les durées déclarées dans le deck.
Règles pour que cela fonctionne
Ne pilotez jamais la timeline à partir de l’horloge réelle. Le renderer se positionne à un t explicite et prend une capture d’écran. render.py appelle window.__seek(t) pour chaque image, donc une machine lente produit un fichier identique à une machine rapide. Tout ce qui utilise requestAnimationFrame ou une animation CSS se déchirera ou perdra des images sous une boucle de capture.
Ancrez chaque animation à un temps fort de la narration. Si la voix dit « trois choses » à 4,2 s, la troisième carte apparaît à 4,2 s. Après toute réécriture, revérifiez les temps forts – une ligne qui revient 3 s plus courte laissera ses visuels orphelins. C’est le plus grand facteur qui détermine si le résultat a l’air dirigé ou générique.
Rendez par morceaux repris. render.py écrit out/parts/part_NNN.mp4 et ignore les parties déjà complétées en cas de re-exécution. Une capture bloquée coûte un seul morceau, pas toute la passe. Ne lancez jamais deux rendus sur le même répertoire de parties.
Mesurez, ne supposez pas. Vérifiez avec des chiffres, pas des impressions :
- détection d’images vides : comptez les pixels sombres (
(pixels < 200).mean()), pas l’écart type – une page UI légitime avec beaucoup de blanc a aussi un faible écart type - prononciation : passez l’audio généré dans un outil de reconnaissance vocale et lisez le résultat
- niveaux :
ffmpeg -af volumedetectsur le fichier final, à chaque fois - géométrie : lisez
getBoundingClientRect()depuis le DOM plutôt que de coder en dur
Une source, plusieurs montages. Sélectionnez des sous-ensembles de scènes d’un seul deck avec un paramètre de requête (deck.html?cut=short) pour qu’une longue démo et une coupe sociale de 40 secondes ne puissent pas dériver. Voir references/PIPELINE.md.
Faire correspondre la marque du produit à partir de son code
Si le produit a un code source, lisez la marque depuis celui-ci plutôt que de demander des codes hexadécimaux :
python3 scripts/detect_brand.py ../leur-produit --css
Il lit les fichiers de tokens de design, les configurations Tailwind, les propriétés CSS personnalisées, les variables SCSS et Less, les objets thème JS/TS et le manifeste web, et rapporte les polices, la bibliothèque d’icônes et les fichiers logo trouvés. Collez le bloc :root qu’il affiche dans deck.html.
Les dossiers de build sont ignorés, car un dossier dist/ est rempli de CSS de bibliothèque de composants externalisés qui n’est pas la marque. La palette est également vérifiée pour sa cohérence, plutôt que d’être seulement approuvée sur la base des noms : un dépôt définissant --surface pour son thème clair et --bg pour son thème sombre donnerait sinon une carte blanche sur un fond noir. Les rejets sont affichés, jamais appliqués silencieusement.
Montrez à l’utilisateur ce qui a été détecté et ce qui a été rejeté avant le rendu.
Conseils de conception
Le deck est du HTML/CSS, donc le design est entièrement le vôtre. Deux choses sont à savoir :
Les contextes sociaux et de lecture automatique sont muets. Le titre à l’écran doit porter chaque temps fort seul, et l’accroche doit atterrir dans la première ou les deux premières secondes. Traitez la voix off comme un enrichissement, pas comme le mécanisme de transmission.
Si l’on vous demande quelque chose de visuellement distinctif, ancrez-le dans le propre monde du sujet – ses artefacts, instruments et vocabulaire – plutôt que de recourir à un fond sombre avec une seule couleur d’accentuation vive, là où se concentre la production générique. La compétence frontend-design d’Anthropic couvre bien ce sujet et se compose proprement avec celle-ci.