WordPress headless sur Next.js ou Astro, conservez wp-admin, oubliez la taxe des plugins.

WordPress headless est justifié quand l'une de trois conditions est vraie. L'installation WordPress classique par défaut est la bonne approche sinon, headless ajoute une surcharge 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 s'irritent de la stack front-end WordPress. Les templates PHP, jQuery, les raccourcis page builder, le langage est mauvais, l'outillage est mauvais, l'histoire du déploiement est mauvaise. 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 des types, déploiement edge et conception orientée 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 apps 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 ne nécessitent une hydratation partielle que sur des composants spécifiques. Nuxt est le bon choix quand l'équipe exécute déjà Vue. Nous préférons Next.js plus WPGraphQL plus un petit scaffolding personnalisé plutôt que Faust.js parce que Faust embarque 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 à votre place.

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, protégé par Cloudflare Access ou une liste blanche 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 l'évidence, chaque post, page, type de post personnalisé, taxonomie et champ ACF, récupérés via WPGraphQL à la compilation ou à la revalidation. Les médias suivent : chaque image uploadée, avec optimisation WebP côté WordPress si disponible ou optimisation d'image côté front-end sinon. Les métadonnées SEO sont la troisième, les champs Yoast ou Rank Math pontés via des schémas GraphQL complémentaires de plugin, rendus en canonical, title, description, OG et Twitter card à partir de la réponse typée.

Le schéma est la quatrième et la plupart des équipes le gèrent mal. Nous remplaçons le 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 à la compilation. Les redirections sont la cinquième : tout dans Yoast Redirect Manager ou le plugin Redirection est exporté et livré comme des 301 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 lourds dans le front-end. Rien de tout cela ne s'exécute sur un front-end headless. La plupart des migrations livrent une réécriture de contenu dans le cadre du projet, nous extrayons le contenu, le reformatons pour correspondre à la bibliothèque de composants du nouveau front-end, et oublions d'importer complètement la couche visual builder. 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 visual builder ne survit pas, et le poids de la page baisse considérablement 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 arrête de fonctionner, les plugins de sécurité, les plugins de cache, les plugins de schéma, les 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 typiquement de soixante-dix à quatre-vingts pour cent après la migration. C'est une partie de la victoire, pas une régression.