Des animations web qui tiennent à l'usage

1Décider si ça doit bouger

Une animation se justifie quand elle répond à une de ces trois questions.

• Où est-ce que ça va ? Un panneau qui glisse depuis la droite indique d'où il vient et où il retournera.
• Est-ce que mon action a été prise en compte ? Un bouton qui réagit au clic confirme sans texte.
• Qu'est-ce qui a changé ? Une ligne de tableau qui s'insère en douceur évite de chercher ce qui est nouveau.

Si aucune ne s'applique, ne bouge pas. Un contenu qui apparaît au défilement ne répond à aucune des trois : le visiteur sait déjà qu'il défile, et le fondu ne fait que retarder la lecture.

2Animer transform et opacity, presque uniquement

Le navigateur découpe le rendu en étapes : calcul de la mise en page, peinture, puis composition des couches. Une animation qui touche à la mise en page force le navigateur à tout recalculer à chaque image.

La recommandation de la documentation de performance web est nette : restreindre les animations à transform et opacity, qui se traitent à l'étape de composition, et éviter les propriétés qui déclenchent mise en page ou peinture sauf nécessité réelle.

/* recalcule la mise en page a chaque image */
.carte { transition: top 200ms; }

/* traite a la composition */
.carte { transition: transform 200ms; }

Sur will-change, la recommandation officielle est de ne l'utiliser que si tu constates un problème graphique et que promouvoir l'élément dans une couche semble aider. Ce n'est pas une optimisation à poser partout : chaque couche consomme de la mémoire.

3Choisir une durée courte

Les repères publiés par le Nielsen Norman Group sont utilisables tels quels :

Au-delà de 500 ms, l'animation devient une gêne. Retiens le principe : plus le déplacement est petit, plus il doit être court. Un survol de bouton à 300 ms est déjà mou.

Pour les courbes, deux suffisent dans la plupart des interfaces : une sortie rapide puis freinée pour ce qui entre à l'écran, et une accélération pour ce qui en sort.

4Gérer l'interruption

C'est le point qui sépare une interface soignée d'une interface irritante. Un visiteur qui survole une carte, part, revient, ne doit pas attendre la fin de l'animation précédente.

Les transitions CSS gèrent ça correctement par nature : elles repartent de la valeur courante. Les animations pilotées en JavaScript, en revanche, redémarrent souvent du début si personne ne s'en occupe. La règle simple : si un état peut changer plus vite que la durée de l'animation, utilise une transition sur une propriété, pas une séquence d'images clés jouée du début à la fin.

/* repart de la position courante si on survole a nouveau */
.carte {
  transition: transform 160ms ease-out;
}
.carte:hover {
  transform: translateY(-4px);
}

5Respecter la préférence système

Certains utilisateurs souffrent physiquement du mouvement à l'écran. Le système d'exploitation expose leur préférence, et le CSS la lit avec une seule requête de média. Les deux valeurs possibles sont no-preference et reduce.

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Ce bloc large est un filet de sécurité, pas une finalité. Mieux vaut, sur les animations importantes, remplacer le mouvement par un changement d'opacité : l'information reste transmise, sans déplacement.