WordPress Headless CMS : Guide du Développeur [2026]

WordPress propulse 43 % de tous les sites web selon W3Techs, et un nombre croissant d'équipes supprime entièrement le frontend PHP pour utiliser WordPress comme une API de contenu. Voici tout ce qu'il faut savoir sur WordPress en mode headless — du choix entre REST API et WPGraphQL au déploiement d'un frontend Next.js sur Vercel avec ISR.

Qu'est-ce que WordPress Headless ? (Et Pourquoi s'y Intéresser ?)

WordPress headless désigne une configuration où WordPress gère le contenu et son stockage, tandis qu'une application frontend séparée — construite avec Next.js, Nuxt, Astro ou n'importe quel framework — récupère ce contenu via une API. WordPress conserve son tableau de bord d'administration, son éditeur, son écosystème de plugins et sa base de données MySQL. Mais au lieu de générer des pages avec des thèmes PHP, il expose le contenu via la WordPress REST API ou WPGraphQL, et votre frontend prend entièrement en charge la couche de présentation.

Imaginez-le ainsi : WordPress devient la cuisine, et votre framework frontend est le restaurant. La cuisine prépare les plats (le contenu), mais le restaurant décide comment les dresser, à quoi ressemble la salle, et comment les clients vivent l'expérience.

Architecture Traditionnelle vs Headless

Dans un WordPress traditionnel, tout est monolithique. Un visiteur demande une page, PHP traite la requête, interroge MySQL, la fait passer par les fichiers de template de votre thème, et renvoie du HTML rendu. Le thème contrôle la mise en page, le style, le routage — tout.

Dans WordPress headless, on supprime toute cette couche de rendu. WordPress se retrouve derrière une API, généralement sur un hébergement managé comme WP Engine ou Kinsta. Votre frontend — une application React, Vue ou Svelte — fait des requêtes API pour récupérer le contenu, puis le rend comme bon lui semble. Les deux systèmes peuvent vivre sur des serveurs complètement différents, avec des stacks techniques et des pipelines de déploiement distincts.

Il y a une subtilité que 9 guides sur 10 passent sous silence : découlé et headless ne signifient pas exactement la même chose. WordPress découplé peut encore recourir au rendu PHP pour certaines pages (comme la zone d'administration ou les routes héritées). Totalement headless signifie que le frontend WordPress est complètement désactivé — c'est uniquement API, sans aucun rendu de thème. Dans ce guide, c'est l'approche totalement headless dont il s'agit.

Quand Passer en Headless (et Quand Rester Traditionnel) ?

Passer en headless a du sens quand votre équipe dispose de développeurs frontend qui veulent travailler avec des outils modernes, quand vous devez diffuser du contenu sur plusieurs canaux (web, application mobile, affichage digital), ou quand les performances sont non négociables. Ce n'est pas pertinent pour tout le monde, et l'admettre honnêtement vous évitera des semaines d'efforts gaspillés.

Passez en Headless Quand...

• Votre équipe maîtrise déjà React/Vue/Svelte. Si vos développeurs frontend écrivent du JSX toute la journée, les forcer à utiliser des thèmes PHP revient à demander à un chef de cuisiner au micro-ondes.
• Vous avez besoin d'une diffusion multi-canal. Un seul backend WordPress peut alimenter votre site marketing, votre application mobile et votre borne en magasin via la même API.
• Les performances sont une exigence absolue. Les pages statiques servies depuis un edge CDN seront toujours plus rapides que le rendu PHP sur un serveur mutualisé.
• Vous gérez un WooCommerce headless. Les frontends e-commerce complexes bénéficient énormément des storefronts React/Next.js sur mesure.
• Vous voulez une DX moderne. Hot module replacement, TypeScript, bibliothèques de composants, CI/CD — la chaîne d'outils frontend complète.

Restez Traditionnel Quand...

• Vos éditeurs de contenu ont besoin d'un aperçu en direct et de page builders. Gutenberg, Elementor et WPBakery supposent un thème traditionnel. Passer en headless détruit la plupart des workflows d'édition visuelle.
• Vous êtes développeur solo ou petite équipe. Le headless ajoute 40 à 60 % de complexité à l'installation. Si vous maintenez un blog seul, un thème traditionnel est bien plus simple.
• Vous dépendez fortement de plugins frontend. Formulaires de contact, plugins SEO (Yoast génère les balises méta côté serveur), bandeaux de consentement aux cookies — tous supposent un rendu PHP.
• Le budget est serré. Vous aurez besoin d'un hébergement séparé pour WordPress et votre frontend. Ce sont deux factures au lieu d'une.

REST API vs WPGraphQL : Choisir sa Couche de Données

WordPress vous offre deux façons de récupérer du contenu en configuration headless : la REST API intégrée et le plugin WPGraphQL. La REST API est fournie avec le cœur de WordPress et fonctionne sans configuration — aucun plugin n'est nécessaire. WPGraphQL nécessite l'installation d'un plugin, mais vous permet d'interroger exactement les champs dont vous avez besoin, éliminant le problème de sur-récupération qui affecte REST. D'après notre expérience, WPGraphQL l'emporte pour la plupart des projets, mais la REST API présente un avantage souvent sous-estimé : la mise en cache HTTP native.

WordPress REST API : L'Option Intégrée

La REST API est disponible sur toutes les installations WordPress depuis la version 4.7 (décembre 2016). Appelez /wp-json/wp/v2/posts et vous récupérez du JSON. Simple, bien documentée, et ça fonctionne sans aucune configuration.

Le problème ? La sur-récupération. Quand vous demandez un article, WordPress renvoie tout : contenu rendu, contenu brut, extrait, ID de l'auteur, ID du média mis en avant, catégories, tags, champs meta, GUID, statut des commentaires, statut du ping, template, et une quinzaine d'autres champs dont vous n'avez probablement pas besoin. Pour une page de listing de blog où vous n'avez besoin que des titres, slugs et extraits, vous transférez 3 à 5 fois plus de données que nécessaire.

// REST API : Récupérer 5 articles récents avec auteur et catégories
const res = await fetch(
  'https://your-site.com/wp-json/wp/v2/posts?per_page=5&_embed'
);
const posts = await res.json();

// Le paramètre _embed inclut les objets auteur et catégorie
// Mais renvoie aussi TOUS les champs de chaque article — ~8 Ko par article
// Pour 5 articles, on parle de ~40 Ko de JSON

Vous pouvez utiliser le paramètre _fields pour limiter les champs retournés (?_fields=id,title,slug,excerpt), mais ça ne résout pas le problème avec les ressources embarquées, et vous ferez quand même plusieurs requêtes si vous avez besoin de données liées.

WPGraphQL : Ne Récupérez que ce dont Vous Avez Besoin

WPGraphQL est un plugin open source gratuit de Jason Bahl (maintenant maintenu par WP Engine) qui ajoute une API GraphQL complète à WordPress. Vous écrivez une requête en spécifiant exactement les champs voulus, et vous obtenez exactement cela — ni plus, ni moins.

# WPGraphQL : Même requête — 5 articles récents avec auteur et catégories
query RecentPosts {
  posts(first: 5) {
    nodes {
      title
      slug
      excerpt
      date
      author {
        node {
          name
        }
      }
      categories {
        nodes {
          name
          slug
        }
      }
    }
  }
}

# Réponse : ~2 Ko de JSON précisément structuré
# Pas de champs superflus, pas de données inutiles

Comparaison Côte à Côte

Voici à quoi ressemblent concrètement les réponses :

Que Choisir ?

Optez pour REST quand vous construisez quelque chose rapidement, que votre équipe ne connaît pas GraphQL, ou que vous avez besoin d'une mise en cache HTTP agressive sans outillage supplémentaire.

Optez pour WPGraphQL quand vous construisez un frontend de production avec des besoins de données complexes, que vous voulez des payloads plus légers, ou que votre équipe utilise déjà GraphQL ailleurs.

Verdict tranché : Pour un projet WordPress headless sérieux avec Next.js, WPGraphQL est le meilleur choix. Les économies sur les données, l'expérience développeur avec l'IDE GraphiQL et la récupération en requête unique en valent la dépendance au plugin.

Configurer WordPress comme un CMS Headless

Configurer WordPress en CMS headless se fait en six étapes : installer WordPress, ajouter les bons plugins, configurer votre modèle de contenu, désactiver le thème frontend, mettre en place l'authentification et vérifier que votre API fonctionne. Le tout prend environ 30 à 45 minutes si vous l'avez déjà fait, ou quelques heures la première fois.

Étape 1 : Commencez par une installation WordPress fraîche sur un hébergement managé. Kinsta, WP Engine et Cloudways proposent tous des environnements optimisés pour WordPress. Si vous testez simplement, une installation locale avec LocalWP convient parfaitement.

Étape 2 : Installez les plugins essentiels :

Étape 3 : Créez votre modèle de contenu avec ACF. Définissez des groupes de champs qui correspondent à vos composants frontend. Un type de contenu portfolio pourrait avoir des champs pour projectUrl, techStack (répéteur), clientName et projectYear.

Plugins Essentiels

WPGraphQL for ACF mérite une attention particulière. Sans lui, vos champs ACF n'apparaîtront pas dans les requêtes GraphQL. Une fois installé, vous pouvez interroger les champs personnalisés comme ceci :

query PortfolioProjects {
  projects(first: 10) {
    nodes {
      title
      slug
      projectFields {
        projectUrl
        clientName
        techStack
        projectYear
      }
    }
  }
}

Désactiver le Frontend WordPress

Étape 4 : Vous ne voulez pas que les visiteurs arrivent sur votre URL WordPress et voient un thème cassé. Ajoutez ceci dans le functions.php de votre thème ou utilisez un mu-plugin :

// Rediriger toutes les requêtes frontend vers l'API
add_action('template_redirect', function () {
    if (!is_admin() && !wp_doing_ajax() && !defined('REST_REQUEST') && !defined('GRAPHQL_REQUEST')) {
        wp_redirect('https://your-frontend-domain.com');
        exit;
    }
});

Étape 5 : Configurez les Application Passwords pour l'authentification. Allez dans Utilisateurs > Votre profil > Mots de passe d'application, générez un mot de passe et utilisez-le pour les requêtes API authentifiées (créer/mettre à jour du contenu depuis des outils externes).

Tester Votre API

Étape 6 : Ouvrez votre navigateur et accédez à https://your-site.com/graphql — vous devriez voir l'IDE GraphiQL. Essayez d'interroger vos articles. Si vous utilisez REST, naviguez vers https://your-site.com/wp-json/wp/v2/posts et vérifiez que vous obtenez du JSON en retour.

Conseil pratique : l'IDE GraphiQL fourni avec WPGraphQL est vraiment excellent pour explorer votre schéma. Vous bénéficiez de l'autocomplétion, de la documentation et de l'historique des requêtes. C'est le moyen le plus rapide de comprendre quels champs sont disponibles et comment vos données ACF sont structurées.

Construire un Frontend Next.js avec WPGraphQL

La façon la plus propre de construire un frontend WordPress headless en 2026, c'est avec App Router de Next.js 15 et les React Server Components. Les Server Components récupèrent les données côté serveur sans envoyer de JavaScript au client, et WPGraphQL vous offre des requêtes précises — c'est une combinaison naturelle. Quand j'ai configuré WPGraphQL avec App Router pour la première fois, le plus grand piège était la gestion des images — mais nous y reviendrons.

Configuration du Projet et Variables d'Environnement

Commencez par un projet Next.js vierge. Vercel propose également un modèle de démarrage WordPress officiel si vous souhaitez une architecture de référence.

npx create-next-app@latest my-wp-frontend --typescript --app
cd my-wp-frontend

Créez .env.local avec vos endpoints WordPress :

WORDPRESS_API_URL=https://your-wordpress-site.com
NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT=https://your-wordpress-site.com/graphql

Créez maintenant un utilitaire GraphQL léger. Vous n'avez pas besoin d'Apollo ou d'urql pour les Server Components — un simple fetch fonctionne parfaitement car il n'y a pas d'état côté client à gérer :

// lib/wordpress.ts
const API_URL = process.env.NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT!;

export async function fetchGraphQL<T>(
  query: string,
  variables?: Record<string, unknown>
): Promise<T> {
  const res = await fetch(API_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ query, variables }),
    next: { revalidate: 3600 }, // ISR : revalider toutes les heures
  });

  const json = await res.json();
  if (json.errors) {
    throw new Error(json.errors[0].message);
  }
  return json.data;
}

Pour les options de frameworks React, consultez notre comparaison entre Next.js et React avec Vite — il existe de bonnes raisons de se passer du framework, bien que pour le travail avec un CMS headless, le SSR et l'ISR intégrés fassent de Next.js le choix le plus pragmatique. Si vous hésitez entre Next.js et Remix, nous détaillons cela dans notre article sur pourquoi nous recommandons Next.js pour la plupart des projets.

Récupérer des Articles avec les Server Components

Voici la page de listing du blog en tant que Server Component — pas de useEffect, pas d'états de chargement, pas d'hydratation côté client :

// app/blog/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import Link from 'next/link';

interface PostsData {
  posts: {
    nodes: Array<{
      title: string;
      slug: string;
      excerpt: string;
      date: string;
      author: { node: { name: string } };
    }>;
  };
}

const POSTS_QUERY = `
  query AllPosts {
    posts(first: 20, where: { status: PUBLISH }) {
      nodes {
        title
        slug
        excerpt
        date
        author {
          node {
            name
          }
        }
      }
    }
  }
`;

export default async function BlogPage() {
  const data = await fetchGraphQL<PostsData>(POSTS_QUERY);

  return (
    <main>
      <h1>Blog</h1>
      {data.posts.nodes.map((post) => (
        <article key={post.slug}>
          <Link href={`/blog/${post.slug}`}>
            <h2>{post.title}</h2>
          </Link>
          <p>{post.author.node.name} · {new Date(post.date).toLocaleDateString()}</p>
          <div dangerouslySetInnerHTML={{ __html: post.excerpt }} />
        </article>
      ))}
    </main>
  );
}

Pages d'Articles Dynamiques

Les pages d'articles individuelles utilisent generateStaticParams pour pré-rendre tous les articles au moment du build, puis l'ISR prend en charge le nouveau contenu :

// app/blog/[slug]/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import { notFound } from 'next/navigation';

const POST_QUERY = `
  query PostBySlug($slug: ID!) {
    post(id: $slug, idType: SLUG) {
      title
      content
      date
      author {
        node {
          name
          avatar {
            url
          }
        }
      }
      categories {
        nodes { name slug }
      }
    }
  }
`;

export async function generateStaticParams() {
  const data = await fetchGraphQL<{
    posts: { nodes: Array<{ slug: string }> };
  }>(`query { posts(first: 100) { nodes { slug } } }`);

  return data.posts.nodes.map((post) => ({ slug: post.slug }));
}

export default async function PostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const data = await fetchGraphQL<{ post: any }>(POST_QUERY, {
    slug,
  });

  if (!data.post) notFound();

  return (
    <article>
      <h1>{data.post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: data.post.content }} />
    </article>
  );
}

N'oubliez pas de configurer next.config.ts pour les images WordPress :

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-wordpress-site.com',
        pathname: '/wp-content/uploads/**',
      },
    ],
  },
};

export default nextConfig;

Déployer WordPress Headless en Production

Une configuration WordPress headless en production utilise un double hébergement : WordPress vit sur un hébergement WordPress managé (WP Engine, Kinsta ou Cloudways), tandis que le frontend Next.js se déploie sur une plateforme edge comme Vercel ou Netlify. Cette séparation permet à chaque couche d'évoluer indépendamment — WordPress gère l'édition de contenu et les requêtes API, tandis que le frontend sert des pages statiques et ISR depuis des nœuds edge CDN dans le monde entier.

Architecture d'Hébergement

Le flux de données ressemble à ceci : les éditeurs de contenu publient dans l'administration WordPress, WordPress stocke le contenu dans MySQL, le frontend Next.js récupère le contenu via WPGraphQL, Vercel génère du HTML statique à l'edge, et les visiteurs accèdent au CDN — sans jamais toucher WordPress directement.

Pour l'hébergement frontend, consultez notre comparaison Vercel vs Netlify pour une analyse détaillée. Les deux fonctionnent bien pour WordPress headless. Si vous envisagez des alternatives basées sur des conteneurs, notre comparaison Railway, Render et Fly.io couvre ces options.

ISR et Revalidation à la Demande

C'est la partie qui rend WordPress headless réellement viable en production. Nous avons constaté que la revalidation à la demande vaut l'effort de configuration, car sans elle, vous êtes coincé à choisir entre du contenu obsolète (longs intervalles de revalidation) et des builds lents (courts intervalles qui saturent votre API WordPress).

L'ISR vous permet de définir un délai de revalidate sur chaque page. Après cet intervalle, le prochain visiteur reçoit la page en cache pendant que Next.js la régénère en arrière-plan. Mais la vraie magie, c'est la revalidation à la demande — déclencher un rebuild à l'instant précis où le contenu est publié :

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidation-secret');

  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ message: 'Invalid secret' }, { status: 401 });
  }

  const body = await request.json();
  const slug = body.post?.post_name;

  if (slug) {
    revalidatePath(`/blog/${slug}`);
    revalidatePath('/blog'); // Revalider aussi la page de listing
  }

  return NextResponse.json({ revalidated: true });
}

Côté WordPress, ajoutez un webhook qui se déclenche sur publish_post à l'aide d'un plugin comme WP Webhooks, ou d'un simple snippet dans functions.php qui appelle votre endpoint /api/revalidate sur Vercel. Le contenu est ainsi mis en ligne en quelques secondes après avoir cliqué sur "Publier" — pas de rebuilds complets, pas d'attente. Consultez la documentation Next.js sur l'ISR pour plus d'options de configuration.

Récapitulatif des Coûts

WordPress Headless vs CMS Headless Natifs

Après avoir travaillé aussi bien avec WordPress headless qu'avec des CMS natifs comme Sanity, Contentful et Strapi, voici mon avis honnête : WordPress headless est un choix pragmatique quand vous avez un site WordPress existant ou une équipe éditoriale déjà formée. C'est rarement le meilleur choix quand on part de zéro.

Là où WordPress Headless Gagne

• Les éditeurs de contenu le connaissent déjà. L'interface d'administration de WordPress a 20 ans de raffinement. Former une équipe non technique à Sanity Studio ou à l'interface de Contentful prend des semaines.
• L'écosystème de plugins. Plus de 60 000 plugins. Besoin du multilingue ? WPML. E-commerce ? WooCommerce. Analyse SEO du contenu ? Yoast (fonctionne toujours dans l'administration). Aucun CMS natif headless n'égale cette richesse.
• Le recrutement. WordPress dispose du plus grand bassin de talents développeurs de tout CMS. Trouver un développeur WordPress est infiniment plus facile que trouver un spécialiste Sanity ou Payload.
• WooCommerce. Si vous avez besoin d'e-commerce headless avec du contenu WordPress, WooCommerce + WPGraphQL est un stack éprouvé. Saleor et Medusa sont des alternatives, mais WooCommerce a la part de marché.

Là où les CMS Natifs Headless Gagnent

• La modélisation de contenu. GROQ de Sanity, les types de contenu de Contentful et le schéma TypeScript de Payload sont conçus pour le contenu structuré depuis le départ. Le modèle post/page/type-personnalisé de WordPress donne l'impression d'avoir été bricolé après coup.
• La collaboration en temps réel. Sanity propose l'édition en temps réel à la Google Docs. Contentful a la collaboration en direct. WordPress ? Vous avez droit à un écran de verrouillage "Cet article est en cours de modification par quelqu'un d'autre".
• L'architecture API-first. WPGraphQL est brillant, mais c'est toujours un plugin posé sur un monolithe PHP. L'API de Contentful et l'API de Sanity ont été conçues API-first dès le premier jour.
• La gestion des médias. La médiathèque WordPress est fonctionnelle mais basique. Le pipeline d'images de Sanity avec recadrage automatique, hotspots et diffusion CDN est dans une autre catégorie. Contentful et Storyblok s'intègrent nativement avec Cloudinary.
• L'expérience développeur. Strapi et Payload offrent une expérience de développement local avec hot-reload sur les changements de schéma. WordPress demande de rafraîchir l'administration et d'exécuter des migrations de base de données.

Verdict : Que Choisir ?

Utilisez WordPress headless quand : vous avez un site WordPress existant avec des années de contenu, vos éditeurs refusent d'apprendre un nouveau CMS, vous avez besoin de WooCommerce, ou vous avez besoin d'un plugin WordPress spécifique qui n'a pas d'équivalent ailleurs.

Optez pour un CMS headless natif quand : vous démarrez un nouveau projet de zéro, vous avez besoin de collaboration en temps réel, votre modèle de contenu est complexe et structuré, ou votre équipe valorise l'expérience développeur plus que la richesse des plugins.

Chez Techsy, nous avons construit des frontends WordPress headless pour des clients migrant depuis un WordPress traditionnel. Notre approche habituelle : WPGraphQL + Next.js App Router sur Vercel, avec ISR pour les performances et la revalidation à la demande pour la fraîcheur du contenu. Obtenez une consultation gratuite ->

WordPress MCP et l'Abilities API : L'Avenir avec l'IA

WordPress 6.9 a introduit l'Abilities API, qui est en cours d'intégration dans le cœur de WordPress 7.0 (avril 2026). Elle crée une interface standardisée, typée et découvrable pour les fonctionnalités de WordPress — imaginez WordPress qui expose ses capacités dans un format lisible par les machines que les outils d'IA peuvent comprendre et utiliser.

Le WordPress MCP Adapter fait le pont entre cette Abilities API et le Model Context Protocol (MCP), le standard ouvert pour connecter les systèmes d'IA à des outils externes. Concrètement, qu'est-ce que cela signifie ? Les agents IA dans Claude, Cursor ou VS Code peuvent maintenant découvrir ce que votre site WordPress est capable de faire, puis exécuter ces actions directement.

Voici un scénario concret : Claude peut créer un article WordPress, remplir des champs ACF avec des données structurées, assigner des catégories, définir une image mise en avant et déclencher votre webhook de revalidation Vercel — le tout en une seule conversation. Sans navigateur, sans panneau d'administration, sans copier-coller.

C'est encore au stade expérimental, et le MCP adapter est toujours en évolution. Mais cela envoie un signal important : WordPress ne reste pas les bras croisés pendant que les CMS headless natifs innovent. La combinaison Abilities API + MCP pourrait faire de WordPress l'un des CMS les plus accessibles aux IA, en exploitant son gigantesque écosystème de plugins d'une façon que les plateformes plus récentes et plus petites ne peuvent pas égaler. Lisez l'annonce officielle sur le WordPress Developer Blog pour tous les détails techniques.

Performances : WordPress Headless vs WordPress Traditionnel

WordPress headless avec un frontend statique améliore considérablement les performances par rapport à un WordPress traditionnel rendu en PHP. WordPress traditionnel sert des pages dynamiques en exécutant PHP à chaque requête, ce qui entraîne un Time to First Byte (TTFB) médiocre — selon des données de performance de mi-2025, seulement 31 % des clients WordPress desktop et 24 % sur mobile obtiennent de bons scores TTFB. Passer en headless avec Next.js et ISR signifie que les pages sont pré-rendues et servies depuis des nœuds edge CDN, faisant tomber le TTFB à moins de 100 ms pour les pages en cache.

L'étude de cas de WP Engine sur Android Authority montre une amélioration de 6x des scores de performance Lighthouse après migration vers WordPress headless. Les données Core Web Vitals racontent la même histoire : seulement 45 % des sites WordPress réussissent les trois métriques CWV sur mobile, contre 65 % pour Shopify et 83 % pour Duda.

Un avertissement important : le headless ne corrige pas un backend WordPress lent. Si votre API WordPress met 3 secondes à répondre parce que vous êtes sur un hébergement mutualisé bon marché avec 40 plugins, votre régénération ISR sera lente aussi. Le frontend ne peut pas être plus rapide que l'API dont il dépend. Investissez dans un hébergement managé de qualité — c'est encore plus important en configuration headless. Le blog de Weston Ruter, lead performance WordPress, contient d'excellentes données sur ce qui fait vraiment bouger le curseur côté serveur.

FAQ

Qu'est-ce que WordPress headless ?

WordPress headless est une architecture où WordPress sert uniquement de backend de gestion de contenu, avec son thème frontend PHP complètement désactivé. Le contenu est diffusé via la REST API ou WPGraphQL vers une application frontend séparée construite avec des frameworks comme Next.js, Nuxt ou Astro. Le tableau de bord d'administration WordPress reste entièrement fonctionnel pour les éditeurs de contenu.

WordPress est-il un bon CMS headless ?

WordPress fonctionne bien comme CMS headless quand vous avez un site WordPress existant, des éditeurs qui connaissent l'interface, ou quand vous avez besoin de l'écosystème de plugins (notamment WooCommerce). Il est moins idéal que les CMS headless natifs comme Sanity ou Contentful pour partir de zéro, car la modélisation de contenu et l'API de WordPress ont été ajoutées après coup plutôt que conçues API-first.

Quels sont les inconvénients de WordPress headless ?

Les principaux inconvénients sont : une complexité accrue (deux environnements d'hébergement au lieu d'un), la perte des fonctionnalités d'édition visuelle et de page builder, l'arrêt des plugins frontend (rendu des balises méta Yoast, formulaires de contact, bandeaux de cookies), l'absence de collaboration en temps réel sur le contenu, et l'API GraphQL qui est une dépendance à un plugin plutôt qu'une fonctionnalité cœur. Le budget augmente également puisque vous payez un hébergement WordPress plus un hébergement frontend.

Comment connecter Next.js à WordPress ?

Installez WPGraphQL sur votre site WordPress, puis créez un projet Next.js avec App Router. Définissez votre endpoint GraphQL WordPress comme variable d'environnement, écrivez un simple utilitaire de récupération GraphQL basé sur fetch, et utilisez-le dans les Server Components pour interroger les articles, pages et types de contenu personnalisés. Pas besoin d'Apollo ou d'urql — un simple fetch suffit car les Server Components s'exécutent côté serveur.

WPGraphQL vs REST API : lequel est le meilleur ?

WPGraphQL est meilleur pour les frontends de production car il ne retourne que les champs demandés (réduisant la taille des données de 60 à 80 %), supporte les requêtes imbriquées en une seule requête, et fournit un IDE GraphiQL pour explorer le schéma. La REST API est meilleure pour les prototypes rapides, les équipes qui ne connaissent pas GraphQL, ou quand la mise en cache HTTP native est critique sans outillage supplémentaire.

Combien coûte WordPress headless ?

Une configuration WordPress headless minimale coûte environ 14 $/mois — Cloudways pour l'hébergement WordPress et le niveau Hobby gratuit de Vercel pour le frontend. Une configuration de production avec WP Engine et Vercel Pro revient à 40-70 $/mois. Ajoutez 0-50 $/mois pour des plugins premium comme ACF Pro et WPML. Les CMS headless natifs ont souvent des offres gratuites généreuses, donc le coût seul n'est pas une raison de choisir WordPress headless.

Puis-je utiliser WooCommerce avec WordPress headless ?

Oui. WPGraphQL dispose d'une extension WooCommerce (WPGraphQL WooCommerce ou "WooGraphQL") qui expose les produits, commandes, panier et fonctionnalités de paiement via GraphQL. Cela vous permet de construire des storefronts React personnalisés avec toutes les capacités e-commerce. Le tunnel de paiement demande un travail supplémentaire par rapport aux thèmes WooCommerce traditionnels, mais les gains en performances et en UX sont significatifs pour les boutiques à fort trafic.

Faut-il un développeur pour configurer WordPress headless ?

Oui, une configuration WordPress headless nécessite des compétences en développement frontend — spécifiquement React (ou Vue/Svelte) et une bonne maîtrise des APIs. Vous devrez construire l'intégralité du frontend de zéro ou personnaliser un template de démarrage. Ce n'est pas une solution no-code. Les éditeurs de contenu peuvent toujours utiliser l'administration WordPress normalement, mais la configuration initiale et la maintenance frontend continue nécessitent l'intervention d'un développeur.

Quels plugins sont indispensables pour WordPress headless ?

Les plugins essentiels sont WPGraphQL (API GraphQL), Advanced Custom Fields ou ACF (modélisation de contenu structuré), et WPGraphQL for ACF (expose les champs personnalisés via GraphQL). Fortement recommandés : Custom Post Type UI pour enregistrer des types de contenu via l'administration, et un plugin webhook comme WP Webhooks pour déclencher des rebuilds frontend à la publication de contenu. Évitez les plugins dépendants du frontend comme le rendu des balises méta de Yoast SEO ou les plugins de formulaires.

WordPress headless est-il bon pour le SEO ?

WordPress headless peut être excellent pour le SEO quand il est correctement implémenté avec Next.js ou Nuxt, car vous bénéficiez du rendu côté serveur, de pages plus rapides (améliorant les Core Web Vitals) et d'un contrôle total sur les balises méta, les données structurées et la structure des URL. Le risque est de perdre les fonctionnalités SEO automatiques comme le rendu des balises méta de Yoast — vous devrez gérer manuellement les balises méta, les sitemaps et les données structurées dans votre code frontend.