Animations sur un site web : utiles ou nuisibles ?

Une animation sur un site web est utile quand elle aide le visiteur à comprendre ce qui se passe : confirmer un clic, montrer d’où sort un menu, signaler une erreur dans un formulaire. Elle devient nuisible quand elle décore au détriment de la vitesse, du confort ou de l’accessibilité : textes qui n’apparaissent qu’au défilement, parallaxe qui donne le vertige, carrousel qui tourne tout seul. Notre règle tient en trois points, pour nos clients comme pour notre propre site : animer seulement ce qui sert, le faire en CSS, et respecter le réglage « réduire les animations » de chaque visiteur. Ce guide complète nos conseils pour des pages claires et accessibles.

Ce qu’une animation apporte au visiteur

Bien employée, une animation remplit l’un de ces trois rôles :

• Confirmer une action. Un bouton qui change d’aspect sous le doigt, un indicateur pendant l’envoi d’un formulaire, une coche quand le message est parti : le visiteur sait que son geste a été pris en compte. Encore faut-il que la réaction soit immédiate : selon le modèle RAIL publié par Google, une réponse en moins de 100 millisecondes est perçue comme instantanée. L’INP, l’indicateur de réactivité de Google, mesure ce délai entre le geste et la réaction à l’écran : il est jugé bon jusqu’à 200 millisecondes.
• Montrer d’où viennent les choses. Un menu qui se déplie sous son bouton, un panneau qui glisse depuis le bord de l’écran, une réponse de FAQ qui s’ouvre sous sa question : le mouvement relie l’état d’avant à l’état d’après.
• Attirer l’œil sur un changement. Un compteur de panier mis à jour, un message d’erreur à côté du champ concerné, une notification discrète. C’est le rôle le plus délicat : ce qui attire le regard le détourne aussi du reste de la page.

Hors de ces trois rôles, l’animation est décorative. Elle a sa place sur un site de marque ou un portfolio, si elle justifie son coût et s’efface quand le visiteur le demande.

Ce que coûte une animation : chargement, réactivité, stabilité

Une animation n’est jamais gratuite : bibliothèque JavaScript, vidéo ou image animée, elle se télécharge puis s’exécute sur l’appareil du visiteur, parfois un téléphone bien moins puissant que l’ordinateur de son concepteur. Les trois Core Web Vitals de Google en portent la trace :

• Le LCP, pour l’affichage du contenu principal. Pour le calculer, Chrome ignore les éléments dont l’opacité est nulle et ne retient un élément qu’une fois qu’il est affiché et visible : un titre qui attend un script ou un délai d’animation pour apparaître peut donc allonger le LCP d’autant. Un écran de chargement animé fait pire : il retarde l’affichage de toute la page.
• Le CLS, pour la stabilité visuelle. Une animation de transform déplace un élément sans décaler la mise en page, contrairement à une animation de top, de left ou de la hauteur d’un bloc. Google tolère les décalages qui surviennent moins de 500 millisecondes après un clic, un toucher ou une frappe, comme à l’ouverture d’un accordéon ; au-delà, ils comptent de nouveau, et le défilement ne bénéficie d’aucune tolérance.
• L’INP, pour la réactivité. Il peut souffrir des animations calculées image par image en JavaScript et des scripts qui suivent le défilement : ils occupent le fil principal du navigateur, celui qui traite aussi les clics.

Pour les mesurer sur votre site, suivez notre guide des Core Web Vitals. Et si des effets l’ont déjà alourdi, notre service d’optimisation de la vitesse commence par un audit, puis classe les corrections selon le gain attendu.

Accessibilité : vertiges, distraction et crises d’épilepsie

Les règles internationales d’accessibilité du W3C, les WCAG, visent trois risques liés au mouvement :

• Les vertiges. Chez les personnes atteintes de troubles vestibulaires, c’est-à-dire de l’oreille interne, une animation peut provoquer vertiges, nausées et maux de tête. Le W3C cite la parallaxe, où l’arrière-plan défile à une autre vitesse que le premier plan, comme une animation souvent non essentielle, et vise aussi les pages dont les éléments bougent quand on les fait défiler.
• La distraction. Un contenu en mouvement peut fortement distraire, et ce qui clignote gêne particulièrement les personnes qui ont des troubles de l’attention. Il complique aussi la lecture pour celles qui suivent mal les objets en mouvement, et peut perturber les lecteurs d’écran.
• Les crises d’épilepsie. Chez les personnes photosensibles, un contenu qui flashe à certaines fréquences peut déclencher une crise, et le rouge est plus à risque que les autres couleurs.

Les WCAG y répondent notamment par trois critères, que le RGAA reprend en partie :

Ces correspondances valent pour le RGAA 4.1.2, en vigueur ; sa version 5 est annoncée pour fin 2026.

Les deux premiers, de niveau A, s’appliquent selon le W3C à tous les contenus de la page, car un seul élément fautif peut gêner l’usage de toute la page. Le RGAA les traduit en tests. Son critère 13.8 admet un mouvement automatique s’il dure cinq secondes au plus, si l’on peut l’arrêter et le relancer, le masquer, ou obtenir la même information sans lui ; une pause limitée au moment où l’élément a le focus ne suffit pas. Son critère 13.7 tolère un flash plus rapide si sa surface cumulée ne dépasse pas 21 824 pixels, soit un carré d’environ 148 pixels de côté.

Le troisième, de niveau AAA, n’est pas exigé par le RGAA, qui s’arrête au niveau AA. C’est pourtant lui qui protège le plus directement les personnes sensibles au mouvement, et il coûte peu à respecter quand il est prévu dès la conception. Pour de nombreuses boutiques en ligne, l’accessibilité n’est d’ailleurs plus une simple bonne pratique depuis juin 2025 et l’European Accessibility Act : voyez ce que la loi sur l’accessibilité numérique change pour les sites marchands.

Respecter le réglage « réduire les animations »

Tous les grands systèmes d’exploitation, d’Android à Windows, proposent un réglage pour limiter les animations, et tous les grands navigateurs le transmettent aux sites depuis janvier 2020 grâce à la requête média CSS prefers-reduced-motion. Un site bien construit le lit, dans ses feuilles de style comme dans ses scripts, et réduit ses propres mouvements. Pour le W3C, c’est une technique suffisante, en CSS comme en JavaScript, pour satisfaire le critère 2.3.3.

Deux écritures sont possibles : retirer le mouvement quand le visiteur a demandé à le réduire, ou ne l’ajouter que s’il n’a rien demandé. Nous préférons la seconde, plus prudente, car un navigateur trop ancien pour lire ce réglage n’ajoute alors aucun mouvement :

/* Le fondu vaut pour tout le monde ; le glissement n’est
   ajouté que si le visiteur n’a pas demandé à réduire les animations. */
.menu {
  transition: opacity 220ms ease-out;
}

@media (prefers-reduced-motion: no-preference) {
  .menu {
    transition: opacity 220ms ease-out, transform 220ms ease-out;
  }
}

Réduire ne veut pas dire tout supprimer. Pour le W3C, un changement de couleur ou d’opacité n’est pas une animation de mouvement : un fondu peut donc remplacer un glissement ou un zoom, comme le fait l’iPhone quand on active son réglage.

Sur notre propre site, les transitions durent 140 ou 220 millisecondes : survol des boutons et des liens, ouverture du menu, dépliage des questions de la FAQ. Aucune bibliothèque d’animation n’est chargée. Le menu et la FAQ ne s’animent que si le visiteur n’a rien demandé. S’il a activé le réglage, nous allons plus loin : une règle générale coupe toutes les autres transitions, fondus compris. Seul le dépliage de la FAQ anime une hauteur plutôt que transform : comme il suit un clic et dure 220 millisecondes, il reste hors du calcul du CLS.

Parallaxe, défilement imposé, carrousels : les effets à risque

Voici, du plus sûr au plus risqué, ce que promettent les effets les plus courants, ce qu’ils coûtent et notre avis.

Si un carrousel s’impose malgré tout, le guide du W3C pour un carrousel accessible en fixe le minimum : des boutons pour afficher la diapositive précédente ou suivante, un bouton pour arrêter et relancer la rotation, un arrêt dès que la souris le survole, et un arrêt dès que le clavier y entre, sans reprise tant que le visiteur ne la demande pas. Pour la parallaxe et les apparitions au défilement, le réglage « réduire les animations » doit tout couper : le contenu reste alors à sa place, visible d’emblée.

Animer léger : le CSS d’abord

Pour la plupart des sites vitrines et des boutiques, le CSS suffit. La documentation de Mozilla sur la performance des animations le résume : mieux vaut écrire ses animations en CSS chaque fois que c’est possible, et réserver le JavaScript aux animations vraiment complexes.

Encore faut-il animer les bonnes propriétés. Google conseille de s’en tenir à transform et opacity, que le navigateur anime sans recalculer la mise en page ni repeindre la page, et de n’employer will-change qu’avec parcimonie, en cas de problème avéré. Même les effets liés au défilement s’écrivent désormais en CSS et peuvent s’exécuter hors du fil principal, sans les saccades d’un script : c’est ainsi qu’est construite la barre de progression de nos articles, que les navigateurs qui ne gèrent pas cette technique ignorent simplement.

Pour les images animées, le GIF est un format lourd et peu efficace. Dans un exemple publié par Google, un GIF de 3,7 Mo ne pèse plus que 551 Ko une fois converti en vidéo MP4, et 341 Ko en WebM. Une courte vidéo sans son, dotée de commandes, a un autre avantage : le visiteur peut l’arrêter.

Le référentiel général d’écoconception des services numériques (RGESN), publié en mai 2024 par l’Arcep et l’Arcom avec l’ADEME, va dans le même sens. Son critère 4.1 demande de désactiver la lecture automatique des animations, vidéos et sons, d’éviter les GIF animés et les vidéos de fond purement esthétiques, et de doter de commandes toute animation de plus de quatre secondes, un seuil plus strict que les cinq secondes des WCAG. Son critère 4.6 n’admet que les vidéos, sons et animations qui portent une information ou servent une fonction critique du service, et demande d’en justifier l’emploi dans la déclaration d’écoconception.

Avant d’animer : la grille de décision

Avant d’ajouter un mouvement, posez ces six questions. Une seule réponse négative suffit à revoir l’effet, ou à y renoncer.

1. Aide-t-il le visiteur ? Il confirme une action, montre d’où vient un contenu ou signale un changement. Sinon, c’est une décoration, qui doit justifier son coût.
2. La page reste-t-elle complète sans lui ? Le premier écran s’affiche sans attendre, le contenu reste visible si le script ne se charge pas, et rien d’essentiel ne se perd avec le réglage « réduire les animations ».
3. Repose-t-il sur le CSS, avec transform ou opacity ? Sinon, mesurez son effet sur l’INP et le CLS avant de le garder.
4. Est-il bref et contrôlable ? La réaction commence tout de suite et se termine vite ; au-delà de quatre secondes, un mouvement automatique peut être mis en pause.
5. Évite-t-il tout clignotement rapide ? Jamais plus de trois flashs par seconde.
6. A-t-il été vérifié sur un téléphone modeste ? C’est là que les saccades apparaissent.

Ces questions se posent dès la conception : une animation se décide sur la maquette et se vérifie à l’étape du prototype cliquable ; la consigne remise aux développeurs précise ensuite sa durée et ce qu’elle devient quand le visiteur réduit les animations. C’est ainsi que travaille notre équipe de design UX/UI à Nantes : nous gardons les mouvements qui aident à comprendre, et chaque effet décoratif doit prouver qu’il vaut ce qu’il coûte.