WordPress headless avec l’API REST et Next.js

WordPress reste l’un des outils d’édition de contenu les plus aboutis, mais son rendu front historique (PHP + thème) n’est pas toujours le bon choix pour une expérience utilisateur moderne. L’approche headless consiste à garder WordPress uniquement comme back-office de contenu et à servir le front avec un framework séparé comme Next.js, connecté via l’API REST ou GraphQL. Voici ce que cette approche apporte réellement, et ses compromis.

Sommaire

1. Qu’est-ce que le WordPress headless
2. L’API REST native de WordPress
3. Consommer l’API depuis Next.js
4. Prévisualisation des brouillons
5. Avantages réels
6. Compromis à connaître

Qu’est-ce que le WordPress headless

Dans une architecture headless, WordPress ne génère plus le HTML final : il sert uniquement de source de contenu, interrogée via une API par une application front totalement séparée. L’équipe éditoriale continue à travailler dans l’interface WordPress habituelle (articles, pages, médias, champs personnalisés), tandis que les visiteurs voient un site généré par Next.js, React ou tout autre framework front.

L’API REST native de WordPress

WordPress expose nativement une API REST complète (/wp-json/wp/v2/) sans plugin supplémentaire : articles, pages, médias, taxonomies et utilisateurs sont accessibles en JSON. Pour des besoins plus complexes (champs ACF, structures personnalisées), des plugins comme Advanced Custom Fields exposent également leurs champs via cette même API REST, ou une extension GraphQL peut être ajoutée pour des requêtes plus précises côté client.

Consommer l’API depuis Next.js

Côté Next.js, un Server Component peut appeler directement l’API WordPress avec fetch, sans exposer cet appel au navigateur : fetch('https://cms.domaine.com/wp-json/wp/v2/posts') puis un rendu du contenu récupéré. La génération statique (generateStaticParams) permet de pré-générer les pages d’articles au build, avec une revalidation périodique (ISR) pour refléter les nouvelles publications sans reconstruire tout le site à chaque fois.

Prévisualisation des brouillons

Un point souvent négligé : l’équipe éditoriale doit pouvoir prévisualiser un brouillon avant publication, ce que WordPress fait nativement en mode couplé mais qui demande une configuration explicite en headless. Le mode preview de Next.js, combiné à un lien de prévisualisation personnalisé généré depuis WordPress (via un plugin ou du code sur mesure), permet de restaurer cette fonctionnalité essentielle pour les rédacteurs.

Avantages réels

Les bénéfices concrets : des performances front nettement supérieures (pages statiques ou mises en cache, sans le poids d’un rendu PHP à chaque requête) ; une liberté totale sur la stack front (React, Next.js, n’importe quelle bibliothèque UI) sans être contraint par l’écosystème de thèmes WordPress ; et une meilleure isolation de sécurité, le back-office WordPress n’étant plus directement exposé au même nom de domaine que le site public.

Compromis à connaître

Cette architecture a un coût réel : deux systèmes à héberger et maintenir au lieu d’un seul, une complexité de déploiement accrue, et la perte de fonctionnalités WordPress qui dépendent du rendu PHP côté serveur (certains plugins Elementor ou de page builder, par exemple, ne fonctionnent pas en headless puisqu’ils génèrent du HTML côté WordPress). Le headless se justifie surtout quand les exigences de performance ou de flexibilité front dépassent ce qu’un thème WordPress classique peut offrir — pas systématiquement.

Chez Any In IT, nous évaluons au cas par cas si une architecture headless apporte un bénéfice réel au projet, plutôt que de l’appliquer par principe : un site vitrine ou un blog classique n’en a souvent pas besoin.