Headless WordPress : un front sur mesure, pour qui ?

Le principe : WordPress d’un côté, l’affichage de l’autre

Dans un site WordPress classique, le même logiciel fait tout. Il stocke vos contenus, vous donne l’administration pour les modifier, et fabrique les pages que voient vos visiteurs grâce au thème.

En headless, littéralement « sans tête », on sépare les rôles. WordPress ne sert plus qu’à saisir et ranger les contenus : c’est la partie arrière, ou back-end. L’affichage, la partie avant ou front-end, devient une application à part, développée sur mesure. Elle va chercher les contenus dans WordPress et construit les pages.

Les deux parties communiquent par une API, c’est-à-dire une porte d’accès prévue pour les programmes plutôt que pour les humains :

• L’API REST, intégrée à WordPress : elle fournit les articles, pages, catégories et médias dans un format que les applications savent lire (le JSON).
• GraphQL, avec l’extension WPGraphQL, toujours maintenue : l’application demande exactement les informations dont elle a besoin, en une seule requête.

Le front-end est souvent construit avec un outil de développement JavaScript comme Next.js, Nuxt ou Astro. Il peut produire les pages à l’avance (pages statiques) ou à la demande, sur un serveur.

Ce que le headless apporte

Un affichage entièrement libre

Le front-end n’est plus limité par ce que permet un thème. Chaque page, chaque animation, chaque parcours est conçu pour votre activité et votre image. C’est tout l’intérêt d’un front sur mesure.

De bonnes performances, si le front est bien construit

Des pages préparées à l’avance et servies par un réseau de diffusion de contenu (CDN) s’affichent vite. Mais la vitesse n’a rien d’automatique : un front-end chargé de JavaScript peut être plus lent qu’un bon thème classique. Ce qui compte reste ce que mesurent les Core Web Vitals chez vos vrais visiteurs.

Une surface d’attaque réduite

L’administration WordPress peut être placée sur une autre adresse, protégée, voire fermée au public. Le site visible, lui, ne fait que lire des contenus. Cela réduit les risques sans les supprimer : WordPress et ses extensions doivent toujours être mis à jour.

Un même contenu pour plusieurs supports

Un contenu saisi une seule fois dans WordPress peut alimenter le site, une application mobile, un écran en magasin ou un autre logiciel de l’entreprise.

Les limites à connaître avant de se lancer

• Deux systèmes à héberger et à entretenir. WordPress d’un côté, l’application d’affichage de l’autre, chacun avec ses mises à jour et sa surveillance.
• Beaucoup d’extensions ne marchent plus telles quelles. Tout ce qu’une extension affiche sur le site public doit être repris dans le front-end : balises de référencement, formulaires, bandeau cookies, constructeur de pages, boutique.
• L’aperçu avant publication demande du travail. Voir un brouillon tel qu’il apparaîtra en ligne n’est plus automatique : il faut le développer.
• Moins d’autonomie pour la mise en page. Les réglages visuels de l’éditeur de blocs (couleurs, styles par taille d’écran, mises en page) n’apparaissent sur le site que si le front-end sait les interpréter.
• Un coût plus élevé. Plus de développement au départ, et un développeur nécessaire pour faire évoluer l’affichage ensuite.

WordPress classique ou headless : le comparatif

Comment se construit un site headless

1. Organiser les contenus dans WordPress : types de contenus, champs sur mesure (par exemple avec Advanced Custom Fields), catégories.
2. Ouvrir l’API : API REST intégrée ou WPGraphQL, en n’exposant que ce qui doit l’être.
3. Développer le front-end : modèles de pages, navigation, formulaires, recherche.
4. Relier la publication à l’affichage : quand vous publiez dans WordPress, le site doit se mettre à jour (pages régénérées, cache vidé).
5. Mettre en place l’aperçu des brouillons, avec un accès protégé.
6. Reprendre le référencement dans le front-end (voir plus bas).
7. Héberger, sauvegarder et surveiller les deux parties.

Sécuriser l’administration en headless

• Placer WordPress sur un sous-domaine dédié, exclu de Google, et le protéger : mot de passe, voire restriction par adresse IP si votre équipe travaille depuis des lieux fixes.
• Activer la double authentification pour tous les comptes.
• N’exposer dans l’API que les contenus publics, et protéger les accès utilisés pour l’aperçu.
• Garder WordPress, le thème et les extensions à jour, même si personne ne voit l’administration.
• Sauvegarder les deux parties, et pas seulement la base de données.

Headless et référencement

Google sait exécuter du JavaScript, mais des pages produites côté serveur ou préparées à l’avance sont lues plus sûrement et s’affichent plus vite. Le front-end doit aussi produire lui-même tout ce qu’une extension SEO faisait dans un WordPress classique :

• le titre et la description de chaque page ;
• l’adresse de référence de chaque page (balise canonique) ;
• le plan du site (sitemap) ;
• les données structurées, par exemple la fiche LocalBusiness d’une entreprise locale avec son adresse et ses horaires ;
• les redirections, si des adresses changent.

Si vous utilisez Yoast SEO, l’extension complémentaire WPGraphQL Yoast SEO Addon permet de récupérer ses réglages dans le front-end. Pour le référencement local, rien ne change sur le fond : une page claire par service et par zone, une fiche d’établissement Google à jour, et les mêmes coordonnées partout.

Pour qui le headless vaut-il le coup ?

Il se justifie surtout quand :

• les mêmes contenus doivent alimenter plusieurs supports (site, application, écrans) ;
• l’affichage ou les interactions voulues sont impossibles avec un thème ;
• le site reçoit beaucoup de visites et les exigences de vitesse sont fortes ;
• une équipe ou un prestataire peut entretenir deux systèmes dans la durée.

Il est rarement utile pour un site vitrine de quelques pages. Un thème WordPress développé sur mesure, léger, apporte l’essentiel : un design propre à votre marque, un code limité à ce qui sert et de bonnes performances, tout en gardant l’aperçu, les extensions et votre autonomie dans l’éditeur. Pour une TPE ou une PME, c’est souvent le bon compromis. Découvrez comment nous construisons nos sites internet.

Questions fréquentes

Qu’est-ce que le headless WordPress, en une phrase ?

C’est un site où WordPress sert uniquement à gérer les contenus, tandis que l’affichage est assuré par une application développée à part, qui récupère ces contenus par une API.

Un site headless est-il forcément plus rapide ?

Non. Il peut l’être si le front-end est bien conçu et bien hébergé. Un thème classique léger, avec un bon cache, peut obtenir d’aussi bons résultats.

Mes extensions fonctionneront-elles encore ?

Celles qui travaillent dans l’administration, oui (champs sur mesure, gestion des utilisateurs, sauvegardes). Celles qui affichent quelque chose sur le site public doivent être reprises dans le front-end ou remplacées.

Peut-on passer d’un site classique à un site headless sans perdre son référencement ?

Oui, avec les mêmes précautions qu’une refonte de site WordPress : garder les adresses qui marchent, rediriger les autres en 301, reprendre titres, descriptions et données structurées, et surveiller la Search Console après la mise en ligne.

Vous vous demandez si votre projet justifie un site headless ou un thème sur mesure ? Parlons-en.