Nehos Groupe
Définition & Concepts

App Router Next.js

Version Décideur

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.

Version Expert

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.

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

Contexte : 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."

Contexte : 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."

Contexte : 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."

Questions & Réponses

Questions fréquentes sur l'App Router Next.js

Pages Router (dossier /pages/) : composants React Client par défaut, getServerSideProps/getStaticProps pour les données, pas de layouts imbriqués natifs. App Router (dossier /app/) : composants React Server Components par défaut, fetch côté serveur directement dans les composants, layouts imbriqués persistants natifs, Server Actions, loading/error/not-found déclaratifs. En pratique : App Router réduit le JavaScript envoyé au client, améliore les Core Web Vitals et simplifie la gestion des layouts complexes. Migration progressive possible : les deux dossiers coexistent dans la même application.
Pas d'urgence si votre Pages Router fonctionne bien. Recommandation Nehos : nouveaux projets = 100 % App Router depuis Next.js 14. Projets existants = migration progressive lors d'une refonte ou d'un ajout de fonctionnalité majeure. L'équipe Vercel maintient le Pages Router sans date de dépréciation annoncée. La stratégie de coexistence (pages + app en parallèle) est stable et documentée. Ne migrez pas pour migrer — migrez si vous avez un objectif mesurable (performance, architecture, maintenabilité).
Un React Server Component (RSC) est un composant qui s'exécute exclusivement côté serveur. Il n'est jamais envoyé au navigateur du visiteur. Avantages : accès direct aux bases de données, fichiers, variables d'environnement secrètes — sans API Route intermédiaire. Pas de JavaScript ajouté au bundle client. Rendu HTML direct envoyé au navigateur. Dans l'App Router, tous les composants sont des RSC par défaut. Pour rendre un composant interactif (useState, useEffect, événements), vous ajoutez 'use client' en tête de fichier. La règle Nehos : mettre 'use client' le plus bas possible dans l'arbre de composants.
Next.js supporte officiellement les deux dossiers (/pages/ et /app/) dans la même application. Les routes de /app/ ont la priorité sur /pages/ en cas de conflit. La coexistence permet une migration progressive route par route, sans casser l'existant. Les composants du Pages Router ne peuvent pas importer des RSC du App Router. Les layouts, contextes et états ne se partagent pas entre les deux systèmes. Nehos migre les nouvelles pages et fonctionnalités vers /app/ en premier, puis les pages à fort trafic, puis le reste sur plusieurs sprints.
Les Server Actions sont des fonctions asynchrones marquées 'use server' qui s'exécutent côté serveur lors d'une soumission de formulaire ou d'un appel explicite. Elles remplacent dans la majorité des cas la création d'une API Route dédiée. Avantages : code réduit (une fonction vs un endpoint + un fetch), formulaires progressifs (fonctionnent sans JavaScript client activé), revalidation de cache intégrée (revalidatePath, revalidateTag). Utilisation typique Nehos : mutations base de données (création lead, mise à jour profil), soumissions formulaires de contact, actions d'administration CMS.
Oui, et c'est même la stack officielle Payload 3.0. Depuis Payload CMS 3.0 (2024), Payload s'installe directement dans une application Next.js App Router — même processus Node.js, même monorepo. Le panneau d'administration Payload tourne dans /app/(payload)/, vos pages marketing dans /app/(site)/. C'est la stack standard Nehos depuis 2025 : Payload 3.0 + Next.js 15-16 App Router + TypeScript + Tailwind + déploiement OVHcloud. Résultat : un seul dépôt, un seul déploiement, zéro latence réseau entre CMS et frontend.
Positivement, si utilisé correctement. Trois mécanismes : (1) RSC réduit le bundle JavaScript client, ce qui améliore INP et FID, (2) streaming SSR avec Suspense boundaries améliore le TTFB perçu et le LCP, (3) layouts imbriqués persistants éliminent les re-renders inutiles lors des navigations. Nos métriques sur 8 projets migrés Pages → App Router : bundle JS initial -38 à -62 %, TTFB -40 % en moyenne, Lighthouse Performance +15 à +28 points. Attention : un mauvais usage de 'use client' (trop haut dans l'arbre) annule tous ces gains.
Réserver un audit