# Next.js 15 et le cache : ce qui change pour un front WordPress

> Les requêtes fetch ne sont plus mises en cache par défaut dans Next.js 15 : ce que ça implique concrètement pour un site WordPress découplé.

- Auteur : Clément Hadrot
- Publié le : 2025-07-23
- Mis à jour le : 2025-07-23
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/nextjs-15-cache-ce-qui-change-front-wordpress/

## L’essentiel

- Le fetch n'est plus mis en cache automatiquement sans configuration
- Chaque appel à WPGraphQL doit désormais déclarer explicitement son intention
- Les temps de build peuvent légèrement augmenter sans réglage adapté

La montée de version vers Next.js 15 sur un projet de guide culinaire a d'abord semblé anodine : les tests automatisés passaient, le site se construisait sans erreur. Le problème est apparu au premier déploiement en production : les temps de réponse avaient nettement augmenté, et les journaux du serveur WordPress montraient un nombre de requêtes bien plus élevé qu'avant la migration.

La cause tenait en une ligne de changelog facile à survoler : Next.js 15 change le comportement par défaut du cache des appels `fetch`, qui n'est plus mis en cache automatiquement comme c'était le cas dans les versions précédentes.

## Le changement de comportement par défaut

Avant cette version, un appel `fetch` exécuté dans un composant serveur ou un gestionnaire de route était mis en cache par défaut, sauf mention contraire explicite. Depuis Next.js 15, c'est l'inverse : chaque appel `fetch` est traité comme non mis en cache par défaut, et il faut désormais déclarer explicitement l'intention de cache.

```
// Avant : mis en cache implicitement
const donnees = await fetch(URL_WPGRAPHQL, { method: 'POST', body: requete });

// Après Next.js 15 : il faut être explicite
const donnees = await fetch(URL_WPGRAPHQL, {
  method: 'POST',
  body: requete,
  next: { revalidate: 300, tags: ['articles'] },
});
```

## Pourquoi ce changement a du sens malgré la migration douloureuse

Un cache implicite et invisible avait tendance à surprendre les équipes qui ne s'attendaient pas à voir un contenu resservi en cache alors qu'elles pensaient chaque requête toujours fraîche. Rendre ce comportement explicite force à réfléchir, route par route, à la vraie fraîcheur nécessaire, plutôt que de subir un cache appliqué uniformément sans y avoir pensé.

> L'essentiel à retenir : Le fetch n'est plus mis en cache automatiquement sans configuration ; Chaque appel à WPGraphQL doit désormais déclarer explicitement son intention ; Les temps de build peuvent légèrement augmenter sans réglage adapté

## Ce qu'il a fallu revoir sur ce projet

- Chaque appel à WPGraphQL a été audité un par un pour lui attribuer un `revalidate` et des `tags` cohérents avec la nature du contenu demandé.
- Les pages de recettes, peu volatiles, ont reçu une durée de cache généreuse.
- La page d'accueil, qui affiche les publications les plus récentes, a reçu une durée bien plus courte pour rester réactive aux nouvelles publications.

## L'impact sur les temps de build

Sans réglage adapté, une partie des pages auparavant construites une seule fois au build se remettent à interroger WordPress à chaque requête, ce qui augmente la charge sur l'origine et peut ralentir le temps de réponse perçu si aucune stratégie de revalidation n'est explicitement définie. Le correctif ne consiste pas à revenir en arrière, mais à choisir consciemment, requête par requête, entre génération statique, revalidation périodique ou appel dynamique à chaque visite.

> Ce changement de version a eu le mérite de forcer une vraie revue de la stratégie de cache du projet, alors qu'elle reposait jusque-là sur un comportement implicite que personne n'avait vraiment challengé depuis le lancement initial.

## Le rôle des tags dans la revalidation ciblée

Au-delà du simple délai fixé par `revalidate`, associer des `tags` à chaque appel `fetch` permet de déclencher une revalidation ciblée depuis un webhook WordPress, via un appel à `revalidateTag`, sans attendre l'expiration naturelle du délai. Sur ce projet, chaque webhook de publication déclenche désormais la revalidation du seul tag concerné (`articles`, `recettes` ou `ingredients`) plutôt qu'un rechargement global de tout le site, ce qui limite la charge imposée à WordPress au moment de chaque publication.

## Un conseil pour toute migration future

Avant de monter de version sur un projet qui dépend fortement d'appels `fetch` vers une API externe comme WPGraphQL, vérifier systématiquement les notes de version concernant le comportement de cache par défaut. Un changement de ce type ne provoque aucune erreur de compilation : il se manifeste uniquement en production, sous forme de charge supplémentaire sur l'origine, ce qui le rend particulièrement facile à manquer en phase de test.

## En résumé

Next.js 15 ne retire aucune capacité de cache, il en change simplement la philosophie par défaut, du cache implicite vers le cache explicite. Pour un front WordPress, cela signifie revoir chaque appel à l'API comme une décision consciente plutôt qu'un comportement hérité, ce qui, une fois fait, rend la stratégie de fraîcheur du site bien plus lisible qu'auparavant.