Animer un hero en déconstruction avec Nano Banana, Kling 3 et canvas : le making of de moninspecteurenbatiment.ca

Un hero qui raconte une histoire en cinq secondes

Quand j'ai conçu le nouveau site de moninspecteurenbatiment.ca, je voulais un hero qui communique instantanément la promesse du service : regarder sous la peau d'une maison pour révéler ce que l'œil nu ne voit pas. Pas un carrousel d'images, pas une vidéo autoplay générique, pas un slider — quelque chose de cinématographique, contrôlable au pixel près, et qui fonctionne aussi bien sur un iPhone en 4G qu'en fibre sur un Retina 5K. Le résultat est une animation de maison isométrique qui se déconstruit en vue éclatée façon teardown Apple, rendue dans un canvas HTML avec 55 frames WebP précachées.

Ce qui est intéressant dans ce pipeline, c'est qu'il n'a nécessité ni After Effects, ni modélisation 3D Blender, ni motion designer externe. Juste trois outils : Nano Banana pour générer les deux images de référence, Kling 3 pour créer la transition morphing entre elles, et ffmpeg pour extraire les frames qui seront jouées dans un canvas. Coût total : environ 1,10 $ de crédits API et 45 minutes de travail. Voici comment j'ai construit cette animation, et pourquoi chacun de ces outils a été choisi pour une raison précise.

Pourquoi un canvas plutôt qu'une balise vidéo HTML5

La première question qu'on se pose, c'est pourquoi ne pas simplement utiliser une balise <video> avec un MP4. C'est plus simple à coder, c'est un standard connu, et les navigateurs modernes gèrent ça très bien. Mais j'ai trois raisons de préférer le rendu canvas frame par frame, et elles expliquent pourquoi ce pipeline vaut l'effort supplémentaire.

La première raison est le contrôle. Un canvas permet d'avancer image par image, de geler exactement sur la frame 42, de relancer l'animation au scroll, au clic, ou à l'apparition dans le viewport — et de synchroniser tout ça avec d'autres animations DOM comme l'apparition du titre ou des cartes de service. Une balise vidéo est beaucoup moins prévisible : l'autoplay est bloqué sur mobile sans mute, les seeks créent des saccades, et chaque navigateur interprète légèrement différemment les événements de lecture.

La deuxième raison est la performance. Contrairement à l'intuition, 55 fichiers WebP préchargés en parallèle se décodent plus vite qu'un MP4 unique qui doit buffer avant le premier frame. Chaque image est cacheable individuellement par le CDN, donc une seconde visite est instantanée. La troisième raison est la qualité : le WebP en mode lossless à 85 préserve les détails fins du diagramme technique (les lignes hairline, les étiquettes de composants), là où la compression H.264 d'un MP4 mangerait ces détails à moins de monter le bitrate à des niveaux irréalistes pour le web.

Étape 1 — Générer la maison assemblée avec Nano Banana

La première image établit la vue de référence : une maison colonial deux étages en projection isométrique stricte, sur fond blanc pur, sans ombres portées, sans ciel, sans environnement. C'est la frame de départ, celle que verra le visiteur quand la page se charge. Le choix de l'isométrique strict (30 degrés d'angle, 45 degrés d'élévation) n'est pas esthétique — c'est technique. Une perspective classique ne morpherait pas proprement vers la vue éclatée parce que les points de fuite déformeraient les composants pendant la transition.

Le prompt que j'ai utilisé décrit précisément les matériaux : stuc blanc et placage de pierre pour l'extérieur, bardeaux d'asphalte gris charbon pour le toit, cheminée en brique rouge à droite, porte d'entrée en bois brun avec portique blanc à colonnes. Chaque détail matériel est nommé explicitement, parce que ces mêmes détails devront apparaître dans l'image 2 (la vue éclatée) pour que Kling puisse créer un morphing cohérent. Le negative prompt est tout aussi important : pas d'herbe, pas de ciel, pas de voitures, pas de gens, pas d'ombres directionnelles. C'est ce qui garantit que la maison reste détourable sur fond blanc #FFFFFF pur, essentiel pour l'intégration canvas où le fond doit se fondre avec le background du hero.

L'éclairage est spécifié comme « flat even studio lighting » — un éclairage studio plat et homogène. Sans cette précision, Nano Banana ajoute souvent un éclairage directionnel qui crée des ombres portées, et ces ombres seraient impossibles à reproduire de manière cohérente dans la vue éclatée. La lumière constante entre les deux images est une condition non négociable pour un morphing propre.

Étape 2 — Générer la vue éclatée technique

La deuxième image est la plus délicate à obtenir, parce qu'elle doit être visuellement différente (tous les composants sont séparés et flottants) tout en partageant le maximum d'ADN visuel avec l'image 1. C'est cette tension entre variation et cohérence qui fait la qualité du morphing final.

Le prompt décrit une illustration isométrique technique éclatée de la même maison, avec la silhouette complète visible au centre comme un wireframe fantôme qui sert de point d'ancrage visuel. Tous les composants structurels et mécaniques sont extraits et flottent en explosion organisée autour de cette silhouette centrale. La référence visuelle que j'invoque dans le prompt est « Apple product teardown aesthetic meets architectural technical drawing » — l'esthétique des teardowns de produits Apple rencontre le dessin technique architectural. Ces références sémantiques sont les raccourcis les plus efficaces pour obtenir un style contrôlé avec un modèle de génération d'image.

Le color-coding par système est défini explicitement en hexadécimal dans le prompt : gris chaud pour la structure bois, orange profond pour les systèmes électriques, bleu acier pour la plomberie, vert sauge pour l'isolation, rouge doux pour le CVC. Sans ces codes exacts, le modèle improviserait et les couleurs ne tiendraient pas entre deux générations — impossible d'avoir une transition propre si les tuyaux de plomberie passent du bleu au turquoise entre l'image 1 et l'image 2. Les étiquettes hairline avec leader lines à 90 degrés et typographie sans-sérif géométrique complètent l'esthétique technique.

L'astuce qui fait marcher le morphing : l'ADN visuel partagé

Voici le principe le plus important de tout ce workflow, et celui que j'aurais aimé connaître avant de faire mes premières tentatives ratées : la qualité d'un morphing image-à-image dépend directement de la quantité d'ADN visuel partagé entre les deux frames sources.

Concrètement, ça veut dire que les descriptions matérielles de la maison doivent être rigoureusement identiques dans les deux prompts. Même bardeaux gris charbon, même brique rouge à droite, même portique blanc, mêmes proportions. Plus la maison « assemblée » et la maison « éclatée » partagent de caractéristiques visuelles (couleurs, matériaux, angle de vue, éclairage), plus Kling aura de points d'ancrage pour créer une transition fluide. Si les deux images sont trop différentes, le modèle de transition vidéo devra inventer des frames intermédiaires hallucinées, et le résultat sera une bouillie visuelle.

La règle pratique que j'utilise maintenant : je rédige d'abord la description commune de la maison dans un bloc de texte séparé, puis je copie ce bloc textuellement dans les deux prompts et j'ajoute seulement les variations spécifiques (assemblée vs éclatée). Cette discipline de copier-coller garantit qu'aucun détail matériel ne dérive entre les deux images.

Étape 3 — La transition vidéo avec Kling 3

Les deux images de Nano Banana sont importées dans Kling 3 comme start frame et end frame, puis on écrit le prompt qui décrit la manière dont la maison doit s'ouvrir. Le texte ne décrit plus quoi générer, il décrit une physique et un pacing. C'est une distinction importante : en mode text-to-video pur, Kling partirait dans n'importe quelle direction. En mode start-frame / end-frame, il est contraint par les deux images et n'a plus qu'à trouver le chemin entre les deux.

Le prompt que j'ai utilisé décrit une transition morphing continue : la surface de la maison commence à se dissoudre et à se séparer lentement, les panneaux de revêtement extérieur se décollent doucement et flottent vers l'extérieur, les bardeaux du toit se soulèvent et dérivent vers le haut en couches successives. Chaque pièce suit un arc courbe fluide jusqu'à sa position éclatée finale. Le mouvement doit ressentir comme un reveal de produit Apple premium — lent, délibéré, satisfaisant.

Les directives non négociables sont au nombre de trois. Première : caméra verrouillée, statique, aucun zoom, aucun dolly. Sans cette précision, Kling ajoute presque toujours un léger travelling qui casse l'effet de maquette technique. Deuxième : éclairage studio constant, aucune variation d'intensité ou de direction entre le début et la fin. Troisième : pacing « slow, deliberate, satisfying » — on vise un effet keynote Apple, pas un fast-forward TikTok. La référence au « Apple product reveal » dans le prompt est le shortcut sémantique le plus efficace pour obtenir une physique contrôlée avec des arcs de mouvement prévisibles.

Étape 4 — Extraire les frames avec ffmpeg

Le MP4 généré par Kling fait environ 5 secondes à 30 images par seconde, soit 150 frames. C'est trop pour un hero web : on veut 55 frames maximum pour garder le poids total sous 2 Mo. L'extraction se fait avec ffmpeg en deux passes. La première passe extrait toutes les frames en WebP avec une qualité de 85 et un niveau de compression de 6 — ces paramètres produisent des fichiers d'environ 28 à 32 Ko chacun, bien plus légers que le JPEG équivalent à qualité visuelle égale.

La seconde passe sous-échantillonne les frames pour ne garder qu'une image sur trois, ce qui nous amène à 50-55 frames totales. Cette réduction est imperceptible parce que le pacing de l'animation est lent (rappelez-vous, on a demandé à Kling un effet Apple délibéré), donc les variations entre frames adjacentes sont minimes. L'œil humain remplit automatiquement les vides grâce à la persistance rétinienne. À 55 frames jouées sur 3 secondes, on est à environ 18 fps — en dessous du seuil cinématographique traditionnel de 24 fps, mais parfaitement suffisant pour une animation stylisée où chaque frame est visuellement riche.

Le poids total final tourne autour de 1,6 Mo pour l'ensemble de la séquence. C'est moins qu'une seule photo haute résolution non optimisée, et c'est distribué sur 55 fichiers individuels que le CDN peut cacher et servir en parallèle. Chaque frame est atomique : si une seule est corrompue dans le cache, les 54 autres restent valides.

Étape 5 — Intégration canvas et triggers d'animation

Côté code, l'intégration est étonnamment simple une fois les frames en place. Trois étapes : précharger les 55 frames en parallèle dès que le composant hero monte dans le DOM, rendre chaque frame dans un canvas dont les dimensions correspondent à celles de l'image source, et avancer l'index de frame selon le trigger choisi — scroll-driven, time-based ou event-based.

Le préchargement utilise un Promise.all qui crée 55 objets Image et attend que tous soient chargés avant de démarrer l'animation. Sur une connexion 4G, ce préchargement prend environ 600 ms pour les 1,6 Mo totaux — moins que le temps d'apparition du titre hero avec son animation d'entrée, donc l'utilisateur ne perçoit aucun délai. Un IntersectionObserver surveille le canvas et démarre l'animation uniquement quand l'élément entre dans le viewport, ce qui évite de consommer des ressources CPU pour une animation hors écran.

Le rendu de chaque frame est une simple méthode drawImage sur le contexte 2D du canvas, précédée d'un clearRect pour effacer la frame précédente. L'avancement de l'index peut être piloté par requestAnimationFrame avec un easing cubic-bezier pour reproduire le pacing Apple, ou directement lié à scrollY pour un effet de scroll-driven storytelling où l'utilisateur contrôle la déconstruction en faisant défiler la page. Sur moninspecteurenbatiment.ca, j'ai choisi le mode time-based avec un cubic-bezier (0.22, 1, 0.36, 1) — un easing qui démarre vite et ralentit en fin de course, parfait pour un effet reveal cinématographique.

Coût, temps de production et reproductibilité

Le bilan économique de ce pipeline est ce qui le rend vraiment intéressant. Image 1 sur Nano Banana : 2 minutes, environ 5 cents. Image 2 sur Nano Banana : 3 minutes avec une itération, environ 5 cents. Vidéo morphing sur Kling 3 : 8 minutes de génération pour obtenir une version satisfaisante, environ 1 dollar de crédits. Extraction frames avec ffmpeg local : 1 minute, gratuit. Intégration canvas dans le code : 30 minutes. Total : environ 45 minutes de travail et 1,10 $ de coûts API.

À titre de comparaison, une animation équivalente en motion design traditionnel (modélisation 3D de la maison dans Blender ou Cinema 4D, rigging des composants, animation image-par-image des trajectoires, rendu, compositing) prendrait facilement deux à trois jours de travail pour un motion designer expérimenté, soit plusieurs milliers de dollars de budget. Le ratio coût/temps de ce nouveau pipeline est de l'ordre de 1 à 100.

Le workflow est aussi hautement reproductible pour d'autres sujets. Pour en faire une version produit (par exemple un ordinateur qui se démonte, une machine industrielle qui s'ouvre, un moteur qui se désassemble), les règles restent identiques : deux images avec projection isométrique stricte et fond blanc, descriptions matérielles rigoureusement partagées entre les deux prompts, color-coding défini en hexadécimal pour les composants de la vue éclatée, et consigne Kling « caméra verrouillée + lumière constante + pacing Apple ». Le reste est juste une question de frames et de triggers canvas.

Ce que cette technique dit de l'avenir du motion design

Ce qui m'impressionne le plus dans ce pipeline, ce n'est pas qu'il produit un résultat techniquement correct — c'est qu'il produit un résultat qui aurait été considéré comme premium il y a deux ans, pour une fraction du coût et du temps. La combinaison de trois outils spécialisés (Nano Banana pour les images de référence, Kling pour la transition morphologique, canvas pour le rendu performant) dépasse ce qu'on peut obtenir avec n'importe quel outil unique, même le meilleur modèle text-to-video actuel.

La leçon plus large pour les designers et développeurs qui intègrent l'IA dans leur workflow, c'est que les meilleurs résultats viennent rarement d'un seul modèle qui fait tout. Ils viennent de l'orchestration de plusieurs modèles spécialisés, chacun utilisé pour ce qu'il fait le mieux, avec des étapes de traitement classique (ffmpeg, canvas, code) qui structurent le pipeline. L'IA générative n'est pas une fin en soi — c'est une brique dans un workflow qui inclut toujours des décisions humaines sur l'esthétique, la physique, le pacing et l'intégration technique.

Si tu veux voir l'animation en contexte, elle est en ligne sur la page hero du site moninspecteurenbatiment.ca et l'étude de cas complète du projet est disponible dans mon portfolio à /portfolio/moninspecteur-en-batiment. Et si tu cherches à intégrer ce type d'animation cinématographique dans ton propre site ou application, c'est exactement le genre de pipeline que j'accompagne chez PASCALPOTVIN.COM : marier la génération IA et le code performant pour produire des expériences web qui sortent du moule.