smasikurr/RemotionMaster

Lancement Produit

Comment utiliser ce playbook. C'est une recette, pas un ensemble de règles : chaque format, longueur, cadence et formule ci-dessous sont des valeurs par défaut, et la demande de l'utilisateur prévaut. Ne commencez pas par des questions : utilisez les valeurs par défaut, construisez, et mentionnez les valeurs par défaut que vous avez choisies en une ligne lorsque vous partagez le premier rendu (ne demandez que si quelque chose d'essentiel manque, comme la vidéo elle-même). Le premier rendu est la proposition, donc il n'y a pas de plan à approuver au préalable. Les storyboards uniquement lorsque l'utilisateur demande à voir les plans au préalable. Les fichiers de planification mentionnés par la méthode (BRIEF.md, PLAN.md et autres) sont vos propres notes de travail : écrivez-les quand ils vous aident, jamais comme une étape pour l'utilisateur.

Un produit entre ; une vidéo de lancement soignée sort. Le genre de vidéo que l'on voit sur X lorsqu'une équipe SaaS publie : une accroche qui nomme le problème, le nom du produit qui tombe sur un temps fort, trois fonctionnalités présentées dans l'interface réelle, une preuve, et un écran de fin propre. Rythmée par la musique, généralement sans voix off, 20 à 60 secondes.

Référence : la démo de lancement de Notion par Moritz (46 s, 16:9, pas de voix off, 120 BPM). Neuf plans : accroche avec outils éparpillés sur fond sombre, logo et titre rotatif sur le temps fort, la vidéo héros réelle dans une fenêtre flottante, trois plans de fonctionnalités (capture, demande, agents) construits à partir de l'interface réelle de Notion, un rouleau de cas d'utilisation, un mur de logos avec des statistiques, et un bloc d'appel à l'action. Son plan se trouve dans references/example-notion.md. Atteignez ce niveau.

La méthode est fixe ; l'outil ne l'est pas. Si le projet a déjà un outil vidéo, utilisez-le. Sinon, démarrez un projet Hyperframes (npx hyperframes init), et copiez template/hyperframes/ comme composition de départ.

<playbook> ci-dessous signifie ce dossier (le chemin local retourné par get_playbook).

Ce qui entre, ce qui sort

• Entrée : ce qui est lancé (URL, l'application elle-même, captures d'écran, enregistrements, un brief ou un script copié), à qui cela s'adresse, où cela sera publié. En option : fichiers de marque, un script de voix off, une piste musicale.
• Sortie : un mp4 de 20 à 60 s (16:9 par défaut, 9:16 ou 1:1 sur demande) avec l'interface utilisateur réelle, du texte cinétique, de la musique et des effets sonores sur une même grille de beats, révisé et approuvé dans FrameJam.

Valeurs par défaut (la demande de l'utilisateur prévaut sur chacune d'elles)

Établissez-les à partir de la demande et des fichiers. Lorsque rien n'est dit, utilisez la valeur par défaut et continuez ; ne demandez que si quelque chose d'essentiel manque.

• La promesse en une ligne. Ce que le spectateur doit retenir. Tout le reste est une preuve de cette promesse.
• Durée et format : flux X 30–45 s 16:9 (par défaut) ; vidéo héros de page d'accueil 30–45 s 16:9, muette d'abord ; Reels 9:16 ≤ 30 s.
• Son : musique uniquement (par défaut, joue en sourdine en lecture automatique, donc le texte porte l'histoire) ou voix off + musique.
• Source d'interface réelle : l'application en cours d'exécution (enregistrez-la), le site web (capturez des captures d'écran et sa vidéo héros), ou les fichiers fournis par l'utilisateur. S'il n'y a rien de réel à montrer, dites-le ; n'inventez pas d'interface.
• Style : Utilisez le style choisi pour cette vidéo, s'il y en a un (à partir de wait_for_pick, ou de get_preset lorsque l'utilisateur en nomme un). Si l'utilisateur a choisi un style FrameJam, il définit l'ensemble de l'apparence (palette, typographie, sensation de mouvement, transitions). Pas de style : dérivez l'apparence de la marque du produit (couleurs, polices, surfaces de l'interface).
• Faits : statistiques, logos clients et affirmations provenant uniquement du site web du produit ou de l'utilisateur. Pas de chiffres inventés.
• Musique : le script gratuit inclus (scripts/launch_bed.py) par défaut, une piste appartenant à l'utilisateur, ou une piste de bibliothèque sous licence. Les services de musique générée sont payants ; arrêtez-vous et demandez avant d'en utiliser un.

Projet existant réalisé avec un autre outil : restez dans cet outil. La méthode (grille de beats, storyboard, interface réelle dans des fenêtres, révélations rythmées, vérification, boucle FrameJam) et les scripts (launch_bed.py, sheet.sh) fonctionnent avec n'importe quel outil.

Lorsque rien n'est dit : musique uniquement, 16:9, ~40 s, l'apparence de la marque. Nommez les valeurs par défaut que vous avez utilisées lorsque vous partagez le premier rendu.

Flux de travail

1. Collecter le produit réel

Rassemblez le matériel avant d'écrire une seule ligne. Détails dans references/assets.md.

• Application : enregistrez de courtes prises propres de chaque fonctionnalité (une action par prise, 2880 px de large ou plus, pas de notifications, des données de démonstration réalistes). Conservez les chronologies des événements (quand le clic atterrit, quand le résultat apparaît).
• Site web : sauvegardez la vidéo héros, des captures d'écran pleine page et de sections en 2x, le logo (SVG), les polices, les titres exacts, les statistiques et les logos clients. Les utilisateurs d'Hyperframes peuvent exécuter npx hyperframes capture <url> -o capture.
• Écrivez ASSETS.md : une ligne par fichier avec ce qu'il montre, sa taille, et pour les vidéos les moments clés en secondes.
• Vérité de la marque : couleurs (encre, toile, un accent), polices d'affichage et de corps, aspect de l'interface (rayon, ombre, chrome).

2. Histoire et grille de beats

Lisez references/story.md. Ensuite, écrivez STORYBOARD.md :

• Choisissez un arc (problème → plateforme, boucle de démonstration, avant/après, cascade de fonctionnalités). Écrivez la promesse en une ligne.
• 6 à 10 plans. Chaque plan a un travail : accroche, introduction du produit, fonctionnalité, bénéfice, preuve, appel à l'action. Une fonctionnalité est présentée comme une courte séquence sur la surface réelle (entrée → action → résultat), pas une capture d'écran statique.
• Agents et assistants IA : montrez une demande réelle de bout en bout : elle est tapée dans l'entrée et envoyée, devient un message, les étapes de l'agent apparaissent une par une (les précédentes s'estompent), le résultat atterrit sous forme de carte avec des faits exacts et une coche, et le plan s'attarde sur le résultat avant le bloc de fin. Les demandes et les résultats sont spécifiques (noms, heures, comptes), jamais de texte générique.
• L'accroche dure 3 à 4 secondes et fonctionne en muet : la douleur ou le désir du spectateur dans ses propres mots, jamais « X est une plateforme qui… ».
• Grille de beats d'abord. Choisissez un tempo (110–128 BPM ; à 120 BPM, un beat dure 0,5 s, une mesure 2 s). Chaque plan commence sur un temps fort et dure un nombre entier de mesures. Marquez les temps forts : généralement le nom du produit et la section de preuve. Chaque révélation dans chaque plan atterrit sur un beat.
• Avec voix off : écrivez SCRIPT.md en courtes répliques (6–20 mots par plan) et laissez la voix définir la durée des plans ; la musique suit toujours la grille en dessous.
• Écrivez un bloc ## Direction vidéo une fois en haut : rôles de la palette, rôles des polices, comment les fenêtres entrent, règles de mouvement, quels plans sont des plans « d'impact » sombres, ce qui n'apparaît jamais.

Ensuite, construisez ; le premier rendu est la proposition. Si l'utilisateur veut voir les plans d'abord, esquissez-les et révisez-les dans FrameJam sous forme de storyboard : open_review avec panelsDir (une image par plan, nommée 01-hook.png…), puis wait_for_feedback.

3. Conception des plans

Pour chaque plan, écrivez une liste de plans avec code temporel par rapport à la grille de beats (references/shots.md) : Scène 1 (0,0–0,5 s) : … avec ce qui est à l'écran, où cela se trouve, et comment cela bouge. Règles :

• À t=0, montrez uniquement la première chose. Chaque autre élément arrive sur son beat (ou son mot parlé). Ne déversez jamais tout le plan dans le premier quart et ne le laissez pas reposer.
• L'interface réelle se trouve dans une fenêtre de produit flottante (rayon de la marque, bordure fine, ombre douce en couches) avec un équilibre 3D à l'entrée. Ne coupez jamais le texte de l'interface au milieu d'un mot. Reconstruisez uniquement le composant qui doit bouger (une zone de recherche qui tape).
• Une couleur d'accent par plan, un mot surligné par titre.
• Terminez chaque plan sur une lecture soutenue. L'immobilité est préférable à un souffle paresseux ou à une caméra dérivante.
• Transitions entre les plans : coupes franches sur le beat par défaut ; zoom traversant lors des changements de section ; poussée-glissade pour une série de fonctionnalités.

4. Musique et son

Lisez references/music.md. Route par défaut, gratuite : écrivez cues.json à partir du storyboard (sections en mesures, temps forts, et un effet sonore pour chaque claquement, pop, clic, frappe et entrée de fenêtre), puis uv run <playbook>/scripts/launch_bed.py cues.json --out assets/music/bed.wav (ou python3 avec numpy, scipy et soundfile). Les effets sonores proviennent de la même feuille de repères, ils se situent donc exactement sur les coupes. Si l'utilisateur apporte une piste : mesurez son tempo, coupez la grille en fonction, et commencez la piste à sa section la plus forte plutôt qu'à une introduction lente.

5. Construction

Construisez plan par plan dans l'outil du projet. Les notes sur Hyperframes (et les pièges que nous avons rencontrés) se trouvent dans references/hyperframes.md ; le starter est template/hyperframes/.

• Une composition par plan, ou un fichier avec un calque par plan pour les pièces courtes. Conservez des temps locaux au plan.
• Animer avec des états de départ explicites (sûrs pour la recherche), des transitions longues (power3/expo.out), pas de rebond, pas de boucles infinies, pas d'aléatoire.
• Vidéos de produits : donnez à chaque <video> un identifiant ; déplacez une div d'encapsulation pour les mouvements de caméra, pas l'élément vidéo.
• Avec des sous-agents parallèles disponibles, donnez à chacun un plan : son bloc de storyboard, ## Direction vidéo, les lignes d'actifs qu'il utilise, et « éditez uniquement votre fichier ». Sinon, construisez dans l'ordre vous-même.

6. Vérification, rendu, révision

• Vérifiez dans l'outil, puis effectuez le rendu dans un nouveau fichier par version (renders/v1.mp4, v2.mp4…).
• bash <playbook>/scripts/sheet.sh renders/v1.mp4 crée une planche contact à 2 images par seconde ; lisez-la. Regardez le milieu de chaque plan et les deux côtés de chaque coupe. Vérifiez : rien ne se produit au début, aucun texte coupé ou sous la bande de légende, aucun saut aux joints, le temps fort atterrit avec le nom, la carte de fin dure ≥ 1,5 s.
• ffmpeg -i renders/v1.mp4 -vf freezedetect=n=0.003:d=2 -f null - signale les passages figés ; un figement est acceptable uniquement là où vous avez prévu une pause.
• Révision dans FrameJam : open_review avec videoPath = le rendu (chemin absolu), ouvrez l'URL dans le navigateur intégré, wait_for_feedback. Mappez chaque note à son plan par horodatage, corrigez, effectuez le rendu de v2, vérifiez à nouveau, puis add_version avec une note d'une ligne et attendez à nouveau. Répétez jusqu'à approbation.
• Livrez le mp4 final (X : H.264, ≤ 2:20, ≤ 512 Mo) avec sa durée et la liste des plans.

Niveau de qualité

• Produit réel, fidèlement : chaque plan d'interface est un enregistrement ou une capture d'écran réel. Les copies, statistiques et logos proviennent des sources du produit. Logos tiers uniquement là où le produit lui-même les montre (intégrations, clients).
• La promesse atterrit au plan 2. L'accroche parle de la douleur ou du désir du spectateur ; le nom arrive sur le temps fort.
• Chaque révélation est sur un beat (ou son mot parlé), et la musique, les effets sonores et les coupes partagent une seule grille.
• Lisible en un coup d'œil : 1 à 7 mots par titre, ≥ 64 px en 1080p, un point focal par plan.
• Mouvement premium : équilibres fluides, fenêtres avec profondeur, raccords de vélocité ; pas de rebond, pas de flottement d'économiseur d'écran, pas de formes génériques de stock représentant le produit.
• Fonctionne en muet : l'histoire se lit à partir du texte et de l'interface seule.
• Regardez vous-même (planche contact + vérification des coupes) avant chaque tour FrameJam.

Fichiers dans ce playbook

• references/story.md : arcs, rôles des plans, types d'accroche, formes de lignes éprouvées pour chaque rôle, règles de voix off.
• references/shots.md : formes de plans pour les plans de lancement, règles de disposition et de mouvement, raccords, une liste de plans travaillée.
• references/assets.md : enregistrement de l'application, capture d'un site, liste des actifs, droits.
• references/music.md : grille de beats, format cues.json, utilisation de votre propre piste.
• references/hyperframes.md : démarrer de zéro dans Hyperframes, fenêtres de produit, vidéo et audio, pièges.
• references/example-notion.md : le plan de la démo de lancement de Notion, plan par plan.
• scripts/launch_bed.py : bande sonore locale gratuite et effets sonores à partir d'une feuille de repères.
• scripts/sheet.sh : planche contact de n'importe quel rendu.
• template/hyperframes/ : une composition de départ (aides à la grille de beats, fenêtre de produit, ligne cinétique, puce, carte d'appel à l'action).