Votre installation WordPress charge 487 kilobytes à chaque chargement de page — assets de thème, scripts de plugin, dépendances jQuery empilées sur trois couches. Vous regardez les scores de performance Lighthouse stagner dans les années 40 tandis que les sites Next.js de vos concurrents vous surclassent avec un contenu identique. La migration vers Next.js et Vercel semble clean en théorie : exporter le contenu, configurer un CMS headless, déployer. En pratique, j'ai suivi douze de ces migrations sur trois ans. Quatre se sont déployées en moins de deux semaines. Huit se sont bloquées pendant des mois parce que les équipes ont raté ce que WordPress gérait silencieusement — redirections, optimisation d'images, sitemaps XML, injection de métadonnées — avant de le supprimer. La différence entre une transition fluide et un rollback à 2 du matin repose presque toujours sur une chose : auditer ce que WordPress fait réellement pour votre site avant de tuer l'installation.

Ce guide couvre tout ce que j'aurais souhaité 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 vos classements, et déployer sur Vercel avec une configuration qui ne s'effondrera pas sous les pics de trafic.

C'est parti.

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

Table des matières

Pourquoi migrer de WordPress à Next.js en 2026 ?

Soyons honnête — WordPress alimente toujours environ 40 % du web en 2026. Il ne disparaît nulle part. Mais les raisons de partir sont devenues plus convaincantes :

Plafond de performance. Même avec des plugins de cache agressifs (WP Rocket, W3 Total Cache), la plupart des sites WordPress plafonnent autour de 70-80 sur les scores de performance Lighthouse. L'encombrement des plugins, 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 complètement éliminer.

Surface d'attaque de sécurité. WordPress a enregistré 149 vulnérabilités documentées en 2025 dans le noyau et les plugins 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, coder en templates PHP ressemble à écrire de la main non dominante. Le routeur d'application Next.js 15, les composants serveur et le cache intégré vous offrent un flux de travail de développement moderne que WordPress ne peut pas égaler.

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

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

  • Sites avec 500+ pages qui ont besoin de meilleures performances
  • Équipes qui veulent un développement basé sur les composants
  • Sites où les conflits de plugins causent des cauchemars de maintenance
  • Sites de e-commerce atteignant les limites de performance de WooCommerce
  • 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 échouent. Les gens pensent qu'ils migrent un blog, mais WordPress gère réellement les formulaires de contact, les redirections, l'optimisation d'images, la recherche, les commentaires, l'authentification, les tâches cron et quinze autres choses enfouies dans les configurations des 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 : Qu'est-ce que cela fait 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 Cache, minification Cache Edge Vercel + 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 admin)
WPML Multilingue next-intl ou routage i18n intégré
WooCommerce E-commerce API Storefront Shopify ou Saleor
Advanced Custom Fields Modèles de contenu personnalisés Modélisation de contenu de votre CMS
Redirection Redirections d'URL Redirections next.config.js ou config 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 : types de posts personnalisés, termes de taxonomie, profils utilisateur, structures de menu, configurations de widgets et valeurs d'options. Ce site WordPress « simple » a probablement plus de types de contenu que vous ne le pensez.

Mappage d'URL

Exportez chaque URL. Chacune. 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 de l'or. Vous l'utiliserez pour le mappage des redirections, la préservation du SEO et les tests d'assurance qualité après migration.

Migration de WordPress à Next.js sur Vercel : Guide 2026 - 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 comme CMS headless

Oui, vous pouvez garder WordPress comme backend et utiliser Next.js comme frontend. WPGraphQL (maintenant à la v2.1) rend cela étonnamment viable. Vos éditeurs conservent l'interface d'administration familière. Vous obtenez un frontend 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 cela reste sur votre assiette. Et vous payez toujours pour l'hébergement WordPress.

Option 2 : CMS headless spécifique au domaine

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

CMS Tarification (2026) Idéal pour Modélisation de contenu Type d'API
Sanity Couche gratuite, 15 $/utilisateur/mois Pro Contenu complexe, collaboration en temps réel Excellent, défini par le code GROQ + GraphQL
Contentful Couche gratuite, 300 $/mois Team Enterprise, grandes équipes Bon, défini par UI REST + GraphQL
Storyblok Couche gratuite, 106 €/mois Business É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 voulant 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 de 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 comme fichiers MDX dans votre repo 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 de WordPress

L'export WordPress intégré (Outils → Exporter) vous donne un fichier XML. C'est un début, mais c'est désordonné. 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 de contenu

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

Pour Sanity, j'utilise @sanity/block-tools pour convertir le HTML en Texte portable. Pour Contentful, leur CLI de migration gère la conversion de texte riche. De toute façon, prévoyez du temps pour le nettoyage du contenu — le contenu WordPress est plein de [shortcodes], de styles inline 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({ /* your schema */ });
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 de wp-content/uploads, re-téléchargez-la vers 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. Crawl le fichier JSON d'export pour les URLs d'images
  2. Télécharge chaque image
  3. L'envoie vers 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 en Next.js 15

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

app/
├── layout.tsx          # Layout racine avec polices, analytics
├── page.tsx            # Page d'accueil
├── blog/
│   ├── page.tsx        # Listing des articles de blog avec pagination
│   └── [slug]/
│       └── page.tsx    # Articles de blog individuels
├── [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, la régénération statique incrémentale est le sweet spot — performance statique avec actualité 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; // Revalidate every hour

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 ayant besoin de mises à jour en temps réel (actualités, contenu en direct), utilisez la revalidation à la demande via webhooks de votre CMS. La plupart des plateformes CMS headless prennent en charge les déclencheurs webhook lors de la publication de contenu.

Si vous explorez le développement Next.js et souhaitez comprendre plus profondément les compromis de rendu, nous en avons écrit davantage 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 [
      // Date-based URLs to clean slugs
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // Category archives
      {
        source: '/category/:slug',
        destination: '/blog?category=:slug',
        permanent: true,
      },
      // Pagination
      {
        source: '/page/:num',
        destination: '/blog?page=:num',
        permanent: true,
      },
      // Feed URLs
      {
        source: '/feed',
        destination: '/rss.xml',
        permanent: true,
      },
    ];
  },
};

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

Données structurées

Les plugins WordPress comme Yoast génèrent automatiquement JSON-LD. Vous devez reproduire 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: 'Your Site Name',
      logo: { '@type': 'ImageObject', url: '/logo.png' },
    },
  };

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

Sitemap 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-les dans le tableau de bord Vercel, pas dans les fichiers .env engagé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'); // Revalidate listing too
  } else {
    revalidatePath(`/${slug}`);
  }

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

Pointez votre webhook 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 chiffres réels proviennent de migrations que nous avons complétées chez Social Animal en 2025-2026 :

Métrique WordPress (WP Engine) Next.js (Vercel) Amélioration
Lighthouse Performance 62-78 95-100 +30-40%
Largest Contentful Paint 2.8-4.2s 0.8-1.4s 60-70% plus rapide
Time to First Byte 800ms-1.5s 50-120ms 90%+ plus rapide
Cumulative Layout Shift 0.12-0.25 0.01-0.05 ~80% 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 la périphérie Ordres de magnitude

Seule l'amélioration du TTFB justifie la migration. WordPress génère chaque page via PHP et MySQL. Vercel sert les pages pré-rendues à partir de nœuds périphériques dans 300+ endroits à travers 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 shortcodes [gallery], [embed] et spécifiques aux plugins. Si vous ne les analysez pas et ne les convertissez pas, ils s'affichent comme du 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 discussions de commentaires précieuses, migrez-les vers un service comme Disqus ou créez 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 remplacement regex find-and-replace 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 d'images, l'ancien contenu peut référencer des chemins /wp-content/uploads/2024/03/image.jpg. Configurez une redirection catch-all ou un proxy vers votre nouveau CDN d'images.

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

FAQ

Combien de temps prend une migration de WordPress à Next.js ?

Pour un site avec 100-500 pages, prévoyez 4-8 semaines avec un développeur dédié. Les sites plus grands avec des types de posts personnalisés, du e-commerce ou du contenu multilingue peuvent prendre 8-16 semaines. La migration de contenu elle-même représente généralement 20% du travail — les 80% restants sont la reconstruction des templates, la gestion des cas limites et les tests d'assurance qualité de chaque URL.

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

Non, si vous gérez les redirections correctement. Implémentez des 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 Changement d'adresse si votre domaine change. Attendez-vous à une légère fluctuation de classement pendant 2-4 semaines, puis récupération ou amélioration à mesure que Google reconnaît de meilleurs Core Web Vitals.

Puis-je continuer à utiliser WordPress comme mon CMS avec Next.js ?

Absolument. C'est ce qu'on appelle « 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, toute la pile.

Combien coûte la migration de WordPress à Next.js ?

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

Dois-je utiliser le routeur Pages ou App Router dans Next.js 15 ?

App Router, sans équivoque. En 2026, l'App Router est la valeur par défaut stable avec Server Components, le streaming et les routes parallèles. Le routeur Pages fonctionne toujours et n'est pas obsolète, mais les nouvelles fonctionnalités et optimisations sont d'abord orientées App Router. Chaque migration que nous faisons chez Social Animal utilise exclusivement l'App Router.

Qu'en est-il des formulaires et des fonctionnalités dynamiques ?

Les routes API Next.js (ou Server Actions dans l'App Router) gèrent les soumissions de formulaires, la recherche, l'authentification et toute logique côté serveur. Pour les formulaires de contact, vous pouvez utiliser Server Actions avec un service comme Resend pour la livraison d'emails. Pour la recherche, considérez Algolia ou Meilisearch. Pour l'authentification, Auth.js v5 (anciennement NextAuth.js) couvre la plupart des cas d'usage.

Vercel est-elle la seule option pour héberger 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 de périphérie, optimisation d'images et analytics fonctionnent mieux sur Vercel. L'écart DX entre Vercel et les alternatives s'est réduit en 2026, mais Vercel reste le chemin du moindre effort.

Que faire si je dois migrer une boutique WooCommerce ?

C'est un projet plus important. La plupart des équipes migrent la vitrine vers Next.js tout en déplaçant le backend de commerce vers Shopify (utilisant Storefront API), Medusa.js ou Saleor. Le framework Hydrogen de Shopify est une autre option, mais si vous souhaitez un contrôle total sur le frontend, Next.js avec l'API de Shopify est le chemin le plus éprouvé. Prévoyez que la migration de e-commerce ajoute 4-8 semaines à votre chronologie.