App Router Next.js
L'essentiel
Imagine un plan de ton site web dessiné directement dans l'arborescence de tes dossiers. Dossier /app/blog/[slug]/ = URL /blog/mon-article. C'est l'idée du routing par dossiers dans Next.js. La grande nouveauté de l'App Router, c'est que par défaut, tes composants React s'exécutent côté serveur — ils ne sont pas envoyés au navigateur du visiteur. Concrètement : moins de JavaScript, pages qui s'affichent plus vite, meilleur SEO. L'ancien système (Pages Router, dossier /pages/) envoyait tout au navigateur par défaut. L'App Router inverse la logique : serveur par défaut, client uniquement quand tu en as besoin (bouton cliquable, animation, état local). Les layouts imbriqués, c'est comme des 'cadres' qui restent fixes quand tu navigues — la barre de navigation ne se recharge pas à chaque clic. Et les Server Actions ? Des fonctions qui s'exécutent côté serveur quand l'utilisateur soumet un formulaire, sans que tu aies besoin de créer une API séparée.
Détails Techniques
L'App Router Next.js est un système de routing basé sur le système de fichiers, introduit dans Next.js 13 et stabilisé dans Next.js 14+. Il repose sur le dossier /app/ et intègre nativement les React Server Components (RSC), permettant une exécution côté serveur par défaut. Chaque fichier page.tsx, layout.tsx, loading.tsx, error.tsx, not-found.tsx, template.tsx joue un rôle déclaratif précis dans l'arbre de rendu. Les layouts imbriqués persistent entre les navigations sans re-render du sous-arbre parent, éliminant les problèmes classiques de double fetch. Les Parallel Routes (slot @folder) permettent d'afficher plusieurs pages dans un même layout simultanément. Les Intercepting Routes ((.)folder remplacent une route dans le contexte de navigation courant. Les Server Actions (directive 'use server') permettent des mutations de données avec formulaires progressifs sans créer d'API Route. Les Route Handlers (route.ts) remplacent les API Routes du Pages Router. Le streaming SSR (Suspense boundaries) avec les React Server Components permet un affichage progressif des sections de page, améliorant le TTFB perçu.
#Définition App Router Next.js
L'App Router Next.js est un système de routing basé sur le système de fichiers, introduit dans Next.js 13 et stabilisé dans Next.js 14+. Il repose sur le dossier /app/ et intègre nativement les React Server Components (RSC), permettant une exécution côté serveur par défaut. Pour approfondir, consultez la page service Development Next.js Nehos.
Du point de vue technique, Chaque fichier page.tsx, layout.tsx, loading.tsx, error.tsx, not-found.tsx, template.tsx joue un rôle déclaratif précis dans l'arbre de rendu. Les layouts imbriqués persistent entre les navigations sans re-render du sous-arbre parent, éliminant les problèmes classiques de double fetch. Les Parallel Routes (slot @folder) permettent d'afficher plusieurs pages dans un même layout simultanément. Les Intercepting Routes ((.)folder remplacent une route dans le contexte de navigation courant. Les Server Actions (directive 'use server') permettent des mutations de données avec formulaires progressifs sans créer d'API Route. Les Route Handlers (route.ts) remplacent les API Routes du Pages Router. Le streaming SSR (Suspense boundaries) avec les React Server Components permet un affichage progressif des sections de page, améliorant le TTFB perçu.
On voit trop de projets échouer par méconnaissance de App Router Next.js. La théorie compte — mais la mise en pratique encore plus.
#App Router Next.js expliqué simplement
Imagine un plan de ton site web dessiné directement dans l'arborescence de tes dossiers. Dossier /app/blog/[slug]/ = URL /blog/mon-article. C'est l'idée du routing par dossiers dans Next.js. La grande nouveauté de l'App Router, c'est que par défaut, tes composants React s'exécutent côté serveur — ils ne sont pas envoyés au navigateur du visiteur. Concrètement : moins de JavaScript, pages qui s'affichent plus vite, meilleur SEO. L'ancien système (Pages Router, dossier /pages/) envoyait tout au navigateur par défaut. L'App Router inverse la logique : serveur par défaut, client uniquement quand tu en as besoin (bouton cliquable, animation, état local). Les layouts imbriqués, c'est comme des 'cadres' qui restent fixes quand tu navigues — la barre de navigation ne se recharge pas à chaque clic. Et les Server Actions ? Des fonctions qui s'exécutent côté serveur quand l'utilisateur soumet un formulaire, sans que tu aies besoin de créer une API séparée.
Visualisez le quotidien d'un directeur technique ou d'un CMO en scale-up. C'est la réalité du terrain — loin des définitions académiques.
#Cas d'usage concrets
Refonte site corporate B2B SaaS (Pages Router → App Router, Next.js 15) — Migration progressive d'un site corporate 120 pages de Pages Router vers App Router sur 10 semaines. Coexistence /pages/ + /app/ pendant toute la durée. Bundle JS initial réduit de 54 %. TTFB passé de 310 ms à 130 ms grâce au streaming RSC. Score Lighthouse performance de 61 à 94. Zero downtime pendant la migration grâce à la coexistence officielle.
Plateforme e-learning avec contenu dynamique et authentification (App Router + Server Actions) — Application Next.js 15 100 % App Router avec Server Actions pour toutes les mutations (inscription cours, progression, commentaires). Suppression de 14 API Routes du projet. Code réduit de 22 %. Formulaires progressifs fonctionnels même sans JavaScript activé côté client. Authentification via middleware Next.js + cookies httpOnly, zéro token exposé côté client.
Site marketing headless CMS Payload 3.0 + Next.js 16 App Router (Nehos stack 2026) — Stack Nehos standard 2026 : Payload CMS 3.0 (Next.js natif, monorepo) + App Router + Partial Prerendering (PPR) + ISR à 60 s sur pages produit. 3 400 pages générées. Temps de build : 4 min 20 s. LCP median 1,1 s. INP <80 ms. Déploiement OVHcloud Managed Kubernetes.
#App Router Next.js chez Nehos Groupe
On connaît les limites autant que les forces de cette technologie. Sur les 3 derniers projets impliquant App Router Next.js, on a documenté les résultats avec des KPIs précis. Notre service Development Next.js Nehos couvre ce périmètre de A à Z.
La méthode Nehos est documentée sur stack Next.js + Payload CMS Nehos™. Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. Les résultats mesurés sur nos clients : 15 100 % est un ordre de grandeur courant. On livre, on mesure, on itère. Pas de slides sans livrable.
#Termes associés
Ce terme s'inscrit dans un écosystème plus large.
- Next.js
- React Server Components
- Partial Prerendering (PPR)
- TypeScript
- Payload CMS
- ISR (Incremental Static Regeneration)
- Jamstack
Chaque terme est défini dans notre glossaire avec la même approche : définition technique, vulgarisation, cas concrets et méthode Nehos.
Applications Concrètes
"Migration progressive d'un site corporate 120 pages de Pages Router vers App Router sur 10 semaines. Coexistence /pages/ + /app/ pendant toute la durée. Bundle JS initial réduit de 54 %. TTFB passé de 310 ms à 130 ms grâce au streaming RSC. Score Lighthouse performance de 61 à 94. Zero downtime pendant la migration grâce à la coexistence officielle."
"Application Next.js 15 100 % App Router avec Server Actions pour toutes les mutations (inscription cours, progression, commentaires). Suppression de 14 API Routes du projet. Code réduit de 22 %. Formulaires progressifs fonctionnels même sans JavaScript activé côté client. Authentification via middleware Next.js + cookies httpOnly, zéro token exposé côté client."
"Stack Nehos standard 2026 : Payload CMS 3.0 (Next.js natif, monorepo) + App Router + Partial Prerendering (PPR) + ISR à 60 s sur pages produit. 3 400 pages générées. Temps de build : 4 min 20 s. LCP median 1,1 s. INP <80 ms. Déploiement OVHcloud Managed Kubernetes."