Nuxt : le framework full-stack pour Vue

Qu'est-ce que Nuxt ?

Nuxt est le framework full-stack open source construit sur Vue.js. Vue est la bibliothèque d'interface ; Nuxt ajoute ce dont une application en production a besoin autour : routage par fichiers, rendu côté serveur, génération statique, points d'accès d'API, outils de build et déploiement. Il joue pour Vue le rôle que Next.js joue pour React et SvelteKit pour Svelte.

Nuxt 4 est la version majeure stable actuelle ; elle est sortie le 15 juillet 2025. Elle repose sur Vue 3, Vite et le moteur serveur Nitro, et place le code de l'application dans le dossier app/ par défaut. Nitro peut produire un serveur Node.js ou des builds pour plusieurs plateformes d'hébergement, selon le preset choisi.

Comment fonctionne Nuxt

Une requête arrive sur un serveur Nitro. Pour une page, Nuxt rend le composant Vue en HTML côté serveur (rendu côté serveur), l'envoie, puis le navigateur en fait une application interactive par hydratation. Le même projet peut aussi prérendre des routes au build (génération de sites statiques) ou tourner comme application monopage uniquement côté client, et l'on peut mélanger route par route.

Structure du projet

my-app/
├── app/
│   ├── pages/            # file-based routing
│   │   ├── index.vue     # /
│   │   └── blog/[slug].vue  # /blog/:slug
│   ├── components/       # auto-imported
│   ├── composables/      # auto-imported
│   ├── layouts/default.vue
│   └── app.vue
├── server/
│   └── api/posts.get.ts  # GET /api/posts
├── public/
└── nuxt.config.ts

Routage et récupération de données

Chaque fichier .vue de pages/ devient une route ; [slug] crée un paramètre dynamique. Les données se chargent avec des composables qui fonctionnent côté serveur et côté client :

<script setup lang="ts">
const route = useRoute();
const { data: post } = await useFetch(`/api/posts/${route.params.slug}`);
</script>

Routes d'API serveur

Les fichiers de server/api/ deviennent des points d'accès et la méthode HTTP vient du nom du fichier (posts.get.ts, posts.post.ts, [id].delete.ts). Pour un backend classique, pas besoin d'un serveur Express séparé.

// server/api/posts/[slug].get.ts
export default defineEventHandler(async (event) => {
  const slug = getRouterParam(event, 'slug');
  const post = await db.post.findUnique({ where: { slug } });
  if (!post) throw createError({ statusCode: 404, message: 'Not found' });
  return post;
});

Modes de rendu

Nuxt rend côté serveur par défaut (rendu universel). Avec ssr: false, il rend uniquement dans le navigateur, ou l'on choisit route par route avec routeRules. Pour un site entièrement statique, nuxt generate suffit.

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },          // built once, served static
    '/dashboard/**': { ssr: false },   // client-side only
    '/blog/**': { isr: 60 }            // ISR: CDN-cached where the host supports it
  }
});

Nuxt, Next.js et SvelteKit

Les trois couvrent le même terrain ; le vrai choix est donc souvent la bibliothèque d'interface que l'équipe connaît déjà.

Erreurs fréquentes

• Utiliser $fetch pendant le rendu. Le serveur charge, le client recharge et la page clignote ou charge deux fois. Pour les données du rendu, utilisez useFetch ou useAsyncData.
• API du navigateur côté serveur. window et localStorage n'existent pas en SSR ; protégez-les ou exécutez-les dans onMounted.
• Écarts d'hydratation. Des valeurs aléatoires, des dates ou un texte dépendant de la langue qui diffèrent entre serveur et client provoquent des avertissements et du travail en plus.
• SSR sans cache sur les pages très visitées. Rendre à chaque requête consomme du CPU. Mettez en cache avec routeRules (swr, isr) ou prérendez ce qui ne change pas.

Tester la charge d'une application Nuxt

Le SSR déplace le rendu sur votre serveur : le trafic coûte donc du CPU, pas seulement de la bande passante. Testez séparément les pages rendues et les routes /api, avec une montée en charge proche du trafic réel, et suivez les percentiles plutôt que les moyennes. Les tests de charge LoadFocus exécutent des scripts JMeter et k6 depuis plus de 25 régions cloud ; pour le côté client, voir tests de charge des applications monopages.

Questions fréquentes sur Nuxt

Nuxt 4 ou Nuxt 3 ?

Démarrez les nouveaux projets sur Nuxt 4, stable depuis le 15 juillet 2025. Une application Nuxt 3 peut migrer par étapes ; l'essentiel concerne le dossier app/ et le comportement de la récupération de données, et le guide officiel de migration couvre les deux.

Nuxt ou Vue seul ?

Vue seul convient à une application monopage que vous maîtrisez de bout en bout. Choisissez Nuxt pour le rendu côté serveur, la génération statique, les pages critiques pour le SEO ou des conventions prêtes à l'emploi.

Nuxt peut-il tourner sur Cloudflare Workers ?

Oui. Nitro propose des presets Cloudflare (cloudflare_module pour Workers, cloudflare_pages pour Pages), définis avec nitro.preset ou la variable NITRO_PRESET au build.

Puis-je créer un site statique avec Nuxt ?

Oui. nuxt generate prérend les routes en fichiers statiques.

Quelle différence entre useFetch et $fetch ?

useFetch est intégré au rendu : il charge une fois côté serveur, transmet le résultat au client et le met en cache. $fetch est un appel simple sans ce traitement.

Nuxt prend-il en charge TypeScript ?

Oui, avec des types générés pour les routes et les API serveur.