Choisir un générateur de sites statiques pour les projets JavaScript
Choisir le mauvais générateur de sites statiques vous coûte plus que du temps. Il façonne votre modèle de déploiement, la complexité de votre runtime et la quantité de JavaScript qui finit devant vos utilisateurs. En 2026, les options ont considérablement mûri, mais elles ont également divergé de manière significative. Voici comment réfléchir à ce choix.
Points clés à retenir
- Les véritables SSG comme Astro 6 et Eleventy 3 diffèrent fondamentalement des frameworks hybrides comme Next.js, Nuxt et SvelteKit — les considérer comme interchangeables conduit à de mauvais choix architecturaux.
- Astro 6 est l’un des choix par défaut les plus solides pour les sites à fort contenu en 2026, grâce à son architecture en îlots et au support de composants multi-frameworks.
- L’API Adapter stable de Next.js 16 et OpenNext rendent le déploiement multi-plateforme viable, mais le framework reste plus complexe qu’Astro ou Eleventy, même pour une sortie majoritairement statique.
- Commencez par les exigences de rendu et d’infrastructure, et non par la popularité du framework, lors du choix d’un outil.
Tous les « SSG » ne sont pas équivalents
Avant de comparer les outils, il est utile de bien préciser les catégories. Astro 6 et Eleventy 3 sont véritablement des générateurs de sites statiques axés sur le contenu. Ils sont conçus pour produire un minimum de JavaScript en sortie et privilégient le rendu au moment de la build.
Next.js 16, Nuxt 4 et SvelteKit sont des frameworks hybrides qui prennent en charge la sortie statique, mais ne sont pas principalement des SSG. Leur modèle mental par défaut concerne les applications rendues côté serveur ou déployées sur l’edge. Les utiliser uniquement pour la génération statique est valable, mais vous transportez toujours bien plus de complexité de framework qu’avec un véritable outil orienté « static-first ».
Considérer ces deux groupes comme équivalents conduit à de mauvaises décisions.
Analyse framework par framework
Astro 6 est devenu l’un des choix les plus solides pour les sites à fort contenu et les portails de documentation. Son architecture en îlots livre zéro JavaScript par défaut, avec une interactivité optionnelle par composant. Astro 6 prend en charge les composants React, Vue, Svelte et Solid dans un même projet. Si votre principale préoccupation est la performance du contenu et que vous souhaitez une flexibilité de framework, Astro est la recommandation la plus claire en 2026.
Eleventy 3 reste le bon outil lorsque vous voulez simplicité et contrôle sans surcoût de framework. Il prend en charge plusieurs langages de templating, possède des temps de build rapides et produit un HTML propre. Eleventy 3 a ajouté un support ESM complet et la configuration asynchrone. Il n’est pas obsolète — il est délibérément minimaliste, ce qui correspond exactement aux besoins de certains projets.
Next.js 16 a introduit une API Adapter stable qui améliore significativement la prise en charge du déploiement multi-plateforme, y compris OpenNext, qui permet de déployer Next.js sur Cloudflare, AWS Lambda et d’autres runtimes non-Vercel. Si votre équipe maîtrise React et que le projet implique un mélange de pages statiques, de routes API et de composants serveur, Next.js reste l’option la plus capable. Soyez simplement lucide : vous utilisez un framework complet, et non un SSG pur.
Nuxt 4 apporte les mêmes capacités hybrides à l’écosystème Vue. Sa génération statique via nuxt generate est solide, et il s’intègre proprement aux plateformes CMS headless. Pour les équipes Vue qui construisent des sites marketing ou des applications orientées contenu pouvant nécessiter des fonctionnalités serveur plus tard, Nuxt 4 est le choix naturel.
SvelteKit avec adapter-static fonctionne bien pour les équipes Svelte construisant des sites majoritairement statiques. L’adaptateur produit une sortie entièrement statique, mais le framework suppose un modèle « server-first », donc certaines fonctionnalités nécessitent des contournements en mode purement statique. C’est un bon choix lorsque l’équipe connaît déjà Svelte et que le projet est léger.
Gatsby existe toujours et reçoit des mises à jour suite à l’acquisition par Netlify, mais la dynamique d’écosystème qui en faisait le SSG React par défaut s’est largement déplacée vers Astro et Next.js. La couche de données GraphQL de Gatsby reste utile pour les maillages de contenu complexes, mais ce n’est plus le point de départ évident pour les nouveaux projets statiques React.
Docusaurus est le choix par défaut pragmatique pour les sites de documentation soutenus par de grandes équipes ou des projets open source. Basé sur React, maintenu par Meta, il gère le versioning, l’i18n et la recherche prêts à l’emploi. Pour un développeur solo ou une petite équipe construisant une documentation, le thème Starlight d’Astro est une alternative plus légère à considérer.
Un cadre de décision simple
| Type de projet | Outil recommandé |
|---|---|
| Site de contenu, blog, marketing | Astro 6 |
| Portail de documentation | Docusaurus ou Astro Starlight |
| Site low-JS, piloté par templates | Eleventy 3 |
| Application React avec besoins statiques + serveur | Next.js 16 + OpenNext |
| Application Vue avec rendu hybride | Nuxt 4 |
| Équipe Svelte, site léger | SvelteKit adapter-static |
Discover how at OpenReplay.com.
Considérations de déploiement et d’hébergement
Votre cible d’hébergement compte. Astro et Eleventy produisent des fichiers statiques bruts qui se déploient partout — Netlify, Cloudflare Pages, S3 ou votre propre serveur. Next.js 16 avec OpenNext s’est considérablement amélioré pour les déploiements non-Vercel, mais il nécessite toujours plus de configuration qu’une véritable sortie statique. Nuxt et SvelteKit présentent des considérations similaires.
Si vous ciblez Cloudflare Pages ou avez besoin d’un déploiement edge-natif, Astro et Eleventy vous offrent le moins de friction. Si vous avez besoin d’ISR ou de composants serveur, vous êtes en territoire de framework hybride, quel que soit votre choix.
La bonne question à se poser en premier
Ne commencez pas par « quel framework est le plus populaire ». Commencez par : De combien de JavaScript ce projet a-t-il réellement besoin au runtime, et quelle quantité d’infrastructure serveur suis-je prêt à gérer ?
Si la réponse est « JavaScript minimal, pas de serveur », Astro 6 ou Eleventy 3 vous serviront mieux qu’un framework hybride configuré pour agir comme tel. Si la réponse implique des routes dynamiques, de l’authentification ou de la personnalisation, Next.js 16 ou Nuxt 4 vous offrent de la marge pour évoluer sans changer d’outils en cours de projet.
Conclusion
Le meilleur SSG pour votre projet est celui qui correspond à vos exigences de rendu — pas celui qui a le plus d’étoiles GitHub. Soyez honnête sur la quantité d’interactivité, de logique serveur et d’infrastructure dont votre projet a réellement besoin, puis choisissez l’outil le plus léger qui répond à ces besoins. Un site de contenu n’a pas besoin d’un framework hybride, et une application avec authentification et routes dynamiques ne sera pas bien servie par un SSG pur. Adaptez l’outil à la charge de travail, et vous vous épargnerez des mois de lutte contre votre propre stack.
FAQ
Globalement oui. Le contenu Markdown et MDX se transfère généralement avec un minimum de modifications puisqu'Astro prend en charge les deux nativement. Le travail le plus difficile consiste à remplacer la couche de données GraphQL de Gatsby par les content collections d'Astro et à réécrire les composants de page React en composants Astro. Prévoyez une migration progressive plutôt qu'une réécriture unique, et attendez-vous à ce que le remplacement des plugins prenne le plus de temps.
Généralement oui. Next.js apporte plus de complexité de framework même lorsque vous n'avez besoin que d'une sortie principalement statique, ce qui signifie des bundles plus volumineux et plus de complexité de build que nécessaire. Pour un blog ou un site marketing sans authentification, routes dynamiques ou logique serveur, Astro 6 ou Eleventy 3 produiront généralement des sites plus rapides avec moins de configuration et un déploiement plus simple.
Oui. Astro prend en charge directement les composants React, Vue, Svelte et Solid, et vous pouvez insérer des composants React existants dans les pages Astro avec un minimum de modifications. Le changement clé consiste à décider quels composants nécessitent une hydratation côté client en utilisant des directives comme client:load ou client:visible. Les composants sans ces directives sont rendus en HTML statique au moment de la build, livrant zéro JavaScript.
Moins qu'avant. L'API Adapter stable de Next.js 16 et des projets comme OpenNext ont rendu pratique le déploiement de Next.js sur Cloudflare, AWS Lambda et d'autres runtimes. Cela dit, certaines fonctionnalités spécifiques à Vercel fonctionnent toujours mieux sur Vercel. Si l'indépendance vis-à-vis de la plateforme est une exigence stricte, évaluez votre utilisation des fonctionnalités par rapport au support des adaptateurs dès le début du projet.
Gain Debugging Superpowers
Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.
