La Duck Conf 2026 CR - L'impact des architectures front sur l'accessibilité

Lors de la Duck Conf 2026, Gauthier Fiorentino présente un sujet souvent négligé dans le développement web moderne : nos choix d'architecture front**, du** Multi-Page Application (MPA) au Single-Page Application (SPA), ont un impact sur l'expérience utilisateur et l'accessibilité.

Gauthier, fervent défenseur du principe de moindre pouvoir* (Rule of Least Power) et certifié en accessibilité (audit RGAA et qualité web Opquast), nous rappelle que derrière les technologies à la mode se cachent toujours du HTML, du CSS et du JavaScript. Les décisions d'architecture qui en découlent ont un impact direct sur les utilisateurs. Sa quête est de promouvoir un web meilleur.

Le sujet, tiré de son expérience, montre que certains problèmes récurrents dans les applications sont invariablement liés à l'architecture web front-end.

La dérive architecturale et ses conséquences

Historiquement, le web a commencé avec le MPA (Multi-Page Application) de Tim Berners-Lee, basé sur la navigation entre différents documents via des liens hypertexte. L'évolution technique a introduit l'AJAX (permettant de modifier un morceau de page) et, vers 2010, le concept de SPA (Single-Page Application), où toute la page est gérée et modifiée côté client.

Aujourd'hui, les frameworks modernes se sont tournés vers une approche hybride (comme Next, Nuxt), se rapprochant du concept de PESPA (Progressively Enhanced SPA), qui livre du HTML au premier appel, puis grâce au routing côté client, seulement du JS et JSON pour générer les pages suivantes.

Cependant, ces architectures, si elles visent la performance perçue et le confort de développement, introduisent des inconvénients majeurs, en particulier pour l'accessibilité et l'écoconception.

L'accessibilité : un concept fondateur mis à mal par les SPA

L'accessibilité (A11Y) n'est pas un nouveau concept. Le WAI (Web Accessibility Initiative) a été lancé en 1996. Dès 1997, Tim Berners-Lee affirmait que :

“Le pouvoir du Web réside dans son universalité. L'accès par tous, quel que soit le handicap, est un aspect essentiel.”

De plus, l'accessibilité et l'écoconception s'inscrivent dans l'ensemble du numérique responsable, visant à donner accès à l'information au maximum d'individus, qu'ils soient en situation de handicap ou en situation de rupture numérique.

Gauthier a brillamment illustré par des démonstrations l'impact des SPA sur les utilisateurs de lecteurs d'écran* (personnes aveugles) en soulevant trois problèmes critiques :

Problème 1 : Désorientation par perte de focus

Dans une SPA, le navigateur n'est pas informé du changement de page (le routing est géré par JavaScript côté client). Par conséquent, le focus du lecteur d'écran n'est pas remis en haut de la nouvelle page, mais reste là où il était (par exemple, sur le footer). L'utilisateur est désorienté, car il ne reçoit aucune indication que le contenu a changé.
Correctif : Le développeur peut ajouter du code (par exemple, document.body.focus() dans un useEffect en React ou onUpdated en Vue) pour gérer manuellement le focus.

Problème 2 : Manque d'annonce du changement de contenu

Contrairement au MPA, où le navigateur annonce naturellement la nouvelle page, dans une SPA, rien n'indique au lecteur d'écran que le contenu a été mis à jour.
Correctif : Les frameworks proposent des composants spécifiques (comme AppRouterAnnouncer ou NuxtRouteAnnouncer) pour annoncer le changement.

Critique des correctifs

Ces solutions manuelles ne sont pas parfaites pour deux raisons :

• Le développeur choisit l'annonce, ignorant la configuration native du navigateur ou les préférences de l'utilisateur (par exemple, vouloir l'annonce du début et de la fin du chargement).
• Pour corriger les problèmes intrinsèques du framework, le développeur se retrouve à écrire plus de code, contredisant l'idée de simplification du développement promise par le framework.

Problème 3 : Instabilité du chargement progressif

Le chargement progressif des éléments (affichage d'états « busy » ou de spinners) est très déstabilisant pour les utilisateurs souffrant de troubles de l'attention. Il n'existe pas de solution simple, la seule étant d'attendre le chargement complet des données avant d'afficher les éléments, ce qui annule l'avantage de performance perçue.

Le principe de moindre pouvoir* et le coût du JavaScript

Le second pilier de la conférence est le principe de moindre pouvoir* (Rule of Least Power), qui enjoint d'utiliser le langage le moins puissant possible pour la tâche à accomplir.

“Use the least powerful language suitable for expressing information, constraints or programs.”

Moins un langage est puissant (comme le HTML, purement descriptif), plus il est facile d'analyser (analyse de sécurité, fonctionnelle, de contenu) statiquement le code ou le contenu. Les assistants techniques, comme les lecteurs d'écran, fonctionnent ainsi en analysant et en adaptant le contenu HTML. Un langage impératif comme le JavaScript exige d'être exécuté pour en connaître le résultat. C'est pourquoi les frameworks basés sur l'exécution JavaScript côté client (SPA/PESPA) génèrent des applications plus difficiles à analyser et augmentent la complexité à opérer et les risques de défaut.

Le coût caché de l'exécution JavaScript

Les SPA génèrent et exécutent les pages côté client, dans un environnement non maîtrisé : le terminal de l'utilisateur. L'accès à l'information en situation de rupture numérique est affecté. La démarche d'écoconception de service numérique nous amène à réfléchir à l'impact de ce type d'architecture. Rappelons ici que plus de 50 % de l'impact environnemental du numérique en France est lié à la fabrication et à l'usage des terminaux*.

Comme l'a souligné Addy Osmani (Google) en 2019, l'exécution du JavaScript est le coût dominant après le téléchargement.

Gauthier a donc fait une brève étude avec quelques sites en PESPA. Les chiffres qui en résultent sont frappants :

• Le JavaScript spécifique au framework représente environ 35 % des données téléchargées et sert souvent juste à afficher du HTML. Gauthier a cité l'exemple d'un code JavaScript de 1 Mo pour une page HTML de 8 Ko.
• 56 % du temps d'affichage (hors temps d'attente) est consacré à l'exécution de JavaScript qui ne sert qu'à générer du HTML.

Ce temps est perdu. En servant le HTML directement depuis le serveur, on pourrait économiser les 56 % de temps d'exécution du JavaScript. Ces constats mènent à la recommandation de préférer le rendu serveur (Server-Side Rendering - SSR).

Cette expérimentation illustre clairement la loi de Wirth* citée le matin même dans la conférence de Tristan Nitot et Romain Taillade sur ERoom*.

Choisir le bon outil pour le bon usage

La SPA n'est pas « le Mal », mais un outil. Il faut l'utiliser de manière judicieuse :

• La (PE)SPA est pertinente uniquement pour les applications lourdes ou riches pour lesquelles la notion de page est entièrement secondaire, voire inexistante (exemples : éditeur de slides, Drive, application de DAO).
• La (PE)MPA est à privilégier pour les applications légères, sites vitrines, blogs, e-commerce, et même pour les applications à données personnalisées.

La documentation d'Angular confirme que le Client-Side Rendering (CSR) impose des temps de chargement plus longs et une plus grande demande de ressources client, recommandant le SSR pour les sites nécessitant du SEO, les pages e-commerce, les flux d'actualités et même le contenu personnalisé.

Il est aussi à noter que le choix d'une SPA, en s'éloignant des standards présents par défaut dans les MPA, exige une réflexion UX très spécifique, avec, notamment, un focus particulier sur les « personae extrêmes » (sourds, aveugles, etc.).

« Ok, on fait du rendu serveur, mais c'est pas si simple »

Pour tendre vers une architecture PEMPA performante et accessible, Gauthier conseille les pratiques suivantes :

1. Le découpage Domaine / UI (Server / Client) :
   • Séparer clairement les responsabilités : le Domaine (récupération des données et génération du HTML associé) doit être exécuté côté serveur.
   • L'UI (interactivité, APIs navigateur comme matchMedia(), gestion des événements onClick) doit être exécutée côté client.
   • Cette séparation doit être concrète, par exemple en utilisant un Design System comme un outil qui contient uniquement les composants UI.
2. Le choix du meta-framework :
   • Les frameworks comme NextJS créent des rendus côté client, même lorsque le développeur avait prévu un rendu côté serveur.
   • Il est recommandé d'utiliser un framework qui est « MPA first », tel qu'Astro*.
3. Le routing natif :
   • Pour forcer le routing côté serveur et non côté client, il faut se passer des optimisations du framework (ex. : router.push() ou <NextLink>).
   • Il faut revenir aux concepts natifs de navigation du navigateur : utiliser la balise <a> et les APIs natives comme navigation.navigate() ou history.push().

La présentation de Gauthier Fiorentino est un appel à la vigilance : nos choix techniques ont un impact direct sur l'utilisateur. Pour bâtir un web universel, accessible et éco-conçu, il est impératif d'appliquer le principe de moindre pouvoir, de privilégier le rendu côté serveur, et de sélectionner le modèle architectural (MPA ou SPA) de manière critique, en fonction de l'usage spécifique et des besoins des utilisateurs les plus exigeants.

Pour aller plus loin :

Principe du moindre pouvoir* : https://www.w3.org/2001/tag/doc/leastPower.html
Lecteurs d'écran* : https://blog.octo.com/n'ayez-plus-peur-du-lecteur-d'ecran-voiceover-sur-mac
Loi de Wirth* : https://fr.wikipedia.org/wiki/Loi_de_Wirth
ERoom* : https://publication.octo.com/decouvrez-notre-refcard-eroom
Étude ADEME - l'impact du numérique en France* : https://ecoresponsable.numerique.gouv.fr/actualites/actualisation-ademe-impact/
Addy Osmani - The cost of Javascript* : https://youtu.be/X9eRLElSW1c?si=g_y_xay1aRyysC9B
Astro* : https://astro.build/