Réserver

WordPress headless en 2026 : quand le découplage vaut la peine

par Francis Rozange | Oct 2, 2026 | WordPress

A glowing glass core separated from its shell, linked by thin streams of light

Le 13 septembre 2022, The Verge a relancé son site sur une toute nouvelle interface. Son système de gestion de contenu n’avait pourtant pas changé : le média n’a remplacé son outil maison par WordPress qu’ensuite, sous un site déjà en ligne. Ce tour de force n’était possible que parce que l’affichage et la gestion des contenus étaient séparés.

C’est la promesse du WordPress headless, ou « sans tête » : WordPress gère les contenus, une autre application les affiche. Le front devient libre, le CMS reste familier aux rédactions. La promesse séduit, et elle a un prix que les démonstrations taisent souvent.

Même l’hébergeur WordPress VIP, qui vend des architectures headless à de grands médias, le reconnaît dans un article de 2026 : sans une équipe capable de régler chaque composant, un WordPress headless sera probablement plus lent.

Ce guide fait le point en octobre 2026 : ce que recouvre le mot, le choix entre REST API et WPGraphQL, les fronts possibles, les aperçus, le référencement, la sécurité, l’hébergement et son coût, puis les cas où il vaut mieux s’abstenir.

Ce que « headless » veut dire

Le front, le back et l’API entre les deux

Dans un site WordPress classique, le même logiciel stocke les contenus et fabrique les pages : le thème transforme les articles en HTML à chaque visite. En headless, WordPress ne sert plus de pages. Il expose ses contenus par une API, et une application séparée, souvent écrite en JavaScript, les récupère pour construire le site.

Les rédacteurs continuent d’écrire dans l’éditeur de blocs, de gérer les médias et les comptes comme avant. Les visiteurs ne voient jamais WordPress : ils naviguent sur le front, hébergé ailleurs, avec ses propres règles de cache et de déploiement.

Headless, découplé, hybride

Les trois mots circulent, avec des nuances. Headless désigne un WordPress sans aucun rendu public. Découplé insiste sur la séparation des deux applications. Hybride décrit un site dont certaines sections restent rendues par WordPress, et d’autres par une application séparée, une approche que WordPress VIP défend pour éviter de tout reconstruire.

Le choix n’est donc pas binaire. Avant de comparer WordPress à d’autres plateformes, comme dans notre comparatif WordPress, Shopify et Webflow, demandez-vous quelle partie du site gagnerait vraiment à être séparée.

REST API ou WPGraphQL : choisir son canal

La REST API, déjà dans le cœur

WordPress expose ses contenus en JSON depuis la version 4.7, sortie en décembre 2016 : articles, pages, commentaires, termes, utilisateurs, métadonnées et réglages. L’éditeur de blocs lui-même repose sur cette API. Aucun plugin n’est nécessaire pour s’en servir.

Un point surprend souvent : les contenus publics le sont aussi par l’API, pour n’importe quel visiteur, et l’API ne vérifie pas l’origine des requêtes. C’est un choix de conception, documenté. Les brouillons et les champs d’édition, en revanche, exigent une requête authentifiée.

La documentation officielle d’Astro utilise cette API pour son guide WordPress, et c’est souvent le chemin le plus court pour un site de contenu simple.

WPGraphQL, plugin canonique annoncé en octobre 2024

WPGraphQL ajoute à WordPress une API GraphQL : le front demande exactement les champs dont il a besoin, imbrique les relations dans une seule requête et s’appuie sur un schéma typé. Créé par Jason Bahl en 2016, le plugin a été financé successivement par Gatsby, puis par WP Engine à partir de 2021.

Le 7 octobre 2024, Matt Mullenweg a annoncé que WPGraphQL devenait un plugin canonique de WordPress.org, le jour où son créateur quittait WP Engine pour Automattic, en plein conflit entre les deux entreprises. Le plugin reste un plugin : il ne fait pas partie du cœur, et la REST API reste l’API officielle de WordPress.

En octobre 2026, WPGraphQL en est à la version 2.23.1, avec plus de 30 000 installations actives. Depuis début 2026, le plugin et ses principaux compagnons, Smart Cache, WPGraphQL for ACF et l’IDE, sont réunis dans un seul dépôt de code. Aucun n’était encore déclaré testé avec WordPress 7.1 au moment où nous écrivons.

Les plugins qui gravitent autour

Plusieurs plugins complètent WPGraphQL. WPGraphQL for ACF expose les champs personnalisés d’ACF ; une demande de compatibilité avec Secure Custom Fields, la version maintenue par WordPress.org, est toujours ouverte en octobre 2026. WPGraphQL Smart Cache gère le cache et l’invalidation des requêtes. WPGraphQL Content Blocks, de WP Engine, expose les blocs de l’éditeur sous forme de données typées.

Pour le référencement, un plugin communautaire relie Yoast SEO à WPGraphQL. Rank Math ne propose pas de prise en charge native de GraphQL.

Comment choisir entre les deux

La REST API suffit pour un site de contenu simple : des articles, des pages, des catégories, un seul front. Elle ne demande aucun plugin et fonctionne avec les points d’accès de Yoast et de Rank Math.

WPGraphQL prend l’avantage quand le modèle de contenu se complique : champs personnalisés nombreux, relations entre contenus, plusieurs fronts ou applications à alimenter. Sa documentation compare une même liste de cent articles, 335 Ko en REST contre 6,4 Ko en GraphQL ; c’est l’argument du projet lui-même, et la REST API sait aussi alléger ses réponses avec le paramètre _fields : comparez sur vos propres requêtes. Pour profiter du cache réseau de Smart Cache, les requêtes doivent passer en GET, et le site doit être chez un hébergeur compatible.

Le front : Next.js, Astro et les autres

Next.js et l’exemple officiel

Le dépôt de Next.js contient un exemple officiel pour WordPress. Il s’appuie sur WPGraphQL et WPGraphQL JWT Authentication pour les aperçus, Yoast SEO et son pont GraphQL, Redirection pour les redirections, et un thème minimal qui renvoie les aperçus et les liens vers le front. Il exige aussi le plugin Classic Editor, un détail révélateur : l’exemple ne cherche pas à reproduire les blocs.

Next.js apporte la régénération incrémentale, qui reconstruit une page en arrière-plan, à la première visite après un délai fixé ou à la demande, et un mode brouillon pour les aperçus. Ces mécanismes sont puissants, mais il faut les relier à WordPress : publier un article doit déclencher la reconstruction des bonnes pages.

Astro, la voie REST la plus simple

Astro publie son propre guide WordPress, basé sur la REST API, en génération statique ou côté serveur. Pour un site éditorial sans compte utilisateur ni commerce, c’est souvent l’option la plus légère. Nuxt et SvelteKit fonctionnent aussi, mais leurs documentations ne proposent pas de guide WordPress dédié ; WP Engine en publie pour sa propre plateforme.

Faust.js et Gatsby : ce qu’ils sont devenus

Faust.js, développé par WP Engine, se présentait comme le framework headless pour WordPress. En février 2025, l’équipe l’a repositionné comme une simple boîte à outils pour Next.js et a abandonné son expérimentation avec le nouveau routeur de Next.js. Ne le choisissez pas par défaut pour un projet neuf.

Gatsby, longtemps associé au WordPress headless, appartient à Netlify depuis février 2023. Ses versions continuent de sortir, lentement : la dernière date de février 2026. Gatsby n’est plus le point de départ naturel qu’il a été.

Aperçus et confort éditorial

Le bouton Aperçu à reconstruire

C’est la première chose que les rédactions remarquent. Dans WordPress, le bouton Aperçu ouvre le site WordPress lui-même, qui n’existe plus pour le public. Il faut donc rediriger ce lien vers le front avec le filtre preview_post_link, puis faire en sorte que le front récupère le brouillon par une requête authentifiée et l’affiche hors cache.

Next.js prévoit pour cela un mode brouillon, activé par une route dédiée protégée par un secret. Sa documentation recommande de rediriger vers l’adresse fournie par le CMS, pas vers un paramètre de la requête, pour éviter une redirection ouverte. WPGraphQL a de son côté revu sa gestion des aperçus fin août 2026, dans sa version 2.21.0, avec un piège à connaître : une requête d’aperçu non autorisée renvoie silencieusement la version publiée, sans erreur.

Les blocs hors de WordPress

Un article écrit dans l’éditeur de blocs arrive au front sous forme de HTML déjà rendu, ou de données de blocs à reconstruire composant par composant. Dans le premier cas, il faut reproduire les styles des blocs ; dans le second, chaque bloc utilisé doit avoir son équivalent dans le front.

L’Interactivity API, qui anime certains blocs récents, repose sur le rendu PHP de WordPress : un front découplé ne l’exécute pas tel quel. Les fonctions récentes de l’éditeur, présentées dans notre point sur les nouveautés de WordPress 7, ne suivent donc pas automatiquement sur un front headless.

Une nouvelle façade de verre éclairée devant une structure ancienne remplacée en arrière-plan

Le cas Vox Media : quitter un CMS maison pour WordPress sans tête

Vox Media, qui éditait alors The Verge, Vox, SB Nation, Eater et Polygon, a d’abord doté The Verge d’un nouveau front en 2022, puis a migré ses sites vers WordPress en mode headless entre 2023 et 2025. Le chantier est documenté par l’éditeur lui-même, par l’hébergeur WordPress VIP, par l’agence XWP, chargée du back-end et de la migration des contenus, et par une conférence au WordCamp US 2024. C’est l’un des exemples les plus complets de ce que coûte et rapporte cette architecture.

Chorus, un CMS maison

Pendant plus de dix ans, Vox Media a publié ses sites sur Chorus, un CMS développé en interne. En 2018, le groupe l’ouvrait même à d’autres éditeurs, en le présentant comme la colonne vertébrale de l’entreprise. Maintenir son propre CMS a pourtant un coût, et en août 2023, WordPress VIP annonce que Vox Media l’adopte pour remplacer Chorus, avec un objectif affiché : plus de fiabilité, de rapidité et de disponibilité.

Le front d’abord, le CMS ensuite

La particularité du projet tient à son ordre. Dès septembre 2022, The Verge passe sur Duet, la nouvelle plateforme d’affichage de Vox Media, construite par ses propres ingénieurs avec son système de design. Le CMS change ensuite, sous un site déjà en ligne. Duet se connecte à WordPress par WPGraphQL.

Selon XWP, après une phase de cadrage, une preuve de concept a d’abord confirmé que WordPress VIP pouvait alimenter Duet, et levé les doutes internes. L’agence cite parmi les difficultés le scepticisme sur la capacité de WordPress à tenir la charge, la préservation des habitudes éditoriales de l’ère Chorus et des structures de données différentes d’un site à l’autre. Quarante-deux personnes de XWP et de Vox Media ont travaillé sur la livraison.

Une migration marque par marque

Vox.com ouvre la marche, avec une refonte lancée en mai 2024 pour ses dix ans. Polygon suit en août 2024 ; son éditeur explique que la nouvelle version repose sur Duet, couplé à un back-end plus souple sous WordPress VIP. En septembre 2024, une équipe mixte présente au WordCamp US la migration de Chorus vers un réseau multisite WordPress headless, avec une API GraphQL sur mesure pour Duet.

SB Nation suit en août 2025, avec près de deux cents communautés de supporters. Selon XWP, plus de quinze millions de commentaires annuels ont été préservés pendant la migration. L’agence annonce aussi pour Vox.com une hausse de trafic de 40 % sur les quarante premiers jours, un chiffre à prendre avec prudence : il n’est pas détaillé, et la refonte du design est sortie en même temps.

Le code source des pages le montre aujourd’hui : The Verge, Vox, SB Nation et Eater sont rendus par Next.js, avec des médias servis depuis des chemins /wp-content/uploads/sites/, la signature d’un multisite WordPress.

Ce que le cas enseigne

Le découplage a permis à Vox Media de livrer un nouveau front avant de remplacer son CMS, puis de changer le moteur sous un site en marche. C’est l’argument le plus fort du headless, démontré à l’échelle d’un groupe de presse. Le coût est à la hauteur : un framework de front et un système de design maison, une équipe de plus de quarante personnes, un hébergeur haut de gamme et un chantier étalé sur trois ans, du nouveau front de The Verge en 2022 à SB Nation en 2025.

Les difficultés citées par XWP, chargée du back-end, sont éditoriales et techniques à la fois : flux de travail, migration des données, fonctions communautaires. Le front relevait des ingénieurs de Vox Media, et ce bilan ne le couvre pas.

Dernier enseignement, inattendu : en mai 2025, Polygon a été vendu à un autre groupe, moins d’un an après sa migration. En 2026, le reste de Vox Media a été scindé entre deux acquéreurs. Le sort de la plateforme commune n’est pas documenté. Un investissement headless de cette ampleur parie aussi sur la stabilité de l’organisation qui le porte.

SEO : métadonnées, sitemaps, canoniques

Yoast et Rank Math côté API

Les métadonnées de référencement restent gérées dans WordPress. Yoast SEO les ajoute aux réponses de la REST API et propose un point d’accès qui renvoie l’en-tête complet d’une adresse. Rank Math propose un point d’accès équivalent, à activer dans ses réglages. Notre comparatif des plugins SEO WordPress détaille leurs autres différences.

L’identité vient du front

Le piège classique concerne les adresses. Si l’adresse du site, dans les réglages généraux de WordPress, pointe vers le CMS, les balises canoniques, les données Open Graph et les données structurées désigneront le CMS, et non le site public. Jason Bahl, qui fait tourner le site de WPGraphQL en headless, résume la règle en 2026 : prendre le contenu dans WordPress, et l’identité dans le front.

Autre piège qu’il décrit : si le CMS est réglé pour décourager les moteurs de recherche, Yoast renverra une consigne de non-indexation que le front ne doit pas recopier. Enfin, le plan du site, le fichier robots.txt et les redirections doivent être servis par le front. L’exemple officiel de Next.js désactive les sitemaps de Yoast et génère le sien côté front.

Authentification et sécurité

Mots de passe d’application, JWT et cookies

Pour lire les brouillons ou écrire dans WordPress, le front doit s’authentifier. Depuis WordPress 5.6, les mots de passe d’application, envoyés en authentification HTTP de base sur une connexion chiffrée, sont la solution intégrée. La documentation donne cet exemple :

curl --user "USERNAME:PASSWORD" https://HOSTNAME/wp-json/wp/v2/users?context=edit

Ces mots de passe se gardent côté serveur, jamais dans le code envoyé au navigateur. Des plugins proposent des jetons JWT, et des solutions de connexion plus complètes existent pour WPGraphQL. L’authentification par cookie exige un jeton de sécurité, faute de quoi la requête est traitée comme anonyme.

Une API publique par défaut

La documentation de la REST API déconseille de la désactiver. Pour exiger une authentification sur toutes les requêtes, elle propose ce filtre :

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }
    if ( ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_not_logged_in',
            __( 'You are not currently logged in.' ),
            array( 'status' => 401 )
        );
    }
    return $result;
});

Attention : ce filtre bloque aussi les lectures anonymes. Un front statique ou régénéré devra alors s’authentifier à chaque reconstruction.

Les réglages de WPGraphQL à vérifier

Les réglages par défaut de WPGraphQL méritent une relecture avant la mise en production. Le point d’accès /graphql est ouvert aux visiteurs anonymes, comme la REST API. Les requêtes groupées sont autorisées, jusqu’à dix par appel. La limite de profondeur des requêtes existe, mais elle est désactivée : activez-la pour éviter qu’une requête trop imbriquée ne sollicite lourdement le serveur.

L’introspection publique du schéma, qui décrit toute l’API à qui la demande, n’est active par défaut que sur les environnements déclarés comme locaux ou de développement. Vérifiez que votre environnement de production est bien déclaré comme tel, et que le mode de débogage reste coupé.

Septembre 2026 : sept avis de sécurité pour WPGraphQL

Masquer WordPress derrière un front ne réduit pas la surface d’attaque : elle se déplace vers l’API. En septembre 2026, le projet WPGraphQL a publié sept avis de sécurité, dont cinq classés graves, parmi lesquels une élévation de privilèges jusqu’au rôle d’administrateur et une faille permettant à un contributeur de publier.

Toute version de WPGraphQL antérieure à la 2.23.1 est exposée à au moins l’une d’elles, et deux de ces avis visent ses compagnons : il faut aussi WPGraphQL Smart Cache 2.3.2 et WPGraphQL for ACF 3.0.0. Les principes de notre guide pour sécuriser WordPress s’appliquent donc toujours au CMS.

Hébergement et coût réel de deux piles

Vercel, Netlify et WP Engine

Un site headless, ce sont deux applications à héberger, à surveiller et à mettre à jour. Côté front, l’offre gratuite de Vercel est réservée à un usage personnel et non commercial : un site professionnel passe à l’offre Pro, 20 dollars par mois et par développeur, avec un crédit d’usage inclus puis une facturation à la consommation.

Netlify fonctionne par crédits : une offre gratuite, une offre Personal à 9 dollars par mois, puis une offre Pro de 20 dollars par mois jusqu’à 126 dollars pour le plus gros palier de crédits. Chaque déploiement en production consomme 15 crédits.

WP Engine propose une plateforme qui héberge les deux moitiés, sans prix public : il faut demander un devis. Avec Vercel ou Netlify, il faut ajouter l’hébergement de WordPress lui-même, toujours nécessaire. Dans tous les cas, le premier coût reste le temps des développeurs capables de maintenir deux piles.

L’invalidation du cache

Le cache est à la fois la force et la difficulté du headless. Un front statique est très rapide, mais chaque publication doit déclencher la reconstruction des pages concernées. Avec plusieurs instances, le cache par défaut de Next.js est propre à chacune, et la documentation de WP Engine précise que son cache de bord optionnel, l’Edge Full Page Cache, n’est pas purgé par les événements venus de WordPress et attend l’expiration de sa durée de vie.

Sur un site qui met souvent ses contenus à jour, comme un site d’actualité qui suit un événement, WordPress VIP note que l’invalidation du cache compense une partie des gains de performance attendus. Mesurez sur le terrain, comme le propose notre guide des correctifs Core Web Vitals, plutôt que de supposer.

Quand ne pas passer en headless

Le headless se paie dès qu’un site dépend de ce que WordPress affiche lui-même. Les formulaires, les constructeurs de pages, les plugins d’adhésion ou de réservation fonctionnent par leur rendu dans le thème : en headless, il faut les reconstruire ou s’en passer.

WooCommerce dispose d’une API dédiée au panier et à la commande, la Store API. Mais chaque passerelle de paiement attend des données différentes, et WooCommerce reconnaît ne pas pouvoir toutes les documenter. Une boutique headless reste un projet lourd ; pour améliorer une boutique classique, notre guide pour optimiser le checkout WooCommerce donne des leviers plus directs.

Méfiez-vous du headless dans ces situations :

  • Le site web est votre seul canal de publication : aucune application, aucun autre écran à alimenter.
  • Le marketing dépend de nombreux plugins qui s’affichent dans le thème.
  • Vous n’avez pas d’équipe capable de développer et d’exploiter un front séparé, ni le budget pour en payer une durablement.
  • Les rédacteurs tiennent à l’aperçu fidèle et à l’édition visuelle de l’éditeur de blocs.
  • Le site a besoin de fonctions récentes de WordPress dès leur sortie.

Tableau récapitulatif

Critère WordPress classique WordPress headless
Liberté du front Limitée par le thème Totale
Aperçu et édition visuelle Natifs À reconstruire
Plugins affichés dans le thème Fonctionnent À remplacer
Référencement Géré par un plugin Métadonnées par l’API, le reste dans le front
Sécurité Site et administration exposés Surface déplacée vers l’API
Hébergement Une pile Deux piles, deux factures
Pour qui La grande majorité des sites Plusieurs canaux, une équipe front dédiée

Questions fréquentes

Un site headless est-il plus rapide ?

Pas automatiquement. Un front statique bien conçu peut être très rapide, mais l’invalidation du cache, les requêtes vers l’API et le JavaScript côté navigateur peuvent annuler ce gain. WordPress VIP prévient lui-même que, sans l’équipe adaptée, le résultat risque d’être plus lent.

WPGraphQL fait-il partie du cœur de WordPress ?

Non. C’est un plugin canonique, annoncé comme tel en octobre 2024 et maintenu dans son propre dépôt. La REST API reste l’API intégrée au cœur.

Peut-on garder Yoast SEO en headless ?

Oui, pour les métadonnées, qu’il expose par la REST API ou par un plugin GraphQL communautaire. Le plan du site, le fichier robots.txt, les redirections et les adresses canoniques doivent en revanche être gérés par le front.

Une boutique WooCommerce headless est-elle réaliste ?

Oui, avec la Store API, mais c’est un projet conséquent : panier, sessions, paiement et plugins de la boutique doivent être repensés. Pour la plupart des boutiques, un thème rapide et un checkout optimisé donnent de meilleurs résultats pour un coût bien moindre.

Combien coûte l’hébergement d’un front ?

Pour un site professionnel, comptez au minimum l’offre Pro de Vercel, 20 dollars par mois et par développeur, ou une offre payante de Netlify, dont l’offre gratuite met le site en pause une fois ses 300 crédits mensuels consommés, en plus de l’hébergement de WordPress. Le premier poste de dépense reste le temps de développement et de maintenance du front.

Conclusion

Le headless n’améliore pas un site par lui-même. Il déplace le travail : moins de contraintes côté affichage, davantage de responsabilités côté développement, sécurité de l’API, cache et référencement. Vox Media en a tiré un bénéfice réel, avec une équipe et des moyens que peu d’organisations réunissent.

Posez-vous trois questions avant de vous lancer. Avez-vous plusieurs canaux à alimenter, ou un front que le thème ne permet vraiment pas de construire ? Disposez-vous d’une équipe capable de maintenir deux applications dans la durée ? Vos rédacteurs accepteront-ils de perdre une partie du confort de l’éditeur ? Si l’une des réponses est non, un WordPress classique bien optimisé, ou une approche hybride, vous servira mieux.

Sources

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.

Francis Rozange

Ancien chef de rubrique à Libération, il dirige LaFactory, agence web internationale depuis 1996.

Panier