Les devis « CMS headless » mettent souvent WordPress headless, Strapi, Contentful, Sanity, parfois un custom, sur la même ligne. Côté visiteur, le front (Nuxt, Next) se ressemble. Côté chantier, non. WordPress est open source, tenu par des milliers de contributeurs, déjà dans les mains de la comm. Un WordPress classique se convertit en headless sans jeter les contenus. On peut aussi revenir. Cet article compare WordPress headless aux autres CMS headless. Pas classique contre découplé : ça, c'est l'autre article.
🔎 Ce qu'on compare, et ce qu'on ne compare pas
Ici, le front est déjà choisi, ou presque : un site, parfois une app, souvent Nuxt ou Next. La question n'est pas « thème PHP ou front JS ». C'est : quel back-office nourrit ce front. WordPress headless, Strapi, Contentful, Sanity, Directus, un custom Symfony. Même schéma : contenus d'un côté, HTML de l'autre, API au milieu.
On ne rejoue pas « WordPress classique ou headless ». Si vous n'avez qu'une vitrine et une comm autonome, lisez d'abord cet article-là. Ici on suppose que le découplage se justifie, ou qu'on vous l'a déjà vendu, et qu'il reste à choisir le CMS. Le visiteur, lui, se moque du logo dans l'admin. Il voit un HTML, un temps de chargement, un formulaire qui marche.
🛠️ L'avantage WordPress que les slides oublient
WordPress est open source. Pas un essai gratuit qui bascule en licence le jour où le catalogue grossit. Le cœur, l'API REST, Gutenberg, ACF : vous les hébergez. Personne ne coupe le robinet parce qu'un plan SaaS a changé. Des milliers de contributeurs patchent, documentent, traduisent. Ce n'est pas « vieux ». C'est tenu.
C'est aussi le CMS que le plus de monde a déjà ouvert. Rédacteurs, stagiaires, prestataires, DSI qui « ont fait un WP il y a dix ans ». Cette mémoire n'est pas un argument de nostalgique. C'est moins de formation, moins de demandes « où je clique », moins de dépendance à un seul profil rare.
On me dit parfois que WordPress a vieilli. Le cœur a bougé : API, blocs, application passwords, écosystème IA, connecteurs MCP pour brancher un LLM sur l'admin sans réécrire un CMS. Ce n'est pas une raison de tout découpler. C'est une raison de ne pas jeter un outil que la comm connaît, sous prétexte qu'un slide préfère headless natif.
L'open source n'est pas un slogan. C'est pouvoir lire le code, rester maître de l'hébergement, changer de prestataire sans racheter les contenus. Un SaaS peut être excellent. Il n'est pas à vous. Le jour où le tarif au record ou au siège double, vous négociez ou vous migrez. Avec WordPress, vous patchez. C'est une corvée. Vous n'êtes pas otage.
💡 MCP, IA, et un admin que vous ouvrez encore
Les CMS « API first » vendent l'IA comme un différenciateur. Sur WordPress, les mêmes usages arrivent : rédaction assistée, taxonomies, MCP pour lire ou proposer des contenus depuis un outil externe. L'écart n'est plus « WP ou l'avenir ». L'écart, c'est qui tiendra le prompt, les droits, et la relecture humaine.
Je refuse de changer de CMS « pour l'IA ». Si vous n'ouvrez plus l'admin, le plus bel assistant du monde restera éteint. Un WordPress headless que la comm sait déjà utiliser bat un Sanity flambant neuf que personne n'alimente après le sprint 3.
⚠️ Convertir un WordPress classique, et pouvoir revenir
C'est l'argument que Strapi et Contentful ne peuvent pas copier. Vous avez déjà un WordPress classique : pages, médias, utilisateurs, ACF, parfois WooCommerce. Passer en WordPress headless, c'est retirer le thème, exposer l'API, brancher un front. Les contenus restent. Les comptes restent. Vous restez dans le même admin.
Tout ne traverse pas tout seul. Formulaires, preview, SEO plugin, search, related posts : chaque pièce du thème devient une spec. On le budgète. On ne le découvre pas pendant les tests. WooCommerce en headless, ce n'est plus « on garde la boutique ». C'est un projet commerce à part (panier, paiement, stocks). Si la boutique est le cœur, lisez d'abord le comparatif WordPress / PrestaShop, pas un slide CMS.
L'inverse existe. Si le front devient trop cher, si le second canal n'arrive jamais, si la preview n'a jamais été livrée : on peut remettre un thème. Pas en un après-midi, mais sans migration de CMS, sans réécrire la taxonomie, sans racheter les licences. Le contenu n'est pas prisonnier d'un schéma propriétaire.
Chez Strapi, Contentful, Sanity, sortir coûte un export, un mapping, une rééducation. Chez un custom, ça coûte le développeur qui part. Chez WordPress, le chemin retour est un thème, pas un nouveau produit.
🧭 Ce que ça change pour la TMA et le recrutement
Un WordPress headless, c'est encore du PHP à patcher, plus un front JS. Deux stacks. C'est le coût déjà décrit dans l'article sur le ROI. L'avantage reste le vivier : plus de prestataires WordPress que de prestataires Strapi seniors, plus de gens qui savent diagnostiquer une admin qu'une instance Contentful mal rodée.
Strapi open source, vous l'hébergez : Node, mises à jour, plugins. Contentful, vous payez le siège et la volumétrie. Sanity, le volume de données et les sièges. Aucun n'est « sans TMA ». Ils déplacent la TMA. WordPress la laisse là où vos interlocuteurs la connaissent déjà.
📌 Quand Strapi, Contentful ou un custom gagnent vraiment
Greenfield, zéro WordPress, équipe Node déjà là, modèle de contenus très typé (objets métier, pas des pages) : Strapi ou Directus peuvent être plus honnêtes. Vous n'achetez pas vingt ans de plugins dont vous n'avez pas besoin.
Gouvernance SaaS, SSO imposé, SLA contractuel, plusieurs marques qui ne veulent pas toucher à PHP : Contentful (ou un cousin) peut gagner, si le budget sièges est assumé à trois ans. Ce n'est pas plus simple. C'est plus cadré, et plus cher à la sortie.
Sanity plaît aux fronts qui veulent un studio sur-mesure. Un custom Symfony plaît quand le contenu est déjà le métier (produits, workflow, droits fins) et que WordPress serait un déguisement. Dans ces cas, je ne force pas WP. Je refuse juste de faire semblant que c'est le défaut « moderne ».
Garder WordPress n'est pas une nostalgie. Jeter WordPress pour un slide, si.
🧪 Ce que je refuse
Je refuse de reconstruire tout le contenu dans un autre CMS « pour être headless ». Le headless est une architecture, pas une excuse pour une migration des contenus. Je refuse aussi de vendre Sanity ou Strapi si vous publiez déjà chaque semaine dans WordPress, sans autre motif qu'un préjugé de développeur.
Je refuse le WordPress headless « parce que c'est WordPress » sur un produit qui n'a aucune page, seulement des objets métier. Là, un CMS plus étroit coûte moins cher à tenir. Les deux dogmatismes existent. Les deux facturent.
🔎 Points à passer en revue en une réunion
Avez-vous déjà un WordPress vivant, avec des gens qui le remplissent ? Si oui, WordPress headless part gagnant, sauf si le modèle de contenus n'a plus rien d'une page. Avez-vous zéro CMS et une équipe Node ? Strapi devient audible. Avez-vous un achat SaaS imposé et un budget sièges ? Contentful entre dans la discussion. Sinon, restez sur ce que vous ouvrez déjà.
Écrivez le chemin retour. Si vous partez de WP, le retour est un thème. Si vous partez ailleurs, le retour est une migration. Cette phrase seule évite la moitié des regrets. Pour le coût du découplage lui-même, lisez « WordPress headless : quand ça vaut le coût ». Ici, on a choisi le CMS. Pas le badge.
- WordPress déjà vivant : headless d'abord
- Zéro CMS, équipe Node : Strapi audible
- SaaS et sièges imposés : Contentful à cadrer
- Chemin retour écrit avant de signer
