Next.js 15 : App Router et Server Components expliqués simplement

Depuis l’introduction de l’App Router, Next.js ne se contente plus d’ajouter du routing par-dessus React : il change où et quand le code s’exécute. Comprendre la différence entre Server Components et Client Components est devenu la base pour structurer correctement une application Next.js 15. Voici une explication concrète, sans jargon inutile.

Sommaire

1. App Router vs Pages Router
2. Que sont les Server Components
3. Quand utiliser « use client »
4. Récupération de données côté serveur
5. Streaming et Suspense
6. Pièges fréquents

App Router vs Pages Router

L’App Router (dossier app/) coexiste avec l’ancien Pages Router (dossier pages/) mais repose sur un modèle fondamentalement différent : le routing par système de fichiers reste, mais chaque segment de route peut désormais imbriquer des layouts, du chargement progressif et une gestion d’erreur dédiée via des fichiers conventionnels (layout.tsx, loading.tsx, error.tsx). Pour un nouveau projet, l’App Router est aujourd’hui le choix par défaut recommandé par Next.js.

Que sont les Server Components

Dans l’App Router, tout composant est un Server Component par défaut : il s’exécute uniquement sur le serveur, son code n’est jamais envoyé au navigateur, et il peut accéder directement à une base de données, au système de fichiers ou à des variables d’environnement secrètes sans passer par une API intermédiaire. Le résultat est un HTML déjà rendu, plus léger côté client, avec moins de JavaScript à télécharger et exécuter.

Quand utiliser « use client »

Un composant devient un Client Component dès qu’il déclare la directive "use client" en tête de fichier. C’est nécessaire dès qu’il utilise des hooks React (useState, useEffect), des écouteurs d’événements (onClick), ou des API du navigateur. La bonne pratique consiste à garder ces composants aussi petits et profonds que possible dans l’arbre — un bouton interactif isolé, pas toute une page — pour maximiser la part du rendu qui reste côté serveur.

Récupération de données côté serveur

Un Server Component peut être une fonction async qui appelle directement une base de données ou une API, sans passer par useEffect ni par un client de requêtes côté navigateur. Next.js étend également la fonction fetch native avec un cache et une revalidation configurables (next: { revalidate: N }), ce qui remplace la plupart des besoins qui nécessitaient auparavant une bibliothèque de gestion de cache dédiée pour de simples lectures.

Streaming et Suspense

L’App Router permet de streamer le HTML au fur et à mesure qu’il est prêt, plutôt que d’attendre que toute la page ait fini de charger ses données. En enveloppant une section lente dans un composant <Suspense> avec un loading.tsx ou un fallback dédié, la page principale s’affiche immédiatement pendant que les sections plus lentes (un appel API tiers, une requête complexe) apparaissent progressivement. L’utilisateur voit du contenu utile plus tôt, sans page blanche en attente du chargement complet.

Pièges fréquents

Les erreurs les plus courantes : ajouter "use client" par réflexe en tête de fichier, ce qui pousse la directive en cascade à tous les composants enfants importés et annule les bénéfices du rendu serveur ; oublier qu’un Server Component ne peut pas utiliser de hooks ni recevoir de fonctions callback depuis un Client Component parent (seules les props sérialisables passent la frontière) ; et confondre le cache de fetch avec un cache applicatif classique, alors que sa portée et sa durée de vie sont spécifiques à Next.js.

Chez Any In IT, nous développons des applications Next.js pour nos clients en tirant parti des Server Components pour réduire le JavaScript envoyé au navigateur et améliorer les temps de chargement perçus.