Pourquoi nous avons choisi Nuxt 4 pour nos produits IA en 2026

Le pitch honnête

La plupart des articles "comparatif de frameworks" sont écrits par les mainteneurs du framework en question, ou par des équipes qui n'ont livré qu'un seul projet. Celui-ci est écrit après avoir mis en production un portefeuille de produits IA sur 24 mois, avec une équipe de 3 à 5 ingénieurs, sur une stack que nous avons choisie, cassée, réparée, et conservée.

Conclusion : nous livrons sur Nuxt 4 + Fastify + MongoDB. Ce qui est intéressant, c'est le pourquoi — et là où cette stack montre ses limites.

Ce dont nous avions besoin

Sur l'ensemble de notre portefeuille — agents vocaux, plateformes RAG, moteurs fintech, IA civique, web immersif, SaaS multi-tenant — les exigences techniques ont convergé :

• Server-side rendering pour le SEO (nous vivons du trafic organique)
• Itération rapide (les clients veulent des démos en jours, pas en semaines)
• Multi-tenancy intégré (la plupart de nos produits servent plusieurs organisations)
• Streaming temps réel (tokens LLM, transcriptions vocales, données de marché)
• i18n (français + anglais au minimum, parfois plus)
• Interactivité poussée (scènes 3D, WebRTC, formulaires complexes, dashboards)
• DX saine (nous sommes une petite équipe — chaque heure de friction est chère)

En dessous de ce seuil, nous aurions été ralentis ou le produit en aurait pâti.

La liste courte

En 2026, les options réalistes pour notre profil sont :

• Next.js 15 (App Router)
• Nuxt 4
• SvelteKit 2
• Astro 5 (avec islands)
• Remix / React Router 7

Nous avons utilisé quatre d'entre eux en production. Astro a été testé pour un site de contenu ; les autres, nous avons livré de vrais produits avec. Voici la comparaison qui compte vraiment dans les tranchées.

Ce que Nuxt 4 réussit

Les auto-imports — le game-changer sous-estimé

On ne réalise pas à quel point on passe du temps à importer des choses… avant qu'on arrête de le faire. Nuxt auto-importe ref, computed, useFetch, useState, chaque composant, chaque composable, chaque store Pinia. Nous avons mesuré : sur notre équipe, cela économise ~3 % du temps et réduit ~25 % des conflits de merge.

Next.js n'a rien d'équivalent. SvelteKit a les runes (problème différent). Astro n'auto-importe pas.

Le routage par fichiers qui passe à l'échelle

pages/projects/[slug].vue → /projects/<slug>. Layouts imbriqués. Routes catch-all ([...slug].vue). Paramètres dynamiques avec inférence TypeScript correcte. Nous avons migré /projects.vue vers /projects/index.vue + /projects/[slug].vue en 30 secondes — sans toucher à une seule config de routeur.

useFetch / useAsyncData sont discrètement parfaits

Fetch côté serveur au premier rendu, mis en cache pour l'hydration, dédupliqué entre les composants, avec paramètres réactifs et support de watchEffect. Le jour où nous avons porté un projet Next.js vers Nuxt, notre data fetching piloté par useEffect a réduit de 60 %.

L'écosystème de modules est mature

Sur notre portefeuille, nous nous sommes appuyés sur (par ordre d'usage) :

• @nuxtjs/i18n — routage multi-locale complet, hreflang, traductions lazy
• @nuxt/image — optimisation d'images, AVIF/WebP, responsive
• @nuxt/content — collections markdown (celui qui fait tourner ce blog)
• @nuxtjs/seo — schema.org, sitemap, robots, images OG en un seul module
• @vueuse/nuxt — 150+ composables auto-importés
• @nuxt/icon — accès Iconify, bundle serveur pour la production
• nuxt-security — CSP, HSTS, permissions-policy out of the box
• @vite-pwa/nuxt — manifest PWA + Workbox

Sous Next.js, vous assembleriez la moitié de ces fonctionnalités depuis npm et écririez des configs. Sous Nuxt, ce sont des modules avec des valeurs par défaut sensées.

Support de la View Transitions API

experimental.viewTransition: true dans la config et vous obtenez la View Transitions API native sur les changements de route — pas de bibliothèque, pas d'overhead JS, dégradation gracieuse sur les anciens navigateurs. Nous l'utilisons sur /projects ↔ /projects/[slug] pour l'effet de morphing carte-vers-détail.

SSR + SPA + SSG + ISR dans une seule config

routeRules: { '/blog/**': { isr: 3600 } } — directement ISR. Besoin d'une route en SPA uniquement ? { '/dashboard/**': { ssr: false } }. Statique ? { prerender: true }. Une config, un seul modèle mental.

Là où Nuxt 4 montre ses limites

Nous ne sommes pas des fanatiques. Les points de douleur :

Les temps de build s'allongent

Build de production d'une application moyenne (50 composants, 8 pages, 10 modules) : ~45–90 s côté client, ~15–25 s côté serveur. Plus long que souhaité. Vite est rapide, mais le pipeline de modules Nuxt ajoute du overhead. SvelteKit est plus rapide sur les petits projets (mais plus lent sur les grands, dans notre expérience).

Les types TypeScript se régénèrent lentement

Après l'ajout d'un nouveau module ou le déplacement d'une page, nuxt prepare prend 5–15 s pour régénérer les types. En développement chaud c'est invisible (HMR), mais quand vous faites pnpm install ou un rebase, cela ajoute de la friction.

Un écosystème Vue moins large que React

Si vous avez besoin d'une bibliothèque UI de niche (arbre complexe, gantt, kanban), l'équivalent React existe souvent et est meilleur. Nous avons parfois dû construire de petites primitives nous-mêmes plutôt que d'importer un portage Vue à moitié maintenu.

Les modes client-only peuvent être délicats

Pour les scènes Three.js, le WebRTC ElevenLabs, tout ce qui touche window/document — vous avez besoin de wrappers <ClientOnly>. La plupart du temps c'est correct ; de temps en temps vous vous battez avec des avertissements d'Hydration mismatch jusqu'à identifier quel sous-arbre est rendu côté serveur.

Pourquoi pas Next.js 15

Nous avons livré sous Next.js. L'App Router a mûri. Alors pourquoi n'y sommes-nous pas ?

• Les React Server Components sont puissants, mais le modèle mental est plus lourd. Pour une équipe de 4 personnes qui livre des projets variés, le surcoût de "est-ce un composant serveur ou client, et qu'est-ce que ça implique pour l'état, les hooks, le fetching" nous ralentit.
• Pas d'auto-import. Les imports s'accumulent.
• Pas d'équivalent à useFetch avec cache intégré, déduplication et couplage SSR — vous l'assemblez avec fetch + Suspense + RSC + une bibliothèque tierce.
• La directive 'use client' est un piège à bugs d'hydration.
• Le delta de DX ne justifie pas le coût de reformation de l'équipe sur chaque projet.

Next.js gagne quand vous avez une grande équipe déjà profondément ancrée dans React, quand vous avez besoin des avantages spécifiques des RSC (bundle plus compact sur une interactivité dense), ou quand votre hébergement est exclusivement Vercel et que vous voulez exploiter chaque fonctionnalité edge. Pour une petite agence IA, Nuxt est plus rapide à livrer.

Pourquoi pas SvelteKit

SvelteKit est vraiment élégant. Nous avons livré un produit dessus. Trois raisons pour lesquelles nous n'en avons pas fait notre standard :

1. Churn de l'API Runes : le passage des stores aux runes était la bonne décision, mais cela a cassé nos réflexes. La Composition API Vue 3 est stable depuis plus de 3 ans.
2. Écosystème plus restreint : moins de modules, couverture bibliothèque moindre.
3. L'inférence TS dans les templates est bonne, mais pas aussi éprouvée en production que vue-tsc + Volar côté Vue.

SvelteKit est plus rapide sur les petites applications et produit des bundles plus légers. Si nous faisions un produit unique en startup, nous le considérerions sérieusement. Pour une agence qui livre plusieurs produits, la richesse de Nuxt l'emporte.

Pourquoi pas Astro

Astro est le meilleur framework pour sites de contenu en 2026. Pour un site marketing à interactivité légère, difficile de faire mieux. Mais nos produits sont des applications, pas des sites de contenu. Ce sont des dashboards SaaS, des agents vocaux, des interfaces fintech temps réel. L'architecture islands d'Astro commence à vous résister quand 80 % de la page est interactive.

Nous appliquons maintenant les patterns Astro (statique + islands) à l'intérieur de Nuxt pour nos pages marketing. Le meilleur des deux mondes.

La stack complète que nous livrons

Pour un produit IA typique en 2026 :

Frontend
├── Nuxt 4 (SSR + SPA hybrid)
├── Vue 3 Composition API
├── Tailwind CSS v4 (with custom @theme tokens)
├── @vueuse/motion for declarative animations
├── @nuxt/icon (Lucide as default set)
└── @nuxtjs/i18n with prefix_except_default

Backend
├── Fastify (default for new services)
├── Express (legacy services we still run — gateways and socket layers)
├── MongoDB + Mongoose (always — relational AND vector, see below)
├── Redis via ioredis (rate limiting, sessions, BullMQ backend, anti-pyramide locks)
├── BullMQ (background jobs)
└── Pino for structured logging

AI Layer (routing per use-case, not a single default)
├── ElevenLabs Conversational AI for voice (STT + LLM-in-loop + TTS + turn-taking, with dynamic webhook tools)
├── Anthropic Claude — Sonnet 4.6 for user-facing chats and forced-tool-calling triage; Haiku 4.5 for classifiers and safety re-checks; Opus 4.7 via claude-agent-sdk for long-running domain agents (ops bots, autonomous loops)
├── Google Gemini 3 Pro for batch analytics, vision (high media_resolution), and narrative generation with thinking_level
├── Mistral for OCR (Pixtral batch) and STT (Voxtral); also as a fallback in declarative routing
├── OpenAI (GPT-4o family) as alternative / fallback per use-case
└── Orchestration: plain Anthropic Messages API forced-tool-calling for synchronous chat; @anthropic-ai/claude-agent-sdk with MCP for long-running agents. No LangGraph agentic orchestration in production — LangChain only used for text splitting in one narrative-engine product, not for chains.

Vector & retrieval
├── MongoDB Atlas $vectorSearch on structured feature vectors (e.g. matching candidate records on cancellation) — already running, not RAG
├── Pinecone + LangChain when the corpus is genuinely textual and large (long-form narrative engines, content-heavy knowledge bases)
└── For most products: no RAG at all — agentic + tool calls on MongoDB beats vector retrieval over fragmented text when the data is relational

Infra
├── Vercel (Nuxt frontend) and DigitalOcean (full-stack backends)
├── AWS S3 (object storage, presigned uploads)
├── Twilio (telephony when voice is involved)
├── PostHog (product analytics + replay + LLM events: ai_call, mission_ai_decision)
└── Sentry (error tracking)

Nous disposons d'un template de démarrage qui inclut tout cela avec auth, billing, multi-tenancy, observabilité, i18n et panneau d'administration pré-câblés. Mise en place d'un nouveau produit : 2 jours au lieu de 2 semaines.

Quand nous choisirions autre chose

• Site marketing pur, riche en contenu : Astro
• 3D / WebGL intensifs avec investissement dans l'écosystème React Three Fiber : Next.js ou Vite + React
• Application mobile native livrée en parallèle : React Native + Next.js codebase partagée
• Mega-application mono-équipe, architecture compatible RSC : Next.js 15

Mais pour des produits IA qui ont besoin de SEO, d'itération rapide, de multi-tenancy, de temps réel et d'i18n — Nuxt 4 gagne pour nous, à chaque fois.

Pour conclure

Le bon framework, c'est celui avec lequel votre équipe peut livrer. Nous sommes arrivés à Nuxt 4 en ayant essayé les autres et en observant où nous nous bloquions. La stack est réversible — si Vue 4 est un désastre, nous porterons. En attendant, Nuxt 4 est notre choix par défaut et nous le recommandons aux clients qui n'ont pas de raison impérieuse d'être ailleurs.

Besoin d'aide pour livrer un produit sur cette stack ? Parlons-en. Nous avons déjà fait les erreurs d'architecture ; inutile de les répéter.