Retour au blog
  • 2 min de lecture

Pourquoi migrer un site Vite/React Router vers Next.js App Router

Retour d'expérience sur la migration de ce site personnel, et les critères qui doivent guider ce choix pour un vrai projet client.

Ce site a longtemps tourné sur Vite + React Router. Une stack simple, rapide en développement, qui a rempli son rôle. Je viens de le migrer vers Next.js avec l'App Router. Voici pourquoi, et surtout : dans quels cas ça vaut le coup pour un vrai projet.

Ce que Vite/React Router ne résout pas

Une SPA classique délègue tout au navigateur : rendu, SEO, chargement des données. Pour une landing page de conseil comme celle-ci, ça veut dire un écran blanc le temps que le bundle JS charge, et un référencement qui dépend entièrement de la capacité des robots à exécuter du JavaScript.

Rien de rédhibitoire pour une petite app interne. Beaucoup plus gênant pour un site public dont l'objectif est d'être trouvé.

Ce que l'App Router apporte concrètement

  • Rendu serveur par défaut : les pages sont des Server Components, le HTML est prêt avant même que React s'hydrate côté client.
  • Metadata par route : export const metadata dans chaque page, sans bibliothèque tierce pour gérer les balises <title> et <meta>.
  • Routing par convention : un dossier blog/[slug]/page.tsx suffit, pas de fichier de configuration de routes à maintenir en parallèle de l'arborescence.
  • Rendu statique quand c'est possible : les pages sans données dynamiques sont pré-générées au build, avec les temps de réponse d'un site statique.

Ce qui ne change pas

Le choix d'une stack ne se fait jamais dans l'absolu. Pour une application très interactive, fortement authentifiée, avec peu d'enjeu SEO (un back-office, un outil interne), une SPA reste souvent le choix le plus simple : moins de concepts à maîtriser (Server vs Client Components, streaming, cache), un modèle mental plus direct.

Le critère qui tranche : est-ce que le contenu doit être visible et rapide avant que React ne prenne la main ? Si oui, Next.js App Router. Sinon, ne changez rien.

C'est exactement le type d'arbitrage que je fais avec mes clients avant de poser la première ligne de code.

Un sujet à creuser pour votre projet ?

Discutons de votre contexte technique et de vos enjeux.

Parlons de votre projet