SSG ou ISR : comment gérer un prix ou une offre qui change sur une landing page Next.js

Une landing page en génération statique (SSG, Static Site Generation) est construite une fois, au moment du build, puis servie telle quelle à chaque visiteur : aucun calcul serveur, aucune requête base de données, juste du HTML déjà prêt renvoyé depuis un CDN. C'est le choix le plus rapide et le moins cher à faire tourner — et c'est celui que Next.js recommande par défaut pour une page qui ne dépend pas d'un compte utilisateur. Le problème arrive dès qu'une information affichée sur la page change dans le temps sans qu'un développeur ne retouche le code : un prix qui augmente, un code promo qui tourne chaque semaine, un compte à rebours dont la date de fin approche. Le HTML généré au dernier build reste alors figé jusqu'au prochain déploiement — sauf à choisir la bonne mécanique pour éviter ce décalage.

Pourquoi le statique reste le bon point de départ

Le réflexe « ça change, donc il faut du rendu dynamique » coûte plus cher qu'il n'y paraît. Une page rendue à chaque requête (SSR) recalcule tout le HTML côté serveur à chaque visite, même quand rien n'a changé depuis la précédente — un coût en temps de réponse et en facture serverless que le LCP d'une landing page n'a aucune raison de payer. Lee Breslau, Pei Cao, Li Fan, Graham Phillips et Scott Shenker, dans « Web Caching and Zipf-like Distributions: Evidence and Implications », publié en 1999 dans les actes de la conférence IEEE INFOCOM (voir sur Google Scholar), montrent à partir de traces de proxys web réels que les requêtes vers un même contenu suivent une distribution très inégale : une poignée de pages concentre l'essentiel du trafic, ce qui rend la mise en cache d'un contenu déjà calculé extrêmement rentable en taux de succès. Une landing page de vente illustre exactement ce cas : la page d'accueil et les pages templates sont visitées des milliers de fois pour un contenu qui, l'essentiel du temps, ne change pas d'une visite à l'autre. Payer un calcul serveur à chaque requête pour re-générer un HTML identique à la précédente n'a donc de sens que si une partie réelle du contenu change effectivement — pas par principe.

Le vrai problème : une offre qui change plus vite que les rebuilds

Le SSG pur pose un problème précis, pas une fragilité générale : si le prix ou le code promo est écrit en dur dans le HTML au moment du build, ce HTML reste exact jusqu'au prochain déploiement — qui peut survenir des jours, voire des semaines plus tard. Un visiteur peut alors atterrir sur une page qui affiche encore une offre expirée, un compte à rebours qui indique un temps restant négatif, ou un prix remisé qui ne correspond plus au coupon réellement actif côté paiement. Ce n'est pas qu'un détail technique : Daniel Kahneman, Jack L. Knetsch et Richard Thaler, dans « Fairness as a Constraint on Profit Seeking: Entitlements in the Market », publié en 1986 dans l'American Economic Review (voir sur Google Scholar), montrent par enquête que les acheteurs jugent une transaction « injuste » dès qu'elle s'écarte de ce qu'ils considèrent comme l'accord implicite affiché — un principe qui s'applique directement à un visiteur qui clique sur un bouton d'achat en croyant bénéficier d'une réduction que la page annonçait, avant de découvrir au paiement qu'elle ne s'applique plus. Une offre périmée ne coûte donc pas seulement une conversion ratée : elle abîme la confiance plus durablement qu'un temps de chargement un peu long, précisément parce qu'elle rompt une promesse que la page elle-même a affichée.

Option 1 : ISR (Incremental Static Regeneration)

L'ISR, propre à Next.js, garde les avantages du HTML statique tout en le régénérant automatiquement en arrière-plan après un délai configuré (revalidate). Le principe : la première requête après expiration du délai reçoit encore l'ancienne version statique (aucun visiteur n'attend un recalcul), pendant que Next.js régénère la page en tâche de fond pour que la requête suivante reçoive la version à jour. C'est la bonne option quand le changement vient d'une source externe imprévisible — un prix modifié dans un CMS, un stock qui s'épuise — et qu'un délai de quelques minutes à quelques heures avant mise à jour est acceptable. Deux limites à connaître : la fenêtre entre le changement réel et la régénération reste une zone où l'ancien contenu continue de s'afficher, et un webhook de revalidation à la demande (revalidatePath ou revalidateTag, déclenché depuis l'outil qui modifie le prix) est nécessaire pour supprimer complètement ce délai plutôt que de le réduire.

Option 2 : statique pur + calcul côté client (l'approche de LanderKit)

Quand l'offre suit une règle prévisible plutôt qu'une décision arbitraire — une rotation hebdomadaire sur un cycle fixe, un compte à rebours dont l'échéance est connue à l'avance — une troisième option évite complètement le problème du cache périmé : ne jamais écrire l'offre dans le HTML statique, et la calculer dans le navigateur au montage du composant, à partir de la date du jour et d'une fonction déterministe. C'est le choix que fait LanderKit sur son propre site : le HTML généré au build n'embarque aucune offre périmable, chaque visiteur recalcule l'offre courante depuis l'horloge de son navigateur selon un cycle de semaines défini à l'avance, et le compte à rebours affiché correspond toujours à la vraie fin de fenêtre — jamais à un chiffre figé au moment du build. Le gain : zéro risque de servir une offre expirée, aucun webhook ni tâche de fond à maintenir, un rendu qui reste 100 % statique et compatible avec n'importe quel CDN. La limite symétrique : ça ne fonctionne que si l'offre est calculable par une règle (une date, un cycle), pas si un humain doit pouvoir la changer à la main sans toucher au code — dans ce cas, l'ISR ou un rebuild déclenché reprennent l'avantage.

Option 3 : rebuild déclenché automatiquement

Pour un changement rare et décidé manuellement — une hausse de prix catalogue, un nouveau palier tarifaire — la solution la plus simple reste souvent le rebuild complet, déclenché automatiquement dès qu'un fichier de configuration ou une entrée de CMS change (un deploy hook Vercel appelé depuis l'outil qui héberge le prix, ou tout simplement un commit Git). Le déploiement automatique sur Vercel régénère alors l'intégralité du site en quelques dizaines de secondes à chaque changement, sans complexité supplémentaire côté code. Cette option devient coûteuse si le changement doit se répéter très souvent (plusieurs fois par jour) : chaque rebuild consomme des minutes de build, et le budget de maintenance grimpe en conséquence si le déclencheur tourne en continu.

Comparatif : SSG pur, ISR, statique calculé, rebuild déclenché

Comment choisir pour votre landing page

1. Rien ne change une fois le site en ligne (texte, tarifs fixes, argumentaire) : le SSG pur, sans aucune couche supplémentaire, reste imbattable en simplicité et en vitesse.
2. Le prix ou le stock est piloté depuis un CMS ou une base externe, par une personne qui doit pouvoir le changer sans toucher au code : l'ISR avec revalidation à la demande couvre ce cas proprement.
3. L'offre suit une règle connue à l'avance — rotation programmée, compte à rebours vers une date fixe, tarif qui change à heure ou jour donné : le calcul côté client élimine tout risque de contenu périmé, sans infrastructure supplémentaire.
4. Le changement est rare et décidé manuellement (une hausse de prix annuelle, un nouveau produit) : un rebuild déclenché automatiquement au commit ou au changement de configuration suffit largement.
5. Dans le doute sur un template en production : commencer en SSG pur, puis n'ajouter de l'ISR ou du calcul côté client que le jour où un vrai besoin de fraîcheur apparaît — anticiper cette complexité avant d'en avoir besoin coûte plus cher qu'elle ne rapporte.

Aucune de ces options n'est un compromis bancal : les quatre gardent l'essentiel de ce qui fait la force d'une landing page statique — vitesse de chargement, coût serveur minimal, résilience face au trafic. La différence se joue uniquement sur la façon de faire coexister cette vitesse avec une information qui change dans le temps, et sur l'effort à fournir pour que ce changement n'atteigne jamais un visiteur sous la forme d'une offre expirée. Chaque template LanderKit part de cette base statique, que ce soit le template SaaS & Liste d'attente (démo) ou le template e-commerce mono-produit (démo), à 89 € l'unité ou 229 € pour le pack complet des dix templates — à vous d'ajouter la couche de fraîcheur qui correspond réellement au rythme de vos propres changements de prix.