Votre client appelle : son magasin WooCommerce a été piraté à nouveau. Vous l'avez nettoyé le mois dernier—supprimé la porte dérobée, corrigé vingt-trois plugins, renouvelé les identifiants. Mais ce matin, son processeur de paiement a signalé une activité de carte suspecte. Vous vous connectez en SSH et le trouvez : un skimmer de carte de crédit caché dans un plugin d'analyse qui ressemble à un plugin légitime et qui s'est mis à jour automatiquement mardi soir. La même histoire, un plugin différent. La surface d'attaque n'est pas un bug dans le cœur de WordPress—c'est les trente-sept plugins tiers sur lesquels son site dépend pour fonctionner. Chacun est une porte. La plupart sont corrigés lentement. Certains ne le sont jamais. La migration vers Next.js + Supabase ne nettoie pas seulement l'infection—elle supprime toute la couche de plugins où 90 % des violations de WordPress prennent origine.

Cet article n'est pas une critique de WordPress. Il a alimenté une part importante 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 2026. 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—voici votre guide pour passer à quelque chose fondamentalement plus sécurisé.

Table des matières

WordPress Piraté ? Pourquoi la Migration vers Next.js + Supabase est votre meilleur correctif

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

Soyons clairs sur quelque chose : l'équipe WordPress core fait un excellent travail de sécurité. Le cœur de WordPress, tenu à jour, est raisonnablement sécurisé. Mais personne ne gère juste le cœur de WordPress. Le site WordPress moyen a 20-30 plugins installés. Chacun 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 est constamment oublié dans les articles « 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 équivalent à donner une copie permanente de la clé de votre maison à chaque entrepreneur qui y travaille.

La base de données des vulnérabilités WPScan a enregistré 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 signalé que 33 % des vulnérabilités critiques de WordPress en 2024 n'avaient pas de 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 de WordPress en 2026

Avant de parler de la solution, cataloguons ce à quoi vous défendez réellement. J'ai personnellement trié des dizaines de sites WordPress compromis, et les attaques se répartissent en 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 d'utilisateur et touche à la base de données est un point d'injection SQL potentiel. La fonction $wpdb->prepare() existe, mais elle est optionnelle. Les développeurs de plugins l'oublient, l'utilisent incorrectement ou la sautent entièrement pour les requêtes « simples ».

J'ai une fois retracé 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 mots de passe administrateur et craquer les mots de passe faibles hors ligne.

-- Ce qu'une injection SQL WordPress typique ressemble 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'objet PHP et exécution de code à distance

L'utilisation intensive de WordPress de serialize() et unserialize() crée des opportunités pour l'injection d'objet PHP. Quand un plugin désérialise les données contrôlées par l'utilisateur (ce que beaucoup 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) permettait aux attaquants non authentifiés d'exécuter du code PHP arbitraire. Le correctif a pris 11 jours pour être livré. Onze jours où chaque site avec ce plugin était une proie facile.

Attaques de la chaîne d'approvisionnement des plugins

C'est celle qui m'effraie le plus. 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 logiciel malveillant à 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écouverts.

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 signalé bloquer une moyenne de 3 milliards de requêtes malveillantes par mois sur son réseau en 2024. Même avec la limitation du débit et l'authentification à deux facteurs, vous dépensez des ressources serveur pour traiter ces attaques.

Scripts intersites (XSS) stockés via les thèmes et plugins

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

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

C'est ici que ça devient intéressant. Une architecture headless n'élimine pas seulement votre surface d'attaque—elle supprime 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 d'administration
  • 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 sur des services isolés :

  • Frontend (Next.js sur Vercel/Netlify) : HTML/JS statiques servis depuis un CDN. Pas d'exécution serveur exposée à 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 points d'extrémité explicites et minimaux.
  • CMS (si nécessaire) : CMS headless s'exécutant 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 pour que les bots frappent.

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 meilleur correctif - architecture

Next.js + Supabase : une pile de sécurité en premier

Soyons précis sur la raison pour laquelle cette combinaison particulière fonctionne si bien d'un point de vue 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é est 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 injecter SQL dans un CDN.

Pour la fonctionnalité dynamique, 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
  • Est sans état (pas de mémoire partagée entre les requêtes)
  • Est courte (cold start, exécuter, terminer)
  • Est explicitement définie (pas de découverte automatique des points d'extrémité)
// Next.js Route Handler -- 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 créer ses propres requêtes SQL. La version Next.js a moins de parties mobiles, une entrée validé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é killer : 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 les 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 empêchent d'accéder à des données qu'il ne devrait 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é en code PHP, non 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 multifacteur. Pas de plugin requis. Pas de code tiers s'exécutant 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 Risque quasi nul--requêtes paramétrées via le client Supabase, RLS en secours
Exécution de code PHP/à distance Risque élevé--les plugins exécutent du PHP côté serveur Non applicable--pas d'exécution PHP
Attaque de la chaîne d'approvisionnement des plugins Risque critique--les mises à jour automatiques distribuent les logiciels malveillants Non applicable--pas d'écosystème de plugins
Force brute (connexion) Toujours exposé (wp-login.php, xmlrpc.php) Accès administrateur via Supabase Auth ou tableau de bord séparé, pas de point d'extrémité de connexion public requis
XSS (Stocké) Risque élevé--contexte d'admin/public partagé Risque faible--React échappe la sortie par défaut, l'admin et le public sont des applications séparées
Exploitation du téléchargement de fichier Risque élevé--les fichiers PHP téléchargés peuvent s'exécuter Risque faible--les téléchargements vont au stockage d'objets (Stockage Supabase/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 chemin connu wp-admin, wp-content, wp-includes tous analysables Pas de chemins prévisibles, pas de routes d'administration exposées

Le 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 chez Social Animal assez de fois pour avoir un processus reproductible.

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

Avant de toucher au 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 comptez pas sur les exports XML--ils manquent les champs meta et les types de publication personnalisés.
  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. Mappez les structures d'URL pour la préservation du référencement. 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 utilisateur, ecommerce--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 : Migration du schéma Supabase et des données (Semaine 2)

Concevez votre schéma de base de données Supabase en fonction de l'audit de contenu. Ne reproduisez 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 spécialisé
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 exports JSON de WordPress en votre nouveau schéma et les insère dans Supabase.

Phase 3 : Build 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 fait cette migration assez de fois pour avoir des avis forts sur les bons modèles.

Décisions architecturales clés :

  • Génération statique pour les pages de contenu--articles de blog, pages d'atterrissage, pages de présentation. Celles-ci deviennent des fichiers HTML sur un CDN.
  • Composants serveur pour les données dynamiques--récupérez depuis Supabase au moment de la requête avec mise en cache.
  • Route handlers pour les soumissions de formulaires--formulaires de contact, inscriptions à des infolettres, etc.
  • Middleware pour les redirections--gérez toutes vos anciennes URL WordPress.
// next.config.ts -- gérez les redirections 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 -- envoyez les bots à 410
      {
        source: '/wp-login.php',
        destination: '/gone',
        permanent: true,
      },
      {
        source: '/wp-admin/:path*',
        destination: '/gone',
        permanent: true,
      },
    ]
  },
}

Phase 4 : Test et validation du référencement (Semaine 6)

  • Exécutez Screaming Frog contre 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 contrôles Lighthouse et Core Web Vitals--vous verrez presque certainement des améliorations puisque vous servez maintenant depuis un CDN.
  • Configurez la surveillance avec Vercel Analytics ou votre outil préféré.

Phase 5 : Lancement et basculement DNS (Semaine 6-7)

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

Si votre site a du trafic important ou de la fonctionnalité ecommerce, envisagez une intégration CMS headless pour la gestion du contenu et parlez avec nous d'Astro comme alternative frontend pour les sites riches en contenu où la performance de build importe.

Renforcement de la sécurité après migration

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

  1. Activez RLS Supabase sur chaque table. Pas d'exceptions. Si une table n'a pas de politiques, elle est soit inaccessible (bon défaut) soit grand ouverte (mauvais).
  2. Utilisez les variables d'environnement pour tous les secrets. Vercel et Netlify traitent cela bien. Ne commitez jamais les clés API.
  3. Configurez les sauvegardes de la base de données Supabase. La récupération point-in-time 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 dans tous les plans).
  6. Configurez la surveillance du temps d'activité--nous utilisons Better Uptime, mais Checkly et la surveillance intégrée de Vercel fonctionnent aussi.
  7. Auditez vos politiques RLS Supabase trimestriellement. Utilisez l'éditeur SQL de 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ût WordPress (Annuel) Next.js + Supabase (Annuel)
Hébergement 300-1 200 $ (WordPress géré) 0-240 $ (Vercel Pro)
Plugins de sécurité (Wordfence/Sucuri) 200-500 $ 0 $ (pas nécessaire)
SSL/CDN 0-200 $ 0 $ (inclus)
Nettoyage de logiciel malveillant (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 $ (Free tier to 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. Un seul incident signalable au RGPD peut coûter des dizaines de milliers de dollars en frais juridiques et de conformité.

La migration elle-même coûte généralement entre 10 000 et 40 000 dollars selon la complexité du site. Pour la plupart des entreprises, cela s'amortit en 1 à 2 ans seulement grâce à la réduction des dépenses de sécurité--et vous obtenez un site plus rapide et plus maintenable. Consultez notre page de tarification pour des détails spécifiques sur les projets de migration.

FAQ

WordPress est-il vraiment aussi peu sûr, ou c'est exagéré ?

Le cœur de WordPress est maintenu correctement. Le problème est que pratiquement personne n'exécute juste le cœur. L'écosystème des plugins est où 96 % des vulnérabilités vivent, et vous ne pouvez pas gérer un site WordPress utile sans plugins. Ce n'est pas exagéré--Sucuri a nettoyé les logiciels malveillants de plus de 60 000 sites WordPress en 2024 seul. L'architecture vous oblige à faire confiance au 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é à la place de migrer ?

Les plugins de sécurité sont eux-mêmes du code PHP s'exécutant sur votre serveur avec un accès profond au système. Wordfence et Sucuri sont bien maintenus, mais ce sont des pansements sur un problème architectural. Ils ajoutent également une charge 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 commercial 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.

Perdrai-je mes classements SEO lors de la migration de WordPress ?

Non, si vous le faites correctement. Les étapes critiques sont : préserver toutes les structures d'URL ou configurer des redirections 301 appropriées, maintenir vos balises 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 une amélioration du classement dans 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 d'administration 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 les intégrations CMS headless régulièrement et pouvons recommander la bonne correspondance pour les besoins de votre équipe.

Supabase est-il assez sécurisé 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 solide antécédent de sécurité. Row Level Security émet des politiques qui appliquent le contrôle d'accès au niveau de la base de données, ce qui est en fait plus sécurisé que le système de permissions basé sur PHP de WordPress. Supabase offre également une récupération point-in-time, des connexions chiffrées et des restrictions réseau sur les plans payants.

Et 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, conservez les preuves médico-légales (dumps de base de données, journaux d'accès, snapshots du système de fichiers). Troisièmement, ne le nettoyez pas simplement et remettez-le--vous serez probablement réinfecté dans quelques semaines. Utilisez l'incident comme catalyseur pour migrer. Contactez notre équipe et nous pouvons aider tant au triage immédiat qu'à la planification de la migration.

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

La migration progressive est possible mais ajoute de la complexité. Vous pouvez exécuter Next.js en tant que frontend tout en gardant WordPress en tant que CMS headless backend temporairement, puis éliminer complètement WordPress. Cependant, cela signifie que WordPress s'exécute toujours et a toujours besoin de maintenance de sécurité pendant la transition. Pour la plupart des sites, une coupure nette est plus rapide, moins chère et élimine le risque de sécurité plus tôt.