WordPress ou Next.js : faut-il passer en headless en 2026

Si vous avez déjà “découplé” WordPress vers un front Next.js pour finir avec deux caches, deux pipelines CI et des previews cassées, vous avez touché le vrai sujet de 2026 : le headless n’est plus une mode, c’est un choix d’architecture qui coûte cher quand il est fait “par défaut”.

Ce qui change

En 2026 (WordPress 6.9.4, PHP 8.1+), la discussion “WordPress vs Next.js” n’est plus un duel techno. Le changement réel, c’est la maturité des deux côtés :

• WordPress a stabilisé ses APIs (REST, blocs, patterns, interop) et la plupart des besoins “front moderne” se couvrent désormais sans découplage complet, surtout si votre site est éditorial et orienté conversion.
• Next.js (et l’écosystème React) a normalisé SSR/SSG/ISR, l’edge rendering, et les pipelines de contenu. Résultat : si vous découplez, vous devez aussi assumer l’industrialisation (observabilité, invalidation, prévisualisation, sécurité).
• Les attentes SEO et performance ont monté d’un cran : Core Web Vitals, préchargements, images, et surtout cohérence cache/CDN.

Le point “actualité WordPress” utile ici : WordPress 6.9.x continue d’orienter les bonnes pratiques vers des intégrations progressives (blocs, interactivité, REST) plutôt que des ruptures d’architecture. Dans mon expérience, c’est exactement là que la plupart des projets se trompent : ils choisissent headless pour “aller plus vite”, et se retrouvent à réécrire ce que WordPress faisait déjà (preview, révisions, permissions, workflows).

Références officielles à garder sous la main :

• REST API Handbook
• Block Editor Handbook
• register_block_type()
• WordPress Core Trac (suivi des changements core)
• wordpress-develop (GitHub)

Note honnête : il n’y a pas “un” ticket Trac qui dit “WordPress supporte mieux Next.js”. Ce sont des évolutions cumulées. Si vous devez documenter votre veille, je vous conseille de suivre les dev notes et tickets liés à l’éditeur de blocs, aux endpoints REST et au chargement des scripts (performance), via Trac et le repo wordpress-develop.

Résumé rapide

• Ne découplez pas si votre besoin principal est : blog, site vitrine, landing pages, SEO standard, formulaires, e-commerce classique, A/B testing simple.
• Découplez (vraiment) si vous avez : multi-fronts, app web complexe, exigences d’edge rendering, personnalisation forte côté front, ou besoin d’un design system React gouverné par une équipe front.
• Le faux headless (WordPress + Next.js “juste pour le score Lighthouse”) est souvent une régression : previews, cache, auth, taxonomies, shortcodes, embeds, tout devient un projet.
• Le bon compromis 2026 est souvent “progressive decoupling” : WordPress reste le front principal, et vous exposez des morceaux via REST (ou blocs) pour des expériences spécifiques.
• Le risque n°1 : l’invalidation de cache et la cohérence des données (ISR/CDN vs cache WordPress vs object cache).
• Le risque n°2 : la sécurité (tokens, endpoints publics, prévisualisation, CORS) et la gouvernance des permissions WordPress.

Avant / Après en code

Je vais volontairement partir d’un cas réel : vous voulez alimenter un front Next.js avec des articles, mais vous voulez aussi des previews fiables (brouillons, révisions) et un contrôle d’accès propre. C’est là que beaucoup d’implémentations “headless rapides” se brisent.

Avant : REST “ouvert” et preview bricolée

Ce pattern, je le vois encore en 2026 : on expose un endpoint custom, on met un token dans l’URL, et on espère que ça ira.

<?php
/**
 * Exemple volontairement imparfait : endpoint trop permissif.
 * Problèmes : token en query string, pas de nonce, pas de cap checks solides.
 */
add_action('rest_api_init', function () {
	register_rest_route('headless/v1', '/post/(?P<id>d+)', [
		'methods'  => 'GET',
		'callback' => function ($request) {
			$post_id = (int) $request['id'];
			$post = get_post($post_id);

			if (!$post) {
				return new WP_Error('not_found', 'Article introuvable', ['status' => 404]);
			}

			// Erreur fréquente : on renvoie le contenu brut sans passer par "the_content".
			return [
				'id'      => $post->ID,
				'title'   => $post->post_title,
				'content' => $post->post_content,
				'status'  => $post->post_status,
			];
		},
		'permission_callback' => '__return_true', // Le pire : tout le monde peut lire tout.
	]);
});

Ce qui se passe en coulisses :

• Vous contournez toute la logique WordPress de capacités (current_user_can()), de statuts (brouillon, privé), et de filtrage de contenu (the_content).
• Vous cassez des plugins : shortcodes, embeds, blocs dynamiques, contenu filtré, etc.
• Vous créez un incident de sécurité le jour où un contenu “privé” est accessible via ID.

Après : endpoint REST robuste + rendu de contenu “WordPress-compatible”

Le but n’est pas de “tout faire dans REST”, mais d’exporter un payload stable, versionné, et respectueux des permissions. Et de rendre le contenu comme WordPress le ferait (au moins côté HTML), pour éviter les surprises.

<?php
/**
 * Endpoint REST headless robuste pour WordPress 6.9.4+.
 * - Respecte les permissions (public vs preview)
 * - Rend le contenu via les filtres WordPress (blocs, shortcodes, embeds)
 * - Versionne implicitement via namespace v1 (à faire évoluer en v2 si breaking)
 */
add_action('rest_api_init', function () {
	register_rest_route('headless/v1', '/post/(?P<id>d+)', [
		'methods'  => 'GET',
		'callback' => 'bpcab_headless_get_post',
		'permission_callback' => 'bpcab_headless_can_read_post',
		'args' => [
			'context' => [
				'default' => 'view',
				'enum'    => ['view', 'preview'],
			],
		],
	]);
});

/**
 * Vérifie si l'utilisateur a le droit de lire l'article.
 * - En context=view : public uniquement
 * - En context=preview : nécessite un utilisateur authentifié + capacité d'édition
 */
function bpcab_headless_can_read_post(WP_REST_Request $request) {
	$post_id = (int) $request['id'];
	$context = (string) $request->get_param('context');

	$post = get_post($post_id);
	if (!$post) {
		return new WP_Error('not_found', 'Article introuvable', ['status' => 404]);
	}

	if ($context === 'preview') {
		// Piège fréquent : utiliser is_user_logged_in() sans vérifier la capacité.
		if (!is_user_logged_in()) {
			return new WP_Error('forbidden', 'Authentification requise pour la prévisualisation', ['status' => 401]);
		}
		if (!current_user_can('edit_post', $post_id)) {
			return new WP_Error('forbidden', 'Droits insuffisants pour la prévisualisation', ['status' => 403]);
		}
		return true;
	}

	// view : ne renvoyer que ce qui est publiquement visible
	if ($post->post_status !== 'publish') {
		return new WP_Error('forbidden', 'Contenu non public', ['status' => 403]);
	}

	return true;
}

/**
 * Construit un payload stable.
 * Note : apply_filters('the_content', ...) peut être coûteux. À mettre en cache côté WP si nécessaire.
 */
function bpcab_headless_get_post(WP_REST_Request $request) {
	$post_id = (int) $request['id'];
	$post = get_post($post_id);

	if (!$post) {
		return new WP_Error('not_found', 'Article introuvable', ['status' => 404]);
	}

	// Rendu WordPress-compatible : blocs, shortcodes, embeds...
	$content_html = apply_filters('the_content', $post->post_content);

	// Exemple : exposer aussi un excerpt fiable.
	$excerpt = has_excerpt($post) ? $post->post_excerpt : wp_trim_words(wp_strip_all_tags($content_html), 40);

	return [
		'id'        => $post->ID,
		'slug'      => $post->post_name,
		'title'     => get_the_title($post),
		'content'   => [
			'html' => $content_html,
		],
		'excerpt'   => $excerpt,
		'status'    => $post->post_status,
		'modified'  => get_post_modified_time('c', true, $post),
		'permalink' => get_permalink($post),
	];
}

Différences clés :

• Permissions explicites : vous ne “leakez” pas les brouillons.
• Rendu cohérent : les blocs dynamiques et shortcodes ont une chance de fonctionner pareil qu’en front WordPress.
• Prévisualisation réaliste : vous imposez un utilisateur authentifié + capacité edit_post.

Et côté Next.js : preview mode propre (exemple)

Le point critique : la preview ne doit pas être un “token magique” permanent. Elle doit expirer, et idéalement s’appuyer sur une auth WordPress (Application Passwords ou OAuth). Beaucoup d’équipes mettent un secret partagé et oublient la rotation.

// Exemple Next.js (conceptuel) : endpoint de preview.
// À adapter selon votre version Next.js et votre stratégie d'auth.
export default async function handler(req, res) {
  const { id, secret } = req.query;

  // Piège fréquent : secret stocké en dur ou exposé dans le front.
  if (secret !== process.env.WP_PREVIEW_SECRET) {
    return res.status(401).json({ error: "Secret invalide" });
  }

  // Active le mode preview (cookies signés)
  res.setPreviewData({ postId: Number(id) }, { maxAge: 60 * 10 }); // 10 minutes

  // Redirige vers la page Next.js qui sait charger context=preview
  res.writeHead(307, { Location: `/posts/${id}?context=preview` });
  res.end();
}

À ce stade, vous avez déjà un aperçu du vrai coût : auth, permissions, expiration, et un contrat API stable.

Impact concret

Pour les blogueurs avancés

Si votre objectif est un site éditorial (articles, catégories, tags, pages marketing), WordPress 6.9.4 reste souvent le chemin le plus court vers un site rapide et maintenable. Vous gagnez :

• Preview native, révisions, planification, workflows éditoriaux.
• Plugins matures (SEO, cache, formulaires, newsletter, analytics).
• Performance acceptable avec un bon thème bloc + cache page + CDN, sans réécrire le front.

Quand le headless devient pertinent pour un blogueur avancé : multi-sites/multi-marques avec un front unifié, ou besoin d’un front “app-like” (personnalisation forte, compte utilisateur, dashboards). Là, Next.js peut être un vrai accélérateur.

Pour les développeurs et agences

Le découplage change la nature du projet :

• Vous passez d’un projet WordPress à un système distribué (WP + front + CDN + cache + auth).
• Vous devez versionner votre API, gérer la compatibilité des plugins, et définir un “contrat de contenu” (blocs autorisés, champs, patterns).
• Vous déplacez une partie de la dette technique : moins de PHP en front, mais plus de JS/infra.

Impact sur les plugins existants

Le headless “pur” casse souvent :

• SEO plugins (rendu des metas, schema, canonical, pagination) si vous ne reproduisez pas fidèlement la logique.
• Plugins de cache et d’optimisation (ils optimisent le front WordPress, pas votre Next.js).
• Shortcodes et blocs dynamiques (ils nécessitent un rendu serveur WordPress ou une réimplémentation côté front).

À l’inverse, un modèle “progressive decoupling” (WordPress reste le front, Next.js sert une app séparée) réduit ces frictions.

Impact sur les thèmes (classiques et FSE)

Avec un thème bloc (FSE), WordPress vous donne une chaîne complète : templates, patterns, styles globaux, et un éditeur qui parle le même langage que le front. En headless, vous perdez une partie de cette valeur : vous devez reconstruire le système de templates dans Next.js.

Je vois souvent une erreur : des équipes adoptent FSE pour l’édition, mais headless pour le rendu. Elles finissent par exporter du HTML de blocs, puis le “rehydrater” côté React. Ça marche… jusqu’au jour où un plugin injecte un bloc dynamique ou un embed qui dépend du front WordPress.

Compatibilité Divi 5, Elementor, Avada

Ces page builders restent des moteurs de rendu front WordPress. En headless :

• Elementor : vous récupérez rarement un rendu fidèle via REST sans passer par le rendu PHP/templating Elementor. Vous finissez avec du HTML “pré-rendu” (possible), mais vous perdez l’édition WYSIWYG cohérente avec Next.js.
• Divi 5 : même logique. Divi est excellent quand WordPress sert le front. En headless, vous devez choisir : soit vous rendez côté WP (HTML), soit vous réimplémentez des modules côté React.
• Avada : Fusion Builder est dans la même catégorie. Headless = vous sortez de la zone d’optimisation du builder.

Le compromis réaliste : garder WordPress + builder pour les pages marketing, et utiliser Next.js pour une application séparée (espace membre, configurateur, moteur de recherche avancé). C’est du découplage partiel, mais c’est celui qui survit.

Risques, compatibilités et points de vigilance

Ce qui est “nouveau” en 2026 (dans les pratiques)

• La plupart des stacks headless ont standardisé ISR/SSR + CDN. Le problème n’est plus “peut-on le faire ?” mais “comment invalider proprement ?”.
• Les équipes WordPress avancées font plus de progressive decoupling : elles extraient un périmètre applicatif au lieu de tout réécrire.

Ce qui change (et surprend)

• La preview n’est pas un détail. Elle devient un produit en soi (permissions, révisions, brouillons, autosaves).
• Les webhooks deviennent critiques : publication = invalidation cache + rebuild partiel + purge CDN.
• Le modèle de sécurité change : vous exposez plus d’API, donc plus de surface d’attaque.

Ce qui casse potentiellement

• Contenu rendu différemment : blocs dynamiques, shortcodes, oEmbed, embeds sociaux, galleries.
• URLs et permaliens : la moindre divergence entre WP et Next.js fait exploser canonical/hreflang/pagination.
• Cache incohérent : vous publiez un article, WordPress l’a, Next.js sert l’ancien pendant 10 minutes, le CDN garde une version encore plus ancienne.
• Internationalisation : WPML/Polylang côté WP vs routing i18n côté Next.js, ça peut devenir un casse-tête.

Timeline de dépréciation / compat

Côté WordPress core, la REST API est stable depuis longtemps. Les “dépréciations” qui vous touchent le plus viennent plutôt :

• des plugins (changement de schéma JSON, endpoints modifiés),
• de votre propre API (si vous ne versionnez pas),
• de Next.js (changement de conventions, runtime, edge).

Donc la règle : versionnez vos endpoints (namespace headless/v1, puis v2 si breaking), et testez vos payloads comme une API produit.

Tableau de diagnostic (problèmes réels)

Symptôme	Cause probable	Vérification	Solution
Les brouillons sont visibles sur le front Next.js	Endpoint REST permissif (permission_callback trop large)	Tester l’URL d’API en navigation privée / sans cookies	Vérifier current_user_can('edit_post') en preview et bloquer les statuts non publics en view
Les blocs dynamiques ne s’affichent pas	Vous renvoyez post_content brut	Comparer post_content vs HTML front WordPress	Utiliser apply_filters('the_content', ...) ou rendre côté WP
Les mises à jour ne se voient pas après publication	Cache ISR/CDN non purgé	Regarder les headers cache, logs CDN, timestamps modified	Webhooks + purge ciblée + stratégie de revalidation cohérente
Erreur 401/403 aléatoire en preview	Cookies preview expirés, auth WP mal gérée, CORS	Tester en local, vérifier cookies, vérifier headers	Preview data expirant + auth robuste (Application Passwords/OAuth) + CORS strict
Les images sont cassées ou non optimisées	URLs relatives, tailles WP non exposées, hotlinking bloqué	Inspecter HTML/JSON renvoyé, vérifier srcset	Exposer les tailles via REST, ou servir via CDN media, ou utiliser un proxy image

Erreurs fréquentes à éviter (terrain)

• Copier le code au mauvais endroit : endpoint REST ajouté dans un thème parent (perdu à la mise à jour). Mettez-le dans un plugin mu-plugin ou un plugin dédié.
• Utiliser un hook inadapté : déclarer register_rest_route hors de rest_api_init et se demander pourquoi l’endpoint n’existe pas.
• Tester sur production sans sauvegarde : une mauvaise permission_callback peut exposer du privé en quelques minutes.
• Oublier de vider les caches : navigateur, CDN, cache page, object cache. J’ai vu des équipes “debugger” 3 heures un bug qui était juste Cloudflare.
• Snippet cassé par un plugin de snippets : une parenthèse oubliée = fatal error. Déployez via Git, ou au minimum sur un mu-plugin versionné.
• PHP trop ancien : vous ciblez PHP 8.1+, mais un serveur staging tourne encore en 7.4 et tout part en erreur. Vérifiez avant de migrer.

Comment migrer

Je pars du scénario le plus courant en 2026 : vous avez un WordPress “classique” (souvent avec Elementor/Divi/Avada), et vous voulez découpler une partie, ou préparer un passage headless sans casser l’existant.

Étape 1 : choisir votre degré de découplage

• Progressive decoupling : WordPress reste le front principal. Next.js sert une app séparée (ex: /app, /compte, /catalogue) qui consomme des endpoints WP.
• Headless hybride : WordPress rend certaines pages (marketing), Next.js rend le blog (ou l’inverse). Attention aux canonical et au tracking.
• Headless total : WordPress = back-office. Next.js = tout le front. C’est le plus coûteux, mais parfois justifié.

Étape 2 : stabiliser un contrat API (versionné)

Ne commencez pas par “tout exposer”. Commencez par 2-3 ressources : posts, pages, catégories. Ajoutez un champ modified et un identifiant stable (ID + slug).

Astuce que j’utilise : intégrer un “schema minimal” dans votre code, même si vous n’allez pas jusqu’à JSON Schema. Ça évite les payloads qui dérivent.

<?php
/**
 * Exemple : endpoint de liste avec pagination + champs explicites.
 * À héberger dans un plugin (idéalement mu-plugin) pour éviter les surprises.
 */
add_action('rest_api_init', function () {
	register_rest_route('headless/v1', '/posts', [
		'methods'  => 'GET',
		'callback' => 'bpcab_headless_list_posts',
		'permission_callback' => '__return_true',
		'args' => [
			'page' => ['default' => 1],
			'per_page' => ['default' => 10],
		],
	]);
});

function bpcab_headless_list_posts(WP_REST_Request $request) {
	$page     = max(1, (int) $request->get_param('page'));
	$per_page = min(50, max(1, (int) $request->get_param('per_page')));

	$q = new WP_Query([
		'post_type'      => 'post',
		'post_status'    => 'publish',
		'paged'          => $page,
		'posts_per_page' => $per_page,
		'no_found_rows'  => false, // On veut la pagination
	]);

	$items = [];
	foreach ($q->posts as $post) {
		$items[] = [
			'id'       => $post->ID,
			'slug'     => $post->post_name,
			'title'    => get_the_title($post),
			'excerpt'  => wp_trim_words(wp_strip_all_tags(apply_filters('the_content', $post->post_content)), 30),
			'modified' => get_post_modified_time('c', true, $post),
			'link'     => get_permalink($post),
		];
	}

	$response = new WP_REST_Response([
		'items' => $items,
		'page'  => $page,
		'total' => (int) $q->found_posts,
	]);

	// Headers utiles pour le front (cache, pagination)
	$response->header('X-WP-Total', (string) $q->found_posts);
	$response->header('X-WP-TotalPages', (string) $q->max_num_pages);

	return $response;
}

Étape 3 : gérer l’invalidation (webhooks) proprement

Sans invalidation, vous allez servir du contenu périmé. Côté WordPress, vous pouvez déclencher un webhook sur save_post (avec précautions : autosaves, révisions, statut).

<?php
/**
 * Webhook de publication : notifie le front pour revalidation.
 * Points de vigilance :
 * - Ignorer autosaves/révisions
 * - Ne déclencher que sur publish (ou transitions pertinentes)
 * - Signer la requête (HMAC) pour éviter les appels frauduleux
 */
add_action('save_post_post', function ($post_id, $post, $update) {
	// Ne pas exécuter sur autosave/révision
	if (wp_is_post_autosave($post_id) || wp_is_post_revision($post_id)) {
		return;
	}

	// Ne notifier que si l'article est publié
	if ($post->post_status !== 'publish') {
		return;
	}

	$endpoint = getenv('NEXT_REVALIDATE_URL');
	$secret   = getenv('NEXT_REVALIDATE_SECRET');

	if (!$endpoint || !$secret) {
		return; // En prod, loggez plutôt que silence total
	}

	$payload = wp_json_encode([
		'postId'   => $post_id,
		'slug'     => $post->post_name,
		'modified' => get_post_modified_time('c', true, $post),
	]);

	// Signature HMAC (évite l'attaque “je forge un webhook”)
	$signature = hash_hmac('sha256', $payload, $secret);

	wp_remote_post($endpoint, [
		'timeout' => 3,
		'headers' => [
			'Content-Type'      => 'application/json',
			'X-WP-Signature'    => $signature,
		],
		'body' => $payload,
	]);
}, 10, 3);

Piège fréquent : mettre ce code dans functions.php et oublier qu’un changement de thème le supprime. Pour du headless, je recommande un mu-plugin (ou un plugin classique) versionné.

Étape 4 : sécuriser l’accès (auth) et éviter les tokens “éternels”

Si vous consommez des endpoints privés (preview, contenus non publiés), vous devez une stratégie d’auth. WordPress fournit un mécanisme simple pour l’API : Application Passwords (si votre politique sécurité l’autorise). C’est souvent un bon compromis pour un serveur Next.js côté backend.

• Documentation : REST API Authentication

Étape 5 : valider la compat SEO et permaliens

Ne sous-estimez pas ce point. Après migration :

• Comparez canonical, Open Graph, schema, pagination, archives, RSS.
• Vérifiez les redirections 301 (ancien WP → nouveau Next).
• Et oui : régénérez les permaliens côté WP si vous avez touché aux structures (Réglages → Permaliens). Beaucoup de bugs “404 API” viennent d’une réécriture non appliquée.

Faut-il agir maintenant ou attendre ?

Recommandation nette :

• Si vous êtes principalement éditorial (blog + pages marketing), et que votre site est déjà sur WordPress 6.9.4 : attendez le découplage total. Investissez plutôt dans un thème bloc performant, un cache propre, et une hygiène plugins. Le ROI est meilleur.
• Si vous avez un périmètre applicatif (compte, portail, recherche avancée, personnalisation, multi-fronts) : agissez maintenant, mais en découplage partiel. Vous réduisez le risque tout en gagnant la vélocité front.
• Si votre équipe front est dominante et que WordPress n’est qu’un CMS parmi d’autres : le headless total peut être rationnel. Mais faites-le en acceptant le coût : preview, auth, cache, observabilité, et tests contractuels.

Le “mauvais moment” pour découpler : quand votre motivation principale est un score Lighthouse ou une impression de modernité. Dans 80% des cas que j’ai accompagnés, c’est une dette immédiate.

Conseils de maintenance

1) Traitez votre API comme un produit

• Namespace versionné (v1, v2).
• Changelog interne à chaque changement de payload.
• Tests automatisés (au minimum : tests d’intégration sur quelques endpoints).

2) Ajoutez de l’observabilité

Sur un système découplé, vous devez corréler :

• logs WordPress (erreurs PHP, REST, timeouts),
• logs Next.js (fetch, SSR),
• logs CDN (cache HIT/MISS, purge).

3) Cache : une seule source de vérité

Décidez qui est “autoritaire” :

• CDN autoritaire (purge sur webhook),
• ou Next.js autoritaire (ISR revalidate),
• ou WordPress autoritaire (page cache + reverse proxy).

Le pire modèle : les trois en même temps sans stratégie d’invalidation.

4) Attention aux priorités de hooks et aux filtres

J’ai souvent vu des contenus différents entre WP et headless parce qu’un plugin filtre the_content avec une priorité inattendue. Si vous rendez via apply_filters('the_content', ...), vous héritez de cette complexité. Documentez les plugins qui modifient le rendu.

5) Plan de tests à chaque mise à jour WordPress 6.9.x

• Tests de preview (brouillon, planifié, privé).
• Tests de rendu de blocs dynamiques et embeds.
• Tests de performance (temps de réponse REST, TTFB SSR).
• Tests de sécurité (accès aux endpoints, CORS, rate limiting côté infra).

Ressources

• WordPress REST API Handbook
• Authentication for the REST API
• Block Editor Handbook
• register_rest_route() (référence)
• apply_filters() (référence)
• WordPress Core Trac (tickets)
• wordpress-develop sur GitHub
• Documentation WordPress (utilisateurs & dev)
• PHP 8.1 (notes de version)

FAQ

Est-ce que “headless” rend forcément mon site plus rapide ?

Non. Vous pouvez gagner sur le TTFB et la stabilité front, mais vous pouvez aussi perdre sur l’invalidation, la surcharge SSR, et les appels API. J’ai vu des headless plus lents que des WordPress bien cachés.

Quel est le meilleur choix pour un blog SEO classique en 2026 ?

WordPress 6.9.4 avec un thème bloc performant + cache page + CDN. Le headless n’apporte pas grand-chose si votre contenu est surtout “lecture”.

Pourquoi mes shortcodes ne fonctionnent plus en headless ?

Parce que vous renvoyez souvent post_content brut. Utilisez apply_filters('the_content', ...) côté WordPress, ou remplacez vos shortcodes par des blocs/structures rendables côté front.

Comment gérer les previews proprement ?

En séparant clairement view (public) et preview (auth + capacité), avec un mode preview expirant côté Next.js. Évitez les tokens permanents dans les URLs.

Dois-je utiliser REST API ou GraphQL ?

REST est natif, stable, documenté, et suffisant pour beaucoup de cas. GraphQL (via plugin) peut être excellent, mais c’est une dépendance supplémentaire et un schéma à gouverner. Choisissez selon votre équipe et vos besoins de requêtes.

Comment éviter le contenu périmé après publication ?

Webhooks côté WordPress + revalidation/purge ciblée côté front/CDN. Sans ça, vous aurez des incohérences “fantômes” difficiles à diagnostiquer.

Divi 5 / Elementor / Avada sont-ils compatibles headless ?

Pas “nativement” au sens où ils sont conçus pour rendre côté WordPress. Vous pouvez exporter du HTML rendu, mais vous perdez une partie de l’intérêt du builder et vous complexifiez le debugging.

Où mettre le code des endpoints REST ?

Dans un plugin (idéalement un mu-plugin) versionné. Évitez functions.php d’un thème, surtout si vous changez de thème ou utilisez un builder.

Qu’est-ce qui casse le plus souvent lors d’une migration headless ?

La preview, l’invalidation cache, les permaliens/redirects, et les différences de rendu (blocs dynamiques, embeds). Côté sécurité, les endpoints trop permissifs sont un classique.

Comment tester sans casser la prod ?

Staging avec même version PHP (8.1+), même cache/CDN si possible, snapshots DB, et tests automatisés sur quelques endpoints. Et purge cache contrôlée, sinon vous “testez” juste votre CDN.

Quel compromis recommandez-vous le plus souvent ?

Découplage partiel : WordPress sert le marketing et l’éditorial, Next.js sert une application dédiée. Vous gardez les forces de WordPress, et vous évitez de réécrire tout l’écosystème.