J'ai migré des dizaines de sites WordPress vers des architectures headless au cours des cinq dernières années. Certaines de ces migrations étaient absolument justifiées -- les équipes ont constaté des chargements de pages plus rapides, moins d'incidents de sécurité et la capacité à déployer des fonctionnalités que WordPress ne pouvait tout simplement pas gérer. Mais j'ai aussi dissuadé de nombreuses équipes de migrer. WordPress alimente plus de 43% du web pour une bonne raison, et le supprimer simplement parce que « headless c'est cool » est une erreur coûteuse.

Cet article est le cadre de décision honnête que j'aurais aimé qu'on me donne à l'époque où je fixais un site WordPress qui mettait 8 secondes à charger en me demandant si je devais tout raser. Nous couvrirons les vrais signaux montrant que vous avez dépassé WordPress, ce vers quoi migrer en 2026, et comment prendre une décision sans gaspiller six mois et un quart de million de dollars.

Table des matières

7 signes que vous avez dépassé WordPress : Quand passer à Headless en 2026

Le bilan de réalité WordPress : Qu'est-ce qui a vraiment changé en 2026

Soyons clair. WordPress 6.7+ s'est amélioré de manière significative. L'édition de site complète est maintenant mature. L'équipe de performance a livré de véritables améliorations -- chargement différé, prérendu spéculatif, et le plugin Performance Lab ont comblé une partie du fossé. Si vous exécutez WordPress sur un hébergement solide comme Cloudways ou Kinsta avec un thème bien construit, vous pouvez absolument servir un site rapide.

Mais voilà : ces améliorations ont un plafond. WordPress est toujours une application PHP monolithique qui rend le HTML à chaque requête (à moins que vous superposiez la mise en cache, ce qui introduit sa propre complexité). L'architecture pilotée par base de données qui rend WordPress flexible est la même architecture qui le rend lent sous pression.

Je ne suis pas anti-WordPress. Je suis anti-prétendre que chaque outil fonctionne pour chaque situation. Parlons donc de quand WordPress cesse vraiment d'être le bon outil.

7 signes que vous avez vraiment dépassé WordPress

Ce ne sont pas des problèmes théoriques. Ce sont des modèles que j'ai observés à plusieurs reprises dans les engagements clients chez Social Animal, et ce sont les signaux qui m'ont fait dire « ouais, c'est le moment ».

Signe 1 : Vos temps de chargement de page s'aggravent malgré l'optimisation

Vous avez déjà fait les bases. Vous utilisez WP Rocket ou W3 Total Cache. Vous avez Cloudflare en avant. Vous avez optimisé les images avec ShortPixel. Vous avez nettoyé les CSS de blocage de rendu. Et votre Largest Contentful Paint dépasse toujours 3 secondes sur mobile.

Quand vous avez épuisé la feuille de route d'optimisation et que vous ne frappez toujours pas les seuils des Core Web Vitals, vous combattez l'architecture, pas l'implémentation.

Signe 2 : Vous gérez plus de 30 plugins

Chaque plugin est une dépendance. Chaque dépendance est un trou de sécurité potentiel, un coup de performance et un risque de compatibilité à la prochaine mise à jour de WordPress. J'ai audité le site d'un client l'année dernière qui avait 47 plugins actifs. Quarante-sept. Le chargement des plugins seuls ajoutait 1,2 seconde à chaque requête non mise en cache.

Signe 3 : Votre équipe de développeurs redoute de travailler dessus

Celui-ci est sous-estimé. Si vos développeurs passent plus de temps à combattre WordPress qu'à construire des fonctionnalités -- en luttant avec les groupes de champs ACF, en déboguant les conflits de plugins, en essayant de faire faire aux blocs Gutenberg des choses pour lesquelles ils n'ont pas été conçus -- vous payez une taxe cachée à chaque sprint.

Les développeurs frontend modernes veulent travailler en React, TypeScript et architectures basées sur des composants. Ils ne veulent pas écrire des fichiers de modèles PHP en 2026. La vélocité des développeurs compte.

Signe 4 : Vous avez besoin de fonctionnalités pour lesquelles WordPress n'a pas été construit

Des tableaux de bord en temps réel. Des flux d'authentification utilisateur complexes. Des assistants multiples avec une logique conditionnelle. Du contenu personnalisé en fonction du comportement de l'utilisateur. Un contrôle d'accès basé sur les rôles qui va au-delà de subscriber/editor/admin.

Oui, vous pouvez ajouter tout cela à WordPress avec des plugins et du code personnalisé. Mais à un moment donné, vous construisez essentiellement une application personnalisée à l'intérieur d'un CMS conçu pour les articles de blog. La fondation ne correspond pas à la construction.

Signe 5 : Les incidents de sécurité deviennent un modèle

Si vous avez traité plus d'un incident de sécurité au cours des 12 derniers mois -- injections de malware, attaques par force brute qui sont passées, vulnérabilités de plugins qui ont été exploitées avant que vous puissiez corriger -- c'est un signal. La part de marché massive de WordPress en fait la cible #1 pour les attaques automatisées. Le rapport 2024 de Sucuri a montré que WordPress représentait plus de 96% des sites CMS infectés.

Signe 6 : Vos pics de trafic causent des arrêts

Vous êtes présenté dans un podcast. Un tweet devient viral. Votre vente Black Friday arrive. Et votre site tombe en panne. Vous pouvez jeter plus de ressources serveur à cela, bien sûr. Mais si vous payez 200-500$/mois pour l'hébergement WordPress géré juste pour gérer les pics de trafic occasionnels, vous surpayez pour un problème que les sites statiques/déployés sur edge résolvent pour 20$/mois.

Signe 7 : Vous gérez plusieurs propriétés à partir d'une seule source de contenu

Un site marketing, une application mobile, un portail partenaire et un tableau de bord interne -- tous ayant besoin du même contenu. L'API REST de WordPress peut techniquement servir tout cela, mais elle a été boulonnée après coup. La performance et l'expérience développeur des API CMS headless à usage spécifique sont dans une ligue différente.

Le mur de performance : Quand le trafic casse WordPress

Parlons chiffres. Voici ce que j'ai observé sur les sites du monde réel :

Métrique WordPress (Optimisé) Headless (Next.js/Vercel) Headless (Astro/Cloudflare)
TTFB (non mis en cache) 400-800ms 50-150ms 20-80ms
TTFB (mis en cache) 100-200ms 50-150ms 20-80ms
LCP (mobile) 2.5-4.5s 1.0-2.0s 0.8-1.5s
Utilisateurs simultanés avant dégradation 500-2,000 50,000+ (edge) 100,000+ (static)
Coût mensuel d'hébergement à l'échelle $100-500 $20-100 $0-20
Temps de construction (500 pages) N/A (dynamique) 30-90s 15-45s

Ce ne sont pas des benchmarks synthétiques. Ce sont des plages provenant de vrais sites de production. L'écart sur TTFB est particulièrement révélateur -- quand chaque requête de page frappe un processus PHP et une base de données MySQL, il y a un plancher que vous ne pouvez pas passer en dessous peu importe la quantité de mise en cache que vous ajoutez.

Le modèle de déploiement edge utilisé par Next.js sur Vercel et Astro sur Cloudflare Pages est fondamentalement différent. Votre contenu est pré-rendu et servi à partir du nœud edge CDN le plus proche de l'utilisateur. Il n'y a pas de serveur d'origine dans le chemin critique pour la plupart des requêtes.

Pour les équipes confrontées à des défis de mise à l'échelle du trafic, nous avons documenté notre approche du développement Next.js et du développement Astro qui adresse spécifiquement ces modèles de performance.

7 signes que vous avez dépassé WordPress : Quand passer à Headless en 2026 - architecture

Le bloat de plugins : Le tueur silencieux

Voici à quoi ressemble une pile de plugins WordPress typique pour un site marketing de taille moyenne :

# La pile de plugins « essentiels » qui ajoute 2-3 secondes à chaque requête
Yoast SEO                    # ~50ms
WPForms Pro                  # ~40ms
WP Rocket                    # ~30ms (ironique)
Wordfence Security           # ~80ms
Advanced Custom Fields Pro   # ~60ms
WPML (multilingue)           # ~120ms
WooCommerce (même basique)   # ~200ms
Elementor Pro                # ~150ms
MonsterInsights              # ~40ms
UpdraftPlus                  # ~20ms
Redirection                  # ~15ms
Smush Pro                    # ~30ms

C'est 835ms de surcharge de plugin sur chaque chargement de page non mis en cache. Et c'est une pile modeste. J'ai vu des sites où l'exécution des plugins seule prend 2+ secondes.

L'équivalent headless ? La plupart de cette fonctionnalité soit n'existe pas au niveau du serveur (le SEO est géré au moment de la construction, la sécurité est gérée par la plateforme d'hébergement, les formulaires sont gérés par le frontend) ou elle est remplacée par des services à usage spécifique qui ne partagent pas un contexte d'exécution PHP.

// Dans une configuration Next.js headless, vos « plugins » sont des packages npm
// qui ne chargent que quand ils sont réellement nécessaires
import { generateMetadata } from '@/lib/seo'     // Temps de construction uniquement
import { Analytics } from '@vercel/analytics'      // Côté client, chargement différé
import { submitForm } from '@/lib/forms'           // À la demande, fonction edge

La différence architecturale est que headless sépare les préoccupations. Votre CMS gère le contenu. Votre frontend gère la présentation. Vos fonctions edge gèrent la logique dynamique. Rien ne concurrence pour le même processus PHP.

La sécurité en 2026 : WordPress vs. Headless

La sécurité WordPress n'est pas intrinsèquement mauvaise. L'équipe de base fait un travail solide. Mais l'écosystème crée une énorme surface d'attaque :

  • Vulnérabilités de plugins : Patchstack a signalé plus de 5 900 nouvelles vulnérabilités de plugins WordPress en 2024. Ce nombre a augmenté chaque année.
  • Attaques par identification : wp-login.php et xmlrpc.php sont constamment sondés par des scanners automatisés.
  • Accès au système de fichiers : WordPress a besoin d'accès en écriture à ses propres fichiers pour les mises à jour, ce qui signifie qu'un plugin compromis peut modifier les fichiers de base.
  • Exposition de la base de données : L'injection SQL reste un vecteur d'attaque majeur car chaque plugin a un accès direct à la base de données.

Une architecture headless réduit drastiquement cette surface d'attaque. Votre frontend est des fichiers statiques sur un CDN -- il n'y a rien à pirater. Votre CMS est derrière une authentification et n'est pas accessible publiquement. Votre couche API peut être verrouillée à des points de terminaison spécifiques avec limitation de débit.

Voici la comparaison du modèle de sécurité :

Vecteur d'attaque WordPress Architecture Headless
Panneau d'administration public Oui (wp-admin) Non (CMS derrière VPN/authentification)
Vulnérabilités de plugins Risque élevé (30+ plugins) Minimal (packages npm, pas d'exécution serveur)
Injection SQL Possible par les plugins CMS uniquement, pas accessible publiquement
Vulnérabilité DDoS Serveur rendu, CPU-intensif Statique/edge, mise à l'échelle triviale
Attaques du système de fichiers Accès en écriture requis Pas de système de fichiers accessible en écriture
Attaque par force brute sur connexion Cible commune CMS non exposé publiquement

Les exigences de fonctionnalités personnalisées que WordPress ne peut pas gérer

Permettez-moi de vous donner des exemples spécifiques de vrais projets :

Configurateurs de produits interactifs

Un client avait besoin d'un configurateur de produit 3D avec tarification en temps réel. Dans WordPress, cela signifiait une application React intégrée dans un shortcode, combattant Elementor pour le contrôle du DOM, chargeant jQuery ET React sur la même page. Après la migration vers Next.js avec un CMS headless, le configurateur faisait partie intégrante de l'application avec une gestion d'état partagée et un fractionnement de code approprié.

Tableaux de bord multi-locataires

Un autre client avait besoin de tableaux de bord accessibles aux clients tirant les données de plusieurs API, avec accès basé sur les rôles et mises à jour en temps réel. Nous avons essayé de construire cela dans WordPress en utilisant les types de publication personnalisés et l'API REST. Le modèle d'authentification seul -- essayer d'étendre l'authentification basée sur les cookies de WordPress pour fonctionner avec les jetons JWT pour l'accès API -- était un cauchemar.

Avec Next.js, Supabase pour l'authentification et les données en temps réel, et Payload CMS pour la gestion de contenu, le même ensemble de fonctionnalités a pris moitié moins de temps de développement et a performé dix fois mieux.

Contenu internationalisé avec routage complexe

WPML coûte 99-199$/an et ajoute un surcharge significatif. Next.js a le routage internationalisé intégré. Astro prend en charge i18n nativement. La modélisation de contenu dans les plates-formes CMS headless comme Payload gère les champs localisés comme un concept de première classe, pas une retouche de plugin.

Le cadre de décision pour la pile Headless

D'accord, vous avez décidé que WordPress ne suffit pas. La question suivante est : qu'est-ce que vous construisez ? Voici comment j'aborde la décision en 2026.

Framework frontend : Next.js vs. Astro

Facteur Next.js Astro
Meilleur pour Expériences ressemblant à des applications, tableaux de bord, e-commerce Sites de contenu, blogs, sites marketing
Interactivité Capacités SPA React complètes Architecture Islands (JS minimal par défaut)
Performance (statique) Excellente Exceptionnelle
Performance (dynamique) Excellente avec RSC Bonne avec server islands
Courbe d'apprentissage Modérée (connaissance de React requise) Inférieure (HTML-first, multi-framework)
Écosystème Massif (écosystème React) Croissance rapide
Déploiement Vercel, Netlify, Cloudflare, auto-hébergé Cloudflare, Netlify, Vercel, n'importe quel hôte statique
Prix 2026 (Vercel Pro) $20/membre/mois $0-20/mois (la plupart des hôtes)

Choisissez Next.js quand : Vous avez besoin d'expériences utilisateur authentifiées, d'un état côté client complexe, de fonctionnalités en temps réel, ou votre équipe connaît déjà React. Consultez nos capacités de développement Next.js pour voir les types de projets où cela brille.

Choisissez Astro quand : Votre site est principalement axé sur le contenu, vous voulez la performance absolue la plus rapide avec un JavaScript minimal, ou votre équipe préfère un modèle mental plus simple. Nous couvrons cela en détail dans notre pratique de développement Astro.

CMS : Payload vs. Sanity vs. Contentful

// Payload CMS 3.0 -- auto-hébergé, contrôle total
// Votre schéma EST votre code TypeScript
import { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'content', type: 'richText' },
    { name: 'author', type: 'relationship', relationTo: 'users' },
    { name: 'publishedAt', type: 'date' },
  ],
  access: {
    read: () => true,
    create: ({ req: { user } }) => user?.role === 'editor',
  },
}

J'ai fortement recommandé Payload CMS 3.0 en 2026 pour les équipes migrant de WordPress. Voici pourquoi :

  • Auto-hébergé : Pas de verrouillage client, pas de surprises de prix par siège. Hébergez-le sur Railway ou Render pour $7-20/mois.
  • Code-first : Votre schéma de contenu est TypeScript. Contrôle de version. Type-safe. Pas de clics via les menus GUI.
  • Construit sur Next.js : Le panneau d'administration s'exécute sur Next.js, donc votre équipe utilise un seul framework pour tout.
  • Gratuit et open source : Le noyau est sous licence MIT. Pas de factures surprises.

Pour les équipes qui préfèrent une solution hébergée, Sanity reste excellent (niveau gratuit généreux, $99/mois pour les équipes). Contentful reste le choix entreprise à $300+/mois mais le prix a poussé de nombreuses équipes du marché intermédiaire vers des alternatives.

Nous travaillons avec tous ces plataux dans notre pratique de développement CMS headless.

Backend/Base de données : Supabase

Si votre projet headless a besoin d'authentification utilisateur, de données en temps réel ou d'accès à la base de données au-delà de ce que fournit le CMS, Supabase est devenu le choix par défaut pour une bonne raison :

  • PostgreSQL sous le capot (pas une base de données propriétaire)
  • Authentification intégrée avec fournisseurs sociaux, liens magiques et sécurité au niveau des lignes
  • Abonnements en temps réel prêts à l'emploi
  • Fonctions edge pour la logique sans serveur
  • Le niveau gratuit gère la plupart des MVPs ; le plan Pro est $25/mois
// Abonnement en temps réel Supabase dans un composant Next.js
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(url, anonKey)

// S'abonner aux nouvelles commandes en temps réel
const channel = supabase
  .channel('orders')
  .on('postgres_changes', 
    { event: 'INSERT', schema: 'public', table: 'orders' },
    (payload) => {
      console.log('Nouvelle commande:', payload.new)
    }
  )
  .subscribe()

Essayez de faire cela dans WordPress sans un plugin de $200 et un serveur WebSocket que vous devez maintenir vous-même.

Planification de la migration : La frise chronologique honnête

Soyons réaliste à propos des délais car je vois beaucoup d'agences citer 4-6 semaines pour les migrations WordPress-to-headless. C'est soit un site très simple, soit quelqu'un ment.

Complexité du site Volume de contenu Délai réaliste Plage budgétaire (2026)
Simple marketing (10-20 pages) Faible 4-8 semaines $15,000-30,000
Taille moyenne avec blog (50-200 pages) Moyen 8-14 semaines $30,000-75,000
E-commerce (500+ produits) Élevé 14-24 semaines $75,000-200,000
Entreprise multi-site Très élevé 24-40 semaines $150,000-400,000+

Les plus grands pièges, dans l'ordre :

  1. Migration et restructuration du contenu (30% de l'effort total) -- Votre modèle de contenu WordPress ne correspond probablement pas proprement à un CMS headless. Vous devrez restructurer.
  2. Conception et développement frontend (35%) -- Vous construisez de nouveaux modèles/composants, pas des fichiers PHP de migration.
  3. Récréation de fonctionnalités (20%) -- Formulaires, recherche, e-commerce, intégrations -- tout doit être reconstruit ou remplacé.
  4. Tests et AQ (15%) -- Mappage de redirection SEO, vérification des liens brisés, tests cross-navigateur.

Pour une conversation honnête sur ce à quoi ressemblerait votre migration spécifique, contactez notre équipe. Nous vous dirons si cela en vaut la peine avant de citer quoi que ce soit.

Quand vous ne DEVRIEZ PAS migrer

J'ai promis l'honnêteté, donc voilà. Ne migrez pas depuis WordPress si :

  • Votre site est un simple blog ou site de brochure et il fonctionne bien. WordPress excelle à cela. Ne réparez pas ce qui ne casse pas.
  • Votre équipe n'a pas de développeurs JavaScript. Une pile headless nécessite des compétences en développement frontend. Si votre équipe est PHP uniquement, la courbe d'apprentissage est importante.
  • Vous dépendez fortement de plugins spécifiques WordPress qui n'ont pas d'équivalents headless. La suite complète de WooCommerce, les plugins d'adhésion comme MemberPress, les plugins LMS comme LearnDash -- ce sont des écosystèmes construits autour de WordPress qui sont difficiles à reproduire.
  • Votre budget est inférieur à $15,000. Une migration appropriée coûte de l'argent réel. Les migrations sous-financées finissent par être pires que le site WordPress qu'elles ont remplacé.
  • Vous avez juste besoin d'un meilleur hébergement. Parfois la réponse n'est pas une nouvelle architecture -- c'est de passer de GoDaddy à Kinsta. Essayez d'abord.
  • Vous n'avez pas de raison claire au-delà de « WordPress se sent vieux ». Les sentiments ne sont pas un cas commercial. Définissez les problèmes spécifiques, quantifiez le coût, et décidez ensuite.

Si votre site WordPress charge en moins de 2 secondes, votre équipe peut construire des fonctionnalités au rythme dont l'entreprise a besoin, et vous ne traitez pas d'incidents de sécurité -- restez sur WordPress. Sérieusement.

Vous pouvez consulter notre page de tarification pour comprendre ce qu'un investissement en migration coûte réellement et décider si le ROI est logique pour votre situation.

FAQ

Combien coûte la migration de WordPress vers un CMS headless ?

Pour un site marketing de taille moyenne avec 50-200 pages, attendez-vous à $30,000-75,000 pour une migration appropriée en 2026. Cela inclut la migration de contenu, le développement frontend, la récréation de fonctionnalités et la préservation du SEO. Les sites simples peuvent être réalisés pour $15,000-30,000, tandis que les sites entreprise ou e-commerce peuvent coûter $150,000+. Le coût est supérieur à une refonte WordPress, mais les économies à long terme sur l'hébergement, la sécurité et la maintenance font souvent que le ROI est positif en 12-18 mois.

Vais-je perdre mes classements SEO si je migre de WordPress vers headless ?

Non si vous le faites correctement. Les étapes critiques sont : conserver la même structure d'URL (ou mettre en place des redirections 301 appropriées pour chaque page), préserver toutes les balises méta et les données structurées, garantir que votre sitemap est généré correctement, et soumettre le nouveau sitemap à Google Search Console immédiatement après le lancement. J'ai vu des sites améliorer les classements post-migration car les scores Core Web Vitals ont bondi de manière significative. Mais j'ai aussi vu des migrations bâclées réduire le trafic de 60% parce que quelqu'un a oublié de mapper les redirections. Traitez la migration SEO comme un flux de travail de première classe, pas une réflexion rétrospective.

Puis-je utiliser WordPress comme CMS headless au lieu de migrer complètement ?

Oui, et c'est en fait une approche de bon compromis. Vous gardez WordPress comme backend de contenu (en utilisant WPGraphQL ou l'API REST) et construisez un frontend Next.js ou Astro. Vos éditeurs gardent l'interface d'administration qu'ils connaissent, et vous obtenez la performance du frontend moderne. Les inconvénients : vous avez toujours WordPress à maintenir et sécuriser, l'API REST et WPGraphQL ajoutent une surcharge comparée aux API CMS headless à usage spécifique, et vous exécutez deux systèmes au lieu d'un. C'est une bonne étape de transition, mais la plupart des équipes finissent par passer à un CMS headless dédié.

Payload CMS est-il vraiment gratuit ? Quel est le piège ?

Payload CMS 3.0 est véritablement open source sous la licence MIT. Pas de prix par siège, pas de limites d'utilisation. Le piège est que vous l'auto-hébergez, donc vous êtes responsable de l'infrastructure -- bien qu'héberger sur Railway, Render ou un VPS soit simple et bon marché ($7-25/mois). Payload offre une option d'hébergement cloud pour les équipes qui ne veulent pas gérer l'infrastructure, à partir d'environ $50/mois. Comparé au plan d'équipe de Contentful à $300+/mois, c'est une différence de coût significative.

Combien de temps dure une migration WordPress vers headless ?

Réalistement, 8-14 semaines pour un site de taille moyenne. Ce n'est pas 8-14 semaines de temps calendrier avec un développeur -- c'est un effort concentré avec une petite équipe (généralement 2-4 personnes). L'investissement de temps le plus important est la restructuration du contenu et le développement frontend. Les migrations qui essaient de se précipiter finissent avec une dette technique qui prend des mois à nettoyer. Si une agence vous cite 2-3 semaines pour autre chose qu'un simple site de brochure, posez des questions difficiles sur ce qui est coupé.

Dois-je choisir Next.js ou Astro pour mon frontend headless ?

Si votre site est principalement du contenu (blog, site marketing, documentation), Astro vous donnera une meilleure performance avec moins de complexité. Il expédie zéro JavaScript par défaut et n'hydrate que les composants interactifs. Si vous avez besoin d'expériences authentifiées, d'interactions côté client complexes ou de fonctionnalités en temps réel, Next.js est le meilleur choix car vous obtenez l'écosystème React complet. Beaucoup d'équipes utilisent les deux -- Astro pour le site marketing et Next.js pour l'application web. Les deux sont d'excellents choix en 2026.

Que se passe-t-il avec mes plugins WordPress quand je passe à headless ?

Ils ne vous accompagnent pas. La fonctionnalité de chaque plugin doit être : recréée dans votre nouvelle pile, remplacée par un service SaaS (p.ex. Formspree pour les formulaires, Algolia pour la recherche), ou déterminée comme inutile. C'est en fait un des avantages de la migration -- vous êtes forcé d'auditer ce que vous avez réellement besoin versus ce qui s'est accumulé au cours des années de « installez juste un plugin pour ça ». La plupart des sites découvrent qu'ils ne nécessitent que 30-40% de la fonctionnalité de leurs plugins.

Le headless est-il excessif pour un petit site web commercial ?

Souvent, oui. Si vous avez un site de 10 pages avec un blog, un formulaire de contact et aucune logique d'application personnalisée, WordPress sur un bon hébergement (Kinsta, WP Engine, Cloudways) est probablement le bon choix. C'est moins cher à construire, plus facile à maintenir sans développeurs, et l'expérience d'édition de contenu est mature. Headless commence à avoir du sens quand vous frappez les plafonds de performance, construisez des fonctionnalités personnalisées, gérez plusieurs canaux de contenu ou mettre à l'échelle au-delà de ce qu'une seule instance WordPress peut gérer. N'ajoutez pas la complexité architecturale dont vous n'avez pas besoin.