WordPress headless + Next.js : avantages et inconvénients vécus

L'été StartingUp. Nous mettons ce temps calme à profit pour cartographier une année dense et en livrer un compte-rendu sans fard. Après vous avoir montré comment nous hébergeons nos applications Next.js sur notre propre VPS, nous ouvrons le capot du site que vous êtes en train de lire : un WordPress headless couplé à Next.js, avec ses avantages réels et ses inconvénients que l'on tait trop souvent.

Le site sur lequel vous lisez ces lignes n'est pas un site WordPress comme les autres. WordPress y existe bel et bien, mais vous ne le verrez jamais : il vit sur un serveur à part, ne sert aucune page au public et se consacre à une seule mission, gérer le contenu. Ce que votre navigateur affiche, c'est une application Next.js qui va chercher ce contenu et le met en scène. C'est le principe du headless : un WordPress « sans tête », dont le visage est rendu par une autre technologie.

Ce choix d'architecture, nous ne l'avons pas fait sur le papier : nous le faisons vivre au quotidien, avec ses vraies victoires et ses vraies factures. Voici ce que nous dirions à un décideur qui nous demanderait, aujourd'hui, s'il doit s'y engager.

En résumé : le WordPress headless apporte une sécurité renforcée, des performances de premier ordre et une liberté de design totale. En contrepartie, il impose deux applications à maintenir, un ticket de développement pour chaque nouveau bloc d'édition et un budget supérieur à celui d'un WordPress classique. Le reste de cet article détaille chacun de ces points, tels que nous les vivons en production.

Concrètement, notre site est composé de deux applications distinctes. Côté back, un WordPress classique en apparence : les rédacteurs y écrivent leurs articles dans Gutenberg, les champs structurés sont gérés avec ACF, les formulaires avec Gravity Forms. La différence est qu'il n'a plus de thème public : il expose son contenu à travers une API GraphQL (l'extension WPGraphQL). Côté front, une application Next.js (App Router, React, Tailwind CSS) interroge cette API, rend les pages sur le serveur et les livre au visiteur. Le tout tourne dans des conteneurs Docker en développement et se déploie de façon reproductible en production.

Retenez l'essentiel : l'équipe contenu ne change rien à ses habitudes, elle travaille dans le back-office WordPress qu'elle connaît. Ce sont les visiteurs qui, sans le savoir, ne touchent plus jamais à WordPress.

La majorité des attaques visant WordPress passent par sa face publique : page de connexion scannée en boucle, failles de plugins exploitées via les pages servies aux visiteurs. En headless, cette face publique n'existe plus. Le WordPress vit sur son propre domaine, ne sert que son API, et peut être filtré bien plus strictement qu'un site vitrine classique. Soyons précis : la surface d'attaque n'est pas nulle, une API reste exposée et les mises à jour restent indispensables. Mais elle est réduite, cloisonnée, et une éventuelle compromission du back n'emporte pas le site que voient vos clients.

Un WordPress traditionnel construit chaque page en PHP, en empilant souvent les plugins de cache pour compenser. Ici, Next.js génère les pages côté serveur et les sert pré-construites, avec des images automatiquement redimensionnées et converties aux formats modernes. Les moteurs de recherche reçoivent un HTML complet et rapide, sans dépendre d'une pile de plugins d'optimisation. Nous ne vous vendrons pas de pourcentage magique : les gains dépendent de ce que vous quittez. Mais le rendu serveur et la maîtrise fine de chaque kilooctet livré constituent, pour un site dont le trafic SEO est stratégique, une fondation qu'aucun réglage de thème n'égale.

Le front étant du code sur mesure, il n'y a plus de thème à contourner ni de builder à amadouer : animations, mise en page, composants interactifs, tout est possible, exactement comme sur n'importe quelle application React. Et parce que le back reste un WordPress standard, il conserve tout son écosystème : c'est d'ailleurs ce qui nous a permis de le brancher sur Claude via MCP pour piloter le contenu depuis un assistant IA. La séparation ne ferme pas de portes côté back-office, elle en ouvre côté front.

C'est le prix d'entrée, et il ne se négocie pas. Deux bases de code, deux chaînes de mises à jour (le cœur WordPress et ses extensions d'un côté, Next.js, React et leurs dépendances de l'autre), deux déploiements, deux choses à surveiller la nuit. Le profil capable d'intervenir des deux côtés, à l'aise en React comme dans les entrailles de WordPress, est aussi plus rare sur le marché qu'un intégrateur WordPress classique. Si votre prestataire disparaît, la succession est plus exigeante à organiser.

Voici le coût que les articles enthousiastes sur le headless oublient systématiquement. Quand un rédacteur insère un bloc dans Gutenberg, WordPress sait le rendre ; notre front, lui, ne sait rien. Chaque type de bloc doit être ré-implémenté côté Next.js. Notre parseur de contenu fonctionne en liste blanche : une quinzaine de blocs sont reconnus et soigneusement rendus (paragraphes, titres, listes, citations, tableaux, images, code, vidéos YouTube), et tout bloc hors de cette liste s'affiche en mode dégradé. Envie d'une galerie, d'un accordéon, d'un nouveau plugin d'édition ? Ce n'est plus une case à cocher, c'est un ticket de développement.

Dans un WordPress classique, « Prévisualiser » fonctionne, tout simplement. En headless, l'aperçu d'un brouillon, les révisions, la mise à jour instantanée d'une page déjà en cache : chacun de ces conforts demande une plomberie dédiée entre les deux applications. Nous avons par exemple dû écrire le mécanisme qui prévient le front, à chaque publication, que telle page doit être régénérée. Rien d'insurmontable, mais rien de gratuit non plus : ce sont des jours de travail pour retrouver ce que le monolithe offrait nativement.

La ligne de partage tient en une question : qui doit avoir la main sur la forme ? Si la réponse est « l'équipe éditoriale, au quotidien, sans intermédiaire », le headless la frustrera. Si la réponse est « la marque, avec un niveau d'exigence que les thèmes ne permettent pas », il la servira.

Après l'avoir pratiquée en conditions réelles, notre conviction est simple : l'architecture headless échange de la simplicité opérationnelle contre de la maîtrise. Nous avons accepté deux applications à entretenir, un parseur de blocs à faire grandir et une prévisualisation à recâbler, parce que la sécurité, les performances et la liberté de design obtenues en retour servent directement ce que ce site doit accomplir. Pour d'autres projets, nous recommandons sans hésiter un WordPress classique, et nous continuerons de le faire.

Méfiez-vous donc des deux discours symétriques : celui qui présente le headless comme l'avenir obligatoire de WordPress, et celui qui le réduit à un caprice de développeurs. C'est un arbitrage d'architecture, qui se décide comme tous les arbitrages : en regardant ce que votre site doit faire, qui le fera vivre, et ce que vous êtes réellement prêt à payer, en euros et en organisation, pour la maîtrise totale de votre vitrine.