App Router est la bonne direction. Le modèle Server Components réduit le JavaScript envoyé au client et améliore les performances de manière mesurable. Après avoir migré plusieurs projets, je ne reviendrai pas sur Pages Router. Mais la courbe d'apprentissage est réelle — j'ai cassé des choses que je ne m'attendais pas à casser.

Le modèle Server Components en pratique

La promesse de base : du code qui tourne sur le serveur, des composants légers côté client. En pratique, ça se traduit par des Core Web Vitals meilleurs, des bundles plus petits, des temps de chargement réduits. La règle fondamentale à intégrer tôt : un Server Component ne peut pas utiliser d'état React, d'effets, ou de gestionnaires d'événements.

Dès que tu as besoin de useState, useEffect, ou onClick, tu es en territoire Client Component. Ce n'est pas une limitation arbitraire — c'est le modèle de données qui change. Les Server Components s'exécutent une fois sur le serveur au moment de la requête. Les Client Components s'hydratent et vivent dans le navigateur.

Les pièges les plus fréquents

  • Event handlers dans Server Components — erreur la plus commune. Fix : extraire le composant interactif dans un fichier séparé avec "use client".
  • useEffect avec hydratation — les erreurs d'hydratation sont les plus difficiles à debugger. Elles indiquent un contenu différent entre le rendu serveur et client.
  • Layouts qui ne re-render pas — les layouts sont Server Components, ils ne répondent pas aux changements de state client.
  • cookies() et headers() dans Server Components — rendent la route dynamique. À utiliser sciemment ou la page perd son cache statique.

Stratégie de migration Pages Router → App Router

Pour migrer sans casser la production, j'ai adopté une approche progressive : créer le répertoire app/ en parallèle du pages/, migrer route par route en commençant par les pages les plus simples (statiques, sans état complexe), puis progresser vers les pages avec data fetching, puis les plus complexes.

L'erreur à éviter absolument : migrer en big bang. App Router introduit suffisamment de concepts nouveaux pour que les bugs soient difficiles à isoler si tu migres tout en même temps. Une migration route par route permet d'identifier les problèmes au fur et à mesure sans mettre en péril l'ensemble du projet.

Ce qui reste complexe en 2025

L'authentification avec sessions côté serveur reste un sujet délicat — les patterns ont évolué rapidement et la documentation officielle n'est pas toujours à jour avec les meilleures pratiques. La gestion du cache granulaire avec les options revalidate et les tags de cache demande une compréhension fine du modèle de rendu.

Les Server Actions sont puissantes pour les mutations mais leur comportement en cas d'erreur et leur interaction avec le cache nécessitent d'être testés soigneusement. Ce sont des sujets qui méritent chacun un article dédié.

Bilan honnête

App Router est supérieur sur les performances, plus complexe à maîtriser, et la bonne direction pour quiconque build du Next.js sérieusement. Si tu démarres un nouveau projet en 2025, pars directement sur App Router. La documentation s'est améliorée, l'écosystème a rattrapé. L'investissement initial en apprentissage se récupère sur le long terme en performances, en maintenabilité et en cohérence avec l'évolution du framework.