Créer une vidéo avec Claude Code : le motion design en code

Depuis la sortie de Claude Opus 5.5, des vidéos de motion design présentées comme « faites en un prompt » circulent partout. On peut en effet créer une vidéo avec Claude, mais pas comme on l'imagine : Claude n'invente pas des pixels, il écrit le programme qui dessine chaque image, et Claude Code lance le rendu. Tout ce que vous voyez ci-dessous, c'est du code.

En octobre 2026, nous avons produit une vingtaine de vidéos courtes pour TikTok et Instagram Reels, destinées à un logiciel de devis et de facturation pour artisans. Nous avons testé trois façons de faire et noté ce qui a vraiment fait la qualité. Cet article donne la méthode complète : le moteur, le mouvement, la boucle de critique, le brief à copier, et les limites à connaître avant de s'y mettre.

Peut-on vraiment créer une vidéo avec Claude ?

Oui, à condition de bien comprendre ce que fait le modèle. Il existe aujourd'hui trois façons de faire une vidéo avec Claude, qui n'ont pas grand-chose en commun.

Cet article traite de la première. C'est celle qui fait parler d'elle, et celle qui tire le mieux parti d'un agent de code : le résultat est déterministe (deux rendus donnent les mêmes octets), modifiable ligne par ligne, et sans question de droits sur des images générées, puisqu'il n'y en a pas. Elle ne sait pas, en revanche, produire une prise de vue réelle ou un visage photoréaliste.

Concrètement, vous ouvrez Claude Code dans un dossier vide, vous lui donnez un brief et des règles, et il écrit une page HTML avec un <canvas>, quelques modules JavaScript, un script de rendu en Python et une partition sonore. Il lance lui-même le rendu, tire des planches d'images, les regarde et corrige. Si l'outil n'est pas encore installé sur votre poste, notre guide pour installer Claude Code prend dix minutes.

Opus 5.5 et les vidéos « faites en un prompt »

Après la sortie de Claude Opus 5.5 le 22 septembre 2026, les réseaux se sont remplis de vidéos de motion design, de publicités et de clips présentés comme sortis d'un seul prompt. Le progrès du modèle est réel. Anthropic met en avant le code agentique et la lecture de visuels, deux capacités dont dépend directement ce travail : écrire un moteur d'animation correct du premier coup, puis juger ses propres images.

Mais « un prompt » est un raccourci. Derrière les vidéos réussies, on retrouve presque toujours un long brief, des exemples, des règles écrites et des outils déjà installés. Notre propre règle de travail le dit ainsi : le modèle n'écrit pas une vidéo, il écrit un programme qui peint chaque image ; le prompt compte pour 10 % du résultat, le harnais pour 90 %. Le harnais, c'est l'ensemble de ce qui entoure le modèle :

• un moteur de rendu déterministe, toujours le même d'une vidéo à l'autre ;
• une bibliothèque de mouvement (ressorts, sauts, chutes) déjà écrite et testée ;
• un document de règles qui dit ce qui est interdit et pourquoi ;
• une boucle de critique, avec une grille de notation et une liste des défauts déjà rencontrés ;
• une vidéo de référence que les suivantes copient.

C'est exactement la logique d'un fichier CLAUDE.md et des skills de Claude Code sur un projet logiciel : le savoir-faire est écrit une fois, dans le dépôt, et l'agent le relit à chaque session.

Notre retour d'expérience : trois façons de faire

Pour la vingtaine de vidéos du projet, nous avons essayé trois techniques de rendu, sur des films d'environ 30 secondes au format vertical 1080 × 1920.

Trois enseignements. D'abord, la taille du code ne change presque pas d'une technique à l'autre : ce qui coûte, c'est l'histoire, le mouvement et les corrections, pas le framework. Ensuite, l'aperçu en direct compte beaucoup pour l'humain qui suit le travail, et c'est la principale faiblesse de l'approche Pillow. Enfin, le moteur maison a gagné sur la vitesse de rendu parce que chaque image est indépendante : six pages Chromium travaillent en parallèle sans se coordonner.

Remotion reste un très bon choix pour une équipe React qui produit une série à partir de gabarits, et il fournit ses propres skills pour Claude Code. Nous détaillons son installation, sa licence et ses limites dans Remotion et Claude Code, avec la comparaison face à HyperFrames.

Ce qui a fait la qualité, en revanche, ne dépendait d'aucun outil : un concept fort (un objet qui se transforme sans jamais couper, ou une histoire muette qui se comprend sans le son), des ressorts physiques pour tout ce qui bouge, une grille à 120 BPM avec une musique synthétisée calée dessus, et surtout la boucle de critique.

Le contrat de rendu : une fonction seek(t)

Tout repose sur une règle : la page expose une fonction window.seek(t) qui peint l'image exacte de l'instant t, sans rien savoir des images précédentes. Pas de transition CSS, pas de setTimeout, pas de requestAnimationFrame pendant le rendu, pas de Math.random (un hasard à graine à la place). On doit pouvoir peindre l'image 812 sans calculer les 811 autres.

// index.html : la résolution interne est la taille de sortie
canvas.width = 1080;
canvas.height = 1920;
window.seek = (t) => seek(ctx, t);   // fonction pure du temps

// Playwright attend que les polices soient chargées
window.pret = (async () => {
  await document.fonts.load('800 40px Affiche', 'ÉÈÀéè€ 0123');
  seek(ctx, 0);
  return true;
})();

Cette contrainte paraît austère, elle rend tout le reste possible :

• rendu parallèle : la page 1 prend les images 0, 6, 12, la page 2 les images 1, 7, 13, et ainsi de suite ;
• image figée à la demande : index.html?t=12.5 affiche l'instant exact dont on discute ;
• flou de mouvement : on rend plusieurs sous-images par image et ffmpeg les moyenne ;
• test de déterminisme : la même image rendue deux fois a la même empreinte, et l'image à t = 0 est identique à la dernière, ce qui donne une boucle parfaite.

Le script de rendu ouvre la page avec Playwright, appelle seek(t), lit le canvas en PNG (et non une capture d'écran de la page, qui dépendrait de l'écran), puis ffmpeg assemble :

# 4 sous-images par image, moyennées : flou de mouvement à 180°
ffmpeg -framerate 120 -i %05d.png \
  -vf "tmix=frames=4,select='not(mod(n+1\,4))',setpts=N/(30*TB),format=yuv420p" \
  -r 30 -c:v libx264 -crf 16 -movflags +faststart muet.mp4

Un détail appris à nos dépens : avec seulement 2 sous-images, les objets rapides se dédoublent au lieu de flouter. Il en faut 4. C'est ce qui fait passer le rendu d'un film chargé d'une vingtaine de secondes à environ six minutes, et c'est pourquoi on ne rend la vidéo complète qu'aux tours qui en ont besoin.

Le mouvement : des ressorts et une grille de tempo

La différence entre une animation « générée » et une animation qui semble faite à la main tient surtout au mouvement. Les courbes d'animation classiques (l'easing : accélération puis décélération) donnent un mouvement correct mais mécanique. Un ressort amorti accélère, dépasse à peine sa cible et se pose, comme un objet réel.

Le ressort se calcule directement à partir du temps écoulé, sans simulation image par image, ce qui respecte le contrat seek(t). Il est coupé à exactement 1 quand l'oscillation devient invisible, pour que la boucle retombe pile et que deux rendus soient identiques :

// k : raideur (rad/s), d : amortissement. Renvoie 0 avant t = 0, 1 au repos.
export function spring(t, k = 24, d = 0.62) {
  if (t <= 0) return 0;
  const env = Math.exp(-d * k * t);
  if (env * (1 + k * t) < 1e-4) return 1;
  if (d >= 1) return 1 - env * (1 + k * t);
  const wd = k * Math.sqrt(1 - d * d);
  return 1 - env * (Math.cos(wd * t) + ((d * k) / wd) * Math.sin(wd * t));
}

Quelques réglages suffisent pour tout un film : un ressort vif et légèrement surpris pour l'interface (k 24, d 0,62), un ressort sans rebond pour la grosse typographie (k 19, d 1), un ressort lent pour le décor, un ressort doux sans dépassement pour le curseur. Quand une valeur change plusieurs fois de cible, on additionne un ressort par changement au lieu d'en redémarrer un, ce qui évite tout à-coup.

Une grille de tempo plutôt que des secondes

Toute la partition s'écrit en temps musicaux, à 120 BPM (un temps toutes les 0,5 seconde). Les changements tombent sur les temps, les grands moments sur les temps forts, et la musique synthétisée suit la même grille. Résultat : chaque impact visible tombe sur un son sans réglage manuel. Les autres règles de rythme que nous avons gardées :

• quelque chose de nouveau toutes les 1 à 2 secondes, et un événement visible par demi-seconde pendant l'accroche ;
• un objet entre en une dizaine d'images, jamais en « pop » instantané ni en simple fondu ;
• un texte reste à l'écran 0,3 seconde par mot plus 0,5 seconde, avec un minimum de 1,4 seconde, et une fonction le vérifie automatiquement avant chaque rendu.

Cette dernière règle a demandé plusieurs allers-retours : la première version était trop rapide pour être lue, la suivante trop lente pour tenir l'attention. Une fois la règle écrite et contrôlée par le code, le problème n'est plus revenu.

La boucle de critique : Claude regarde ses propres images

C'est l'étape qui a le plus amélioré nos vidéos. Claude ne voit pas une vidéo, mais il lit très bien des images. On lui fait donc tirer des planches : deux images par seconde sur une seule feuille, la même planche réduite à la largeur d'un téléphone, et des bandes d'images consécutives autour des moments délicats.

# Planche contact : 2 images par seconde
ffmpeg -i video.mp4 -vf "fps=2,scale=270:-1,tile=6x10" -frames:v 1 contact.png
# Bande de 12 images consécutives autour de 4,1 s
ffmpeg -ss 4.1 -i video.mp4 -vf "scale=320:-1,tile=12x1" -frames:v 1 bande.png
# Lisibilité au format téléphone
ffmpeg -i video.mp4 -vf "fps=1,scale=360:-1,tile=5x3" -frames:v 1 telephone.png

À chaque tour, Claude regarde ces planches « comme un directeur d'animation exigeant, pas comme l'auteur », note la vidéo sur 10 selon une grille fixe (accroche, lisibilité au téléphone, qualité du mouvement, vie du personnage, variété, composition, fidélité à la marque, synchronisation du son, silhouette), écrit les trois pires problèmes avec leur horodatage dans un journal, corrige, et recommence. Il faut 3 à 5 tours pour atteindre 8 sur 10 partout.

Voici des défauts réels que cette boucle a trouvés et corrigés sur nos vidéos :

Deux remarques. Certains défauts, comme le geste involontaire ou la forme ambiguë, n'auraient jamais dû être publiés, et c'est la notation explicite d'un critère « silhouette correcte et décente » qui les a fait sortir. Ensuite, chaque défaut trouvé devient une règle écrite pour les vidéos suivantes : la liste ci-dessus vit dans notre document de méthode, et l'agent la relit avant de commencer. C'est le même principe que pour vérifier une réponse de Claude : on ne lui fait pas confiance, on lui fait contrôler son travail selon des critères écrits.

Pointer la méthode vers un produit et sa marque

Une fois le moteur en place, la même méthode sert à n'importe quel produit. Il suffit d'un second document, propre au projet, qui l'emporte sur les règles générales : la palette en hexadécimal, les polices et leurs fichiers, le logo, la signature de fin, les libellés exacts de l'interface et ce qu'on a le droit d'affirmer sur le produit. Voici par exemple une micro-publicité de cinq secondes pour Heeya, l'assistant de service client que nous éditons.

Pour cette vidéo, l'agent a repris la palette, la police Inter et la grammaire du widget depuis le site du produit, sans rien inventer sur ses fonctions ni afficher aucun chiffre. L'histoire se lit sans le son : une question, le document où se trouve la réponse, la réponse, un pouce levé. Avec un flou de mouvement à 8 sous-images, les 5 secondes se rendent en 4 secondes.

Les règles qui comptent le plus quand on passe à un vrai produit :

• L'interface est un décor dessiné, pas une capture d'écran. Fenêtres, champs, boutons et bulles sont redessinés en code, entrent par ressort, vivent (le texte se tape seul, le bouton s'écrase au clic) et sortent. Les libellés sont exactement ceux du produit.
• Une seule chose au premier plan à la fois. Une fenêtre qui entre pendant que le personnage joue le cache toujours à un moment.
• Une histoire qui se comprend sans le son et sans lire. Sur les réseaux, une grande partie des vidéos est regardée en muet : peu de texte, 6 à 8 blocs de 2 à 5 mots, gros et lisibles sur un téléphone.
• La vérité produit est écrite d'avance. Les chiffres, les fonctions montrées et les promesses autorisées sont listés dans le brief. Le modèle n'invente pas une fonction parce qu'elle ferait une jolie scène.
• Une liste d'interdits visuels : titre centré sur un dégradé, halos lumineux, particules génériques, cerveaux et robots pour dire « IA », logo seul à la fin sans histoire.

Pour les vidéos courtes destinées aux réseaux sociaux, nous ajoutons trois règles de format : l'accroche des deux premières secondes porte la vidéo (une image forte, un son, une phrase courte), le sujet compte plus que la réalisation, et une fin qui reboucle sur le début pousse à revoir. Le moteur gère cette boucle parfaite : la fin du fichier joue le préambule de l'accroche, si bien qu'au moment où la vidéo recommence, rien ne saute.

Le brief à donner à Claude Code

Voici une version condensée du gabarit que nous donnons à l'agent. Il suppose que le moteur et le document de règles sont déjà dans le dossier du projet ; sans eux, le même brief donne un résultat bien plus inégal.

Tu es le réalisateur, l'animateur, le sound designer et l'ingénieur
de rendu d'un film de [DURÉE] s en [1080 × 1920] à 30 i/s, rendu en code.
Lis MOTION_PROMPT.md et le dossier du moteur, puis la vidéo de référence
[CHEMIN]. Pas de rendu final avant la fin de la boucle de critique.

Le film en une ligne : [ce que le spectateur ressent à la fin].
Objectif : [visibilité / marque / vente].
Variante : [histoire avec personnage | objet unique qui se transforme].
Accroche (0 à 2 s) : [image forte + son + phrase courte].
Boucle : la dernière image est la première.
Texte à l'écran : au plus [N] blocs de 2 à 5 mots.
Libellés d'interface exacts : [liste].
Marque : [palette hexa, polices et fichiers, logo, signature].
Son : musique synthétisée à 120 BPM + bruitages.
Vérité : [faits autorisés et interdits, chiffres].
Contraintes : port libre vérifié, images temporaires hors du dépôt.

Rapport final : chemins, histoire en 3 phrases, notes par critère,
3 corrections majeures, ce qu'un humain doit encore vérifier
(écoute, silhouette).

Trois choses font la différence dans ce brief. La ligne de film force à avoir une idée avant d'avoir des images. La variante tranche entre une histoire avec personnage (pour une émotion, une accroche forte) et un objet unique qui se transforme d'étape en étape (pour montrer un parcours ou une interface). Et le rapport final oblige l'agent à dire ce qu'il n'a pas pu vérifier, au lieu d'annoncer que tout est parfait.

Si vous gérez plusieurs vidéos, rangez ce brief et le document de règles dans le dépôt, comme un skill de Claude Code. La première vidéo réussie devient l'implémentation de référence : les suivantes copient son dossier, gardent son moteur et ne changent que l'histoire.

Temps, droits et limites

Le temps réel passé

Le rendu est rapide. Le temps humain est ailleurs : écrire le brief et la ligne de film, relire les planches de chaque tour, trancher les choix que l'agent signale, écouter le son, et faire les allers-retours de rythme. La première vidéo d'un projet est de loin la plus longue, parce qu'elle fixe le moteur, le personnage et les règles de marque. Les suivantes vont beaucoup plus vite. Si vous comptez faire une seule vidéo, un outil de montage classique ou un prestataire sera souvent plus simple.

Les droits

• Polices : utilisez des fichiers de police dont la licence couvre la vidéo et la diffusion commerciale, et chargez-les en local plutôt que de dépendre des polices du poste.
• Musique : synthétisée dans le code, elle ne pose pas de question de droits. Une piste du commerce, si, avec ses conditions d'usage sur les réseaux.
• Images : tout étant dessiné en code, il n'y a pas d'image générée par IA dont l'origine serait discutable. N'utilisez que vos propres marques et logos.
• Outils : Remotion est gratuit pour les particuliers et les entreprises de trois salariés au plus, et demande une licence entreprise au-delà. HyperFrames est sous licence Apache 2.0. Un moteur maison n'a que les licences de Playwright et ffmpeg.

Ce que la méthode ne remplace pas

Elle ne remplace pas la direction artistique : quelqu'un doit décider de l'intention, choisir entre deux propositions et refuser ce qui ne va pas. Elle ne remplace pas un motion designer pour une pièce phare de la marque, où chaque image se travaille à la main. Elle ne fait pas de prise de vue réelle. Elle excelle en revanche sur les formats courts et répétables : vidéos de réseaux sociaux, démonstrations d'interface, chiffres animés, déclinaisons d'une même vidéo par offre ou par métier.

Pour une PME, l'intérêt est double. On produit des formats que l'équipe n'aurait pas faits du tout, faute de budget ou de compétence, et on apprend au passage à travailler avec un agent de code sur un projet où chaque erreur se voit immédiatement. C'est un très bon exercice pour une équipe qui découvre Claude Code. Pour des profils marketing ou produit qui ne développent pas, la formation vibe coding couvre le socle (terminal, Git, petits pas, vérification) ; pour une équipe technique, la formation Claude Code va jusqu'aux skills, aux sous-agents et aux permissions.

Questions fréquentes sur les vidéos créées avec Claude

Pour aller plus loin

• Remotion et Claude Code : installer les skills de Remotion, temps de rendu, licence et comparaison avec HyperFrames.
• Le guide Claude Code : l'outil, ses usages et sa mise en place en équipe.
• Skills, sous-agents et hooks de Claude Code : ranger une méthode dans le dépôt pour que l'agent la relise.
• Claude Code pour PowerPoint : un autre usage de l'agent hors du code applicatif.
• Claude Opus 5.5 en entreprise : prix, cache et choix du modèle.

Sources

• Anthropic, présentation de Claude Opus 5.5 (22 septembre 2026)
• Playwright pour Python, documentation officielle
• ffmpeg, documentation des filtres (tmix, tile, loudnorm)
• Remotion, conditions de licence
• HyperFrames, dépôt open source de HeyGen