Chapitre 9.7 — Arbitrages : headless ou pas ?

⏱️ TL;DR — Le headless est puissant mais pas gratuit : vous perdez (ou devez reconstruire) tout ce que WordPress offre « pour rien » — preview (ch. 9.6), rendu des blocs, plugins front (SEO, formulaires, cache), aperçu WYSIWYG, liens/médias, deux systèmes à héberger et déployer. Le headless brille quand vous avez un vrai besoin (front très custom/React, perf extrême, multi-canal, équipe front forte). Pour un site vitrine standard, un thème bloc classique (Partie 6) est souvent plus rapide, moins cher, plus maintenable. Savoir dire « pas headless ici » est une marque d’expertise (et de conseil honnête).

🎯 Objectifs

Peser gains et coûts du headless honnêtement.
Reconnaître les cas où le headless se justifie (ou pas).
Anticiper les « coûts cachés » (preview, blocs, plugins, ops).
Conseiller un client avec lucidité (argument commercial).

1. Ce que le headless vous fait gagner

Front 100 % React/Next.js : DX moderne, composants, animations, état client riche.
Performance : SSG/ISR, CDN, découplage du PHP.
Multi-canal : le même CMS alimente site web, app mobile, écrans, etc.
Séparation des équipes : les rédacteurs sur WordPress, les devs sur Next.js.
Sécurité : le WordPress peut être isolé (back-office non exposé publiquement).

2. Ce que le headless vous coûte (les coûts cachés)

La preview : à recréer (Draft Mode + auth). Non trivial.
Le rendu des blocs Gutenberg : le front classique rend les blocs automatiquement ; en headless, content.rendered donne du HTML, mais des blocs custom/dynamiques peuvent nécessiter un rendu React équivalent (ou rester en HTML brut). Reconstruire fidèlement l’éditeur de blocs côté React est beaucoup de travail.
Les plugins front : SEO (Yoast/RankMath posent des balises côté thème), formulaires, cache, redirections, sliders… ne s’appliquent plus au front headless → à remplacer (parfois par leurs données via API, souvent à réécrire).
Liens & médias : URLs absolues vers le CMS à réécrire (ch. 9.5).
L’exploitation : deux systèmes (WordPress + Next.js) à héberger, déployer, mettre à jour, monitorer, sécuriser. Le coût ops double.
Le WYSIWYG : le rédacteur perd la correspondance « ce que je vois = ce qui s’affiche » (le front n’est plus le thème).

⚠️ Piège — sous-estimer le coût du SEO et de la preview. Deux « détails » qui coulent des projets headless : (1) reproduire ce que les plugins SEO faisaient automatiquement (balises meta, sitemaps, schema) côté Next ; (2) offrir une preview correcte aux rédacteurs. Chiffrez-les dès le devis, pas en cours de route.

3. Quand le headless se justifie

✅ Bon candidat si :

le front doit être très custom/interactif (app-like, React lourd) ;
besoin de perf extrême ou d’un front commun multi-canal ;
une équipe front solide (Next.js) est en place ;
le contenu est relativement structuré (CPT/champs) et l’éditorial peut composer avec une preview dédiée ;
l’entreprise veut découpler et isoler le back-office.

❌ Mauvais candidat si :

site vitrine/blog standard sans besoin front particulier ;
budget/maintenance limités (le headless coûte plus en dev et en ops) ;
forte dépendance à des plugins front (SEO, formulaires, page builders) ;
l’équipe éditoriale exige un WYSIWYG fidèle et une preview simple ;
pas de compétence Next.js en interne pour maintenir le front.

4. Les alternatives « entre les deux »

Le choix n’est pas binaire :

Thème bloc moderne (Partie 6) : très rapide à produire, WYSIWYG natif, plugins front OK. Le défaut pour la plupart des sites.
Îlots React dans un thème classique : garder WordPress en rendu, injecter des composants React là où l’interactivité l’exige (comme les blocs dynamiques, Partie 8) — le meilleur de React sans payer le coût headless complet.
Headless partiel : ne passer en headless qu’une section (ex. un catalogue/app), le reste restant classique.

💡 Pour un dev React — La tentation est de tout faire en Next.js « parce qu’on préfère React ». Mais conseiller le bon niveau (thème bloc vs îlots React vs headless) selon le besoin réel et le budget est ce qui distingue un prestataire mûr d’un dev qui impose sa stack. Le marché paie l’arbitrage juste, pas la sur-ingénierie. Souvent, îlots React dans un thème donne 90 % de la valeur pour 30 % du coût.

5. Grille de décision rapide

Question	Plutôt classique/thème bloc	Plutôt headless
Front très interactif/app-like ?	Non	Oui
Multi-canal (web + app…) ?	Non	Oui
Dépendance forte aux plugins front ?	Oui	Non
Équipe Next.js pour maintenir ?	Non	Oui
Budget/maintenance serrés ?	Oui	Non
Preview WYSIWYG simple exigée ?	Oui	(à reconstruire)

Si la colonne « classique » l’emporte, assumez-le : c’est le choix responsable.

✏️ Exercices

Citez trois « coûts cachés » du headless souvent oubliés dans un devis.
Un client veut un blog d’entreprise standard, petite équipe, budget serré, forte utilisation d’un plugin SEO. Headless ou pas ? Pourquoi ?
Quelle alternative permet d’avoir du React sans payer le coût complet du headless ?

✅ Solution

Par exemple : la preview des brouillons (à reconstruire), le remplacement des plugins front (SEO, formulaires, cache), et le coût d’exploitation de deux systèmes (héberger/déployer/monitorer/sécuriser WordPress et Next.js). (Aussi : rendu des blocs custom, réécriture des liens/médias.)
Pas headless : site standard, petite équipe, budget serré, dépendance à un plugin SEO front → un thème bloc (Partie 6) est plus rapide, moins cher, plus maintenable, et garde le SEO/plugins front. Le headless ajouterait du coût dev et ops sans bénéfice proportionné.
Les îlots React dans un thème classique/bloc (comme les blocs dynamiques, Partie 8) : de l’interactivité React ciblée, tout en gardant WordPress en rendu, WYSIWYG et plugins front.

🧠 Quiz de révision