Migrer son site WordPress vers Nuxt : quand est-ce vraiment justifié ?

Migrer WordPress vers Nuxt n'est pas une upgrade automatique — c'est une décision stratégique justifiée par 4 critères précis, pas par la mode. On a fait quatre migrations cette année. Deux ont eu un ROI clair (perfs, conversion, équipe dev qui livre 3x plus vite). Deux auraient pu rester sur WordPress optimisé sans perdre grand-chose, et auraient même évité quelques mois de friction inutile.

Cet article te donne le cadre qu'on utilise en cadrage chez CZMultimedia, agence de développement d'application web à Lyon, pour répondre honnêtement à la question "faut-il qu'on migre ?". Pas de plaidoyer pro-Jamstack, pas de bashing WordPress : un arbre de décision basé sur ce qu'on a vu sur le terrain.

Pour un cadrage honnête sur ton projet : Contactez-nous — on te dit clairement si la migration vaut le coup ou pas.

Sommaire

• Pourquoi cette question revient en 2026
• Les 4 cas où la migration est justifiée
• Les 3 cas où il vaut mieux optimiser WordPress
• Architecture cible : Nuxt + Strapi ou Nuxt Content
• Cas terrain : migration d'un site corporate
• Risques et coûts cachés
• Checklist : faut-il migrer ?
• FAQ
• Conclusion

Pourquoi cette question revient en 2026

Trois forces convergent et expliquent pourquoi on reçoit, en moyenne, deux à trois demandes de cadrage "WP → Nuxt" par mois en ce moment.

1. La pression performance n'est plus négociable. Google a durci son discours sur les Core Web Vitals depuis l'introduction d'INP (Interaction to Next Paint) en 2024. Sur WordPress, atteindre un INP < 200 ms et un LCP < 2,5 s sur mobile demande une discipline plugin et thème que peu d'équipes tiennent dans la durée. Les projets WP qu'on audite ont en moyenne 20 à 40 plugins, dont 5 à 10 chargent du JS sur toutes les pages.

2. Le headless et le Jamstack se sont stabilisés. Nuxt 3 (et désormais Nuxt 4) propose un rendu hybride mature (SSR, SSG, ISR, edge), des modules officiels solides (@nuxt/content, @nuxt/image, @nuxt/seo), et un écosystème Vue 3 qui ne bouge plus tous les six mois. Ce n'est plus un pari technologique en 2026.

3. L'AI search redéfinit le SEO. Les LLM (Perplexity, ChatGPT Search, Claude, Google AI Overviews) crawlent, parsent et re-citent du contenu structuré. Un site Nuxt avec schéma Article, FAQPage et un HTML sémantique propre est plus facilement réutilisé. Les sites WP avec balisage anarchique (héritage de plugins SEO empilés) le sont moins.

4. L'expérience développeur (DX). Pour une équipe interne avec des devs Vue/React, livrer une nouvelle page sur Nuxt prend 1 à 2 jours. Sur un WordPress custom avec ACF + Gutenberg + thème child, ça peut prendre 3 à 5 jours, plus le risque de casse à chaque mise à jour de plugin.

Les 4 cas où la migration est justifiée

Voici les quatre scénarios où, sur nos projets, la migration WordPress → Nuxt a généré un retour clair.

1. Performance critique avec impact business mesuré

Si ton LCP mobile est au-dessus de 3,5 s, que tu as essayé les optimisations WP classiques (cache page, image lazy loading, suppression de plugins, CDN) et que tu plafonnes, Nuxt apporte un gain structurel. Le rendu côté serveur ou statique avec hydration partielle de Nuxt élimine les goulots d'étranglement liés à l'empilement WordPress (PHP + plugins + thème + jQuery + scripts marketing).

Signal terrain : sur un e-commerce dont chaque seconde de latence faisait perdre 7 % de conversion (mesure interne client, pas généralisable), passer de 4,2 s à 1,1 s de LCP a justifié à lui seul la migration.

Si ce point te parle, va voir notre article dédié : amélioration performance sites web.

2. Une équipe dev existante (Vue, React, ou JS senior)

Si tu as déjà une équipe qui code en JS moderne — front Vue/React, ou même backend Node — Nuxt s'aligne avec leur stack. Tu factures moins de "context switch", tu réutilises ton design system, tu déploies sur la même infra (Vercel, Cloudflare Pages, Netlify) que les autres apps.

À l'inverse, si ton équipe est PHP/WordPress, leur faire apprendre Vue + Nuxt + Pinia + écosystème JS est un projet de 6 à 12 mois. Ce n'est pas un drame, mais il faut le budgéter.

3. Multi-channel : web + app mobile + écrans + AI

Si ton contenu doit être servi à plusieurs surfaces (site web + app mobile native + chatbot + écrans physiques + flux pour LLM), un back-office headless (Strapi, Directus, ou WP en mode headless) couplé à Nuxt rend le multi-channel naturel. WordPress monolithique force à dupliquer ou à hacker des plugins API pour exposer le contenu.

Cas typique : un éditeur B2B qui veut pousser ses fiches produit vers son site, son app sales et un chatbot ChatGPT custom — un seul modèle de contenu, plusieurs consommateurs.

4. Custom UI très avancé ou interactions riches

Si ton site doit afficher des configurateurs, simulateurs, dashboards, animations 3D (Three.js, R3F), ou des micro-interactions complexes, le couple Nuxt + Vue 3 te donne plus de contrôle qu'un thème WP customisé. Tu travailles avec des composants, un design system, un build moderne (Vite), des tests unitaires (Vitest).

Sur WordPress, tu finis par charger React ou Vue dans le thème, par-dessus jQuery et l'éditeur Gutenberg — la stack devient incohérente.

Les 3 cas où il vaut mieux optimiser WordPress

À l'inverse, voici les trois scénarios où on déconseille la migration. Ce sont des cas où on a vu des clients dépenser 30 à 50k€ en migration pour un gain marginal — l'argent aurait été mieux placé en optimisation WP, en SEO de fond ou en acquisition.

1. Site éditorial avec une équipe non-tech autonome sur WP

Si l'essentiel de ton activité, c'est publier deux à cinq articles par semaine, que tes éditeurs maîtrisent Gutenberg, ACF et Yoast, et que la chaîne édito tourne, ne casse pas ce qui marche. Migrer vers Nuxt, c'est imposer Markdown/MDC ou un nouveau back-office (Strapi, Directus) à des gens dont ce n'est pas le métier. Tu vas perdre 3 à 6 mois de productivité éditoriale pour gagner 1 s sur le LCP.

Optimise plutôt : audit plugins, thème léger, CDN, cache objet (Redis), images en WebP/AVIF.

2. Équipe technique limitée ou inexistante

Si tu es une PME sans dev interne, que tu te reposes sur une agence pour tes évolutions, WordPress optimisé reste un choix raisonnable. L'écosystème WP est plus standardisé (n'importe quelle agence prend la main), les compétences se trouvent partout, le risque de "single point of failure" sur un dev Vue parti à la concurrence est réduit.

Nuxt demande une équipe (interne ou agence longue durée) qui maîtrise Node, Vue, le déploiement edge et le suivi des dépendances.

3. Budget serré ou ROI flou

Une migration WP → Nuxt sérieuse, c'est entre 15k€ et 45k€ sur nos projets récents (corporate + blog), plus 6 à 18 mois pour amortir si l'objectif est purement la performance. Si tu n'as pas de KPI business adossé (conversion, SEO chiffré, lead gen), tu vas justifier l'investissement par "c'est plus moderne" — c'est rarement suffisant.

Contactez-nous si tu as un doute sur ton cas — on te dit honnêtement s'il vaut mieux migrer ou optimiser, sans engagement.

Architecture cible : Nuxt + Strapi ou Nuxt Content

Si tu décides de migrer, deux architectures dominent en 2026. Le bon choix dépend de qui édite le contenu, et à quelle fréquence.

Option A : Nuxt Content (contenu en Git)

Comment ça marche : tes pages, articles et données structurées vivent dans le repo (content/blog/*.md, content/pages/*.md) en Markdown ou MDC. Nuxt Content les compile en build (SSG) ou à la volée (SSR/ISR).

Avantages :

• Aucune base de données ni back-office à héberger
• Versioning Git natif (PR, review, rollback)
• Performance maximale (statique pur)
• Coût d'infra quasi nul (Cloudflare Pages, Netlify, Vercel free tier sur petits volumes)

Inconvénients :

• Édition par des non-devs : compliquée sans outil tiers (Decap CMS, TinaCMS) ou sans formation Markdown
• Pas adapté à une équipe édito de 5+ personnes qui publient quotidiennement
• Multi-langue possible mais demande discipline

Quand le choisir : blog d'agence, site corporate avec contenu stable, documentation produit, équipe technique ou semi-technique.

Option B : Nuxt + Strapi (ou Directus) headless

Comment ça marche : Strapi (ou Directus) joue le rôle de back-office — interface d'édition, types de contenu, relations, médias, multi-langue, rôles. Nuxt consomme l'API REST/GraphQL exposée et rend les pages.

Avantages :

• Vraie expérience éditeur (formulaires, preview, rôles, workflows)
• Multi-langue, multi-tenant, relations complexes natives
• Découple complètement front et contenu : tu peux refaire le front sans toucher au contenu
• Reste plus léger qu'un WP avec 30 plugins

Inconvénients :

• Une infra de plus à héberger et maintenir (Strapi = Node + DB)
• Coût de licence (Strapi Cloud ~99€/mois minimum) ou self-host à gérer
• Courbe d'apprentissage pour configurer les types de contenu et les permissions

Quand le choisir : site avec équipe édito non-tech (3+ personnes), multi-langue, e-commerce léger, plateforme contenu (PIM/DAM intégré), projets multi-channel.

Option C (hybride) : WordPress headless

Garder WordPress comme CMS et consommer son API REST ou GraphQL (WPGraphQL) depuis Nuxt. C'est une option défendable si l'équipe édito connaît déjà très bien WP et qu'on veut juste gagner sur le rendu front. Mais en pratique, on y revient rarement : tu cumules les inconvénients de WordPress (mises à jour, plugins, sécurité) sans le bénéfice de la cohérence stack.

Cas terrain : migration d'un site corporate

Voici un projet concret livré récemment, anonymisé.

Contexte : société de services B2B, site corporate WordPress (Avada + 28 plugins), 60 pages + blog (~120 articles), traffic ~25k visites/mois, équipe édito de 2 personnes, 1 dev externe en TMA.

Symptômes initiaux :

• LCP mobile : 4,2 s (mesure CrUX P75)
• INP : 380 ms (au-delà du seuil "needs improvement")
• TTFB : 1,1 s (cache plugin pourtant actif)
• Bounce rate mobile : 68 %
• Conversion formulaire contact : 1,8 %

Diagnostic : empilement de plugins (Yoast, Elementor, Slider Revolution, formulaires divers, A/B test) qui chargeaient ~1,2 Mo de JS et bloquaient le rendu. Le thème Avada générait du HTML imbriqué difficile à optimiser. Tentatives d'optimisation antérieures (cache, image lazy) avaient plafonné.

Décision : migration vers Nuxt 3 + Nuxt Content (équipe édito petite, contenu stable, contenu blog en Markdown). Hébergement Cloudflare Pages.

Méthode CZMultimedia (étapes) :

1. Cadrage et inventaire (semaine 1-2)

Audit des 60 pages, mapping des URLs source → cible, inventaire des plugins WP à remplacer (formulaire → endpoint Nitro custom, A/B test → analytics produit, etc.), définition des types de contenu Nuxt Content.

2. Design system + dev front (semaines 3-8)

Reprise visuelle légère (pas de refonte design — l'objectif était la perf, pas le look). Composants Vue, intégration Bootstrap 5, optimisation images (NuxtImg + Cloudflare Images), build SSG.

3. Reprise de contenu (semaines 6-9, en parallèle)

Export WP → Markdown via script custom + revue éditoriale. Un junior + un éditeur ont repris les 120 articles en 3 semaines (formation Markdown incluse).

4. QA, redirections, bascule (semaines 10-12)

Mapping de redirections 301 (1:1 sur les URLs blog, ajustements sur les pages corporate), setup Cloudflare en mode preview, recette par l'équipe édito, bascule DNS un mardi matin.

Résultats à J+90 (sur ce projet précis, ne pas généraliser) :

• LCP mobile : 1,1 s (-74 %)
• INP : 120 ms
• TTFB : 180 ms
• Bounce rate mobile : 48 % (-20 points)
• Conversion formulaire : 2,12 % (+18 % relatif)
• Positions SEO Search Console : tenues à J+30, +12 % de clics organiques à J+90 (effet combiné perf + meilleure indexation)

Coût et durée : 12 semaines calendaires, équipe de 2 (1 dev senior, 1 junior) + 0,5 ETP édito côté client. Budget total dans la fourchette 30-40k€.

Ce qui a marché : le mapping de redirections fait dès la semaine 2, la bascule progressive (preview pendant 3 semaines avant DNS), la formation édito intégrée au projet (pas après).

Ce qu'on aurait fait différemment : démarrer plus tôt l'export du contenu — on a perdu 1 semaine à debugger le script d'extraction WP (HTML pourri par Elementor, à nettoyer manuellement).

Risques et coûts cachés

Une migration WP → Nuxt n'est pas qu'un projet de dev. Voici les pièges qu'on voit le plus souvent.

SEO : la peur n°1 (souvent gérable)

Le risque réel : casser les URLs sans redirections 301 propres, perdre les balisages structurés, oublier des canoniques, casser le sitemap. Sur nos projets, on n'a jamais perdu de SEO net quand le mapping 1:1 était fait avant la bascule et que la Search Console était surveillée à J+7, J+30, J+90.

À prévoir :

• Mapping URL source → cible exhaustif (export sitemap WP + crawl Screaming Frog)
• Redirections 301 côté Nuxt (nuxt.config.ts ou _redirects Cloudflare/Netlify)
• Reprise des balisages : Article, FAQPage, Organization, BreadcrumbList
• Sitemap.xml automatisé (@nuxtjs/sitemap)
• Submission Search Console post-bascule
• Surveillance des 404 dans les 30 premiers jours

Formation de l'équipe édito

Si tu passes de Gutenberg à Markdown/MDC ou à Strapi, prévois 2 à 4 sessions de formation et un guide écrit. Sinon, l'équipe va revenir te voir tous les jours pour publier un article. Sur le projet corporate cité ci-dessus, on a budgété 1 jour de formation + 1 demi-journée de support sur 4 semaines.

Maintenance et dépendances

Nuxt + Vue + l'écosystème JS bouge vite. Tu auras des mises à jour mineures tous les 2-3 mois et des migrations majeures tous les 12-18 mois (Nuxt 3 → 4, par exemple). Budgéter une enveloppe TMA récurrente (l'équivalent de 0,5 à 2 jours/mois selon la taille du site) est non négociable.

Coûts d'infra

Bonne nouvelle : un site Nuxt SSG sur Cloudflare Pages coûte souvent moins qu'un hébergement WP managé. Compter 0–20€/mois pour un site corporate moyen (vs 30–80€ chez Kinsta/WP Engine).

Mauvaise nouvelle : si tu pars sur Strapi self-hosted, ajoute 25–60€/mois (VPS + DB managée + backups).

Dépendance prestataire

Si l'agence qui livre Nuxt disparaît demain, peux-tu trouver un repreneur ? La réponse en 2026 est "oui, plus facilement qu'en 2022", mais c'est encore plus rare qu'un dev WP. Privilégier une agence avec documentation, code propre et tests, ou intégrer un dev en interne.

Checklist : faut-il migrer ?

Si tu coches 5/8 ou plus, la migration est probablement justifiée.Si tu coches moins de 3, optimise WordPress et garde le budget pour de l'acquisition ou du SEO de fond.

FAQ

Conclusion

Pour résumer ce qu'on retient sur le terrain :

• Migrer WordPress vers Nuxt n'est pas une upgrade automatique — c'est une décision stratégique justifiée par 4 critères (perf critique, équipe dev existante, multi-channel, custom UI avancé).
• Si tu coches au moins 2 de ces 4 critères, la migration est probablement rentable. Si tu n'en coches qu'un, optimise WordPress avant.
• L'architecture cible dépend de ton équipe édito : Nuxt Content pour les petites équipes techniques, Strapi/Directus pour les équipes édito larges ou multi-langue.
• Le SEO se garde si les redirections 301 et les balisages sont préparés dès le cadrage. Le risque réel est l'exécution, pas la techno.
• Le coût se situe entre 15k€ et 45k€ pour un site corporate, avec amortissement 18-24 mois sur la perf seule, plus rapide si conversion ou SEO sont des leviers business chiffrés.

Si tu hésites, le pire choix est de migrer "pour faire moderne" sans avoir validé un cas d'usage business. On préfère te dire "reste sur WordPress, on optimise" plutôt que d'embarquer un projet qui ne paiera pas son ticket.

Notre agence de développement d'application web à Lyon accompagne ces refontes — Nuxt 3 reste notre stack de prédilection (agence Vue.js à Lyon) et on peut auditer ton WordPress avant de te dire si la migration en vaut la peine. Pour automatiser tes process autour du nouveau site (lead routing, sync CRM, publication multi-canal), notre agence d'automatisation à Lyon peut compléter le projet de migration.

Contactez-nous — on regarde ensemble ton site actuel, ton équipe et tes objectifs, et on te dit honnêtement si la migration vaut le coup. Réponse sous 24h, sans engagement.