WordPress headless : quand ça vaut le coût, ce n'est pas une question de tendance front. C'est une question de surfaces à nourrir, d'équipe disponible, de preview, de TMA double, de durée de vie du produit. Cet article chiffre (ordres de grandeur, pas une grille tarifaire) et qualifie. Il se lit après « WordPress classique ou headless ». Ici, on parle argent, risque, et critères d'arrêt : quand rester en thème, quand découpler, quand choisir un statique sans WordPress du tout.
🔎 Où va l'argent dans un headless
Build du front, contrat d'API, preview, auth, SEO côté front, hébergement WordPress plus hébergement front, TMA des deux, formation. Le thème classique a : thème, plugin SEO, une TMA sur une seule stack. L'écart n'est pas 10 %. Il est souvent un facteur deux sur la première année, parfois plus si la preview est prise au sérieux.
Les devis qui « offrent » le headless au prix d'un thème ont coupé quelque chose : souvent l'aperçu, souvent la TMA front, souvent le SEO. Vous le paierez après.
🛠️ Cas où ça vaut le coût
Plusieurs fronts (site, app mobile, bornes, extranet) sur les mêmes contenus. Une équipe front déjà salariée qui livrera plus vite en React/Vue qu'en thème PHP. Des exigences de perf / UX que le thème ne tiendra pas, et un budget de TMA double assumé. Un produit à cinq ans, pas une vitrine à dix-huit mois.
Dans ces cas, le headless n'est pas cher. Il est moins cher que de forcer WordPress à être une app, ou que de dupliquer les rédactions.
✅ Cas où ça ne le vaut pas
Une vitrine de 12 à 40 pages, vous qui publiez seul, un prestataire unique, un blog classique. Un « on veut un site moderne » sans surface seconde. Un budget TMA déjà juste pour un WordPress. Ici le headless achète de la complexité. Un site statique, ou un WordPress classique soigné, sert le même visiteur pour moins.
Les landing pages de campagne qui changent chaque semaine : le headless sans preview est un enfer. Le classique, ou le statique généré depuis des fichiers, gagne.
⚠️ Comparer à un statique sans WordPress
Si l'argument du headless est la perf et la sécu, un site statique sans WordPress est souvent moins cher : plus de CMS à patcher. Si l'argument est l'édition WordPress, alors le headless doit vraiment livrer l'édition. Sinon vous avez le pire des deux (un WordPress à maintenir, un front à déployer) sans le bénéfice comm.
L'article WordPress ou site statique pose cette alternative. Le headless est le pont, pas le défaut.
📌 Coût de TMA à trois ans
Année 1 : build. Années 2-3 : deux veilles de sécu (PHP et JS), deux dépendances, les ruptures d'API. Un front Next/Nuxt se refond plus souvent qu'un thème PHP sage. Budgétez des évolutions front, pas seulement des maj WordPress.
Un forfait unique « TMA headless » qui ne dit pas combien d'heures front vs WP est un forfait qui mentira à la première grosse maj React.
🧭 Signes que le devis est honnête
Une ligne preview. Une ligne SEO front. Une ligne TMA double. Un hors-scope (plugins WordPress qui ne traverseront pas). Un critère d'arrêt (si on n'a qu'un site, on reste classique). L'absence de ces lignes n'est pas un bon prix. C'est un risque.
Je préfère perdre un projet headless mal cadré que le livrer. Le coût se juge à l'année 2, quand le client veut « juste changer le header » et découvre un build.
💡 Décider avec trois questions
Combien de fronts dans deux ans ? Qui tient le JS ? Quel budget TMA annuel réel ? Si les réponses sont un, personne, petit : pas de headless. Si les réponses sont plusieurs, une équipe, un budget : on ouvre le chantier.
WordPress headless vaut le coût quand il évite une duplication ou une pile de thèmes à entretenir. Il ne le vaut pas comme badge. C'est toute l'histoire.
🧪 Ordres de grandeur, sans grille tarifaire
Un WordPress classique soigné de vitrine : un build, une TMA. Un headless du même périmètre : souvent le double à la construction, plus 30 à 80 % de TMA en plus selon le preview. Un headless multi-fronts : le build se justifie si chaque front aurait coûté une rédaction ou un connecteur. Ces fourchettes bougent. L'écart de forme, rarement.
WordPress headless : quand ça vaut le coût, c'est quand l'écart est absorbé par un gain (moins de duplication, une app déjà prévue, une équipe front déjà là). Sinon l'écart est un hobby d'architecture.
🔎 Indicateurs à suivre après six mois
Temps pour publier une page (avec preview). Incidents « API vs front ». Heures de TMA front vs WP. LCP réel. Si publier a ralenti et que le LCP n'a pas bougé, le headless a perdu. Si publier est égal et qu'un second front est né sans nouvelle rédaction, il a gagné.
On revoit le contrat à six mois. Pas à quatre ans quand tout le monde a oublié pourquoi on avait découplé.
Deux stacks, c'est deux TMA. On le dit avant de découpler, pas après.
