remotion-design-system

Système de design Remotion pour montage HUD (v1 hub)

Objectif de style : reproduire le look HUD du film de référence (images de référence dans le dossier refs/). Ce fichier est le hub central des contraintes : règles absolues + sémantique des tokens + catalogue de composants + collection d'erreurs. Les détails de chaque module se trouvent dans le dossier references/ (synthèse des 77 différences identifiées le 2026-07-16). Toute décision visuelle non décrite dans ce système doit d'abord être ajoutée au fichier du module correspondant avant d'être codée.

Table de routage des modules (lire le fichier correspondant à votre besoin)

Module	Fichier	Responsabilité
Tableau des spécifications (vérifier avant d'écrire)	references/specs.md	Valeurs mesurées du film de référence : largeur de carte, taille de police, positions, numéros d'images de l'animation. Vérifier avant tout assemblage ; si la valeur n'est pas dans le tableau, la mesurer et la rajouter. Interdiction d'estimer à l'œil nu
Mise en page	references/layout.md	Trois zones, mécanisme de takeover (classe A sans PiP, assombrissement interdit), un centre par écran, modèles de groupement, points d'accroche
Typographie	references/typography.md	Seul mot le plus grand, devoir h1, sandwich hero, variante SideLabel, titre
Couleurs et matières	references/texture.md	Dégradés/bloc gélatineux, SURFACE foncé/clair, règle unique du tampon, pas plus de 2 tons par écran, interdiction d'écriture nue sur fond clair (détails)
Animation	references/motion.md	useEnter/useExit, séquences rythmiques, build-up, plage de service, Breathe, écran net
Conception d'infographie	references/infographic.md	Choix de graphiques, métaphores visuelles, waffle, grands nombres en trois couches, lexique de micrographiques
Narration/Rythme/Sous-titres/Média/Son	dans les references/ du module remotion-assembly	narration / rythme / sous-titres / médias / audio
Collection d'erreurs (symptôme → correctif)	Skill indépendant remotion-gotchas-index	Pour chaque erreur #NN, retrouver l'emplacement du correctif ; à consulter en cas d'anomalie de rendu ou d'image incorrecte

Liste des fichiers de base (substrate — vérifier leur présence avant tout nouveau projet)

Ce système de design est partagé entre tous les projets ; il n'est pas recréé pour chaque nouveau contenu. Les fichiers suivants sont les prérequis de toute la chaîne (assembly « validation de l'entrée → sortie image → trois portes de contrôle » + motion §12). Un nouveau projet les réutilise par défaut, en n'ajoutant que ses propres composition, sous-titres et scènes, sans reconstruire la base. Les utilisateurs qui démarrent un projet (interdiction de lire src/) tombent souvent dans ce piège — vérifier d'abord que ces fichiers sont présents, puis ouvrir le fichier correspondant pour obtenir les valeurs, ne pas attendre que le skill les reproduise.

Fichier de base	Contenu	Comment l'utiliser en démarrage à froid
src/design/tokens.ts	Source unique des valeurs : COLOR (quatre sémantiques + hexadécimal de base), SURFACE, FONT, GRADIENT, échelles SIZE (kicker…mega), GRID, RADIUS, SAFE, numéros d'images MOTION	Pour obtenir SIZE.mega, l'hexa d'une couleur sémantique, etc., lire directement ce fichier — le skill ne les reproduit pas volontairement (pour éviter les écarts avec le code, voir §1) ; si le fichier manque, la base est absente, il faut d'abord la créer
src/design/*.tsx	Bibliothèque de composants (§3 complet : SideLabel/HeroText/Chip…) + FontGuard.tsx (garde de police, erreur #01) + qc.tsx (sonde QC QcProbe : lit les boîtes [data-qc] image par image pour détecter les chevauchements, erreur #29)	Avant d'écrire un élément d'emballage, consulter le tableau §3 pour localiser le fichier
src/design/motion.ts	Hooks de base useEnter/useExit/usePop + constantes MOTION	Les règles de motion.md référencent ces hooks
src/design/fonts.ts	Enregistrement des polices locales via @fontsource (erreur #01 : les webfonts passent par le réseau et produisent silencieusement du Songti en chinois)	package.json sideEffects doit absolument l'inclure
src/koubo/scenes/shared.tsx	Quatre gardiens d'assemblage Enter/DimAfter/Exit/ClearOut (motion §12) + Place (boîte de positionnement) + qcAllow (liste blanche de chevauchement QC, assembly §2.5 porte ①)	Lors de l'assemblage des scènes, utiliser directement ces enveloppes ; ne pas créer manuellement de opacity
src/Root.tsx	Enregistrement des compositions (existant : <Composition id="Koubo-0715-01" fps={30} …/>)	Ajouter une ligne <Composition> pour un nouveau projet, avec un id personnalisé ; le script de rendu par segment doit correspondre à cet id (voir assembly §6 render-service pour changer l'id)
src/koubo/	Propre à chaque projet : subtitles-<nom>.ts / SubtitleTrack.tsx / <composant principal du projet>.tsx / scenes/SceneNN.tsx	Pour un nouveau projet, ajouter uniquement des fichiers dans ce répertoire (structure selon assembly §4)

Démarrage véritablement à partir de zéro (dossier src/ vide) : tant que la base n'est pas en place, la chaîne d'assembly ne peut pas commencer (tokens indisponibles, première image impossible, trois portes de contrôle inopérantes). Ordre à suivre : ① tokens.ts : source unique des valeurs → ② fonts.ts + FontGuard.tsx (erreur #01) → ③ motion.ts : trois hooks → ④ §3 bibliothèque de composants → ⑤ src/koubo/scenes/shared.tsx : quatre gardiens d'assemblage + Place/qcAllow → ⑥ src/design/qc.tsx : sonde QC → ⑦ src/Root.tsx : enregistrement de la composition. Utiliser le dossier src/design de ce dépôt comme référence pour la transplantation ; après transplantation, les valeurs sont toujours lues depuis tokens.ts, elles ne sont pas inscrites en dur dans le skill.

0. Six règles absolues

1. Zone d'information par défaut à gauche, personnage à droite : la zone d'information est par défaut à gauche (le personnage est l'auteur de la décision), le HUD est ancré à gauche et se développe verticalement ; le personnage ne doit jamais entrer dans la zone. Mais pour chaque projet, demander d'abord à l'utilisateur, ne pas décider seul ; les coordonnées des trois zones et le mécanisme d'exception takeover sont décrits dans references/layout.md, règle 1.
2. Tout texte a une structure à deux couches : en UPPERCASE anglais avec espacement large pour le kicker (petit) + un chinois en gras (grand). Tout composant n'ayant qu'une seule couche de texte est considéré comme inachevé.
3. Une seule phrase ne met en valeur qu'un seul mot : dans un titre chinois, au maximum un mot changé de couleur/souligné ; la couleur doit provenir du système sémantique à quatre couleurs.
4. Le vrai contenu est le sujet, Remotion est un synthétiseur, pas un logiciel de dessin (décision finale du 2026-07-16 seg01) : les scènes de « démonstration produit » (frappe/génération/interface/présentation) doivent être montées à partir de vraies séquences — capture d'écran personnelle > vidéo officielle > capture d'écran web > carte de simulation d'interface ; les dessins à la main sont réservés à la couche HUD (étiquettes latérales, sous-titres, graphiques, tampons, métaphores graphiques). Essayer de reproduire à la main le travail d'une équipe professionnelle de motion design avec du CSS est voué à l'échec. « Ça a l'air proche mais pas tout à fait / à des années-lumière » vient du fait qu'on utilise un logiciel de dessin pour faire le travail d'un synthétiseur. La chaîne de capture et de montage est décrite dans assembly references/broll.md.
5. Interdiction d'écriture nue sur fond clair (décision du 2026-07-16, règle transversale numéro un, couvrant 6 modules) : tout texte sur fond clair (tableau blanc, mur blanc, fond de takeover clair) doit reposer sur un fond sombre (SURFACE.darkPlate), une carte ou une variante de surface claire ; textShadow n'est pas une solution. Détails dans references/texture.md.
6. Un seul élément dominant par écran : chaque écran d'information a un et un seul « plus grand mot/plus grand élément » ; en dehors de la zone principale, au maximum 2 petits éléments de type chip. Détails dans references/typography.md et layout.md.

1. Design Tokens

Source unique = src/design/tokens.ts, tous les composants ne doivent qu'importer les valeurs qui s'y trouvent. Cette section ne contient que les règles sémantiques et d'utilisation, pas les valeurs numériques — un décalage entre la capture et le code s'est déjà produit (2026-07-16, valeurs kicker/h1 divergentes) ; se fier au code.

• Quatre couleurs sémantiques (seules couleurs d'accentuation autorisées) : bleu = définition/méthode/progression neutre ; vert = positif/faible seuil/déjà actif ; jaune = opportunité/avertissement/controverse/tournant ; rouge = négatif/piège/crise. Les couleurs de base sont blanc/gris/gris terne/cardBg/cardStroke.
• Polices (deux couches, ne pas les mélanger) : Couche MG — FONT.zh = Noto Sans SC (seule police chinoise pour la couche d'emballage, tous les titres en FONT.zhHeavy) ; FONT.en = Inter (kicker, corps de texte, chiffres) ; FONT.enTitle = Archivo Black (titres anglais et grandes conclusions, noir extra-large, weight 400 — Inter ne donne pas l'ampleur nécessaire aux grands titres, conclusion de la comparaison de glyphes du 2026-07). Couche de sous-titres inférieure — FONT.subZh = PingFang SC 400 / FONT.subEn = Inter 300 (décision de l'utilisateur après comparaison de 5 échantillons le 2026-07-26) : les sous-titres sont une couche de lecture, pas une couche d'emballage ; seule une police fine donne le rendu des sous-titres Apple, et elle se distingue bien des titres MG gras, sans attirer l'attention. L'ancienne version, avec Noto 700 sur toute la ligne, donnait un effet d'autocollant. PingFang SC est une police système macOS, elle n'est pas empaquetée via @fontsource — le rendu local est correct ; sur les environnements Windows/Linux, elle tombe sur Noto Sans SC 400 fine (déjà importée dans fonts.ts, rendu similaire mais pas identique) ; avant de lancer le rendu sur une autre machine, faire un test pour vérifier le rendu des sous-titres. Les lignes de sous-titres en anglais doivent utiliser une police proportionnelle, voir l'erreur #42.
• Les grandes conclusions sont toujours en couleur sémantique pure + textShadow ; interdiction d'utiliser backgroundClip: text pour des dégradés (erreur #06) ; GRADIENT est réservé aux blocs de couleur et aux contours.
• Tailles de police : uniquement l'échelle SIZE (kicker / subSmall / chip / subZh / subEn / card / h2 / h1 / mega) ; interdiction d'utiliser une taille en dehors de cette échelle. Base 1080p ; pour une sortie 4K, multiplier par 2.
• Espacements : toujours un multiple de GRID (8px) ; les angles arrondis utilisent RADIUS ; la zone de sécurité utilise SAFE (ancrage des étiquettes latérales, bord gauche des piles, distance au bas des sous-titres ; les cartes permanentes ne dépassent pas 55 % en x ; les coordonnées de la zone interdite au personnage et de la zone droite se trouvent dans layout.md ; la zone interdite aux sous-titres est y>82 %, le bord inférieur des éléments de la zone gauche ≤ y840 est une règle plus stricte que y82 % pour la zone gauche).

2. SideLabel (étiquette latérale de chapitre, permanent tout au long du projet, composant prioritaire)

• Structure : │ (trait vertical de 4px, couleur sémantique) + KICKER EN ANGLAIS · phrase en chinois (première ligne, kicker en anglais avec la spécification kicker + couleur sémantique, chinois blanc 34px) + deuxième ligne grise 24px (explication complémentaire).
• Position : fixe à SAFE.sideLabel ; au changement, l'ancienne étiquette se dissout en 12 images, la nouvelle glisse de la gauche en 15 images.
• Nommage avec un système de numérotation : SCENE 01, PATH 1/2/3, opposition ( DISSOLVED·01.. vs IMMUNE·01.. ).
• Couleur = sémantique émotionnelle de cette section, voir les commentaires dans les tokens. Référence : refs/01-版式与侧标/.

3. Aperçu rapide des spécifications des composants (les spécifications détaillées seront complétées en fonction de l'implémentation ; consulter d'abord les images de référence, puis coder)

Composant	Spécifications clés	Référence
BilingualSub	Chinois 52 blanc + ombre noire / Anglais 28 blanc pur, centré en bas, toujours en haut de tout	N'importe quel refs
HeroText	kicker + h1/h2 chinois, mot mis en valeur changé de couleur sémantique ; variantes : rouge barré pour correction, jaune souligné au pinceau, tampon incliné	refs/02
Chip	Carte noire RADIUS.chip + icône colorée + texte 34px, possibilité de changer la couleur d'un mot	refs/03
Checklist	Empilement vertical de chips, apparition progressif de chaque ligne ; lignes non actives : opacity 0.35	refs/03
InfoCard	Icône + kicker + titre 44px + mot mis en valeur en bleu	refs/01
StepList	Numérotation ①②③ en cercle + chinois + petit kicker anglais, allumage progressif	refs/04
FlowChain	Carte noire + flèche → en série, apparition nœud par nœud	refs/04
CompareCard	Logo + nom + chip rouge ✕ (faiblesse) + chip vert ✓ (force), empilement vertical	refs/04
Formula	Grand caractère A symbole B (>, », ⇄, =), symbole en couleur sémantique	refs/05
BigNumber	Grand chiffre en Inter + unité petite + kicker ; compteur avec scroll animé	refs/05
BarChart	Barres de données à coins arrondis 8px ; barre importante en jaune + chip couronne en haut ; les autres en gris	refs/05
CurveOverlay	Courbe jaune 2–3px directement superposée au B-roll, annotation à l'extrémité droite	refs/05
Timeline	Type intervalle entre deux points / type événement avec puces de résultat rouges/vertes	refs/05
ScoreBoard	Score vert:rouge en grands chiffres	refs/05
PhoneMockup	Cadre iPhone + dégradé lumineux + capture d'écran intégrée qui défile	refs/06
WindowCard	Feux tricolores mac + icône d'application + chip fonctionnel, contenu dynamique	refs/04
QuoteDoc	Capture d'écran sur fond blanc + surlignage jaune fluo + bande de traduction chinoise sur fond noir en superposition	refs/07
TweetCard	Avatar + kicker d'identité + grande conclusion en rouge + chip vues	refs/07
PersonCard	Avatar rond + nom + petits caractères d'identité + chip institution	refs/07
Stamp	Texte de tampon incliné -8°~-6° avec contour (rouge/vert), animation de tamponnage = scale 1.3→1 + légère vibration	refs/08
MatrixIcon	Icône en matrice carrée : rouge = faction dissoute / vert = faction immunisée	refs/08
CardWall	Petites cartes blanches, de 3 à 20, qui remplissent progressivement l'écran pour simuler une explosion de demandes	refs/06
BeforeAfter	Deux cartes icônes + flèche bleue + chip de conclusion inférieure	refs/04
Breathe	Enveloppe d'animations micro au repos : respiration scale ±0.6% + flottement ±3px, phase décalée pour éviter la synchronisation ; à placer autour de l'élément principal	src/design/Breathe.tsx
BrickWall	Mur de briques dorées en quinconce, construction brique par brique + étiquette centrale, métaphore du « mur/obstacle dur »	src/design/BrickWall.tsx
UnitMatrix	Matrice carrée de N groupes, allumage progressif de chaque cellule ; mode waffle fillRatio (champ de données 73%)	src/design/UnitMatrix.tsx
CloneCascade	Carte icône source + copies qui apparaissent progressivement + puce d'avertissement, métaphore du « copiage/distillation »	src/design/CloneCascade.tsx

Composants intégrés aux scènes en production de masse (ajoutés le 2026-07-17 pour la production de masse, non encore promus en composants partagés)

Les composants suivants ne vivent actuellement que dans une seule scène, marqués « Scène intégrée, à promouvoir en composant partagé dans src/design et à ajouter une ligne de spécifications dans specs lors de sa deuxième réutilisation » — lors de la création d'un nouveau projet confronté à un besoin similaire, vérifier d'abord ici, ne pas recréer :

Composant intégré	Emplacement	Fonction	Condition de promotion
DissolveGrid	scenes/Scene08.tsx	Grille de dissolution : les carrés de la faction dissoute se désintègrent progressivement, le fond ⚡ du centre se dissout, ne laissant qu'un contour blanc en suspension	Lors de la deuxième réutilisation de la métaphore « dissolution de faction »
VerdictBox (boîte de verdict)	scenes/Scene17.tsx	Boîte de verdict miroir rouge/vert : ≈400×170, cadre vide d'abord posé + header dans le cadre + 3 chips horizontaux entrant par lots (rouge plein d'abord, vert plein après, créant une suspension « de quel côté es-tu »)	Lors de la deuxième promotion « VS verdict »
NamePlate + CtaBadge (rangée de badges CTA)	scenes/Scene19.tsx	Rangée horizontale en bas du CTA final : plaque nominative d'abord ancrée → quatre badges d'action entrant en élastique (le dernier commentaire le plus large = accentuation)	Lors de la deuxième fin de CTA

Directive sur les icônes

• Utiliser exclusivement les icônes SVG linéaires de lucide-react ; couleur = couleur sémantique (COLOR[accent]), strokeWidth 2.5 environ ; interdiction totale d'utiliser des emojis (les blocs colorés arrondis entrent en conflit avec le style linéaire monochrome du film de référence, leçon apprise lors de la troisième série de tests en juillet 2026).
• Les props icon des composants Chip / Checklist / SideLabel acceptent un ReactNode : icon={<Lock size={26} strokeWidth={2.5} />}.

Directive sur les matières → references/texture.md

Dégradés/bloc gélatineux, glow de même couleur, vignette, vrai logo, variantes claires/foncées de SURFACE, règle unique du tampon : tout se trouve dans texture.md (à partir de 2026-07-16, c'est la seule source de vérité pour les matières ; les anciens textes de cette section ont été déplacés).

4. Règles d'animation → references/motion.md

useEnter/useExit, entrée par séquences rythmiques, plage de service, Breathe, écran net entre les chapitres, interdictions : tout se trouve dans motion.md (à partir de 2026-07-16, c'est la seule source de vérité pour les animations ; les anciennes règles « l'information ancienne reste transparente en permanence » ont été remplacées par « plage de service + discipline de sortie »).

5. Auto-vérification avant export (exécuter avant chaque rendu)

1. Utiliser grep pour vérifier qu'aucun composant n'utilise des valeurs de couleur/taille/police en dehors de celles des tokens.
2. Vérifier qu'aucune carte permanente ne dépasse faceZone / subtitleZone.
3. Vérifier que chaque phrase titre n'a qu'un seul mot mis en valeur ; que le kicker anglais est bien en majuscules avec espacement.
4. Extraire 3 à 5 images clés et les comparer côte à côte avec les images de référence dans refs/. Si ce n'est pas ressemblant, identifier la règle de token violée et corriger le token, pas le composant.

6. Collection d'erreurs

#01 Le chinois se transforme silencieusement en Songti (2026-07-15 · premier jour du système de design)

• Symptôme : dans le rendu/capture d'écran, le chinois devient Songti, l'anglais reste normal ; parfois le même composant est normal, parfois non (aléatoire).
• Cause : trois couches, la dernière est la véritable responsable. ① @remotion/google-fonts télécharge la police depuis gstatic au moment de l'exécution ; le réseau chinois ne peut pas l'atteindre, fallback silencieux. ② Les webfonts chinoises sont segmentées par unicode-range, ce qui crée une compétition entre chargement et capture d'écran. ③ Tree-shaking : sideEffects: ["*.css"] dans package.json fait que fonts.ts, qui n'est importé que par effet de bord, est complètement éliminé lors du bundle de production ; le CSS de la police n'est pas dans le bundle de rendu (document.fonts.size === 0). En mode développement Studio, le tree-shaking n'a pas lieu, donc « Studio normal, rendu en échec ».
• Correction : ① Utiliser les polices locales via @fontsource (src/design/fonts.ts). ② Dans package.json, sideEffects doit absolument inclure "src/design/fonts.ts". ③ Tout composant contenant du texte doit intégrer <FontGuard/> : une boucle load→check qui vérifie aussi que document.fonts.size > 0 (fonts.check() retourne vrai à vide si aucune police n'est enregistrée), et en cas de timeout appelle cancelRender avec une erreur ; ne jamais produire silencieusement une image en Songti.
• Leçon : « Studio normal, export en échec » — suspecter d'abord une différence de bundle de production (tree-shaking/minification), pas une compétition mystérieuse ; la validation des polices doit passer par la barrière rigide de FontGuard, l'œil humain ne suffit pas pour les miniatures.

#02 remotion still affiche « ○ » = réutilisation de l'image ancienne

• Symptôme : code modifié, nouveau rendu, le fichier de sortie semble inchangé ; la ligne de commande affiche ○ au lieu de +.
• Correction : avant de valider le rendu, supprimer l'ancienne sortie (ou utiliser un nouveau nom de fichier) ; si nécessaire, ajouter --bundle-cache=false. + = vrai rendu, ○ = suspect.
• Leçon : la validation comparative doit se baser sur des produits de rendu dont la fraîcheur est confirmée ; sinon, on risque de diagnostiquer à tort « correctif inefficace » (cela a fait perdre deux tours dans ce projet).

#03 Les miniatures comparatives sont trompeuses

• Symptôme : en comparant côte à côte des miniatures, le chinois semble en Songti, alors que l'original est normal.
• Correction : pour juger de la police/des détails de contour, découper une partie de la résolution originale et l'agrandir ; ne pas se baser sur une miniature de l'image entière pour conclure.

#04 Les chaînes d'attributs JSX ne résolvent pas les échappements \uXXXX

• Symptôme : <Chip icon="\u2705" /> affiche le texte littéral \u2705 au lieu de ✅.
• Cause : les chaînes littérales des attributs JSX sont du texte HTML, elles ne passent pas par l'analyse des échappements JS ; seules les chaînes dans les expressions JS ( icon={'\u2705'} ) résolvent les échappements. On tombe facilement dans ce piège en écrivant du TSX par script.
• Correction : pour les emoji/caractères spéciaux dans les attributs JSX, écrire directement le caractère (icon="✅") ; si une échappement est nécessaire, écrire icon={'\u2705'}.

#06 Le texte en dégradé backgroundClip: text rend sombre

• Symptôme : un grand titre utilisant un dégradé CSS avec backgroundImage + WebkitBackgroundClip:'text' + WebkitTextFillColor:'transparent' semble acceptable dans Studio, mais le rendu est sombre et terne (rouge vif devenu brique), immédiatement rejeté par l'utilisateur.
• Correction : pour les grandes conclusions, utiliser uniquement une couleur sémantique pure COLOR[semantic] + textShadow ; pour donner de la profondeur, jouer sur l'ombre et le poids de la police, pas sur un remplissage dégradé. tokens.GRADIENT est réservé aux blocs de couleur et aux contours.

#08 Le texte MG du montage final a un halo / un effet de flou ( « qualité d'image dégradée après ajout de MG » ) (2026-07-16 · 0715-01 v3)

• Symptôme : l'utilisateur trouve que la qualité de l'image finale est médiocre ; en zoomant, on voit un bruit JPEG / halo autour du texte MG, d'autant plus marqué sur les éléments très nets. Le contenu original en HEVC 15 Mbps est très propre.
• Cause : la chaîne par défaut de Remotion effectue une double compression : chaque image est capturée en JPEG qualité 80, puis compressée en H264 avec CRF 18. Les grands textes MG / lignes fines sont des signaux haute fréquence, les premiers à montrer des artefacts de compression. Avant l'ajout de la MG, les artefacts étaient cachés dans la texture de la vidéo réelle et moins visibles, d'où le diagnostic erroné « La MG dégrade la qualité ».
• Correction : dans remotion.config.ts, fixer Config.setJpegQuality(100) + Config.setCrf(15) (déjà fait dans ce projet, ne pas revenir en arrière). Le volume augmente d'environ 20%, le rendu est un peu plus lent, mais c'est nécessaire.
• Méthode de diagnostic : pour une même image, faire une capture à partir de la source, de l'ancien montage et du nouveau paramétrage de test ; découper la même zone du texte MG et la comparer côte à côte en agrandissant ; faire un test de rendu de 5 secondes pour valider les paramètres avant de lancer le rendu complet.

#09 Rendu long qui disparaît en cours de route, fichier mp4 restant corrompu (2026-07-16 · 0715-01 v3)

• Symptôme : le processus de rendu est présent depuis longtemps mais le fichier de sortie n'augmente plus de taille ; ou le rendu disparaît silencieusement, laissant un mp4 illisible.
• Cause : ① Le rendu est lancé dans un sous-processus d'une session IA ; si la session redémarre/se ferme, le rendu est tué (ici tué à 90%). ② La détection de processus avec pgrep -f "remotion render" correspond aussi au script de détection lui-même (son nom contient la même chaîne), créant l'illusion que « le processus est encore en vie ».
• Correction : ① Pour tout rendu de plus de quelques minutes, utiliser nohup npx remotion render … > /tmp/xx.log 2>&1 & disown pour le détacher de la session. ② Le critère de fin est la présence de la ligne + nom_du_fichier_de_sortie dans le journal (+ = vrai rendu réussi), et non la présence du processus. ③ Pour détecter le processus, exclure la correspondance avec lui-même (en regardant l'utilisation CPU ou en utilisant un PID précis). ④ Avant de relancer le rendu, supprimer les fichiers corrompus restants.
• Leçon : ne jamais livrer un mp4 corrompu (durée/taille non correspondante) ; d'abord utiliser ffprobe pour vérifier la durée et la piste audio avant de le montrer à l'utilisateur.