---
title: "Animations sur un site web : utiles ou nuisibles ?"
description: "Animation de site web : ce qu’elle apporte au visiteur, ce qu’elle coûte en vitesse (LCP, INP, CLS) et en accessibilité, et comment animer utile et léger."
canonical_url: "https://studiofogg.fr/journal/animations-site-web-utiles-ou-nuisibles"
---

> Index of every page on this site: [llms.txt](https://studiofogg.fr/llms.txt)

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](https://studiofogg.fr/journal/rubrique/ux-contenus-accessibilite).

## 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](https://web.dev/articles/rail), une réponse en moins de 100 millisecondes est perçue comme instantanée. [L’INP, l’indicateur de réactivité de Google](https://studiofogg.fr/glossaire#inp), 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](https://web.dev/articles/lcp) : 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](https://web.dev/articles/cls), 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](https://web.dev/articles/inp).

Pour les mesurer sur votre site, suivez [notre guide des Core Web Vitals](https://studiofogg.fr/journal/core-web-vitals-lcp-inp-cls). Et si des effets l’ont déjà alourdi, [notre service d’optimisation de la vitesse](https://studiofogg.fr/services/optimisation-vitesse-site-web-nantes) 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](https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html). 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](https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html), 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](https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold.html), 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 :

<table>
<thead>
  <tr>
    <th>
      Critère WCAG
    </th>
    
    <th>
      Ce qu’il demande
    </th>
    
    <th>
      Niveau
    </th>
    
    <th>
      RGAA 4.1.2
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      2.2.2 Mettre en pause, arrêter, masquer
    </td>
    
    <td>
      Un mouvement automatique de plus de cinq secondes, affiché avec d’autres contenus, peut être mis en pause, arrêté ou masqué, sauf s’il est essentiel
    </td>
    
    <td>
      A
    </td>
    
    <td>
      Critère 13.8
    </td>
  </tr>
  
  <tr>
    <td>
      2.3.1 Pas plus de trois flashs ou sous le seuil critique
    </td>
    
    <td>
      Rien ne flashe plus de trois fois par seconde, sauf sous les seuils de flash général et de flash rouge
    </td>
    
    <td>
      A
    </td>
    
    <td>
      Critère 13.7
    </td>
  </tr>
  
  <tr>
    <td>
      2.3.3 Animation résultant d’interactions
    </td>
    
    <td>
      Le mouvement déclenché par une interaction peut être désactivé, sauf s’il est essentiel
    </td>
    
    <td>
      AAA
    </td>
    
    <td>
      Non exigé
    </td>
  </tr>
</tbody>
</table>

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](https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/#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](https://studiofogg.fr/journal/european-accessibility-act-ce-qui-change-pour-votre-site).

## 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`](https://developer.mozilla.org/fr/docs/Web/CSS/Reference/At-rules/@media/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 :

```text
/* 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](https://support.apple.com/fr-fr/111781).

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.

<callout type="conseil">

Activez ce réglage sur votre téléphone (la FAQ plus bas indique où le trouver), puis parcourez votre site. Tout ce qui glisse, zoome ou bouge encore mérite d’être revu en priorité.

</callout>

## 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.

<table>
<thead>
  <tr>
    <th>
      Effet
    </th>
    
    <th>
      Ce qu’il promet
    </th>
    
    <th>
      Ce qu’il coûte
    </th>
    
    <th>
      Notre avis
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Survol, clic, ouverture d’un menu ou d’un accordéon
    </td>
    
    <td>
      Confirmer l’action, montrer d’où vient le contenu
    </td>
    
    <td>
      Presque rien s’il reste bref et écrit en CSS
    </td>
    
    <td>
      Oui
    </td>
  </tr>
  
  <tr>
    <td>
      Indicateur de chargement après un clic
    </td>
    
    <td>
      Faire patienter
    </td>
    
    <td>
      Presque rien
    </td>
    
    <td>
      Oui
    </td>
  </tr>
  
  <tr>
    <td>
      Apparitions au défilement
    </td>
    
    <td>
      Une page qui « vit »
    </td>
    
    <td>
      LCP retardé si le premier écran attend l’effet ; contenu invisible si le script échoue
    </td>
    
    <td>
      Avec parcimonie, jamais sur le premier écran
    </td>
  </tr>
  
  <tr>
    <td>
      Parallaxe
    </td>
    
    <td>
      De la profondeur
    </td>
    
    <td>
      Vertiges possibles ; scripts qui suivent le défilement
    </td>
    
    <td>
      À éviter, ou à couper avec le réglage
    </td>
  </tr>
  
  <tr>
    <td>
      Défilement imposé (molette « lissée » par un script, défilement par sections)
    </td>
    
    <td>
      Une mise en scène
    </td>
    
    <td>
      Le visiteur ne maîtrise plus sa lecture ; scripts sur le fil principal
    </td>
    
    <td>
      À éviter
    </td>
  </tr>
  
  <tr>
    <td>
      Carrousel automatique
    </td>
    
    <td>
      Plusieurs messages au même endroit
    </td>
    
    <td>
      On ne voit que la diapositive du moment ; pause obligatoire
    </td>
    
    <td>
      Des blocs fixes, plutôt
    </td>
  </tr>
  
  <tr>
    <td>
      Bandeau défilant de logos ou d’actualités
    </td>
    
    <td>
      Du mouvement en continu
    </td>
    
    <td>
      Distraction ; pause obligatoire au-delà de cinq secondes
    </td>
    
    <td>
      Une liste fixe
    </td>
  </tr>
  
  <tr>
    <td>
      Vidéo de fond en lecture automatique
    </td>
    
    <td>
      Une ambiance
    </td>
    
    <td>
      Poids ; pause obligatoire au-delà de cinq secondes
    </td>
    
    <td>
      À éviter
    </td>
  </tr>
  
  <tr>
    <td>
      Écran de chargement animé
    </td>
    
    <td>
      Habiller l’attente
    </td>
    
    <td>
      Retarde l’affichage de toute la page
    </td>
    
    <td>
      Non
    </td>
  </tr>
</tbody>
</table>

Si un carrousel s’impose malgré tout, le guide du W3C pour [un carrousel accessible](https://www.w3.org/WAI/ARIA/apg/patterns/carousel/) 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](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/CSS_JavaScript_animation_performance) 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`](https://web.dev/articles/animations-guide), 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](https://developer.chrome.com/docs/css-ui/scroll-driven-animations), 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](https://web.dev/articles/replace-gifs-with-videos). 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](https://ecoresponsable.numerique.gouv.fr/publications/referentiel-general-ecoconception/) (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](https://studiofogg.fr/journal/maquette-prototype-design-system-etapes-du-webdesign) ; 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](https://studiofogg.fr/services/webdesign-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.

## Sitemap

See the full [sitemap](https://studiofogg.fr/sitemap.md) for all pages.