Headless WordPress avec Next.js : le guide honnête (et quand l'éviter)

01Qu'est-ce que le headless WordPress, concrètement

Dans un WordPress classique, le même logiciel gère deux choses : l'administration du contenu (le back-office wp-admin) et l'affichage public (le thème PHP qui génère les pages HTML). Le « headless » découple ces deux rôles. WordPress devient une pure source de contenu, exposée via une API — soit l'API REST native, soit GraphQL via l'extension WPGraphQL. Un frontend séparé, ici Next.js, consomme cette API et génère les pages. On parle de « headless » (sans tête) parce qu'on coupe la tête d'affichage de WordPress pour la remplacer. Pour comprendre les briques, voir nos définitions du [headless WordPress](/lexique/headless-wordpress), de [WPGraphQL](/lexique/wpgraphql) et des [React Server Components](/lexique/react-server-components-rsc) qui changent la donne côté Next.js. L'éditeur garde son confort Gutenberg ; le visiteur reçoit une page Next.js optimisée.

02Quand le headless a du sens — et quand c'est une régression

Soyons direct : 90% des sites WordPress n'ont aucun besoin de passer en headless. Si votre site est un site vitrine, un blog, ou une boutique WooCommerce standard, un thème WordPress bien développé (code propre, pas de page builder lourd) atteint déjà d'excellentes performances pour une fraction du coût. Le headless se justifie dans des cas précis : (1) vous avez déjà une équipe ou un budget Next.js, et WordPress n'est qu'une des sources de données parmi d'autres ; (2) vous avez besoin d'interactions front très riches (application web, dashboards, temps réel) que le modèle de thème PHP rend pénibles ; (3) vous mutualisez un même back-office de contenu sur plusieurs frontends (site + app + bornes). En dehors de ces cas, le « faux headless » — mettre Next.js juste pour gagner des points Lighthouse — est presque toujours une mauvaise affaire : vous payez 2 à 5 fois plus cher pour reconstruire ce que WordPress faisait gratuitement. Notre [comparateur Next.js vs WordPress](/comparateur/nextjs-vs-wordpress) détaille les arbitrages stack par stack.

03L'architecture WordPress + Next.js + WPGraphQL en pratique

L'architecture type qu'on déploie : WordPress tourne sur un hébergement PHP classique (mutualisé ou VPS), rôle 100% back-office, bloqué à l'indexation. WPGraphQL expose le contenu en GraphQL. Next.js, hébergé sur Vercel, interroge cette API au build (génération statique / ISR) ou à la demande (rendu serveur). Les pages sont régénérées via revalidation à la sauvegarde d'un article (webhook WordPress → Next.js). Le visiteur ne touche jamais WordPress directement : il reçoit du HTML Next.js servi en edge. Côté requêtes, on récupère un article et ses métadonnées en une seule requête GraphQL typée, ce qui évite les multiples allers-retours de l'API REST.

// app/blog/[slug]/page.tsx — récupération via WPGraphQL
async function getPost(slug: string) {
  const res = await fetch(process.env.WPGRAPHQL_URL!, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      query: `query Post($slug: ID!) {
        post(id: $slug, idType: SLUG) {
          title
          content
          date
          modified
          seo { title metaDesc }   # via WPGraphQL for Yoast
        }
      }`,
      variables: { slug },
    }),
    // ISR : revalide via webhook on-publish, sinon toutes les heures
    next: { revalidate: 3600, tags: [`post:${slug}`] },
  });
  const { data } = await res.json();
  return data.post;
}

04Le coût réel : ce que les plugins faisaient gratuitement

C'est le point que les articles enthousiastes oublient. En headless, vous perdez l'écosystème de plugins WordPress côté affichage — et environ 40% de l'effort de migration consiste à recoder à la main ce qui était gratuit : le formulaire de contact (plus de Contact Form 7, il faut une route API + anti-spam), le balisage Schema.org (plus de plugin SEO automatique, voir notre [guide Schema.org pour agences](/blog/schema-org-agences-web)), les redirections, le sitemap, l'aperçu en éditeur (Gutenberg affiche le thème par défaut, pas votre frontend Next.js — le bouton « Aperçu » devient inutile sans travail supplémentaire), le cache et sa revalidation, la gestion des formulaires, les embeds, les shortcodes. Chacun de ces éléments devient un mini-projet. Sur un budget de PME, ça transforme un site à 5 000 € en projet à 15 000-25 000 €. Pour un comparatif des coûts d'hébergement entre les deux mondes, voir [Vercel vs OVH](/blog/vercel-vs-ovh-hebergement-2026).

05Performance & SEO : le vrai gain, mesuré

Quand le headless est bien fait, le gain de performance est réel : un frontend Next.js avec rendu serveur et images optimisées atteint des Core Web Vitals excellents sans bidouille. Là où un WordPress mal optimisé peine à passer sous 2,5s de LCP sur mobile, un Next.js bien construit y arrive nativement. Mais attention au piège : un thème WordPress développé proprement (sans Elementor/Divi, avec un cache correct et WP Rocket) atteint AUSSI de très bons scores. Le headless n'est pas magique — il supprime juste le plafond de verre des thèmes lourds. Pour mesurer objectivement, on s'appuie sur notre [méthode d'audit Lighthouse](/blog/audit-lighthouse-methode-agence) et notre lecture des [Core Web Vitals 2026 où l'INP a remplacé le FID](/blog/core-web-vitals-2026-inp). Le SEO, lui, est neutre côté technique : Google indexe parfaitement le HTML rendu par Next.js, à condition que le rendu serveur soit bien configuré (pas de contenu critique chargé uniquement côté client).

06Notre retour d'expérience agence

Sur nos projets, on applique une règle simple : on ne propose le headless que si le client coche une des trois cases qui le justifient (équipe/budget Next.js existant, front très interactif, multi-frontend). Pour un site vitrine ou une boutique standard, on recommande un WordPress sur mesure bien développé — c'est plus rapide à livrer, moins cher à maintenir, et le client reste autonome. Quand le headless est justifié, on construit l'architecture WordPress + WPGraphQL + Next.js + Vercel décrite plus haut, en budgétisant honnêtement le recodage des fonctionnalités perdues dès le devis. La pire situation, qu'on refuse de vendre : le « headless pour faire moderne » sur un projet qui n'en a pas besoin. Ça coûte cher au client pour un bénéfice marginal. Notre rôle d'agence, c'est aussi de dire non au sur-engineering.