J'ai migré plus d'une douzaine de sites WordPress vers Next.js au cours des trois dernières années. Certains se sont déroulés sans accroc. D'autres m'ont fait remettre en question mes choix de carrière à 2h du matin un mardi. La différence entre ces deux résultats provenait presque toujours de la planification — spécifiquement, de la compréhension de ce que WordPress faisait réellement pour le site avant de le déchirer.

Ce guide contient tout ce que j'aurais aimé qu'on me remette avant ma première migration. Nous couvrirons le voyage complet : évaluer si vous devriez même migrer, choisir votre CMS headless, déplacer le contenu, reconstruire les templates, gérer le SEO sans perdre les classements, et déployer sur Vercel avec une configuration qui ne s'effondrera pas sous les pics de trafic.

Commençons.

Migration de WordPress vers Next.js sur Vercel : Guide 2026

Table des matières

Pourquoi migrer de WordPress vers Next.js en 2026 ?

Soyons honnêtes — WordPress alimente toujours environ 40% du web en 2026. Ce n'est pas près de disparaître. Mais les raisons de partir sont devenues plus convaincantes :

Plafond de performance. Même avec des plugins de mise en cache agressifs (WP Rocket, W3 Total Cache), la plupart des sites WordPress atteignent un mur autour de 70-80 sur les scores de performance Lighthouse. L'obésité logicielle, le PHP bloquant le rendu et les requêtes de base de données à chaque chargement de page créent une surcharge qu'aucune quantité d'optimisation ne peut entièrement éliminer.

Surface d'attaque en matière de sécurité. WordPress a connu 149 vulnérabilités documentées en 2025 dans le noyau et les extensions populaires. Chaque plugin est un vecteur d'attaque. Chaque mise à jour de thème est une rupture potentielle. Si vous exécutez WooCommerce, la surface d'attaque double.

Expérience développeur. Si votre équipe connaît React, construire en templates PHP est comme écrire de ta main non-dominante. Le routeur d'application Next.js 15, les composants serveur et la mise en cache intégrée vous offrent un flux de travail de développement moderne que WordPress ne peut pas égaler.

Coût à l'échelle. L'hébergement WordPress managé (WP Engine, Kinsta) coûte 30 à 300 dollars par mois pour des performances décentes. Le forfait Pro de Vercel à 20 $/utilisateur/mois avec des fonctions edge et une mise à l'échelle automatique coûte souvent moins cher tout en offrant de meilleures performances.

Cela dit — ne migrez pas seulement parce que c'est tendance. Si votre site est un simple blog avec 50 articles et que votre client le met à jour chaque semaine via l'administrateur WordPress, une migration pourrait créer plus de problèmes qu'elle n'en résout. Les meilleurs candidats pour la migration sont :

  • Les sites avec 500+ pages qui ont besoin de meilleures performances
  • Les équipes qui veulent un développement basé sur les composants
  • Les sites où les conflits de plugins causent des cauchemars de maintenance
  • Les sites e-commerce qui atteignent les limites de performance de WooCommerce
  • Les sites marketing qui ont besoin de tests A/B et de personnalisation à la périphérie

Audit pré-migration : Ce que WordPress fait réellement

C'est là que la plupart des migrations se trompent. Les gens pensent qu'ils migrent un blog, mais WordPress gère réellement des formulaires de contact, des redirections, l'optimisation d'images, la recherche, les commentaires, l'authentification, les travaux cron et quinze autres choses enfouies dans les configurations de plugins.

Avant d'écrire une seule ligne de code Next.js, documentez tout :

Inventaire des plugins

Exportez votre liste de plugins et catégorisez chacun :

wp plugin list --status=active --format=csv > active-plugins.csv

Pour chaque plugin, répondez : Que fait ce plugin, et qu'est-ce qui le remplace dans l'écosystème Next.js ?

Plugin WordPress Fonction Remplacement Next.js
Yoast SEO Balises meta, sitemaps, schéma next-seo + route sitemap.xml personnalisée
WP Rocket Mise en cache, minification Vercel Edge Cache + Next.js intégré
Contact Form 7 Gestion des formulaires React Hook Form + route API ou Formspree
Wordfence Sécurité Non nécessaire (pas de surface administrateur)
WPML Multilingue next-intl ou routage i18n intégré
WooCommerce E-commerce Shopify Storefront API ou Saleor
Advanced Custom Fields Modèles de contenu personnalisés Modélisation de contenu de votre CMS headless
Redirection Redirections d'URL Redirections next.config.js ou configuration Vercel
WP Cron Tâches planifiées Vercel Cron Jobs ou service séparé
Imagify Optimisation d'images next/image avec optimisation d'images Vercel

Inventaire de contenu

Comptez et catégorisez votre contenu :

SELECT post_type, post_status, COUNT(*) 
FROM wp_posts 
GROUP BY post_type, post_status;

N'oubliez pas : les types de publications personnalisés, les termes de taxonomie, les profils utilisateur, les structures de menu, les configurations de widgets et les valeurs d'option. Ce site WordPress "simple" a probablement plus de types de contenu que vous ne le pensez.

Mappage d'URL

Exportez chaque URL. Chaque. Seule. Utilisez Screaming Frog ou un simple crawl de sitemap :

curl -s https://yoursite.com/sitemap_index.xml | \
grep -oP '<loc>\K[^<]+' | \
xargs -I {} curl -s {} | \
grep -oP '<loc>\K[^<]+' > all-urls.txt

Ce fichier est précieux. Vous l'utiliserez pour le mappage de redirection, la préservation du SEO et les tests d'assurance qualité après la migration.

Migration de WordPress vers Next.js sur Vercel - architecture

Choisir votre backend CMS Headless

Vous avez besoin d'un endroit pour stocker et gérer le contenu. Les trois chemins les plus courants en 2026 :

Option 1 : WordPress en tant que CMS Headless

Oui, vous pouvez garder WordPress comme back-end et utiliser Next.js comme front-end. WPGraphQL (actuellement à la v2.1) rend cela étonnamment viable. Vos éditeurs conservent l'interface administrateur familière. Vous obtenez un front-end moderne.

// lib/wordpress.js
const API_URL = process.env.WORDPRESS_GRAPHQL_URL;

export async function getPostBySlug(slug) {
  const res = await fetch(API_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      query: `
        query PostBySlug($slug: ID!) {
          post(id: $slug, idType: SLUG) {
            title
            content
            date
            featuredImage {
              node {
                sourceUrl
                altText
              }
            }
            seo {
              title
              metaDesc
              opengraphImage {
                sourceUrl
              }
            }
          }
        }
      `,
      variables: { slug },
    }),
    next: { revalidate: 60 },
  });
  const json = await res.json();
  return json.data.post;
}

L'inconvénient ? Vous maintenez toujours une installation WordPress. Mises à jour de sécurité, gestion des versions PHP, sauvegardes de base de données — tout reste sous votre responsabilité. Et vous payez toujours pour l'hébergement WordPress.

Option 2 : CMS Headless spécialisé

C'est ce que je recommande pour la plupart des migrations. Déplacez votre contenu vers un CMS construit de zéro pour la distribution API-first.

CMS Prix (2026) Meilleur pour Modélisation de contenu Type d'API
Sanity Niveau gratuit, 15 $/utilisateur/mois Pro Contenu complexe, collaboration en temps réel Excellent, défini par le code GROQ + GraphQL
Contentful Niveau gratuit, 300 $/mois Équipe Entreprise, grandes équipes Bon, défini par UI REST + GraphQL
Storyblok Niveau gratuit, 106 €/mois Affaires Édition visuelle, composants Excellent, visuel REST + GraphQL
Strapi v5 Gratuit (auto-hébergé), Cloud à partir de 29 $/mois Contrôle total, open source Flexible, défini par UI REST + GraphQL
Payload CMS 3.0 Gratuit (auto-hébergé) Développeurs qui veulent du code-first Excellent, défini par le code REST + GraphQL

Si votre équipe chez Social Animal gère la migration, nous recommandons généralement Sanity ou Payload pour le développement de CMS headless — ils donnent aux développeurs le plus de contrôle sur la modélisation du contenu tout en gardant les éditeurs heureux.

Option 3 : Markdown/MDX dans le dépôt

Pour les blogs de développeurs et les sites de documentation, stocker le contenu sous forme de fichiers MDX dans votre référentiel Git est l'approche la plus simple. Aucun CMS à gérer, aucun appel API, contenu versionné aux côtés du code. Mais cela ne fonctionne que si vos éditeurs de contenu sont à l'aise avec les flux de travail Git.

Stratégie de migration de contenu

Exportation à partir de WordPress

L'export WordPress intégré (Outils → Exporter) vous donne un fichier XML. C'est un début, mais c'est désordre. Pour une migration structurée, j'utilise un script WP-CLI personnalisé :

// export-content.php
<?php
$posts = get_posts([
    'post_type' => ['post', 'page', 'your_custom_type'],
    'posts_per_page' => -1,
    'post_status' => 'publish',
]);

$export = [];
foreach ($posts as $post) {
    $export[] = [
        'id' => $post->ID,
        'title' => $post->post_title,
        'slug' => $post->post_name,
        'content' => apply_filters('the_content', $post->post_content),
        'excerpt' => $post->post_excerpt,
        'date' => $post->post_date,
        'modified' => $post->post_modified,
        'author' => get_the_author_meta('display_name', $post->post_author),
        'categories' => wp_get_post_categories($post->ID, ['fields' => 'names']),
        'tags' => wp_get_post_tags($post->ID, ['fields' => 'names']),
        'featured_image' => get_the_post_thumbnail_url($post->ID, 'full'),
        'acf' => function_exists('get_fields') ? get_fields($post->ID) : [],
        'yoast' => [
            'title' => get_post_meta($post->ID, '_yoast_wpseo_title', true),
            'description' => get_post_meta($post->ID, '_yoast_wpseo_metadesc', true),
        ],
    ];
}

file_put_contents('export.json', json_encode($export, JSON_PRETTY_PRINT));

Transformation du contenu

Le contenu WordPress est stocké en HTML avec balisage de bloc Gutenberg. Vous devrez décider : conserver le HTML et le rendre, ou convertir au format structuré de votre CMS ?

Pour Sanity, j'utilise @sanity/block-tools pour convertir le HTML en Portable Text. Pour Contentful, leur CLI de migration gère la conversion du texte enrichi. Dans les deux cas, prévoyez du temps pour le nettoyage du contenu — le contenu WordPress est rempli de [shortcodes], de styles en ligne et de HTML cassé qui doit être nettoyé.

// migrate-to-sanity.js
import { htmlToBlocks } from '@sanity/block-tools';
import { JSDOM } from 'jsdom';
import { Schema } from '@sanity/schema';

const schema = Schema.compile({ /* votre schéma */ });
const blockContentType = schema.get('post')
  .fields.find(f => f.name === 'body').type;

function convertPost(wpPost) {
  return {
    _type: 'post',
    title: wpPost.title,
    slug: { current: wpPost.slug },
    publishedAt: wpPost.date,
    body: htmlToBlocks(
      wpPost.content,
      blockContentType,
      { parseHtml: (html) => new JSDOM(html).window.document }
    ),
  };
}

Migration d'images

Ne sautez pas cela. Téléchargez chaque image depuis wp-content/uploads, retéléchargez sur votre CMS ou un CDN (Cloudinary, Vercel Blob Storage, S3) et mettez à jour toutes les références de contenu. J'écris généralement un script qui :

  1. Parcourt le JSON d'export pour les URL d'images
  2. Télécharge chaque image
  3. Télécharge sur le nouveau stockage
  4. Crée un fichier de mappage d'URL
  5. Exécute find-and-replace sur tout le contenu

Reconstruire votre frontend dans Next.js 15

Next.js 15 (stable depuis fin 2024, avec 15.2 actuel en 2026) utilise le routeur d'application par défaut. Voici la structure que j'utilise pour les sites riche en contenu :

app/
├── layout.tsx          # Layout racine avec polices, analytics
├── page.tsx            # Page d'accueil
├── blog/
│   ├── page.tsx        # Listing de blog avec pagination
│   └── [slug]/
│       └── page.tsx    # Publications de blog individuelles
├── [slug]/
│   └── page.tsx        # Pages génériques
├── sitemap.ts          # Génération dynamique de sitemap
├── robots.ts           # robots.txt
└── not-found.tsx       # 404 personnalisé

Génération statique avec ISR

Pour la plupart des pages de contenu, Incremental Static Regeneration est l'équilibre idéal — performance statique avec fraîcheur dynamique :

// app/blog/[slug]/page.tsx
import { getPostBySlug, getAllPostSlugs } from '@/lib/cms';
import { notFound } from 'next/navigation';

export async function generateStaticParams() {
  const slugs = await getAllPostSlugs();
  return slugs.map((slug) => ({ slug }));
}

export async function generateMetadata({ params }) {
  const post = await getPostBySlug(params.slug);
  if (!post) return {};
  return {
    title: post.seo?.title || post.title,
    description: post.seo?.description || post.excerpt,
    openGraph: {
      images: [post.featuredImage?.url],
    },
  };
}

export const revalidate = 3600; // Revalider chaque heure

export default async function BlogPost({ params }) {
  const post = await getPostBySlug(params.slug);
  if (!post) notFound();

  return (
    <article className="prose lg:prose-xl">
      <h1>{post.title}</h1>
      <time dateTime={post.date}>{formatDate(post.date)}</time>
      <PostBody content={post.body} />
    </article>
  );
}

Pour les sites nécessitant des mises à jour en temps réel (actualités, contenu en direct), utilisez la revalidation à la demande via les webhooks de votre CMS. La plupart des plates-formes CMS headless prennent en charge les déclencheurs webhook lors de la publication du contenu.

Si vous envisagez le développement Next.js et souhaitez comprendre plus profondément les compromis de rendu, nous avons écrit à ce sujet séparément.

Structure d'URL et préservation du SEO

C'est non négociable. Si vous perdez votre structure d'URL, vous perdez vos classements de recherche. Point.

Carte de redirection

WordPress utilise des modèles d'URL comme /2024/03/post-slug/ ou /category/term/. Votre site Next.js utilise probablement /blog/post-slug. Créez une carte de redirection :

// next.config.js
module.exports = {
  async redirects() {
    return [
      // URLs basées sur la date vers slugs propres
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // Archives de catégories
      {
        source: '/category/:slug',
        destination: '/blog?category=:slug',
        permanent: true,
      },
      // Pagination
      {
        source: '/page/:num',
        destination: '/blog?page=:num',
        permanent: true,
      },
      // URLs de flux
      {
        source: '/feed',
        destination: '/rss.xml',
        permanent: true,
      },
    ];
  },
};

Pour les sites volumineux (1000+ redirections), utilisez la configuration vercel.json ou le middleware de Vercel à la place — les redirections next.config.js ont une limite logicielle d'environ 1024 entrées avant que les temps de construction commencent à en souffrir.

Données structurées

Les plugins WordPress comme Yoast génèrent automatiquement JSON-LD. Vous devez réplique cela :

// components/structured-data.tsx
export function ArticleSchema({ post }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: post.title,
    datePublished: post.date,
    dateModified: post.modified,
    author: {
      '@type': 'Person',
      name: post.author,
    },
    image: post.featuredImage?.url,
    publisher: {
      '@type': 'Organization',
      name: 'Nom de votre site',
      logo: { '@type': 'ImageObject', url: '/logo.png' },
    },
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

Plan du site XML

Next.js 15 rend les sitemaps dynamiques simples :

// app/sitemap.ts
import { getAllPosts, getAllPages } from '@/lib/cms';

export default async function sitemap() {
  const posts = await getAllPosts();
  const pages = await getAllPages();

  return [
    { url: 'https://yoursite.com', lastModified: new Date() },
    ...pages.map((page) => ({
      url: `https://yoursite.com/${page.slug}`,
      lastModified: page.modified,
    })),
    ...posts.map((post) => ({
      url: `https://yoursite.com/blog/${post.slug}`,
      lastModified: post.modified,
    })),
  ];
}

Déploiement sur Vercel : Configuration qui fonctionne réellement

Configuration du projet

npx create-next-app@latest my-migrated-site --typescript --tailwind --app
cd my-migrated-site
vercel link

Variables d'environnement

Définissez celles-ci dans le tableau de bord de Vercel, pas dans les fichiers .env validés dans Git :

CMS_API_URL=https://your-cms-api-endpoint
CMS_API_TOKEN=your-read-only-token
REVALIDATION_SECRET=a-random-string-for-webhook-auth
SITE_URL=https://yoursite.com

Configuration Vercel

// vercel.json
{
  "crons": [
    {
      "path": "/api/revalidate-sitemap",
      "schedule": "0 */6 * * *"
    }
  ],
  "headers": [
    {
      "source": "/fonts/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
      ]
    }
  ]
}

Webhook de revalidation à la demande

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidation-secret');
  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ error: 'Invalid secret' }, { status: 401 });
  }

  const body = await request.json();
  const { slug, type } = body;

  if (type === 'post') {
    revalidatePath(`/blog/${slug}`);
    revalidatePath('/blog'); // Revalider le listing aussi
  } else {
    revalidatePath(`/${slug}`);
  }

  return NextResponse.json({ revalidated: true });
}

Pointez le webhook de votre CMS vers https://yoursite.com/api/revalidate avec l'en-tête secret. Maintenant, les mises à jour de contenu apparaissent en quelques secondes sans reconstructions complètes.

Benchmarks de performance : Avant et après

Ces sont des chiffres réels provenant de migrations que nous avons complétées chez Social Animal en 2025-2026 :

Métrique WordPress (WP Engine) Next.js (Vercel) Amélioration
Performance Lighthouse 62-78 95-100 +30-40%
Plus grand rendu de contenu 2,8-4,2s 0,8-1,4s 60-70% plus rapide
Temps jusqu'au premier octet 800ms-1,5s 50-120ms 90%+ plus rapide
Décalage cumulatif de la mise en page 0,12-0,25 0,01-0,05 ~80% de réduction
Coût d'hébergement mensuel 115 $/mois moy. 20-40 $/mois 60-80% d'économies
Temps de construction (500 pages) N/A (dynamique) 45-90 secondes N/A
Pages/seconde (ISR) 15-30 req/s 10 000+ depuis l'edge Ordres de grandeur

L'amélioration du TTFB seule vaut la migration. WordPress génère chaque page via PHP et MySQL. Vercel sert les pages pré-rendues à partir de nœuds edge dans plus de 300 emplacements dans le monde.

Pièges courants de migration

Piège 1 : Oublier les flux RSS WordPress. Si les gens s'abonnent à votre flux, redirigez /feed/ et /rss/ vers un nouveau point de terminaison RSS. Next.js ne génère pas de flux par défaut — vous avez besoin d'une route personnalisée.

Piège 2 : Manquer les shortcodes WordPress. Le contenu exporté de WordPress est rempli de [gallery], [embed] et de shortcodes spécifiques à des plugins. Si vous ne les analysez pas et les convertissez pas, ils s'affichent sous forme de texte brut. Écrivez des transformateurs pour chaque type de shortcode que votre contenu utilise.

Piège 3 : Ignorer les données de commentaires WordPress. Si vous avez des fils de commentaires précieux, migrez-les vers un service comme Disqus ou construisez un système de commentaires personnalisé. La plupart des gens abandonnent simplement les commentaires, mais vérifiez d'abord auprès des parties prenantes.

Piège 4 : Ne pas tester les liens internes. Le contenu WordPress est plein de liens internes utilisant des URL absolues (https://yoursite.com/old-path/). Ceux-ci doivent être mis à jour vers des chemins relatifs ou votre nouvelle structure d'URL. Un simple find-and-replace regex lors de la migration gère la plupart des cas.

Piège 5 : Oublier les références wp-content/uploads. Même après la migration des images, l'ancien contenu peut référencer les chemins /wp-content/uploads/2024/03/image.jpg. Configurez une redirection fourre-tout ou un proxy vers votre nouveau CDN d'images.

Si cela semble accablant, c'est honnêtement normal. Une migration appropriée prend 4 à 12 semaines selon la complexité du site. Consultez nos tarifs ou contactez-nous directement si vous souhaitez des mains expérimentées sur le projet.

FAQ

Combien de temps une migration de WordPress vers Next.js prend-elle ? Pour un site avec 100-500 pages, attendez 4-8 semaines avec un développeur dédié. Les sites plus grands avec des types de publications personnalisés, l'e-commerce ou le contenu multilingue peuvent prendre 8-16 semaines. La migration du contenu elle-même représente généralement 20% du travail — les 80% restants consistent à reconstruire les templates, gérer les cas limites et tester l'assurance qualité pour chaque URL.

Vais-je perdre mes classements Google lors de la migration ? Non, si vous gérez correctement les redirections. Implémentez les redirections 301 pour chaque URL qui change, préservez vos titres et descriptions meta, soumettez votre nouveau sitemap à Google Search Console et utilisez l'outil de modification d'adresse si votre domaine change. Attendez-vous à une petite fluctuation de classement pendant 2-4 semaines, puis une récupération ou une amélioration à mesure que Google reconnaît de meilleures Core Web Vitals.

Puis-je continuer à utiliser WordPress comme mon CMS avec Next.js ? Absolument. C'est ce qu'on appelle le "WordPress headless" et c'est une approche populaire. Utilisez WPGraphQL pour exposer votre contenu en tant qu'API, puis consommez-le depuis Next.js. Vos éditeurs conservent l'admin WordPress qu'ils connaissent. Le principal inconvénient est que vous maintenez toujours une installation WordPress — mises à jour de sécurité, hébergement, tout l'ensemble.

Combien coûte la migration de WordPress vers Next.js ? Fait soi-même avec un développeur : 100-300 heures de travail. Migration en agence : généralement 15 000 à 75 000 $ selon la complexité. Les frais d'hébergement continus diminuent généralement — Vercel Pro à 20 $/utilisateur/mois par rapport à l'hébergement WordPress managé à 50-300 $/mois. Le retour sur investissement provient de la réduction des coûts d'hébergement, de meilleures performances (ce qui améliore les taux de conversion) et une surcharge de maintenance réduite.

Dois-je utiliser le routeur pages ou le routeur d'application dans Next.js 15 ? Routeur d'application, c'est tout. En 2026, le routeur d'application est la valeur par défaut stable avec les composants serveur, le streaming et les itinéraires parallèles. Le routeur pages fonctionne toujours et n'est pas déprécié, mais les nouvelles fonctionnalités et optimisations sont d'abord du routeur d'application. Chaque migration que nous faisons chez Social Animal utilise exclusivement le routeur d'application. Consultez nos capacités de développement Next.js pour en savoir plus sur notre approche.

Qu'en est-il des formulaires et des fonctionnalités dynamiques ? Les routes API Next.js (ou les actions serveur dans le routeur d'application) gèrent les soumissions de formulaires, la recherche, l'authentification et toute logique côté serveur. Pour les formulaires de contact, vous pouvez utiliser les actions serveur avec un service comme Resend pour la livraison d'e-mails. Pour la recherche, envisagez Algolia ou Meilisearch. Pour l'authentification, NextAuth.js (maintenant Auth.js v5) couvre la plupart des cas d'usage.

Vercel est-il la seule option pour l'hébergement de Next.js ? Non. Vous pouvez déployer Next.js sur Netlify, AWS Amplify, Cloudflare Pages ou auto-héberger avec Node.js. Cependant, Vercel est construit par l'équipe Next.js, et l'intégration le montre — ISR, middleware edge, optimisation d'images et analytics fonctionnent tous mieux sur Vercel. L'écart de DX entre Vercel et les alternatives s'est réduit en 2026, mais Vercel reste le chemin de moindre résistance.

Que faire si j'ai besoin de migrer un magasin WooCommerce ? C'est un projet plus important. La plupart des équipes migrent la vitrine vers Next.js tout en déplaçant le back-end de commerce vers Shopify (en utilisant l'API Storefront), Medusa.js ou Saleor. Le framework Hydrogen de Shopify est une autre option, mais si vous souhaitez un contrôle total sur le front-end, Next.js avec l'API Shopify est le chemin le plus éprouvé. Attendez-vous à la migration e-commerce pour ajouter 4-8 semaines à votre calendrier.