Table des matières

Pourquoi les équipes quittent WordPress

WordPress fait tourner environ 40 % du web mondial, mais cette part recule depuis 2024. Les raisons sont les mêmes partout : fatigue face aux failles de sécurité, surcharge de plugins et performances bridées.

Une installation WordPress classique — avec un thème et les plugins indispensables — génère entre 30 et 80 requêtes HTTP dès le départ. Chaque plugin ajoute du temps d'exécution PHP, des requêtes en base de données et de nouvelles surfaces d'attaque. Les équipes passent plus de temps à mettre à jour des plugins et à colmater des failles qu'à développer de nouvelles fonctionnalités.

Next.js renverse complètement ce modèle. Plutôt qu'une application PHP monolithique qui génère du HTML à chaque requête, vous disposez d'un framework React qui pré-génère les pages au moment du build, les sert depuis des CDN edge et hydrate le tout côté client de manière interactive. Résultat : des pages qui s'affichent en moins d'une seconde, zéro requête en base pour vos visiteurs, et un code que vous maîtrisez vraiment.

Les points de rupture

La plupart des équipes franchissent le cap après l'un de ces déclencheurs :

  • Échec aux Core Web Vitals — les sites WordPress peinent systématiquement sur le LCP et le CLS, surtout avec des constructeurs de pages comme Elementor ou WPBakery
  • Conflits de plugins — une seule mise à jour casse le site, et déboguer revient à désactiver les plugins un par un
  • Coûts d'hébergement — un hébergement WordPress managé (WP Engine, Kinsta) facture entre 30 et 200 €/mois pour des performances qu'un déploiement Vercel gratuit atteint sans effort
  • Expérience développeur — les templates PHP paraissent archaïques face au développement React basé sur des composants
  • Incidents de sécurité — 97 % des failles WordPress proviennent des plugins et des thèmes, pas du cœur de l'application

Next.js vs WordPress : le comparatif

Critère WordPress Next.js
Rendu PHP côté serveur à chaque requête Génération statique + ISR + server components
Performances LCP entre 2,5 et 6 s en moyenne LCP entre 0,5 et 1,5 s en moyenne
Sécurité Failles constantes via plugins et thèmes Aucune surface d'attaque (fichiers statiques sur CDN)
Coût d'hébergement 30 à 200 €/mois en managé Offre gratuite Vercel suffisante pour la plupart des sites
Contrôle SEO Limité par le thème + Yoast Contrôle total sur les méta, données structurées et sitemaps
Édition de contenu Panneau d'administration intégré CMS headless (Sanity, Strapi, Payload, Supabase)
Scalabilité Nécessite cache, CDN et optimisation BDD Edge-native, passe à des millions de visites sans configuration
Expérience développeur PHP + hooks + hiérarchie de templates React + TypeScript + outillage moderne
Temps de build Aucun (rendu à la volée) De quelques secondes à quelques minutes selon le volume de pages
Gestion des images Plugins requis (Smush, ShortPixel) next/image intégré avec optimisation automatique

Là où WordPress garde l'avantage

WordPress n'est pas le mauvais choix pour tout le monde. Si votre équipe n'a pas de développeurs et a besoin d'un blog ou d'un site vitrine rapidement, WordPress avec un hébergeur managé reste la solution la plus rapide. L'écosystème de thèmes et de plugins permet à des utilisateurs non techniques de créer des sites fonctionnels sans écrire une ligne de code.

Mais dès que vous avez besoin de fonctionnalités sur mesure, d'optimisation des performances ou d'une équipe de développement productive — WordPress devient le goulet d'étranglement.

Les gains de performance à espérer

Nous avons migré plus de 200 sites WordPress vers Next.js. Voici les chiffres que nous constatons régulièrement :

Largest Contentful Paint (LCP) : de 3,2 s en moyenne à 0,9 s — soit une amélioration de 72 %. La génération statique signifie que le HTML est prêt avant même que la requête n'arrive.

Cumulative Layout Shift (CLS) : de 0,18 à 0,02. Le composant Next.js Image gère automatiquement les dimensions, éliminant les décalages visuels qui polluent les thèmes WordPress.

First Input Delay (FID) / Interaction to Next Paint (INP) : de 180 ms à 45 ms. Plus de jQuery, plus de scripts de plugins qui se disputent le thread principal.

Time to First Byte (TTFB) : de 600 ms (en cache) à 50 ms. Un CDN edge face à un serveur d'origine, ce n'est pas un combat équitable.

Poids des pages : de 2,8 Mo en moyenne à 340 Ko. Plus de CSS inutilisé venant des thèmes, plus de scripts de plugins bloquant le rendu.

Ces chiffres se traduisent directement en résultats business. Google utilise les Core Web Vitals comme signal de classement. Les sites rapides convertissent mieux. Chaque amélioration de 100 ms du temps de chargement augmente le taux de conversion d'environ 1 %.

Le processus de migration étape par étape

Phase 1 : Audit et export du contenu

Avant de toucher au code, auditez tout ce qui se trouve dans WordPress :

  • Pages et articles — exportez tout le contenu, y compris les champs personnalisés (ACF, meta boxes)
  • Médiathèque — téléchargez toutes les images et tous les documents
  • Structure des URLs — documentez chaque permalien, URL de catégorie et slug de custom post type
  • Redirections — exportez toutes les règles de redirection existantes
  • Formulaires — documentez toutes les configurations de formulaires et leurs destinations
  • Intégrations tierces — listez chaque plugin et sa fonction

Utilisez wp-cli pour l'export ou l'outil d'export natif de WordPress. Pour les champs ACF et les custom post types, utilisez l'API REST pour obtenir du JSON structuré.

Phase 2 : Choisir votre couche de contenu

La décision la plus importante de la migration concerne l'endroit où vivra votre contenu après WordPress. Les options :

WordPress headless — conservez WordPress comme backend et utilisez l'API REST ou WPGraphQL pour alimenter Next.js. Bonne étape de transition, mais vous continuez à maintenir WordPress.

CMS headless — Sanity, Strapi, Payload CMS ou Contentful. Conçus spécifiquement pour les architectures headless. Sanity et Payload sont nos deux recommandations principales pour leur flexibilité.

Base de données directe — Supabase ou PlanetScale. Contenu stocké en PostgreSQL avec une interface d'administration personnalisée. Contrôle maximal, mais davantage de travail en amont.

Markdown/MDX — Pour les blogs de développeurs et la documentation. Le contenu vit dans le dépôt git, versionné nativement.

Phase 3 : Construire le site Next.js

Commencez avec create-next-app en utilisant l'App Router. Faites correspondre la hiérarchie de templates WordPress aux layouts et pages Next.js :

  • header.php / footer.php → app/layout.tsx
  • page.php → app/page.tsx
  • single.php → app/blog/[slug]/page.tsx
  • archive.php → app/blog/page.tsx
  • functions.php → Routes API dans app/api/

Recréez votre design en composants React. C'est l'occasion de solder des années de dette CSS et de repartir sur des bases saines avec un système de design moderne.

Phase 4 : Migration SEO

C'est la phase qui peut faire ou défaire la migration. Plus de détails dans la section suivante.

Phase 5 : Tests et mise en ligne

Faites tourner les deux sites en parallèle. Utilisez des outils comme Screaming Frog pour crawler le nouveau site et le comparer à l'ancien :

  • Chaque ancienne URL dispose d'une redirection ou d'une nouvelle URL correspondante
  • Tous les titres et descriptions méta sont préservés ou améliorés
  • Les données structurées (schema.org) s'affichent correctement
  • Le sitemap XML est valide et soumis à la Search Console
  • Les balises canoniques pointent vers les bonnes URLs
  • Les méta Open Graph et Twitter Card sont présentes
  • Tous les liens internes se résolvent correctement

Gérer le SEO pendant la migration

Le SEO est la première préoccupation de toutes les équipes qui migrent depuis WordPress. Perdre ses positions dans les résultats de recherche, et la migration est un échec — peu importe la rapidité du nouveau site.

Cartographie des URLs

Établissez une carte complète de toutes les anciennes URLs vers les nouvelles. Chaque page, sans exception. Utilisez un tableur ou un script pour générer les règles de redirection. Implémentez-les sous forme de redirections permanentes 301 dans next.config.js ou sur votre plateforme d'hébergement.

Préserver les métadonnées

Extrayez tous les titres SEO, méta descriptions et données Open Graph depuis Yoast ou RankMath. Associez-les aux pages correspondantes dans Next.js. Ne comptez pas sur les méta générées automatiquement — vérifiez manuellement les 50 pages qui génèrent le plus de trafic.

Données structurées

Les plugins WordPress génèrent automatiquement le balisage schema. Avec Next.js, vous le contrôlez directement. Implémentez du JSON-LD pour : Organization sur la page d'accueil, Article sur les articles de blog, BreadcrumbList sur toutes les pages, FAQPage sur les pages avec des sections FAQ, et LocalBusiness le cas échéant.

Sitemap XML

Générez un sitemap dynamique avec next-sitemap ou une route API personnalisée. Soumettez-le à Google Search Console immédiatement après la mise en ligne.

Surveiller après le lancement

Consultez la Search Console quotidiennement pendant les 4 premières semaines. Guettez les erreurs de crawl et les pages en 404, les baisses d'indexation, les fluctuations de positionnement (normales pendant 2 à 4 semaines) et les améliorations des Core Web Vitals.

Gérer le contenu après WordPress

L'objection la plus fréquente au départ de WordPress, c'est la perte du panneau d'administration. Les rédacteurs sont attachés à l'éditeur WordPress qu'ils connaissent bien.

Les plateformes CMS headless modernes ont entièrement comblé cet écart. Sanity Studio, Payload CMS et Strapi proposent tous des expériences d'édition riches avec aperçu en direct, glisser-déposer et gestion des médias. Beaucoup de rédacteurs finissent par les préférer une fois la transition faite.

Pour les équipes qui veulent l'option la plus simple possible, Payload CMS mérite une attention particulière. Il s'intègre directement dans votre application Next.js, utilise votre base de données existante et propose un panneau d'administration qui rivalise avec WordPress — sans les contraintes de sécurité et de performance qui vont avec.

Les erreurs classiques à éviter

Ne pas tout rediriger. Chaque URL qui a existé sur WordPress doit avoir une redirection — y compris les URLs de pagination, les pages des pièces jointes, les archives d'auteurs et les URLs de flux RSS. Oubliez-en et vous perdez du jus de lien.

Lancer sans monitoring. Mettez en place la surveillance de disponibilité, le suivi des erreurs (Sentry) et les analytics avant le lancement — pas après.

Sur-ingénierie dès la première version. Migrez d'abord le contenu et le design. Ajoutez de nouvelles fonctionnalités une fois la migration stabilisée. Vouloir tout repenser et tout remplacer en même temps double les risques.

Négliger la médiathèque. WordPress génère plusieurs tailles d'image par upload. Définissez votre stratégie d'images avant la migration, puis traitez-les en masse.

Oublier les flux RSS. Si votre blog WordPress a des abonnés via RSS, conservez l'URL du flux ou redirigez-la.

Quand rester sur WordPress

Soyez honnête sur votre situation. WordPress reste le bon choix si :

  • Vous n'avez pas de développeurs et pas de budget pour en faire appel
  • Votre équipe de contenu dépend fortement de plugins WordPress spécifiques qui n'ont pas d'équivalent headless
  • Vous gérez une boutique WooCommerce avec des configurations produits complexes (migrez plutôt vers Shopify ou Medusa que vers Next.js)
  • Votre site reçoit moins de 10 000 visites par mois et la performance n'est pas un enjeu commercial

Pour tous les autres — surtout les équipes qui construisent des sites marketing, des landing pages SaaS, des plateformes de contenu, ou tout projet où la performance et l'expérience développeur comptent — Next.js est le choix qui s'impose en 2026.

FAQ

Combien de temps prend une migration WordPress vers Next.js ? Un site vitrine classique (10 à 30 pages) prend 3 à 6 semaines. Un site riche en contenu avec des centaines d'articles prend 6 à 12 semaines. Le calendrier dépend avant tout de la complexité du contenu et des fonctionnalités personnalisées, pas du nombre de pages.

Est-ce que je vais perdre mon positionnement Google ? Pas si vous gérez correctement les redirections et la migration SEO. Attendez-vous à une légère fluctuation (1 à 3 semaines) le temps que Google recrawle et réindexe le site. La plupart des sites voient leur positionnement s'améliorer en 4 à 8 semaines grâce aux meilleurs Core Web Vitals.

Les personnes non techniques peuvent-elles toujours éditer le contenu ? Oui. Un CMS headless comme Sanity, Payload ou Strapi propose une expérience d'édition visuelle. Certains offrent un aperçu en direct pour que les rédacteurs voient leurs modifications en temps réel.

Combien coûte l'hébergement d'un site Next.js ? L'offre gratuite de Vercel convient à la plupart des sites. Le plan Pro (20 $/mois) couvre les projets commerciaux avec domaines personnalisés et analytics. Comparez à 30-200 €/mois pour un hébergement WordPress managé.

Faut-il apprendre React ? Si vous êtes développeur, oui — React est le socle de Next.js. Si vous êtes rédacteur ou marketeur, non. Le CMS gère votre flux de travail ; le framework sous-jacent vous est invisible.

Et pour l'e-commerce ? Pour les boutiques simples, Shopify avec un storefront Next.js (via la Storefront API) est excellent. Pour le commerce B2B complexe, Medusa.js ou Saleor couplé à Next.js vous donne un contrôle total. La migration WooCommerce vers Next.js est techniquement possible mais rarement justifiée — mieux vaut migrer vers une plateforme e-commerce dédiée.

Puis-je garder WordPress comme backend ? Oui. Le WordPress headless (via WPGraphQL ou l'API REST) vous permet de conserver l'éditeur WordPress tout en servant le frontend via Next.js. C'est une bonne approche de transition, même si vous héritez toujours de la charge de maintenance WordPress.

Et WordPress multisite ? Les architectures multi-tenant fonctionnent très bien dans Next.js grâce au middleware pour le routage par domaine. Chaque site peut partager des composants tout en conservant son propre contenu et sa configuration. C'est bien plus propre que WordPress multisite et beaucoup plus facile à maintenir.