Une page produit affichait un tarif de 49 euros alors que le champ ACF correspondant avait été mis à jour à 39 euros dans WordPress plus de deux heures auparavant. Aucune erreur dans la console, aucun log suspect côté serveur : juste un prix qui refusait obstinément de se mettre à jour sur une page pourtant régénérée à intervalle régulier grâce à l’ISR (Incremental Static Regeneration) de Next.js.
Le symptôme touchait spécifiquement les pages à faible trafic, jamais celles consultées plusieurs fois par minute. Ce détail, une fois relevé, a orienté directement vers la cause : un malentendu classique sur le fonctionnement réel de la revalidation temporelle d’ISR.
Symptôme : un contenu à jour dans WordPress, périmé sur le front
La page produit était configurée avec revalidate: 3600 dans getStaticProps, censé déclencher une régénération toutes les heures. Pourtant, plusieurs heures après la mise à jour du prix côté WordPress, la version affichée restait celle d’avant modification, y compris après avoir vidé le cache du navigateur — ce qui excluait d’emblée un problème de cache côté client.
Diagnostic : la revalidation ISR n’est pas un minuteur
Le paramètre revalidate ne déclenche pas une régénération automatique en arrière-plan à intervalle fixe, contrairement à une interprétation courante. Il définit la durée après laquelle la prochaine visite déclenchera une régénération en arrière-plan, tout en continuant de servir la version périmée à ce visiteur précis. Sur une page consultée une fois par jour, l’écart entre la mise à jour du contenu et la première visite suivante peut largement dépasser l’heure configurée — et c’est exactement ce qui s’est produit ici.
Correctif : un webhook de revalidation à la demande
La solution consiste à ne plus dépendre uniquement du délai temporel, mais à déclencher explicitement une revalidation au moment précis de la modification du contenu, via l’API de revalidation à la demande de Next.js (res.revalidate()), introduite dans la version 12.2.
// pages/api/revalidate.js
export default async function handler(req, res) {
if (req.headers['x-webhook-secret'] !== process.env.REVALIDATE_SECRET) {
return res.status(401).json({ message: 'Non autorise' });
}
const { slug } = req.body;
try {
await res.revalidate(`/produits/${slug}`);
return res.json({ revalidated: true });
} catch (err) {
return res.status(500).json({ message: 'Erreur de revalidation' });
}
}Côté WordPress, un hook déclenché à chaque sauvegarde d’un article du type produit appelle ce point d’entrée :
add_action('save_post_produit', function ($post_id) {
if (wp_is_post_revision($post_id)) {
return;
}
$slug = get_post_field('post_name', $post_id);
wp_remote_post('https://front.exemple.fr/api/revalidate', [
'body' => json_encode(['slug' => $slug]),
'headers' => [
'Content-Type' => 'application/json',
'X-Webhook-Secret' => WEBHOOK_SECRET,
],
'timeout' => 5,
]);
});Désormais, la page se régénère dans les secondes qui suivent la publication, indépendamment de son trafic — le paramètre revalidate temporel reste en place comme filet de sécurité, mais n’est plus le seul mécanisme de mise à jour.
Prévention : distinguer les deux rôles de revalidate
- Le
revalidatetemporel protège contre l’oubli d’un webhook, pas contre la lenteur de mise à jour d’une page peu visitée. - Le webhook de revalidation à la demande garantit la fraîcheur au moment exact de la publication, quel que soit le trafic de la page.
- Pour les pages générées à la demande lors de leur première visite (
fallback: 'blocking'), s’assurer qu’aucune version partiellement construite ne soit jamais servie en cas d’erreur pendant la génération.
Un test simple pour vérifier la mise en place
Modifier un contenu, observer que la page se régénère en quelques secondes plutôt qu’à la prochaine visite après l’intervalle configuré, constitue le test le plus direct pour confirmer que le webhook fonctionne réellement — plutôt que de se fier uniquement à la configuration de revalidate, qui peut donner une fausse impression de fraîcheur garantie.
ISR sans webhook de revalidation à la demande, c’est un cache qui se rafraîchit au petit bonheur du trafic. Sur une page rarement visitée, ce petit bonheur peut durer des jours.
En résumé
Ce correctif ne traite pas la configuration des produits ou des tarifs côté Stripe : il porte uniquement sur le mécanisme qui garantit qu’un changement de contenu côté WordPress se répercute réellement, et rapidement, sur le rendu du front Next.js. Un webhook de revalidation à la demande, ajouté au revalidate temporel existant, ferme ce trou une bonne fois pour toutes.
