La philosophie PE : commencer par le HTML

L’amélioration progressive (PE) consiste à créer une expérience utilisable avec le seul HTML, puis à ajouter des couches de CSS pour la présentation et de JavaScript pour l’interactivité. Chaque couche enrichit la précédente ; aucune n’est nécessaire au fonctionnement de la page.

HTML est la couche la plus résiliente. Il s’analyse partiellement lorsqu’il est malformé, ignore les balises qu’il ne comprend pas et fonctionne sans scripts ni feuilles de style. En revanche, l’absence d’un fichier CSS dégrade l’apparence, tandis qu’un paquet JS défectueux peut rendre une page inutilisable.

Contenu (HTML), présentation (CSS), comportement (JS). Un bouton d’envoi est un véritable <button type="submit"> : le formulaire est envoyé même si JS échoue. CSS le rend esthétique ; JS peut intercepter l’envoi pour utiliser AJAX, mais le HTML sous-jacent garantit l’action.

Les réseaux se déconnectent. Les scripts ne se chargent pas. Les utilisateurs désactivent JS. Les connexions lentes expirent avant l’arrivée des paquets. Une page conçue selon PE se dégrade progressivement dans chacun de ces cas : l’utilisateur peut toujours lire, naviguer et envoyer des formulaires avec le seul HTML.

Les pages qui affichent un HTML utilisable avant le chargement des scripts obtiennent un premier affichage de contenu plus rapide, un temps avant interaction plus court et de meilleurs scores pour les indicateurs essentiels du Web. Le navigateur affiche un contenu utile sans attendre l’initialisation de JS.

Les véritables éléments HTML intègrent l’accessibilité. <button> peut être activé au clavier ; <input type="email"> fait apparaître le clavier virtuel approprié ; <a> est annoncé comme un lien par les lecteurs d’écran. PE fournit gratuitement des comportements accessibles par défaut.

Les robots des moteurs de recherche préfèrent le HTML qu’ils peuvent analyser sans exécuter JavaScript. Les pages conçues selon PE sont entièrement indexées sans exécution de JS ; les pages reposant uniquement sur SPA dépendent de la prise en charge des scripts par le robot et omettent souvent du contenu.

Les applications monopages effectuent tout le rendu côté client et cessent complètement de fonctionner lorsque JS échoue. PE fait l’inverse : le serveur produit un HTML complet, puis JS ajoute des améliorations comme le préchargement, les mises à jour optimistes ou la modification sur place, sans jamais prendre en charge la fonctionnalité de base.

Remix, les composants serveur de Next.js, SvelteKit et Astro privilégient tous le HTML rendu côté serveur avec une amélioration progressive par JS. Choisir un tel cadre logiciel fait de PE la solution la plus naturelle.

Les interfaces utilisateur très interactives (éditeurs collaboratifs, applications de dessin, jeux en temps réel) ne peuvent pas réellement exister sans JS. La « solution de repli sans JS » de telles applications peut être un mode statique en lecture seule — mieux que rien, mais forcément limité. Soyez honnête quant à ce compromis.

« Faites-le fonctionner, puis rendez-le esthétique, puis rendez-le rapide. » Commencez par créer le formulaire HTML ; vérifiez qu’il fonctionne avec curl. Ajoutez CSS pour la mise en page. Ajoutez JS pour la validation sur place, les mises à jour optimistes ou l’envoi avec AJAX. Chaque couche est facultative ; l’ensemble compose une excellente expérience pour tout le monde.

L’amélioration progressive commence par un HTML sémantique qui fonctionne sans CSS ni JS, puis ajoute des couches de CSS pour la présentation et de JS pour l’interactivité. Chaque couche est facultative ; la page se dégrade progressivement en cas de défaillance. PE offre des avantages en matière de performance, d’accessibilité, de référencement et de résilience, au prix d’un travail de conception initial plus important pour les applications très interactives.