J'ai perdu le compte du nombre de fois où un client est venu nous voir avec une variation de la même histoire : « Notre site WordPress a été piraté. Nous l'avons nettoyé. Il a été piraté à nouveau. Nous abandonnons. » Le dernier cas était une entreprise de commerce électronique de taille moyenne dont la boutique WooCommerce avait été injectée avec un skimmer de carte de crédit caché dans une mise à jour de plugin légitime. Ils fuyaient les données de paiement des clients depuis trois semaines avant que quelqu'un ne s'en aperçoive. Ce n'est pas un cas limite. C'est un mardi dans l'écosystème WordPress.

Cet article n'a pas pour but de critiquer WordPress. Il alimente une énorme partie du web pour une bonne raison. Mais l'architecture qui l'a rendu accessible en 2005 est la même architecture qui en fait un aimant pour les attaques automatisées en 2025. Si vous avez été piraté — ou si vous en avez assez de dépenser de l'argent en plugins de sécurité qui sont eux-mêmes des vecteurs d'attaque — ceci est votre guide pour passer à quelque chose fondamentalement plus sûr.

Table des matières

WordPress piraté ? Pourquoi la migration vers Next.js + Supabase est votre meilleure solution

Le problème de sécurité WordPress est architectural

Soyons clairs : l'équipe WordPress effectue un travail solide en matière de sécurité. WordPress core, à jour, est raisonnablement sûr. Mais personne n'exécute que WordPress core. Le site WordPress moyen a 20-30 plugins installés. Chacun d'eux est une dépendance que vous n'avez pas écrite, maintenue par quelqu'un que vous ne connaissez pas, avec accès à votre base de données, votre système de fichiers et aux données de vos utilisateurs.

Voici ce qui passe inaperçu dans les articles sur les « meilleures pratiques de sécurité WordPress » : le problème n'est pas que les propriétaires de sites WordPress sont négligents. Le problème est que l'architecture de WordPress vous oblige à installer du code PHP exécutable provenant de tiers directement sur votre serveur pour obtenir des fonctionnalités de base. C'est comme donner à chaque entrepreneur qui travaille sur votre maison une copie permanente de votre clé de maison.

La base de données de vulnérabilités WPScan a suivi plus de 7 900 nouvelles vulnérabilités WordPress en 2024, les plugins représentant environ 96 % d'entre elles. Le rapport de menace 2024 de Sucuri a révélé que WordPress représentait environ 95 % de toutes les infections CMS qu'ils ont nettoyées. Et Patchstack a rapporté que 33 % des vulnérabilités critiques de WordPress en 2024 n'avaient aucun correctif disponible au moment de la divulgation.

Ce ne sont pas des bugs qui peuvent être corrigés par de meilleures pratiques de codage. Ce sont des propriétés émergentes de l'architecture elle-même.

Vecteurs d'attaque courants WordPress en 2025

Avant de parler de la solution, cataloguons ce à quoi vous vous défendez réellement. J'ai personnellement trié des dizaines de sites WordPress compromis, et les attaques suivent des modèles prévisibles.

Injection SQL via les plugins

WordPress utilise une base de données MySQL avec un schéma bien documenté. Chaque plugin qui accepte une entrée utilisateur et touche à la base de données est un point d'injection SQL potentiel. La fonction $wpdb->prepare() existe, mais elle est facultative. Les développeurs de plugins l'oublient, l'utilisent mal, ou la sautent entièrement pour les requêtes « simples ».

J'ai une fois tracé une injection jusqu'à un plugin de formulaire de contact qui avait été abandonné depuis 18 mois mais était toujours installé sur plus de 200 000 sites. L'attaquant utilisait une injection basée sur UNION pour vider la table wp_users, récupérer les hachages de mot de passe admin et les craquer hors ligne.

-- À quoi ressemble une injection SQL WordPress typique dans les logs
GET /wp-content/plugins/vulnerable-plugin/ajax.php?id=1%20UNION%20SELECT%201,user_login,user_pass,4,5%20FROM%20wp_users--

Injection d'objets PHP et exécution de code à distance

L'utilisation intensive par WordPress de serialize() et unserialize() crée des opportunités d'injection d'objets PHP. Quand un plugin désérialise des données contrôlées par l'utilisateur (et beaucoup le font), un attaquant peut créer des charges utiles qui exécutent du code arbitraire pendant le processus de désérialisation.

En 2024, une vulnérabilité RCE critique dans un plugin de sauvegarde populaire (installé sur plus de 5 millions de sites) a permis à des attaquants non authentifiés d'exécuter du code PHP arbitraire. La correction a pris 11 jours à livrer. Onze jours où chaque site avec ce plugin était une cible facile.

Attaques de la chaîne d'approvisionnement des plugins

C'est celle qui me fait le plus peur. Les attaquants achètent des plugins abandonnés avec de grandes bases d'installation, poussent une « mise à jour de sécurité » contenant une porte dérobée, et les mécanismes de mise à jour automatique de WordPress distribuent le malware à chaque site exécutant ce plugin. C'est arrivé avec Display Widgets (300 000 installations) et Social Warfare (70 000 installations), et ce ne sont que ceux qui ont été détectés.

Attaques par force brute sur wp-login.php

Chaque site WordPress expose /wp-login.php et /xmlrpc.php par défaut. Les botnets automatisés frappent constamment ces points d'extrémité. Wordfence a rapporté avoir bloqué une moyenne de 3 milliards de requêtes malveillantes par mois sur son réseau en 2024. Même avec limitation de débit et authentification à deux facteurs, vous dépensez les ressources du serveur pour traiter ces attaques.

Scripting intersite (XSS) stocké via les thèmes et plugins

Le XSS stocké dans WordPress est particulièrement dangereux car le tableau de bord administrateur et le site public partagent le même contexte de session. Une charge utile XSS injectée via un commentaire, une soumission de formulaire, ou un paramètre de plugin vulnérable peut s'escalader à un accès administrateur complet.

Pourquoi l'architecture Headless élimine des catégories entières d'attaques

Ici, les choses deviennent intéressantes. Une architecture headless ne réduit pas seulement votre surface d'attaque — elle élimine des catégories entières d'attaques en supprimant les conditions qui les rendent possibles.

Dans une configuration WordPress traditionnelle, le même serveur qui rend votre HTML :

  • Exécute du code PHP provenant de 20+ plugins tiers
  • Gère l'authentification des utilisateurs
  • Se connecte à la base de données
  • Sert l'interface administrateur
  • Gère les téléchargements de fichiers
  • Traite les soumissions de formulaires

C'est beaucoup de responsabilités pour une seule application. Dans une configuration headless avec Next.js et Supabase, ces responsabilités sont séparées entre des services isolés :

  • Frontend (Next.js sur Vercel/Netlify) : HTML/JS statique servi depuis un CDN. Aucun runtime côté serveur exposé à l'internet public dans la plupart des cas.
  • Base de données + Auth (Supabase) : Postgres géré avec Row Level Security, jamais directement exposé aux utilisateurs finaux.
  • Couche API : Fonctions serverless avec des points d'extrémité explicites et minimaux.
  • CMS (si nécessaire) : CMS headless exécuté sur sa propre infrastructure isolée.

Il n'y a pas de PHP à injecter. Il n'y a pas de répertoire de plugins avec accès en écriture. Il n'y a pas de session partagée entre l'administrateur et le site public. Il n'y a pas de wp-login.php que les bots peuvent frapper.

Vous n'avez pas besoin d'un WAF pour protéger une surface d'attaque qui n'existe pas.

WordPress piraté ? Pourquoi la migration vers Next.js + Supabase est votre meilleure solution - architecture

Next.js + Supabase : une pile axée sur la sécurité

Soyons spécifiques sur la raison pour laquelle cette combinaison particulière fonctionne si bien du point de vue de la sécurité.

Next.js : le frontend qui n'exécute pas de code

Quand vous construisez un site Next.js avec la génération statique (SSG) ou la régénération statique incrémentale (ISR), ce qui est déployé ce sont des fichiers HTML, CSS et JavaScript sur un CDN. Il n'y a pas de serveur d'application traitant les requêtes en temps réel. Vous ne pouvez pas SQL-injecter un CDN.

Pour les fonctionnalités dynamiques, les Server Actions et Route Handlers de Next.js s'exécutent en tant que fonctions serverless. Chaque fonction est :

  • Isolée dans son propre contexte d'exécution
  • Sans état (pas de mémoire partagée entre les requêtes)
  • De courte durée (démarrage à froid, exécution, arrêt)
  • Explicitement définie (pas de découverte automatique de points d'extrémité)
// Route Handler Next.js -- explicite, typé, minimal
import { createClient } from '@/lib/supabase/server'
import { NextRequest, NextResponse } from 'next/server'
import { z } from 'zod'

const ContactSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  message: z.string().min(10).max(5000),
})

export async function POST(request: NextRequest) {
  const body = await request.json()
  const parsed = ContactSchema.safeParse(body)
  
  if (!parsed.success) {
    return NextResponse.json({ error: 'Invalid input' }, { status: 400 })
  }
  
  const supabase = await createClient()
  const { error } = await supabase
    .from('contact_submissions')
    .insert(parsed.data)
  
  if (error) {
    return NextResponse.json({ error: 'Submission failed' }, { status: 500 })
  }
  
  return NextResponse.json({ success: true })
}

Comparez cela à un plugin de formulaire de contact WordPress qui doit se connecter au système d'action de WordPress, inclure son propre gestionnaire AJAX, gérer sa propre vérification nonce, et construire ses propres requêtes SQL. La version Next.js a moins de pièces mobiles, une validation d'entrée via Zod, et des requêtes paramétrées via le client Supabase.

Supabase : Postgres avec Row Level Security

Supabase vous donne une base de données PostgreSQL gérée avec une fonctionnalité de sécurité fondamentale : Row Level Security (RLS). Au lieu de faire confiance à votre code d'application pour appliquer le contrôle d'accès (le modèle WordPress), vous définissez des politiques de sécurité au niveau de la base de données.

-- Seuls les utilisateurs authentifiés peuvent lire leurs propres données
CREATE POLICY "Users can view own profile"
  ON profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- Le public peut insérer dans contact_submissions mais pas lire
CREATE POLICY "Anyone can submit contact form"
  ON contact_submissions
  FOR INSERT
  WITH CHECK (true);

CREATE POLICY "Only admins can read submissions"
  ON contact_submissions
  FOR SELECT
  USING (auth.jwt() ->> 'role' = 'admin');

Même si un attaquant trouve un moyen de faire des requêtes Supabase arbitraires (ce qui est déjà beaucoup plus difficile sans un contexte d'exécution PHP), les politiques RLS les empêchent d'accéder aux données qu'ils ne devraient pas voir. C'est une défense en profondeur que WordPress ne peut fondamentalement pas offrir car son système de permissions est implémenté dans du code PHP, pas au niveau de la base de données.

Supabase gère également l'authentification avec un support intégré pour email/mot de passe, liens magiques, fournisseurs OAuth et authentification multi-facteurs. Aucun plugin requis. Aucun code tiers exécuté sur votre serveur.

Comparaison de la surface d'attaque : WordPress vs Headless

Mettons cela côte à côte.

Vecteur d'attaque WordPress Next.js + Supabase
Injection SQL Risque élevé -- les plugins construisent des requêtes brutes Quasi zéro -- requêtes paramétrées via client Supabase, RLS comme secours
Exécution de code à distance PHP Risque élevé -- les plugins exécutent du PHP côté serveur Non applicable -- pas de runtime PHP
Chaîne d'approvisionnement des plugins Risque critique -- les mises à jour automatiques distribuent les malwares Non applicable -- pas d'écosystème de plugins
Brute force (connexion) Toujours exposé (wp-login.php, xmlrpc.php) Accès administrateur via Supabase Auth ou tableau de bord séparé, aucun point d'extrémité de connexion public requis
XSS (Stocké) Risque élevé -- contexte admin/public partagé Risque faible -- React échappe la sortie par défaut, admin et public sont des apps séparées
Exploitation du téléchargement de fichiers Risque élevé -- les fichiers PHP uploadés peuvent s'exécuter Risque faible -- les uploads vont au stockage d'objets (Supabase Storage/S3), jamais exécutés en tant que code
Exposition de la base de données Accès MySQL direct si le serveur est compromis Base de données derrière l'infrastructure Supabase, politiques RLS comme garde final
DDoS sur l'origine Le serveur doit traiter chaque requête Actifs statiques sur CDN, l'origine est rarement frappée
Énumération de chemins connus wp-admin, wp-content, wp-includes tous analysables Pas de chemins prévisibles, pas de routes administrateur exposées

Guide de migration : WordPress vers Next.js + Supabase

D'accord, vous êtes convaincu (ou votre site piraté vous a convaincu). Voici comment faire réellement. Nous avons exécuté cette migration assez souvent pour avoir un processus reproductible.

Phase 1 : Triage et audit de contenu (Semaine 1)

Avant de toucher à du code, vous devez comprendre ce que vous avez réellement.

  1. Exportez tout le contenu WordPress en utilisant WP-CLI ou l'API REST. Ne vous fiez pas aux exportations XML -- elles manquent les métachamps et les types de publications personnalisées.
  2. Cataloguez toutes les fonctionnalités fournies par les plugins. Créez une feuille de calcul : nom du plugin, ce qu'il fait, si vous en avez vraiment besoin, et ce qui le remplace.
  3. Cartographiez les structures URL pour la préservation du SEO. Chaque URL existante a besoin d'une redirection ou d'une route correspondante dans Next.js.
  4. Identifiez les fonctionnalités dynamiques -- formulaires, recherche, comptes utilisateurs, commerce électronique -- qui ont besoin de points d'extrémité API.
# Exportez le contenu WordPress via l'API REST
curl -s "https://yoursite.com/wp-json/wp/v2/posts?per_page=100&page=1" | jq '.' > posts_page1.json
curl -s "https://yoursite.com/wp-json/wp/v2/pages?per_page=100" | jq '.' > pages.json
curl -s "https://yoursite.com/wp-json/wp/v2/media?per_page=100" | jq '.' > media.json

Phase 2 : Schéma Supabase et migration de données (Semaine 2)

Concevez votre schéma de base de données Supabase en fonction de l'audit de contenu. Ne replicquez pas simplement le schéma WordPress -- il est gonflé avec des tables de métadonnées et des blobs de données sérialisées.

-- Schéma propre et conçu dans un but spécifique
CREATE TABLE posts (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  title TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  content TEXT,
  excerpt TEXT,
  featured_image TEXT,
  status TEXT DEFAULT 'draft' CHECK (status IN ('draft', 'published', 'archived')),
  published_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW(),
  author_id UUID REFERENCES auth.users(id)
);

-- Activez RLS immédiatement
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Published posts are public"
  ON posts FOR SELECT
  USING (status = 'published');

CREATE POLICY "Authors can manage own posts"
  ON posts FOR ALL
  USING (auth.uid() = author_id);

Écrivez un script de migration (Node.js ou Python) qui transforme les exportations JSON WordPress en votre nouveau schéma et les insère dans Supabase.

Phase 3 : Construire Next.js (Semaines 3-5)

Construisez votre frontend Next.js. Si vous travaillez avec une équipe qui connaît la pile, cela va vite. Si vous avez besoin d'aide, notre équipe de développement Next.js a suffisamment exécuté cette migration pour avoir des opinions solides sur les bons modèles.

Décisions architecturales clés :

  • Génération statique pour les pages de contenu -- articles de blog, pages d'accueil, pages à propos. Ceux-ci deviennent des fichiers HTML sur un CDN.
  • Composants serveur pour les données dynamiques -- récupérer depuis Supabase au moment de la requête avec mise en cache.
  • Route handlers pour les soumissions de formulaires -- formulaires de contact, inscriptions à la infolettre, etc.
  • Middleware pour les redirections -- gérer toutes vos anciennes URL WordPress.
// next.config.ts -- gérer les redirects d'URL WordPress
const nextConfig = {
  async redirects() {
    return [
      {
        source: '/category/:slug',
        destination: '/blog/category/:slug',
        permanent: true,
      },
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // wp-login.php -- envoyer les bots à un 410
      {
        source: '/wp-login.php',
        destination: '/gone',
        permanent: true,
      },
      {
        source: '/wp-admin/:path*',
        destination: '/gone',
        permanent: true,
      },
    ]
  },
}

Phase 4 : Tests et validation SEO (Semaine 6)

  • Exécutez Screaming Frog sur le nouveau site pour vérifier que chaque ancienne URL se résout ou se redirige.
  • Validez que les données structurées (JSON-LD) sont présentes sur toutes les pages.
  • Testez tous les formulaires et fonctionnalités dynamiques.
  • Exécutez les vérifications Lighthouse et Core Web Vitals -- vous verrez presque certainement des améliorations puisque vous servez maintenant depuis un CDN.
  • Configurer le monitoring avec Vercel Analytics ou votre outil préféré.

Phase 5 : Lancement et changement DNS (Semaines 6-7)

Déployez sur Vercel ou Netlify, mettez à jour DNS et configurez le monitoring. Gardez l'ancienne instance WordPress hors ligne mais accessible pendant 30 jours au cas où vous auriez besoin de consulter quelque chose.

Si votre site a un trafic important ou une fonctionnalité de commerce électronique, envisagez une intégration CMS headless pour la gestion de contenu et discutez avec nous d'Astro comme alternative de frontend pour les sites riches en contenu où la performance de build a de l'importance.

Durcissement de la sécurité post-migration

Une fois que vous êtes sur la nouvelle pile, voici votre liste de contrôle de sécurité :

  1. Activez Supabase RLS sur chaque table. Aucune exception. Si une table n'a pas de politiques, elle est soit inaccessible (bon par défaut) soit grande ouverte (mauvais).
  2. Utilisez des variables d'environnement pour tous les secrets. Vercel et Netlify gèrent cela bien. Ne validez jamais les clés API.
  3. Configurez les sauvegardes de base de données Supabase. La récupération jusqu'au point dans le temps est disponible sur les plans Pro (25 $/mois).
  4. Configurez les en-têtes Content Security Policy dans votre middleware Next.js.
  5. Activez la protection DDoS de Vercel (incluse sur tous les plans).
  6. Configurez le monitoring de disponibilité -- nous utilisons Better Uptime, mais Checkly et le monitoring intégré de Vercel fonctionnent aussi.
  7. Auditez vos politiques RLS Supabase trimestriellement. Utilisez l'éditeur SQL Supabase pour tester les politiques avec différents contextes utilisateur.
// middleware.ts -- en-têtes de sécurité
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const response = NextResponse.next()
  
  response.headers.set('X-Frame-Options', 'DENY')
  response.headers.set('X-Content-Type-Options', 'nosniff')
  response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin')
  response.headers.set(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"
  )
  response.headers.set(
    'Permissions-Policy',
    'camera=(), microphone=(), geolocation=()'
  )
  
  return response
}

Coût réel de la sécurité WordPress vs Migration

Parlons argent, car c'est ce qui entraîne vraiment les décisions.

Catégorie de coûts WordPress (Annuel) Next.js + Supabase (Annuel)
Hosting 300-1 200 $ (WordPress géré) 0-240 $ (Vercel Pro)
Plugins de sécurité (Wordfence/Sucuri) 200-500 $ 0 $ (non requis)
SSL/CDN 0-200 $ 0 $ (inclus)
Nettoyage de malware (si piraté) 500-2 500 $ par incident N/A
Temps de développeur sur les correctifs de sécurité 2 000-5 000 $ 500-1 000 $
Base de données (Supabase) Incluse dans l'hébergement 0-300 $ (Tier gratuit à Pro)
Total 3 000-9 400 $ 500-1 540 $

Et c'est avant de tenir compte du coût des temps d'arrêt, de la perte de confiance des clients et des pénalités réglementaires potentielles si les données des clients sont compromises. Une seule violation nécessitant un signalement en vertu du RGPD peut coûter des dizaines de milliers en frais juridiques et de conformité.

La migration elle-même coûte généralement entre 10 000-40 000 $ selon la complexité du site. Pour la plupart des entreprises, cela s'amortit en 1-2 ans en économies de sécurité seules -- et vous obtenez un site plus rapide et plus maintenable en prime.

FAQ

WordPress est-il vraiment si peu sûr, ou est-ce exagéré ?

WordPress core est maintenu bien. Le problème est que pratiquement personne n'exécute que core. L'écosystème des plugins est où vivent 96 % des vulnérabilités, et vous ne pouvez pas exécuter un site WordPress utile sans plugins. Ce n'est pas exagéré -- Sucuri a nettoyé les malwares de plus de 60 000 sites WordPress en 2024 seul. L'architecture vous oblige à faire confiance à du code PHP tiers sur votre serveur, et cette confiance est constamment exploitée.

Ne puis-je pas simplement utiliser de meilleurs plugins de sécurité au lieu de migrer ?

Les plugins de sécurité sont eux-mêmes du code PHP exécuté sur votre serveur avec un accès système profond. Wordfence et Sucuri sont bien maintenus, mais ce sont des rustines sur un problème architectural. Ils ajoutent également la charge du serveur, peuvent entrer en conflit avec d'autres plugins, et ont eu leurs propres vulnérabilités au fil des ans. Vous ajoutez de la complexité pour résoudre un problème de complexité.

Combien de temps prend généralement une migration de WordPress vers Next.js ?

Pour un site d'affaires standard (10-50 pages, blog, formulaires de contact), nous complètons généralement les migrations en 5-7 semaines. Les sites de commerce électronique avec WooCommerce sont plus complexes et peuvent prendre 8-14 semaines selon la taille du catalogue de produits et les fonctionnalités personnalisées. Si vous avez un site plus simple, contactez-nous et nous pouvons vous donner une chronologie plus spécifique.

Vais-je perdre mes classements SEO lors de la migration de WordPress ?

Non, si vous le faites correctement. Les étapes critiques sont : préserver toutes les structures URL ou configurer des redirections 301 appropriées, maintenir vos marques de données structurées, garder votre contenu intact et soumettre des sitemaps mises à jour à Google Search Console. La plupart de nos clients de migration voient des améliorations de classement dans les 2-3 mois car les scores Core Web Vitals s'améliorent considérablement quand vous passez à un site statique servi par CDN.

Qu'en est-il de l'édition de contenu ? WordPress est facile pour les utilisateurs non techniques.

C'est une préoccupation légitime. Vous avez des options : Supabase avec un tableau de bord administrateur personnalisé, ou un CMS headless comme Sanity, Contentful ou Payload CMS qui donne aux éditeurs de contenu une expérience d'édition visuelle similaire à WordPress. Nous gérons régulièrement les intégrations de CMS headless et pouvons recommander le bon ajustement pour les besoins de votre équipe.

Supabase est-il assez sûr pour une utilisation en production ?

Supabase s'exécute sur l'infrastructure AWS avec conformité SOC 2 Type II. La base de données sous-jacente est PostgreSQL, qui a un fort antécédent de sécurité. Row Level Security applique le contrôle d'accès au niveau de la base de données, ce qui est en fait plus sûr que le système de permissions basé sur PHP de WordPress. Supabase offre également la récupération jusqu'au point dans le temps, les connexions chiffrées et les restrictions réseau sur les plans payants.

Que faire si mon site WordPress a été piraté et j'ai besoin d'aide immédiate ?

Premièrement, mettez le site hors ligne immédiatement pour arrêter les dommages supplémentaires et les fuites de données. Deuxièmement, préservez les preuves judiciaires (dumps de base de données, logs d'accès, snapshots de système de fichiers). Troisièmement, ne le nettoyez pas simplement et ne le remettez pas en ligne -- vous serez probablement réinfecté dans les semaines. Utilisez l'incident comme catalyseur pour migrer. Contactez notre équipe et nous pouvons aider avec le triage immédiat et la planification de la migration.

Dois-je tout migrer à la fois, ou puis-je le faire progressivement ?

La migration progressive est possible mais ajoute de la complexité. Vous pouvez exécuter Next.js comme frontend tout en gardant WordPress comme backend CMS headless temporairement, puis éliminer entièrement WordPress. Cependant, cela signifie que WordPress fonctionne toujours et a toujours besoin d'une maintenance de sécurité pendant la transition. Pour la plupart des sites, un basculement propre est plus rapide, moins cher et élimine le risque de sécurité plus tôt.