Aller au contenu principal

Vidéos explicatives IA : le pipeline piloté par le code

Intermédiaire

Une soumission intitulée « Opus 5.5 is good at explainer videos » est restée près du sommet de Hacker News avec 319 points et 175 commentaires — et à la lecture du fil, le plus intéressant est le nombre de personnes qui se sont trompées sur le mécanisme. Elles ont supposé un modèle vidéo. Ce n'en est pas un.

Ce qui se passe est plus étrange et bien plus utile : un modèle de code écrit un programme d'animation déterministe, et un moteur de rendu distinct transforme ce programme en images. Le modèle ne voit jamais un seul pixel du résultat. Ce qui signifie que l'ensemble se comporte comme du logiciel — diffable, re-rendable, paramétrable et débogable — au lieu de se comporter comme une machine à sous que l'on re-prompte jusqu'à ce que ça ait l'air correct.

Cette page est le guide pratique qui manquait à ce fil : comment fonctionne le pipeline, lequel des trois moteurs de rendu choisir (et celui pour lequel les modèles sont mesurablement mauvais), les deux modes de défaillance qui cassent silencieusement le code d'animation écrit par un agent, l'arithmétique de rythme qui sépare un explicatif regardable d'un explicatif illisible, et où va réellement l'argent.

What you'll learn
  • Expliquer pourquoi un modèle de code bat un modèle vidéo sur les explicatifs — et ce qu'il abandonne
  • Nommer la raison pour laquelle Math.random() est interdit dans une animation rendue image par image, et ce qui le remplace
  • Choisir entre Remotion, Motion Canvas et Manim sur la licence et sur la qualité du code que les modèles écrivent
  • Repérer les deux pièges du code d'animation écrit par un agent : la scission des forks Manim et l'API Remotion périmée
  • Calculer une durée d'affichage minimale par diapositive au lieu de la deviner, pour que les spectateurs puissent vraiment lire
  • Prédire quel poste dominera la facture (ce n'est généralement pas le LLM)

Le mécanisme : le modèle écrit un programme, pas une vidéo​

Deux choses complètement différentes sont appelées « vidéo IA ».

Les modèles vidéo par diffusion (la famille traitée dans médias génératifs) prennent un prompt et émettent directement des pixels. Excellents pour du b-roll, un plan de drone, une texture, une ambiance. Mauvais pour tout ce qui doit être exactement juste : du texte lisible, un schéma d'architecture correct, l'interface réelle de votre produit, un chiffre qui doit afficher 40 %.

L'animation pilotée par le code prend le chemin inverse. Un modèle de code écrit le code source d'une animation — composants React, graphe de scène TypeScript, ou Python — et un moteur de rendu l'exécute. Le texte est du texte, donc il est net et correctement orthographié. Un schéma est une mise en page, donc il est exact. Votre logo est votre fichier de logo.

Cette scission explique le retour de flux de travail le plus courant du fil HN : le modèle « crée une page HTML et utilise des animations JS brutes cadencées », puis les images sont capturées et assemblées avec ffmpeg. Elle explique aussi ce que l'approche abandonne — elle ne peut pas inventer d'imagerie photographique, donc la plupart des pipelines réels appellent un modèle d'image ou un modèle vidéo pour le b-roll et le composent par-dessus.

La conséquence qu'il faut intérioriser : votre explicatif devient un dépôt. Changez le prix sur la diapositive 4, re-rendez, c'est fait. Localisez la voix off, re-rendez douze langues à partir des mêmes scènes. Ce n'est une propriété d'aucun modèle prompt-vers-vidéo.

Pourquoi le déterminisme est toute l'astuce​

Voici le détail qui décide discrètement si votre pipeline produit une vidéo propre ou une bouillie scintillante, et que presque personne n'évoque en écrivant sur le sujet.

Un moteur de rendu comme Remotion n'effectue pas un enregistrement d'écran de votre animation. Il ouvre la composition dans un Chrome headless, place l'horloge à l'image 0, prend une capture, place l'horloge à l'image 1, prend une capture, et ainsi de suite — et il fait cela sur plusieurs threads, en ouvrant la page plusieurs fois. Les images sont produites dans le désordre, en parallèle, dans des contextes de navigateur séparés.

Tout découle de là :

  • L'animation doit être une fonction pure du numéro d'image. Dans Remotion, c'est littéralement l'API : useCurrentFrame() vous donne l'image, interpolate() la transforme en valeur. Pas de minuteurs, pas de requestAnimationFrame, pas de transitions CSS pilotées par l'horloge murale. Une transition CSS rend ce qui se trouvait être à mi-parcours au moment où la capture s'est déclenchée.
  • Math.random() est cassé par construction. Il renvoie une valeur différente dans chaque thread et à chaque chargement de page, donc une particule « aléatoire » saute à une nouvelle position à chaque image. Remotion fournit random(seed) — un PRNG mulberry32 à graine — précisément pour cela : random(1) renvoie toujours 0.07301638228818774. Idem pour spring(), qui est un calcul pur mis en cache indexé sur (frame, fps, config).
  • Les images perdues deviennent impossibles. Un enregistrement d'écran d'une animation lourde perd des images quand le CPU ne suit pas. Le rendu image par image prend simplement plus de temps. C'est pourquoi un rendu de 5 minutes sur un portable peut produire une vidéo qui se lit parfaitement fluide.
Watch out
  • Si vous ne retenez qu'une règle pour demander à un agent d'écrire du code d'animation : interdisez l'horloge murale. Pas de setTimeout, pas de transition CSS, pas de Date.now(), pas de Math.random(). Chaque valeur visuelle doit dériver du numéro d'image courant. Les modèles iront chercher les transitions CSS parce que c'est ce dont le corpus web est rempli.

Les trois moteurs​

Tous les trois sont réels, activement maintenus, et produisent une sortie de qualité broadcast. Ils diffèrent par le langage, par la licence, et — surtout — par la fiabilité avec laquelle un modèle les écrit.

RemotionMotion CanvasManim
LangageReact / TypeScriptTypeScript (générateurs)Python
Dépôtremotion-dev/remotionmotion-canvas/motion-canvas (~19,2 k étoiles)ManimCommunity/manim (~41 k) · 3b1b/manim (~94 k)
LicenceSource-available + Licence EntrepriseMITMIT
Terrain de prédilectionVidéo produit/lancement, UI, explicatif riche en texteMotion design précis à la timelineVisualisation mathématique et algorithmique
Qualité du code écrit par un modèleForte — et elle livre des agent skills officiellesCorrecteLa plus faible des trois (voir ci-dessous)

Deux points de ce tableau méritent mieux qu'une ligne.

Le piège de Remotion, c'est la licence, pas le code​

Remotion n'est pas MIT. C'est du source-available avec une licence commerciale à deux niveaux, et le seuil est assez bas pour attraper la plupart des équipes : gratuit pour les particuliers, les associations, l'évaluation, et les sociétés à but lucratif jusqu'à 3 employés ; une Licence Entreprise payante pour les organisations à but lucratif de plus de trois.

La seconde scission compte davantage si vous construisez un produit plutôt qu'une vidéo :

  • Remotion for Creators — par siège, destiné au rendu à faible volume au sein de et pour votre propre entreprise, explicitement pas pour servir des vidéos personnalisées à vos utilisateurs finaux.
  • Remotion for Automators — par rendu, c'est le palier dans lequel vous atterrissez dès qu'un agent rend des vidéos pour des clients. À partir de la version 5.0, il s'accompagne d'une remontée de télémétrie obligatoire avec une clé de licence.

Donc « mon agent génère une vidéo par inscription » n'est pas un cas d'usage Creators. Budgétisez-le en Automators avant de livrer. Si c'est rédhibitoire, Motion Canvas est en MIT et couvre une grande partie du même terrain.

Le piège Manim : deux forks, un seul nom d'import​

Celui-ci brûle les gens qui n'en ont jamais entendu parler, et il explique aussi une observation du fil HN — que de bons modèles de code écrivent du Manim moins bon que ce à quoi on s'attendrait, avec des retours de la communauté indiquant que Gemini s'en sort actuellement mieux qu'Opus 5.5.

Il existe deux Manim :

  • 3b1b/manim — l'original de Grant Sanderson, celui des vidéos célèbres, ~94 k étoiles, installé sous le nom manimgl.
  • ManimCommunity/manim — le fork communautaire, ~41 k étoiles, celui qui est réellement documenté et maintenu pour un usage général, installé sous le nom manim.

Ils sont incompatibles au niveau de l'API et tous deux s'importent par from manim import *. Chaque tutoriel, réponse StackOverflow et billet de blog du corpus d'entraînement relève de l'un ou de l'autre, sans étiquette. Le modèle écrit donc du code plausible qui mélange les deux dialectes, et Python lève une exception sur une méthode qui existe dans l'autre fork. Ce n'est pas un échec de raisonnement ; c'est un échec d'espace de noms empoisonné.

Le correctif est ennuyeux et il fonctionne : épinglez le fork dans votre prompt et dans votre environnement, et donnez à l'agent la vraie surface d'API de la version au lieu de le laisser la reconstituer de mémoire.

Épinglez le dialecte Manim avant que l'agent n'écrive une ligne

Use ManimCommunity Manim (the "manim" package on PyPI), NOT 3b1b/manimgl.
Before writing any scene, run:
python -c "import manim; print(manim.__version__)"
and confirm the version. If a class or method you want is not in that
version's API, do not use it — check with:
python -c "import manim; print([n for n in dir(manim) if 'Text' in n])"
Never mix manimgl APIs (e.g. ShowCreation) with community APIs (Create).

Le piège de l'API périmée (édition Remotion)​

Le même problème de corpus empoisonné frappe Remotion pour une raison différente : la bibliothèque a évolué plus vite que les données d'entraînement.

Dans le Remotion actuel, les composants média vivent dans @remotion/media, et les propriétés de rognage sont trimBefore / trimAfter. La prévisualisation et le rendu peuvent même utiliser délibérément des composants différents — Html5Audio depuis remotion pendant la prévisualisation, Audio depuis @remotion/media au rendu, bascule via useRemotionEnvironment(). Un modèle entraîné surtout sur du matériel plus ancien écrit import {Audio} from 'remotion' avec startFrom, qui est l'ancienne forme.

Ce code peut encore s'exécuter. Il peut aussi silencieusement ne rien faire d'utile, ce qui est pire.

C'est exactement pour cela que Remotion publie des Agent Skills officielles — un ensemble de douze skills qui remettent à un agent les bonnes pratiques actuelles au lieu d'espérer qu'il s'en souvienne. Elles sont conçues pour Claude Code, Codex, Cursor et consorts, et suivent le même format ouvert traité dans SKILL.md comme standard ouvert.

Installer les agent skills officielles de Remotion

npx skills add remotion-dev/skills

Les skills sont granulaires, et c'est tout l'intérêt — vous invoquez celle qui correspond à la phase de travail : /remotion-create pour l'échafaudage, /remotion-markup pour l'animation et la typographie, /remotion-studio pour prévisualiser, /remotion-render pour rendre, /remotion-captions pour les sous-titres, plus remotion-best-practices comme parapluie quand vous n'êtes pas sûr. Les skills maintenues par l'éditeur sont le correctif le moins cher disponible contre la connaissance périmée qu'a un modèle d'une bibliothèque qui bouge vite : une installation, et l'agent cesse de deviner.

Le pipeline qui fonctionne vraiment​

Le plus grand levier de qualité n'est pas un meilleur prompt pour la vidéo entière. C'est de découper le travail pour que le modèle fasse le travail de jugement et que le moteur de rendu fasse le travail de déterminisme — avec un artefact lisible par un humain entre les deux.

Guided walkthrough1 of 7
  1. Demandez d'abord une liste de scènes en JSON : par scène, un titre, le texte à l'écran, l'intention visuelle et une durée en secondes. C'est l'étape peu coûteuse et relisable. Vous pouvez lire douze scènes en trente secondes et corriger le récit avant qu'un seul composant n'existe — et corriger l'histoire est la retouche qui améliore le plus la vidéo. Le code généré à partir d'un storyboard relu est aussi bien plus cohérent que le code généré à partir d'un paragraphe d'intentions vagues.

Rendre depuis la CLI, puis trouver votre vraie concurrence

# deterministic render, reproducible in CI
npx remotion render src/index.ts MyExplainer out/video.mp4

# stop guessing --concurrency: measure it
npx remotion benchmark src/index.ts MyExplainer --concurrencies=2,4,8 --runs=3

Rythme : la raison pour laquelle la plupart des explicatifs IA sont irregardables​

La plainte la plus constante du fil HN n'était pas que les vidéos étaient laides. C'était qu'elles allaient trop vite pour être lues. Les diapositives apparaissent, le texte s'anime, et il a disparu avant qu'un humain n'ait fini la phrase.

C'est un bug qui a une formule, pas une affaire de goût. La vitesse de lecture d'un adulte sur du texte à l'écran non familier se situe autour de 200–250 mots par minute, et un spectateur a aussi besoin de temps pour trouver le nouveau texte avant de commencer à le lire. Donc :

# minimum dwell time for a text block, in frames
words = number of words in the block
wpm = 200 # conservative for unfamiliar on-screen text
settle = 0.4 # seconds to notice and locate the new text
exit = 0.3 # seconds of breathing room before it leaves

dwell_seconds = settle + (words / wpm) * 60 + exit
dwell_frames = ceil(dwell_seconds * fps)

# worked example: a 14-word bullet at 30 fps
# 0.4 + (14 / 200) * 60 + 0.3 = 4.9 s -> 147 frames

Deux remarques qui rendent cela réellement utile :

  • Animez l'entrée vite, tenez longtemps. La transition d'entrée devrait durer 200–400 ms ; c'est le maintien qui consomme le budget d'affichage. Les modèles ont tendance à faire l'inverse — un long fondu élégant, puis un maintien court.
  • S'il y a une narration, le plancher d'affichage est la longueur de la narration. Le texte doit rester à l'écran au moins aussi longtemps que la phrase qui le décrit. C'est pourquoi dériver la durée de scène de l'audio synthétisé (étape 4 ci-dessus) corrige le rythme presque gratuitement.

Bornez chaque scène à max(dwell_frames, narration_frames) et une bonne partie de l'impression de « vidéo slop IA » disparaît, sans aucun changement des visuels.

Ce que ça coûte, et quel poste domine​

Les retours de la communauté dans le fil HN situent un explicatif généré complet autour de 3–4 $ de dépense d'API, avec le détail notable que le coût était dominé par les appels au modèle d'image, pas par le modèle de langage. Un commentateur a rapporté avoir généré une vidéo de 5 minutes sur un MacBook Air M4 en environ 5 minutes de temps réel à l'aide d'un pipeline orchestré.

Traitez les chiffres absolus comme périssables, mais la forme est structurelle et mérite qu'on la planifie :

  • Le LLM est bon marché ici. Un storyboard plus quelques centaines de lignes de code d'animation, cela fait peu de tokens. Même au tarif flagship, cela se compte en centimes. Voir ce que coûte l'IA chez les différents fournisseurs.
  • Les appels génératifs par actif dominent. Chaque image ou clip de b-roll généré est un appel payant distinct, et ils se multiplient par le nombre de scènes. C'est le poste à plafonner.
  • Le calcul est le vôtre. Le rendu tourne sur votre machine ou votre CI, donc c'est du temps et de l'électricité plutôt que de la dépense d'API — jusqu'à ce que vous le déplaciez vers un moteur de rendu serverless, auquel moment ça devient les deux.
  • Les re-rendus sont quasi gratuits, ce qui constitue tout l'avantage structurel. Corriger une coquille sur la diapositive 4 coûte un rendu, pas une régénération. Localiser en douze langues coûte douze passages TTS et douze rendus, pas douze vidéos.

Le geste de budgétisation pratique : générez les images une fois, versionnez-les comme actifs, et gardez les re-rendus sans génération d'actifs. Un pipeline qui régénère l'imagerie à chaque rendu est celui qui produit une facture surprise.

Le problème de l'uniformité​

La critique la plus acérée du fil est celle qu'il faut prendre au sérieux : en quelques semaines de diffusion de ces outils, les productions sont devenues reconnaissables. Mêmes fonds en dégradé, mêmes cartes qui entrent en ressort, mêmes puces de trois mots, même voix alerte. Plusieurs commentateurs ont aussi signalé des textes répétitifs et, dans un cas, une vidéo affirmant avec aplomb un sujet entièrement faux — un site de référence sur Twilight Imperium décrit comme une startup de données IA.

Si vous utilisez cela sérieusement, les leviers qui dé-uniformisent mesurablement la sortie :

  • Fournissez le design system, ne le laissez pas être inventé. Transmettez votre vraie palette, votre échelle typographique, votre échelle d'espacement et votre logo sous forme de constantes importées par les composants. Les prompts sous-spécifiés sont exactement l'endroit où le style maison d'un modèle s'infiltre.
  • Écrivez le texte vous-même, ou éditez-le durement. Les visuels sont la partie où les modèles sont bons. Le récit est la partie qui se lit comme générée.
  • Utilisez vos propres captures d'écran comme actif vedette. De vraies images de produit composées dans une scène générée est le geste anti-uniformité le plus puissant, et cela corrige aussi le risque d'hallucination — la vidéo ne peut pas décrire votre produit de travers si le produit est à l'écran.
  • Vérifiez les affirmations comme de la documentation. Tout élément factuel dans un explicatif est une affirmation factuelle publiée en votre nom, sans le chemin de correction facile d'une page de texte. Vérifiez avant de rendre, pas une fois que c'est sur YouTube.
  • Cassez une convention exprès. Un choix délibéré que le gabarit par défaut ne ferait pas — un format d'image inhabituel, du silence là où l'on attend de la musique, un actif dessiné à la main — suffit généralement à empêcher la sortie d'être lue comme un réglage machine par défaut.
Vidéo pilotée par le code : le vocabulaire
Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 8

Ce à quoi c'est bon, et ce à quoi ça ne l'est pas​

Il faut être honnête, parce que les sceptiques de ce fil n'avaient pas tort : une grande partie de ce qui est produit est un diaporama animé avec une voix off. C'est un artefact parfaitement valable pour un changelog, un lancement, une note de version ou un parcours d'onboarding — et un piètre substitut à un véritable enseignement, qui exige un exemple travaillé, un faux pas, et une raison de s'y intéresser.

Tournez-vous vers le pipeline piloté par le code quand :

  • Le contenu doit être exactement juste — vraie UI, vrais chiffres, vrais schémas.
  • Vous devrez le modifier plus tard, ou le livrer en plusieurs langues.
  • Le même gabarit produira de nombreuses vidéos à partir de données différentes.

Tournez-vous vers autre chose quand le but est de l'image photographique (utilisez un modèle vidéo), ou quand la valeur réside dans un humain qui explique une idée difficile d'abord mal puis bien — ce qui reste la chose qu'aucun pipeline ne produit.

Check yourself

0/5
  1. Un modèle écrit une animation explicative en utilisant des transitions CSS et setTimeout. La prévisualisation est parfaite. Que se passe-t-il au rendu ?
  2. Le code Manim de votre agent échoue sans cesse sur des méthodes qui « devraient exister ». Cause la plus probable ?
  3. Une startup de 3 personnes construit un produit qui rend une vidéo Remotion personnalisée pour chaque nouvelle inscription. Position en matière de licence ?
  4. Les relecteurs disent que votre explicatif généré est « trop rapide ». Correctif structurel le moins coûteux ?
  5. Vous vous attendez à ce que le LLM domine le coût d'un explicatif généré. Que montrent réellement les retours ?

Sources et lectures complémentaires​

Suite​