View Transitions : des transitions de page fluides sans framework

Pendant des années, animer le passage d’une vue à l’autre supposait une bibliothèque dédiée et un surcoût de code. L’API View Transitions déplace ce travail dans le navigateur : elle prend un instantané de l’ancien état, un instantané du nouveau, et interpole entre les deux. Elle existe en deux variantes, l’une pour les applications à page unique, l’autre pour la navigation entre pages, et s’adopte sans risque grâce à une dégradation propre.

#Deux API sous un même nom

Le terme recouvre deux mécanismes proches mais distincts. La transition dans une même page (same-document) s’applique quand le JavaScript modifie le DOM sur place, typiquement dans une application à page unique. La transition entre pages (cross-document) s’applique lors d’une navigation classique d’une URL à une autre, à condition que les deux pages partagent la même origine. Les deux reposent sur le même moteur de rendu et sur les mêmes sélecteurs, ce qui limite ce qu’il faut apprendre.

La bonne nouvelle tient en une ligne : si le navigateur ne sait pas animer, la page se met quand même à jour.

#Animer une transition dans une même page

Le point d’entrée est document.startViewTransition. La fonction reçoit un rappel chargé de modifier le DOM ; le navigateur capture l’écran avant l’appel, exécute le rappel, capture l’écran après, puis anime la bascule. La détection de fonctionnalité suffit à garantir le repli.

function mettreAJourVue(donnees) {
  // remplace le contenu du DOM ici
}

if (!document.startViewTransition) {
  mettreAJourVue(donnees);            // repli : mise a jour sans animation
} else {
  document.startViewTransition(() => mettreAJourVue(donnees));
}

Sans personnalisation, le navigateur applique un fondu enchaîné sur toute la page. C’est déjà utile pour un changement d’onglet, un tri de liste ou l’ouverture d’un panneau, là où une coupure sèche nuisait à la lecture.

#Enchaîner deux pages sans JavaScript

La transition entre pages n’exige aucun script. Elle s’active côté CSS, sur les deux pages concernées, par une règle d’activation. La navigation doit rester dans la même origine ; un lien vers un autre domaine ne déclenche pas de transition.

/* opt-in : transitions entre pages de meme origine */
@view-transition {
  navigation: auto;
}

À partir de là, un simple clic sur un lien interne produit un fondu entre l’ancienne et la nouvelle page, sans bibliothèque de routage ni rendu côté client. Pour un site éditorial ou une boutique en pages classiques, c’est le gain le plus immédiat.

#Faire persister un élément d’une vue à l’autre

L’effet marquant vient du morphing : une image de vignette qui grandit pour devenir l’image d’en-tête de la page suivante, par exemple. Il suffit de donner le même view-transition-name à l’élément de départ et à l’élément d’arrivée. Le navigateur comprend qu’il s’agit du même objet et l’anime d’une position à l’autre.

.carte-article img {
  view-transition-name: visuel-article;
}

::view-transition-old(visuel-article),
::view-transition-new(visuel-article) {
  animation-duration: 300ms;
}

Chaque nom doit être unique dans une vue donnée. Le navigateur génère alors un arbre de pseudo-éléments : ::view-transition-group(), ::view-transition-old() et ::view-transition-new(), que l’on cible en CSS pour ajuster durée, courbe ou trajectoire. La racine de la page porte le nom réservé root, ce qui permet de personnaliser le fondu global.

#Personnaliser l’animation et respecter les préférences

Comme les pseudo-éléments sont animés par des règles CSS ordinaires, tout l’outillage habituel s’applique : animation, @keyframes, délais. La contrepartie est une responsabilité d’accessibilité : une animation trop appuyée gêne une partie des utilisateurs. La requête de préférence prefers-reduced-motion doit couper les transitions pour qui l’a demandé.

@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*),
  ::view-transition-old(*),
  ::view-transition-new(*) {
    animation: none !important;
  }
}

Cette précaution ne coûte presque rien et évite de transformer une amélioration en obstacle. Elle vaut pour toute animation, pas seulement pour View Transitions.

#Un exemple concret : de la liste au détail

Le cas le plus parlant est le passage d’une grille d’articles à la page d’un article. Sur la grille, la vignette porte un nom de transition ; sur la page de détail, l’image d’en-tête porte le même nom. Au clic, le navigateur relie les deux et fait grandir la vignette jusqu’à sa position finale, pendant que le reste de la page se fond. L’utilisateur garde le fil visuel : il voit d’où vient le contenu qu’il consulte, ce qui réduit la charge mentale d’une navigation.

Pour que l’effet reste net, le nom doit être présent sur un seul élément à la fois dans chaque vue. Si plusieurs vignettes partagent le même nom au même instant, le navigateur ne sait plus lequel animer et abandonne la transition. La règle pratique consiste à composer le nom à partir d’un identifiant unique, par exemple le slug de l’article, plutôt qu’une valeur figée réutilisée partout.

#Les pièges à connaître

Trois erreurs reviennent souvent. La première est le nom de transition dupliqué, qui annule silencieusement l’animation. La deuxième tient aux décalages de mise en page : si le contenu se réorganise pendant la capture, l’instantané fige un état intermédiaire et l’animation paraît sauter. Mieux vaut réserver les transitions aux changements où la structure reste stable. La troisième concerne le coût : chaque élément nommé génère ses propres instantanés, et multiplier les noms sur une même vue alourdit le rendu sans bénéfice visible. Quelques éléments clés suffisent presque toujours.

Un dernier réflexe évite bien des déconvenues : une transition ne doit jamais masquer un temps de chargement réel. Si la page suivante attend des données, l’animation se joue sur un écran incomplet et donne une impression de lenteur. L’API habille une navigation déjà prête ; elle ne remplace ni un état de chargement, ni un retour visuel d’attente.

Testée avec ces réflexes, l’API tient ses promesses : elle rend une interface plus lisible sans ajouter de dette, et se retire d’elle-même là où le navigateur ne la suit pas encore.

#État du support et stratégie d’adoption

Les transitions dans une même page ont atteint le statut Baseline en octobre 2025 et fonctionnent sur les principaux navigateurs. Les transitions entre pages sont disponibles sur les navigateurs Chromium et sur Safari récent, tandis que Firefox y travaille encore. Comme l’API se replie proprement, rien n’empêche de l’adopter dès aujourd’hui en amélioration progressive.

#Ce qu’il faut retenir

View Transitions couvre deux besoins avec une même grammaire : animer une mise à jour du DOM dans une application à page unique, et fluidifier la navigation entre pages classiques. La première variante est largement disponible, la seconde progresse vite. Dans les deux cas, l’API se contente d’améliorer l’existant sans le casser, ce qui en fait un candidat idéal pour une adoption prudente : la brancher là où elle apporte de la clarté, la couper là où le mouvement dérange.

#Pour aller plus loin

Documentation de référence, MDN Web Docs : developer.mozilla.org — View Transition API

#À lire aussi sur Mail Studio

• Positionnement d’ancrage CSS : menus, infobulles et popovers sans JavaScript
• Design tokens en CSS : la méthode pour un thème clair/sombre maintenable