sui-motion-graphic-reel · Créer des animations au design soigné avec du code

Auteur : Sui Yang (IG @asksui.ai). Ce skill est issu de sept itérations de correction d'une animation de 15 secondes : chaque idée est née d'une version refusée, les captures d'écran sont dans examples/, l'historique complet dans references/case-0099.md.

En une phrase : la qualité d'une animation dépend à 90% du langage visuel et des plans décidés avant de commencer, pas du nombre d'effets utilisés. Ce skill vous apprend « comment penser, comment demander à l'IA et comment vous relire », quel que soit le moteur utilisé.

Le fil conducteur : Trouver le design system (§1 : suivre celui de l'utilisateur s'il existe ; sinon, faire générer plusieurs options par l'agent de design) → Script & son (§2) → Storyboard présenté à l'utilisateur (§3) → Définir le langage visuel, créer chaque scène (§4, neuf principes) → Relecture avant rendu (§5) → Auto-relecture après rendu (§6) → Livraison et itérations (§7).

Deux choses à garder séparées (le principe de conception le plus important de ce skill) :

	Où cela vit	Modifiable ?
Goût : couleurs, dégradés, polices, rythme de parole, présence de personnages	`references/design-system.md` (un par projet)	L'utilisateur décide. Les exemples dans le design system sont un point de départ ; l'ensemble peut être remplacé
Métier : cohérence globale, une technique par scène, multi-couches, sens du plan, un focus à la fois, auto-relecture	Ce SKILL.md §4–§6	Indépendant du goût ; valable quel que soit le style choisi

En cas de conflit entre une règle et le style souhaité par l'utilisateur : le goût est celui de l'utilisateur, le métier est appliqué. Exemple : l'utilisateur veut des dégradés néon – d'accord, alors toute la vidéo utilise ce langage néon (métier : cohérence globale), pas une scène en néon et la suivante en grille suisse.

1. Commencer par trouver le design system

Sans design system (couleurs, polices, grille, éléments signatures, personnalité du mouvement, liste de « à ne pas faire »), l'IA retombe par défaut sur : dégradé violet-rose, lueur, fondu + zoom sur chaque scène. Donc la première étape est toujours celle-ci, et on cherche d'abord, on demande ensuite, on ne crée qu'en dernier recours.

Design system existant ?
├─ Oui → Suivre celui de l'utilisateur (1A)
└─ Non → L'utilisateur répond à quelques questions ou fournit des références (1B) → L'agent de design prend le relais et propose plusieurs options à l'utilisateur (1C) → L'utilisateur choisit → Suivre ce choix

1A. Chercher d'abord : l'utilisateur a-t-il le sien ?

Vérifier le projet : design-system.md, charte graphique, design tokens, variables CSS du site, export Figma, logo, vidéos ou images précédentes.
Si rien trouvé, demander : « Avez-vous un design system ou une charte graphique existante ? Si oui, envoyez-la moi et je l'utiliserai. »
Oui → Suivre celui de l'utilisateur. Le retranscrire dans design-system.md (les champs sont dans references/design-system.md). Ne pas modifier un iota de ce qui est déjà défini ; pour les champs manquants nécessaires à la vidéo (personnalité du mouvement, élément signature, marges de sécurité de la plateforme), les ajouter en les marquant « Ajouté par l'IA » et demander confirmation à l'utilisateur.

1B. Sinon : l'utilisateur répond d'abord ou fournit des références

Deux possibilités, l'une ou l'autre, ou les deux :

Questions : poser en une seule fois, maximum quatre questions, chacune avec des options.
- Ambiance : sobre et élégant / dynamique / technologique / artisanal / à définir
- Couleurs : y a-t-il des couleurs imposées ? Sinon, choisir une seule couleur d'accent
- Personnage ou mascotte ? Voix off ?
- À qui s'adresse la vidéo ? Sur quelle plateforme sera-t-elle diffusée ?
Références : une vidéo appréciée, un site web, une affiche, une marque. Pour chaque référence, demander : « Qu'aimez-vous chez elle ? ». Apprendre son langage (couleurs, grille, typographie, mouvement), ne pas copier son image.

1C. L'agent de design prend le relais : proposer plusieurs options à l'utilisateur

Transmettre les réponses et références obtenues en 1B à un autre agent (l'agent de design), dont la seule mission est de produire des propositions de design system. Les instructions et le format de retour sont dans references/design-agent.md.

Proposer 3 directions bien distinctes (pas la même chose avec une couleur d'accent différente).
Chaque direction doit être accompagnée d'une vraie maquette : les trois versions utilisent le même titre et le même contenu visuel, présentées côte à côte sur une seule image. L'utilisateur choisit avec ses yeux, pas en lisant des codes couleur.
L'utilisateur peut choisir une direction entière ou mixer des éléments (par ex. « les couleurs de A avec la police de B »). Si rien ne plaît, demander ce qui ne va pas et refaire un tour.
La direction choisie est écrite dans design-system.md du projet. Chaque scène ultérieure n'utilisera que ce qui est dans ce fichier ; pour ajouter une couleur, une police ou une technique, revenir d'abord le modifier.

Pourquoi un autre agent ? L'agent qui crée la vidéo a déjà en tête le script et les images ; s'il doit aussi proposer des directions, elles se ressembleront. En ouvrir un autre, qui ne voit que les besoins et les références, garantit des directions variées. Si l'environnement ne permet pas d'ouvrir un second agent, suivre soi-même les mêmes instructions et livrer trois directions avec maquettes.

En l'absence de l'utilisateur

Planification, travail de nuit, ou quand l'utilisateur dit « vous décidez » : ne pas bloquer l'avancement. L'agent de design produit quand même trois directions, choisir celle qui correspond le mieux aux besoins, l'indiquer dans design-system.md comme « Choix effectué par l'IA » avec les maquettes des deux autres options, et demander confirmation ou changement à la livraison.

Les champs et quatre exemples sont dans references/design-system.md.

2. Script et son : le son d'abord

Rédiger le script comme un discours parlé, avec des connecteurs (« vous voyez », « et aussi », « d'ailleurs »). Pas de liste de mots-clés. Il doit sonner comme si on parlait à un ami, pas comme si on lisait un slogan.
Générer la voix off en une seule fois, pas phrase par phrase puis assembler – chaque phrase générée séparément sonne comme un slogan, et l'ensemble n'a pas de fluidité. Pendant la génération, obtenir le timing de chaque mot (la plupart des services TTS ont une API avec timestamps).
L'image suit les mots : chaque scène, chaque élément apparaît au moment précis où le mot correspondant est prononcé. La durée totale de la vidéo = durée de la voix off + conclusion, pas une durée arbitraire en secondes entières. Même chose pour les mouvements : lorsque la voix dit « la caméra arrive », l'image doit montrer ce mouvement à ce moment-là ; si le mouvement se termine avant que le mot ne soit prononcé, le spectateur voit une image fixe avec une voix qui décrit un mouvement qui a déjà eu lieu. Imprimer le timing des mots et vérifier, ne pas se fier à une estimation.
Ne pas insérer de blancs dans la voix off pour attendre l'image. Si l'image n'est pas prête à temps, simplifier l'image.
Pour une vidéo sans voix off : écrire d'abord une partition rythmique (ce qui se passe à quelle seconde), puis suivre cette partition.
Après le rendu, transcrire le son de la vidéo en texte pour vérifier que chaque phrase est présente et qu'aucune n'a été coupée à la fin (une voix coupée est invisible à l'écran).

Comment intégrer la voix off, droits d'utilisation : references/engines.md « Voix off ».

3. Montrer le storyboard d'abord, valider avant de produire

Le retour en arrière le plus coûteux est de réaliser l'animation et de découvrir que la direction n'était pas la bonne. Avant de commencer, produire un tableau de storyboard, une ligne par scène :

Colonne	Contenu
Temps / mots prononcés	De quelle seconde à quelle seconde, quels mots de la voix off
Focus	Ce que le spectateur doit regarder (un seul élément)
Quatre couches	Arrière-plan · Acteur principal · Avant-plan · Couche d'information (cf. §4 règle 4)
Technique	La méthode d'animation utilisée pour cette scène (cf. §4 règle 2), différente de la scène précédente
Caméra	D'où et vers où la caméra se déplace
Rythme	Cette scène est-elle dense ou aérée, lumineuse ou sombre (cf. §4 règle 9). Une fois le tableau rempli, lire cette colonne seule
Transition	Comment passer à la scène suivante

Si possible, pour chaque scène, dessiner une image fixe clé (réellement dessinée selon le design system), et les assembler en un tableau pour l'utilisateur. Attendre son approbation avant de commencer l'animation.

En l'absence de l'utilisateur : rédiger le storyboard quand même, l'archiver, le vérifier selon §4 avant de commencer, et le fournir à la livraison.

4. Les neuf principes

Chaque principe est accompagné de « pourquoi » et de « à quoi ça ressemble quand c'est mal fait ». Les noms des techniques et la manière de les demander sont dans references/techniques.md.

① Définir un seul langage visuel, l'utiliser pour toute la vidéo

Avant de commencer, fixer ces éléments dans un fichier de tokens commun, que chaque scène utilise : palette de couleurs · grille et marges de sécurité · polices et hiérarchie typographique · position des blocs de titre · un « élément signature » qui traverse toute la vidéo (ex. dans l'exemple A, il s'agit des annotations d'outils de design – poignées de sélection, trames d'images clés, étiquettes de formes – pour montrer le processus de création).

Pourquoi : le spectateur ne peut pas dire précisément ce qui cloche, mais il voit immédiatement que « ces scènes ne font pas partie de la même vidéo ». La cohérence est la source la moins chère de la « qualité ».
À quoi ça ressemble quand c'est mal fait : on ne corrige que la scène rejetée, les autres gardent leurs propres couleurs (comparer examples/v3-only-first-scene-fixed.jpg et examples/v4-unified.jpg). Corriger une scène, c'est aligner toute la vidéo.

② Changer de technique à chaque scène, pas de couleur

La richesse vient de la manière dont la scène est animée, pas du changement de palette. Alterner les méthodes sur toute la vidéo :

Sujet	Technique
Grands titres	Déformation élastique (écrasement à l'atterrissage, étirement au rebond)
Pixel / rétro	Pas à pas, déplacement sur des entiers, pas d'interpolation lisse
Particules	Simulation physique ou champ de force, dispersion puis regroupement
Écriture manuscrite	Tracer chaque trait dans l'ordre réel du coup de pinceau
Interface / écran	Perspective 3D, panneaux décalés en profondeur, la caméra tourne autour
Chiffres	Compteur qui défile, chaque saut est accompagné d'un écrasement

À quoi ça ressemble quand c'est mal fait : chaque scène est un simple « fondu + zoom ». Même avec beaucoup de scènes, une seule technique de mouvement.

③ Les lettres doivent être vraiment cinétiques

Quand les grands titres sont les acteurs principaux, ils doivent avoir du poids : tomber en s'allongeant, s'écraser au sol puis rebondir, se décaler lettre par lettre, entrer en s'étirant, sortir en se comprimant en une ligne. Formules et exemples dans references/techniques.md « Typographie ».

À quoi ça ressemble quand c'est mal fait : les lettres apparaissent en fondu, ou sont poussées uniformément par un masque.

④ Quatre couches par scène, un seul focus à la fois

Couche	Rôle
Arrière-plan	Environnement animé, donne le contexte, sombre, lent
Plan moyen	Le seul focus : le personnage ou l'objet principal, net, grand, au centre
Avant-plan	Objets qui passent devant la caméra, créent la profondeur
Information	Étiquettes, compteurs, petites UI, sous-titres

Plusieurs choses peuvent bouger en même temps, mais une seule doit être la plus lumineuse, la plus nette et la plus visiblement en mouvement en même temps. La richesse vient du nombre de couches, pas du nombre d'éléments qui attirent l'attention simultanément.

Quand ça s'arrête : le sujet (focus et texte à lire) s'arrête complètement pour être lisible, tout ce qui est autour doit continuer de bouger lentement : petits marqueurs qui flottent en arrière-plan, grands mots en arrière-plan, objets d'avant-plan qui encadrent le visuel principal, la respiration d'un personnage. Si tout s'arrête, l'image meurt. Le mouvement se place autour du sujet, sans traverser le texte à lire.
Les couches doivent se superposer, pas s'empiler verticalement : l'arrière-plan derrière l'acteur principal, l'avant-plan par-dessus le bord de l'acteur principal. Mettre « arrière-plan » et « avant-plan » dans les zones vides sous le personnage principal, ce n'est pas créer des couches, c'est juste ajouter deux éléments ; la zone inférieure en format vertical est souvent masquée par l'interface de la plateforme.
À quoi ça ressemble quand c'est mal fait : une carte sur un fond uni (il manque trois couches, ça semble « plat ») ; ou quatre éléments qui clignotent en même temps (pas de focus, ça semble « confus »).

⑤ La caméra doit bouger par elle-même

Placer tous les éléments dans un seul monde (un canevas beaucoup plus grand que l'écran, ou un espace 3D), et faire bouger la caméra à l'intérieur, plutôt que de changer d'image fixe.

Ouverture : la caméra arrive de loin (fly-in), traverse plusieurs couches d'avant-plan, et au moment où elle s'arrête, l'acteur principal commence son mouvement.
Deux vagues dans les 4 premières secondes : une première grande translation (0–1 sec), puis une deuxième (nouveau mouvement de caméra, changement de zone, ou grande déformation du texte lui-même). Une seule vague et c'est fini = seulement 1 seconde d'ouverture.
Transition : la caméra se déplace vers une autre zone du monde, les trois couches (loin, moyen, près) bougent à des vitesses différentes (parallaxe). Ajouter un flou de mouvement sur les images rapides, mais le texte ne doit pas être flou.
Même les vidéos calmes ont besoin d'une deuxième vague, mais d'une manière différente : pas forcément un grand mouvement de caméra, mais une déformation du texte (étirement, écrasement), une ligne qui balaie l'écran pour amener la ligne suivante, un objet principal qui fait une action. « Lent » signifie des courbes d'accélération douces, pas l'absence de mouvement.
Quand la caméra bouge, les marges de sécurité doivent être recalculées : après un zoom avant ou un panoramique, un petit texte qui était dans les marges peut se retrouver en dehors. Pour les images où la caméra a bougé, vérifier le bord à la taille réelle.
À quoi ça ressemble quand c'est mal fait : l'ouverture est une image fixe ; les transitions sont des fondus au noir vers une nouvelle image.

⑥ Si c'est 3D, que ce soit vraiment 3D

Pour des mouvements de caméra 3D, créer une vraie scène 3D avec une vraie caméra perspective (three.js ou similaire) : des trajectoires courbes, des accélérations et décélérations, montrer le côté des objets. Les particules doivent avoir un volume, une profondeur de champ, une traînée.

À quoi ça ressemble quand c'est mal fait : agrandir une image 2D pour simuler un « zoom avant » ; construire un cube avec quelques faces CSS (trop peu de faces, mauvaise occlusion, ça se casse dès qu'on tourne) ; des particules ne sont que des points sur un plan.
Les séquences vraiment 3D doivent impérativement être vérifiées image par image (§6) – c'est ce qui casse le plus facilement et est le moins visible en miniature.

⑦ Les transitions sont des attractions en soi

En plus du mouvement de caméra fluide, les transitions entre les scènes peuvent être : traversée (la caméra avance dans un objet de la scène précédente, et à l'intérieur se trouve la scène suivante) · masque (la scène suivante apparaît à travers une lettre ou une forme, ouverture d'un iris) · match cut (un point de la scène précédente = la pointe du pinceau de la suivante) · dévoilement arrière (la scène précédente n'était qu'un petit écran parmi beaucoup d'autres).

Placer les transitions dans les blancs entre les phrases de la voix off.
Pour chaque transition, extraire plusieurs images consécutives et vérifier qu'il n'y a pas de cassure ou de saut (examples/v4-transitions.jpg).

⑧ Tout dans l'image est calculé à partir du « numéro d'image »

Quel que soit le moteur, le rendu est une série de captures d'écran. Chaque position, taille, opacité doit être une fonction du numéro d'image : donnez l'image 137, et elle dessine l'image 137. Ne pas utiliser de mécanismes temporels autonomes (transitions CSS, minuteurs internes, boucle d'animation du moteur 3D) – au moment de la capture, ils ne sont pas synchronisés avec l'image, ce qui provoque des scintillements, des sauts et des éléments manquants.

Avantage : n'importe quelle scène peut être placée dans une fenêtre de transition, dans un récapitulatif de fin, et continuer d'être animée – il suffit de lui donner un numéro d'image.
Les données qui nécessitent du temps de calcul (échantillons de points sur le texte, positions cibles des particules, pixels d'un personnage) doivent être pré-calculées et sauvegardées, pas calculées au moment du rendu.

⑨ Écrire le rythme comme une musique : des variations de densité et de luminosité

Une vidéo avec la même densité et la même couleur de fond du début à la fin, même si chaque scène est parfaite individuellement, devient rapidement ennuyeuse. Considérez la vidéo comme une musique : des passages denses et aérés, des moments lumineux et sombres, planifiez les montées et les descentes avant de commencer.

Écrire une partition rythmique : dans le storyboard, pour chaque scène, marquer deux cases : dense / aéré, lumineux / sombre. Lire la séquence comme « dense aéré aéré, dense aéré aéré, dense » – c'est bon. Si on a quatre ou cinq scènes « dense, sombre » à la suite, ajouter une scène aérée ou changer de luminosité.
Aéré = il n'y a qu'une seule chose à l'écran : un téléphone, un grand mot, un chiffre, avec beaucoup d'espace vide. Un montage rapide n'est pas aéré, c'est la partie la plus dense de la vidéo.
Une scène dense peut aussi commencer aérée : d'abord seulement le titre, et au moment du mot clé, on ajoute les éléments.
Le changement de luminosité se fait en changeant la couleur de fond : si le design system a plusieurs couleurs de fond, en changer pour une scène entière est le moyen le plus direct de créer une variation. Changer pour toute l'image, sans laisser une bande de l'ancienne couleur.
La couleur la plus intense ne doit être qu'un éclat : remplir tout l'écran avec la couleur d'accent, un balayage rapide, un flash (environ une seconde) est très puissant ; l'utiliser comme couleur de fond pour une scène entière de texte à lire devient agressif.
À quoi ça ressemble quand c'est mal fait : chaque scène est « fond de couleur unie + grand titre + un cadre au milieu » ; ou alors le premier passage aéré n'arrive qu'à la fin.
Comment s'auto-vérifier : réduire les images fixes de chaque scène à de très petites vignettes, les aligner, et cacher le texte. On doit distinguer des paragraphes, voir où c'est lumineux ou sombre – alors le rythme est bon.

5. Relecture avant rendu : corriger avant de montrer à l'utilisateur

Faire une vidéo complète est lent. La plupart des défauts que l'utilisateur remarquera peuvent être détectés avant le rendu final, en ne regardant que quelques captures d'écran statiques. Donc ne pas lancer le rendu directement après avoir écrit les scènes, passer d'abord trois filtres, du moins cher au plus coûteux :

Filtre	Quoi vérifier	Permet de détecter
① Relecture papier	Confronter le storyboard au fichier des habitudes de relecture	Répétition des techniques par scène, couches manquantes, focus multiples, absence de deuxième vague d'ouverture, écart par rapport au script
② Métrique	Prendre quelques captures d'écran statiques, lancer `scripts/preflight.py`	Texte hors des marges de sécurité, deux images quasi identiques, passages qui devraient bouger mais ne bougent pas, image trop vide
③ Agent de relecture	Un autre agent regarde les images et le fichier des habitudes de relecture	Le personnage principal est-il reconnaissable ? Vulgarité ? Platitude ? Les objets sont-ils cassés ? Cohérence ?

Fichier des habitudes de relecture (review-habits.md) : c'est le cœur de cette étape. Chaque défaut que l'utilisateur a remarqué lors des visionnages précédents est noté une par une. Chercher d'abord dans le projet, puis dans le fichier personnel de l'utilisateur. Si rien, copier le fichier de démarrage dans references/review-habits.md.
Chaque fois que l'utilisateur remarque un problème, l'ajouter dans le fichier. Au moment de l'ajouter, se demander : ce problème aurait-il pu être détecté avant le rendu ? Si oui, noter comment. Ce fichier deviendra de plus en plus comme ses propres yeux.
Ne lancer le rendu qu'après avoir passé les trois filtres. Les items obligatoires non corrigés bloquent le rendu.
Cette étape ne détecte pas les problèmes de son ni le ressenti du mouvement continu – ceux-ci sont réservés pour §6.

Comment réaliser chaque filtre, instructions pour l'agent de relecture : references/pre-render-review.md. Format du fichier d'habitudes, entrées de démarrage, comment le faire grandir : references/review-habits.md.

6. S'auto-relire avant de livrer (obligatoire, ne pas attendre que l'utilisateur se plaigne)

Ne pas dire « c'est prêt » tout de suite après le rendu. Suivre cette checklist dans l'ordre, noter « ce que j'ai vu, ce que j'ai corrigé » :

Tableau de contact : une image toutes les 0,5 secondes, pour vérifier le rythme général et la lisibilité de chaque image. python3 scripts/review.py sheet <vidéo>
Agrandir les images fixes : au moment où le sujet s'arrête dans chaque scène, extraire une image à la taille réelle et les regarder une par une. Le tableau de contact réduit ne montre pas un texte collé au bord, un personnage cassé, une superposition incorrecte. python3 scripts/review.py frames <vidéo> 1.2 4.5 7.0 …
Vérifier les passages animés de manière dense : transitions, mouvement 3D, particules, une image toutes les 0,1–0,2 seconde. python3 scripts/review.py burst <vidéo> <début> <fin>
Détecter les arrêts : y a-t-il des passages de plus d'une seconde sans aucun mouvement (cause fréquente : un élément fige toute la scène) ? python3 scripts/review.py freeze <vidéo>
Transcription : transcrire le son de la vidéo en texte, le comparer au script.
Vérifier le design system : chaque scène utilise-t-elle uniquement les couleurs, polices et techniques du design system ?
Comparer à la version précédente : cette version est-elle meilleure que la précédente ? Si ce n'est qu'un changement, pas une amélioration, le dire.

Questions à se poser pour chaque image :

Quel est le focus de cette image ? Peut-on le voir en une seconde ?
Le texte est-il assez grand, pas flou, pas collé au bord, pas écrasé par autre chose ?
Les quatre couches sont-elles présentes ? Les compter une par une : arrière-plan, avant-plan, combien d'éléments d'information ? Si on ne distingue que l'acteur principal, c'est trop plat. Comparer la densité avec n'importe quelle image de examples/v7-near-final.jpg.
La technique de cette scène est-elle différente de celle de la scène précédente ?
Y a-t-il quelque chose de la liste « à ne pas faire » du design system ?
Deux éléments font-ils la même chose dans la même image ?

Les outils d'auto-relecture peuvent aussi tromper : chaque image du tableau de contact peut être correcte, mais il peut y avoir un arrêt (il faut le détecter séparément) ; les images extraites peuvent être correctes, mais le mouvement peut être mauvais (séquences 3D et transitions à vérifier en continu) ; la transcription peut confondre des homophones ou des noms de marque en anglais (c'est un problème de transcription, pas de la voix off).

Maximum trois auto-corrections. Une correction = une vidéo complète + les 7 étapes ci-dessus ; vérifier avec une capture d'écran statique avant de lancer le rendu ne compte pas comme une correction. Si au bout de trois corrections il reste des problèmes, les lister et les dire à l'utilisateur, ne pas les cacher.

7. Livraison et quand l'utilisateur dit « pas satisfait »

À la livraison, dire trois choses : ce qui a été fait · ce que l'auto-relecture a révélé et ce qui a été corrigé · et ce qui reste comme défauts.

Le retour de l'utilisateur est souvent une impression. D'abord traduire cette impression en langage visuel, puis corriger ; si la traduction est impossible, demander, ne pas deviner :

L'utilisateur dit	C'est probablement	Vérifier d'abord
Vulgaire / typique de l'IA / pas élégant	Langage visuel : trop de couleurs, dégradé lumineux, style trop présent	§4① et la liste « à ne pas faire » du design system
Seulement partiellement corrigé / pas cohérent	Les autres scènes n'ont pas suivi le changement de langage	§4①
Monotone / tout pareil	Chaque scène utilise la même technique de mouvement	§4②
Lourd / pas de variation / épuisant à regarder	Pas de variation de densité ou de luminosité : chaque scène est pleine, tout au long de la même couleur de fond	§4⑨, réduisez les images fixes en vignettes et alignez-les
Figé quand ça s'arrête	Quand le sujet s'arrête, l'arrière-plan et les environs s'arrêtent aussi	§4④ « Quand ça s'arrête »
Plat / vide / sans profondeur	Manque d'arrière-plan, d'avant-plan, ou de couche d'information ; ou le sujet est trop petit	§4④
Confus / on ne sait pas où regarder	Trop d'éléments qui attirent l'attention en même temps	§4④
Immobile / pas de dynamisme / pas de sensation d'espace	La caméra ne bouge pas, ou seulement un petit mouvement	§4⑤
Mouvement de caméra artificiel / 3D bizarre	Utilisation d'un zoom 2D pour simuler, ou objet 3D cassé	§4⑥
Le texte n'a pas d'impact	Seulement un fondu	§4③
Ça ressemble à un slogan / rythme lent	La voix off est coupée, avec des blancs, ou le débit est trop lent	§2
Le texte et la voix ne sont pas synchronisés	Les éléments ne sont pas liés au timing des mots	§2
Oppressant / trop plein	Le sujet remplit tout l'écran sans espace vide, ou n'est pas encadré	Réduire le sujet, ajouter un cadre, laisser de l'espace pour les titres et annotations

Deux règles :

Corriger un endroit, vérifier toute la vidéo : ce défaut existe-t-il dans d'autres scènes ?
Ne pas toucher à ce que l'utilisateur a dit qu'il aimait. Seulement ajuster ses couleurs et sa grille pour l'aligner, garder la technique inchangée.

Après chaque correction, revenir au message principal que la vidéo doit transmettre. Après plusieurs corrections, l'accident le plus fréquent est que chaque correction a bien résolu le problème pointé, mais que la vidéo entière ne parle plus du sujet initial.

Annexes : fichiers

Fichier	Description
`references/design-system.md`	Champs du design system + quatre exemples (point de départ, peut être entièrement remplacé)
`references/design-agent.md`	Instructions et format de retour pour l'agent de design (proposer trois design system + maquettes)
`references/pre-render-review.md`	Comment réaliser les trois filtres de relecture avant rendu
`references/review-habits.md`	Fichier des habitudes de relecture : format, entrées de démarrage, comment ajouter chaque défaut
`references/techniques.md`	Vocabulaire des techniques : nom, apparence, comment demander à l'IA, erreurs fréquentes
`references/engines.md`	Intégration des moteurs (HyperFrames · Remotion · autres), 3D réelle, voix off, effets sonores, licences
`references/case-0099.md`	Histoire complète d'une vidéo de 15 secondes de v1 à v7 : ce qui a été dit à chaque version, la cause, comment c'est corrigé
`examples/`	Tableau de contact de chaque version du cas ci-dessus (exemples corrects et incorrects) ; plus une autre vidéo test dans un style différent (cf. exemple C de `design-system.md`)
`scripts/preflight.py`	Métrique avant rendu : ne prend que des captures d'écran statiques, produit des images fixes alignées avec les marges de sécurité, des bursts, une checklist (nécessite Pillow)
`scripts/review.py`	Script d'auto-relecture : tableau de contact, extraction d'images à taille réelle, burst dense, détection d'arrêt (nécessite ffmpeg ; place les résultats dans `review/<nom_video>/` à côté de la vidéo, un dossier par version pour faciliter la comparaison)

sui-motion-graphic-reel

Qu'est-ce que sui-motion-graphic-reel ?

Demander à votre IA préférée

Documentation