Next.js 14 : guide complet du App Router en français
Guide complet du App Router Next.js 14 en français : layouts, server components, data fetching et déploiement.
L App Router de Next.js, introduit dans la version 13.4, represente un changement fondamental dans la facon de structurer les applications React. En s appuyant sur les React Server Components et un systeme de routage base sur les dossiers dans le repertoire app/, il remplace progressivement le Pages Router tout en offrant des performances nettement superieures grace au streaming SSR et au rendu partiel.
Contrairement au Pages Router qui utilise getServerSideProps et getStaticProps pour le data fetching, l App Router permet de faire des appels asynchrones directement dans les composants serveur avec async/await. Cette approche simplifie considerablement l architecture en eliminant la separation artificielle entre la logique de recuperation de donnees et le rendu des composants.
Ce guide couvre les concepts essentiels de l App Router : le routage par fichiers, les layouts imbriques, les Server Components et Actions, ainsi que les strategies de caching. Vous y trouverez des exemples concrets pour migrer vos projets existants et tirer parti des nouvelles fonctionnalites de Next.js 14 et 15.
1. Routage par fichiers et conventions de nommage
Le systeme de routage de l App Router repose sur une arborescence de dossiers dans app/. Chaque dossier represente un segment de route, et le fichier page.tsx a l interieur definit le composant rendu pour cette URL. Les routes dynamiques utilisent la syntaxe [param] pour les segments variables et [...slug] pour les catch-all routes.
Les fichiers speciaux comme layout.tsx, loading.tsx, error.tsx et not-found.tsx permettent de definir des comportements automatiques a chaque niveau de la hierarchie. Un layout.tsx persiste entre les navigations et ne se re-rend pas, tandis que template.tsx cree une nouvelle instance a chaque navigation, ce qui est utile pour les animations d entree.
Les Route Groups, definis avec la syntaxe (nomDuGroupe), permettent d organiser les routes sans affecter l URL. Par exemple, app/(marketing)/about/page.tsx et app/(dashboard)/settings/page.tsx partagent la meme racine mais peuvent avoir des layouts completement differents sans prefixe dans l URL.
2. Server Components et composants client
Par defaut, tous les composants dans l App Router sont des Server Components. Ils s executent uniquement cote serveur, ce qui signifie que leur code JavaScript n est jamais envoye au navigateur. Cela permet d utiliser directement des requetes Prisma, des appels fetch avec des cles API privees, ou des lectures de fichiers avec fs sans exposer de donnees sensibles.
Pour ajouter de l interactivite (useState, useEffect, onClick), il faut declarer explicitement un composant client avec la directive 'use client' en haut du fichier. La strategie recommandee consiste a garder les composants serveur au niveau le plus haut possible et a isoler l interactivite dans de petits composants client feuilles, en leur passant les donnees via props.
La frontiere entre serveur et client est traversee par la serialisation des props. Seuls les types serialisables (strings, nombres, tableaux, objets simples) peuvent passer d un Server Component a un Client Component. Les fonctions, les classes et les instances de Date ne sont pas serialisables et provoquent des erreurs a l execution.
3. Server Actions et mutations de donnees
Les Server Actions sont des fonctions asynchrones marquees avec 'use server' qui s executent exclusivement cote serveur. Elles peuvent etre definies directement dans un Server Component ou dans un fichier dedie (par exemple actions.ts). Next.js genere automatiquement un endpoint POST securise pour chaque action, permettant aux formulaires HTML natifs de les invoquer sans JavaScript cote client.
L integration avec les formulaires utilise l attribut action du tag form. Combine avec useFormStatus de react-dom pour afficher un etat de chargement et useActionState pour gerer les retours de validation, les Server Actions offrent une experience formulaire complete. La fonction revalidatePath ou revalidateTag permet de rafraichir les donnees mises en cache apres une mutation.
Pour la gestion des erreurs, les Server Actions peuvent retourner des objets structures avec des champs success et errors, que le composant client consomme pour afficher des messages de validation. L utilisation de Zod pour la validation cote serveur avec z.object().safeParse() est un pattern recommande qui garantit la securite des types tout au long du flux de donnees.
Besoin d’aide en Technologie ?
Nos experts vous accompagnent. Recevez 3 devis gratuits sous 24h.
Gratuit · Sans engagement · Reponse sous 24h
4. Data fetching et strategies de caching
Dans l App Router, le data fetching se fait directement dans les composants serveur avec fetch() ou des ORM comme Prisma. Next.js etend l API fetch native avec des options de cache : force-cache pour la mise en cache indefinie (equivalent a getStaticProps), no-store pour les donnees dynamiques a chaque requete, et next.revalidate pour l ISR avec un delai en secondes.
Le systeme de cache de Next.js opere a quatre niveaux : le Request Memoization (deduplique les fetch identiques dans un meme rendu), le Data Cache (persiste les reponses fetch entre les requetes), le Full Route Cache (met en cache le HTML et le RSC payload des routes statiques) et le Router Cache (cache cote client les segments visites). Comprendre ces couches est essentiel pour eviter les bugs de donnees obsoletes.
Pour les cas ou fetch n est pas applicable (appels a une base de donnees via Prisma, requetes a des API internes), la fonction unstable_cache de next/cache permet de wrapper n importe quelle fonction asynchrone avec un comportement de cache configurable. Les tags de cache combines avec revalidateTag offrent une invalidation granulaire sans revalider des pages entieres.
5. Middleware et optimisation des performances
Le fichier middleware.ts a la racine du projet intercepte chaque requete avant le routage. Il s execute dans le Edge Runtime, ce qui le rend extremement rapide mais limite aux API Web standards (pas d acces a fs ou aux modules Node natifs). Les cas d usage principaux incluent la redirection basee sur la geolocalisation, l authentification avec NextAuth.js, et la reecriture d URL pour l A/B testing.
L optimisation des performances dans l App Router repose sur le composant Image de next/image pour le lazy loading et le redimensionnement automatique, le composant Script de next/script pour le chargement differe des scripts tiers, et les metadata exports pour le SEO. La fonction generateStaticParams permet de pre-rendre les routes dynamiques au build time, combinant les avantages du SSG avec la flexibilite du routage dynamique.
Le Parallel Routes (avec la syntaxe @slot) et les Intercepting Routes (avec (..) ou (...)) permettent des patterns UI avances comme les modales avec URL propre ou les dashboards avec panneaux independants. Ces fonctionnalites permettent de charger simultanement plusieurs segments de page, avec des etats de chargement et d erreur independants pour chaque slot.
Questions frequentes
Quelle est la difference entre l App Router et le Pages Router de Next.js ?
L App Router utilise le repertoire app/ avec les React Server Components par defaut, des layouts imbriques persistants et un data fetching integre aux composants. Le Pages Router utilise le repertoire pages/ avec getServerSideProps/getStaticProps et des composants entierement client. L App Router offre de meilleures performances grace au streaming SSR et au rendu partiel.
Peut-on utiliser l App Router et le Pages Router dans le meme projet ?
Oui, Next.js supporte la coexistence des deux routeurs pendant la migration. Les routes dans app/ prennent priorite sur celles dans pages/ en cas de conflit. Il est recommande de migrer progressivement en commencant par les nouvelles pages et en convertissant les anciennes au fur et a mesure.
Comment gerer l authentification avec l App Router ?
La solution recommandee est NextAuth.js v5 (Auth.js) qui supporte nativement l App Router. L authentification se verifie dans le middleware.ts pour les redirections, dans les layouts serveur pour le rendu conditionnel, et dans les Server Actions pour la protection des mutations. La session est accessible via la fonction auth() cote serveur.
Les Server Components sont-ils compatibles avec toutes les librairies React ?
Non, les librairies qui utilisent des hooks React (useState, useEffect, useContext) ou des API navigateur ne fonctionnent pas dans les Server Components. Il faut les encapsuler dans des composants client avec la directive 'use client'. Les librairies de styling comme styled-components necessitent une configuration specifique pour le SSR.
Comment optimiser le build time avec generateStaticParams ?
La fonction generateStaticParams retourne un tableau de parametres pour pre-rendre les routes dynamiques au build time. Pour les grands catalogues, generez uniquement les pages les plus visitees et laissez les autres se generer a la demande avec dynamicParams: true. Utilisez le mode ISR avec revalidate pour mettre a jour les pages statiques sans rebuild complet.
Guides complementaires
Tailwind CSS : guide complet et bonnes pratiques 2025
Guide complet Tailwind CSS : configuration, responsive design, dark mode, composants réutilisables et bonnes pratiques.
TechnologieAPI REST vs GraphQL : quel choix pour votre projet
Comparatif détaillé REST vs GraphQL : performances, flexibilité, sécurité et cas d'usage pour choisir votre API.
TechnologieTypeScript : du débutant au professionnel
Guide progressif TypeScript : des types basiques aux generics avancés, avec exemples concrets et bonnes pratiques.
Outils gratuits recommandes
Lancez votre projet technologie
500+ experts verifies prets a vous accompagner. Devis gratuit sous 24h.