Dans la plupart des design systems la couleur a ses tokens, la typographie a son échelle, l’espacement a sa grille. L’animation, elle, se décide au cas par cas, dans un fichier After Effects que personne ne rouvre, ou directement dans le code par un développeur qui tape 300 ms parce que 300 ms « ça fait bien ».
La conférence Figma Config 2026 a quelque peu changé le décor. Avec Figma Motion, une timeline d’animation est maintenant disponible, l’animation s’attache aux composants, et les durées comme les courbes se stockent en variables. En parallèle, le W3C a stabilisé les types de tokens liés au mouvement et aux animations.
La matière technique existe désormais pour traiter le motion comme des tokens à part entière.
Le motion vaut le coup d’être standardisé
Les temps d’affichage
Faites l’exercice sur votre propre produit ou site web : ouvrez trois modales et chronométrez-les. Il y a de bonnes chances que vous trouviez trois durées différentes, des courbes d’easing choisies au ressenti, et aucune trace de la manière dont ces temps ont été paramétrés. C’est la situation par défaut dans la majorité des design systems, y compris ceux qui sont matures sur d’autres aspects tels que la « tokenisation » des couleurs et de la typographie.
L’absence de règles pour le motion a deux impacts directs. Il est d’abord cognitif : des transitions incohérentes brouillent la lecture des changements d’état, et forcent l’utilisateur à re-vérifier ce qui vient de se passer. Le mouvement d’interface est un canal d’information à part entière, comme nous le rappelions dans notre article sur le bon usage de l’animation d’interface.
Le deuxième impact est opérationnel : une spécification de mouvement transmise en vidéo ou en description textuelle se traduit toujours différemment dans le code. Chaque livraison d’un contenu animé s’accompagne d’un temps de traduction des animations en spécifications techniques… avec leur lot d’approximations.
Figma motion
Annoncé lors de la conférence Figma Config 2026 et disponible en bêta ouverte, Figma Motion apporte une timeline native dans l’environnement de travail. On y retrouve tout l’attirail du parfait outil d’animation : des keyframes, et une animation rattachée au composant maître, propagée à ses instances. Le timing et l’easing deviennent stockables en variables. La réflexion que les designers apportent sur le mouvement passe d’une tâche non standardisée à celui de valeur partagée et versionnable, au même titre que les autres nouveautés Figma orientées design system.
Dès lors les éléments d’animation deviennent des tokens comme les autres et il faut donc le décrire. Un token nommé par sa fonction (feedback de validation, orientation spatiale, invitation à cliquer, mise en avant du choix par défaut) décrit une intention ; c’est à ce niveau qu’une règle d’accessibilité ou de gouvernance peut s’accrocher. La valeur du motion dans un design system ne réside pas tant dans la cohérence des timelines d’animation (elles doivent être cohérentes et homogènes) mais dans la sémantique associée. Exactement comme pour les polices et les couleurs. C’est la fonction du motion qui prime à l’échelle du système.
Comment documenter le motion dans un design system
Cinq design systems comme sources d’inspiration
Avant d’inventer sa propre taxonomie, autant regarder ce que documentent les organisations qui ont dix ans de recul sur leur design system. Cinq références suffisent, elles couvrent l’ensemble des paradigmes existants.
Design system | Paradigme | Exemple de token | Échelle de durée | Particularité |
|---|---|---|---|---|
Material Design 3 (Google) | Physique de ressort (raideur, amortissement) | md.sys.motion.spring.fast.spatial | 150 à 750 ms | Sépare mouvement expressif et standard |
IBM Carbon | Mouvement sémantique | productive-motion / expressive-motion | Mise à l’échelle par distance | Pensé pour la densité B2B |
Microsoft Fluent 2 | Couches (global, alias, composant) | motion-duration-fast | Valeurs multiplateformes | Parité stricte React / WinUI |
Atlassian | Tokens par intention | motion.duration.fast | 50 à 150 ms (interactions), 150 à 400 ms (transitions) | Fourchettes publiées explicitement |
Shopify Polaris | Primitives CSS | –p-motion-duration-150 | 50 à 500 ms par pas de 50 | Tokenise jusqu’aux keyframes |
Ce qui est tokenisé : la durée, la courbe et le mouvement
Trois valeures primitives reviennent dans ces design systems : la durée, la courbe (cubic-bezier ou paramètres de ressort) et la transition composite qui encapsule les deux plus le délai. La tendance est l’abandon des valeurs absolues au profit de tokens décrivant l’intention (entrance, expressive, spatial) : le nombre devient un détail d’implémentation. Deux composantes d’une animation réussie restent néanmoins très largement non décrites : la chorégraphie (l’ordre entre plusieurs éléments animés ensemble) et l’interruption (ce qui se passe si l’utilisateur agit avant la fin).
IBM Carbon, le design system d’IBM, distingue le mouvement productif (utilitaire, rapide, invisible) du mouvement expressif (marquant, réservé aux moments qui comptent). C’est la meilleure réponse au reproche d’uniformisation : standardiser les 95 % de micro-interactions utilitaires libère du budget pour les 5 % qui portent la signature de marque. Quel que soit votre système, cette grille de travail se transpose telle quelle.
Les tokens de motion se normalisent
La spécification W3C
Le Design Tokens Community Group du W3C a publié une version stable de son format en octobre 2025. Trois types concernent directement le mouvement : duration, cubicBezier (un tableau de quatre nombres) et transition. C’est un token composite qui associe durée, délai et fonction de timing.
Attention toutefois, ce standard ne fait pas tout. La spécification normalise le format, pas la sémantique. Elle dit comment écrire une durée, jamais quand l’utiliser. Le travail de fond décrit dans notre guide des design tokens reste entier ; la norme donne simplement le cadre.
De la Variable Figma au CSS en production
La chaîne de production pourrait se décrire de la manière suivante.
Le designer modifie les valeurs de motion, duration, speed dans les Variables Figma. Un export (type Tokens Studio) produit un JSON au format DTCG, poussé dans Git. Un moteur de transformation (type Style Dictionary) génère les variables natives : propriétés CSS personnalisées, Swift, Kotlin. Une valeur, plusieurs plateformes, un historique.
Encore faut-il nommer les tokens correctement, et la pratique converge vers trois couches de tokens.
- Les tokens primitifs, nommés par leur échelle (duration-100), ne sont jamais appelés directement dans un composant : ce sont des détails d’implémentation.
- Les tokens sémantiques (motion.duration.fast, motion.easing.entrance) sont la couche que les composants consomment.
- Les tokens de composant (button-transition-hover) se créent pour les animations conçues spécifiquement pour les transitions entre les états d’un composant interactif.
Nos premières impression sur la bêta de Figma Motion
Ce qui manque dans la bêta
Figma Motion produit des séquences linéaires, jouées puis « oubliées ». Un feu tricolore sait qu’il passe du vert à l’orange puis au rouge, jamais du vert au rouge : sans ce modèle, Figma n’arrive pas à recalculer une trajectoire inverse quand l’utilisateur interrompt un geste en cours. Les praticiens documentent depuis la bêta des bugs d’inversion à la fermeture soudaine d’une feuille inférieure, et la parité d’export reste imparfaite : le CSS généré ne correspond pas toujours au rendu des moteurs natifs.
Il y a aussi le sujet du coût de Figma Motion. Les fonctions avancées sont réservées aux sièges Design complets (de l’ordre de 16 à 90 dollars par mois selon le plan au moment où nous écrivons), et l’usage de l’agent IA est plafonné en crédits mensuels. Systématiser le motion par l’agent revient à piloter un budget de consommation, pas seulement un budget de licences. Avant d’équiper une équipe entière, il vaut mieux se former aux design system et aux tokens W3C.
Où s’arrête la spec, où commence le code
Un design system qui prétend spécifier toutes les animations sans écrire une ligne de code se ment à lui-même. Ce qui se spécifie côté système : les tokens (durée, courbe, transition), les règles d’usage par type de composant, les comportements d’entrée et de sortie, la politique de mouvement réduit. Ce qui reste du ressort du code : les logiques d’état, les animations interruptibles, les runtimes dédiés (Rive, Lottie), les moteurs natifs (Jetpack Compose, SwiftUI).
À quoi sert le mouvement dans les expériences numériques
Pourquoi animer ?
La question « pourquoi animer » a des réponses vieilles de trente-cinq ans. Baecker et Small (1990) posent que l’animation en interface sert à révéler la structure, le processus ou la fonction du système. Chang et Ungar (1993) montrent que les changements d’état brutaux désorientent.
Pour passer de la théorie à la pratique, le modèle de Dan Saffer sur les micro-interactions (déclencheur, règles, feedback, boucles) donne le bon découpage : on ne tokenise pas une animation, on tokenise le feedback d’une classe de déclencheurs.
Ajsuter les seuils de durée
Trois repères circulent. À 100 ms, on est dans le spectre de la manipulation directe, le seuil documenté par la recherche que relaie le Nielsen Norman Group : c’est la durée d’un état pressé de bouton. C’est entre 150 et 500 ms que se joue la grande majorité des transitions d’interface. Au-delà de 500 ms, l’animation devient une attente subie ; au-delà d’une seconde, on réserve le mouvement aux séquences sans interaction immédiate, typiquement l’onboarding et les parcours guidés.
Le mouvement doit être implémenté avec parcimonie car il capte involontairement le regard, c’est sa force mais aussi son potentiel de nuisance, un mécanisme bien décrit par l’ergonomie cognitive. Ceci amène à une règle de tri simple : si l’animation retirée ne change rien à la compréhension de ce qui vient de se passer, elle est décorative. À traiter comme telle, donc à désactiver en priorité pour des expériences à mouvement réduit.
Accessibilité et motion
Le cadre normatif
Pour les personnes atteintes de troubles vestibulaires, un mouvement d’interface prolongé ou en parallaxe ne crée pas une gêne : il déclenche vertiges, nausées, migraines.
Le cadre normatif l’est tout autant. WCAG 2.2 pose deux critères : le 2.3.3 (Animation from Interactions) exige que toute animation déclenchée par une interaction puisse être désactivée, le 2.2.2 (Pause, Stop, Hide) que le contenu en mouvement automatique puisse être arrêté. Et depuis le 28 juin 2025, l’European Accessibility Act s’applique dans l’Union européenne ; le RGAA porte la même exigence en France. L’accessibilité numérique du mouvement est passée du registre des bonnes pratiques à celui du risque juridique.
Implémenter une couche token dite : « prefers-reduced-motion »
L’implémentation la plus répandue pour répondre aux enjeux d’accessibilité c’est de retirer toutes les animations. En gros, sur un bloc CSS global, on écrase toutes les durées à zéro en fin de feuille de style. Ça fonctionne mais ça casse toutes les transitions jugées nécessaires au feedback et à la compréhension.
La bonne implémentation encode la préférence dans la couche de tokens elle-même. Le token motion-duration-standard change de valeur à l’intérieur du bloc de media query, et un mouvement spatial potentiellement nauséeux se décline en simple fondu d’opacité plutôt que de disparaître. Tout cela est possible qu’avec un motion design correctement « tokenisé ».
Enfin, réduire et simplifier les animations dans un mode d’affichage « reduced motion » permet d’alléger le CSS et de maintenir une bonne expérience sur des appareils moins puissants ou avec un débit faible.
La gouvernace du motion dans un design system
La fin du motion designer qui livre une « simple » animation
Le modèle qui tend à devenir obsolète est le suivant : un motion designer produit une séquence After Effects, la transmet, et un développeur la réinterprète. Aucune valeur ne circule, seulement une intention approximative. Le modèle qui émerge au sein des organisations matures est une gouvernance fédérée : l’équipe design system tient les fondations (format des tokens, seuils, politique d’accessibilité), les designers produit et les développeurs contribuent en proposant de nouvelles sémantiques, réintégrées après validation. C’est le type d’arbitrage qu’un accompagnement design system sert à cadrer, car une question bloque systématiquement en atelier : qui a le droit de créer un nouveau token de motion, et qui a le droit de le refuser ?
Quels indicateurs pour la systématisation du motion
Les indicateurs actionnables existent : taux de couverture (la part des composants dont le mouvement est spécifié), disponibilité (lisible directement dans Git), et adoption réelle des tokens dans les fichiers de handoff activement édités, comme le pratique l’équipe design system de Pinterest ou de Stripe.
Pour le moment il n’existe quasiment aucune étude sérieuse isolant le retour sur investissement du motion seul.
Reste l’objection classique : la tokenisation tuerait la marque. Elle confond l’infrastructure et l’expression, et le clivage productif / expressif y répond déjà : le système de motion ne contraint pas la créativité, il la finance et la rend défendable.
Par où commencer
- Commencez par un audit. Inventoriez les durées et les courbes réellement présentes dans le produit : le nombre de valeurs distinctes trouvées est l’argument qui débloque le budget.
- Créez d’abord la couche sémantique minimale : trois à cinq durées, trois courbes (entrée, sortie, standard), et rien d’autre. La granularité vient après, jamais avant.
- Définissez une taxonomie de tokens en production coûte infiniment plus cher que de la nommer correctement au départ.
- Traitez le mouvement réduit comme une variante de token pour être conforme avec les règles d’accessibilité. C’est le seul point du sujet qui soit une obligation légale.
