WordPress classique ou WordPress headless : quelle architecture

🔎 WordPress classique : un seul système à comprendre

L'éditeur voit la page, à peu près. Les plugins de formulaire, de SEO, de cache vivent dans le même monde. La TMA a un dépôt, un PHP, une base. Pour une vitrine, un magazine, un site institutionnel, c'est encore le chemin le plus honnête. Moins de magie, plus de prestataires qui savent intervenir.

Les limites sont connues : perf si le thème est sale, sécurité si la TMA est fantôme, rigidité du front si on veut une app. Ces limites se traitent souvent par un thème propre, un allègement, un cache, pas par un découplage.

🛠️ WordPress headless : deux produits, deux rythmes

Le rédacteur reste dans WordPress (Gutenberg, ACF, parfois un builder qu'on a justement voulu quitter). Le visiteur voit un front qui n'est plus le thème. Entre les deux : une API, un cache, un build, des webhooks. Chaque contenu publié doit arriver de l'autre côté. Si le webhook rate, le site ment.

Vous payez : le WordPress (hébergement, sécu, mises à jour) et le front (build, hébergement, dépendances JS). Deux stacks, deux veilles. Le headless n'enlève pas WordPress. Il l'ajoute à autre chose.

✅ Prévisualisation et quotidien éditorial

C'est le point qui fait échouer les projets headless « pour la comm ». En classique, Aperçu existe. En headless, l'aperçu est un projet : token, front de preview, environnements. Sans ça, vous publiez à l'aveugle ou n'utilisez plus WordPress que comme un drive.

Si votre argument pour rester sur WordPress est « vous savez déjà vous en servir », vérifiez que le headless vous laisse un aperçu digne de ce nom. Sinon vous avez acheté un CMS dont on a retiré le bénéfice.

⚠️ SEO et rendu

Un front statique ou SSR bien fait peut être excellent pour le SEO : HTML complet, vitesse, contrôle des metas. Un front SPA mal rendu peut être pire qu'un thème WordPress moyen. Le headless n'est pas un levier SEO par lui-même. C'est un levier si l'équipe front maîtrise le rendu et les metas.

Les plugins SEO WordPress ne remplissent plus le thème. Il faut relire titles, canoniques, schema, sitemap côté front. C'est du travail. On le budgète. On ne « garde » pas Yoast en croyant que le Nuxt lira les champs tout seul sans contrat d'API.

📌 Formulaires, recherche, aperçus de campagne, multilingue

Chaque plugin qui injectait un shortcode dans le thème devient une spec d'intégration. Formulaire, search, related posts, A/B : tout passe par une API ou un service tiers. C'est libérateur quand on le veut. C'est une facture quand on le découvre en cours de route.

Le multilingue headless est un projet à part (routes, fallback, previews par langue). Polylang / WPML « comme avant » n'existe plus. Si le site est trilingue et que le budget est celui d'un thème, restez classique.

🧭 Coût et TMA : le critère qu'on oublie au kick-off

Un WordPress classique tenu : une TMA. Un WordPress headless tenu : TMA WordPress plus TMA front, plus le contrat entre les deux. Les incidents sont plus longs à qualifier (« c'est l'API ou le cache du front ? »). Prévoyez ce temps. Sinon le headless vieillit plus vite que le classique.

Le classique sale (builder, 40 plugins) peut coûter plus cher qu'un headless propre. La comparaison honnête oppose un WordPress classique soigné à un headless soigné. Pas un monstre Elementor à un slide Nuxt.

💡 Quand je conseille le classique, quand je conseille le headless

Classique : vitrine, équipe qui publie en autonomie, budget TMA unique, pas besoin d'app, SEO tenu dans WordPress. Headless : plusieurs fronts (site, app, écrans), design très spécifique impossible en thème, équipe front déjà là, budget pour la preview et la double TMA, besoin de perf front que le PHP ne tient plus.

Je refuse le headless « pour être moderne » sur un site de quinze pages. Je refuse aussi de garder un thème mort si le vrai besoin est un front soigné et que le budget est là. Les deux dogmatismes existent. Les deux coûtent.

🧪 Comment décider en une réunion

Listez les surfaces (un site, une app, une boutique). Listez qui publie, avec quel aperçu minimum. Listez le budget TMA annuel acceptable. Si une seule surface, vous qui publiez, un budget TMA unique : classique. Si plusieurs surfaces et une équipe qui tiendra le front : headless possible.

Ensuite lisez « WordPress headless : quand ça vaut le coût ». L'architecture n'est pas un badge. C'est une facture récurrente. Choisissez celle que vous paierez encore dans trois ans.

🔎 Le cas hybride : thème pour le marketing, app à côté

Tout n'a pas besoin d'être headless. Un WordPress classique pour le site public, plus une app qui lit quelques types de contenus via l'API REST, suffit souvent. On découple seulement le morceau qui le justifie. Moins de preview à inventer, moins de TMA double sur toutes les pages.

Ce hybride déçoit les architectes qui veulent un schéma unique. Il arrange les budgets. WordPress classique ou headless n'est pas un choix binaire pour tout le SI. C'est un choix par surface.

🛠️ Critères de bascule dans deux ans

Si vous restez classique, écrivez à quelle condition vous rouvrirez le headless : deuxième front, LCP intenable malgré un thème mince, équipe front embauchée. Si vous partez headless, écrivez à quelle condition vous reviendriez (budget TMA explosé, preview abandonnée, un seul front restant). Ces critères évitent de vivre dans une décision de kick-off datée.

L'architecture n'est pas un mariage. C'est un contrat que l'on relit. L'article sur le coût du headless donne les montants. Celui-ci donne la forme. Les deux évitent le slide « on est headless » collé sur une vitrine de vingt pages.

Le headless se justifie par un second canal, pas par un slide.