ISR (Incremental Static Regeneration)
L'essentiel
Imaginez un site e-commerce avec 30 000 fiches produits générées statiquement. Chaque nuit, vous mettez à jour 500 prix. Avec du SSG classique : vous devez rebuilder les 30 000 pages. Durée : 25 minutes. Pendant ce temps, vos anciens prix sont en ligne. Et si quelqu'un modifie un produit en urgence à 14h, c'est encore 25 minutes d'attente. Avec ISR, voilà ce qui se passe : quand un visiteur demande la fiche produit dont le délai de revalidation est écoulé, Next.js lui sert immédiatement l'ancienne version depuis le cache (aucune attente), et en parallèle régénère discrètement la nouvelle version en arrière-plan. Le prochain visiteur voit la version fraîche. Encore mieux avec l'ISR on-demand : votre CMS déclenche un webhook dès qu'un produit est modifié. Next.js invalide uniquement cette page, pas les 29 999 autres. Latence d'invalidation : 1 à 3 secondes. Sans rebuild global. C'est ça l'ISR : la performance du statique avec la fraîcheur du dynamique.
Détails Techniques
L'ISR (Incremental Static Regeneration) est un mécanisme de cache et régénération de pages statiques dans Next.js, fonctionnant selon le principe HTTP stale-while-revalidate (RFC 5861). Il permet de maintenir les avantages du SSG (performances CDN, pas de serveur à chaque requête) tout en garantissant la fraîcheur des données, sans rebuild complet du site. Fonctionnement dans le App Router Next.js 15/16 : **ISR time-based** : exporter une constante `revalidate` au niveau d'un segment (layout.tsx ou page.tsx). ```ts // app/produits/[slug]/page.tsx export const revalidate = 3600 // régénère au plus toutes les heures ``` La première requête après le délai déclenche une régénération en arrière-plan. La requête en cours reçoit le cache stale (jamais de temps d'attente serveur visible). **ISR on-demand** : invalider des pages précises depuis une Server Action, une API Route, ou un webhook. ```ts import { revalidatePath, revalidateTag } from 'next/cache' // Invalider un chemin précis revalidatePath('/produits/[slug]', 'page') // Invalider par tag (granularité fine) revalidateTag('produits-catalogue') ``` Les tags sont posés au niveau du fetch : ```ts const data = await fetch('/api/produits', { next: { tags: ['produits-catalogue'] } }) ``` Différence avec les Pages Router : dans le Pages Router, ISR utilisait `getStaticProps` avec `revalidate`. Dans l'App Router, tout passe par la gestion de cache des Server Components et des directives `revalidate`/`revalidateTag`/`revalidatePath`. Limite technique : l'ISR ne garantit pas la fraîcheur absolue — il y a toujours une fenêtre pendant laquelle des données légèrement obsolètes peuvent être servies. Pour les données nécessitant une fraîcheur absolue (prix bourse, inventaire critique), un composant SSR ou PPR dynamique est plus approprié.
#Définition ISR (Incremental Static Regeneration)
L'ISR (Incremental Static Regeneration) est un mécanisme de cache et régénération de pages statiques dans Next.js, fonctionnant selon le principe HTTP stale-while-revalidate (RFC 5861). Il permet de maintenir les avantages du SSG (performances CDN, pas de serveur à chaque requête) tout en garantissant la fraîcheur des données, sans rebuild complet du site. Pour approfondir, consultez la page service Development Next.js Nehos.
Du point de vue technique, Fonctionnement dans le App Router Next.js 15/16 : ISR time-based : exporter une constante revalidate au niveau d'un segment (layout.tsx ou page.tsx). ts // app/produits/[slug]/page.tsx export const revalidate = 3600 // régénère au plus toutes les heures La première requête après le délai déclenche une régénération en arrière-plan. La requête en cours reçoit le cache stale (jamais de temps d'attente serveur visible). ISR on-demand : invalider des pages précises depuis une Server Action, une API Route, ou un webhook. ts import { revalidatePath, revalidateTag } from 'next/cache' // Invalider un chemin précis revalidatePath('/produits/[slug]', 'page') // Invalider par tag (granularité fine) revalidateTag('produits-catalogue') Les tags sont posés au niveau du fetch : ts const data = await fetch('/api/produits', { next: { tags: ['produits-catalogue'] } }) Différence avec les Pages Router : dans le Pages Router, ISR utilisait getStaticProps avec revalidate. Dans l'App Router, tout passe par la gestion de cache des Server Components et des directives revalidate/revalidateTag/revalidatePath. Limite technique : l'ISR ne garantit pas la fraîcheur absolue — il y a toujours une fenêtre pendant laquelle des données légèrement obsolètes peuvent être servies. Pour les données nécessitant une fraîcheur absolue (prix bourse, inventaire critique), un composant SSR ou PPR dynamique est plus approprié.
La compréhension fine de ISR (Incremental Static Regeneration) différencie les équipes qui livrent des résultats de celles qui accumulent de la dette.
#ISR (Incremental Static Regeneration) expliqué simplement
Imaginez un site e-commerce avec 30 000 fiches produits générées statiquement. Chaque nuit, vous mettez à jour 500 prix. Avec du SSG classique : vous devez rebuilder les 30 000 pages. Durée : 25 minutes. Pendant ce temps, vos anciens prix sont en ligne. Et si quelqu'un modifie un produit en urgence à 14h, c'est encore 25 minutes d'attente.
Avec ISR, voilà ce qui se passe : quand un visiteur demande la fiche produit dont le délai de revalidation est écoulé, Next.js lui sert immédiatement l'ancienne version depuis le cache (aucune attente), et en parallèle régénère discrètement la nouvelle version en arrière-plan. Le prochain visiteur voit la version fraîche.
Encore mieux avec l'ISR on-demand : votre CMS déclenche un webhook dès qu'un produit est modifié. Next.js invalide uniquement cette page, pas les 29 999 autres. Latence d'invalidation : 1 à 3 secondes. Sans rebuild global. C'est ça l'ISR : la performance du statique avec la fraîcheur du dynamique.
Prenez un cas concret : une entreprise de 50 personnes qui accélère sa croissance. C'est la réalité du terrain — loin des définitions académiques.
#Cas d'usage concrets
Catalogue e-commerce 40 000 SKU (ISR time-based + on-demand mixte) — Catalogue mode avec 40 000 fiches produits sur Next.js 16. ISR time-based revalidate=3600 pour les pages catégories. ISR on-demand (webhook Payload CMS) pour les fiches produits modifiées en back-office. Temps de rebuild global éliminé — avant : 38 min de build Vercel à chaque update tarifaire. Après ISR on-demand : invalidation en 2 s sur les seules pages concernées. Infra cost Vercel -62 % (moins de deploys).
Blog media SaaS (ISR time-based revalidate 86400) — Blog technique Nehos hébergé sur Next.js App Router. Articles régénérés toutes les 24h (revalidate=86400). Pages auteur et catégorie toutes les 6h. En cas de correction urgente (typo, lien cassé) : revalidatePath('/blog/[slug]') déclenché depuis l'interface admin Payload en 1 clic. Core Web Vitals maintenus à Lighthouse 98/100 sans aucun serveur SSR permanent.
Page tarifs SaaS (ISR on-demand déclenché par webhook Stripe) — Page /tarifs d'un SaaS B2B mise à jour dynamiquement via webhook Stripe dès qu'un plan est modifié. Tag 'pricing' invalidé en temps réel. Les commerciaux peuvent modifier les prix depuis le dashboard Stripe sans intervention dev, et la page publique est à jour en moins de 3 secondes. Avant : déploiement manuel nécessaire pour chaque modification tarifaire (45 min en moyenne).
#ISR (Incremental Static Regeneration) chez Nehos Groupe
Nehos Groupe applique ce concept au quotidien. Sur les 3 derniers projets impliquant ISR (Incremental Static Regeneration), on a documenté les résultats avec des KPIs précis. Notre service Development Next.js Nehos couvre ce périmètre de A à Z.
La méthode Nehos est documentée sur méthode Performance Core Web Vitals Nehos™. Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. Les résultats mesurés sur nos clients : 62 % est un ordre de grandeur courant. On livre, on mesure, on itère. Pas de slides sans livrable.
#Termes associés
Pour aller plus loin, explorez les termes connexes.
- Next.js
- App Router Next.js
- Partial Prerendering (PPR)
- Server Components React
- Headless Commerce
- Headless CMS
Chaque terme est défini dans notre glossaire avec la même approche : définition technique, vulgarisation, cas concrets et méthode Nehos.
Applications Concrètes
"Catalogue mode avec 40 000 fiches produits sur Next.js 16. ISR time-based revalidate=3600 pour les pages catégories. ISR on-demand (webhook Payload CMS) pour les fiches produits modifiées en back-office. Temps de rebuild global éliminé — avant : 38 min de build Vercel à chaque update tarifaire. Après ISR on-demand : invalidation en 2 s sur les seules pages concernées. Infra cost Vercel -62 % (moins de deploys)."
"Blog technique Nehos hébergé sur Next.js App Router. Articles régénérés toutes les 24h (revalidate=86400). Pages auteur et catégorie toutes les 6h. En cas de correction urgente (typo, lien cassé) : `revalidatePath('/blog/[slug]')` déclenché depuis l'interface admin Payload en 1 clic. Core Web Vitals maintenus à Lighthouse 98/100 sans aucun serveur SSR permanent."
"Page /tarifs d'un SaaS B2B mise à jour dynamiquement via webhook Stripe dès qu'un plan est modifié. Tag 'pricing' invalidé en temps réel. Les commerciaux peuvent modifier les prix depuis le dashboard Stripe sans intervention dev, et la page publique est à jour en moins de 3 secondes. Avant : déploiement manuel nécessaire pour chaque modification tarifaire (45 min en moyenne)."