Parmi tous les sujets techniques d’un projet headless, la prévisualisation des brouillons est probablement celui qui cause le plus de frustration éditoriale une fois le projet livré, précisément parce qu’il est rarement évoqué avant. L’équipe technique se concentre sur l’API, l’authentification, la performance, et découvre souvent le problème seulement quand un rédacteur clique pour la première fois sur le bouton « Aperçu ».
Ce bouton, familier à tout utilisateur de WordPress, redirige par défaut vers une URL construite sur le thème actif. Sur un site headless, ce thème n’a souvent plus aucune vocation à afficher quoi que ce soit : le rendu réel se fait ailleurs, sur un frontend Next.js, Nuxt ou Astro totalement indépendant. Résultat : un aperçu cassé, une page blanche, ou pire, un rendu qui ne ressemble en rien au site final.
Pourquoi ce problème est plus profond qu’il n’y paraît
Deux difficultés se superposent. D’abord, il faut rediriger l’aperçu vers la bonne URL, celle du frontend headless. Ensuite, et c’est le plus délicat, il faut permettre à ce frontend d’accéder à un contenu qui n’est pas encore publié, ce qui suppose une authentification ou un mécanisme de contournement du statut de publication, sans pour autant exposer les brouillons à n’importe qui.
Rediriger le bouton Aperçu avec preview_post_link
Le filtre preview_post_link permet de reconstruire dynamiquement l’URL générée par le bouton « Aperçu » dans l’administration. Voici une implémentation qui redirige vers un frontend Next.js, avec un token secret en paramètre de requête :
add_filter( 'preview_post_link', function( $link, $post ) {
$token = wp_create_nonce( 'preview_' . $post->ID );
return add_query_arg(
array(
'preview' => 'true',
'id' => $post->ID,
'token' => $token,
),
'https://frontend.exemple.fr/api/preview'
);
}, 10, 2 );Ce filtre modifie uniquement l’URL affichée dans l’administration ; il ne suffit pas à lui seul, il faut désormais que le frontend sache traiter cette requête de prévisualisation.
Côté frontend : basculer en mode aperçu
Le principe côté frontend : une route dédiée reçoit l’identifiant de l’article et le token, vérifie leur validité auprès de WordPress, puis active un mode « aperçu » qui autorise la lecture d’un contenu non publié pour la durée de la session de navigation.
Sur Next.js Pages Router, ce mécanisme s’appelle le Preview Mode, activé via res.setPreviewData() dans une route API :
// pages/api/preview.js
export default async function handler( req, res ) {
const { id, token } = req.query;
const valide = await verifierToken( id, token );
if ( ! valide ) {
return res.status( 401 ).json( { message: 'Token invalide' } );
}
res.setPreviewData( {} );
res.redirect( `/articles/${ id }?preview=true` );
}Une fois le mode aperçu activé, getStaticProps reçoit un paramètre preview: true, qu’on peut utiliser pour requêter l’article via l’API REST avec une authentification (mot de passe d’application) capable de lire les brouillons, plutôt que via l’appel public standard :
export async function getStaticProps( { params, preview } ) {
const url = preview
? `https://exemple.fr/wp-json/wp/v2/posts/${ params.id }?status=draft`
: `https://exemple.fr/wp-json/wp/v2/posts?slug=${ params.slug }`;
const headers = preview
? { Authorization: `Basic ${ process.env.WP_APP_PASSWORD_B64 }` }
: {};
const reponse = await fetch( url, { headers } );
// ...
}Sécuriser l’accès aux brouillons
Ce point ne doit jamais être négligé : sans vérification stricte du token, n’importe qui pourrait forger une URL et consulter des contenus non encore publiés, potentiellement sensibles (communiqué avant embargo, contenu en cours de correction). Quelques règles à respecter :
- Le nonce ou token généré doit être lié à l’article précis et vérifié côté serveur à chaque requête d’aperçu
- L’authentification utilisée pour lire le brouillon (mot de passe d’application dédié) doit avoir le rôle le plus restreint possible
- Le mode aperçu doit avoir une durée de vie limitée côté frontend, pas une session illimitée
Sur nos cahiers des charges, la prévisualisation des brouillons figure désormais systématiquement comme un point à chiffrer explicitement, au même titre que l’authentification ou la performance. C’est un irritant qui coûte cher en confiance auprès des équipes éditoriales s’il est découvert après la mise en production.
En résumé
La prévisualisation des brouillons en headless n’a rien d’insurmontable techniquement, mais elle demande une réflexion explicite dès la conception du projet : rediriger le bouton « Aperçu » avec preview_post_link, mettre en place une route de vérification côté frontend, et sécuriser l’ensemble avec un token à durée de vie limitée. Le vrai piège n’est pas technique, il est organisationnel : oublier ce sujet jusqu’à ce qu’un rédacteur s’en plaigne en pleine mise en production.
