Micro-interactions et animations UI : comment donner du mouvement à une interface sans en faire trop ?

Je clique sur un bouton. Il réagit immédiatement.

J’ouvre un accordéon. Le contenu se déploie sans faire sauter brutalement toute la page.

Je passe une tâche en « Terminée ». Son état change, puis elle rejoint la bonne liste.

Dans ces trois cas, l’animation dure peu de temps. Elle n’est pas là pour attirer l’attention sur elle-même. Elle m’aide à comprendre ce qui vient de se passer.

C’est généralement ce que je recherche lorsque je travaille le mouvement dans une interface.

Les problèmes commencent lorsqu’on anime parce qu’il « manque quelque chose » à la maquette. Les titres apparaissent au scroll, les cartes montent depuis le bas, les images zooment, les boutons rebondissent et les fonds se déplacent. Au bout de quelques écrans, l’utilisateur attend parfois que la page finisse de s’animer avant de pouvoir simplement la lire.

Je garde une animation lorsqu’elle explique une action, un changement d’état ou une relation entre deux éléments. Sinon, elle doit avoir une très bonne raison de rester.

Micro-interaction, transition et animation

Les trois notions sont proches, mais je ne les utilise pas exactement de la même manière.

Une micro-interaction commence généralement par une action ou un changement précis : ajouter un favori, activer une option, envoyer un formulaire, déplacer une carte.

La transition décrit le passage entre deux états.

L’animation est le mouvement utilisé pour rendre ce passage visible.

Prenons une icône de favori. Je clique dessus. Le cœur se remplit et change légèrement d’échelle. La micro-interaction correspond à tout l’échange. Le passage du cœur vide au cœur plein est le changement d’état. Le mouvement entre les deux constitue l’animation.

Cette distinction évite de réfléchir uniquement en termes d’effets graphiques. Ce qui m’intéresse d’abord est l’information donnée à l’utilisateur.

Partir de ce que le mouvement doit expliquer

Quand je prototype, je me pose une question avant de régler la durée ou l’easing :

« Qu’est-ce que la personne doit comprendre grâce à ce mouvement ? »

La réponse peut être très concrète.

Le clic a bien été pris en compte.

Ce panneau appartient à la page que je consulte et vient se superposer dessus.

Cette donnée est encore en cours de chargement.

L’élément que je viens de déplacer n’a pas disparu : il a changé de liste.

Les recommandations d’Apple sur le motion vont dans ce sens : le mouvement doit aider à comprendre l’interface, conserver une continuité et éviter d’interférer avec l’action.

Voir : Apple Human Interface Guidelines – Motion.

Une animation décorative peut exister. Je la traite simplement différemment. Elle n’a pas la priorité sur un feedback ou une information fonctionnelle.

Réagir immédiatement après une action

Un utilisateur clique sur « Envoyer » et rien ne change.

Il peut penser que le bouton n’a pas fonctionné et cliquer une deuxième fois.

Le retour n’a pas besoin d’être spectaculaire. Le bouton peut passer à « Envoi… », afficher un petit indicateur ou simplement modifier son état visuel pendant que la requête part.

Une fois le traitement terminé, l’interface confirme le résultat :

Votre demande a bien été envoyée.

Le mouvement n’est qu’une partie de cette réponse. La microcopy indique ce qui s’est réellement passé.

Je préfère cette combinaison à une animation seule. Une coche verte qui apparaît pendant 300 millisecondes ne remplace pas toujours un message compréhensible.

Montrer un changement d’état

Le mouvement fonctionne bien lorsque le même objet passe d’un état à un autre.

Un interrupteur est un bon exemple.

Le curseur se déplace de gauche à droite et la couleur change. La personne voit la continuité entre « désactivé » et « activé ».

Une flèche qui tourne lorsqu’un accordéon s’ouvre joue un rôle comparable.

Je veille cependant à ce que l’état final reste compréhensible sans avoir assisté à l’animation.

Si j’arrive sur l’écran après la transition, je dois encore pouvoir voir si l’option est activée.

Le mouvement accompagne donc la différence entre les états. Il ne doit pas être le seul moyen de la percevoir.

Aider à comprendre d’où vient un élément

Le mouvement peut créer une logique spatiale.

Un panneau de filtres arrive depuis la droite. Lorsqu’il est refermé, il repart dans la même direction.

Un menu mobile descend depuis le header au lieu d’apparaître sans relation visuelle avec le bouton qui l’a ouvert.

Une galerie glisse horizontalement parce que les images sont perçues comme une série.

Ces mouvements indiquent comment les éléments sont reliés.

Je trouve les interfaces plus difficiles à suivre lorsqu’un composant entre depuis la droite, se referme vers le bas et réapparaît ensuite avec un fondu. La direction change sans que la structure ait changé.

La cohérence spatiale est souvent plus importante que la sophistication de l’effet.

Boutons : hover, pressed et focus n’ont pas le même rôle

Un bouton n’a pas besoin de rester parfaitement statique.

Sur desktop, le hover peut signaler que le pointeur se trouve sur une zone interactive. Au clic, un état pressed confirme l’appui.

Le focus clavier répond à un autre besoin : montrer quel composant est actuellement sélectionné lors d’une navigation sans souris.

Je ne confonds donc pas forcément focus et hover.

Un effet de hover peut être discret. Le focus doit rester suffisamment visible pour être identifié rapidement.

J’évite également les transformations importantes de taille. Un bouton qui grossit fortement au passage de la souris peut déplacer visuellement les éléments voisins ou donner une interface instable.

Ces états devraient être prévus directement dans le design system ou le UI kit.

Accordéons, menus et panneaux qui s’ouvrent

Un accordéon ouvert instantanément peut déplacer brutalement plusieurs centaines de pixels de contenu.

Une transition courte facilite le suivi.

Je ne cherche pas pour autant à rendre l’ouverture « spectaculaire ».

Sur une FAQ, une animation de 700 ou 800 millisecondes paraît vite lente lorsqu’on ouvre plusieurs réponses à la suite.

Le même principe vaut pour les menus déroulants.

Quelques dizaines ou centaines de millisecondes peuvent suffire pour donner une continuité. L’accès aux liens ne devrait pas être retardé par une entrée complexe.

Pour les panneaux latéraux ou les modales, une transition discrète permet aussi de conserver le contexte de la page située derrière.

Dans un formulaire, l’erreur n’a pas besoin de trembler

Le champ qui secoue horizontalement lorsqu’une valeur est incorrecte est devenu un effet assez courant.

Je l’utilise rarement.

Il attire l’attention, mais ne dit pas ce qui doit être corrigé.

Je préfère un état stable : une indication visuelle, un message relié au champ et une formulation suffisamment précise.

Par exemple :

Saisissez une adresse e-mail au format Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser..

Une légère apparition du message peut accompagner le changement. Je ne fais pas dépendre la compréhension de l’animation.

Kim détaille ces situations dans ses articles sur les formulaires UX et la microcopy.

Montrer qu’une action est en cours

Le chargement mérite une réponse différente selon sa durée et ce qui est attendu.

Pour un envoi très court, modifier le bouton peut suffire :

Envoi…

Pour une liste dont plusieurs blocs doivent être chargés, un skeleton peut déjà montrer la future structure.

Pour un export qui dure davantage, je peux utiliser un indicateur de progression si le système connaît réellement son avancement.

Je me méfie des faux pourcentages.

Une barre qui monte rapidement à 90 %, reste figée pendant trente secondes puis termine soudainement donne peu d’informations sur le temps restant.

Si l’avancement réel n’est pas calculable, un indicateur indéterminé est plus honnête.

Je n’ajoute pas non plus un délai artificiel uniquement pour laisser une animation se terminer. Une action qui peut être immédiate doit rester immédiate.

Animations au scroll : le contenu ne devrait pas attendre l’effet

Faire apparaître une image lorsqu’elle entre dans la fenêtre peut donner un rythme agréable.

Faire attendre chaque paragraphe est une autre histoire.

Je rencontre régulièrement des pages où le lecteur arrive sur une zone blanche, continue légèrement à descendre, puis le texte apparaît avec un fondu et une translation.

La lecture est devenue dépendante de l’animation.

Je préfère garder les informations importantes disponibles immédiatement et sélectionner quelques moments visuels à animer.

Une grande statistique, une illustration ou une transition entre deux parties peuvent recevoir un traitement particulier.

Le texte courant n’a pas besoin d’entrer en scène à chaque section.

Le parallaxe mérite d’être utilisé avec parcimonie

Le parallaxe fait défiler plusieurs couches à des vitesses différentes. L’effet de profondeur peut être intéressant sur une page très visuelle.

Il devient beaucoup moins pertinent sur une page où l’objectif principal est de lire, comparer ou remplir un formulaire.

Le mouvement est important et peut aussi gêner les personnes sensibles aux animations vestibulaires.

Le W3C cite les mouvements importants et certains effets de parallaxe parmi les situations à prendre en compte dans son explication du critère « Animation from Interactions ».

Voir : W3C – Animation from Interactions.

Je préfère que la composition de la page fonctionne déjà sans cet effet.

Créer une continuité entre deux écrans

Les transitions deviennent intéressantes lorsqu’un élément existe avant et après le changement.

Je clique sur une miniature dans une galerie. Elle s’agrandit jusqu’à devenir l’image principale.

Je comprends que je regarde toujours le même objet.

Figma permet de simuler ce type de comportement avec Smart Animate lorsque des calques correspondants existent dans plusieurs frames.

Voir : Figma – Smart Animate.

Je ne cherche pas à appliquer cette logique à chaque changement de page.

Une transition est plus utile lorsqu’elle explique une continuité. Faire tourner toute l’interface à chaque clic crée surtout de l’attente.

Choisir une durée adaptée à la fréquence d’usage

Je n’utilise pas une durée unique pour toutes les animations.

Un feedback de bouton peut être extrêmement bref.

Un panneau qui traverse une partie de l’écran a besoin d’un peu plus de temps pour que son mouvement reste perceptible.

Je regarde surtout la fréquence.

Une animation de 500 millisecondes sur une interaction utilisée deux fois pendant une visite peut passer inaperçue.

La même animation sur un composant manipulé cinquante fois par jour devient lente.

Je teste donc plusieurs utilisations à la suite.

Si j’ai envie de cliquer plus vite que le composant ne me le permet, je réduis généralement la durée.

Courbes et springs : le mouvement a aussi un ton

Une animation linéaire avance à vitesse constante. Selon le contexte, elle peut paraître assez mécanique.

L’easing modifie l’accélération et le ralentissement du mouvement.

Figma permet aussi de créer des springs, avec un mouvement qui peut dépasser légèrement sa position finale avant de se stabiliser.

Voir : Figma – Easing and spring animations.

Le spring peut donner un caractère plus souple ou plus ludique.

Je ne le mets pas partout pour autant.

Un petit rebond sur une réaction ponctuelle peut fonctionner. Un menu, un accordéon, une modal et chaque bouton qui rebondissent produisent vite une interface agitée.

Les courbes font partie du langage visuel au même titre que les rayons ou les couleurs. Je cherche donc une certaine cohérence.

Sur mobile, le geste donne déjà une direction

Sur un écran tactile, le mouvement peut prolonger directement le geste.

Je glisse une galerie vers la gauche. Le contenu suivant arrive depuis la droite.

Je tire un panneau vers le bas pour le fermer. Il suit mon doigt dans cette direction.

Lorsque l’animation part dans le sens opposé sans justification, le comportement paraît moins naturel.

Les distances doivent aussi être revues.

Une translation de 300 pixels est relativement modeste sur un grand écran. Sur un smartphone, elle peut représenter presque toute la largeur.

La version mobile ne récupère donc pas automatiquement tous les mouvements de la maquette desktop.

C’est la même logique que pour les autres adaptations traitées dans l’article sur l’UX mobile.

Prévoir une interface avec moins de mouvement

Les mouvements importants peuvent provoquer un inconfort chez certaines personnes souffrant de troubles vestibulaires : vertiges, nausées ou migraines.

Les zooms, déplacements de grande amplitude et parallaxes demandent une attention particulière.

WCAG 2.2 comporte le critère 2.3.3 « Animation from Interactions », de niveau AAA. Lorsque l’animation de mouvement est déclenchée par une interaction, elle doit pouvoir être désactivée si elle n’est pas essentielle à la fonction ou à l’information.

Voir : W3C – Understanding Animation from Interactions.

Sur le web, la media query prefers-reduced-motion permet de détecter une préférence système demandant moins d’animations.

Voir : MDN – prefers-reduced-motion.

Je ne supprime pas nécessairement tout mouvement.

Un déplacement important peut par exemple devenir un fondu court. L’état reste compréhensible, sans imposer le même mouvement.

Je veille également à ce que l’information finale existe indépendamment de l’animation.

Une animation fluide dans Figma peut être mauvaise dans le navigateur

Le prototype ne montre pas toujours le coût réel d’un effet.

Une animation peut être parfaitement fluide dans Figma et provoquer des saccades lorsqu’elle est appliquée à de nombreux éléments dans une page chargée.

web.dev recommande de privilégier transform et opacity pour beaucoup d’animations courantes lorsque ces propriétés permettent d’obtenir le résultat recherché. Elles évitent généralement certains recalculs de mise en page plus coûteux.

Voir : web.dev – How to create high-performance CSS animations.

Je n’ai pas besoin de décider seule de l’implémentation CSS. En revanche, lorsqu’une direction artistique repose sur dix éléments animés simultanément pendant le scroll, je préfère en parler avant la fin de la maquette.

Documenter le mouvement dans le design system

Sans règles communes, chaque composant peut finir avec sa propre vitesse et sa propre personnalité.

Un menu s’ouvre lentement. Une modal rebondit. Un accordéon disparaît instantanément. Un bouton utilise encore une autre courbe.

Je peux éviter cette dispersion avec quelques catégories simples.

Type de mouvement	Exemples	Principe
Feedback local	Bouton, toggle, sélection	Réponse très rapide
Ouverture	Menu, accordéon, panneau	Transition courte liée à l’origine du composant
Changement d’écran	Galerie, détail d’un élément	Conserver la continuité lorsqu’elle apporte une information
Mouvement éditorial	Hero, illustration, campagne	Utilisation ponctuelle, sans bloquer le contenu

Je peux ensuite associer quelques durées et easings à ces familles.

Le but n’est pas d’imposer la même animation partout. Il est d’éviter que chaque prototype invente un nouveau langage.

Ce travail prolonge directement l’article consacré au design system et au UI kit.

Ce que je teste dans Figma

Figma permet de simuler plusieurs types de transitions : dissolve, slide, push, move ou Smart Animate.

Voir : Figma – Prototype animations.

Je m’en sers surtout pour vérifier le comportement, pas pour produire une démonstration spectaculaire.

J’ouvre le même panneau plusieurs fois.

Je teste le parcours assez vite, sans attendre volontairement l’animation.

Je regarde si je comprends toujours où je suis lorsque la transition se termine.

Je vérifie aussi l’état sans animation. Si le composant devient incompréhensible lorsqu’il est figé, il manque probablement une information dans son design.

Exemple : ajout au panier

L’utilisateur clique sur « Ajouter au panier ».

Je peux faire voler pendant deux secondes une miniature du produit jusqu’à l’icône du panier.

Visuellement, l’effet est compréhensible. Il est aussi assez long pour une action fréquente.

Je préfère généralement :

le bouton réagit immédiatement ;

le compteur du panier passe de 1 à 2 ;

un panneau court confirme « Produit ajouté au panier ».

Ce panneau peut proposer « Voir le panier » et « Continuer mes achats ».

L’utilisateur obtient trois informations : le clic a fonctionné, le panier contient désormais un produit supplémentaire et il peut choisir la suite.

Il n’a pas dû attendre une animation pour continuer.

Exemple : changement d’état dans un SaaS

Une tâche passe de « À faire » à « Terminée ».

Je peux d’abord faire changer l’état de la checkbox.

La ligne reçoit ensuite son apparence « terminée », puis rejoint éventuellement la section correspondante.

L’ordre compte.

Si la tâche disparaît instantanément de l’écran avant que l’utilisateur ait pu voir la confirmation, il peut se demander ce qui vient de se passer.

À l’inverse, je n’ai pas besoin d’afficher une notification, une animation de confettis, une barre de progression et un compteur animé pour une action aussi simple.

Le feedback doit rester proportionné à l’événement.

Exemple : une page éditoriale

Une page de marque laisse davantage de liberté qu’un outil métier utilisé huit heures par jour.

Je peux utiliser une transition sur le hero, faire évoluer une illustration au scroll ou animer une grande donnée.

Je garde volontairement des zones statiques.

Un article long n’a pas besoin de faire apparaître chaque sous-titre. Une section contenant plusieurs paragraphes gagne souvent à rester calme.

Ce contraste est utile.

Si tout bouge, plus rien n’a réellement de poids particulier.

Une animation placée sur un seul moment important devient beaucoup plus visible qu’une série d’effets identiques répétés tous les 500 pixels.

Les erreurs que je rencontre le plus souvent

Faire entrer chaque bloc au scroll

Le lecteur attend parfois que le texte apparaisse alors qu’il est déjà arrivé à sa position.

Animer un élément pour compenser une hiérarchie faible

Un CTA qui pulse ne résout pas une page contenant six actions concurrentes.

Mélanger trop de mouvements

Slides, springs, rotations et zooms utilisés ensemble donnent rarement une interface plus claire.

Imposer une animation longue à une action répétitive

Le coût est faible une fois et irritant à la cinquantième utilisation.

Secouer un champ sans expliquer son erreur

Le message est plus utile que l’effet.

Masquer le contenu en attendant JavaScript

Une animation de révélation ne devrait pas transformer un problème de script en page vide.

Utiliser du parallaxe parce que la page paraît trop statique

Le mouvement ne remplace pas une composition insuffisamment travaillée.

Ignorer la réduction des mouvements

Une direction très animée doit prévoir ce qui se passe avec prefers-reduced-motion.

Prototyper sans discuter de faisabilité

Un prototype Figma peut produire facilement un effet qui sera coûteux ou fragile une fois développé.

Ne travailler que l’animation et oublier l’état final

Une fois le mouvement terminé, l’interface doit continuer à expliquer clairement son état.

Ma méthode

Je commence par les changements d’état du parcours : ouvrir, fermer, sélectionner, envoyer, charger, terminer, supprimer.

Pour chacun, je dessine d’abord l’état avant et l’état après.

Si ces deux écrans sont déjà difficiles à comprendre sans animation, je règle le problème avant d’ajouter du mouvement.

Je définis ce qui doit être compris

Le mouvement doit-il confirmer l’action ? Montrer l’origine d’un panneau ? Faire suivre le déplacement d’un élément ?

Je cherche l’effet le plus simple

Une variation d’opacité ou une petite translation suffit souvent.

Je répète l’interaction

Je ne regarde pas seulement la première impression. J’ouvre dix fois le menu ou l’accordéon.

Je vérifie l’état mobile

Le même mouvement n’a pas toujours la même amplitude ni la même logique avec un geste tactile.

Je définis la version réduite

Les animations importantes ont une réponse prévue lorsque l’utilisateur souhaite moins de mouvement.

Je confronte les effets complexes au développement

Je préfère simplifier un mouvement avant intégration plutôt qu’obtenir une version saccadée du prototype initial.

Je réutilise les règles

Une fois validées, les durées, les comportements et les courbes récurrentes rejoignent le design system.

Checklist avant validation

L’animation explique-t-elle quelque chose ?
L’état final est-il compréhensible sans avoir vu la transition ?
Le feedback commence-t-il rapidement après l’action ?
La durée reste-t-elle supportable lorsque l’action est répétée ?
Le mouvement respecte-t-il l’origine et la destination du composant ?
Les différents composants utilisent-ils un langage de mouvement cohérent ?
L’utilisateur peut-il continuer sans attendre inutilement ?
Le contenu éditorial reste-t-il lisible sans animation ?
Le comportement a-t-il été revu sur mobile ?
Une réduction du mouvement est-elle prévue ?
L’information reste-t-elle accessible sans animation ?
Le coût technique de l’effet a-t-il été discuté lorsque nécessaire ?

FAQ sur les micro-interactions et animations UI

Qu’est-ce qu’une micro-interaction ?

Une micro-interaction est un échange court entre l’utilisateur et l’interface : activer un favori, modifier un réglage, envoyer un formulaire ou changer l’état d’un élément. Une animation peut accompagner cet échange.

À quoi sert une animation UI ?

Elle peut confirmer une action, rendre un changement d’état plus facile à suivre, expliquer une relation spatiale ou maintenir une continuité entre deux écrans.

Faut-il animer tous les boutons au survol ?

Non. Une variation discrète peut signaler l’interactivité sur desktop, mais elle n’est pas obligatoire si le bouton est déjà clairement identifiable. Le focus clavier doit rester visible indépendamment du hover.

Quelle durée utiliser pour une micro-interaction ?

La durée dépend de l’amplitude du mouvement et de la fréquence d’utilisation. Un feedback très local peut être presque instantané. Un grand panneau peut prendre un peu plus de temps. L’utilisateur ne devrait pas être obligé d’attendre la fin d’une animation pour poursuivre une action courante.

Le parallaxe est-il mauvais pour l’UX ?

Il peut fonctionner ponctuellement sur une page très visuelle, mais il ajoute beaucoup de mouvement et n’apporte généralement rien à une interface fonctionnelle. Il faut aussi prévoir une réduction de cet effet pour les personnes sensibles au mouvement.

Qu’est-ce que `prefers-reduced-motion` ?

C’est une préférence détectable en CSS qui indique que l’utilisateur souhaite réduire certains mouvements dans les interfaces. Le site peut alors supprimer ou remplacer les animations non essentielles.

Faut-il supprimer toutes les animations lorsque cette préférence est active ?

Non. Une transition importante pour comprendre un changement peut être remplacée par une version plus discrète, par exemple un fondu. L’objectif est de réduire les mouvements problématiques sans supprimer l’information.

Les animations doivent-elles faire partie du design system ?

Oui lorsque plusieurs composants utilisent les mêmes types de transitions. Documenter quelques durées, courbes et usages permet d’éviter que chaque élément possède un comportement différent.

Quelles propriétés CSS sont généralement adaptées aux animations ?

transform et opacity sont souvent privilégiées lorsqu’elles permettent de produire l’effet voulu, car elles peuvent généralement être animées plus efficacement que des propriétés qui provoquent des recalculs de mise en page.

Sources et ressources

Apple Human Interface Guidelines – Motion : continuité, feedback, durée et utilisation du mouvement dans les interfaces.
W3C – Understanding Success Criterion 2.3.3: Animation from Interactions : prise en compte des animations déclenchées par l’interaction.
W3C – Technique C39 : utilisation de prefers-reduced-motion.
MDN – prefers-reduced-motion : fonctionnement de la media query CSS dédiée à la réduction du mouvement.
web.dev – How to create high-performance CSS animations : performances des animations CSS et propriétés à privilégier.
Figma – Prototype animations : transitions disponibles dans les prototypes Figma.
Figma – Smart Animate : animation entre éléments correspondants de plusieurs frames.
Figma – Easing and spring animations : courbes d’accélération et comportements spring.