C’est quoi WordPress headless ? Découpler son site expliqué
WordPress headless désigne une installation où WordPress ne gère plus que le contenu, via son API REST ou GraphQL, pendant qu’un autre outil (Next.js, Nuxt, une application mobile) se charge entièrement de l’affichage — les deux parties communiquent par API plutôt que par les modèles d’affichage intégrés à WordPress.
WordPress headless sépare la gestion du contenu (WordPress) de son affichage (un front-end distinct), les deux communiquant uniquement par API.
C’est quoi WordPress headless, concrètement ?
Dans une installation WordPress classique, le même logiciel gère à la fois le contenu (articles, pages, médias, dans la base de données) et son affichage, via un thème qui génère les pages HTML envoyées au visiteur. En mode headless (littéralement « sans tête »), cette seconde partie est retirée : WordPress ne sert plus qu’à créer et stocker le contenu, exposé via son API REST ou une extension GraphQL, pendant qu’une application complètement séparée se charge de l’afficher.
L’expression vient du modèle client-serveur : la « tête » désigne la couche d’affichage, retirée du duo pour laisser WordPress agir comme un pur fournisseur de contenu, exploitable par n’importe quelle interface capable d’appeler une API — un site web, une application mobile, un écran connecté.
WordPress, qui reste l’interface de rédaction et la base de données du contenu.
Le pont qui transmet le contenu au format JSON, via REST ou GraphQL (avec le plugin WPGraphQL).
L’application séparée (souvent en JavaScript) qui récupère le contenu et l’affiche.
Comment fonctionne une architecture headless ?
Concrètement, l’équipe éditoriale continue de rédiger dans l’administration WordPress habituelle — rien ne change de ce côté. Ce qui change, c’est ce qui se passe ensuite : au lieu qu’un thème WordPress transforme cet article en page HTML, une application front-end distincte interroge l’API au moment où un visiteur demande la page, récupère le contenu au format JSON, puis construit elle-même l’affichage final.
Cette application peut être hébergée sur un serveur complètement différent de celui de WordPress, utiliser un langage de programmation différent, et suivre son propre cycle de mise à jour, indépendant de celui du CMS.
Quelle différence avec un WordPress classique ?
| Critère | WordPress classique | WordPress headless |
|---|---|---|
| Affichage | Géré par un thème WordPress | Géré par une application front-end séparée |
| Éditeurs visuels | Elementor, Gutenberg fonctionnent nativement | Aperçu visuel limité, à reconstruire côté front-end |
| Hébergement | Un seul environnement pour tout le site | Deux environnements distincts à maintenir |
| Vitesse d’affichage | Dépend du thème et du cache | Souvent plus rapide avec un front-end statique ou pré-rendu |
| Compétences requises | Administration WordPress | Administration WordPress + développement front-end |
Quels frameworks front-end utiliser avec WordPress headless ?
Next.js
Le framework React le plus utilisé pour le headless, avec un pré-rendu des pages qui aide au référencement.
Nuxt
L’équivalent basé sur Vue.js, avec les mêmes avantages de rendu côté serveur pour le SEO.
Astro
Orienté vers des sites majoritairement statiques et très rapides, avec du JavaScript ajouté seulement où nécessaire.
Application mobile
Le même contenu WordPress peut alimenter une application iOS ou Android via la même API.
Ces frameworks front-end se déploient le plus souvent sur des plateformes spécialisées plutôt que sur un hébergement WordPress classique : notre article c'est quoi Vercel détaille la plateforme la plus utilisée pour héberger ce type de projet.
Quels cas d’usage justifient le headless ?
- Diffuser le même contenu sur plusieurs supports : site web, application mobile et écran connecté alimentés par la même base WordPress.
- Rechercher une vitesse d’affichage maximale sur un site à très fort trafic, où un front-end pré-rendu réduit le temps de chargement.
- Imposer une interface front-end très spécifique, impossible à obtenir avec un thème WordPress classique, tout en gardant WordPress comme outil de rédaction familier pour les équipes.
Ce que nous observons chez les projets que nous accompagnons
Voici un exemple représentatif de notre pratique, sans donnée client ni chiffre inventé.
Un choix réservé à des besoins précis, pas un standard par défaut
Chez Amari Agency, l’immense majorité des sites WordPress que nous accompagnons restent en mode classique, avec Elementor pour l’édition visuelle : c’est plus simple à maintenir pour une équipe qui n’a pas de développeur front-end dédié. Le headless, nous ne le recommandons que lorsqu’un client a déjà une application mobile ou un besoin de diffusion multi-support clairement identifié — sinon, le gain de vitesse ne compense pas la complexité ajoutée.
Avantages et limites du WordPress headless
Avantages
- Vitesse d’affichage potentiellement supérieure avec un front-end optimisé.
- Un même contenu réutilisable sur plusieurs interfaces (web, mobile, écrans).
- Liberté totale sur la technologie et le design du front-end.
Limites à connaître
- Perte des éditeurs visuels natifs comme Elementor, à recréer côté front-end.
- Deux environnements à héberger et maintenir plutôt qu’un seul.
- Demande des compétences en développement front-end en plus de WordPress.
Quels contenus lire ensuite ?
Ces ressources complètent cette définition sans cibler la même requête :
Questions fréquentes sur WordPress headless
Peut-on utiliser Elementor avec WordPress headless ?
Non, pas dans son usage normal : Elementor génère l’affichage via un thème WordPress, ce que le mode headless retire justement du fonctionnement du site.
WordPress headless est-il plus rapide qu’un WordPress classique ?
Souvent, grâce au pré-rendu des pages par le front-end, mais ce n’est pas automatique : un WordPress classique bien mis en cache peut rester très performant.
Faut-il un développeur pour passer en headless ?
Oui, la mise en place du front-end demande des compétences en développement, contrairement à un WordPress classique administrable sans coder.
Le référencement est-il impacté par le mode headless ?
Pas négativement en soi, à condition que le front-end pré-rende les pages ; un front-end qui charge tout en JavaScript sans rendu serveur peut au contraire nuire au SEO.
Quelle différence entre l’API REST et GraphQL pour le headless ?
L’API REST est native à WordPress ; GraphQL, ajouté via un plugin comme WPGraphQL, permet de ne demander que les champs précis nécessaires, réduisant le volume de données transférées.