Vue ou Nuxt, lequel choisir ?

TL;DR — Vue.js est un framework JavaScript pour construire des interfaces interactives ; Nuxt est le framework qui s'appuie dessus pour aller plus loin, notamment côté rendu serveur et SEO. Choisir entre les deux, c'est avant tout une question de contexte projet.

Un peu de contexte

Dans l'écosystème JavaScript, les choix ne manquent pas. React, Astro, Angular, Svelte, Solid... et bien sûr Vue.js. Depuis sa création par Evan You en 2014, Vue s'est imposé comme une solution crédible, lisible et agréable à utiliser.

Nuxt, lui, est né d'un besoin concret : rendre Vue exploitable pour des projets nécessitant d'autres modes de fonctionnement, c'est-à-dire avec du rendu côté serveur, une structure de projet cohérente, et une bonne gestion du SEO. Créé en 2016 par Sébastien Chopin et son frère Alexandre, Nuxt est aujourd'hui très complet construit autour de Vue et de Vite.

Vue en bref

Vue.js est un framework JavaScript progressif pour construire des interfaces utilisateur. Il est particulièrement apprécié pour :

• Sa courbe d'apprentissage OKLM on peut l'adopter progressivement, sans tout réécrire et même le greffer sur des pages existantes (un peu à la manière de jQuery mais ce n'est pas très pratique)
• Sa syntaxe TKT avec les Single File Components (fichiers .vue) qui regroupent template, script et style dans une seule brique et qui sont bien plus proches de ce qu'on produit en intégration native que d'autres frameworks tels que React avec JSX
• Sa réactivité grv de ouf avec la Composition API (introduite en Vue 3), qui apporte une vraie flexibilité architecturale
• Son écosystème swag : Vue Router, Pinia, Vite, et une communauté active

Vue est un framework côté client (CSR — Client Side Rendering) par défaut. Le code HTML ou plutôt le DOM est généré dans le navigateur à partir du code JavaScript des composants. C'est ce détail qui va se révéler important.

Nuxt en bref

Nuxt est un méta-framework basé sur Vue. Il ajoute une couche d'abstraction qui prend en charge des problématiques que Vue ne résout pas nativement (parce qu'il n'est pas fait pour ça) :

• Rendu universel (SSR / SSG / hybride) : le contenu peut être généré côté serveur, au build (compilation), ou à la demande
• Routing automatique basé sur la structure des fichiers dans /pages
• Auto-imports des composants, composables et utilitaires
• Modules Nuxt et plugins pour intégrer facilement des outils tiers (image, i18n, PWA, Auth...)
• Nitro, le moteur serveur intégré, compatible avec de nombreuses plateformes de déploiement (Vercel, Netlify, Node.js, Cloudflare Workers...)
• Composables spécifiques avec une belle petite collection qui vient compléter celle de Vue

Nuxt ne remplace pas Vue, il le complète, il lui ajoute des pouvoirs insoupçonnés. Tout ce qu'on sait faire en Vue fonctionne dans Nuxt, avec en prime une structure de projet qui fait gagner un temps précieux sur les projets d'équipe et sur la documentation.

Une différence fondamentale : le rendu

On touche au coeur de la meu... du sujet avec différents modes de rendus possibles de nos jours.

Mode	Description	Outil
CSR (Client Side Rendering)	Le HTML est généré dans le navigateur	Vue seul
SSR (Server Side Rendering)	Le HTML est généré à chaque requête par le serveur	Nuxt
SSG (Static Site Generation)	Le HTML est pré-généré au moment du build	Nuxt
ISR (Incremental Static Regeneration)	Pages statiques regénérées à intervalles	Nuxt (via Nitro)

Vue en mode CSR convient très bien pour des applications où le SEO n'est pas critique : interfaces d'administration, dashboards, apps internes, SaaS avec espace connecté.

Nuxt avec SSR ou SSG devient indispensable dès qu'on a besoin que les moteurs de recherche indexent le contenu ou que la première navigation+rendu de page soit véloce (lié aux indiacteurs Core Web Vitals et au ressenti utilisateur).

Le mode hybride de Nuxt est très intéressant pour combiner toute cette panoplie de modes de rendus et les piloter très finement dans une même application :

• Certaines pages peuvent être générées statiquement (SSG) pour des performances optimales notamment lorsqu'elles ne changent pas souvent.
• D'autres peuvent être rendu côté serveur (SSR) pour des données dynamiques (ex: espace public avec des paramètres de génération de page).
• Et certaines peuvent être rendu côté client (CSR) comme une SPA classique (ex: espace privé).

Cela offre une grande flexibilité selon les besoins de chaque route (page), tout en optimisant SEO et performances ; et kiwi sur le gâteau on peut piloter tout ceci au niveau global ou au niveau de la page elle-même pour spécifier le mode de rendu par page.

Et le SEO / référencement ?

C'est probablement la première raison pour laquelle on choisit Nuxt plutôt que Vue seul. Même si les robots de Google ont fait des progrès dans l'indexation de contenus dynamiques et de JavaScript, ils restent mou du genou pour les applications complexes avec frameworks CSR. Une page HTML rendue côté serveur — avec le contenu réel dans la source, pas en attente d'exécution — reste la solution la plus fiable et la plus prévisible.

Nuxt gère nativement, entre autres :

• La génération des balises meta (<title>, og:, twitter:, etc.) via le composable useHead ou useSeoMeta
• Le rendu du contenu dans le code HTML (indexable par les robots)
• Les sitemaps via le module @nuxtjs/sitemap
• La gestion des redirections et des codes HTTP au niveau serveur

En mode SSG, Nuxt génère des fichiers HTML statiques au build. C'est idéal pour les sites dont le contenu ne change pas en temps réel : sites vitrines, blogs, sites marketing, documentation. Les performances sont excellentes, le déploiement est trivial (un CDN suffit), et le SEO est irréprochable.

Quand choisir Vue seul ?

Vue sans Nuxt reste pertinent dans plusieurs situations :

👉 Une Single Page Application (SPA) sans contrainte SEO Interface d'administration, back-office, outil métier, application avec authentification : le contenu est derrière un login, les robots n'ont rien à crawler. Vue est suffisant, et probablement plus simple à mettre en place.

👉 Une intégration dans un projet existant Vue est conçu pour être adopté progressivement. On peut l'intégrer sur une page ou une section d'un site existant sans tout réécrire. C'est son avantage "progressif" historique.

👉 Un projet simple ou un prototype Pas besoin de la machinerie complète de Nuxt pour un composant isolé ou un outil interne léger. Vue + Vite, et on est opérationnel en quelques minutes. Le piège peut toutefois prendre forme : quand l'outil survit, grossit et qu'il faut progressivement lui ajouter des fonctionnalités on se prend à rêver de l'avoir débuté avec Nuxt (ne serait-ce que pour l'auto-import des composants).

Quand choisir Nuxt ?

👉 Un site vitrine ou institutionnel Le contenu doit être indexé, les pages doivent se charger vite, le client attend un bon référencement naturel. SSG ou SSR, Nuxt est taillé pour ça.

👉 Un site e-commerce ou une landing page produit Les Core Web Vitals impactent le ranking Google. Un bon LCP (Largest Contentful Paint) et un HTML pré-rendu font la différence. Nuxt avec SSR ou SSG coche toutes les cases.

👉 Un blog ou un site de contenu Nuxt Content est un module officiel qui transforme Nuxt en CMS headless local (fichiers Markdown, YAML, JSON). Idéal pour un blog de dev ou un site de documentation.

👉 Un projet d'équipe avec besoin de structure Le routing basé sur les fichiers, les auto-imports, les conventions de nommage... Nuxt impose une structure qui évite les débats en équipe et facilite la maintenance dans le temps.

👉 Une application hybride Certaines pages peuvent être statiques (home, blog, about), d'autres dynamiques (espace utilisateur, tableau de bord). Nuxt gère ça avec sa configuration de rendu par route (routeRules).

Nos préférences chez Alsacreations

En tant qu'agence web, nous travaillons sur des projets variés — sites vitrines et institutionnels, grand public, applications, e-commerce, etc. Outre les autres frameworks et CMS existants (WordPress, Astro), restons dans le sujet principal :

Pour les sites orientés contenu et SEO, notre choix par défaut est Nuxt. La combinaison SSG + Nuxt Content (ou un CMS headless comme Directus ou Strapi) nous donne une base solide, performante et maintenable. On voit les résultats en termes de référencement, et on évite les mauvaises surprises.

Pour les interfaces applicatives (SPA, dashboards, outils internes), Vue seul reste notre outil de prédilection. Moins de surcharge, plus de flexibilité, et une initialisation de projet plus rapide.

Dans les deux cas, nous travaillons avec la dernière version des frameworks et la Composition API. Les <script setup> et les composables ont rendu le code plus lisible et plus réutilisable, ce qui est pertinent sur des projets qui durent et qui grandissent en taille.

Nous utilisons aussi au quotidien Vite comme outil de build (commun aux deux), qui a franchement rendu le développement front beaucoup plus agréable depuis quelques années, et sa configuration beaucoup plus compacte et compréhensible qu'avec Webpack ou Gulp.

En résumé

Critère	Vue seul	Nuxt
SEO	⚠️ Limité à cause du CSR	✅ Natif (SSR/SSG)
Structure de projet	Libre ou par défaut	Fortement suggérée
Courbe d'apprentissage	Faible	Modérée
Sites vitrines	👎 Déconseillé	✅ Recommandé
Applications SPA	✅ Adapté	🆗 Possible
Déploiement statique	🆗 avec Vite	🆗 Natif (mode SSG)

Conclusion ?

Vue et Nuxt ne sont pas concurrents — Nuxt est Vue, avec des super-pouvoirs. La vraie question n'est pas "lequel est meilleur ?", mais "de quoi mon projet a-t-il besoin ?". Si vous construisez une interface applicative sans contrainte SEO : Vue suffit, et c'est très bien. Si vous construisez un site visible sur le web, destiné à être trouvé et performant : Nuxt est une solution.

Et si vous hésitez encore... la bonne nouvelle, c'est que la transition de Vue vers Nuxt est tout à fait possible. 🥁

Rebondissement ! Passer de Vue à Nuxt ?

Ce qui reste identique

La bonne nouvelle, c'est que tout ce qu'on sait faire en Vue est valide dans Nuxt.

Les composants .vue, la Composition API, les ref, les computed, les watch, Pinia 🍍 pour le state management… rien de tout ça ne change fondamentalement. On se sent à l'aise dans un projet Nuxt dès les premières heures. C'est fondamentalement la même syntaxe, quasiment la même organisation, le même écosystème, mais on va plus loin en configuration et rendu.

Ce qui change : la structure du projet

C'est le premier point d'adaptation. Un projet Vue créé avec Vite a une structure assez libre — on organise les dossiers comme on le souhaite. Nuxt, lui, impose des conventions de nommage et d'organisation qui ne sont pas négociables :

• /pages pour les pages routées automatiquement
• /components pour les composants auto-importés
• /composables pour les composables auto-importés
• /layouts pour les gabarits de page
• /middleware pour les gardes de navigation (entre autres)
• /server pour les routes et middlewares serveur (API)
• /plugins pour les plugins Vue

Ce n'est pas une contrainte... très contraignante, c'est ce qui permet à Nuxt de faire fonctionner ses rouages et automatismes (auto-imports, routing, etc.). Sur un projet Vue existant avec une arborescence personnalisée, il faudra réorganiser les fichiers selon ces conventions.

Ce qui change aussi : le routing

Dans un projet Vue, le routing est géré manuellement via Vue Router : on déclare les routes dans un fichier de configuration en JavaScript/TypeScript, on associe chaque route à un composant. C'est explicite, parfois verbeux, mais précis.

Dans Nuxt, le routing est automatique et basé sur le système de fichiers. Un fichier /pages/contact.vue génère automatiquement la route /contact. Une route dynamique comme /pages/articles/[slug].vue génère /articles/:slug. C'est très agréable une fois qu'on y est habitué, mais ça demande de repenser la façon dont on structure les pages — et de migrer les déclarations de routes existantes vers cette logique de fichiers. On peut aussi hacker le système et introduire des règles maison (comme avec Vue), pour les sites avec des pages très dynamiques où la solution de base organisée autout des dossiers ne suffit plus et où on n'envisage pas de créer des milliers de dossiers là où un pattern est bien plus concis.

Ce qui change également : la gestion du cycle de vie et du contexte

C'est probablement l'aspect le plus subtil de la transition, et le plus important à comprendre.

Dans Vue (CSR), tout le code s'exécute dans le navigateur. On peut accéder à window, document, localStorage, c'est-à-dire au DOM, sans se poser de question. Les hooks de cycle de vie comme onMounted se comportent de manière prévisible, toujours au même moment.

Dans Nuxt avec SSR, le code peut s'exécuter côté serveur ET côté client. Certains composables et certaines API navigateur n'existent tout simplement pas côté serveur puisqu'il n'y a pas de DOM. Il faut donc apprendre à distinguer ce qui doit s'exécuter où, et utiliser les utilitaires Nuxt prévus pour ça (par exemple useAsyncData, useFetch, $fetch, les hooks...).

C'est le changement le plus délicat : nul besoin de réécrire tout le code, mais il faut vérifier et parfois réécrire des portions de code de récupération de données et d'initialisation, voire l'authentification utilisateur si c'est une application concernée. Les bugs liés à ce contexte à deux têtes (serveur/client) sont aussi les plus tordus à déboguer.

Ce qui change encore : le déploiement

Un projet Vue compilé avec Vite produit des fichiers statiques (HTML, CSS, JS) qu'on peut déposer sur n'importe quel hébergement, même un simple serveur Apache ou un CDN. Très pratique.

Nuxt, selon le mode de rendu choisi, peut nécessiter un environnement Node.js en production (pour le SSR). Ce n'est pas un obstacle en 2025 — la plupart des plateformes modernes gèrent ça très bien, mais c'est une donnée à prendre en compte dès le début du projet, surtout si l'infrastructure client est contrainte.

En mode SSG pur en revanche, avec la commande generate, Nuxt génère des fichiers HTML statiques comme Vue, et le déploiement est tout aussi simple. Il vaut mieux savoir dès le début du projet quel mode de rendu on souhaite exploiter, et le tester tout au long, car changer à la fin n'est pas aisé.

La migration : approche recommandée

Il n'existe pas réellement d'outil de migration automatique entre Vue et Nuxt. Dans la pratique, on procède généralement ainsi :

1. Créer un nouveau projet Nuxt vide (ou sur le modèle proposé par défaut) et se familiariser avec sa structure
2. Migrer les composants : c'est la partie la plus simple, ils sont souvent réutilisables tels quels
3. Recréer les pages dans /pages en s'appuyant sur le routing automatique cette fois-ci
4. Adapter la récupération de données, pour être compatible avec le contexte SSR, c'est-à-dire qu'on va au-delà du simple appel à fetch ou axios
5. Migrer le state management : Pinia fonctionne dans les deux environnements, c'est une bonne nouvelle, et on peut lui adjoindre des modules qui vont permettre de conserver son contenu en sessions, ou dans localStorage par exemple
6. Vérifier les dépendances tierces : certaines librairies ne sont pas SSR-compatible, cela veut dire qu'elles comportent des bouts de code qui ne peuvent s'exécuter correctement que dans un contexte navigateur, et nécessitent un traitement particulier soit pour les adapter soit pour les exclure d'une exécution côté serveur
7. Configurer le déploiement selon le mode de rendu retenu, et si besoin trier/activer uniquement les dépendances dans certains modes (client ou serveur ou les deux)

Pour un projet Vue de taille moyenne bien structuré, une telle migration prend quelques jours à deux semaines lorsqu'on connaît bien les deux outils. Pour un projet plus conséquent ou avec beaucoup de dépendances, de requêtes vers des API, prévoir davantage de temps et de tests.

Vaut-il mieux migrer ou repartir de zéro ?

Honnêtement, cela dépend (© marque déposée) de l'état du projet existant. Si le projet Vue est bien structuré, avec des composants clairs et une logique de données propre, la migration est rentable. Si c'est un projet qui a accumulé de la dette technique, de l'historique, et dont l'architecture est difficile à démêler, la réécriture peut être l'occasion de repartir sur des bases saines et d'éliminer aussi des composants devenus inutiles.

Dans tous les cas, la transition de Vue vers Nuxt reste bien plus agréable qu'un changement de framework complet. On ne jette pas la base de code, on la réorganise et on l'adapte. C'est une évolution fluide.

Conclusion (la vraie)

Maintenant, vous savez tout.