WordPress Headless : le guide complet (avantages et pièges)

WordPress fait tourner 43% du web. Pas 43% des blogs — 43% de tout le web. Et pourtant, son architecture n’a pas bougé depuis 2003. Un serveur PHP génère chaque page à la volée, la renvoie au navigateur, et recommence à chaque visite. Ça marche. Mais quand le trafic monte, quand les exigences de performance augmentent, quand on veut un frontend moderne — ça coince.

Le headless, c’est une autre approche. On garde WordPress pour ce qu’il fait bien (gérer du contenu), et on confie l’affichage à un framework JavaScript. Deux briques distinctes. Chacune fait son boulot.

Je vis le headless au quotidien. Le site que vous lisez en ce moment tourne sur cette architecture : WordPress en backend, Next.js 16 en frontend, 450 articles migrés, 220 redirections gérées à la main. PageSpeed 96 en mobile, 100 en desktop — les chiffres détaillés arrivent plus bas.

Mais je vais être honnête avec vous dès le départ : le headless n’est pas l’avenir de WordPress. C’est une option. 90% des sites n’en ont pas besoin. Si votre WordPress classique fonctionne bien, gardez-le. Cet article est là pour vous aider à comprendre ce qu’est le headless, quand il a du sens, et surtout — ce que personne ne vous dit sur ce qu’il faut reconstruire de zéro.

Parce qu’on va être clair : les tutos « WordPress headless en 10 minutes » sur Internet, c’est du marketing. La réalité du terrain, c’est autre chose. Et c’est exactement ce que vous allez lire ici.

→ Si vous hésitez encore sur WordPress en général, lisez d’abord WordPress en 2026 : vaut-il encore le coup ?

Qu’est-ce que WordPress headless ?

Un WordPress headless, c’est un WordPress qu’on a décapité. Littéralement. On lui a retiré la « tête » — la partie visible, les thèmes, le frontend PHP — pour ne garder que le corps : la base de données, l’éditeur Gutenberg, la gestion des utilisateurs, l’API. WordPress devient un pur gestionnaire de contenu. Il stocke, il organise, il expose les données. Mais il n’affiche plus rien.

L’affichage, c’est un framework JavaScript qui s’en charge. Next.js, Nuxt, Astro, SvelteKit — peu importe. Ce framework va chercher le contenu via l’API REST de WordPress (ou GraphQL), construit les pages HTML, et les sert aux visiteurs. Deux applications distinctes, deux serveurs potentiellement différents, connectés par une API.

WordPress classique vs headless

Critère	WordPress classique	WordPress headless
Architecture	Monolithique (PHP)	Découplée (API + JS)
Performance	Dépend du cache	Native (CDN + SSG/ISR)
Sécurité	WordPress exposé	Backend masqué
Thèmes	Milliers disponibles	Aucun (tout est custom)
Plugins frontend	Fonctionnels	Majoritairement inutilisables
Coût développement	2 000 – 5 000 €	8 000 – 25 000 €
Compétences requises	PHP, WordPress	PHP + JavaScript + DevOps

Pour comprendre la structure d’un WordPress classique, j’ai écrit un guide complet. Le headless part de cette base et la découpe en deux.

Le vocabulaire à connaître

Avant d’aller plus loin, quelques termes que vous allez croiser partout :

• Headless : le CMS n’a plus de frontend. Il ne sert que les données via API.
• Découplé : similaire au headless, mais WordPress conserve un thème (fallback). Nuance subtile que 90% des articles confondent.
• API REST : interface native de WordPress (depuis WP 4.7) pour exposer le contenu en JSON.
• GraphQL : alternative à l’API REST, plus flexible, via le plugin WPGraphQL.
• SSR (Server-Side Rendering) : le serveur JS génère le HTML à chaque requête.
• SSG (Static Site Generation) : les pages sont pré-générées à la compilation.
• ISR (Incremental Static Regeneration) : le meilleur des deux mondes — pages statiques, régénérées à intervalles ou à la demande.
• CDN : réseau de serveurs qui distribue vos pages au plus près des visiteurs.
• JAMstack : JavaScript + API + Markup — l’architecture dont le headless est un cas d’usage.

Comment fonctionne un WordPress headless

L’API REST de WordPress

Depuis WordPress 4.7 (décembre 2016), l’API REST est intégrée nativement. Chaque article, chaque page, chaque catégorie, chaque media est accessible via un endpoint JSON. Tapez /wp-json/wp/v2/posts après l’URL de n’importe quel WordPress et vous verrez les données brutes.

C’est la colonne vertébrale du headless. Le frontend interroge ces endpoints, récupère le contenu en JSON, et construit les pages. Pas de PHP côté visiteur. Pas de thème. Juste des données structurées.

Un prérequis que beaucoup oublient : les permaliens WordPress ne doivent pas être en mode « Simple ». L’API REST a besoin de jolies URLs pour fonctionner correctement. Si vous êtes encore en ?p=123, commencez par ça. Mon guide pour installer WordPress couvre ce point.

GraphQL avec WPGraphQL

L’API REST, c’est bien. Mais elle a un défaut : on récupère tout à chaque requête. Vous voulez juste le titre et le slug d’un article ? L’API REST vous renvoie aussi le contenu complet, les meta, les embeds, Yoast… Des kilooctets de données inutiles.

GraphQL résout ça. Vous demandez exactement ce que vous voulez, rien de plus. Le plugin WPGraphQL (gratuit, 15 000+ installations actives) transforme votre WordPress en serveur GraphQL.

Critère	API REST	GraphQL
Intégré nativement	Oui (WP 4.7+)	Non (plugin requis)
Requêtes flexibles	Non (réponses fixes)	Oui (vous choisissez)
Courbe d’apprentissage	Faible	Moyenne
Communauté	Immense	Croissante
Performance réseau	Sur-fetching fréquent	Optimale

Pour wpformation.com, j’ai choisi l’API REST. Pourquoi ? Parce qu’elle est native, qu’elle ne nécessite aucun plugin supplémentaire côté serveur, et que pour 450 articles le sur-fetching n’est pas un problème avec le bon cache.

SSR, SSG, ISR — les 3 modes de rendu

Imaginez un restaurant. Trois façons de servir :

• SSG (buffet) : tous les plats sont préparés à l’avance. Service instantané. Mais si un plat change, il faut tout refaire.
• SSR (à la minute) : chaque plat est cuisiné à la commande. Toujours frais. Mais l’attente est plus longue.
• ISR (buffet régénéré) : les plats sont préparés à l’avance, mais automatiquement rafraîchis à intervalles réguliers. Le meilleur compromis.

Sur wpformation.com, j’utilise l’ISR avec Next.js. Chaque page est pré-générée, mise en cache sur le CDN de Vercel, et régénérée toutes les heures ou à la demande quand je publie un article. Les visiteurs ont toujours une page servie en millisecondes, et le contenu n’est jamais obsolète de plus d’une heure.

Les avantages concrets

Pas de théorie ici. Des chiffres réels, des métriques vérifiables.

Performance

wpformation.com en WordPress headless (Next.js 16 + Vercel) :

• Mobile : Performance 96, Accessibilité 93, Bonnes pratiques 100, SEO 100
• Desktop : 100 partout
• Core Web Vitals : LCP 1,5s, INP 88ms, CLS 0

Mon ancien site avec WordPress classique et LiteSpeed Cache : 85 en mobile. Correct, mais loin du 96-100 actuel. La différence ? Le CDN sert des pages statiques pré-générées. Pas de PHP, pas de requêtes SQL, pas de plugins qui empilent du JavaScript. Juste du HTML optimisé livré par le nœud CDN le plus proche.

TechCrunch a fait la même transition. Temps de chargement divisé par 4 (3,5s → 0,8s). Conversions en hausse de 22%. Ce n’est pas un hasard.

Sécurité

En WordPress classique, votre wp-login.php est exposé au monde entier. Les bots testent des combinaisons en boucle. D’où des plugins comme WPS Hide Login (mon plugin, 2 millions d’installations) pour masquer l’URL de connexion.

En headless ? Le problème disparaît. WordPress tourne sur un sous-domaine séparé, non accessible au public. Pas de wp-login.php exposé. Pas d’attaques bruteforce possibles. La surface d’attaque est réduite au strict minimum. WPS Hide Login n’est même plus nécessaire — et ça me fait un drôle d’effet de dire ça vu que c’est mon plugin.

Liberté frontend totale

Plus de contrainte thème. Plus de template hierarchy PHP. Vous dessinez votre interface exactement comme vous la voulez, avec les technologies que vous maîtrisez. React, Vue, Svelte — votre choix.

Les thèmes WordPress, même les meilleurs, imposent des compromis. Le headless supprime ces compromis. Chaque pixel est sous votre contrôle. Chaque animation, chaque interaction, chaque micro-détail d’UX.

Développement local et GitHub

Un avantage que je n’avais pas mesuré avant de sauter le pas : le développement local. Avec WordPress classique, je devais soit bosser directement en production (risqué), soit maintenir un environnement Local/DevKinsta synchronisé avec la prod (pénible).

En headless, je lance npm run dev sur localhost:3000 et j’ai mon site complet en local. Le frontend interroge l’API WordPress distante, et je vois le résultat en temps réel. Je peux tester une modification CSS, un nouveau composant, un changement de layout — tout ça sans toucher à la production. Quand c’est prêt, un git push et Vercel déploie automatiquement.

Et justement, le code est sur GitHub. Chaque modification est versionnée. Je peux revenir en arrière en 10 secondes. Comparer deux versions d’un fichier. Créer une branche pour expérimenter sans risque. En WordPress classique, j’éditais des fichiers PHP directement sur le serveur via FTP. Si je cassais quelque chose, je priais pour me souvenir de ce que j’avais modifié. Aujourd’hui, git log me donne l’historique complet. C’est le jour et la nuit.

Multi-plateforme

WordPress classique sert du HTML. Point. En headless, l’API REST peut alimenter n’importe quoi : un site web, une application mobile, une borne interactive, un chatbot, un assistant vocal. Le contenu est créé une fois, consommé partout.

Provalliance (3 000 salons de coiffure, 70 marques) utilise cette approche : un WordPress unique alimente plusieurs sites de marques différentes. Un contenu, N frontends. C’est exactement le genre de cas où le headless a du sens. Si vous vous intéressez à l’avenir du contenu distribué, lisez mon article sur le GEO et WordPress.

Les inconvénients qu’on ne vous dit pas

La plupart des articles sur le headless ressemblent à des brochures commerciales. « Performance incroyable ! Sécurité renforcée ! Liberté totale ! » OK. Mais voici ce qu’on omet systématiquement.

Le coût réel

Un site WordPress classique avec un thème premium : 2 000 à 5 000 €. Un site WordPress headless équivalent : 8 000 à 25 000 €. Minimum.

Pourquoi ? Parce qu’il faut deux profils au lieu d’un. Un développeur PHP/WordPress pour le backend. Un développeur JavaScript pour le frontend. Et idéalement quelqu’un qui comprend les deux (ce profil est rare et cher). Sans compter l’hébergement double : un serveur pour WordPress, un service pour le frontend (Vercel, Netlify, Cloudflare Pages).

La facture d’hébergement n’est pas dramatique (Vercel propose un plan gratuit suffisant pour beaucoup de sites), mais le coût de développement et de maintenance, lui, est bien réel.

La perte de l’écosystème

C’est LE point qui fait mal. WordPress a 60 000+ plugins. En headless, la majorité ne sert plus à rien.

Contact Form 7 ? Inutile — il génère du HTML côté PHP. Elementor, Divi, WPBakery ? Inutiles — ce sont des page builders qui n’existent que dans le thème. Yoast SEO ? À moitié — il génère les meta, mais ne les affiche plus. Vous devez les récupérer via l’API et les injecter vous-même côté frontend.

J’ai dû recoder à la main le formulaire de contact, le schema FAQ, l’auto-revalidation du cache, les 220 redirections. 40% de l’effort total de migration, c’est reconstruire ce que les plugins faisaient gratuitement.

Les plugins qui restent utiles : Yoast (en lecture seule via API), ACF (champs personnalisés exposés via API), WPGraphQL, et… c’est à peu près tout. Le reste du frontend, vous le codez. Si le concept de thème enfant WordPress vous est familier, oubliez-le : en headless, il n’y a plus de thème du tout.

Le preview

En WordPress classique, vous cliquez « Aperçu » dans Gutenberg et vous voyez votre article tel qu’il apparaîtra. Simple. Natif. Immédiat.

En headless ? Gutenberg affiche le contenu avec le thème par défaut de WordPress (Twenty Twenty-Five ou autre). Ça ne ressemble en rien à votre frontend Next.js. Le bouton « Aperçu » devient inutile. Il faut reconstruire tout un système de preview côté frontend — je détaille le chantier dans la section retour terrain plus bas.

Le SEO à reconstruire

Yoast SEO fait un travail remarquable en WordPress classique. Il génère les balises title, les meta descriptions, les balises Open Graph, le Schema.org, le sitemap XML — tout, automatiquement.

En headless, Yoast continue de générer ces données. Mais il ne les affiche plus, puisqu’il n’y a plus de thème PHP. C’est à vous de récupérer chaque meta via l’API Yoast et de l’injecter dans votre frontend. Le sitemap, le robots.txt, le fichier llms.txt — tout est à regénérer côté JavaScript. Je détaille le chantier complet dans la section retour terrain.

Pour tout comprendre aux données structurées et Schema.org sur WordPress, j’ai publié un guide dédié. En headless, ces données existent toujours — mais c’est vous qui devez les brancher.

Tout ce qu’il faut reconstruire (mon retour terrain)

Cette section est la raison d’être de cet article. Aucun concurrent ne la propose. Parce que personne ne détaille ce qu’il a vraiment dû reconstruire. Moi, si.

wpformation.com : 450 articles, 220 redirections, 8 mu-plugins custom, 568 pages ISR. Voici le chantier réel.

Le SEO, entièrement

Yoast SEO, en headless, devient un générateur de données en lecture seule. Il calcule les scores, il produit les meta, il structure le Schema.org — mais c’est votre frontend qui doit tout afficher.

Concrètement, il faut appeler l’endpoint /yoast/v1/get_head?url= pour chaque page, parser le HTML qu’il renvoie, extraire le title, la meta description, les balises Open Graph (og:title, og:description, og:image), les balises Twitter Card, le canonical, et tout le bloc Schema.org en JSON-LD. Puis injecter tout ça dans le <head> de la page Next.js via generateMetadata().

Attention aussi au piège du blog_public=0 côté backend — j’en parle dans les pièges rencontrés plus bas. Si vous ne le gérez pas, zéro indexation Google.

Le sitemap XML, le robots.txt, le fichier llms.txt pour les IA — tout est régénéré côté Next.js. WordPress ne gère plus rien de visible. Pour approfondir la stratégie de silo SEO avec WordPress, le principe reste le même en headless — mais l’implémentation technique change du tout au tout.

Le backend sur un sous-domaine séparé

Première décision architecturale : WordPress doit vivre sur un sous-domaine dédié, différent du domaine principal. Le frontend (wpformation.com) est servi par Vercel. Le backend WordPress est sur un sous-domaine hébergé chez o2switch. Deux serveurs, deux domaines, une API entre les deux.

Pourquoi ? Pour que Google n’indexe que le frontend. Le backend WordPress est protégé par une triple couche noindex :

1. robots.txt avec Disallow: /
2. Header HTTP X-Robots-Tag: noindex sur toutes les pages
3. Réglage WordPress blog_public=0 (décourage l’indexation)

Conséquence directe : toutes les URLs internes dans le contenu des articles pointent vers le sous-domaine backend. Il faut les réécrire dynamiquement vers le domaine frontend. Chaque <a href>, chaque <img src>. À chaque chargement de page. C’est automatisé, mais il a fallu le coder.

Les images WordPress passent par un proxy Next.js : un rewrite de /wp-content/uploads/ vers le backend. Résultat : les images transitent par le CDN de Vercel, qui les convertit automatiquement en WebP/AVIF et les sert au format le plus léger selon le navigateur. Pas de plugin d’optimisation d’images côté WordPress. Le CDN fait tout.

Les 8 mu-plugins, votre nouvelle boîte à outils

En WordPress classique, vous installez des plugins et ça marche. En headless, les plugins frontend ne fonctionnent plus. Il faut créer des mu-plugins (must-use plugins) — des fichiers PHP déposés dans wp-content/mu-plugins/, activés automatiquement, impossibles à désactiver depuis l’interface.

Sur wpformation.com, j’en ai construit 8 :

1. Auto-revalidation (v2.0) — Le cœur du système. Quand je publie ou modifie un article, un hook save_post envoie un POST vers le frontend Next.js pour invalider le cache ISR. La v2.0 est bloquante (elle attend la confirmation) avec un warm-up non-bloquant qui pré-charge la page, les catégories et la homepage.
2. Formulaire de contact — Un endpoint REST API custom qui remplace Contact Form 7. Rate limiting, protection Cloudflare Turnstile, envoi email + notification. 200 lignes de PHP.
3. Frontend URLs — Quand je clique « Voir l’article » dans l’admin WordPress, ça ouvre le frontend, pas le backend. Même chose pour les liens dans les emails de notification.
4. Backend noindex — Headers X-Robots-Tag: noindex injectés sur toutes les pages du backend. Ceinture et bretelles avec le robots.txt.
5. Security hardening — Désactivation XML-RPC, blocage de l’énumération des utilisateurs (?author=1), suppression du numéro de version WP dans le code source.
6. Security headers — Content-Security-Policy, X-Content-Type-Options, Referrer-Policy côté WordPress. En complément des headers de sécurité configurés côté Next.js (HSTS, Permissions-Policy, X-Frame-Options).
7. FAQ Schema (v1.1) — Détecte les balises <details> dans le contenu des articles et génère automatiquement le schéma FAQPage en JSON-LD, exposé via l’API REST. Le frontend l’injecte dans le <head>.
8. Optimisation WP — Désactivation des emojis WordPress (oui, WP charge encore un script emoji en 2026), suppression d’oEmbed, de jQuery Migrate, réduction des requêtes admin.

Chaque mu-plugin fait entre 50 et 200 lignes de PHP. Pas compliqué individuellement. Mais 8 mu-plugins à maintenir, c’est un vrai socle technique. À chaque mise à jour majeure de WordPress, il faut vérifier que rien n’a cassé.

La preview des brouillons

En WordPress classique, « Aperçu » fonctionne. En headless, ce bouton ouvre WordPress avec son thème par défaut — qui ne ressemble en rien à votre site.

La solution, c’est un système de preview complet côté Next.js :

1. Le middleware intercepte les URLs /?p=123 (format preview WordPress)
2. Une route API /api/draft active le mode brouillon de Next.js
3. Le frontend récupère l’article non publié via l’API WordPress (authentification requise)
4. Un bandeau visuel indique « Mode brouillon » avec un lien pour modifier l’article et un bouton pour quitter la preview

Ça marche. Mais c’est du travail que vous n’auriez jamais eu à faire en WordPress classique. Comptez une bonne journée pour implémenter un système de preview fiable.

La sécurité, en double

En WordPress classique, vous installez Wordfence ou Sucuri et c’est réglé. En headless, la sécurité se gère en deux endroits :

• Côté WordPress : mu-plugins security hardening + security headers + désactivation XML-RPC
• Côté Next.js : Content-Security-Policy, HSTS, Permissions-Policy, X-Frame-Options dans la config next.config.ts

L’avantage : la surface d’attaque est drastiquement réduite puisque WordPress n’est plus exposé au public. Pas de wp-login.php accessible, pas d’attaques bruteforce possibles.

L’inconvénient : il faut configurer les headers de sécurité à la main, en comprenant ce que chaque directive autorise ou bloque. Une CSP mal configurée peut casser le chargement de Google Analytics, de Turnstile, des fonts — j’en ai fait l’expérience.

Les 220 redirections

Chaque article dépublié, chaque slug renommé, chaque fusion d’articles = une redirection 301. En WordPress classique, le plugin Redirection gère ça. En headless, c’est un fichier TypeScript avec 220+ entrées, maintenu à la main.

Les redirections couvrent les anciens slugs, les catégories renommées, les URLs WordPress par défaut (/wp-admin/, /xmlrpc.php, /wp-login.php) renvoyées vers la homepage, et les articles fusionnés. Chaque fois que je fusionne deux articles ou que j’en dépublie un, j’ajoute une ligne dans ce fichier. 220 lignes aujourd’hui. 300 d’ici la fin de l’année, probablement.

Le workflow automatisé

En WordPress classique, vous cliquez « Publier » et votre article est en ligne. En headless, la publication déclenche une chaîne automatisée :

1. Publication WordPress → le hook save_post se déclenche
2. POST vers Next.js → le mu-plugin auto-revalidate envoie une requête au endpoint /api/revalidate
3. Invalidation ISR → Next.js marque la page comme stale et la régénère
4. Warm-up → le mu-plugin pré-charge la page, les catégories associées et la homepage pour remplir le cache
5. IndexNow → notification envoyée à Bing et Yandex pour une indexation rapide
6. Google Sitemap Ping → notification au moteur de recherche que le sitemap a changé

Tout ça se passe automatiquement. Mais la première version du mu-plugin (v1.0) était bancale — fire-and-forget sans warm-up. Les visiteurs tombaient sur du cache stale pendant 30 à 60 secondes après chaque publication. Il a fallu passer en mode bloquant + warm-up non-bloquant pour que ça marche vraiment. C’est le genre de détail que personne ne mentionne dans les tutos headless.

Les pièges qu’on a rencontrés (et corrigés)

Voici les erreurs réelles que j’ai dû corriger. Pas de la théorie — du vécu.

Yoast : 6 champs, pas 1. Yoast SEO a des champs séparés pour le SEO title, la meta description, l’OG title, l’OG description, le Twitter title et le Twitter description. Si les champs OG et Twitter sont vides, le fallback n’est PAS le SEO title — c’est le titre brut de l’article WordPress. Résultat : les partages sur Facebook et Twitter affichaient le mauvais titre. Il a fallu 2 semaines pour comprendre d’où venait le problème. Leçon : toujours setter explicitement les 6 champs Yoast.

Noindex global, le faux positif. Le réglage blog_public=0 sur le backend (nécessaire pour empêcher son indexation) fait que l’API Yoast retourne robots: noindex pour tous les articles. Le frontend doit systématiquement overrider à index: true. Si vous oubliez cette ligne de code, votre site entier disparaît de Google. Silencieusement.

Le cache qui ne se purge pas. revalidatePath('/mon-article/') dans Next.js ne purge pas toujours le Data Cache au niveau fetch. Les visiteurs voient encore l’ancienne version pendant une heure. Solution : revalidatePath("/", "layout") — l’option nucléaire qui purge tout. Brutal mais efficace.

Le code inline qui devient un bloc. La regex qui convertit les <code> inline (de l’époque Classic Editor) en blocs terminal <pre><code> était trop agressive. Elle promouvait category_description() en bloc parce que les entités HTML (&, >) contiennent un point-virgule. Fix : strip les entités HTML avant de détecter les vrais terminateurs de statement.

Le trailing slash oublié. Une seule URL sans trailing slash = soft 404 + perte de linking juice. Configuration Next.js, liens internes, Schema.org, BreadcrumbList — le trailing slash doit être PARTOUT. Un oubli et Google indexe deux versions de la même page.

Chaque piège m’a coûté entre 2 heures et 2 jours. Aucun n’est documenté dans les tutos « headless en 10 minutes ». C’est la réalité du terrain.

La stack technique en 2026

Les frameworks frontend

Framework	Langage	SSR	SSG	ISR	Écosystème WP
Next.js	React	✅	✅	✅	Excellent
Nuxt	Vue	✅	✅	✅	Bon
Astro	Multi	✅	✅	Partiel	Correct
Gatsby	React	❌	✅	❌	Déclinant
SvelteKit	Svelte	✅	✅	Partiel	Limité

Next.js est le choix par défaut. Pas parfait (les App Router breaking changes entre versions sont pénibles), mais c’est le framework le plus documenté pour WordPress headless. La communauté est immense, les exemples abondent, et Vercel (qui édite Next.js) propose un hébergement optimisé avec déploiement automatique depuis GitHub.

Si vous êtes plus à l’aise avec Vue.js, Nuxt est un excellent choix. Si vous cherchez la performance maximale avec un minimum de JavaScript client, Astro mérite un regard. Gatsby, lui, a perdu la bataille — Netlify l’a racheté puis l’a laissé mourir.

Les plugins utiles en headless

Sur les 60 000+ plugins WordPress, voici ceux qui gardent une utilité en headless :

• Yoast SEO — En lecture seule via API. Génère les meta, le Schema.org. Vous les récupérez et les affichez côté frontend.
• ACF (Advanced Custom Fields) — Les champs personnalisés sont exposés via l’API REST (depuis ACF 5.11). Indispensable si vous avez des contenus structurés au-delà du titre/contenu.
• WPGraphQL — Si vous préférez GraphQL à l’API REST. Gratuit, bien maintenu, compatible Yoast et ACF.
• CoCart — Rend l’API WooCommerce utilisable pour un frontend découplé. Si vous faites du e-commerce headless.

C’est court, oui. C’est le headless.

Hébergement

Le headless implique deux hébergements :

• Backend WordPress : un hébergement PHP classique. o2switch, OVH, Infomaniak — n’importe quel hébergeur WordPress fait l’affaire. La charge est minime puisque seule l’API est sollicitée, pas le rendu des pages.
• Frontend JavaScript : Vercel (optimal pour Next.js), Netlify (polyvalent), Cloudflare Pages (le plus économique). Le frontend est servi depuis un CDN mondial.

Pour wpformation.com, c’est o2switch pour WordPress et Vercel Pro pour Next.js. Coût total : ~7€/mois (o2switch) + 20$/mois (Vercel Pro). Avant, le même site en WordPress classique coûtait 7€/mois chez o2switch. La différence de 20$/mois se justifie par les performances CDN et le déploiement automatique.

Pour choisir votre hébergement backend, consultez mon comparatif hébergement WordPress.

C’est pour qui ?

Les bons candidats

Le headless a du sens si vous cochez au moins 3 de ces cases :

• Votre site reçoit un trafic significatif et la performance est un enjeu business
• Vous avez un développeur JavaScript dans l’équipe (ou le budget pour en embaucher un)
• Vous avez besoin de distribuer le contenu sur plusieurs plateformes (web + mobile + API partenaires)
• Votre design frontend dépasse ce que les thèmes WordPress peuvent offrir
• Vous publiez du contenu fréquemment et avez besoin d’un workflow de publication automatisé

Sites media (TechCrunch, Meta Newsroom), e-commerce multi-canal, plateformes SaaS avec blog intégré, réseaux multi-sites d’entreprise — ce sont les profils types.

Ceux qui ne devraient pas

Blog personnel. PME avec un site vitrine. Freelance qui gère 5 sites clients. Boutique WooCommerce avec 50 produits. Association locale. Restaurant.

Si votre WordPress classique fonctionne, qu’il charge en moins de 3 secondes, et que vos visiteurs sont satisfaits — ne changez rien. Le headless ne résoudra pas un problème que vous n’avez pas.

Si vous devez demander « est-ce que le headless est fait pour moi ? », la réponse est probablement non.

Pour les débutants, commencez par apprendre WordPress dans sa version classique. Le headless viendra peut-être un jour, quand les limites du classique vous freineront vraiment. Et si vous cherchez des leviers d’amélioration sans passer au headless, lisez comment reprendre le contrôle de votre WordPress en 2026.

Cas concrets

TechCrunch et Meta Newsroom

TechCrunch (Automattic/WP VIP) a migré vers un frontend React découplé. Résultat : temps de chargement divisé par 4, bounce rate en baisse, conversions +22%. Meta Newsroom utilise la même approche pour alimenter des dizaines de sites régionaux depuis un WordPress unique.

Ces deux exemples ont un point commun : des équipes de développeurs dédiées, un budget conséquent, et un trafic qui justifie l’investissement. Ce ne sont pas des PME.

wpformation.com

Mon propre site. 450 articles, Next.js 16, hébergé sur Vercel. PageSpeed 96-100, ISR avec revalidation automatique, 8 mu-plugins custom, 220 redirections gérées en TypeScript.

La migration a pris plusieurs semaines de travail. Pas 10 minutes. Pas un week-end. Des semaines. Mais le résultat est là : un site qui charge instantanément, un frontend moderne avec des animations CSS, un workflow de publication automatisé, et un code versionné sur GitHub.

Dans un prochain article, je détaillerai exactement comment j’ai migré les 450 articles de wpformation.com vers du headless avec Claude Code. Les scripts, les pièges, les optimisations — tout.

Provalliance / Zento

Provalliance (Jean Louis David, Franck Provost, Saint Algue…) gère 70 marques et 3 000 salons. Leur solution : un WordPress central alimentant plusieurs frontends via API, avec un cache à 3 niveaux (CDN + edge + application).

Zento, l’agence derrière cette architecture, a publié un retour d’expérience détaillé. Le point commun avec tous les cas headless réussis : une équipe technique solide et un budget qui ne fait pas peur. Pour un autre retour terrain sur les architectures découplées, lisez comment j’ai reconstruit un site institutionnel avec Next.js et Payload CMS.

Headless WordPress, comment se lancer ?

Si vous êtes convaincu que le headless est pour vous, voici une roadmap en 6 étapes. Pas un tuto pas-à-pas (ça viendra), mais une vue d’ensemble pour ne pas partir dans le mur.

1. Évaluez le besoin réel. Votre WordPress classique est-il vraiment limitant ? Avez-vous testé un bon plugin de cache (LiteSpeed Cache, WP Rocket) avant de tout casser ?
2. Choisissez votre stack. Next.js + Vercel est le chemin le plus balisé. Ne réinventez pas la roue au premier projet.
3. Configurez l’API WordPress. Permaliens en mode « Nom de l’article », Yoast SEO installé, CORS configuré pour autoriser les requêtes depuis votre domaine frontend.
4. Prototypez avec 5 articles. Pas 450. Cinq. Vérifiez que le contenu s’affiche, que les images chargent, que le SEO est correct.
5. Intégrez le SEO dès le jour 1. Pas à la fin. Dès le début. Chaque page doit avoir ses meta, son Schema.org, ses OG tags fonctionnels avant de passer à la suite.
6. Testez le workflow complet. Publication → revalidation → cache → indexation. Si cette chaîne ne fonctionne pas de bout en bout, votre site headless sera un cauchemar à maintenir.

Et si vous voulez apprendre WordPress en profondeur avant de vous lancer, ma formation WordPress couvre les bases solides dont vous aurez besoin.

Questions fréquentes sur WordPress headless

Qu’est-ce qu’un WordPress headless exactement ?

C’est un WordPress dont on a supprimé le frontend (thèmes PHP). WordPress ne sert plus que de gestionnaire de contenu via son API REST ou GraphQL. Un framework JavaScript (Next.js, Nuxt, Astro) récupère les données et génère les pages visibles par les visiteurs. Deux applications distinctes, connectées par une API.

Quelle différence entre headless et découplé ?

En headless pur, WordPress n’a plus aucun frontend — pas de thème, pas de rendu HTML. En mode découplé, WordPress conserve un thème (souvent minimal) qui peut servir de fallback. La distinction est subtile et la plupart des articles confondent les deux termes. En pratique, 95% des projets « headless » sont techniquement découplés.

WordPress headless est-il meilleur pour le SEO ?

Pas automatiquement. Le headless peut améliorer le SEO grâce à de meilleures performances (Core Web Vitals, temps de chargement), mais il faut reconstruire toute la couche SEO côté frontend : meta tags, Schema.org, OG tags, sitemap XML, robots.txt. Si vous bâclez cette partie, votre SEO sera pire qu’en WordPress classique. C’est un outil, pas une garantie.

Combien coûte un site WordPress headless ?

Comptez 8 000 à 25 000 € pour un site headless équivalent à un WordPress classique à 2 000-5 000 €. Le surcoût vient principalement du développement frontend custom (pas de thème tout fait), du double hébergement, et de la reconstruction des fonctionnalités que les plugins faisaient gratuitement. L’hébergement récurrent ajoute 20-50$/mois pour le service frontend (Vercel, Netlify).

Peut-on utiliser WooCommerce en headless ?

Oui, mais c’est le scénario le plus complexe. WooCommerce a une API REST, et des plugins comme CoCart la rendent plus exploitable. Mais le panier, le checkout, les paiements, les comptes clients — tout doit être reconstruit côté frontend. Pour une boutique avec 50 produits et un checkout standard, WordPress classique + WooCommerce reste infiniment plus simple et économique.

API REST ou GraphQL, que choisir ?

L’API REST est native (aucun plugin), bien documentée, et suffisante pour la majorité des projets. GraphQL (via WPGraphQL) est plus performant en réseau (vous ne récupérez que les données demandées) et plus flexible pour les requêtes complexes. Pour un premier projet headless, commencez par l’API REST. Migrez vers GraphQL si le sur-fetching devient un problème mesurable.

Next.js est-il le meilleur framework pour WordPress headless ?

C’est le plus documenté et le mieux supporté pour WordPress headless. L’écosystème (exemples, tutoriels, starters) est le plus riche. Vercel propose un hébergement optimisé avec déploiement automatique. Mais « meilleur » dépend de votre équipe : si vous êtes plus à l’aise avec Vue.js, Nuxt est un excellent choix. Si vous cherchez la performance brute avec un minimum de JavaScript client, regardez Astro.

WordPress headless fonctionne-t-il avec Gutenberg ?

Oui, pour la rédaction. Gutenberg reste l’éditeur de contenu côté WordPress. Mais le rendu visuel dans Gutenberg ne reflète plus votre site (puisqu’il n’y a plus de thème). Le bouton « Aperçu » ouvre le thème WordPress par défaut, pas votre frontend. Il faut construire un système de preview custom pour voir le rendu réel. Le contenu Gutenberg (blocs HTML) est récupéré via l’API et affiché par le frontend.

Peut-on revenir en arrière après une migration headless ?

Oui. WordPress n’a pas été modifié, juste « décapité ». Réinstallez un thème, reconfigurez les permaliens, désactivez les mu-plugins headless — et vous retrouvez un WordPress classique fonctionnel. Le contenu n’est pas touché. Les seules pertes seraient les fonctionnalités frontend custom (composants React, animations) qui n’existent pas côté WordPress.

Quelles alternatives à WordPress pour le headless ?

Strapi (Node.js, open source), Sanity (cloud, schéma flexible), Contentful (cloud, entreprise), Payload CMS (Node.js, open source, excellent en 2026), Directus (Node.js, headless natif). Chacun a ses forces. WordPress reste pertinent en headless grâce à sa communauté, son éditeur Gutenberg, et le fait que beaucoup de sites existants tournent déjà dessus. Migrer le contenu est plus simple que migrer le CMS.

Conclusion

Le WordPress headless n’est pas une mode. Ce n’est pas non plus une révolution. C’est un outil. Comme un marteau pneumatique : puissant, précis, mais inutile pour planter un clou dans un cadre photo.

Si votre site a du trafic, si vous avez les compétences JavaScript, si le budget le permet, et si les limites du WordPress classique vous freinent vraiment — alors oui, le headless vaut le détour. Les performances sont réelles. La sécurité est renforcée. La liberté frontend est grisante.

Mais ne sous-estimez pas le chantier. Huit mu-plugins à construire. Le SEO à recâbler entièrement. Le preview à réinventer. Les redirections à maintenir à la main. Le workflow de publication à automatiser. Et les pièges — les pièges qu’aucun tutoriel ne mentionne parce que leurs auteurs n’ont jamais migré un vrai site avec 450 articles.

C’est exactement ce que je compte documenter dans un prochain article : comment j’ai migré les 450 articles de wpformation.com vers du headless avec l’aide de Claude Code. Les scripts, les erreurs, les raccourcis, les impasses. Du concret, pas du marketing.

En attendant, si vous avez des questions sur le headless ou si vous cherchez un accompagnement pour votre projet, consultez ma page formation WordPress. Et pour comprendre comment les IA interagissent avec le contenu web, jetez un œil à mon article sur llms.txt et WordPress — un sujet directement lié à l’architecture headless.

Le headless n’est pas une fin en soi. Si votre WordPress classique fonctionne bien, gardez-le!