Cache Components Next.js 16 en 2026 : use cache, PPR et Questions d'Entretien

Les composants cache de Next.js 16 marquent une rupture fondamentale dans l'architecture des applications React modernes. Depuis mars 2025, cette fonctionnalité stable redéfinit comment les développeurs pensent la performance et le data fetching, en remplaçant progressivement les anciens patterns de cache manual. Comprendre ces mécanismes devient un impératif pour tout développeur React senior, particulièrement lors d'entretiens techniques où les questions sur l'optimisation de performance et les stratégies de cache sont désormais incontournables.

Pourquoi Next.js 16 a remplacé le cache implicite

Le modèle de cache implicite de Next.js 14-15 posait des problèmes de prévisibilité. Un appel fetch dans un Server Component était automatiquement dédupliqué et caché, mais déterminer si une page était statique ou dynamique dépendait des API utilisées. Le débogage du cache nécessitait de comprendre plusieurs couches cachées : le fetch cache, le full-route cache et le router cache.

Next.js 16 supprime ces trois caches implicites. Chaque page se rend dynamiquement à chaque requête sauf si elle est explicitement marquée avec "use cache". L'export revalidate disparaît. unstable_cache est remplacé par la directive "use cache" gérée par le compilateur.

Ce changement échange l'optimisation automatique contre un contrôle explicite. Les performances peuvent initialement baisser pour les applications qui s'appuyaient sur le cache implicite, mais l'expérience de débogage s'améliore considérablement : le contenu caché l'est parce que le code le dit, pas à cause d'heuristiques du framework.

Comment la directive use cache fonctionne à trois niveaux

La directive "use cache" opère à trois niveaux : fichier, composant et fonction. Choisir le bon scope est la décision de cache la plus importante dans Next.js 16.

Le cache au niveau fichier marque chaque export asynchrone d'un fichier comme cacheable. Cela convient aux pages avec un contenu entièrement statique sans données utilisateur.

"use cache"

import { getPricingPlans } from "@/lib/data"

// Entire page is cached as a static shell
export default async function PricingPage() {
  const plans = await getPricingPlans()
  return (
    <section>
      {plans.map((plan) => (
        <PricingCard key={plan.id} plan={plan} />
      ))}
    </section>
  )
}

Le cache au niveau composant met en cache des composants individuels au sein d'une page. Cela active le Partial Pre-Rendering : le composant caché se rend dans le shell statique, tandis que les composants dynamiques arrivent en streaming.

async function ProductRecommendations({ categoryId }: { categoryId: string }) {
  "use cache"
  // categoryId becomes part of the automatic cache key
  const products = await getTopProducts(categoryId)
  return (
    <ul>
      {products.map((p) => (
        <li key={p.id}>{p.name} - {p.price}</li>
      ))}
    </ul>
  )
}

Le cache au niveau fonction cible directement les fonctions de récupération de données. Cela remplace l'ancien pattern unstable_cache.

import { cacheLife } from "next/cache"

export async function getArticleBySlug(slug: string) {
  "use cache"
  cacheLife("hours")
  // slug is automatically included in the cache key
  const article = await db.article.findUnique({ where: { slug } })
  return article
}

Le compilateur génère automatiquement les clés de cache à partir des arguments de fonction. Plus besoin de tableaux keyParts manuels ni de workarounds avec JSON.stringify. Les arguments doivent être sérialisables (chaînes, nombres, objets simples). Passer une instance de classe ou une fonction en argument casse la sérialisation.

Partial Pre-Rendering : Shell statique avec trous dynamiques

Le Partial Pre-Rendering (PPR) était expérimental dans Next.js 14-15. Dans Next.js 16, PPR est stable et intégré directement dans Cache Components via cacheComponents: true dans next.config.ts.

PPR permet à une seule route d'être partiellement statique et partiellement dynamique simultanément. Le shell statique est servi instantanément depuis le CDN. Le contenu dynamique arrive en streaming à mesure que les boundaries <Suspense> se résolvent.

import { Suspense } from "react"
import { UserGreeting } from "@/components/UserGreeting"
import { StaticSidebar } from "@/components/StaticSidebar"
import { RecentActivity } from "@/components/RecentActivity"

export default function DashboardPage() {
  return (
    <div className="grid grid-cols-12 gap-6">
      {/* Cached static shell - served instantly */}
      <StaticSidebar />

      <main className="col-span-9">
        {/* Dynamic - streams in after static shell */}
        <Suspense fallback={<GreetingSkeleton />}>
          <UserGreeting />
        </Suspense>

        {/* Dynamic - streams independently */}
        <Suspense fallback={<ActivitySkeleton />}>
          <RecentActivity />
        </Suspense>
      </main>
    </div>
  )
}

L'arbre de décision de rendu est direct : les composants avec "use cache" font partie du shell statique. Les composants enveloppés dans <Suspense> qui lisent des cookies, headers ou d'autres données spécifiques à la requête sont streamés dynamiquement. Tout le reste se rend au moment de la requête.

Profils cacheLife : remplacer revalidate

L'export revalidate de Next.js 15 disparaît. À sa place, cacheLife() fournit des profils nommés qui contrôlent la durée du cache. Les profils intégrés incluent seconds, minutes, hours, days, weeks et max.

import { cacheLife } from "next/cache"

export async function getExchangeRates() {
  "use cache"
  cacheLife("minutes") // Revalidates every few minutes
  const rates = await fetch("https://api.exchangerate.host/latest")
  return rates.json()
}

export async function getCompanyInfo() {
  "use cache"
  cacheLife("weeks") // Rarely changes
  return db.company.findFirst()
}

Les profils personnalisés se définissent dans next.config.ts :

import type { NextConfig } from "next"

const config: NextConfig = {
  cacheComponents: true,
  cacheLife: {
    // Custom profile for product data
    product: {
      stale: 300,      // Serve stale for 5 minutes
      revalidate: 3600, // Revalidate in background every hour
      expire: 86400,    // Hard expire after 24 hours
    },
  },
}

export default config

Centraliser les profils dans la configuration signifie qu'un seul changement ajuste le cache dans toute l'application. Cela élimine les valeurs revalidate: 3600 éparpillées qui posaient problème dans les bases de code Next.js 15.

Une règle à retenir : cacheLife() ne doit s'exécuter qu'une seule fois par invocation de fonction. Le cache conditionnel est valide uniquement si une seule branche s'exécute :

export async function getProduct(id: string) {
  "use cache"
  const product = await db.product.findUnique({ where: { id } })
  if (!product) {
    // Short cache for missing items (may appear soon)
    cacheLife("minutes")
    return null
  }
  // Longer cache for existing products
  cacheLife("product")
  return product
}

cacheTag pour l'invalidation ciblée

Sans cacheTag(), une fonction cachée ne peut expirer que par le temps. L'invalidation à la demande nécessite de taguer les entrées de cache et d'appeler revalidateTag() dans une Server Action.

import { cacheLife, cacheTag } from "next/cache"

export async function getProductById(id: string) {
  "use cache"
  cacheTag(`product-${id}`, "products")
  cacheLife("days")
  return db.product.findUnique({ where: { id } })
}

"use server"

import { revalidateTag } from "next/cache"

export async function updateProduct(id: string, data: ProductUpdate) {
  await db.product.update({ where: { id }, data })
  // Invalidate this specific product AND the product list
  revalidateTag(`product-${id}`)
  revalidateTag("products")
}

Les tags supportent jusqu'à 256 caractères chacun, avec un maximum de 128 tags par entrée de cache. Une convention pratique : utiliser des tags au niveau entité (product-123) pour les enregistrements individuels et des tags au niveau collection (products) pour les pages de liste.

Sécurité : use cache vs use cache private

La directive "use cache" par défaut crée un cache partagé. Toute combinaison d'arguments produit une entrée de cache qui peut être servie à n'importe quel utilisateur. C'est correct pour les données publiques mais dangereux pour le contenu personnalisé.

"use cache: private" crée un cache par utilisateur qui inclut la session courante dans la clé de cache. Il peut accéder en toute sécurité à cookies() et headers() dans le scope caché.

// WRONG: User data in shared cache - data leak risk
export async function getUserDashboard(userId: string) {
  "use cache"
  return db.user.findUnique({
    where: { id: userId },
    include: { orders: true, preferences: true },
  })
}

// CORRECT: Private cache scoped to the current user
export async function getUserDashboard() {
  "use cache: private"
  cacheLife("minutes")
  const session = await cookies()
  const userId = session.get("userId")?.value
  return db.user.findUnique({
    where: { id: userId },
    include: { orders: true, preferences: true },
  })
}

La troisième variante, "use cache: remote", persiste le cache dans un stockage externe. Dans les environnements serverless (Vercel, AWS Lambda), le cache en mémoire par défaut est perdu lors des cold starts. "use cache: remote" garantit que les entrées de cache survivent entre les instances de fonction.

Une matrice de décision pour les entretiens :

| Directive | Scope | Use When | |-----------|-------|----------| | "use cache" | Shared, all users | Public data: pricing, articles, product catalogs | | "use cache: private" | Per-user session | Personalized data: dashboards, settings, order history | | "use cache: remote" | Shared, external storage | High-traffic data in serverless environments |

Migration de Next.js 15 vers les Cache Components

La migration de unstable_cache vers "use cache" est principalement mécanique mais comporte trois pièges qui reviennent fréquemment en entretien.

Piège 1 : Closures sur des données liées à la requête. Si la fonction cachée référence une valeur du scope englobant qui varie par requête (un header, un cookie, un ID utilisateur), la conversion n'est pas directe. Il faut soit passer cette valeur comme argument explicite, soit utiliser "use cache: private".

Piège 2 : Cache conditionnel. Le code qui wrappait unstable_cache uniquement sous condition nécessite une restructuration. "use cache" est toujours actif une fois appliqué. Il faut déplacer la condition en dehors de la fonction cachée.

Piège 3 : Clés de cache manuelles. unstable_cache nécessitait des tableaux keyParts explicites. Le compilateur "use cache" génère les clés automatiquement à partir des arguments plus un build ID et un hash de fonction. Supprimer la gestion manuelle des clés est l'objectif, mais il faut vérifier que toutes les valeurs différenciant le cache sont bien des paramètres de fonction.

Questions d'entretien : ce que les développeurs seniors se font demander

Ces questions reflètent les patterns d'entretien réels en 2026 pour les postes Next.js seniors. Chacune cible un aspect spécifique des Cache Components.

Q1 : Expliquer le passage du cache implicite au cache explicite dans Next.js 16. Pourquoi le framework a-t-il fait ce changement ?

Next.js 14-15 cachait les appels fetch et les pages implicitement. Déboguer si une page était statique ou dynamique nécessitait de tracer à travers plusieurs couches de cache cachées. Le modèle explicite avec "use cache" rend le cache visible dans le code source. Le compromis : les performances peuvent initialement baisser pour les applications migrant depuis le cache implicite, mais les développeurs gagnent un contrôle total et une prévisibilité complète.

Q2 : Quels sont les trois scopes de "use cache" et quand utiliser chacun ?

Niveau fichier pour les pages entièrement statiques. Niveau composant pour mixer du contenu caché et dynamique au sein d'une page (le pattern PPR). Niveau fonction pour cacher des opérations spécifiques de récupération de données. Le choix du scope détermine la granularité du cache et les limites d'invalidation.

Q3 : Une équipe cache une fonction retournant l'historique des commandes d'un utilisateur avec "use cache". Que se passe-t-il ?

Le cache partagé stocke le résultat clé par les arguments de la fonction. Si la fonction accepte un paramètre userId, différents utilisateurs obtiennent des entrées de cache différentes, mais le cache reste une infrastructure partagée. Si la fonction lit userId depuis cookies() au lieu des paramètres, le build échoue car cookies() est une API runtime interdite dans le scope du cache partagé. La solution : passer à "use cache: private" ou passer l'ID utilisateur comme argument explicite.

Q4 : Comment cacheLife diffère-t-il de l'ancien export revalidate ?

revalidate était un simple nombre (secondes) défini au niveau page ou layout. cacheLife utilise des profils nommés avec trois dimensions : stale (servir du contenu périmé), revalidate (intervalle de rafraîchissement en arrière-plan) et expire (expiration ferme). Les profils sont centralisés dans next.config.ts, donc un seul changement affecte tous les sites d'appel utilisant ce profil.

Q5 : Décrire comment PPR rend une page dashboard avec une sidebar statique et du contenu utilisateur dynamique.

Au build time, Next.js génère un shell statique contenant la sidebar (marquée avec "use cache") et des fallbacks <Suspense> pour les sections dynamiques. À la requête, le CDN sert le shell statique instantanément. Le serveur streame ensuite le contenu dynamique (salutation utilisateur, fil d'activité) dans les boundaries Suspense. L'utilisateur voit le layout immédiatement et le contenu dynamique se remplit progressivement.

Q6 : Que se passe-t-il avec une fonction cachée sans cacheTag() ?

Elle ne peut expirer que par le temps via son profil cacheLife. L'invalidation à la demande via revalidateTag() est impossible. C'est un oubli courant qui se manifeste quand les éditeurs de contenu mettent à jour un enregistrement et s'attendent à un reflet immédiat sur le site. Toute fonction cachée susceptible de nécessiter une invalidation à la demande doit inclure au moins un cacheTag().

Pour plus de questions d'entretien sur le data fetching Next.js, SharpSkill propose des modules de pratique avec des sessions chronométrées et des explications détaillées. Le module Server Actions Next.js couvre les patterns Server Action qui s'associent à revalidateTag.

Checklist pratique pour les Cache Components en production

• Activer cacheComponents: true dans next.config.ts et supprimer les flags experimental.ppr ou experimental.dynamicIO
• Auditer chaque page : ajouter "use cache" aux pages statiques et aux fonctions de récupération de données qui servent du contenu public
• Envelopper tout le contenu dynamique (spécifique à l'utilisateur, au moment de la requête) dans des boundaries <Suspense> avec des fallbacks skeleton pertinents
• Utiliser "use cache: private" pour toute fonction qui accède aux cookies, headers ou retourne des données personnalisées
• Définir des profils cacheLife personnalisés pour les catégories de données courantes (données produit, sessions utilisateur, contenu statique)
• Ajouter cacheTag() à chaque fonction cachée susceptible de nécessiter une invalidation à la demande
• Tester en mode production avec next build && next start car le comportement du cache en next dev diffère significativement
• Surveiller les ratios de cache-hit par page pendant 24 heures avant de déployer sur la page suivante

Conclusion

• Next.js 16 remplace le cache implicite par un "use cache" explicite aux niveaux fichier, composant et fonction
• PPR est désormais stable et par défaut sous cacheComponents: true, délivrant des shells statiques avec du contenu dynamique streamé
• Les profils cacheLife remplacent revalidate avec un contrôle centralisé et tridimensionnel de la durée du cache
• cacheTag + revalidateTag permettent l'invalidation à la demande ; des tags manquants signifient une expiration uniquement basée sur le temps
• "use cache: private" est obligatoire pour les données utilisateur afin de prévenir les fuites de données cross-utilisateur
• Les questions d'entretien en 2026 se concentrent sur le passage de l'implicite à l'explicite, le flux de rendu PPR, la sécurité du cache et les pièges de migration depuis Next.js 15