Construire un studio d’animation parallaxe 2.5D en une seule session avec Claude Code : 3 segments de code clés pour un export MP4 image par image déterministe

Note de l’auteur : des invites à la formule de compensation de profondeur de champ, en passant par l’export image par image avec Playwright + ffmpeg, voici le détail complet de la construction, avec Claude Code, d’un studio d’animation parallaxe 2.5D dont l’export ne perd aucune image.

Beaucoup de gens qui utilisent pour la première fois un assistant de programmation IA pour faire de l’animation vivent la même scène : la prévisualisation est fluide dans le navigateur, mais dès qu’on exporte la vidéo, ça saccade, des images sautent et la durée ne correspond plus. Le problème vient souvent de l’architecture : dès le départ, on n’a pas traité l’export comme une partie de la conception. Cet article suit un fil conducteur : une fonction pure renderAt(t) + une capture d’écran avec seek image par image. On y explique comment construire avec Claude Code, en une seule session, un studio d’animation parallaxe 2.5D et exporter des MP4 de façon fiable.

Ce n’est pas une énième démo du type « demandez à l’IA de vous écrire une animation ». L’article détaille la dérivation de la formule de compensation de profondeur de champ, un bug de décalage très typique, et la différence fondamentale entre la lecture en temps réel et l’export image par image.

Ce que vous allez en tirer : une structure d’invite réutilisable, une chaîne d’export reproductible et une liste de vérifications transposable à d’autres projets de vidéo programmatique.

L’essentiel sur le studio d’animation parallaxe 2.5D avec Claude Code

La pratique décrite ici vient d’un article publié le 9 novembre 2026. L’auteur a utilisé Claude Code avec Opus 5.5 pour créer, en une seule session, un studio dans un unique fichier HTML, accompagné d’un script d’export Playwright d’environ 25 lignes. Sur son portable, une vidéo de 6 secondes en 720p (180 images) s’exporte en 20 secondes environ. Il ne donne pas sa configuration matérielle : ce temps n’est donc qu’un ordre de grandeur.

Le principe de l’animation parallaxe 2.5D

L’idée du 2.5D, c’est de placer des éléments 2D à plat à différentes profondeurs d’un espace 3D, puis de faire traverser tout ça par une caméra virtuelle. Les calques proches de la caméra bougent vite, les calques lointains bougent lentement, et l’œil interprète cet écart de vitesse comme de la profondeur : c’est la parallaxe. Pas de modélisation, pas d’éclairage, pas de moteur 3D : les propriétés CSS perspective et preserve-3d du navigateur suffisent.

Ce qui distingue un « studio » d’une « animation jetable », c’est la présence de trois composants : le graphe de scène, la timeline et le moteur de rendu déterministe. Beaucoup de tutoriels sautent le troisième, alors que c’est lui qui décide si le MP4 exporté va saccader ou non. Dès la première ligne de votre invite, il faut donc en faire une exigence impérative.

Configuration de l’environnement et du modèle pour le studio 2.5D de Claude Code

Les ressources de référence recommandent d’utiliser Opus 5.5 pour la première construction. Dans son aperçu des modèles, Anthropic le positionne comme un modèle dédié à « la programmation agentique de longue durée et au travail de connaissance », avec une fenêtre de contexte de 1M tokens et une sortie maximale de 128K. Côté tarifs officiels, comptez 4 / 20 dollars par million de tokens en entrée / sortie ; pour les prix réels, référez-vous à la page officielle.

Je vous conseille de verrouiller l’ID exact du modèle dès le lancement, afin d’éviter qu’un changement d’alias en cours de projet ne modifie le comportement :

claude --model claude-opus-5-5 --effort high

Opus 5.5 utilise par défaut l’effort medium. Pour la première construction, l’agent doit écrire correctement du premier coup les maths de projection, le moteur de keyframes et le pipeline d’export : mieux vaut donc passer en high. Ensuite, pour de petites retouches comme modifier des valeurs de keyframes ou une couleur, vous pouvez revenir à medium pour économiser des tokens.

Les ressources de référence ne fournissent aucune donnée comparative sur le rendu d’une construction équivalente avec d’autres modèles, ni sur l’écart de coût. Si vous voulez changer de modèle, lancez la même invite avec chacun, puis comparez point par point grâce à la méthode de validation par image fixe présentée plus loin.

La structure d’invite pour construire un studio 2.5D avec Claude Code

Une invite bien précise vaut mieux que cinq invites floues. Dans la documentation de référence, la spécification de construction tient en une seule invite. Voici une version qui en conserve le sens :

Build a 2.5D motion studio as one file, studio.html, with no dependencies.
- Scene: 6 layers (sky, moon, hills, city skyline, a title card "Ship it.",
  foreground foliage), each at its own z depth, using CSS perspective and preserve-3d.
- Camera: keyframes for x, y, z (dolly) and yaw (orbit around the card).
- Per-layer tracks: opacity, scale, y. Easings: linear, easeInOutCubic,
  easeInOutSine, easeOutBack.
- A timeline bar with keyframe markers, a playhead, click to scrub, space to play or pause.
- renderAt(t) must be pure in t. Expose window.__seek(t) that resolves after
  the frame paints, and a ?capture mode that hides the UI.
Then write export.mjs: Playwright opens ?capture, seeks every frame at 30 fps,
screenshots it and pipes PNGs to ffmpeg as H.264.

Cette invite se découpe en quatre couches : la scène, la caméra, les pistes avec leurs courbes d’interpolation (easings) et l’interface d’interaction, puis, pour finir, le contrat d’export. Ce sont les deux dernières lignes qui font toute la différence. Elles exigent que renderAt(t) soit une fonction pure de t, qu’on expose un __seek qui ne rend la main qu’une fois l’image dessinée, et qu’on prévoie un mode ?capture qui masque l’interface. L’export devient ainsi une contrainte d’architecture : l’agent conçoit son code en la respectant.

Si vous voulez réutiliser cette approche dans votre propre projet, prenez cette structure comme modèle. Décrivez d’abord clairement « ce qu’on dessine », puis fixez en deux ou trois lignes « comment on en extrait les images de façon déterministe ».

Analyse du code 2.5D généré par Claude Code

Le studio complet tient en 150 lignes environ. L’essentiel se joue dans les trois morceaux ci-dessous.

Échantillonnage des images clés et fonctions d’accélération

Chaque piste est un tableau d’images clés (keyframes) triées par temps. La fonction sample() commence par repérer les deux images clés qui encadrent t, puis calcule la progression avec la fonction d’accélération (easing) de la première des deux, et enfin interpole tous les champs numériques :

function sample(keys, t) {
  if (t <= keys[0].t) return keys[0];
  for (let i = 0; i < keys.length - 1; i++) {
    const a = keys[i], b = keys[i + 1];
    if (t <= b.t) {
      const p = (easings[a.ease] || easings.linear)((t - a.t) / (b.t - a.t));
      const out = {};
      for (const k in b)
        if (typeof b[k] === 'number' && k !== 't') out[k] = a[k] + (b[k] - a[k]) * p;
      return out;
    }
  }
  return keys[keys.length - 1];
}

Cette fonction ne lit pas l’heure courante, ne dépend pas de l’état de l’image précédente et n’utilise aucun nombre aléatoire. Pour un même t, elle renvoie toujours les mêmes valeurs : c’est de là que vient le caractère déterministe de renderAt(t).

Compensation de profondeur : la formule centrale de la parallaxe 2.5D

L’idée, c’est que la caméra reste immobile et que c’est le monde entier qui bouge en sens inverse. Chaque calque, en plus de sa translation sur l’axe z, reçoit une mise à l’échelle de compensation :

const PERSPECTIVE = 1200; // Doit correspondre à la perspective de #viewport
world.style.transform =
  `translate3d(${-cam.x}px, ${-cam.y}px, ${cam.z}px) rotateY(${-cam.yaw}deg)`;
const comp = 1 - L.z / PERSPECTIVE;
el.style.transform = `translate(-50%,-50%) ` +
  `translate3d(${x * comp}px, ${y * comp}px, ${L.z}px) scale(${comp * s})`;

Voici la démonstration. Avec une distance de perspective CSS p, un point situé à la profondeur z (z négatif signifie qu’il s’éloigne de l’observateur) est projeté à l’écran avec un facteur d’échelle de p / (p - z). Pour p = 1200 et z = -900, on obtient 1200 / 2100 ≈ 0.571 : le calque ne fait plus qu’environ 57 % de sa taille d’origine.

Pour annuler ce rétrécissement, on le multiplie par son inverse : (p - z) / p = 1 - z/p = 1 + 900/1200 = 1.75. C’est exactement la valeur de comp dans le code. Comme 0.571 × 1.75 = 1, quand la caméra est immobile, chaque calque apparaît à la taille et à la position que vous avez définies.

Alors, d’où vient la parallaxe ? Quand la caméra bouge, tout le world se translate du même dx, mais le déplacement de chaque calque à l’écran reste multiplié par son propre p/(p - z). Les calques lointains ont un coefficient faible, donc ils bougent peu ; les calques proches ont un coefficient élevé, donc ils bougent beaucoup. La compensation ne corrige que la composition à l’arrêt et n’affecte pas la différence de vitesse pendant le mouvement : c’est précisément ce qui fait fonctionner l’effet 2.5D.

(Les valeurs du tableau sont calculées avec p = 1200 ; les lignes -300 et -1800 sont des exemples dérivés.)

Un bug à retenir : on a compensé la taille, mais pas le décalage

Dans la première version du code, les calques étaient seulement multipliés par scale(comp), sans appliquer comp aux décalages x/y. Résultat : le décalage des collines lointaines était écrasé par la perspective, toute la composition se retrouvait de travers, et les collines montaient progressivement jusqu’à masquer environ deux tiers du ciel. La correction est toute simple : il faut aussi multiplier x et y par comp, car la perspective applique le même coefficient à la position et à la taille.

Ce qui est plus intéressant, c’est la façon dont le bug a été repéré. L’auteur l’a vu en regardant une seule image rendue, alors que la lecture du code ne l’avait pas révélé. Avant de faire confiance à un mouvement de caméra, demandez donc à l’agent de rendre trois images fixes : le début, le milieu et la fin.

Export MP4 déterministe image par image d’une animation à parallaxe 2.5D

Lecture en temps réel et export image par image : la différence de fond

L’aperçu en temps réel s’appuie sur requestAnimationFrame : dès que la machine est chargée, des images sautent. C’est acceptable pendant la prévisualisation, mais pas pour l’export, où aucune image ne doit manquer. Avec une capture d’écran vidéo, on enregistre « ce que l’écran affiche à l’instant T en temps réel » : à la moindre image de retard, on obtient une image dupliquée ou manquante.

Script d’export minimaliste

Le temps de l’exporteur est piloté par l’indice de la trame. Pour chaque trame, on fait d’abord un seek, on attend que le rendu soit terminé, on prend la capture, puis on écrit le PNG dans l’entrée standard de ffmpeg :

import { chromium } from 'playwright';
import { spawn } from 'node:child_process';
import { pathToFileURL } from 'node:url';

const out = process.argv[2] || 'out.mp4';
const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1280, height: 720 } });
await page.goto(pathToFileURL('studio.html').href + '?capture');

const { duration, fps } = await page.evaluate(() => window.__scene);
const ffmpeg = spawn('ffmpeg', ['-y', '-f', 'image2pipe', '-framerate', String(fps),
  '-i', '-', '-c:v', 'libx264', '-pix_fmt', 'yuv420p', '-crf', '18', out],
  { stdio: ['pipe', 'ignore', 'inherit'] });

const frames = Math.round(duration * fps);
for (let i = 0; i < frames; i++) {
  await page.evaluate(t => window.__seek(t), i / fps);
  ffmpeg.stdin.write(await page.screenshot({ type: 'png' }));
}
ffmpeg.stdin.end();
await new Promise(r => ffmpeg.on('close', r));
await browser.close();

Quelques détails à noter. window.__seek(t) ne se résout qu’après deux trames d’animation, ce qui garantit que la capture récupère bien le nouveau transform. image2pipe permet à ffmpeg de lire une séquence de PNG depuis stdin. yuv420p assure que le fichier généré se lit correctement dans un navigateur. Si Playwright n’a pas encore de navigateur installé, lancez d’abord npx playwright install chromium.

// Dans studio.html : seek déterministe, on ne retourne qu'après avoir dessiné deux trames
window.__seek = (t) => new Promise(resolve => {
  renderAt(t);                       // Fonction pure : ne dépend que de t
  requestAnimationFrame(() =>
    requestAnimationFrame(resolve)); // S'assurer que les styles sont appliqués et dessinés
});

// stills.mjs : génère trois images fixes (début / milieu / fin), on regarde d'abord les images avant de faire confiance au plan
import { chromium } from 'playwright';
import { pathToFileURL } from 'node:url';

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1280, height: 720 } });
await page.goto(pathToFileURL('studio.html').href + '?capture');
const { duration } = await page.evaluate(() => window.__scene);

for (const [name, t] of [['start', 0], ['mid', duration / 2], ['end', duration - 1e-3]]) {
  await page.evaluate(t => window.__seek(t), t);
  await page.screenshot({ path: `still-${name}.png` });
}
await browser.close();

Résultats mesurés par l’auteur : 180 trames, 1280×720, 30 fps, durée de 6,0 secondes, MP4 de sortie d’environ 420 Ko, pour un temps total d’environ 20 secondes. Dans l’image, les tours de la ville se déplacent moins que les collines sombres du premier plan, qui finissent par sortir complètement du cadre : c’est exactement l’effet de parallaxe.

Ajouter une fonction « décrire un plan » au studio 2.5D

On peut maintenant laisser le scénariste saisir une phrase décrivant un plan, et le modèle renvoie un JSON de keyframes. Dans la documentation de référence, on appelle directement l’API Anthropic Messages :

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2026-10-21" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 4096,
    "output_config": { "effort": "low" },
    "system": "Return only JSON: {\"camera\": [{\"t\",\"x\",\"y\",\"z\",\"yaw\",\"ease\"}], \"tracks\": {}}. Times in seconds, 0 to 6.",
    "messages": [{ "role": "user", "content": "Slow push-in, slight orbit right, title fades up in the first second." }]
  }'

Deux pièges à éviter ici. Premièrement, le paramètre effort doit se placer dans output_config.effort. Deuxièmement, Opus 5.5 utilise toujours la réflexion adaptative : passer thinking: {"type": "disabled"} renvoie une erreur 400, et les tokens de réflexion comptent aussi dans max_tokens. Si vous fixez max_tokens trop bas, le JSON sera tronqué au milieu du tableau, avec stop_reason égal à "max_tokens".

Une réponse tronquée, ou accompagnée de texte superflu, fera planter sample() au moment du rendu. Mieux vaut donc accompagner cet appel d’un test de contrat. La documentation de référence utilise Apidog CLI pour que la même session Claude Code crée et exécute le test, avec les assertions suivantes : code de statut 200, stop_reason différent de "max_tokens", texte renvoyé analysable comme du JSON, et valeurs de t dans le tableau camera croissantes de 0 à 6. Un autre outil de test d’API, ou un script d’assertions maison, fait aussi l’affaire. Relancez le test après chaque modification de l’invite système (system prompt) ou de effort, car les deux changent le contenu de la réponse.

Questions fréquentes (FAQ)

Points clés de l’animation de parallaxe 2.5D avec Claude Code

• L’export fait partie du design : dans les dernières lignes de l’invite, imposez une fonction pure renderAt(t) et un contrat de seek
• Formule de compensation de profondeur : comp = 1 − z/perspective, à appliquer à la taille ainsi qu’aux décalages x/y
• D’où vient la parallaxe : la compensation ne corrige que la composition statique ; en mouvement, chaque couche se déplace à une vitesse différente selon sa profondeur
• Regardez les images fixes avant de faire confiance au travelling : trois images (début, milieu, fin) révèlent des bugs que la lecture du code ne montre pas
• Pilotez le temps par numéro d’image : seek avec Playwright, capture d’écran, puis encodage H.264 via ffmpeg image2pipe
• Ajustez l’effort par étapes : high pour la première construction, medium pour les retouches, et démarrez à low pour une interface JSON structurée
• Ajoutez des tests de contrat sur la sortie du modèle : pour éviter qu’une troncature due à max_tokens fasse échouer l’analyse des images clés

Conclusion

Pour monter un studio d’animation de parallaxe 2.5D avec Claude Code, retenez trois points :

1. Architecture : un graphe de scène, une timeline et un moteur de rendu déterministe. C’est le troisième élément qui détermine la qualité du rendu final
2. Maths : le coefficient de compensation de perspective 1 - z/p s’applique à la fois à la taille et au décalage. À l’arrêt, la composition est exacte ; en mouvement, la parallaxe vient toute seule
3. Pipeline : seek image par image selon i/fps, capture d’écran, puis encodage avec ffmpeg. Le résultat ne dépend pas des performances de la machine

Je vous conseille de reproduire d’abord la structure d’invite de cet article pour générer un clip test de 6 secondes, et de prendre l’habitude de regarder trois images fixes avant de toucher à un mouvement de caméra. Ensuite, vous pourrez ajouter des couches, brancher une interface de « description de plan », ou transposer la même logique déterministe à d’autres solutions de vidéo programmatique comme Remotion.

📚 Références

1. How to Build a 2.5D Motion Studio With Opus 5.5 : source de la mise en pratique décrite dans cet article
2. Lien : apidog.com/blog/build-2-5d-motion-studio-opus-5-5

3. Description : contient l’invite complète, le code du studio, le script d’export et un exemple d’interface « décrire le plan »

4. Documentation Anthropic sur les modèles et le paramètre effort : positionnement du modèle, fenêtre de contexte, tarification et explications sur le paramètre effort

5. Lien : docs.anthropic.com

6. Description : pour vérifier l’identifiant du modèle claude-opus-5-5, l’en-tête de version de l’API et l’utilisation de output_config

7. Documentation ffmpeg sur les formats : présentation des formats d’entrée, dont image2pipe

8. Lien : ffmpeg.org/ffmpeg-formats.html

9. Description : pour comprendre la lecture d’une séquence PNG depuis stdin et les paramètres d’encodage H.264

10. Documentation Playwright : automatisation du navigateur et API de capture d’écran

11. Lien : playwright.dev
12. Description : page.evaluate, page.screenshot et la commande d’installation des navigateurs

Articles connexes

• Claude crée des vidéos sans modèle vidéo : 1 fonction temporelle + un rendu image par image en 4 étapes, tout le principe expliqué de bout en bout: Décryptage du fonctionnement complet de Claude pour créer des vidéos : chaque image est une fonction pure du temps seek(t), rendu image par image en quatre étapes avec un navigateur headless et ffmpeg, ressorts fermés et synchronisation au rythme pour des animations fluides, puis un guide de démarrage en 5 étapes à suivre.