J'ai migré plus d'une douzaine de sites WordPress vers Next.js en production, et je vais vous dire quelque chose qui pourrait vous surprendre : la migration réelle du code n'est pas la partie difficile. C'est le basculement. Ce moment terrifiant où vous appuyez sur le bouton et priez pour que rien ne se casse. La bonne nouvelle ? Avec le bon playbook, vous pouvez rendre ce moment ennuyeux. Et en exploitation, ennuyeux, c'est exactement ce que vous voulez.

C'est le playbook que nous utilisons chez Social Animal pour les basculements en production. Ce n'est pas théorique — c'est construit à partir de migrations réelles où les revenus réels étaient en jeu. On parle de sites e-commerce générant 50 000 $/jour, d'éditeurs de contenu avec des millions de pages vues mensuelles, et de sites marketing SaaS où 5 minutes d'indisponibilité signifient que le PDG appelle votre téléphone portable.

Table des matières

Migration CMS sans interruption : Playbook de basculement WordPress vers Next.js

Pourquoi zéro interruption est plus important que vous ne le pensez

Mettons des chiffres sur cela. La recherche de Google de 2024 montre qu'un délai d'une seconde dans le temps de chargement des pages coûte environ 7 % en conversions. Imaginez maintenant que votre site soit simplement... disparu. Même pendant 5 minutes.

Voici ce qui est réellement en jeu :

Durée de l'interruption Impact sur les revenus (pour un site de 10 000 $/jour) Impact SEO Impact sur la confiance utilisateur
5 minutes ~35 $ perdus Minimal s'il est isolé Faible
30 minutes ~208 $ perdus Googlebot peut le remarquer Modéré
2 heures ~833 $ perdus Erreurs d'exploration dans GSC Élevé
24 heures 10 000 $ + perdus Risque de désindexation Grave

Mais ce n'est pas seulement les revenus. Les moteurs de recherche crawlent constamment. Si Googlebot visite votre site pendant une migration et obtient des erreurs 500, ces URL peuvent être supprimées de l'index en quelques heures. J'ai vu des sites perdre 40 % de leur trafic organique parce que quelqu'un a fait une « migration rapide » à l'heure du déjeuner.

L'objectif n'est pas seulement zéro interruption. C'est zéro changement visible pour les utilisateurs et les crawlers pendant la transition.

Vue d'ensemble de l'architecture de migration

Avant d'entrer dans les phases, regardons l'architecture que nous ciblons. Le motif fondamental consiste à exécuter les deux systèmes en parallèle, puis à basculer le trafic de manière atomique.

                    ┌─────────────────┐
                    │   Cloudflare /   │
                    │   Load Balancer  │
                    └────────┬────────┘
                             │
                    ┌────────┴────────┐
                    │  Traffic Router  │
                    │  (weight-based)  │
                    └────┬───────┬────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  WordPress  │ │   Next.js   │
              │  (Blue)     │ │   (Green)   │
              │  Origin     │ │   on Vercel │
              └──────────┬──┘ └──┬──────────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  MySQL DB   │ │ Headless CMS │
              │             │ │ (Sanity/etc) │
              └─────────────┘ └─────────────┘

L'idée clé : vous ne migrez pas seulement un frontend. Vous migrez la couche contenu, la couche rendu et la couche livraison — et chacune peut être migrée indépendamment.

Phase 1 : Migration du contenu et couche API

C'est là que la plupart des équipes commencent mal. Elles essaient de créer le frontend Next.js en premier, puis règlent le contenu plus tard. Ne faites pas cela. Commencez par le contenu.

Choisir votre CMS sans en-tête

Votre contenu WordPress a besoin d'une nouvelle maison. Le choix a beaucoup d'importance pour la complexité de la migration :

CMS Facilité de migration depuis WP Synchronisation en temps réel possible Tarification (2025) Meilleur pour
Sanity Élevée (le contenu structuré cartographie bien) Oui, via webhooks Niveau gratuit, puis 99 $/mois Modèles de contenu complexes
Contentful Moyen (mappage de champs requis) Oui 300 $/mois pour Équipe Équipes d'entreprise
Strapi Élevée (modèle similaire basé sur BD) Oui Auto-hébergé gratuit, Cloud à partir de 29 $/mois Contrôle total
REST API WordPress N/A (garder comme sans en-tête) Déjà synchronisé Coûts d'hébergement existants Victoires rapides
Payload CMS Élevée Oui Auto-hébergé gratuit Équipes orientées développeur

Nous couvrons la sélection du CMS sans en-tête en détail sur notre page de capacités de développement de CMS sans en-tête, mais en résumé : pour la plupart des migrations WordPress, Sanity ou Payload CMS vous offre le meilleur chemin de migration.

Configuration de la synchronisation du contenu

Voici la partie critique : lors de la phase d'exécution parallèle, le contenu doit exister dans les deux systèmes. Vous avez deux stratégies :

Stratégie A : Migration unique + gel Migrez tout le contenu vers le nouveau CMS, puis figez l'édition WordPress. Cela fonctionne pour les petits sites mais s'écroule quand les éditeurs ont besoin de continuer à publier.

Stratégie B : Synchronisation continue (recommandée) Configurez un pipeline de synchronisation qui réplique les modifications WordPress vers votre nouveau CMS en quasi temps réel.

// Exemple : gestionnaire de webhook WordPress qui se synchronise avec Sanity
// Cela s'exécute en tant que fonction serverless (Vercel/AWS Lambda)

import { createClient } from '@sanity/client';

const sanity = createClient({
  projectId: process.env.SANITY_PROJECT_ID,
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2025-01-01',
  useCdn: false,
});

export async function POST(request) {
  const payload = await request.json();
  const { post_id, post_title, post_content, post_status } = payload;

  if (post_status !== 'publish') return new Response('Skipped', { status: 200 });

  try {
    await sanity.createOrReplace({
      _id: `wp-${post_id}`,
      _type: 'post',
      title: post_title,
      body: convertGutenbergToPortableText(post_content),
      migratedFrom: 'wordpress',
      wpId: post_id,
      _updatedAt: new Date().toISOString(),
    });

    return new Response('Synced', { status: 200 });
  } catch (error) {
    console.error('Sync failed:', error);
    return new Response('Sync error', { status: 500 });
  }
}

Vous aurez également besoin du côté WordPress. Nous utilisons un simple plugin qui se déclenche sur save_post :

// wp-content/plugins/headless-sync/headless-sync.php
add_action('save_post', function($post_id, $post) {
    if (wp_is_post_revision($post_id)) return;
    
    wp_remote_post(SYNC_ENDPOINT_URL, [
        'body' => json_encode([
            'post_id' => $post_id,
            'post_title' => $post->post_title,
            'post_content' => $post->post_content,
            'post_status' => $post->post_status,
        ]),
        'headers' => [
            'Content-Type' => 'application/json',
            'X-Sync-Secret' => SYNC_SECRET,
        ],
    ]);
}, 10, 2);

Exécutez cette synchronisation pendant au moins 2 semaines avant le basculement. Vous voulez attraper les cas limites — les shortcodes bizarres, les types de publication personnalisés, les champs ACF qui ne se cartographient pas proprement.

Migration CMS sans interruption : Playbook de basculement WordPress vers Next.js - architecture

Phase 2 : Création de l'application Next.js

Je ne vais pas couvrir l'intégralité du processus de construction Next.js ici — cela mérite son propre article (et nous avons une expertise approfondie en développement Next.js). Mais il y a des préoccupations spécifiques à la migration qui sont importantes pour zéro interruption.

La parité des URL est non-négociable

Chaque URL qui existe sur votre site WordPress doit se résoudre en le même contenu sur votre site Next.js. Chaque. Seule. Une.

Cela signifie :

  • /blog/my-post-slug/ doit fonctionner (y compris la barre oblique finale si WordPress l'a utilisée)
  • /category/technology/ doit fonctionner ou rediriger
  • /wp-content/uploads/2024/03/image.jpg doit rediriger vers votre nouveau CDN d'assets
  • /feed/ doit toujours retourner un RSS/Atom valide
  • Les URL de pagination comme /blog/page/2/ doivent fonctionner

Créez un script d'audit d'URL au début :

# Exporter toutes les URL WordPress en utilisant WP-CLI
wp post list --post_type=post,page --post_status=publish \
  --fields=ID,post_name,post_type,guid --format=csv > urls.csv

# Récupérez également les redirections de tout plugin SEO
wp db query "SELECT * FROM wp_redirection_items" --format=csv > redirects.csv

Puis validez-les contre votre construction Next.js :

// validate-urls.mjs
import { readFileSync } from 'fs';
import { parse } from 'csv-parse/sync';

const urls = parse(readFileSync('./urls.csv'), { columns: true });
const NEXT_BASE = 'https://staging.yoursite.com';

for (const row of urls) {
  const res = await fetch(`${NEXT_BASE}/${row.post_name}/`, {
    redirect: 'manual'
  });
  
  if (res.status >= 400) {
    console.error(`BROKEN: /${row.post_name}/ → ${res.status}`);
  }
}

Ligne de base des performances

Avant le basculement, votre site Next.js doit être au moins aussi rapide que WordPress. Cela semble évident, mais j'ai vu des équipes tellement excitées par la nouvelle pile qu'elles oublient de faire un benchmark.

Capturez les Core Web Vitals de votre site WordPress en utilisant les données CrUX ou Lighthouse CI, puis égalez ou dépassez-les. Si votre site WordPress a un LCP de 2,1 s et votre site Next.js est à 3,4 s, vous n'êtes pas prêt.

Phase 3 : Configuration du déploiement parallèle

Maintenant, nous arrivons à l'infrastructure qui rend zéro interruption possible.

L'exécution parallèle

Les deux systèmes s'exécutent simultanément, servant le trafic réel. Mais un seul est « principal » à tout moment donné.

Pour Next.js sur Vercel (notre configuration la plus courante), vous déploierez votre application Next.js sur un domaine personnalisé comme next.yoursite.com ou utilisez l'URL d'aperçu de Vercel. Votre site WordPress continue de s'exécuter sur yoursite.com.

# Si vous utilisez Nginx comme proxy inverse
# Ceci est la configuration de l'exécution parallèle

upstream wordpress {
    server wordpress-origin.internal:80;
}

upstream nextjs {
    server next-yoursite.vercel.app:443;
}

server {
    listen 443 ssl;
    server_name yoursite.com;

    # Pendant l'exécution parallèle : mettre en miroir le trafic vers les deux,
    # mais servir les réponses depuis WordPress
    location / {
        mirror /mirror;
        proxy_pass http://wordpress;
    }

    location = /mirror {
        internal;
        proxy_pass https://nextjs$request_uri;
    }
}

Cette configuration de miroir envoie chaque requête aux deux backends mais ne retourne que la réponse WordPress. Vous obtenez un vrai trafic frappant votre application Next.js sans que les utilisateurs le voient. Vérifiez vos journaux Next.js pour les erreurs, les 404 et les réponses lentes.

Surveillance synthétique

Configurez une surveillance qui valide continuellement que les deux systèmes retournent du contenu équivalent :

// canary-check.mjs — s'exécute toutes les 5 minutes via cron
const CRITICAL_URLS = [
  '/',
  '/blog/',
  '/about/',
  '/contact/',
  '/blog/most-popular-post/',
];

for (const path of CRITICAL_URLS) {
  const [wpRes, nextRes] = await Promise.all([
    fetch(`https://yoursite.com${path}`),
    fetch(`https://next.yoursite.com${path}`),
  ]);

  if (wpRes.status !== nextRes.status) {
    alert(`Status mismatch on ${path}: WP=${wpRes.status} Next=${nextRes.status}`);
  }

  // Comparez les balises de titre comme vérification de parité du contenu
  const wpTitle = (await wpRes.text()).match(/<title>(.*?)<\/title>/)?.[1];
  const nextTitle = (await nextRes.text()).match(/<title>(.*?)<\/title>/)?.[1];

  if (wpTitle !== nextTitle) {
    alert(`Title mismatch on ${path}`);
  }
}

Exécutez ceci pendant une semaine minimum sans aucune alerte avant de procéder au basculement.

Phase 4 : Configuration du déploiement bleu-vert

Le déploiement bleu-vert signifie avoir deux environnements de production identiques — bleu (WordPress actuel) et vert (nouveau Next.js) — et basculer entre eux de manière atomique.

Utilisation de Cloudflare Workers pour le routage du trafic

C'est notre approche préférée car elle vous donne un basculement du trafic instantané et global sans délai de propagation DNS.

// Cloudflare Worker pour le routage bleu-vert
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Lire l'environnement actif depuis le magasin KV
    const activeEnv = await env.CONFIG.get('active_environment') || 'blue';
    
    // Optionnel : routage canary basé sur un pourcentage
    const canaryPercent = parseInt(await env.CONFIG.get('canary_percent') || '0');
    const useGreen = activeEnv === 'green' || 
                     (canaryPercent > 0 && Math.random() * 100 < canaryPercent);
    
    const origin = useGreen
      ? 'https://next-yoursite.vercel.app'
      : 'https://wp-origin.yoursite.com';
    
    const originUrl = new URL(url.pathname + url.search, origin);
    
    const response = await fetch(originUrl, {
      method: request.method,
      headers: {
        ...Object.fromEntries(request.headers),
        'Host': new URL(origin).hostname,
        'X-Forwarded-Host': url.hostname,
      },
      body: request.method !== 'GET' ? request.body : undefined,
    });
    
    const newResponse = new Response(response.body, response);
    newResponse.headers.set('X-Served-By', useGreen ? 'green-nextjs' : 'blue-wordpress');
    
    return newResponse;
  }
};

La beauté de cette approche : basculer de WordPress à Next.js est une seule écriture du magasin KV. Aucun changement DNS. Pas de propagation. Instantané.

# Basculer vers vert (Next.js)
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "green"

# Restaurer vers bleu (WordPress) si quelque chose se passe mal
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "blue"

Routage Canary

Ne basculez pas 100 % du trafic à la fois. Commencez par un canary :

  1. 1 % du trafic vers Next.js — Regardez les erreurs pendant 1 heure
  2. 10 % du trafic — Surveillez pendant 2 heures
  3. 50 % du trafic — Surveillez pendant 4 heures
  4. 100 % du trafic — Surveillez pendant 24 heures
  5. Désactiver WordPress — Après 1 semaine à 100 %

Phase 5 : Stratégie de basculement DNS

Si vous ne pouvez pas utiliser Cloudflare Workers (ou une solution de routage d'edge similaire), vous devrez gérer le basculement au niveau DNS. C'est plus délicat en raison de la propagation TTL.

Préparation DNS avant le basculement

Au moins 48 heures avant le basculement :

  1. Abaissez votre TTL DNS à 60 secondes (par rapport aux 3600 ou 86400 typiques)
  2. Attendez l'expiration de l'ancien TTL
  3. Vérifiez que le TTL bas est actif : dig yoursite.com +short devrait afficher TTL ~60
# Vérifier le TTL actuel
dig yoursite.com A +noall +answer
# Devrait afficher quelque chose comme :
# yoursite.com.  60  IN  A  76.76.21.21

Le basculement DNS

Avec un TTL de 60 secondes, la mise à jour de votre enregistrement DNS A/CNAME signifie une propagation mondiale en environ 5 à 10 minutes (certains résolveurs ignorent les TTL bas, mais la plupart les respectent en 2025).

# Si vous passez à Vercel
# Mettre à jour CNAME pour pointer vers cname.vercel-dns.com
# Ou mettre à jour les enregistrements A vers les adresses IP de Vercel : 76.76.21.21

Le piège : Calendrier du certificat SSL

Voici quelque chose qui pique les gens. Quand vous basculez DNS vers Vercel (ou tout nouvel hôte), le certificat SSL pour votre domaine doit être provisionné sur le nouvel hôte avant le basculement. Sinon, vous obtenez une fenêtre où HTTPS ne fonctionne pas.

Sur Vercel, ajoutez votre domaine personnalisé dans les paramètres du projet avant le basculement DNS. Vercel tentera de provisionner le certificat via un défi HTTP-01 ou DNS-01. Si vous utilisez DNS proxié Cloudflare, vous devrez peut-être désactiver temporairement le proxy (cloud orange → cloud gris) pour que la provisioning du certificat fonctionne.

Phase 6 : Liste de contrôle du basculement

C'est la liste de contrôle que nous utilisons le jour du basculement. Imprimez-la. Cochez chaque case.

Avant le basculement (T-24 heures)

  • Tout contenu synchronisé et vérifié dans le nouveau CMS
  • Validation de parité d'URL réussissant à 100 %
  • Certificat SSL provisionné sur le nouvel hôte
  • TTL DNS confirmé à 60 secondes
  • Procédure de restauration documentée et testée
  • Toutes les redirections du plugin SEO WordPress migrées vers next.config.js ou middleware d'edge
  • robots.txt et sitemap.xml générant correctement sur Next.js
  • Suivi d'analytics vérifié sur Next.js (GA4, GTM, etc.)
  • Soumissions de formulaires testées de bout en bout
  • Flux RSS validé
  • Balises OpenGraph vérifiées sur les pages clés
  • Page 404 testée

Basculement (T-0)

  • Notifier les parties prenantes : « Migration en cours »
  • Définir canary sur 1 % → surveiller 30 min
  • Augmenter à 10 % → surveiller 1 heure
  • Vérifier les erreurs d'exploration dans Google Search Console
  • Augmenter à 50 % → surveiller 2 heures
  • Augmenter à 100 %
  • Soumettre le sitemap mis à jour à Google Search Console
  • Vérifier que Googlebot peut accéder à toutes les pages critiques (utiliser l'outil Inspection d'URL)
  • Tester tous les formulaires, flux e-commerce, flux d'authentification

Après le basculement (T+24 heures)

  • Surveiller les Core Web Vitals dans le tableau de bord CrUX
  • Vérifier les problèmes de couverture dans Google Search Console
  • Vérifier que toutes les données d'analytics circulent correctement
  • Origine WordPress toujours en cours d'exécution (conserver pendant 2 semaines minimum)
  • Exécuter un crawl complet du site avec Screaming Frog contre le nouveau site

Phase 7 : Surveillance post-basculement et restauration

Quoi surveiller

Configurez des tableaux de bord dans votre outil de surveillance (nous utilisons une combinaison de Vercel Analytics, Datadog et Google Search Console) en suivant :

  • Taux d'erreur : Des réponses 5xx ? Une augmentation des 4xx ?
  • Temps de réponse : Latence P50, P95, P99
  • Core Web Vitals : LCP, FID/INP, CLS
  • Search Console : Statistiques d'exploration, rapport de couverture, statut d'indexation
  • Métriques métier : Taux de conversion, taux de rebond, pages/session

Le plan de restauration

Votre restauration doit être une seule commande. Pas un processus en 15 étapes. Une seule commande.

Avec l'approche Cloudflare Worker :

# Restauration en une seule commande
wrangler kv:key put --namespace-id=$NS_ID "active_environment" "blue"

Avec le basculement basé sur DNS :

# Restauration DNS pré-scriptée via l'API Cloudflare
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record_id}" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"content": "old-wordpress-ip-address"}'

Gardez WordPress en cours d'exécution pendant au moins 2 semaines après le basculement. Ne soyez pas un héros. Le moment où vous arrêtez WordPress est le moment où vous découvrez une page que vous avez oubliée de migrer.

Modes de défaillance courants et comment les prévenir

Après avoir fait cela des douzaines de fois, voici les défaillances que je vois le plus souvent :

1. Plugins WordPress oubliés avec routes frontend Ce plugin de formulaire de contact crée des points de terminaison /wp-json/contact-form-7/. Cette installation WooCommerce a /my-account/ et /cart/. Mappez l'empreinte URL de chaque plugin.

2. URL wp-content codées en dur dans le contenu Les images de votre contenu référencent /wp-content/uploads/. Vous avez besoin de redirections ou d'une règle de réécriture pointant ces éléments vers votre nouveau CDN d'assets.

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/wp-content/uploads/:path*',
        destination: 'https://cdn.yoursite.com/uploads/:path*',
        permanent: true,
      },
    ];
  },
};

3. Oubli des sitemaps XML Google Search Console pointe vers /sitemap.xml. Votre application Next.js doit en générer un. Utilisez next-sitemap ou créez-le dans les gestionnaires de route de votre application.

4. Problèmes d'authentification et de session Si votre site WordPress a des utilisateurs connectés, leurs cookies ne fonctionneront pas sur la nouvelle pile. Planifiez la migration utilisateur séparément.

5. Empoisonnement du cache CDN pendant la transition Si Cloudflare met en cache les réponses, vous pourriez servir des pages WordPress obsolètes après le basculement vers Next.js. Purgez le cache CDN immédiatement après le basculement.

# Purger l'intégralité du cache Cloudflare après le basculement
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Si vous planifiez une migration et souhaitez que des experts gèrent le travail lourd, consultez notre page de tarification ou contactez-nous directement. Nous avons fait cela suffisamment de fois pour que nos playbooks soient estafiladés de la bonne façon.

Pour les sites construits avec d'autres frameworks, nous faisons également des migrations basées sur Astro qui peuvent être encore plus rapides pour les sites riche en contenu qui n'ont pas besoin de beaucoup d'interactivité.

FAQ

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

Pour un site de complexité moyenne (100-500 pages, types de publication personnalisés, certaines fonctionnalités dynamiques), prévoyez 8-12 semaines de bout en bout. Seules les phases de migration de contenu et d'exécution parallèle prennent 3-4 semaines. Le basculement réel, si vous avez fait le travail préparatoire, prend environ 4 heures de travail actif. Ne laissez personne vous dire que cela peut se faire en un week-end.

Puis-je utiliser WordPress comme CMS sans en-tête au lieu de migrer le contenu ?

Absolument, et pour certaines équipes c'est le bon appel. Vous gardez WordPress comme votre CMS, utilisez l'API REST ou WPGraphQL pour alimenter le contenu vers Next.js, et migrerez uniquement le frontend. Cela réduit considérablement la chronologie de migration car vous sautez la phase de migration de contenu entièrement. Le compromis est que vous maintenez toujours une installation WordPress avec tous ses frais généraux de mise à jour et de sécurité.

Qu'advient-il de mes classements SEO pendant une migration ?

Avec une migration appropriée sans interruption, vos classements doivent rester stables. John Mueller de Google a confirmé que la modification de votre CMS ne devrait pas affecter les classements si le contenu, les URL et les éléments SEO techniques restent équivalents. Les plus gros risques sont les URL cassées (qui causent des 404), les structures de liens internes modifiées et les performances dégradées. Notre playbook aborde spécifiquement ces trois éléments.

Comment gère-je les formulaires WordPress dans Next.js ?

Vous avez plusieurs options : utilisez un service de formulaire comme Formspree ou Basin, créez des routes API dans Next.js qui gèrent directement les soumissions, ou utilisez les fonctionnalités de formulaire de votre CMS sans en-tête (Sanity n'a pas de formulaires natifs, mais Payload CMS le fait). Pour les formulaires complexes avec logique conditionnelle, nous construisons généralement des routes API personnalisées et utilisons React Hook Form sur le frontend.

Dois-je utiliser Vercel, Netlify ou l'auto-hébergement pour le déploiement Next.js ?

Pour la plupart des équipes, Vercel est le chemin de moindre résistance pour Next.js. C'est construit par la même équipe, et des fonctionnalités comme ISR, middleware et optimisation d'image fonctionnent mieux là. Le plan Vercel Pro à 20 $/utilisateur/mois couvre la plupart des besoins de production. Si vous avez des exigences de conformité spécifiques ou devez rester sur AWS, vous pouvez auto-héberger avec le mode de sortie standalone. Netlify fonctionne aussi mais a historiquement accumulé du retard sur le support des fonctionnalités Next.js.

Quelle est la différence entre le déploiement bleu-vert et le déploiement canary ?

Le déploiement bleu-vert est binaire : tout le trafic va vers l'ancien système (bleu) ou le nouveau (vert). Le déploiement canary bascule progressivement un pourcentage du trafic d'ancien à nouveau. En pratique, nous combinons les deux. Nous configurons une infrastructure bleu-vert (deux environnements complets) mais utilisons le routage basé sur un pourcentage de style canary lors du basculement réel. Cela vous donne la sécurité d'un déploiement progressif avec la simplicité de gérer seulement deux environnements.

Comment migrer les redirections WordPress vers Next.js ?

Exportez vos redirections du plugin WordPress que vous utilisez (Redirection, Yoast, RankMath). Convertissez-les au format de redirection Next.js dans next.config.js. Pour les sites avec des centaines de redirections, utilisez plutôt le middleware — c'est plus performant et peut gérer la correspondance de modèles. Sachez que les redirections next.config.js ont une limite pratique d'environ 1 000 entrées sur Vercel avant que les temps de construction en souffrent.

Puis-je restaurer vers WordPress si quelque chose se passe mal après le basculement ?

Oui, et c'est non-négociable. Gardez votre instance WordPress en cours d'exécution pendant au moins 2 semaines après le basculement. Avec l'approche Cloudflare Worker décrite dans cet article, la restauration est un seul appel API qui prend effet globalement en quelques secondes. Avec le basculement basé sur DNS, la restauration prend 1 à 10 minutes selon la propagation TTL. Ne désactivez jamais l'ancien système jusqu'à ce que vous soyez sûr que le nouveau est stable.