J'ai déployé un site marketing le mois dernier qui obtient 100 dans toutes les catégories Lighthouse. JavaScript total envoyé au client : zéro octet. Pas « presque zéro » ou « minimal » -- littéralement rien. Les formulaires fonctionnent, la navigation fonctionne, il y a un bouton de mode sombre, et les transitions de page semblent fluides. Il y a cinq ans, cela aurait nécessité des compromis sérieux. En 2026, la plateforme a rattrapé son retard au point où le zéro-JS n'est pas une limitation -- c'est un choix architectural légitime.

Mais voici ce que la plupart des articles sur l'amélioration progressive se trompent : ce n'est pas une question de purisme ou de haine de JavaScript. Il s'agit de prendre des décisions intentionnelles sur ce qui s'exécute où. Laissez-moi vous montrer comment nous abordons cela chez Social Animal, ce qui a changé en 2026 qui rend le zéro-JS viable pour plus de projets que jamais, et quand vous devriez absolument utiliser du code côté client.

Table des matières

Progressive Enhancement & Sites Zero-JS en 2026

Ce que l'amélioration progressive signifie réellement en 2026

L'amélioration progressive existe depuis le début des années 2000, mais la plupart des développeurs avec lesquels je parle la comprennent mal. Ils pensent que cela signifie « construire d'abord une version HTML médiocre, puis l'améliorer avec JavaScript ». C'est à l'envers.

L'amélioration progressive signifie que votre expérience de base fonctionne. Point. HTML est votre fondation. CSS ajoute la couche visuelle. JavaScript -- si vous en avez besoin -- ajoute l'interactivité par-dessus. Chaque couche est additive. Si une couche échoue, les couches ci-dessous fonctionnent toujours.

En 2026, cette philosophie est devenue plus pratique que jamais parce que les capacités de base de HTML et CSS se sont étendues dramatiquement. Les choses qui nécessitaient JavaScript il y a cinq ans ont désormais des solutions natives de plateforme :

  • Accordéons et widgets de divulgation → <details> et <summary>
  • Modales et boîtes de dialogue → élément <dialog>
  • Validation de formulaire → Constraint Validation API
  • Défilement fluide → scroll-behavior: smooth
  • Mode sombre → @media (prefers-color-scheme) avec des astuces du sélecteur :has()
  • Carrousels → CSS scroll snap avec scrollbar-width
  • Popovers et infobulle → Popover API
  • Positionnement d'ancre → CSS Anchor Positioning
  • Transitions de vue → View Transitions API (Niveau 2 pour multi-documents)

La plateforme web en 2026 n'est pas la plateforme web de 2020. Nous avons eu une expansion massive de ce qui est possible sans scripting.

La plateforme a tout changé

La Popover API

La Popover API a atteint le support cross-navigateur complet en 2024 et maintenant elle est prête pour la production partout où cela compte. Avant cela, chaque infobulle, menu déroulant et notification toast avait besoin de JavaScript. Maintenant :

<button popovertarget="my-menu">Menu</button>
<nav popover id="my-menu">
  <a href="/about">À propos</a>
  <a href="/work">Travail</a>
  <a href="/contact">Contact</a>
</nav>

C'est tout. Cliquez sur le bouton, le popover apparaît. Cliquez à l'extérieur, il se ferme. Appuyez sur Échap, il se ferme. La gestion du focus est gérée. Accessible par défaut. Zéro JavaScript.

CSS Anchor Positioning

C'est celui qui a vraiment ouvert les portes. Positionner une infobulle par rapport à son déclencheur nécessitait auparavant JavaScript pour mesurer les positions du DOM. CSS Anchor Positioning (baseline en 2025, entièrement stable maintenant) le gère de manière déclarative :

.trigger {
  anchor-name: --my-trigger;
}

.tooltip {
  position: fixed;
  position-anchor: --my-trigger;
  top: anchor(bottom);
  left: anchor(center);
  translate: -50% 8px;
}

Combinez ceci avec la Popover API et vous avez des infobulle complètement positionnées et accessibles sans code côté client.

Transitions de vue multi-documents

View Transitions Level 2 est celle qui rend les sites zéro-JS ressentir comme des SPAs. Vous ajoutez une at-rule CSS et soudainement naviguer entre les pages a des transitions animées fluides :

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 0.2s ease;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease;
}

Chrome, Edge et Safari supportent tous cela maintenant. Firefox devrait suivre plus tard cette année. Cette seule fonctionnalité élimine l'une des plus grandes raisons pour lesquelles les équipes choisissaient les SPAs -- la performance perçue grâce aux transitions animées.

Le sélecteur `:has()`

Le sélecteur :has() (parfois appelé le « sélecteur parent ») est stable depuis 2024 et c'est véritablement transformateur pour l'interactivité CSS uniquement :

/* Basculer le mode sombre sans JS */
html:has(#dark-mode:checked) {
  color-scheme: dark;
  --bg: #1a1a2e;
  --text: #eee;
}

Avec une case à cocher cachée et un <label>, vous avez un bouton de basculement du mode sombre fonctionnel. Pas de JavaScript. L'état persiste pendant la session et vous pouvez même le synchroniser avec localStorage via un petit script d'amélioration si vous voulez la persistance entre les visites.

Modèles CSS uniquement qui remplacent JavaScript

Permet-moi de cataloguer les modèles que nous utilisons régulièrement. Je ne parle pas d'art CSS ou de démos de nouveauté -- ce sont des modèles de production que nous livrons aux vrais clients.

Modèle Ancienne approche (JS) Approche 2026 (CSS/HTML) Support navigateur
Menus déroulants Écouteurs d'événements, pièges de focus Popover API + :has() 95%+
Accordéons Basculer les classes, gestion ARIA <details> + ::details-content 96%+
Modales Bibliothèques de pièges de focus, verrouillage du défilement <dialog> + ::backdrop 97%+
Onglets Afficher/masquer les panneaux, onglets ARIA Boutons radio + :has() + scroll-snap 95%+
Carrousels Swiper.js, Flickity scroll-snap + scroll-timeline 93%+
Infobulle Popper.js, Floating UI Popover API + Anchor Positioning 90%+
Validation de formulaire Logique de validation personnalisée Constraint Validation + :user-valid 95%+
Animations de défilement Intersection Observer, GSAP animation-timeline: scroll() 88%+
Basculement de thème localStorage + manipulation du DOM Case à cocher + :has() + color-scheme 96%+
Transitions de page Routage côté client View Transitions multi-documents 85%+

Ce tableau représente probablement 80% des modèles interactifs sur un site marketing typique ou une plateforme de contenu. Tous réalisables sans envoyer un seul kilooctet de JavaScript.

Le modèle d'onglets

Voici un que j'aime particulièrement. Onglets CSS uniquement utilisant des boutons radio :

<div class="tabs">
  <input type="radio" name="tab" id="tab1" checked>
  <label for="tab1">Fonctionnalités</label>
  <input type="radio" name="tab" id="tab2">
  <label for="tab2">Tarification</label>
  <input type="radio" name="tab" id="tab3">
  <label for="tab3">FAQ</label>
  
  <div class="panels">
    <div class="panel" id="panel1">Contenu des fonctionnalités...</div>
    <div class="panel" id="panel2">Contenu de tarification...</div>
    <div class="panel" id="panel3">Contenu FAQ...</div>
  </div>
</div>

.tabs:has(#tab1:checked) .panels { --active: 0; }
.tabs:has(#tab2:checked) .panels { --active: 1; }
.tabs:has(#tab3:checked) .panels { --active: 2; }

.panels {
  display: flex;
  overflow: hidden;
  translate: calc(var(--active) * -100%) 0;
  transition: translate 0.3s ease;
}

.panel {
  min-width: 100%;
}

Basculement d'onglets fluide et animé sans JavaScript. Ajoutez role="tablist" et les attributs ARIA appropriés pour l'accessibilité, et vous avez un composant prêt pour la production.

Progressive Enhancement & Sites Zero-JS en 2026 - architecture

Interactivité en priorité HTML

Au-delà du CSS, HTML lui-même est devenu beaucoup plus capable. Permettez-moi de mettre en évidence les modèles que nous utilisons.

L'élément ``

Je sais que <dialog> existe depuis un moment, mais beaucoup d'équipes utilisent toujours une bibliothèque modale. Ne le faites pas. La boîte de dialogue native gère le piégeage du focus, le verrouillage du défilement, Échap pour fermer, et le pseudo-élément ::backdrop pour les superpositions.

La seule mise en garde : vous avez besoin d'une minuscule quantité de JavaScript pour ouvrir une boîte de dialogue modale (appelant .showModal()). Mais pour l'amélioration progressive, vous pouvez faire du déclencheur un lien vers une page séparée, puis améliorer avec JS si disponible :

<a href="/contact" class="js-dialog-trigger" data-dialog="contact-form">
  Entrez en contact
</a>

<dialog id="contact-form">
  <form method="dialog">
    <!-- champs de formulaire -->
    <button type="submit">Envoyer</button>
  </form>
</dialog>

Sans JavaScript : l'utilisateur navigue vers /contact. Avec JavaScript : la boîte de dialogue s'ouvre en ligne. Les deux fonctionnent. C'est l'amélioration progressive.

Formulaires sans JavaScript

Les formulaires sont le plus grand gain pour les approches zéro-JS. Les formulaires HTML natifs soumettent des données aux serveurs. C'est à ça qu'ils ont été conçus pour servir. Avec les frameworks côté serveur modernes, vous n'avez pas besoin d'appels e.preventDefault() et fetch() :

<form action="/api/contact" method="POST">
  <input type="email" name="email" required>
  <textarea name="message" required minlength="10"></textarea>
  <button type="submit">Envoyer</button>
</form>

Les pseudo-classes :user-valid et :user-invalid (maintenant baseline) vous permettent de styliser les états de validation sans JS, mais seulement après que l'utilisateur a interagi -- plus de bordures rouges au chargement de la page.

input:user-invalid {
  border-color: var(--error);
  outline-color: var(--error);
}

input:user-valid {
  border-color: var(--success);
}

Frameworks côté serveur qui n'envoient pas de JavaScript

Choisir le bon framework est extrêmement important pour l'amélioration progressive. Voici comment les acteurs majeurs se comparent en 2026.

Astro

Astro reste le standard d'or pour les sorties zéro-JS. Il envoie HTML et CSS par défaut, et vous optez pour JavaScript par composant avec les directives client:. Nous l'utilisons beaucoup pour les sites marketing, la documentation et les plateformes riches en contenu -- consultez nos capacités de développement Astro pour plus de détails.

---
// Ce composant n'envoie PAS DE JavaScript
const posts = await fetch('https://api.example.com/posts').then(r => r.json());
---
<ul>
  {posts.map(post => <li><a href={post.url}>{post.title}</a></li>)}
</ul>

Astro 5 (stable depuis début 2025) a ajouté les îles serveur et amélioré les APIs de couche de contenu. Le modèle mental est simple : tout est rendu côté serveur sauf si vous le dites explicitement.

Eleventy (11ty)

Eleventy 3.0 continue à être excellent pour les sites zéro-JS. C'est un pur générateur de site statique -- aucune opinion sur JavaScript côté client. Si vous le voulez, vous l'ajoutez manuellement. Nous l'avons trouvé idéal pour les plus petits sites et les blogs où la simplicité du temps de construction compte.

Next.js avec Server Components

Next.js est intéressant ici. Les Server Components (par défaut dans App Router) n'envoient pas de JavaScript au client. Mais le runtime Next.js lui-même ajoute une charge JavaScript de base pour l'hydratation, le routage et le préchargement. Vous ne pouvez pas arriver à un vrai zéro-JS avec Next.js, mais vous pouvez vous en rapprocher remarquablement pour les applications interactives. Consultez notre travail de développement Next.js -- nous avons poussé cette limite sur plusieurs projets.

SvelteKit

SvelteKit vous permet de désactiver JavaScript par page avec export const csr = false. La sortie est du pur HTML/CSS. C'est un excellent compromis -- vous obtenez l'expérience de développeur des composants Svelte mais pouvez sélectivement désactiver le rendu côté client.

Framework Sortie JS par défaut Zéro-JS possible ? Meilleur pour
Astro 5 0 KB Oui (par défaut) Sites de contenu, marketing
Eleventy 3 0 KB Oui (par défaut) Blogs, docs, sites simples
Next.js 15 ~85-100 KB Non (runtime requis) Applications web, contenu dynamique
SvelteKit 2 ~15-25 KB Oui (opt-out par page) Sites hybrides
Fresh (Deno) 0 KB Oui (architecture île) Projets basés sur Deno
Enhance 0 KB Oui (HTML-first) Sites de composants web

Quand JavaScript zéro est le mauvais choix

Je vous ferais du mal si je parlais seulement de quand le zéro-JS fonctionne. Voici quand ce n'est pas le cas :

Collaboration en temps réel. Si vous construisez quelque chose comme Figma, Google Docs ou une application de chat, vous avez besoin de WebSockets et de gestion d'état côté client. Pas d'échappatoire.

Visualisation de données complexe. D3, Observable Plot ou deck.gl pour les cartes -- ceux-ci ont besoin de JavaScript. Vous pourriez rendre des graphiques statiques en SVG côté serveur (et nous le faisons), mais tout ce qui est interactif a besoin de code côté client.

Éditeurs de texte enrichi. ProseMirror, TipTap, Lexical -- ce sont intrinsèquement des applications côté client. L'amélioration progressive ici signifie fournir un repli <textarea>, ce qui est en fait assez raisonnable.

Recherche côté client. Si vous voulez une recherche instantanée au fur et à mesure de la saisie sans frapper le serveur à chaque frappe, vous avez besoin d'index de recherche côté client (Pagefind, Lunr, Fuse.js). Pagefind vaut la peine d'être souligné spécifiquement -- c'est un index de recherche au temps de construction qui ne charge que ~5 KB initialement.

Flux d'authentification. Les redirections OAuth fonctionnent sans JS, mais l'actualisation de jeton, la gestion de session et les routes protégées côté client nécessitent généralement du scripting.

Lecteurs vidéo/audio. Les lecteurs personnalisés ont besoin de JavaScript. Mais les éléments <video> et <audio> avec les contrôles natifs fonctionnent parfaitement sans.

Le modèle que je recommande : commencer avec le zéro-JS et l'ajouter chirurgicalement là où l'expérience utilisateur le demande véritablement. C'est exactement ce que l'architecture d'île d'Astro permet -- 95% de la page est du HTML statique, et le widget interactif unique obtient l'hydratation.

Benchmarks de performance : JS vs zéro-JS

Nous suivons les performances sur les projets clients. Voici les chiffres réels des sites de production que nous avons construits en 2025-2026.

Métrique SPA React typique Next.js (App Router) Astro (Zéro-JS) Amélioration
Largest Contentful Paint 1.8s 0.9s 0.4s 78% plus rapide
Largest Contentful Paint 2.5s 1.3s 0.6s 76% plus rapide
Temps pour interactif 3.2s 1.8s 0.4s 87% plus rapide
Temps de blocage total 450ms 180ms 0ms réduction de 100%
Taille du transfert JS 280 KB 105 KB 0 KB réduction de 100%
Performance Lighthouse 65-75 85-95 100 --
Taux de passage Core Web Vitals 55% 82% 99% --

Ces chiffres comptent pour les vrais résultats commerciaux. Google a été de plus en plus transparent sur l'impact de CWV sur les classements de recherche. Une étude de 2025 de Searchmetrics a montré que les sites réussissant tous les Core Web Vitals avaient des positions de classement moyennes 24% plus élevées que celles échouant. Et cet écart s'élargit.

Pour nos clients, nous avons vu des améliorations mesurables : une marque e-commerce a vu une augmentation du trafic organique de 15% après avoir migré d'une SPA React vers un magasin basé sur Astro avec hydratation sélective. Leur architecture CMS sans tête est restée la même -- nous avons juste changé la façon dont le frontend consommait et rendait le contenu.

Construire une stratégie d'amélioration progressive

Voici le manuel pratique que nous suivons :

Étape 1 : Auditer votre JavaScript

Avant de construire quelque chose de nouveau, regardez quel JavaScript vous livrez actuellement et demandez-vous : cela a-t-il besoin de s'exécuter sur le client ?

# Moyen rapide de vérifier l'utilisation JS dans Chrome DevTools
# Onglet Coverage → Recharger → Voir combien JS s'exécute réellement

Nous trouvons régulièrement que 40-60% du JavaScript livré ne s'exécute jamais au chargement initial de la page. C'est du code mort, des polyfills inutilisés ou des fonctionnalités qui n'ont pas été déclenchées.

Étape 2 : Catégoriser votre interactivité

Mettez chaque fonctionnalité interactive dans l'une de trois catégories :

  1. Natif de plateforme -- Peut être fait avec HTML/CSS seul (utiliser la plateforme)
  2. Amélioration -- Fonctionne sans JS, mieux avec (amélioration progressive)
  3. Nécessite JS -- Réellement impossible sans code côté client (l'envoyer)

Soyez honnête avec vous-même. La plupart des choses atterrissent dans la catégorie 1 ou 2.

Étape 3 : Choisir le bon framework

Si vous construisez un site de contenu, une documentation, des pages marketing ou un blog -- optez pour Astro ou Eleventy. Ne choisissez pas Next.js pour un site marketing juste parce que votre équipe connaît React. L'inadéquation architecturale vous coûte en performance.

Si vous construisez une application avec une interactivité côté client importante, Next.js ou SvelteKit avec rendu serveur sélectif a plus de sens. Utilisez Server Components là où c'est possible et les composants clients seulement là où c'est nécessaire.

Nous aidons les équipes à prendre exactement ces décisions -- consultez nos capacités ou contactez-nous si vous voulez discuter de votre situation spécifique.

Étape 4 : Tester sans JavaScript

C'est l'étape que tout le monde saute. Désactivez JavaScript dans votre navigateur et naviguez sur votre site. Est-ce que ça fonctionne ? Les utilisateurs peuvent-ils :

  • Lire le contenu ? ✓
  • Naviguer entre les pages ? ✓
  • Soumettre des formulaires ? ✓
  • Accéder à l'information critique ? ✓

Sinon, votre stratégie d'amélioration a des trous.

Architecture du monde réel pour les sites zéro-JS

Permettez-moi de partager une architecture concrète que nous avons utilisée pour plusieurs projets clients :

┌─────────────────────────────────────────┐
│         CDN (Cloudflare)                │
│      Actifs statiques HTML/CSS          │
├─────────────────────────────────────────┤
│       Couche Astro SSG / SSR            │
│  Récupère le contenu au build/requête   │
├─────────────────────────────────────────┤
│          CMS sans tête                  │
│  (Sanity / Storyblok / Payload)         │
├─────────────────────────────────────────┤
│       Service gestionnaire de formulaire │
│   (Cloudflare Workers / Resend)         │
└─────────────────────────────────────────┘

Le contenu vit dans un CMS sans tête. Astro le récupère au temps de construction (ou au temps de requête pour le contenu fréquemment mis à jour). La sortie est du pur HTML et CSS, déployée sur un CDN edge. Les formulaires soumettent à une fonction serverless qui gère la validation et l'envoi d'email.

L'ensemble du frontend n'a pas de JavaScript. Le CMS donne une grande expérience aux éditeurs de contenu. Les formulaires fonctionnent sans code côté client. Les transitions de page utilisent les View Transitions multi-documents. C'est rapide, accessible et résilient.

Pour les sites qui ont besoin d'une interactivité sélective -- disons, un configurateur de produit sur une page -- nous utilisons l'architecture d'île d'Astro pour hydrater juste ce composant. Le reste du site reste statique.

C'est le genre d'architecture que nous construisons régulièrement. Si vous êtes curieux de connaître les tarifs de cette approche, consultez notre page de tarification -- les sites zéro-JS sont généralement plus rapides à construire et moins chers à héberger.

FAQ

L'amélioration progressive est-elle encore pertinente en 2026 ?

Plus pertinente que jamais. Avec 95%+ de support navigateur pour des fonctionnalités comme la Popover API, le CSS :has(), les View Transitions et <dialog>, la plateforme web peut gérer l'interactivité qui nécessitait auparavant JavaScript. L'amélioration progressive n'est pas une philosophie du passé -- c'est une stratégie d'ingénierie pratique qui aboutit à des sites web plus rapides, plus résilients et plus accessibles.

Pouvez-vous construire un site web complet avec zéro JavaScript ?

Absolument. Les sites marketing, les blogs, la documentation, les portefeuilles et même les vitrines e-commerce peuvent être construits sans JavaScript côté client. Les formulaires soumettent nativement, la navigation utilise des liens standard (avec View Transitions pour le polish), et les composants interactifs comme les accordéons, les modales et les infobulle ont tous des solutions HTML/CSS natives. Les seuls sites que vous ne pouvez pas construire sans JS sont les applications en temps réel, les éditeurs de texte enrichi et les visualisations de données complexes.

Comment JavaScript zéro affecte-t-il le SEO ?

Positivement, dans presque tous les cas. Les moteurs de recherche peuvent indexer le contenu HTML instantanément sans attendre l'exécution de JavaScript. Les scores Core Web Vitals s'améliorent dramatiquement -- surtout le Temps de blocage total, qui tombe à zéro. Les systèmes de classement de Google récompensent les pages rapides et accessibles, et les sites zéro-JS atteignent régulièrement des scores Lighthouse plus élevés et de meilleurs taux de réussite CWV.

Quel est le meilleur framework pour les sites zéro-JavaScript en 2026 ?

Astro est le choix le plus solide pour la plupart des projets zéro-JS. Il génère zéro JavaScript par défaut et vous permet d'ajouter l'interactivité côté client par composant si nécessaire. Eleventy est une autre excellente option pour les sites plus simples. Les deux ont des écosystèmes matures, une bonne documentation et des communautés actives. Le choix entre eux dépend généralement de si vous voulez une création basée sur les composants (Astro) ou la simplicité basée sur les modèles (Eleventy).

Les composants interactifs CSS uniquement fonctionnent-ils pour l'accessibilité ?

Les éléments HTML natifs comme <details>, <dialog> et la Popover API sont accessibles par défaut -- ils gèrent la gestion des focus, la navigation au clavier et les sémantiques ARIA automatiquement. Les modèles CSS uniquement utilisant des astuces de case à cocher nécessitent plus de soin : vous devez ajouter les rôles ARIA appropriés et assurer l'opérabilité au clavier. En général, les solutions HTML natives sont plus accessibles que les implémentations JavaScript personnalisées parce que les fournisseurs de navigateur ont fait le travail d'accessibilité pour vous.

Comment les View Transitions fonctionnent-elles sans JavaScript ?

Les View Transitions multi-documents (Niveau 2 de la spécification) fonctionnent entièrement via CSS. Vous ajoutez une règle @view-transition { navigation: auto; } et le navigateur crée automatiquement des transitions animées entre les navigations de page. Vous pouvez personnaliser les animations avec les pseudo-éléments ::view-transition-old() et ::view-transition-new(). Pas de JavaScript requis. Chrome, Edge et Safari supportent cela en 2026, avec le support Firefox attendu bientôt.

Quel pourcentage d'utilisateurs ont JavaScript désactivé ?

Seulement environ 1-2% des utilisateurs désactivent activement JavaScript. Mais ce n'est pas le point. JavaScript échoue pour beaucoup plus d'utilisateurs que cela -- connexions instables, pare-feu d'entreprise, extensions de navigateur, pannes CDN et erreurs d'analyse causent tous des défaillances JS. Le UK Government Digital Service a découvert que 1,1% des utilisateurs n'obtenaient pas les améliorations JavaScript malgré le JS activé. L'amélioration progressive protège tous ces utilisateurs.

Puis-je utiliser un CMS sans tête avec un frontend zéro-JavaScript ?

Oui, et c'est l'une des meilleures combinaisons. Le CMS fournit une excellente expérience d'édition pour les équipes de contenu, tandis que le frontend (construit avec Astro ou Eleventy) consomme le contenu au temps de construction via API et génère du pur HTML/CSS. Le JavaScript du CMS s'exécute dans le navigateur de l'éditeur, pas dans celui de vos visiteurs. Ce découplage vous donne le meilleur des deux mondes : une excellente expérience d'édition et une performance zéro-JS pour les utilisateurs finaux.