Migration WordPress → Next.js — Performance ×5 et Sécurité Renforcée

#Pourquoi migrer de WordPress à Next.js en 2026

WordPress est le CMS le plus déployé au monde — 43 % du web, chiffre que ses défenseurs brandissent comme une marque de qualité. En réalité, c'est aussi une marque sur le dos de chaque site qui tourne dessous : 43 % du web sous la même stack PHP, les mêmes URL patterns (/wp-login.php, /wp-admin/, xmlrpc.php), les mêmes vecteurs d'attaque documentés et massifiés. La CISA publie régulièrement des alertes sur des CVE critiques dans l'écosystème WordPress/plugins — en 2025, la moyenne documentée était de 3 CVE critiques par mois sur les plugins les plus répandus (Contact Form 7, Yoast SEO, WooCommerce, Elementor). Plus de 90 % des compromissions WordPress viennent des plugins, pas du core.

Mais le problème de sécurité n'est pas le seul, ni même le premier que nos clients SaaS B2B ou cabinets de conseil expriment lors du premier RDV. Le premier problème, c'est la performance — et l'impact direct sur le SEO et la conversion. Un site WordPress typique avec Elementor ou Divi charge 2 à 5 Mo de resources sur la page d'accueil. Les page builders injectent des centaines de kilobytes de JavaScript et de CSS non utilisés. Même avec WP Rocket, LiteSpeed Cache et un CDN Cloudflare bien configuré, atteindre un Lighthouse Performance Score > 90 de façon cohérente sur mobile reste l'exception plutôt que la règle. En 2026, Google Core Web Vitals est un signal de classement établi : un LCP > 4s en mobile pénalise directement les positions organique. Pour un site qui génère des leads à partir de 592 € le contact qualifié, 10 positions perdues sur une requête à fort intent, c'est un manque à gagner calculable.

Deuxième problème : l'expérience développeur et la dette technique. WordPress est en PHP — un langage sans TypeScript natif, sans typage strict par défaut, avec un écosystème de plugins qui évolue indépendamment et introduit des régressions au moment des mises à jour. Les sites Elementor ou Divi accumulent une dette de templates imbriqués qu'il devient rapidement impossible de maintenir proprement. Chaque mise à jour WordPress majeure (6.5, 6.6, 6.7…) nécessite des tests manuels sur tous les plugins actifs. Sur un site avec 25 plugins, c'est une après-midi par mise à jour, sans garantie de non-régression.

Troisième problème : le vendor lock-in des page builders. Un site construit sur Elementor est prisonnier d'Elementor — ses structures de données propriétaires sont stockées dans la base MySQL en sérialisé, ses composants ne sont pas portables, sa dette JS est structurelle (Elementor injecte ~400 kb de JS minifié même sur les pages statiques). Migrer vers un autre thème ou page builder WP ne résout pas les problèmes de performance fondamentaux.

La réponse correcte à ces trois problèmes n'est pas "trouver le bon thème WordPress" ou "mieux configurer WP Rocket". C'est changer d'architecture.

#Next.js 15 + Payload CMS 3 — La stack headless Nehos

La stack que Nehos standardise sur ses projets de migration WordPress repose sur deux briques complémentaires. Next.js 15 comme framework front-end, Payload CMS 3 comme CMS headless.

#Next.js 15 App Router

Next.js 15 introduit l'App Router comme paradigme par défaut : les React Server Components (RSC) permettent de rendre les composants côté serveur et d'envoyer du HTML pur vers le navigateur, sans JavaScript côté client sur les composants statiques. Sur une page de service ou une page d'accueil institutionnelle, cela se traduit par un bundle JavaScript initial proche de zéro — là où un Elementor envoie 400+ kb de JS. Les Server Actions remplacent les API routes pour les formulaires et les mutations, avec une DX TypeScript propre. Le Partial Prerendering (PPR) permet de mixer contenu statique pré-généré et contenu dynamique dans la même page, sans sacrifier le TTFB. Pour le SEO, Next.js expose une API Metadata native (generateMetadata, generateStaticParams) qui gère title, description, Open Graph, canonical, hreflang, robots.txt et sitemap XML nativement, sans plugin.

#Payload CMS 3 — Le CMS headless TypeScript-native

Payload CMS 3 est notre choix par défaut pour remplacer le backend WordPress, et voici pourquoi il gagne face à Sanity ou Contentful sur les projets B2B France. (1) Auto-hébergé — Payload tourne sur votre infrastructure OVHcloud ou Vercel, vos données ne partent pas chez un tiers SaaS américain. Critère clé pour les cabinets de conseil et les ETI qui ont des clients sensibles. (2) TypeScript natif — Le schéma de données (collections, fields, blocks) est défini en TypeScript et génère les types automatiquement. Zéro drift entre le CMS et le front-end. (3) REST + GraphQL inclus — Payload expose une API REST complète et une API GraphQL sans configuration supplémentaire. (4) Rich text blocks — Le composant Lexical de Payload permet aux équipes marketing de composer des pages complexes (hero, feature blocks, témoignages, CTA, tableaux de comparaison) sans toucher au code. (5) RBAC natif — Gestion fine des rôles et permissions par collection et par field, sans plugin de sécurité additionnel.

#Déploiement et hébergement

Deux options selon le contexte client. Vercel Edge Network pour les projets dont la priorité est la performance globale maximale et la DX (déploiement continu Git, preview deployments par Pull Request, Vercel Analytics et Speed Insights natifs, ISR sub-second). OVHcloud + Traefik + Docker pour les clients avec exigences de souveraineté numérique, hébergement France, données sensibles ou contraintes sectorielles — voir service Hébergement Souverain Nehos. L'ISR (Incremental Static Regeneration) permet dans les deux cas de mettre à jour les pages de contenu dans les 30 secondes après une publication Payload CMS, sans redéploiement complet.

#Ce qui est migré — Et ce qui ne l'est pas

#Ce qui est toujours migré

Sur une migration WordPress → Next.js + Payload, Nehos migre systématiquement : toutes les pages statiques, tous les articles de blog (posts + metadata auteur + catégories + tags + images featured), les custom post types (CPT) définis via ACF ou Pods, les medias (images, vidéos, PDF — réoptimisation WebP/AVIF incluse), les taxonomies (catégories, tags, taxonomies custom), les données ACF (Advanced Custom Fields) exportées et remappées en Payload fields, les formulaires de contact (reconvertis en Payload form collections + webhook), les auteurs, les pages d'archive, les redirects existants (301 mapping exhaustif). La taxonomie des URLs existantes est conservée par défaut — ou restructurée si une amélioration SEO est identifiée lors de l'audit (avec 301 redirect covering correspondant).

#Ce qui nécessite une discussion préalable

WooCommerce pose un cas particulier. Une boutique WooCommerce active (catalogue produits, panier, checkout, gestion des commandes, extensions WooCommerce) ne se migre pas vers Next.js + Payload comme un site institutionnel — c'est un projet de migration e-commerce headless à part entière, avec Medusa.js ou Shopify Hydrogen comme backend commerce. Voir service Refonte E-commerce Headless. Les plugins de membership complexes (MemberPress, Restrict Content Pro) et les systèmes de booking avancés (Bookly, Amelia) sont à re-développer comme des Payload custom collections ou des intégrations tierce via API — à qualifier en amont lors de l'audit.

#Ce qui est amélioré pendant la migration

La migration est l'occasion de corriger des années de dette SEO technique : restructuration du sitemap XML (Payload + Next.js génèrent un sitemap dynamique propre), ajout ou correction des données structurées JSON-LD (Service, FAQPage, Article, BreadcrumbList, Speakable là où pertinent), normalisation des balises Open Graph et Twitter Card, implémentation du hreflang si site multilingue, correction des balises canoniques, optimisation des images (WebP/AVIF + lazy loading natif Next.js Image), mise en place du robots.txt et des meta robots corrects par template de page.

#Migration SEO — Zéro régression sur les positions Google

La continuité SEO est la contrainte N°1 d'un projet de migration de CMS — et la principale source d'anxiété légitime de nos interlocuteurs côté client. "Est-ce qu'on va perdre nos positions Google pendant la migration ?" La réponse courte : non, si le 301 redirect mapping est exhaustif et si le déploiement est fait correctement. La réponse longue : voici notre protocole.

Avant la migration. Crawl complet du site existant avec Screaming Frog (ou Sitebulb selon complexité) : export de toutes les URLs indexées, statut HTTP de chaque URL, title + description + H1 actuels, nombre de backlinks entrants (via Ahrefs ou SEMrush), Core Web Vitals de base (CrUX + Lighthouse), positions Google Search Console sur les 12 derniers mois pour les requêtes principales. Ce snapshot est la référence. Il sera comparé page par page et requête par requête 30, 60 et 90 jours après lancement.

Pendant le développement. 301 redirect mapping exhaustif dans un fichier de configuration Next.js (next.config.js redirects) ou via middleware Next.js selon volume (au-delà de 500 URLs, le middleware est plus performant). Règle absolue : chaque URL existante indexée a un 301 explicite vers son équivalent sur la nouvelle architecture. Pas de 404 silencieux, pas de redirection vers la page d'accueil en fallback générique. Les canonical tags sont définis via generateMetadata par template de page. Les données structurées JSON-LD sont injectées par route dans le head via script type application/json ou via React Server Components.

Au déploiement. Déploiement canary (10 % du trafic d'abord pendant 48h, monitoring GSC + Cloudflare Analytics en temps réel), puis bascule progressive. Soumission du nouveau sitemap XML à Google Search Console le jour J. Demande de revalidation des pages principales via GSC. Monitoring GSC quotidien pendant 60 jours post-lancement — volume de crawl, couverture, Core Web Vitals CrUX, clics et impressions par page.

Résultat typique. Lighthouse Performance 40-60 → 90-100. Core Web Vitals CrUX : 3/3 vert sur desktop et mobile. Trafic SEO organique : maintenu dans les 30 jours, amélioré dans les 60-90 jours grâce aux gains Core Web Vitals. Référence interne : cabinet de conseil B2B — leads organiques +67 % en 6 mois post-migration.

#Phase de migration — De l'audit au lancement en 8 à 16 semaines

#Phase 1 — Audit site existant (2-3 jours)

Crawl complet Screaming Frog : inventaire de toutes les URLs (pages, articles, CPT, archives, auteurs, taxonomies), statuts HTTP, performance Lighthouse par template, audit des plugins actifs (liste exhaustive + date de dernière mise à jour + CVE documentées), baseline GSC (positions, clics, impressions, Core Web Vitals CrUX). Export Ahrefs ou SEMrush : backlinks par URL, mots-clés positionnés par page. Ce document est le contrat de départ — il définit ce qui doit être migré et ce qui doit être amélioré.

#Phase 2 — Architecture Payload CMS + Next.js (1 semaine)

Conception des schémas Payload CMS (collections, globals, fields, blocks) en miroir des CPT et ACF WordPress existants. Inventaire des composants React nécessaires (hero, header, footer, article blog, page service, formulaire contact, tableaux, CTAs, témoignages, FAQPage). Définition des templates Next.js App Router (layout.tsx racine, page.tsx par route). Validation de l'arborescence des URLs et du plan de 301 redirects. Ce livrable est validé côté client avant tout développement.

#Phase 3 — Développement front-end et CMS (6 à 12 semaines)

Développement par composants React TypeScript avec Tailwind CSS + shadcn/ui. Intégration Payload CMS : définition des collections en TypeScript, configuration REST/GraphQL, upload des médias, blocs de contenu riches (Lexical). Développement des intégrations API identifiées lors de l'audit (HubSpot, Salesforce, Mailchimp, Brevo, Calendly, Intercom selon contexte client). Tests unitaires Jest + tests d'intégration Playwright sur les parcours critiques (formulaires, navigation, redirects). Revues de code systématiques.

#Phase 4 — Migration de contenu (parallèle au développement)

Export WordPress via l'API REST WP ou le plugin WP All Export selon complexité. Script de transformation Node.js TypeScript pour mapper les données WP vers les collections Payload (champs title, content, featured_image, categories, tags, custom fields ACF). Import Payload via API REST ou seed script. Optimisation des médias : recompression WebP/AVIF via Sharp, dimensions correctes pour Next.js Image (srcset automatique). Validation manuelle page par page sur les contenus prioritaires (pages de service, articles top trafic, landing pages).

#Phase 5 — Recette, 301s, déploiement canary, mise en ligne

Recette technique (liens cassés, redirects, formulaires, rendu mobile, performance Lighthouse par template). Validation du 301 redirect mapping exhaustif (outil de test automatisé sur toutes les URLs exportées Phase 1). Déploiement en environnement staging avec preview Next.js. Déploiement canary 10 % du trafic, monitoring 48h. Bascule DNS complète. Soumission GSC. Monitoring 60 jours.

#Sécurité post-migration — Ce qui disparaît avec WordPress

Une migration WordPress → Next.js + Payload CMS, c'est aussi une suppression radicale de surface d'attaque. Voici ce qui disparaît.

Vectors d'attaque éliminés. xmlrpc.php — vecteur historique d'attaques DDoS amplifiées et d'exploitation RPC, exploité en masse même sur des sites qui ne l'utilisent pas activement. /wp-login.php — cible de brute force permanente, credential stuffing, phishing pages. WP-Admin (/wp-admin/) — exposé par défaut, cible de multiples CVE chaque année sur le core et les plugins. Plugins vulnérables — les 10 plugins WP les plus répandus (Contact Form 7, Yoast, WooCommerce, Elementor, WPForms, W3 Total Cache…) cumulent des centaines de CVE documentées. L'absence de plugins tiers signifie une surface d'attaque réduite à zéro sur ce vecteur. wp-cron.php — abusé pour des tâches planifiées malveillantes après compromission. Injections SQL via les fonctions WP — WP_Query, wpdb::prepare mal utilisées dans des plugins custom ou des thèmes premium.

Ce qui remplace. Interface Payload CMS protégée par authentification JWT + 2FA (TOTP), RBAC par collection et par field. Next.js API Routes sécurisées par JWT ou OAuth 2.0 selon contexte. WAF (Web Application Firewall) au niveau edge (Cloudflare ou OVHcloud Anti-DDoS). Aucune surface PHP en production — le front Next.js est du JavaScript/TypeScript compilé, pas du PHP interprété à la demande. Headers de sécurité HTTP correctement configurés via next.config.js (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy). Voir service Souveraineté Numérique Responsable pour les déploiements avec exigences de conformité renforcée.

#Intégrations conservées post-migration

La migration vers une stack headless ne signifie pas partir de zéro sur les intégrations marketing et commerciales. Voici comment chaque catégorie est traitée.

CRM et marketing automation. HubSpot Forms et HubSpot CRM : les formulaires Payload (collection leads + webhook) envoient vers l'API HubSpot Contacts nativement. Salesforce : connecteur via Payload hooks + API Salesforce REST. Pipedrive, Zoho CRM : même pattern via Payload webhook.

Email marketing. Mailchimp, Brevo (ex-SendinBlue), Klaviyo : intégration API dans les Payload hooks de soumission de formulaire. Les sequences de bienvenue et les listes de segmentation sont conservées — seul le point d'entrée change (formulaire Payload plutôt que formulaire WP).

Analytics. Google Analytics 4 via composant Next.js + Consent Mode v2 compliant (CMP intégrée). Matomo auto-hébergé pour les clients avec exigences RGPD strictes. Plausible comme alternative légère sans cookie.

Live chat et support. Intercom, Crisp, Zendesk Chat : intégration via script dans le layout Next.js root, lazy-loaded pour ne pas impacter les Core Web Vitals.

Paiement. Stripe : intégration Payload collections (produits, commandes) + Next.js API Route pour le checkout. Pour les besoins e-commerce complexes, voir service Headless Commerce.

Booking et prise de RDV. Calendly embed en composant React lazy-loaded. Cal.com open-source comme alternative auto-hébergée.

#Méthodologie de déploiement

Nehos déploie tous ses projets Next.js + Payload CMS via une pipeline Git standardisée. Chaque push sur une Pull Request génère un déploiement Vercel Preview (URL unique, partageables avec les équipes marketing pour validation avant merge). Les branches main et production sont protégées par revues de code obligatoires. La CD (Continuous Deployment) vers staging est automatique sur merge vers main. Le déploiement en production est manuel (déclenchement humain) après validation staging.

Le déploiement canary — 10 % du trafic pendant 48h avant bascule complète — est systématique sur les migrations. Il permet de détecter des régressions sur des cas d'usage non couverts par les tests automatisés avant qu'ils n'affectent 100 % des visiteurs. Le monitoring pendant cette phase : Vercel Analytics (Web Vitals par route), Google Search Console (crawl stats, coverage), Sentry (erreurs JS front-end et API), Uptime Robot (SLA).

Pour les déploiements OVHcloud souverains : Docker Compose + Traefik comme reverse proxy + Let's Encrypt pour les certificats TLS, pipeline GitLab CI/CD auto-hébergée. Le schéma de déploiement est documenté et livré au client avec les credentials infrastructure au terme du projet.

#ROI mesurable — Cas cabinet conseil 15 000 visites/mois

Cas client de référence : cabinet de conseil B2B (conseil en organisation et transformation digitale, anonymisé NDA). Site WordPress avec Elementor, 68 pages, blog actif (120 articles), 15 000 visites organiques par mois. Enjeu : regain de compétitivité SEO face à des concurrents ayant déjà migré vers des stacks modernes, lead generation organique en stagnation depuis 18 mois malgré une stratégie de contenu active.

Diagnostic initial : Lighthouse Performance mobile 42 (LCP 5,8s, CLS 0,28, FID 180ms), Core Web Vitals CrUX 0/3 vert sur mobile, 18 plugins actifs dont 4 n'ayant pas reçu de mise à jour depuis plus de 12 mois (3 CVE documentées sur l'un d'eux), Elementor version 3.12 avec 380 kb de JS injecté sur chaque page, temps de génération TTFB > 800ms même sur hébergement premium.

Mission Nehos sur 12 semaines : audit complet, architecture Next.js 15 + Payload CMS 3, migration des 68 pages + 120 articles, intégration HubSpot CRM, déploiement Vercel Edge, 301 redirect mapping 240 URLs. Budget : 141 k€ HT.

Résultats mesurés à 6 mois post-migration. Lighthouse Performance mobile : 97 (LCP 0,9s, CLS 0,02, INP 45ms). Core Web Vitals CrUX : 3/3 vert sur mobile et desktop. Trafic organique : maintenu à J+30, +23 % à J+60, +67 % à J+180 (effet combiné Core Web Vitals + positions SEO récupérées sur plusieurs clusters). Leads organiques qualifiés (formulaire de contact + téléchargements de livres blancs) : +67 % en volume sur 6 mois vs 6 mois pré-migration. Incidents sécurité : 0 (vs 2 tentatives d'intrusion via wp-admin détectées dans les logs WP l'année précédente). Score NPS équipes internes (marketing + tech) sur l'outil CMS Payload : 72.

#Tarification — 8,5 k€ HT

Trois fourchettes selon la taille du site et la complexité des intégrations.

Site institutionnel 20 à 80 pages, blog optionnel, 1 formulaire de contact — 35 à 111 k€ HT, 8 à 10 semaines. Typiquement : site vitrine cabinet de conseil, site marketing SaaS B2B sans e-commerce, site corporate ETI. Inclus : audit complet, architecture Payload + Next.js, migration de contenu, 1 intégration CRM (HubSpot ou Salesforce), déploiement Vercel ou OVHcloud, 301 mapping, formation équipe marketing (2h), 30 jours de support post-lancement.

Site 80 à 250 pages, blog actif, multilingue optionnel, 2-3 intégrations —à partir de 51 k€ HT, 10 à 14 semaines. Typiquement : scale-up SaaS avec site marketing dense, cabinet multi-expertises avec contenu sectoriel, ETI avec plusieurs marques sur un même CMS. Inclus : audit complet, architecture multilingue (hreflang), migration de contenu + médias, intégrations CRM + email marketing + analytics, déploiement, 301 mapping, formation équipe (4h), 60 jours de support post-lancement.

Projet complexe 250+ pages, WooCommerce léger, intégrations API multiples, déploiement souverain OVHcloud — 221 k€ HT, 14 à 16 semaines. Inclus : périmètre complet ci-dessus + qualification WooCommerce (migration vers Payload e-commerce léger ou recommendation Medusa.js selon volume), intégrations API sur-mesure (ERP, PIM, booking), déploiement OVHcloud souverain avec pipeline GitLab CI/CD, SLA 99,5 % contractualisé, 90 jours de support.

Exploitation MCO post-livraison : forfait mensuel à partir de 825 € HT selon volume de contenu, fréquence des évolutions et SLA contractualisé. Estimation précise en 30 minutes via RDV consultant : [Calendly migration WP](https://calendly.com/raphael-poirier_/decouverte15min-nehos-groupe Outil d'estimation libre-service : Estimateur migration WordPress.