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

#Pourquoi migrer de WordPress à Next.js en 2026

WordPress est le CMS le plus déployé au monde, ce que ses défenseurs brandissent comme une marque de qualité. En réalité, c'est aussi une cible : tous ces sites partagent 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.

Des alertes sont régulièrement publiées sur des failles critiques dans l'écosystème WordPress/plugins (Contact Form 7, Yoast SEO, WooCommerce, Elementor). Une grande partie 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 plusieurs Mo de ressources 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 score Lighthouse Performance élevé 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 trop long en mobile pénalise les positions organiques. Pour un site qui génère des leads, perdre des positions sur une requête à fort intent 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 nécessite des tests manuels sur tous les plugins actifs : sur un site avec beaucoup de plugins, c'est du temps à chaque 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 plusieurs centaines de kb de JS 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 Netlify, 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. Netlify (notre standard) pour les projets dont la priorité est la performance globale maximale et la DX (déploiement continu Git, deploy previews par Pull Request, analytics intégrés, 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 visé. Un score Lighthouse Performance nettement meilleur, des Core Web Vitals au vert sur desktop et mobile, un trafic SEO organique maintenu dans les semaines qui suivent la bascule puis amélioré grâce aux gains Core Web Vitals. Nous mesurons ces points avant et après la migration, sur votre site.

#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 Deploy Preview Netlify (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 : RUM (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.

#Exemple de situation : cabinet de conseil

Exemple de situation, pas une référence client : un cabinet de conseil B2B avec un site WordPress sous Elementor, un blog actif et une génération de leads organiques qui stagne malgré une stratégie de contenu. Enjeu : regagner de la compétitivité SEO face à des concurrents ayant déjà migré vers des stacks modernes.

Diagnostic initial typique : Lighthouse Performance mobile faible, Core Web Vitals CrUX dans le rouge sur mobile, plusieurs plugins sans mise à jour depuis plus d'un an (dont certains avec des failles documentées), Elementor injectant beaucoup de JavaScript sur chaque page, TTFB élevé même sur un hébergement premium.

Mission type : audit complet, architecture Next.js 15 + Payload CMS 3, migration des pages et des articles, intégration HubSpot CRM, déploiement sur une infrastructure edge, 301 redirect mapping exhaustif.

Ce que nous mesurons ensuite : Lighthouse Performance mobile, Core Web Vitals CrUX sur mobile et desktop, trafic organique à J+30, J+60 et J+180, leads organiques qualifiés (formulaire de contact, téléchargements de livres blancs), incidents de sécurité, et satisfaction des équipes internes sur l'outil CMS.

#Tarification

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

Site institutionnel 20 à 80 pages, blog optionnel, 1 formulaire de contact — à partir de 15 000 € HT. 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 Netlify ou hébergeur français, 301 mapping, formation de l'équipe marketing, support post-lancement.

Site de 80 à 250 pages, blog actif, multilingue optionnel, 2-3 intégrations — sur devis, chiffré en 48 h. 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 de l'équipe, support post-lancement.

Projet complexe, 250+ pages, WooCommerce léger, intégrations API multiples, déploiement souverain — à partir de 50 000 € HT. Inclus : périmètre complet ci-dessus + qualification WooCommerce (migration vers Payload e-commerce léger ou recommandation Medusa.js selon volume), intégrations API sur-mesure (ERP, PIM, booking), déploiement chez un hébergeur français avec pipeline GitLab CI/CD, SLA contractualisé, support post-lancement.

Exploitation MCO post-livraison : maintenance logicielle à partir de 750 € par mois, selon le volume de contenu, la fréquence des évolutions et le SLA contractualisé. Estimation précise en 30 minutes via RDV consultant : Calendly migration WP. Outil d'estimation libre-service : Estimateur migration WordPress.