Statique, dynamique, hybride : architecturer Next.js pour le web

« Rendu statique » ne veut pas dire « site figé ». Cela veut dire qu’une partie du site existe déjà, prête à être servie, avant même qu’un visiteur n’arrive. Cette décision — quoi générer au build, quoi générer à la requête — structure toute l’architecture.

Ce que le build peut figer

Tout ce qui ne dépend pas de la requête a vocation à être pré-rendu : pages de contenu, articles, fiches produits, pages marketing. Les bénéfices sont directs — aucun calcul au moment du clic, un serveur quasi statique, des pages instantanées à servir de n’importe où dans le monde.

export function generateStaticParams() {  return articles.map(({ slug }) => ({ slug }));} // La page devient un fichier généré au build :// /blog/[slug]/index.html, prêt à servir.

Ce qui doit rester dynamique

Les données personnalisées — un panier, un tableau de bord, un contenu propre à chaque visiteur — n’ont pas leur place dans un build figé. Elles passent par des points d’entrée dynamiques, isolés des pages de contenu. Le site hybride sépare les deux mondes au lieu de les mélanger.

Le piège du « tout dynamique »

Quand tout est rendu à la requête, chaque visite paye le coût de calcul, et chaque erreur d’infrastructure devient un problème de performance visible. Le réflexe statique d’abord inverse la charge : on ne paie le dynamique que là où il apporte de la valeur.

Une bonne architecture marketing n’est pas une prouesse technique : c’est une liste de choix qui rendent chaque page triviale à servir.

En pratique, sur ce site

Ce site est statiquement généré de bout en bout : les pages de contenu ne chargent aucun JavaScript client, et les seuls îlots interactifs — recherche, formulaires — sont chargés séparément. Résultat mesurable : un score Lighthouse de 100 sur les pages de contenu.