SSR, SSG, ISR: comment choisir en pratique avec Next.js
Next.js offre plusieurs stratégies de rendu : SSR pour des pages dynamiques, SSG pour des pages statiques rapides, ISR pour un compromis entre les deux. Comment choisir la bonne approche selon les besoins de votre projet ?
Publié le 7 mai 2026
Next.js: un projet, plusieurs stratégies de rendu
Next.js permet de construire des pages rendues de plusieurs manières. Cette souplesse est puissante, mais elle peut aussi créer de la confusion. SSR, SSG et ISR ne sont pas des options interchangeables : chaque stratégie répond à un compromis entre performance, fraîcheur des données, coût serveur, SEO et complexité de déploiement.
Le choix ne doit pas être dogmatique. Un même projet peut combiner plusieurs stratégies. Une page institutionnelle peut être statique, une fiche produit peut être régénérée, un tableau de bord peut être rendu côté serveur ou côté client selon ses données.
La bonne approche consiste à partir de la page, de son usage et de ses contraintes.
SSG: générer les pages à l’avance
Le SSG, ou Static Site Generation, consiste à produire les pages au moment du build. Le serveur livre ensuite des fichiers statiques. C’est souvent la stratégie la plus rapide, la plus économique et la plus simple à héberger.
Elle convient très bien aux pages dont le contenu change peu : pages de services, articles, documentation, landing pages, pages institutionnelles. Pour le SEO et la performance, c’est une base solide lorsque la fraîcheur en temps réel n’est pas nécessaire.
La limite apparaît lorsque le contenu change souvent ou dépend fortement d’un utilisateur. Dans ce cas, reconstruire tout le site à chaque modification peut devenir peu pratique.
SSR: rendre la page à chaque requête
Le SSR, ou Server-Side Rendering, génère la page au moment où l’utilisateur la demande. Cette approche permet d’utiliser des données fraîches, de personnaliser le contenu et de garder un HTML initial exploitable.
Elle convient aux pages qui dépendent de données dynamiques : résultats de recherche, pages liées à une session, contenus fortement variables, interfaces qui doivent refléter un état récent.
Le coût est plus élevé : chaque requête demande du travail serveur. La performance dépend alors de la qualité de l’infrastructure, du cache, des requêtes de données et du temps de réponse backend.
ISR: régénérer progressivement
L’ISR, ou Incremental Static Regeneration, cherche un compromis. Les pages sont servies comme du statique, mais peuvent être régénérées périodiquement ou à la demande. Cela permet de conserver de bonnes performances tout en mettant à jour le contenu sans rebuild complet permanent.
Cette stratégie est intéressante pour des catalogues, des blogs volumineux, des fiches produit ou des contenus qui doivent rester relativement frais sans exiger du temps réel.
L’ISR demande toutefois un environnement de déploiement compatible. Dans certains contextes d’export statique ou d’hébergement mutualisé, il ne sera pas disponible comme sur une plateforme conçue pour Next.js.
Choisir par type de page, pas par préférence personnelle
La meilleure méthode consiste à classer les pages. Une page d’accueil marketing peut être statique. Une page d’article peut être statique. Une fiche régulièrement mise à jour peut utiliser l’ISR. Une page de compte utilisateur peut nécessiter du SSR ou du rendu client après authentification.
Cette approche page par page évite les excès. Tout rendre côté serveur peut coûter inutilement cher. Tout rendre en statique peut bloquer des besoins dynamiques. Tout rendre côté client peut dégrader le SEO et la performance perçue.
Next.js est précisément utile parce qu’il permet ces arbitrages fins.
Checklist pour choisir entre SSR, SSG et ISR
- Le contenu doit-il être disponible dès le HTML initial ?
- La donnée change-t-elle souvent ?
- La page dépend-elle de l’utilisateur connecté ?
- L’hébergement supporte-t-il le rendu serveur ?
- Le coût serveur est-il acceptable ?
Ne pas oublier la contrainte d’hébergement
Le choix de rendu n’est pas seulement une décision de code. Il dépend aussi de l’endroit où le projet sera déployé. Un export statique impose des contraintes différentes d’un déploiement Node.js ou d’une plateforme serverless compatible avec Next.js.
Pour un site vitrine hébergé sur un serveur mutualisé classique, le SSG peut être parfaitement cohérent. Pour une application avec données dynamiques, il faut prévoir un runtime adapté.
Un mauvais alignement entre stratégie de rendu et hébergement produit souvent des contournements fragiles.
Conclusion: SSR, SSG et ISR sont des outils, pas des dogmes
SSG, SSR et ISR ne sont pas des niveaux de modernité, mais des réponses à des contraintes différentes. Le SSG privilégie la simplicité et la vitesse. Le SSR privilégie la fraîcheur et la personnalisation. L’ISR cherche un équilibre entre les deux.
Le bon choix se fait page par page, en tenant compte du contenu, des utilisateurs, du SEO, de la performance, du coût serveur et de l’hébergement. C’est cette lecture pratique qui permet de construire un projet Next.js cohérent.
