Votre tableau de bord WordPress s'ouvre et l'icône de mise à jour brille en rouge — encore une fois. Vous cliquez. Trois plugins entrent en conflit. Le formulaire de contact arrête de fonctionner. Votre client vous envoie un email à 23 h parce que le site se sent lent, et vous savez déjà : six secondes avant l'interactivité, peut-être sept si quelqu'un est sur mobile. Un avis de sécurité arrive le lendemain matin — CVE-2022-quelque-chose — et l'auteur du plugin a disparu il y a deux ans. Vous corrigez ce que vous pouvez, reportez ce que vous ne pouvez pas, et vous promettez que c'est la dernière fois. Mais le prochain cycle de mise à jour est déjà dans deux semaines, et vous faites face au même compromis : la stabilité ou les fonctionnalités, jamais les deux. Une meilleure stack vous attend — une qui ne vous oblige pas à choisir.

Voici la chose — WordPress alimente plus de 40 % du web, et pour une bonne raison. C'est accessible, cela dispose d'un écosystème massif, et cela a mis beaucoup d'entreprises en ligne rapidement. Mais il y a une différence entre un outil qui vous permet de commencer et un outil qui évolue avec vous. Si vous lisez ceci, vous avez probablement atteint ce mur. Laissez-moi vous montrer à quoi ressemble réellement une migration de WordPress vers une architecture headless Next.js + Supabase — pas la version marketing, mais le véritable playbook d'ingénierie.

Table des matières

Avez-vous dépassé WordPress ? Un playbook de migration pour Next.js + Supabase

Signes que vous avez réellement dépassé WordPress

Tout le monde n'a pas besoin de quitter WordPress. Je veux être franc à ce sujet. Si vous gérez un blog personnel ou un site vitrine pour une petite entreprise locale, WordPress avec un thème décent et une poignée de plugins est probablement toujours le bon choix. Mais il y a des signaux clairs que vous avez dépassé cela :

Les conflits de plugins cassent les choses chaque mois

Vous mettez à jour WooCommerce, et votre page builder se casse. Vous mettez à jour votre page builder, et votre plugin SEO lance des avertissements. Vous mettez à jour PHP vers 8.2 parce que votre hôte l'exige, et trois plugins cessent complètement de fonctionner. Ce n'est pas un bug — c'est l'architecture. Les plugins WordPress partagent tous la même portée globale, les mêmes hooks, la même base de données. Chaque plugin est un conflit potentiel avec chaque autre plugin.

J'ai audité des sites WordPress exécutant 30, 40, voire 60+ plugins actifs. À ce stade, vous ne maintenez pas un site web. Vous maintenez une tour Jenga.

La performance est devenue un travail à temps plein

Votre score PageSpeed est dans les 30. Vous avez installé un plugin de cache, un plugin d'optimisation d'image, un plugin de minification et un plugin CDN — tout pour corriger les problèmes de performance créés par les 25 autres plugins. L'ironie est épaisse.

WordPress génère des pages de manière dynamique à chaque requête (sauf en cas de cache). Chaque plugin peut injecter ses propres fichiers CSS et JavaScript. Une page WordPress typique avec les plugins populaires charge 15-30 ressources distinctes bloquant le rendu. Les données de Google Core Web Vitals montrent que les sites WordPress ont un taux de réussite de 33 % sur les trois métriques CWV, par rapport à 52 % pour les sites construits avec des frameworks JavaScript modernes.

Les vulnérabilités de sécurité vous gardent éveillé la nuit

La base de données de vulnérabilités de WPScan a suivi des milliers de vulnérabilités WordPress — la grande majorité dans les plugins et les thèmes. Si vous gérez un site qui traite des données utilisateur, des paiements ou toute sorte d'informations sensibles, chaque plugin est une surface d'attaque. Patchstack a signalé que 97 % des vulnérabilités de sécurité WordPress proviennent de plugins.

Vous confiez essentiellement des dizaines de développeurs indépendants — dont beaucoup maintiennent des plugins comme des projets secondaires — avec votre posture de sécurité.

Votre équipe de développement la déteste

Celui-ci est sous-estimé. Les bons développeurs ne veulent plus travailler dans WordPress. Le workflow PHP-template-spaghetti-with-ACF-fields est douloureux par rapport au développement basé sur des composants modernes. Si vous essayez d'attirer et de retenir les talents en ingénierie, votre stack technologique compte.

La taxe WordPress : ce que l'enfer des plugins coûte vraiment

Permetez-moi de mettre des chiffres à cela. Pour un site WordPress de taille moyenne (disons un site e-commerce ou un site marketing SaaS avec un blog, des comptes utilisateur et des fonctionnalités personnalisées), voici à quoi ressemble la « taxe WordPress » annuelle typiquement :

Catégorie de coûts Estimation annuelle
Licences de plugins premium (15-20 plugins) 1 500 $ - 4 000 $
Hébergement WordPress géré (WP Engine, Kinsta) 1 200 $ - 6 000 $
Surveillance de la sécurité + nettoyage (Sucuri, Wordfence) 300 $ - 500 $
Temps d'optimisation des performances (heures de développeur) 3 000 $ - 8 000 $
Débogage des conflits de plugins (heures de développeur) 2 000 $ - 6 000 $
Correctifs d'urgence des mises à jour qui cassent les choses 1 000 $ - 4 000 $
Total annuel de la taxe WordPress 9 000 $ - 28 500 $

C'est avant de construire une seule nouvelle fonctionnalité. C'est le coût du simple fait de garder les lumières allumées.

Pourquoi Next.js + Supabase est la stack qui a du sens

Il existe une douzaine de façons d'aller headless. Vous pourriez utiliser Gatsby (bien qu'il soit essentiellement en mode de maintenance depuis que Netlify l'a acquis). Vous pourriez utiliser Remix, Astro ou SvelteKit. Pour le backend, vous pourriez utiliser Firebase, PlanetScale ou une API personnalisée.

Mais pour les équipes migrant depuis WordPress en 2026, Next.js + Supabase atteint un sweet spot difficile à battre. Voici pourquoi.

Next.js : le frontend qui fait tout

Next.js 15 (stable depuis octobre 2024) vous donne des composants serveur par défaut, ce qui signifie que vous obtenez les performances des sites statiques avec la flexibilité des sites dynamiques. Vous pouvez générer statiquement vos articles de blog au moment de la compilation, effectuer un rendu côté serveur de vos pages dynamiques et effectuer un rendu côté client de vos composants interactifs — tout dans la même application.

Pour les équipes provenant de WordPress, les avantages clés sont :

  • Optimisation d'image intégrée — remplace 2-3 plugins WordPress
  • Fractionnement de code automatique — chaque page charge uniquement le JS dont elle a besoin
  • Middleware Edge — gérer les redirections, l'authentification et les tests A/B au niveau du CDN
  • Régénération statique incrémentale (ISR) — reconstruire des pages individuelles sans déploiements complets
  • App Router avec composants serveur React — réduit considérablement le JavaScript côté client

Nous construisons beaucoup de projets Next.js chez Social Animal (consultez nos capacités de développement Next.js), et la différence de performance par rapport à WordPress est constamment dramatique.

Supabase : le backend dont WordPress rêvait

Supabase est une alternative open-source Firebase construite sur PostgreSQL. Il vous donne :

  • Une base de données Postgres complète avec une API REST et GraphQL générées automatiquement à partir de votre schéma
  • Authentification intégrée (e-mail, OAuth, magic links, SSO)
  • Politiques de sécurité au niveau des lignes pour un contrôle d'accès granulaire
  • Abonnements en temps réel via WebSockets
  • Edge Functions pour la logique backend sans serveur
  • Stockage pour les téléchargements de fichiers avec livraison CDN

Pour les migrations WordPress spécifiquement, Supabase est brillant car WordPress utilise MySQL, et votre modèle de données correspond étonnamment bien à PostgreSQL. Les types de publication personnalisés deviennent des tables. Les métadonnées de publication deviennent des colonnes JSONB. Les données utilisateur correspondent presque 1:1.

Le niveau gratuit de Supabase comprend 500 Mo de base de données, 1 Go de stockage et 50 000 utilisateurs actifs mensuels sur l'authentification. Leur plan Pro à 25 $/mois couvre la plupart des sites de production. Comparez cela aux 30 $ à 100 $/mois que vous payez uniquement pour l'hébergement WordPress géré.

Avez-vous dépassé WordPress ? Un playbook de migration pour Next.js + Supabase - architecture

Le playbook de migration : phase par phase

Voici l'approche que j'ai affinée au fil de dizaines de migrations WordPress. Ce n'est pas un projet de fin de semaine — budget 4-12 semaines selon la complexité du site — mais c'est prévisible et à faible risque si vous suivez les phases.

Phase 1 : Audit et architecture (semaine 1)

Avant d'écrire une seule ligne de code :

  1. Exportez une liste complète des plugins avec wp plugin list --status=active (WP-CLI)
  2. Mappez chaque plugin à son remplacement dans la nouvelle stack
  3. Exportez votre structure d'URL complète incluant tous les articles, pages, taxonomies et types de publication personnalisés
  4. Documentez tous les formulaires, intégrations et connexions tiers
  5. Identifiez les fonctionnalités personnalisées qui vivent dans le functions.php de votre thème

L'exercice de mappage des plugins est critique. Voici à quoi ressemblent les remplacements courants :

Plugin WordPress Remplacement Headless
Yoast SEO API de métadonnées intégrée Next.js + generateMetadata()
WP Super Cache / W3 Total Cache Non nécessaire (statique par défaut)
Wordfence / Sucuri RLS Supabase + protection DDoS intégrée de Vercel
Contact Form 7 / Gravity Forms React Hook Form + Supabase Edge Function
WooCommerce Saleor, Medusa.js ou Shopify Storefront API
ACF / Custom Fields Tables Supabase avec schémas typés
WP Migrate DB Script de migration Supabase ponctuel
Smush / ShortPixel Composant Next.js Image (intégré)
Elementor / WPBakery Composants React (vous ne les regretterez pas)

Phase 2 : Configurer la nouvelle stack (semaine 2)

# Créer votre projet Next.js
npx create-next-app@latest mon-site --typescript --tailwind --app --src-dir

# Installer Supabase
npm install @supabase/supabase-js @supabase/ssr

# Configurer les variables d'environnement
cp .env.example .env.local

Votre .env.local :

NEXT_PUBLIC_SUPABASE_URL=https://votre-projet.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=votre-clé-anon
SUPABASE_SERVICE_ROLE_KEY=votre-clé-rôle-service

Déployez sur Vercel immédiatement. Oui, avant d'avoir construit quelque chose de significatif. Avoir une URL d'aperçu en direct dès le premier jour change la façon dont vous travaillez — les parties prenantes peuvent voir la progression, et vous détectez les problèmes de déploiement tôt.

Migration de données : extraire votre contenu de WordPress

C'est ici que la plupart des guides de migration deviennent vagues. Soyez spécifique.

Étape 1 : Exporter les données WordPress

N'utilisez pas l'export XML intégré de WordPress. C'est incomplet et mal structuré. À la place, utilisez WP-CLI et les requêtes de base de données directes :

# Exporter des articles au format JSON
wp post list --post_type=post --format=json --fields=ID,post_title,post_content,post_excerpt,post_date,post_status,post_name > posts.json

# Exporter les pages
wp post list --post_type=page --format=json --fields=ID,post_title,post_content,post_excerpt,post_date,post_status,post_name > pages.json

# Exporter les types de publication personnalisés
wp post list --post_type=votre_cpt --format=json > cpt.json

# Exporter les métadonnées de publication (champs ACF, etc.)
wp eval 'global $wpdb; $results = $wpdb->get_results("SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key NOT LIKE \"_%\""); echo json_encode($results);' > postmeta.json

Étape 2 : Transformer et charger dans Supabase

Écrivez un script de migration. Je préfère TypeScript pour cela :

import { createClient } from '@supabase/supabase-js'
import posts from './exports/posts.json'

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

async function migratePosts() {
  for (const post of posts) {
    const { error } = await supabase.from('posts').insert({
      wp_id: post.ID,
      title: post.post_title,
      slug: post.post_name,
      content: convertWpContentToMdx(post.post_content),
      excerpt: post.post_excerpt,
      published_at: post.post_date,
      status: post.post_status === 'publish' ? 'published' : 'draft',
    })
    
    if (error) console.error(`Échec de la migration de l'article ${post.ID}:`, error)
  }
}

function convertWpContentToMdx(html: string): string {
  // Utilisez turndown ou rehype pour convertir le HTML WordPress en MDX
  // Gérer les codes courts, intégrations et blocs Gutenberg
  // C'est ici que vivent 80 % de la complexité de la migration
}

La fonction convertWpContentToMdx est l'endroit où vous passerez le plus de temps. Le contenu WordPress est un gâchis de HTML, de codes courts, de commentaires de bloc Gutenberg et d'URL oEmbed intégrées. Les bibliothèques comme turndown gèrent la conversion de base de HTML à Markdown, mais vous aurez besoin de règles personnalisées pour les codes courts et les blocs.

Étape 3 : Migrer les médias

import { createClient } from '@supabase/supabase-js'
import fetch from 'node-fetch'

async function migrateMedia(mediaItems: any[]) {
  for (const item of mediaItems) {
    const response = await fetch(item.source_url)
    const buffer = await response.buffer()
    
    const { error } = await supabase.storage
      .from('media')
      .upload(`uploads/${item.slug}.${item.mime_type.split('/')[1]}`, buffer, {
        contentType: item.mime_type,
      })
    
    if (error) console.error(`Échec du téléchargement de ${item.slug}:`, error)
  }
}

Construire le nouveau frontend avec Next.js

Avec vos données dans Supabase, la construction du frontend est la partie amusante. Voici une page d'article de blog typique utilisant l'App Router de Next.js :

// src/app/blog/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server'
import { notFound } from 'next/navigation'
import { MDXRemote } from 'next-mdx-remote/rsc'

export async function generateMetadata({ params }: { params: { slug: string } }) {
  const supabase = createClient()
  const { data: post } = await supabase
    .from('posts')
    .select('title, excerpt, og_image')
    .eq('slug', params.slug)
    .single()

  if (!post) return {}

  return {
    title: post.title,
    description: post.excerpt,
    openGraph: { images: [post.og_image] },
  }
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const supabase = createClient()
  const { data: post } = await supabase
    .from('posts')
    .select('*')
    .eq('slug', params.slug)
    .eq('status', 'published')
    .single()

  if (!post) notFound()

  return (
    <article className="prose lg:prose-xl mx-auto">
      <h1>{post.title}</h1>
      <time dateTime={post.published_at}>
        {new Date(post.published_at).toLocaleDateString()}
      </time>
      <MDXRemote source={post.content} />
    </article>
  )
}

Notez qu'il n'y a pas de plugin de cache, pas de plugin de performance, pas de plugin SEO. L'API de métadonnées gère le SEO. Les composants serveur gèrent les performances. Le CDN gère la mise en cache. C'est tout intégré.

Configurer Supabase en tant que backend

Votre schéma Supabase doit être conçu autour de vos besoins réels en données, pas la structure générique wp_posts / wp_postmeta de WordPress. Voici un schéma plus propre :

-- Table Posts
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')),
  author_id uuid references auth.users(id),
  published_at timestamptz,
  created_at timestamptz default now(),
  updated_at timestamptz default now(),
  metadata jsonb default '{}'
);

-- Catégories
create table categories (
  id uuid default gen_random_uuid() primary key,
  name text not null,
  slug text unique not null,
  description text
);

-- Row Level Security
alter table posts enable row level security;

create policy "Les articles publiés sont visibles par tous"
  on posts for select
  using (status = 'published');

create policy "Les auteurs peuvent gérer leurs propres articles"
  on posts for all
  using (auth.uid() = author_id);

La colonne metadata jsonb est votre échappatoire. Tous les champs personnalisés qui ne méritent pas leur propre colonne peuvent vivre là. Elle est indexée, interrogeable et infiniment flexible — comme les champs ACF mais sans le plugin.

Gestion de l'authentification et des données utilisateur

Si votre site WordPress a des comptes utilisateur, Supabase Auth gère la migration proprement. Vous ne pouvez pas migrer les hashs de mot de passe (WordPress utilise phpass, Supabase utilise bcrypt), mais vous pouvez :

  1. Importer les emails utilisateur et les profils dans Supabase
  2. Déclencher un flux « réinitialisez votre mot de passe » pour tous les utilisateurs à la première connexion
  3. Ou utiliser l'authentification par magic link pour que les mots de passe ne soient pas nécessaires du tout

Supabase supporte l'email/mot de passe, Google, GitHub, Apple et des dizaines d'autres fournisseurs OAuth prêts à l'emploi. Aucun plugin nécessaire.

Préservation du SEO : ne perdez pas ce que vous avez construit

C'est non-négociable. Une migration bâclée peut détruire des années d'équité SEO en une nuit. Voici la checklist :

  1. Mappez chaque ancienne URL à sa nouvelle URL. WordPress utilise /2024/01/post-title/ par défaut. Votre nouveau site pourrait utiliser /blog/post-title. Chaque ancienne URL doit avoir une redirection 301.

  2. Implémentez les redirections dans Next.js:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // URLs WordPress basées sur la date vers des slugs propres
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // Pages de catégorie
      {
        source: '/category/:slug',
        destination: '/blog/category/:slug',
        permanent: true,
      },
    ]
  },
}
  1. Préservez tous les titres méta, descriptions et données structurées. Exportez-les depuis Yoast avant la migration.
  2. Soumettez le nouveau sitemap à Google Search Console immédiatement après le lancement.
  3. Gardez l'ancien site en cours d'exécution sur un sous-domaine (old.yoursite.com) pendant 30 jours comme solution de secours.

Benchmarks de performance : avant et après

Voici les chiffres réels des migrations que nous avons effectuées chez Social Animal (ce sont les moyennes sur les projets de migration) :

Métrique WordPress (Avant) Next.js + Supabase (Après) Amélioration
Score Lighthouse Performance 38 94 +147 %
Largest Contentful Paint (LCP) 4.2s 0.9s -79 %
First Input Delay (FID) 180ms 12ms -93 %
Cumulative Layout Shift (CLS) 0,25 0,02 -92 %
Time to First Byte (TTFB) 1.8s 0.15s -92 %
Poids total de la page 3.2MB 420KB -87 %
Requêtes HTTP 47 8 -83 %

Ce ne sont pas des cas sélectionnés. C'est cohérent. Quand vous éliminez 30+ plugins, chacun injectant ses propres CSS et JS, et remplacez le rendu PHP dynamique par des composants React statiques/rendus côté serveur sur un CDN global, les résultats sont prévisibles.

Si vous êtes curieux de savoir à quoi ces types de résultats pourraient ressembler pour votre projet, notre page de tarification détaille ce que les projets de migration headless coûtent généralement.

Comparaison des coûts : WordPress vs stack headless

WordPress (Annuel) Next.js + Supabase (Annuel)
Hébergement 1 200 $ - 6 000 $ (WP Engine/Kinsta) 0 $ - 240 $ (Vercel Pro)
Base de données/Backend Inclus dans l'hébergement 0 $ - 300 $ (Supabase Pro)
Licences de plugins 1 500 $ - 4 000 $ 0 $
Outils de sécurité 300 $ - 500 $ 0 $ (intégré)
CDN 0 $ - 600 $ 0 $ (inclus avec Vercel)
Heures de développeur de maintenance 6 000 $ - 18 000 $ 1 000 $ - 4 000 $
Total 9 000 $ - 29 100 $ 1 000 $ - 4 540 $

La stack headless est 70-85 % moins chère à exploiter annuellement. La migration elle-même a un coût initial, évidemment — généralement 15 000 $ à 60 000 $ selon la complexité pour une construction professionnelle (consultez nos services de développement de CMS headless pour les détails). Mais elle s'amortit en 6-18 mois grâce à la réduction des coûts d'exploitation seule, sans compter l'impact sur les revenus d'une meilleure performance et SEO.

FAQ

Ai-je besoin d'apprendre React/Next.js pour gérer mon contenu après la migration ?

Non. La plupart des équipes associent Next.js à un CMS headless comme Sanity, Contentful ou même WordPress lui-même utilisé purement comme CMS headless (via son API REST). Les éditeurs de contenu ne touchent jamais au code. Ils obtiennent une interface d'édition propre, et le frontend extrait le contenu via une API. Si vous voulez garder l'éditeur WordPress que votre équipe connaît déjà, vous pouvez absolument le faire — supprimez simplement le frontend WordPress et utilisez-le comme backend de contenu.

Combien de temps prend une migration typique WordPress vers Next.js ?

Pour un site centré sur le contenu avec un blog et des pages standard : 4-6 semaines. Pour un site avec e-commerce, comptes utilisateur, types de publication personnalisés et fonctionnalités complexes : 8-14 semaines. La plus grande variable est la complexité du contenu — les sites avec beaucoup de codes courts ou des blocs Gutenberg profondément personnalisés prennent plus de temps pour migrer proprement.

Vais-je perdre mes classements Google lors de la migration ?

Non, si vous gérez correctement les redirections. Les redirections 301 préservent ~90-99 % de l'équité des liens. Nous voyons généralement une petite baisse dans les 1-2 premières semaines après la migration (Google doit recrawler), suivie par des classements améliorés grâce à de meilleurs scores Core Web Vitals. La clé est de mapper chaque URL et de ne pas lancer tant que votre carte de redirection n'est pas complète.

Supabase est-il prêt pour la production sur les sites à fort trafic ?

Oui. Supabase s'exécute sur l'infrastructure AWS et a été utilisé en production par des entreprises traitant des millions de requêtes. Leur base de données est juste PostgreSQL — probablement la base de données la plus éprouvée au combat qui existe. Supabase sert plus d'1 million de bases de données et traite des milliards de requêtes API quotidiennement. Pour une mise à l'échelle supplémentaire, leurs plans Pro (25 $/mois) et Team (599 $/mois) incluent des ressources dédiées et un support prioritaire.

Puis-je migrer WooCommerce vers cette stack ?

Vous pouvez, mais l'e-commerce ajoute une complexité importante. La plupart des équipes migrant depuis WooCommerce vont soit à Shopify (en utilisant l'API Storefront avec un frontend Next.js) soit à une solution open-source comme Medusa.js ou Saleor. Supabase peut gérer les catalogues de produits et la gestion des commandes, mais vous devriez construire le paiement, le traitement des paiements, la gestion des stocks et le calcul des taxes vous-même. Pour la plupart des entreprises, utiliser un backend e-commerce dédié et le connecter à Next.js a plus de sens.

Qu'en est-il de WordPress multisite — cette stack peut-elle la remplacer ?

Absolument. Next.js a un excellent support pour les architectures multi-locataires utilisant les middleware et le routage dynamique. La Row Level Security de Supabase rend simple le partitionnement des données par locataire. Nous avons migré des réseaux WordPress multisite avec plus de 50 sites vers une seule application Next.js avec routage spécifique au locataire, et la simplification opérationnelle était énorme.

Ai-je toujours besoin d'un CMS, ou puis-je simplement utiliser Supabase directement ?

Supabase vous donne un éditeur de tableau qui fonctionne pour les développeurs, mais les éditeurs de contenu veulent généralement quelque chose de plus poli. Les approches les plus courantes sont : (1) utiliser un CMS headless dédié comme Sanity ou Storyblok pour le contenu et Supabase pour les données d'application, (2) construire une simple interface d'administration en utilisant quelque chose comme Next.js + Supabase Auth, ou (3) garder WordPress comme backend CMS headless. L'option 1 est la plus populaire pour les sites riches en contenu. Si vous explorez les options, nous détaillons les compromis sur nos pages développement Astro et CMS headless.

Et si la migration s'avère mal — puis-je revenir à WordPress ?

Oui, et vous devriez planifier cela. Gardez votre site WordPress en cours d'exécution sur un sous-domaine tout au long du processus de migration. Utilisez les commutateurs au niveau du DNS (modifiez votre enregistrement A ou CNAME) pour pouvoir effectuer une restauration en minutes. Nous recommandons de garder l'ancienne instance WordPress en cours d'exécution pendant au moins 30 jours après le lancement. Déclassez-la seulement après avoir confirmé que toutes les redirections fonctionnent, que les classements de recherche sont stables et que toutes les fonctionnalités ont été vérifiées. Si vous voulez de l'aide pour planifier une migration avec les bonnes procédures de restauration, contactez notre équipe — nous avons fait cela assez de fois pour savoir où se trouvent les pièges.