WordPress headless, l'architecture expliquée

Ce que veut dire headless

Un WordPress classique gère vos contenus et les affiche aussi, à travers son thème et en langage PHP. En headless, on ne garde que l'administration, cette interface sécurisée où l'on rédige et organise les contenus, et le site public est développé séparément avec un framework qui vient chercher ces contenus par l'API de WordPress.

Les rédacteurs continuent à travailler exactement comme avant, tandis que les visiteurs découvrent un site rapide sans jamais passer par WordPress.

Pourquoi WordPress, et quand choisir le headless

WordPress fait tourner plus de 40 % des sites web, et c'est justement ce qui en fait une très bonne base pour une architecture headless. Énormément de développeurs, de webmasters et de gestionnaires de contenu le connaissent déjà, ce qui rend la prise en main immédiate pour les équipes et donc le recrutement bien plus simple.

Avec Advanced Custom Fields (ACF), WordPress permet aussi de construire une expérience d'édition sur mesure. Quand on conçoit à la fois l'interface et le produit, on sait qui va écrire dans l'administration et ce dont ces personnes ont besoin au quotidien, on leur prépare exactement les champs utiles, et on les ajuste au fil de leurs retours, de la même manière que l'on ajuste des détails d'un site public en fonction du comportement des visiteurs.

Le headless prend tout son sens pour un site important, avec une équipe de rédaction habituée à WordPress, des exigences fortes de performance ou de sécurité, un design sur mesure, ou des contenus qui alimentent aussi une application. Pour un petit site vitrine, c'est souvent plus que nécessaire, et un site sur mesure avec une interface de gestion simple fait très bien le travail pour un budget bien moindre.

L'architecture

C'est l'architecture que j'ai mise en place pour une grande organisation, avec un site public en Angular rendu côté serveur. Angular n'est qu'un choix parmi d'autres, puisque Next.js, Nuxt, SvelteKit ou Astro font le même travail, pourvu que le framework sache générer les pages côté serveur.

Le chemin d'un contenu, de la rédaction jusqu'au visiteur, se fait en cinq étapes :

1. Les rédacteurs écrivent dans l'administration WordPress, avec leurs champs, leurs catégories et leurs réglages SEO, comme ils en ont l'habitude.
2. WordPress expose ces contenus par son API REST, ou en GraphQL avec l'extension WPGraphQL.
3. Le site public va chercher les contenus et génère des pages HTML complètes côté serveur (SSR), si bien que Google, les aperçus de liens et les visiteurs reçoivent immédiatement une page entière.
4. Un cache conserve ces pages, et, dès qu'un contenu change, WordPress prévient le serveur par un webhook qui appelle un service Node.js pour supprimer et régénérer la page concernée.
5. Le visiteur reçoit une page rapide, servie sans jamais solliciter WordPress.

Ce qu'il faut préparer dans WordPress

C'est la partie que l'on sous-estime le plus souvent, parce que tout ce que le thème faisait seul doit maintenant passer par l'API, et WordPress doit être configuré pour l'exposer correctement :

• L'API REST est active par défaut depuis WordPress 4.7, mais elle doit être ouverte à vos propres contenus, avec show_in_rest sur chaque custom post type et chaque taxonomie, tout en décidant de ce qui reste privé.
• Les champs d'ACF n'apparaissent pas d'eux-mêmes dans l'API. Depuis ACF 5.11, chaque groupe de champs peut être exposé avec l'option « Show in REST API », et ses données arrivent alors sous la clé acf.
• Le SEO se branche sur l'extension que les rédacteurs utilisent déjà. Yoast SEO renvoie les balises de chaque page dans l'API (yoast_head_json) et Rank Math propose un mode « Headless CMS Support », ce qui permet au site de reprendre les titres, les descriptions et les données structurées saisis dans WordPress.
• Le sitemap est un cas à part. Celui que génère WordPress reflète la structure de ses propres pages, pas celle du site public construit avec le framework, dont les adresses et l'organisation peuvent être différentes, et il doit donc être généré côté serveur par le site lui-même.
• Les menus ont bien leurs routes dans l'API, mais elles demandent une authentification, et un petit endpoint personnalisé les rend lisibles par le site.
• La prévisualisation des brouillons est le point le plus délicat, mais elle se règle. Le bouton « Prévisualiser » pointe encore vers le thème, et une fonction PHP personnalisée doit le rediriger vers le site, avec un token qui l'autorise à lire les contenus non publiés.
• Le cache doit être prévenu de chaque changement, grâce à un hook sur l'enregistrement des contenus qui appelle le site.
• L'ancien affichage ne sert plus, et ses pages doivent être redirigées ou fermées pour que Google ne trouve pas deux fois le même contenu.
• L'administration peut vivre sur un autre serveur que le site public, dans un réseau protégé comme votre réseau interne ou une DMZ. Comme le site va chercher les contenus côté serveur, seul le site public est exposé sur internet, et WordPress n'a jamais besoin d'être accessible au public.

Cela représente un peu de PHP, sans que ce soit énorme, avec quelques endpoints, quelques filtres et deux ou trois hooks, mais c'est un travail à prévoir dès le départ du projet.

Ce que vous gagnez, et ce que ça demande

Vos questions

Qu'est-ce qu'un CMS headless ?

C'est un CMS dont on ne garde que l'administration, l'interface où l'on gère les contenus. Ceux-ci sortent par une API, et un site développé à part les met en page.

WordPress headless est-il bon pour le SEO ?

Oui, à condition que le site soit rendu côté serveur. Avec Yoast SEO ou Rank Math, les titres, descriptions et données structurées saisis dans WordPress sont repris par le site, qui génère aussi son propre sitemap.

API REST ou GraphQL ?

L'API REST est intégrée à WordPress et suffit souvent. WPGraphQL, une extension, permet de demander exactement les champs voulus en une seule requête, ce qui devient utile quand les pages assemblent beaucoup de contenus différents.

Peut-on garder la prévisualisation des brouillons ?

Oui, même si c'est le point le plus délicat. Une fonction PHP personnalisée redirige le bouton « Prévisualiser » vers le site, qui lit le brouillon grâce à un token.

Faut-il beaucoup de PHP ?

Non, quelques endpoints, quelques filtres et deux ou trois hooks suffisent en général, mais ils font partie du projet dès le départ.

Combien coûte un WordPress headless ?

Chaque projet a son budget, selon le nombre de contenus, le design et les intégrations, mais une architecture headless représente en général plusieurs mois de développement, entre la préparation de WordPress, le site public et son infrastructure. C'est un budget important, à la mesure des projets d'envergure.

Vous construisez un produit et cherchez quelqu'un pour en concevoir l'architecture ? Vous pouvez découvrir mon parcours sur LinkedIn, ou m'écrire directement à lexy@eyn.art. Et quand votre produit sera prêt à rencontrer son public, je peux aussi dessiner son logo et son identité visuelle.