WordPress sans tête sur Next.js ou Astro — gardez wp-admin, perdez la taxe des extensions.

WordPress sans tête est approprié quand l'une de trois choses est vraie. La configuration WordPress classique par défaut est mauvaise sinon — headless ajoute une charge d'ingénierie et vous ne devriez pas la payer sans une vraie raison.

La première raison est la performance. Un site WordPress vanilla avec cinq ou six plugins livre environ sept cents kilooctets de JavaScript avant que le H1 ne s'affiche, et avec Elementor ou Divi plus une pile d'extensions typique, les sites réels livrent deux à trois mégaoctets au premier chargement. Il existe un plafond dur sur Lighthouse et les données de terrain CrUX même avec le meilleur plugin de cache devant. Headless sur un front-end Next.js ou Astro statique ou ISR atteint régulièrement plus de quatre-vingt-quinze sur Lighthouse sur un hébergement mutualisé et les données de terrain suivent.

La deuxième raison est l'expérience d'ingénierie sans perdre l'équipe éditoriale. Les ingénieurs qui écrivent TypeScript au quotidien se frustrent avec la pile front-end WordPress. Les templates PHP, jQuery, les shortcodes du page builder — le langage ne convient pas, les outils ne conviennent pas, l'histoire du déploiement ne convient pas. Headless permet à l'équipe d'ingénierie de travailler dans une base de code Next.js ou Astro avec contrôle de version, vérification de type, déploiement sur edge, et design piloté par composants tandis que les éditeurs gardent wp-admin, Yoast, et ACF inchangés.

La troisième raison est les destinations multiples. Un site marketing, une application mobile, un portail interne, et un portail partenaire lisant tous la même source de contenu. WordPress classique est un CMS, un front-end. WordPress headless devient le back-end éditorial pour toutes les destinations dont vous avez besoin, chacune avec son propre framework front-end optimisé pour sa surface.

Trois décisions structurent la majorité de l'histoire technique.

Le framework front-end est généralement Next.js avec App Router pour les sites marketing et les applications avec authentification ou interactivité. Astro est le chemin le plus simple pour les sites riches en contenu qui bénéficient de la génération statique et n'ont besoin que d'une hydratation partielle sur des composants spécifiques. Nuxt est le bon choix quand l'équipe utilise déjà Vue. Nous utilisons par défaut Next.js plus WPGraphQL plus un petit échafaudage personnalisé plutôt que Faust.js parce que Faust livre des opinions avec lesquelles nous ne sommes parfois pas d'accord — mais Faust est excellent si vous voulez que le framework prenne les décisions pour vous.

La couche API est WPGraphQL par défaut. API typée requête-par-forme, support ACF via WPGraphQL for ACF, support Yoast via Yoast SEO for WPGraphQL, équivalent RankMath. WP REST fonctionne sans plugin et convient aux sites simples, mais vous récupérez plus de données que vous n'en avez besoin et il n'y a pas d'introspection de schéma sur le front-end. Recourez à REST uniquement quand WPGraphQL est bloqué par la politique d'hébergement ou quand vous avez un ensemble de données très petit.

L'hébergement sépare le front-end du back-end. Front-end sur Vercel, Netlify, ou Cloudflare Pages selon la préférence de l'équipe. Back-end sur Cloudways, Kinsta, ou WP Engine sur un sous-domaine non public — cms.yourdomain.com — verrouillé derrière Cloudflare Access ou une liste blanche d'adresses IP. Le trafic public ne frappe jamais WordPress directement. WordPress devient invisible du web public ; seuls vos éditeurs savent qu'il est là.

Une construction headless WordPress réussie transporte cinq choses du côté WordPress vers le front-end public sans perdre de fidélité en chemin.

Le contenu est le plus évident — chaque article, page, type de publication personnalisé, taxonomie, et champ ACF, récupéré via WPGraphQL à la génération ou à la revalidation. Les médias suivent : chaque image téléchargée, avec optimisation WebP du côté WordPress si disponible ou optimisation d'image du côté front-end autrement. Les métadonnées SEO sont la troisième — les champs Yoast ou Rank Math pontés via les schémas GraphQL d'accompagnement de plugin, rendus sous forme de canonical, title, description, OG, et Twitter card à partir de la réponse typée.

Le schéma est le quatrième et la plupart des équipes le font mal. Nous remplaçons JSON-LD émis par les plugins par des templates écrits à la main sur le front-end pour une sortie plus propre. Article, BlogPosting, Service, Product, BreadcrumbList — tous générés à partir de données typées, validés au moment de la génération. Les redirections sont la cinquième : tout dans Yoast Redirect Manager ou le plugin Redirection est exporté et livré sous forme de 301s dans vercel.json ou _redirects sur Netlify, jamais comme des redirections JavaScript qui perdent le signal de classement en transit.

Le transport est automatisé. Nous ne construisons pas à la main l'une de ces couches par site. Le même échafaudage est livré dans chaque construction headless que nous faisons, ce qui explique pourquoi le coût par site a diminué au fil du temps même si la surface d'ingénierie a augmenté.

Les page builders cassent en premier. Elementor et Divi injectent du CSS et du HTML lourd dans le front-end. Rien de tout cela ne fonctionne sur un front-end headless. La plupart des migrations incluent une réécriture de contenu dans le projet — nous extrayons le contenu, le reformatons pour correspondre à la bibliothèque de composants du nouveau front-end, et nous ignoring complètement l'importation de la couche du page builder visuel. Les éditeurs obtiennent une nouvelle UX d'édition plus simple basée sur les blocs Gutenberg plus le contenu flexible ACF. Le contenu survit, le page builder visuel ne survit pas, et le poids de la page chute significativement comme effet secondaire.

Les commentaires et les formulaires ont aussi besoin d'une réflexion nouvelle. Les commentaires WordPress natifs ne s'affichent pas headless sans proxyfier le rendu. La plupart des équipes les remplacent par Disqus, Giscus, ou un système de commentaires custom sur le front-end. Les formulaires migrent généralement vers ConvertKit, HubSpot Forms, ou un endpoint Next.js custom qui appelle un service d'envoi d'email. Contact Form 7 et Gravity Forms ont des versions headless-friendly mais demandent une intégration GraphQL explicite qui ajoute du travail.

Les plugins front-end sont la troisième chose qui casse. Tout ce qui injecte du HTML ou du JavaScript dans le front-end WordPress cesse de fonctionner — plugins de sécurité, plugins de cache, plugins de schéma, plugins de partage social. Chacun est soit remplacé par du code sur le front-end soit par un service géré. Le nombre de plugins chute généralement de soixante-dix à quatre-vingts pour cent après la migration. C'est une partie de la victoire, pas une régression.