Votre tableau de bord WordPress bégaie avec 47 plugins actifs. Vous actualisez le panneau d'administration et regardez le spinner de chargement tourner pendant huit secondes tandis que votre site de staging affiche un écran blanc. Un autre conflit de plugin. Un autre samedi matin que vous n'aviez pas prévu de passer à faire un SSH dans une droplet pour annuler une mise à jour qui a cassé WooCommerce.

J'ai migré plus de 60 sites WordPress vers des stacks headless—Next.js, Astro, Payload CMS—et environ la moitié de ces équipes ont vu des chargements de pages 3 à 5 fois plus rapides, zéro collision de plugins, et des cycles de déploiement qui sont passés de 14 minutes à moins de deux. L'autre moitié ? Je les en ai dissuadées. WordPress alimente 43 % du web parce qu'il fonctionne pour la plupart des cas d'usage. Le déchirer parce qu'une conférence rendait le headless facile est une erreur de 40 000 $ qui sabote votre feuille de route pendant un trimestre.

Alors comment savoir quand le changement a vraiment du sens—et quand vous êtes juste fatigué de voir ce badge de notification de mise à jour ?

Cet article est le cadre de décision honnête que j'aurais aimé qu'on me donne à l'époque où je regardais un site WordPress qui prenait 8 secondes à charger et je me demandais si je devais tout brûler. Nous couvrirons les vrais signaux que vous avez dépassé WordPress, vers quoi migrer en 2026, et comment prendre la 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 au headless en 2026

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

Soyons clairs. WordPress 6.7+ s'est véritablement amélioré. L'édition complète du site est maintenant mûre. L'équipe de performance a livré de vraies améliorations—chargement différé, prérendu spéculatif, et le plugin Performance Lab ont réduit l'écart. Si vous exécutez WordPress sur un bon hébergeur 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 du HTML à chaque requête (sauf si vous ajoutez de la mise en cache par-dessus, ce qui introduit sa propre complexité). L'architecture basée sur 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 vus répétés à travers les engagements clients chez Social Animal, et ce sont les signaux qui m'ont fait dire « oui, c'est le moment ».

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

Vous avez déjà fait l'essentiel. Vous exécutez WP Rocket ou W3 Total Cache. Vous avez Cloudflare devant. Vous avez optimisé les images avec ShortPixel. Vous avez nettoyé les CSS bloquants. Et votre Largest Contentful Paint est toujours au-dessus de 3 secondes sur mobile.

Quand vous avez épuisé le manuel d'optimisation et vous ne répondez toujours pas aux seuils Core Web Vitals, vous combattez l'architecture, pas l'implémentation.

Signe 2 : Vous gérez 30+ plugins

Chaque plugin est une dépendance. Chaque dépendance est un trou de sécurité potentiel, un impact sur les performances, 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. La charge du plugin seule ajoutait 1,2 seconde à chaque requête non mise en cache.

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

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

Les développeurs frontaux modernes veulent travailler en React, TypeScript, et architectures basées sur composants. Ils ne veulent pas écrire de fichiers de template 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 multi-étapes avec logique conditionnelle. Du contenu personnalisé basé sur le comportement des utilisateurs. Un contrôle d'accès basé sur les rôles qui va au-delà de subscriber/editor/admin.

Oui, vous pouvez greffer tout cela sur WordPress avec des plugins et du code personnalisé. Mais à un certain point, vous construisez essentiellement une application personnalisée à l'intérieur d'un CMS conçu pour les billets de blog. La fondation ne correspond pas au bâtiment.

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 ont réussi, vulnérabilités de plugins exploitées avant que vous puissiez les corriger—c'est un signal. La part de marché massive de WordPress le rend cible numéro 1 pour les attaques automatisées. Le rapport 2024 de Sucuri a montré que WordPress representait plus de 96 % des sites CMS infectés.

Signe 6 : Vos pics de trafic causent des temps d'arrêt

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

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

Un site marketing, une app 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é ajoutée après coup. La performance et l'expérience développeur des API CMS headless dédiées sont dans une autre ligue.

Le mur de performance : Quand le trafic casse WordPress

Parlons chiffres. Voici ce que j'ai observé sur des 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+ (statique)
Coût d'hébergement mensuel à grande échelle $100-500 $20-100 $0-20
Temps de build (500 pages) N/A (dynamique) 30-90s 15-45s

Ce ne sont pas des repères synthétiques. Ce sont des plages de sites de production réels. 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 descendre en dessous peu importe combien de mise en cache vous ajoutez.

Le modèle de déploiement en edge que Next.js sur Vercel et Astro sur Cloudflare Pages utilisent est fondamentalement différent. Votre contenu est prérendu et servi depuis le nœud 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 faisant face à des défis de scaling de trafic, nous avons documenté notre approche au développement Next.js et au développement Astro qui aborde spécifiquement ces modèles de performance.

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

L'encrassement des 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 plugins sur chaque chargement de page non mis en cache. Et ceci est une pile modeste. J'ai vu des sites où l'exécution du plugin seule prend 2+ secondes.

L'équivalent headless ? La plupart de ces fonctionnalités n'existent soit pas au niveau du serveur (le SEO est géré au moment de la build, la sécurité est gérée par la plateforme d'hébergement, les formulaires sont gérés par le frontend) soit elles sont remplacées par des services dédiés qui ne partagent pas un contexte d'exécution PHP.

// Dans une configuration Next.js headless, vos "plugins" sont des packages npm
// qui se chargent uniquement quand ils sont réellement utilisés
import { generateMetadata } from '@/lib/seo'     // Build-time seulement
import { Analytics } from '@vercel/analytics'      // Client-side, lazy-loaded
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 rivalise 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 principale fait du bon travail. Mais l'écosystème crée une surface d'attaque massive :

  • Vulnérabilités de plugins : Patchstack a rapporté plus de 5 900 nouvelles vulnérabilités de plugins WordPress en 2024. Ce nombre a augmenté chaque année.
  • Attaques par identifiants : 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 principaux.
  • Exposition de la base de données : L'injection SQL reste un vecteur d'attaque majeur parce que 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 à hacker. Votre CMS est derrière l'authentification et 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'admin public Oui (wp-admin) Non (CMS derrière VPN/auth)
Vulnérabilités de plugins Risque élevé (30+ plugins) Minimal (packages npm, pas d'exécution serveur)
Injection SQL Possible via plugins CMS seulement, pas accessible publiquement
Vulnérabilité DDoS Serveur rendu, CPU intensif Statique/edge, infiniment évolutif
Attaques du système de fichiers Accès en écriture requis Pas de système de fichiers inscriptible
Attaque par force brute au login Cible courante CMS non accessible publiquement

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

Permetez-moi de vous donner des exemples spécifiques à partir de projets réels :

Configurateurs de produits interactifs

Un client avait besoin d'un configurateur de produits 3D avec tarification en temps réel. Dans WordPress, cela signifiait une app React intégrée dans un shortcode, combattant avec 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 était une partie native de l'application avec gestion d'état partagée et code splitting approprié.

Tableaux de bord multi-locataires

Un autre client avait besoin de tableaux de bord orientés clients extrayant des données de plusieurs APIs, 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 des types de posts personnalisés et l'API REST. Le seul modèle d'authentification—essayer d'étendre l'authentification basée sur cookie de WordPress pour travailler avec les tokens 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 prenait la moitié du temps de développement et fonctionnait dix fois mieux.

Contenu internationalisé avec routage complexe

WPML coûte 99-199 $/année et ajoute une surcharge significative. Next.js a un routage internationalisé intégré. Astro supporte l'i18n en natif. La modélisation de contenu dans les plateformes CMS headless comme Payload gère les champs localisés comme un concept de première classe, pas un plugin après coup.

Le cadre de décision de la stack Headless

D'accord, vous avez décidé que WordPress ne suffisait plus. La question suivante est : avec quoi construisez-vous ? Voici comment je pense à la décision en 2026.

Framework frontend : Next.js vs. Astro

Facteur Next.js Astro
Meilleur pour Expériences semblables à une application, tableaux de bord, e-commerce Sites de contenu, blogs, sites marketing
Interactivité Capacités complètes de React SPA Architecture îles (JS minimal par défaut)
Performance (statique) Excellente Exceptionnelle
Performance (dynamique) Excellente avec RSC Bonne avec server islands
Courbe d'apprentissage Modérée (connaissances React requises) Plus basse (HTML-first, multi-framework)
Écosystème Massif (écosystème React) Croissant rapidement
Déploiement Vercel, Netlify, Cloudflare, auto-hébergé Cloudflare, Netlify, Vercel, n'importe quel hôte statique
Tarification 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'état client-side 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 les types de projets où cela brille.

Choisissez Astro quand : Votre site est principalement piloté par 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 complet
// 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 vivement recommandé Payload CMS 3.0 en 2026 pour les équipes migrant depuis WordPress. Voici pourquoi :

  • Auto-hébergé : Pas de verrouillage fournisseur, pas de surprises de tarification 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 clic à travers des menus GUI.
  • Construit sur Next.js : Le panneau d'administration fonctionne sur Next.js, donc votre équipe utilise un framework pour tout.
  • Gratuit et open source : Le cœur est sous licence MIT. Pas de factures surprises.

Pour les équipes qui préfèrent une solution hébergée, Sanity reste excellente (tier gratuit généreux, 99 $/mois pour les équipes). Contentful reste le choix d'entreprise à 300+$/mois mais la tarification a poussé de nombreuses équipes de marché intermédiaire vers d'autres alternatives.

Nous travaillons avec toutes ces plates-formes 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 le CMS fournit, 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 serverless
  • Le tier 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 chronologie honnête

Soyons réalistes sur les chronologies parce que je vois beaucoup d'agences citer 4-6 semaines pour les migrations WordPress vers headless. C'est soit un site très simple soit quelqu'un ment.

Complexité du site Volume de contenu Chronologie réaliste Plage budgétaire (2026)
Marketing simple (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 gros générateurs de temps, par ordre :

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

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

Quand vous ne devriez PAS migrer

J'ai promis de l'honnêteté, alors voici. Ne migrez pas depuis WordPress si :

  • Votre site est un simple blog ou site vitrine et il fonctionne bien. WordPress est excellent pour cela. Ne réglez pas ce qui n'est pas cassé.
  • Votre équipe n'a pas de développeurs JavaScript. Une stack headless nécessite des compétences en développement frontend. Si votre équipe est PHP uniquement, la courbe d'apprentissage est significative.
  • Vous dépendez fortement des plugins spécifiques à WordPress qui n'ont pas d'équivalents headless. L'ensemble des fonctionnalités complètes de WooCommerce, les plugins d'adhésion comme MemberPress, les plugins LMS comme LearnDash—ceux-ci ont 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 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 passer de GoDaddy à Kinsta. Essayez d'abord cela.
  • 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 vérifier notre page de tarification pour comprendre quel est réellement un investissement de migration et décider si le ROI a du sens pour votre situation.

FAQ

Combien coûte une 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 fait pour 15 000-30 000 $, tandis que les sites d'entreprise ou d'e-commerce peuvent coûter 150 000 $+. Le coût est plus élevé qu'une refonte WordPress, mais les économies à long terme en hébergement, sécurité, et maintenance rendent souvent le ROI positif dans 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 : maintenir la même structure d'URL (ou configurer des redirections 301 appropriées pour chaque page), préserver toutes les méta-tags et données structurées, vous assurer que votre sitemap est généré correctement, et soumettez le nouveau sitemap à Google Search Console immédiatement après le lancement. J'ai vu des sites améliorer les classements après migration parce que les scores Core Web Vitals ont augmenté considérablement. Mais j'ai aussi vu des migrations échouées qui ont tanné 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 après coup.

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

Oui, et c'est en réalité une bonne approche de compromis. Vous gardez WordPress comme votre 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 une performance 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 dédiées, et vous exécutez deux systèmes au lieu d'un. C'est une bonne étape transitoire, mais la plupart des équipes passent finalement à un CMS headless dédié.

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

Payload CMS 3.0 est genuinely open source sous licence MIT. Pas de tarification par siège, pas de limites d'utilisation. Le piège est que vous auto-l'hébergez, donc vous êtes responsable de l'infrastructure—bien qu'héberger sur Railway, Render, ou un VPS soit simple et pas cher (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 équipe de Contentful à 300+$/mois, c'est une différence de coût significative.

Combien de temps prend une migration de WordPress vers headless ?

Réalistiquement, 8-14 semaines pour un site de taille moyenne. Ce ne sont pas 8-14 semaines de temps calendaire 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 de la dette technique qui prend des mois à nettoyer. Si une agence vous cote 2-3 semaines pour autre chose qu'un simple site vitrine, posez des questions difficiles sur ce qui est coupé.

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

Si votre site est principalement du contenu (blog, site marketing, documentation), Astro vous donnera de meilleures performances avec moins de complexité. Il expédie zéro JavaScript par défaut et hydrate uniquement les composants interactifs. Si vous avez besoin d'expériences authentifiées, d'interactions client-side complexes, ou de fonctionnalités en temps réel, Next.js est le meilleur choix parce que vous obtenez l'écosystème React complet. De nombreuses é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 au headless ?

Ils ne viennent pas avec vous. La fonctionnalité de chaque plugin doit soit : être recréée dans votre nouveau stack, être remplacée par un service SaaS (par exemple, Formspree pour les formulaires, Algolia pour la recherche), ou être déterminée comme inutile. C'est en réalité l'un des avantages de la migration—vous êtes forcé d'auditer ce que vous avez vraiment besoin versus ce qui s'est accumulé au fil des années de « juste installer un plugin pour cela ». La plupart des sites découvrent qu'ils n'ont besoin que de 30-40 % de la fonctionnalité de leur plugin.

Est-ce que headless est excessif pour un petit site commercial ?

Souvent, oui. Si vous avez un site de 10 pages avec un blog, un formulaire de contact, et pas de logique d'application personnalisée, WordPress sur 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 à faire sens quand vous atteignez des plafonds de performance, construisez des fonctionnalités personnalisées, gérez plusieurs canaux de contenu, ou montez au-delà de ce qu'une seule instance WordPress peut gérer. N'ajoutez pas de complexité architecturale dont vous n'avez pas besoin.