Grammaire du mouvement : quand l'animation mérite ses images

La plupart des animations d’interface sont de la décoration qui porte le badge d’une fonction. Le test que j’applique est sans détour : si vous ne pouvez pas expliquer ce qu’une animation dit à l’utilisateur, elle ne mérite pas ses images — supprimez-la. Ce qui survit à ce test se révèle être une grammaire réduite : quatre plages de durée, deux règles d’easing et une poignée de tâches que le mouvement accomplit vraiment mieux qu’un changement statique. Tout le reste, c’est un designer qui se divertit aux dépens de l’utilisateur, seize millisecondes à la fois. {.answer-block}

En résumé

• Le mouvement est une information, ou bien c’est du bruit. Les tâches légitimes : montrer d’où vient une chose ou vers où elle est partie, confirmer qu’une action a été enregistrée, diriger l’attention pendant un changement et masquer une latence inévitable. Tout le reste, coupez.
• Quatre plages de durée couvrent l’interface entière : ~100ms pour les appuis et les bascules, 150-200ms pour les survols et les fondus, 250-300ms pour les déploiements et repliements, 300-400ms pour les transitions de page et les fenêtres modales.
• Deux règles d’easing couvrent les entrées et les sorties : ease-out pour tout ce qui entre, ease-in pour tout ce qui sort. Les éléments qui se déplacent en restant à l’écran prennent ease-in-out ; linear est réservé aux barres de progression et aux fondus purs.
• Le test de suppression prime sur le test du goût. « Est-ce que c’est agréable ? » maintient en vie les mauvaises animations ; « qu’est-ce que cela dit à l’utilisateur ? » les tue.
• Traitez prefers-reduced-motion comme une exigence de premier ordre, et non comme une réflexion après coup — la grammaire doit pouvoir se dégrader en changements d’état instantanés tout en gardant du sens.

Le mouvement est une phrase, pas une ambiance

Une animation d’interface est une affirmation sur la causalité : ce panneau vient de ce bouton ; cet élément est parti vers cette liste ; ce changement s’est produit parce que vous avez agi. Quand le mouvement porte l’une de ces affirmations, le modèle mental de l’utilisateur se met à jour gratuitement — sans lecture, sans raisonnement. Quand il ne porte rien, l’utilisateur attend la fin de la chorégraphie avant de pouvoir continuer, et chaque attente est une petite taxe prélevée sur la confiance.

Ce cadrage produit la liste de travail des tâches que le mouvement remplit réellement :

1. Continuité spatiale — d’où vient ceci, où est-ce parti. La carte qui se déploie, la feuille qui s’élève depuis son déclencheur, la ligne supprimée qui se replie vers l’icône d’archivage.
2. Accusé de réception — votre appui a été enregistré. L’enfoncement du bouton en 100ms, le lancer de l’interrupteur, la coche de la case.
3. Orientation de l’attention — pendant un changement d’état, la seule chose qui a bougé est la seule chose qui a changé. Le mouvement compte parmi les signaux attentionnels les plus puissants qu’une interface puisse émettre ; c’est précisément pour cela qu’un mouvement non mérité coûte si cher.
4. Masquage de la latence — le scintillement du squelette de chargement, l’échange optimiste, la révélation progressive qui fait passer 400ms de requête pour une intention plutôt que pour une panne.

Si une animation présente sur votre écran ne remplit aucune de ces quatre tâches, c’est qu’elle en remplit une cinquième : se faire remarquer.

Les quatre plages de durée

Les durées ne relèvent pas du goût ; elles relèvent d’une physique accordée à l’attention. Voici les plages auxquelles je tiens toute interface :

Le motif sous-jacent : la durée croît avec l’ampleur du changement. Un contrôle qui accuse réception d’un appui doit être quasi instantané — au-delà de ~150ms, l’accusé de réception se lit comme de la latence. Une transition plein écran obtient plus de temps parce que l’utilisateur en a besoin pour se réorienter. L’échec le plus courant est l’inversion : des boutons qui rebondissent sur 400ms (de la latence déguisée en plaisir) et des fenêtres modales qui claquent en 100ms (de la désorientation déguisée en vitesse).

Au-delà de 400ms, un mouvement d’interface a besoin d’une raison d’exister exceptionnelle. Les moments d’onboarding et les états de célébration méritent parfois 500-600ms ; la navigation à l’échelle du téléphone, presque jamais, même si les transformations de conteneur sur grand écran sont l’exception honnête — les surfaces de tablette et d’ordinateur s’étirent légitimement vers 500ms parce que l’œil a plus de chemin à parcourir. L’utilisateur exécute votre transition des milliers de fois — la chorégraphie qui charmait pendant la démo est la friction qu’il maudit la troisième semaine.

Les systèmes à ressort (SwiftUI, Framer Motion) expriment le tempo en rigidité et en amortissement plutôt qu’en durées fixes, mais les plages s’appliquent toujours : elles décrivent le temps de stabilisation perçu vers lequel vous réglez. La grammaire survit au changement de notation.

Deux règles d’easing

L’easing, c’est là que l’animation acquiert une physique, et deux règles couvrent presque tout :

Ease-out pour ce qui entre. Les éléments qui arrivent à l’écran démarrent vite et décélèrent jusqu’à leur place — ils atterrissent. Ease-out concentre le mouvement au début, si bien que l’œil saisit la destination tôt et que l’élément paraît réactif.

Ease-in pour ce qui sort. Les éléments qui partent accélèrent en s’éloignant — ils sortent avec intention. Le démarrage lent laisse à l’œil un temps pour enregistrer qu’une chose s’en va avant qu’elle ne disparaisse.

L’easing linear se lit comme mécanique parce que rien dans le monde physique ne se déplace ainsi ; réservez-le aux indicateurs de progression, où la cadence constante est l’information, et aux fondus purs d’opacité ou de couleur, où rien ne parcourt de distance et où aucun mouvement n’attend d’être façonné par une courbe. Quant à l’ease-in-out symétrique, il relève du troisième cas que les deux règles laissent délibérément de côté : les éléments qui se déplacent tout en restant à l’écran, comme une ligne qui change de rang ou un panneau qui se redimensionne. Ils n’atterrissent ni ne sortent : ils accélèrent depuis le repos et y reviennent. Là où ease-in-out gagne sa mauvaise réputation, c’est comme valeur par défaut jamais interrogée sur les entrées et les sorties, où il rend d’un même geste les arrivées molles et les départs abrupts.

Le test de suppression en pratique

La procédure de revue qui garde honnête un système de mouvement :

1. Inventoriez chaque animation de la surface — y compris les valeurs par défaut du framework que personne n’a choisies délibérément.
2. Pour chacune, complétez la phrase : « Ce mouvement dit à l’utilisateur ___. » Origine spatiale, accusé de réception, attention, latence — l’une des quatre, en mots simples.
3. Tout ce qui reste vide reste vide même après discussion. « Cela ajoute du raffinement » et « cela fait premium » sont des vides au vocabulaire plus riche. Supprimez le mouvement et regardez la surface pendant une journée ; un raffinement qui n’existait que dans le mouvement n’a jamais été du raffinement.
4. Chronométrez ce qui survit face aux plages, corrigez les easings et testez le parcours en mouvement réduit. prefers-reduced-motion doit produire une interface pleinement cohérente faite de changements d’état instantanés — si retirer une animation casse la compréhension, c’est que cette animation portait une information qui devrait aussi exister de façon statique, ce qui constitue un constat à part entière.

Appliquez cela à un produit mature et, en général, la moitié de l’inventaire meurt. Une liste d’exécutions représentative issue d’un seul passage : le soulèvement au survol de 400ms sur les cartes (il ne dit à l’utilisateur rien qu’un changement de curseur ne disait déjà), l’entrée de liste en cascade rejouée à chaque navigation (600ms pour annoncer « nous avons des lignes »), l’icône d’enregistrement qui pulse (attention réclamée, rien de changé à observer). Personne ne les regrette. Ce qui reste devient plus rapide, plus cohérent et, paradoxalement, plus remarquable — parce que le mouvement retrouve sa valeur de signal dès l’instant où il cesse d’être ambiant.

La vue système

Dans un design system, le mouvement appartient aux tokens exactement comme l’espacement et la couleur : des durées nommées (--motion-press: 100ms, --motion-surface: 300ms), des easings nommés (--ease-enter, --ease-exit) et des composants qui consomment des tokens au lieu d’inventer des tempos en ligne. Le mode de défaillance d’un mouvement non systématisé n’est pas la laideur, c’est la dérive — cinq fenêtres modales avec cinq durées, chacune défendable, collectivement incohérentes. La discipline qui gouverne une échelle d’espacement gouverne une échelle de mouvement : chaque valeur vient du système, ou porte une raison documentée.

Le mouvement est aussi la couche la plus périssable d’un design system — celle sur laquelle les contributeurs improvisent en premier, parce qu’un tween ponctuel de 250ms paraît inoffensif. Il l’est, onze fois, puis le produit vacille sous onze accents de mouvement immotivé. La grammaire ne tient qu’aussi longtemps que le test de suppression continue de tourner.

Questions fréquentes

Combien de temps doivent durer les animations d’interface ?

Accordez la durée à l’ampleur du changement : ~100ms pour l’accusé de réception d’un contrôle (appuis, bascules), 150-200ms pour les survols et les fondus, 250-300ms pour les déploiements et repliements, 300-400ms pour les transitions de page et les fenêtres modales. Au-delà de 400ms, il faut une justification exceptionnelle — les utilisateurs répètent les transitions d’interface des milliers de fois.

Quel easing utiliser pour les animations d’interface ?

Ease-out pour les éléments qui entrent (démarrage rapide, décélération jusqu’à leur place), ease-in pour les éléments qui sortent (accélération en s’éloignant) et ease-in-out pour les éléments qui se déplacent tout en restant à l’écran. Réservez linear aux indicateurs de progression et aux fondus purs d’opacité ou de couleur. À l’entrée, linear se lit comme mécanique et ease-in-out rend les arrivées molles — ease-out est la règle.

Quand une interface doit-elle recourir à l’animation ?

Quand le mouvement porte une information qu’un changement statique ne peut pas porter : continuité spatiale (d’où vient une chose ou vers où elle est partie), accusé de réception d’une saisie, orientation de l’attention vers ce qui a changé, ou masquage d’une latence inévitable. Si vous ne pouvez pas dire laquelle de ces tâches remplit une animation, retirez-la — un mouvement décoratif taxe chaque interaction qu’il touche.

Comment prefers-reduced-motion s’intègre-t-il dans un système de mouvement ?

Comme une exigence de premier ordre : le parcours réduit remplace le mouvement par des changements d’état instantanés, et l’interface doit rester pleinement compréhensible. Si retirer une animation casse la compréhension, c’est que le mouvement portait une information qui a besoin d’un équivalent statique — un constat d’accessibilité et un constat de design à la fois.