nolan

Que fait nolan ?

Un réalisateur n'appuie pas sur « enregistrer » en espérant que ça marche. Il storyboarde chaque plan, le cadre, et tourne des prises complètes. nolan fait la même chose pour les démos logicielles : il transforme une fonctionnalité en storyboard, pilote votre vraie application à l'écran, narre chaque étape comme un chef de produit qui présente le produit à un utilisateur, et capture une vidéo propre par scène.

Le résultat est une démo, pas un test de fumée — le genre de clip que vous mettriez sur une page d'accueil ou enverriez à un client, où un spectateur novice comprend à la fois ce qui se passe et pourquoi c'est important.

Quand utiliser cette compétence

Utilisez-la dès que le vrai travail est « produire une vidéo regardable de ce produit en train de faire quelque chose, destinée à une personne qui ne l'a jamais vu ». Cela inclut les clips de lancement, les présentations de fonctionnalités, les vidéos héros de page d'accueil, les tutoriels d'intégration et les GIF d'annotations de version.

Ne l'utilisez pas pour tester un flux — c'est un test de bout en bout, qui doit être concis et sans tête. nolan optimise pour l'inverse : clarté, rythme et narration pour un public humain.

Le workflow — trois étapes

Étape	Vous demandez…	nolan produit	Référence
🎬 Storyboard	« planifier une démo de la fonctionnalité X »	Un storyboard scène par scène (JSON) : cartes-titres, légendes, les clics/saisies exacts, et quoi attendre	reference/storyboard.md
🎥 Enregistrer	« enregistrer »	Un .webm par scène, piloté en direct sur l'application en cours avec cartes-titres superposées + légendes de sous-titres	reference/recording.md
✨ Polir	« rendre ceci regardable »	Une prise revue et refaite : rythme corrigé, actions complètes, légendes lisibles, cadrage ajusté	reference/polish.md

Les étapes s'enchaînent : storyboard → enregistrer → regarder le résultat → polir → réenregistrer. Le storyboard est la source de vérité ; l'enregistrement en est déterministe.

Les quatre disciplines (non négociables, chaque vidéo)

Ce sont ce qui distingue une démo d'une capture d'écran. Elles ne sont pas optionnelles.

1. Voix de chef de produit, pas de test de fumée. Racontez la valeur pour l'utilisateur — ce que cela lui permet de faire et pourquoi c'est bien — jamais les mécanismes de test. Chaque légende se lit comme si un chef de produit guidait un client dans le produit. Voir reference/pm-voice.md.

2. Contenu quotidien et compréhensible à l'écran. Seules des saisies qu'un public général comprend déjà apparaissent dans l'interface — questions normales, exemples concrets (« acheter du lait d'avoine », « une note de remerciement à un collègue »). Jamais de jargon de niche, de noms de code internes ou de concepts « extraterrestres » que le spectateur doit décoder. L'accessibilité avant tout.

3. Montrer, puis dire. Chaque scène commence par une carte-titre plein écran (produit + nom de la scène) et porte des légendes de sous-titres intégrées (une bannière en haut) qui narrent chaque étape au fur et à mesure, pour que aucun spectateur ne soit jamais perdu. Voir reference/captions.md.

4. Prises complètes sur l'application réelle. Pilotez le produit réel en direct — saisie visible au rythme humain et vrais clics — et attendez que chaque action soit entièrement terminée avant de passer à la suivante, puis faites une pause pour que ce soit lisible. Ne coupez jamais une réponse ou une transition en plein milieu. La longueur sert l'exhaustivité.

Procédure standard

1. Cadrer la démo. Quel produit, quelle(s) fonctionnalité(s), à quelle URL est-il servi, et qui est le public ? Confirmez que l'application est en cours d'exécution et accessible (nolan filme une application vivante ; il n'en simule pas).
2. Storyboard. Ébauchez storyboard.json — une scène par idée, chacune avec une carte-titre, des étapes ordonnées (taper / cliquer / sélectionner / attendre), et des légendes en voix de chef de produit. Utilisez assets/storyboard-template.json comme modèle. Gardez les invites génériques (§2).
3. Prévisualiser les sélecteurs. Vérifiez que les espaces réservés / rôles / textes ciblés par le storyboard existent réellement dans le DOM avant un tournage complet (un mauvais sélecteur gâche toute une prise). reference/recording.md couvre la sélection robuste.
4. Enregistrer. Exécutez scripts/record.py storyboard.json [scène ...]. Il injecte la superposition de légendes/cartes-titres, pilote chaque scène, attend la fin, et sauvegarde un .webm par scène dans le out_dir du storyboard.
5. Regarder le résultat et polir. Vérifiez chaque discipline par rapport à reference/polish.md — y a-t-il des coupures, du jargon dans les légendes, la saisie semble-t-elle humaine, chaque action est-elle complète ? Corrigez le storyboard et refilmez uniquement les scènes concernées.
6. Livrer. Rapportez où se trouvent les fichiers, leurs tailles/durées, et une description d'une ligne par scène. Proposez une image d'aperçu ou un GIF si utile.

Configuration attendue par nolan

• Python + Playwright (pip install playwright && playwright install chromium). scripts/record.py utilise l'API synchrone et record_video_dir pour capturer du .webm.
• Une application en cours d'exécution à une URL accessible par la machine (serveur de dev local ou environnement déployé que vous êtes autorisé à filmer).
• Des données de démonstration réalistes et non sensibles chargées dans l'application — voir discipline §2 et la note sur les données dans SECURITY.md. Ne filmez jamais de véritables données client ou secrets.
• Optionnel — narration parlée. Par défaut, la démo est silencieuse (les légendes portent le message). Pour ajouter une voix off qui sonne humaine, ajoutez un bloc voice au storyboard et des lignes vo aux étapes ; cela nécessite ffmpeg (brew install ffmpeg) plus un fournisseur TTS — ElevenLabs / OpenAI / Deepgram (clé API, le plus humain), Piper (hors ligne, open source), macOS say (gratuit, robotique), ou tout outil via un modèle command. Voir reference/narration.md.

Voir reference/recording.md pour les détails du harnais, la technique de superposition et la référence des étapes du storyboard.

Ajouter une narration (optionnel)

La narration est désactivée sauf si le storyboard contient un bloc voice. Quand quelqu'un demande de l'audio / une voix off / que ce soit « humain » :

1. Demandez quel fournisseur. Pour un audio vraiment humain, utilisez un fournisseur cloud et confirmez que l'utilisateur a (ou ajoutera) la clé API : ELEVENLABS_API_KEY, OPENAI_API_KEY ou DEEPGRAM_API_KEY. Il peut aussi pointer command vers son propre outil TTS.
2. S'il n'a pas de clé, proposez les alternatives gratuites/hors ligne (Piper pour une qualité correcte, macOS say pour zéro configuration mais robotique) — ou `