Créer des animations de morphing UI avec l’IA
Un bouton devient un indicateur de chargement, se transforme en coche de confirmation, puis s’ouvre sur un graphique. Le spectateur suit un seul objet tout au long de la séquence. C’est le principe de ce tutoriel d’animation de morphing UI : montrer une interaction produit courte sans couper entre des écrans distincts.
Nous avons construit l’exemple dans iArt en utilisant Haiku 5.5, puis l’avons révisé deux fois. La première version rognait les étiquettes du graphique. La suivante corrigeait la mise en page mais semblait lente. L’animation finale dure huit secondes, avec des transitions plus rapides et un graphique lisible pendant la pause.
Ce pas-à-pas inclut les prompts utilisés, les problèmes rencontrés et les ajustements de timing qui ont rendu le résultat plus pertinent. Pulse, l’application d’analytique de l’exemple, est fictive ; les chiffres d’inscription sont des données d’exemple.
Ce que vous allez réaliser
L’animation suit une interaction courte : Voir le rapport → chargement → succès → Inscriptions hebdomadaires → Voir le rapport. Le conteneur central change ses dimensions, son rayon de coin et sa couleur. Son contenu évolue à chaque état pertinent.
Ce format peut illustrer un chargement de rapport, une confirmation de paiement ou une fonctionnalité produit dans une vidéo de lancement. Le résultat est une démonstration vidéo, pas une interface fonctionnelle ni un composant UI installable. Pour ce test, nous avons utilisé le mode Animation, un canevas 16:9 et l’option Haiku 5.5 affichée dans iArt le 22 octobre 2026. Nous n’avons demandé ni narration, ni musique, ni séquences générées.
Préparez trois éléments avant de commencer : les états à montrer, le texte et les données exacts, et une direction visuelle simple. Notre brief utilisait un fond blanc cassé, une UI sombre et une couleur d’accent. Les valeurs du graphique étaient 24, 38, 31, 52, 46, 68 et 84, étiquetées de lundi à dimanche.
1. Décrivez l’objet qui reste continu
Ouvrez iArt en mode Animation et choisissez votre modèle. Nous avons utilisé Haiku 5.5 tout au long de cet exemple. Nous n’avons pas comparé avec d’autres modèles ni mesuré le coût facturé de la génération.
L’élément clé du prompt est la relation entre les états : le même conteneur change de forme. Demander une scène de bouton suivie d’une scène de graphique peut produire une coupure ou un fondu croisé à la place. Indiquez au modèle quel objet persiste, ce qui change à l’intérieur et quand le spectateur doit pouvoir lire.
Voici une traduction du prompt original testé en anglais. Elle conserve le brief de quinze secondes pour permettre de suivre les révisions ci-dessous.
Créez une animation de morphing UI fluide de 15 secondes pour une application d’analytique fictive appelée Pulse, format 16:9. Un conteneur central sombre et arrondi change continuellement de forme : 0–3s un bouton intitulé « Voir le rapport » avec un clic de curseur ; 3–5s le MÊME conteneur rétrécit en un indicateur de chargement circulaire ; 5–7s il devient une coche verte de succès ; 7–12s il s’étend en une carte analytique épurée intitulée « Inscriptions hebdomadaires », avec sept barres étiquetées Lun–Dim et valeurs 24, 38, 31, 52, 46, 68, 84 ; 12–15s il revient en douceur au bouton d’origine, avec des premières et dernières images identiques. Fond blanc cassé chaleureux, UI quasi-noire, accent émeraude, typographie nette, mouvement à ressort sobre. Le morphing doit être visiblement continu, pas des scènes séparées en fondu croisé. Gardez toutes les étiquettes lisibles, pas de chevauchement de texte, pas de rognage. Pas de voix off, musique, images ou vidéos générées. Réalisez directement l’animation.
iArt a produit un aperçu avec les états demandés. Cela a fourni un point de départ utile, mais l’instruction « pas de rognage » n’a pas garanti une mise en page correcte.
2. Inspectez le graphique avant de juger l’animation
Vers dix secondes, le premier aperçu rognait le graphique sur son bord inférieur. Les étiquettes des jours de la semaine n’étaient pas visibles. La transition de forme existait, mais le résultat ne communiquait pas correctement les données.
Lors de la vérification d’un graphique généré, comparez chaque valeur au brief et vérifiez que les étiquettes ne sortent pas du conteneur. Contrôlez à la fois le graphique stable et les images où il s’agrandit ou rétrécit. Une mise en page correcte en taille finale peut tout de même être rognée pendant une transition.
Voici une traduction de notre première révision : elle identifiait le problème visible, conservait les données et demandait un changement de couleur.
L’aperçu à 10 secondes présente un vrai bug de mise en page : le bas du graphique est rogné et les étiquettes des jours Lun–Dim ne sont pas visibles. Corrigez la mise en page du graphique pour que les sept valeurs ET les sept étiquettes de jours soient entièrement à l’intérieur de la carte avec au moins 24px de marge inférieure, pendant toute la pause graphique de 8 à 12 secondes. Supprimez aussi la pause de carte vide avant le retour : gardez le contenu du graphique visible jusqu’au début du morphing, puis faites-le disparaître pendant le rétrécissement sans rognage. Gardez le même design, les mêmes données, la durée de 15 secondes et des premières/dernières images identiques. Changez l’accent d’émeraude à violet #7C3AED pour que je puisse vérifier l’édition du chat aussi. Pas d’audio ni de média généré. Inspectez les images à 9, 10, 11, 12, 13 secondes avant de finaliser.

L’aperçu révisé montrait bien les sept valeurs et étiquettes, y compris le 84 du dimanche. Le changement de couleur était aussi visible. Nous pouvions alors évaluer le rythme sans défaut de mise en page. Pour d’autres exemples axés sur les graphiques, voir graphiques animés dans iArt.
3. Raccourcissez les transitions, pas le temps de lecture
Le retour suivant était simple : les transitions semblaient trop lentes. Le brief initial allouait plusieurs secondes aux premiers états bouton, chargement et confirmation. Le résultat mettait trop de temps à afficher l’information.
Nous avons réduit la durée de la scène de quinze à huit secondes. Plus important, nous avons attribué des rôles différents à chaque partie de la séquence : les transitions sont rapides, tandis que le graphique final reste affiché assez longtemps pour être lu.
| Temps dans le brief révisé | Action | But |
|---|---|---|
| 0–0,55 seconde | Bouton et arrivée du curseur | Installer l’action sans longue attente initiale. |
| 0,55–0,90 seconde | Le bouton se rétrécit en loader | Réagir immédiatement au clic. |
| 0,90–2,05 secondes | Chargement puis confirmation | Rendre les changements d’état reconnaissables mais brefs. |
| 2,05–3,20 secondes | Le conteneur s’agrandit ; barres et étiquettes entrent | Révéler le résultat en un mouvement continu. |
| 3,20–6,65 secondes | Le graphique complet reste affiché | Laisser le temps de comparer les sept valeurs. |
| 6,65–8 secondes | Retour au bouton et stabilisation | Clore la séquence sans longue pause de carte vide. |
Ces timings sont le brief de cette petite démo, pas des règles universelles d’animation UI. Une interface plus grande ou un graphique complexe peut nécessiter plus de temps de lecture.
Voici une traduction de la révision du timing envoyée au même projet :
Le retour utilisateur est que les transitions semblent lentes et déconnectées. Passage timing : raccourcissez toute l’animation à 8 secondes et changez réellement la durée des scènes (pas la vitesse du lecteur). Gardez le design violet, les données exactes du graphique et la mise en page corrigée et lisible. Planning : 0–0,55s bouton au repos et arrivée rapide du curseur ; clic à 0,55s, morphing immédiat du bouton en loader pendant 0,55–0,90s ; spinner 0,90–1,45s ; morphing en coche de succès 1,45–1,70s, maintien jusqu’à 2,05s ; expansion du même conteneur en graphique 2,05–2,50s ; toutes les barres et étiquettes terminent leur entrée à 3,20s, avec un décalage de 40ms et une montée de 300ms ; maintien du graphique complet lisible 3,20–6,65s ; rétrécissement en bouton 6,65–7,15s avec mise à l’échelle/fondu du contenu pendant le morphing, restauration du texte bouton à 7,15s ; repos 7,15–8s et image initiale identique. Les transitions de forme doivent durer 250–450ms avec easing cubic out et stabilisation sobre, pas de longue interpolation linéaire, pas de pause de carte vide, pas de fondu répété vers blanc entre les états. Le curseur doit cliquer visiblement et déclencher immédiatement le morphing. Toujours pas d’audio/média. Vérifiez la durée et les images à 0, 0,75, 1,2, 1,9, 2,3, 3,3, 6,8, 7,3, final ; vérifiez explicitement l’absence de rognage ou de coupure.
Le lecteur mis à jour affichait une durée de huit secondes à vitesse normale. Nous avons vérifié le loader près d’une seconde et le graphique complet autour de trois secondes. Les sept valeurs et étiquettes restaient lisibles.
L’easing et la durée traitent des aspects différents. La durée contrôle combien de temps dure le mouvement ; l’easing contrôle la progression à l’intérieur de ce temps. Pour comprendre la mise en œuvre, la documentation sur l’interpolation de Remotion explique le mapping des plages d’images aux valeurs visuelles, et sa référence easing documente les fonctions linéaires, cubiques et ease-out. Vous pouvez décrire le timing voulu dans le chat sans écrire ces fonctions vous-même.
4. Vérifiez le résultat à vitesse normale
Une capture d’écran peut confirmer la lisibilité du texte. Elle ne garantit pas que le mouvement est fluide. Rejouez la séquence en 1× et vérifiez le moment du clic, la transition loader-vers-coche, l’expansion de la carte et le retour au bouton.
- Action et réaction : la forme commence-t-elle à changer au clic du curseur ?
- Continuité : pouvez-vous suivre le conteneur entre les états, ou disparaît-il puis est-il remplacé ?
- Lecture : toutes les valeurs sont-elles entrées avant la pause graphique ?
- Retour : le contenu part-il avec la carte qui rétrécit, sans pause vide visible ?
- Boucle : comparez la fin au début, y compris le curseur et le texte. Demander des images identiques ne prouve pas que la boucle est parfaite.
Notre aperçu final est une démonstration UI basique et exploitable. Ce n’est pas une preuve que chaque prompt produira une animation polie du premier coup. La révision du timing a aussi nécessité une réparation automatique avant d’obtenir un aperçu fonctionnel. Nous n’avons pas mesuré image par image la fluidité ni vérifié indépendamment la boucle finale exacte.
5. Exportez la version réellement relue
Une fois l’aperçu prêt, ouvrez Exporter et choisissez une résolution. Si vous modifiez l’animation ensuite, exportez la version mise à jour plutôt que d’utiliser un rendu antérieur.
Nous avons exporté la version finale de huit secondes en 720p et l’avons intégrée en haut de cet article. La version web utilise une vidéo H.264 en 1280 × 720 à 30 fps, sans piste audio. Relisez le fichier exporté ainsi que l’aperçu éditeur avant de le partager.
Pour adapter l’exercice, remplacez le nom de l’application, les étiquettes et les chiffres par les vôtres, en gardant la séquence d’états courte. Pour une histoire produit plus longue, poursuivez avec notre guide pour réaliser une vidéo de lancement produit.
Créez votre propre animation UI dans iArt
FAQ
Dois-je écrire du code pour réaliser cette animation ?
Nous avons créé et révisé cet exemple via l’interface chat d’iArt. Nous n’avons pas édité manuellement le code d’animation généré. Le travail utile consistait à spécifier les états, vérifier l’aperçu et décrire des corrections concrètes.
Quel modèle avez-vous testé ?
Nous avons utilisé l’option Haiku 5.5 affichée dans iArt le 22 octobre 2026, pour la première génération et les deux révisions. Il s’agissait d’un seul projet, pas d’une comparaison ou d’un benchmark de fiabilité entre modèles.
Pourquoi la première version semblait-elle lente ?
Le brief de quinze secondes donnait trop de temps aux premiers états et transitions pour cette interaction simple. Nous avons réduit la durée totale à huit secondes, raccourci les changements de forme et gardé un peu plus de trois secondes pour lire le graphique final.
Est-ce que cela crée une vraie interface produit interactive ?
Non. Cet exemple crée une vidéo animée d’une interface. Le bouton, le curseur et le graphique illustrent un parcours produit ; ce ne sont ni un tableau de bord fonctionnel ni un composant UI déployable.
Puis-je réutiliser le prompt avec d’autres données ?
Oui. Remplacez les étiquettes et valeurs d’exemple, puis vérifiez à nouveau le résultat. Des étiquettes plus longues, des chiffres plus grands ou des barres supplémentaires peuvent nécessiter une autre mise en page de carte et plus de temps de lecture.