App Router
Définition
Nouveau système de routing de Next.js basé sur des dossiers, avec Server Components, layouts imbriqués et Server Actions. Remplace le Pages Router historique sur tous nos nouveaux projets.
Comment ça marche
L'App Router est le système de routing introduit dans Next.js 13. Chaque dossier sous app/ correspond à un segment d'URL, et un fichier page.tsx rend la page de ce segment. Les layouts (layout.tsx) sont imbriqués naturellement : un layout par dossier, hérité dans les sous-routes, ce qui permet de partager une nav, un header, une sidebar sans répétition. Les segments dynamiques se déclarent avec des crochets : app/articles/[slug]/page.tsx. Le routage est entièrement basé sur le système de fichiers, sans configuration séparée à maintenir.
Server Components par défaut
Tous les composants de l'App Router sont des Server Components par défaut, sauf déclaration explicite de "use client". Cela change la philosophie de Next.js : on rend le maximum côté serveur, on n'envoie au client que les portions réellement interactives. Le bundle JavaScript diminue, le LCP s'améliore, et les requêtes base de données vivent directement dans le composant sans passer par une route API séparée. Le réflexe : commencer chaque composant en serveur, et basculer en client uniquement quand on a besoin d'un hook React ou d'un event handler.
Les fichiers spéciaux
L'App Router expose plusieurs fichiers conventionnés par segment : page.tsx (la page), layout.tsx (le layout), loading.tsx (état de chargement affiché pendant le streaming), error.tsx (page d'erreur), not-found.tsx (404 dédié), route.ts (handler d'API REST). Chaque fichier prend automatiquement effet sur son segment et ses descendants. Le système est moins explicite qu'une configuration React Router, mais il rend chaque segment autonome et facile à raisonner. La courbe d'apprentissage tient en quelques heures pour qui connaît déjà React.
Server Actions et mutations
L'App Router introduit les Server Actions : des fonctions asynchrones marquées "use server" qu'on appelle directement depuis un composant client ou un formulaire. Plus besoin de monter une route API pour chaque mutation simple. Le framework gère la sérialisation, le transport HTTP, l'exécution serveur et la revalidation des caches. Combiné à revalidatePath et revalidateTag, on bâtit des UI qui se mettent à jour automatiquement après une mutation, sans gestion d'état manuelle côté client. C'est l'une des évolutions les plus marquantes du framework.
Streaming et Suspense
L'App Router stream la réponse HTML par défaut : le serveur envoie la coquille de la page immédiatement, puis pousse chaque section au fur et à mesure que ses données arrivent. On l'orchestre avec React Suspense et des fichiers loading.tsx par segment. Un dashboard avec cinq widgets indépendants ne bloque plus sur le widget le plus lent : chacun apparaît dès que prêt. Le résultat : une expérience perçue radicalement meilleure que l'attente totale du rendu, surtout sur les pages qui agrègent plusieurs sources de données.
Migration depuis Pages Router
L'App Router remplace progressivement le Pages Router historique de Next.js. Tous les nouveaux projets démarrent dessus, et Vercel investit l'essentiel de ses efforts produit sur ce système. La migration d'un projet existant peut se faire route par route : les deux systèmes cohabitent dans le même projet, on bascule un segment à la fois. Pour un projet de taille moyenne, la migration prend quelques semaines en étalant l'effort entre nouveaux développements. Pour les très gros projets avec patterns custom complexes, on planifie une bascule progressive sur plusieurs mois.
Les pièges à éviter
Trois pièges sur l'App Router. Le premier : ajouter "use client" trop haut dans l'arbre par habitude, ce qui annule les bénéfices serveur sur tous les enfants. Le deuxième : confondre les caches (cache de fetch, cache de Data Cache, cache HTTP, ISR), qui ont chacun leurs règles d'invalidation. Le troisième : oublier que les composants serveur ne peuvent pas utiliser de hooks ni d'event handlers, ce qui force à découper la frontière proprement. La règle pratique : un Client Component doit être aussi petit que possible, idéalement une feuille.