WordPress headless : est-ce aussi compliqué qu’il y paraît ?

Un WordPress headless est un WordPress utilisé uniquement comme back-office : les équipes y rédigent et organisent les contenus comme d’habitude, mais le site visible est une application séparée (Next.js, Astro, Nuxt, une application mobile…) qui récupère ces contenus par l’API REST intégrée à WordPress depuis la version 4.7, ou par GraphQL. Techniquement, ce n’est pas si compliqué pour une équipe de développeurs. Ce qui est plus exigeant, c’est d’exploiter deux applications au lieu d’une : aperçu des contenus, extensions à remplacer côté affichage, hébergement et maintenance en double. C’est pertinent pour des projets multicanaux ou très exigeants, rarement pour un site vitrine.

Le terme « headless » (sans tête) revient souvent dans les projets web, avec la promesse de sites plus rapides, plus sûrs et plus modernes. On explique ici ce qu’est un CMS headless en général, en quoi il diffère d’un CMS traditionnel ou découplé, comment WordPress fonctionne dans ce mode, comment le connecter à un front-end React, ses vrais avantages et inconvénients, les alternatives, et surtout les projets pour lesquels il vaut la peine.

• Qu’est-ce qu’un CMS headless ?
• CMS traditionnel, découplé ou headless : quelle différence ?
• Comment WordPress fonctionne-t-il en mode headless ?
• Quels sont les avantages d’un WordPress headless ?
• Quels sont ses inconvénients ?
• Comment créer un WordPress headless avec React ?
• Un WordPress headless est-il plus rapide et plus sûr ?
• Quelles alternatives à WordPress en headless ?
• Pour quels projets choisir le headless ?
• Questions fréquentes
• Sources

Qu’est-ce qu’un CMS headless ?

Un CMS (système de gestion de contenu) traditionnel fait deux choses : il stocke et organise les contenus (le « corps ») et il les met en forme pour les afficher sur un site (la « tête »). Dans WordPress classique, les deux sont liés : le back-office enregistre les pages dans la base de données, et le thème PHP génère les pages HTML que voit le visiteur. Si la notion de CMS ne vous est pas familière, notre article qu’est-ce qu’un système de gestion de contenu pose les bases.

Un CMS headless supprime la tête. Il se limite à stocker les contenus et à les exposer par une API, c’est-à-dire une interface qui permet à d’autres logiciels de les demander et de les recevoir dans un format structuré (généralement du JSON). C’est ensuite à une ou plusieurs applications distinctes (site web, application mobile, borne, écran en magasin, assistant vocal) de décider comment les afficher. On parle parfois de « contenu en tant que service ». L’idée est simple : on écrit un contenu une fois, et on le diffuse partout.

Ce principe applique un vieux précepte de l’informatique, la séparation des responsabilités : le CMS gère le contenu, le front-end gère l’affichage, et l’API sert de contrat entre les deux. Pour comprendre ce qu’est une API, voir notre article qu’est-ce qu’une API et comment peut-elle aider votre entreprise.

CMS traditionnel, découplé ou headless : quelle différence ?

Les termes « découplé » et « headless » sont souvent employés l’un pour l’autre. La nuance est la suivante : un CMS découplé garde une couche de présentation, mais la sépare du back-office et la nourrit par API ; un CMS headless n’a pas de couche de présentation du tout, il est d’abord une API. En pratique, un WordPress utilisé en headless est techniquement un CMS découplé, puisque son thème existe toujours, simplement on ne s’en sert plus pour le site public.

	CMS traditionnel (couplé)	CMS découplé	CMS headless
Affichage	Intégré (thème)	Séparé mais prévu par l’éditeur	Entièrement à construire
Diffusion des contenus	Pages web	Pages web et API	API uniquement, vers tous les canaux
Autonomie des rédacteurs	Forte (aperçu, mise en page)	Variable	Plus limitée sans développement spécifique
Compétences requises	Faibles à moyennes	Moyennes à fortes	Fortes (développement front-end)
Exemples	WordPress classique	WordPress avec front-end séparé	Strapi, Contentful, Cockpit

Comment WordPress fonctionne-t-il en mode headless ?

WordPress n’a pas été conçu comme un CMS headless, mais il s’y prête bien. Depuis WordPress 4.7 (décembre 2016), le cœur intègre les points d’accès de l’API REST pour les articles, les commentaires, les catégories et étiquettes, les utilisateurs, les métadonnées et les réglages. Chaque point d’accès (endpoint) ressemble à une adresse web classique et répond à des requêtes HTTP : GET pour lire, POST pour créer, etc. Par exemple :

GET https://exemple.fr/wp-json/wp/v2/posts?per_page=5
GET https://exemple.fr/wp-json/wp/v2/pages?slug=contact

La première requête renvoie les cinq derniers articles publiés, avec leur titre, leur contenu, leur date et leur image, au format JSON. Le front-end n’a plus qu’à les mettre en forme. Pour les contenus publics, aucune authentification n’est nécessaire. Pour écrire ou lire des contenus privés depuis une application externe, WordPress propose depuis la version 5.6 les mots de passe d’application, générés depuis le profil de l’utilisateur.

Beaucoup de projets headless utilisent aussi GraphQL, un langage de requête qui permet au front-end de demander exactement les champs dont il a besoin, en une seule requête. Sous WordPress, c’est l’extension WPGraphQL qui l’apporte ; elle est en cours d’intégration comme extension « canonique » de WordPress.org, c’est-à-dire soutenue par le projet WordPress lui-même.

Ce qui reste côté WordPress : l’interface d’administration que connaissent vos équipes, l’éditeur de blocs, la médiathèque, les rôles utilisateurs, les types de contenus personnalisés et les champs (par exemple avec ACF, à condition de les exposer dans l’API). Il suffit d’une pile PHP et MySQL ou MariaDB classique pour le faire tourner.

Un point technique à anticiper : les contenus rédigés dans l’éditeur de blocs arrivent dans l’API sous forme de HTML déjà assemblé (le champ content.rendered). Le front-end doit donc soit styler ce HTML, soit découper les blocs pour les transformer en composants. C’est un choix à faire dès le début du projet, car il conditionne la liberté laissée aux rédacteurs dans la mise en page des articles.

Quels sont les avantages d’un WordPress headless ?

• Une liberté totale sur le front-end : l’interface n’est plus contrainte par la logique des thèmes. Les développeurs utilisent leurs outils (React, Vue, Svelte, Angular) et peuvent changer de framework plus tard sans toucher aux contenus. Notre comparatif Angular, React ou Vue aide à choisir.
• Des contenus diffusés sur plusieurs canaux : le même article ou la même fiche produit alimente le site, l’application mobile, une newsletter ou un écran en magasin, sans copier-coller entre plusieurs outils, donc sans risque d’incohérence.
• Tout le contenu au même endroit : textes, images, vidéos, données structurées sont centralisés et modifiables en un point.
• Des rédacteurs qui gardent leurs habitudes : c’est l’argument principal de WordPress face aux CMS headless natifs. Vos équipes ne changent pas d’outil.
• Des performances potentiellement excellentes : si le front-end génère des pages statiques ou mises en cache, servies depuis un CDN, elles s’affichent très vite, quelle que soit la charge sur WordPress.
• Une surface d’attaque réduite : le site public ne fait plus tourner WordPress. L’administration peut être placée sur un sous-domaine protégé (restriction d’adresses IP, authentification supplémentaire), et un pic de trafic ou une attaque sur le site public ne touche pas directement le back-office.
• Des refontes plus légères : on peut refaire entièrement l’interface sans migrer les contenus.

Quels sont ses inconvénients ?

Le headless n’est pas une solution miracle. Voici ce qu’on oublie souvent de dire avant de lancer un projet :

• Deux applications à héberger et à maintenir : WordPress d’un côté, le front-end de l’autre, chacun avec ses mises à jour, sa sécurité, son hébergement. Le coût de maintenance augmente.
• L’aperçu des contenus n’est plus natif : le bouton « Prévisualiser » de WordPress affiche le thème, pas votre front-end. Il faut développer un mode aperçu spécifique, sinon les rédacteurs publient à l’aveugle.
• Une partie des extensions ne sert plus : tout ce qui agit sur l’affichage (constructeurs de pages, formulaires de contact, commentaires, recherche, extensions SEO qui gèrent les balises meta, sitemaps) doit être recréé ou relié au front-end. Certaines extensions exposent leurs données dans l’API, d’autres non.
• Des compétences de développement indispensables : un changement de mise en page qui se faisait dans l’éditeur demande désormais l’intervention d’un développeur. Les équipes non techniques perdent de l’autonomie sur la présentation.
• Un référencement à construire : si les pages sont rendues uniquement dans le navigateur (application monopage), les moteurs de recherche et les outils d’IA voient d’abord une page vide. Il faut un rendu côté serveur ou une génération statique, des balises meta, un sitemap, des redirections : rien n’est automatique.
• Un coût initial plus élevé : on développe une application front-end complète au lieu d’un thème.

Comment créer un WordPress headless avec React ?

React, bibliothèque JavaScript créée par Facebook (aujourd’hui Meta) et maintenue avec sa communauté, est le choix le plus courant pour le front-end d’un WordPress headless. C’est d’ailleurs avec des composants React que sont construits les blocs de l’éditeur de WordPress. Voici les grandes étapes, pour une équipe qui maîtrise JavaScript.

1. Préparer WordPress : activez les permaliens, vérifiez que vos types de contenus personnalisés et vos champs sont bien exposés dans l’API (option show_in_rest), installez WPGraphQL si vous choisissez GraphQL, et placez l’administration sur un sous-domaine (par exemple admin.exemple.fr).
2. Installer l’environnement : Node.js et npm, un éditeur de code (Visual Studio Code par exemple) et Git pour la gestion des versions.
3. Créer le projet front-end avec un framework : la documentation officielle de React recommande désormais de démarrer une nouvelle application avec un framework, en premier lieu Next.js, ou React Router associé à Vite. Pour un site éditorial, un framework comme Astro, orienté contenu, est aussi une option solide.
4. Récupérer les contenus : avec fetch natif (ou une bibliothèque comme Axios), appelez l’API REST ou GraphQL et transformez les données en pages.
5. Choisir le mode de rendu : génération statique au moment du déploiement, rendu côté serveur à chaque visite, ou un mélange (pages statiques régénérées périodiquement). C’est ce choix qui détermine la vitesse et la qualité du référencement.
6. Mettre en place l’aperçu et la republication : un mode aperçu pour les brouillons, et un déclencheur (webhook) qui reconstruit les pages concernées quand un contenu est publié dans WordPress.
7. Déployer : WordPress sur un hébergement PHP classique, le front-end sur un hébergement adapté à votre framework, et tester les formulaires, le SEO et les redirections avant la mise en ligne.

Un exemple minimal de récupération des articles, dans un composant serveur Next.js :

export default async function Blog() {
  const res = await fetch("https://admin.exemple.fr/wp-json/wp/v2/posts?per_page=5");
  const posts = await res.json();
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title.rendered}</li>
      ))}
    </ul>
  );
}

Il existe de nombreux tutoriels pour aller plus loin. Si les étapes vous paraissent lourdes, c’est un bon indicateur : un projet headless se pilote avec des développeurs, pas en autonomie. Notre équipe accompagne ce type de projet dans le cadre du développement d’applications web sur mesure.

Un WordPress headless est-il plus rapide et plus sûr ?

Il peut l’être, mais ce n’est pas automatique. La vitesse vient du mode de rendu : des pages générées à l’avance et servies depuis un CDN sont très rapides. À l’inverse, une application React lourde, rendue uniquement dans le navigateur et qui interroge l’API à chaque visite, peut être plus lente qu’un WordPress classique bien optimisé avec un bon thème et un cache. Ce principe de pages pré-générées est au cœur de l’approche décrite dans notre article sur l’architecture Jamstack.

Côté sécurité, séparer le site public de l’administration réduit clairement l’exposition. Mais WordPress reste en ligne, avec son API, ses extensions et ses comptes : il doit être mis à jour et protégé exactement comme un WordPress classique. Le headless déplace une partie des risques, il ne les supprime pas.

Quelles alternatives à WordPress en headless ?

Si vous partez de zéro et n’avez pas d’équipe habituée à WordPress, un CMS pensé dès l’origine pour le headless peut être plus adapté :

• Strapi : CMS headless open source écrit en TypeScript, que l’on héberge soi-même, avec une interface de modélisation des contenus très souple.
• Contentful : plateforme en mode SaaS, hébergée par l’éditeur, pensée pour la diffusion multicanale, avec des offres qui varient selon l’usage.
• Cockpit : CMS headless open source léger, adapté aux structures de contenu simples mais flexibles.

Le bon choix dépend moins de la technologie que de vos équipes : qui rédige, qui développe, qui maintient. Garder WordPress a un intérêt fort quand vos rédacteurs l’utilisent déjà ou que votre site existant contient des années de contenus.

Pour quels projets choisir le headless ?

Le headless se justifie quand au moins une de ces conditions est réunie :

• les mêmes contenus doivent alimenter plusieurs supports (site, application mobile, écrans, partenaires) ;
• l’interface demande une expérience très interactive, proche d’une application, difficile à obtenir avec un thème ;
• le site doit encaisser de fortes pointes de trafic, et des pages statiques servies par un CDN sont la meilleure réponse ;
• vous disposez d’une équipe de développement (interne ou prestataire) pour faire vivre le front-end dans la durée.

À qui ça ne sert pas : un site vitrine de quelques pages, un blog d’entreprise, une petite boutique en ligne, ou toute structure qui veut modifier ses pages elle-même sans développeur. Dans ces cas, un WordPress classique bien construit, avec un thème léger et un bon cache, sera plus rapide à livrer, moins cher à maintenir et tout aussi performant pour les visiteurs.

Questions fréquentes

Que veut dire « headless » ?

« Sans tête » : la « tête » désigne la partie qui affiche le site aux visiteurs. Un CMS headless ne gère que les contenus et les fournit par une API ; l’affichage est confié à une ou plusieurs applications séparées.

Peut-on passer un site WordPress existant en headless ?

Oui, les contenus restent en place et l’API REST est déjà disponible. Il faut en revanche développer tout le front-end, recréer les fonctions assurées par les extensions d’affichage, et soigner les redirections pour ne pas perdre de référencement. C’est l’équivalent d’une refonte complète de l’interface.

Faut-il connaître React pour utiliser un WordPress headless ?

Pour rédiger, non : les contenus se gèrent dans l’administration WordPress habituelle. Pour construire et faire évoluer le front-end, oui, ou un autre framework JavaScript. C’est le principal changement pour une organisation.

Un site headless est-il bien référencé ?

Il peut l’être parfaitement, à condition que les pages soient rendues côté serveur ou générées en HTML statique, avec des balises title et meta description, un sitemap et des URL propres. Une application rendue uniquement dans le navigateur est plus fragile pour le référencement.

WooCommerce peut-il fonctionner en headless ?

Oui, WooCommerce expose ses données par une API REST, et c’est une configuration utilisée pour des boutiques qui veulent une interface très personnalisée. Le panier, le paiement et les comptes clients demandent toutefois un travail de développement important : à réserver aux boutiques qui ont le budget et l’équipe pour le maintenir.

Quelle différence entre headless et Jamstack ?

Le headless décrit la façon de gérer les contenus (un CMS sans affichage, relié par API). Le Jamstack décrit une façon de construire le front-end (des pages pré-générées, servies par un CDN, enrichies en JavaScript). Les deux se combinent souvent : un WordPress headless peut alimenter un site Jamstack, mais un front-end headless peut aussi être rendu à chaque visite par un serveur.

Sources

• WordPress.org : version 4.7 et points d’accès de l’API REST
• WordPress Developer Resources : REST API Handbook
• WordPress Developer Resources : authentification de l’API REST
• Extension WPGraphQL sur WordPress.org
• WordPress Developer Resources : fondamentaux de l’éditeur de blocs
• React : créer une application React
• Strapi
• Contentful
• Cockpit
• WooCommerce REST API Documentation