WordPress Headless avec Next.js

WordPress headless signifie que le back-end WordPress (base de données, admin, workflow éditorial) reste en place, mais qu'un front-end séparé — généralement Next.js — gère ce que voient les visiteurs. Les deux communiquent via une API (WPGraphQL ou REST). Les éditeurs gardent leur interface, le site public passe sur une stack moderne.

Pas toujours. Pour un site vitrine de moins de 20 pages sans problème de performance et avec une équipe éditoriale satisfaite, le WordPress classique reste le choix le plus simple. Le headless devient rentable quand il faut viser le vert sur Core Web Vitals, une isolation sécurité avancée, une diffusion multi-canal, ou des fonctionnalités front que la couche thème WordPress rend difficiles.

Chez Next Impact, un site WordPress Headless + Next.js standard démarre à 4 000 € (4 à 6 semaines). Une plateforme headless plus complexe avec intégrations sur-mesure ou multisite va de 6 500 € à 15 000 €+ (6 à 10 semaines). Le WordPress classique reste proposé à partir de 2 250 € si le headless n'est pas justifié.

Non — bien fait, il l'améliore. Les pages sont pré-rendues (SSG/ISR), les Core Web Vitals progressent nettement, les données structurées et meta sont explicites. Le risque est pendant la migration : conserver chaque URL à l'identique, poser des redirects 301 pour toute slug modifiée, régénérer le sitemap.xml. Avec ces étapes respectées, le SEO progresse au lieu de chuter.

Gutenberg oui — son JSON de blocs est consommable et rendu par Next.js. Elementor et les page builders visuels qui produisent du HTML chargé en shortcodes posent problème car leur logique de rendu vit dans le thème WordPress. Migrer un site Elementor en headless implique généralement de reconstruire les gabarits côté front.

WPGraphQL est recommandé pour les nouveaux projets headless : un seul endpoint, uniquement les champs demandés, ergonomie TypeScript bien meilleure dans Next.js. L'API REST native fonctionne toujours et reste parfois plus simple pour de très petits sites ou des intégrations ciblées, mais pour un vrai site en production, WPGraphQL est le défaut.

Oui, nettement. L'admin WordPress peut être isolée (sous-domaine privé, restriction IP, basic-auth). Le site public est du HTML statique ou pré-rendu servi par CDN — pas d'exécution PHP exposée aux visiteurs, pas de faille plugin atteignant le front. La majorité des vecteurs d'attaque automatisés contre WordPress ne s'appliquent plus.

Migration standard d'un site de 30 à 100 pages : 4 à 6 semaines. Étapes : audit de contenu, mapping des URL (critique pour le SEO), mise en place de l'API (WPGraphQL), reconstruction du front Next.js calé sur le design existant, redirects et bascule progressive. Les sites avec WooCommerce massif, multilingue ou plugins custom demandent une planification plus longue.

Deux moitiés, deux hébergeurs. Le back-end WordPress reste sur un hébergeur PHP/MySQL classique (l'hébergeur actuel suffit le plus souvent). Le front Next.js est déployé sur une plateforme JAMstack : Vercel, Netlify ou Node auto-hébergé. Le coût mensuel cumulé est comparable à un hébergement WordPress optimisé.

Oui. Comme WordPress reste intact en back-end, retourner à un rendu par thème classique est toujours possible. Le front Next.js est une couche additionnelle, pas un remplacement du CMS. Cela fait du headless une évolution à faible risque.