Pendant longtemps, la transition entre le Pages Router et l'App Router a divisé la communauté. C'était "instable", "complexe", "mal documenté". C'était vrai en 2023. Mais nous sommes en 2026. Aujourd'hui, lancer un nouveau projet avec le Pages Router est une erreur d'architecture fondamentale.

Ce n'est pas seulement une mise à jour de routing. C'est un changement complet du modèle mental de React. Voici pourquoi l'App Router est le seul choix viable pour une ingénierie moderne, et pourquoi le Pages Router est officiellement de la "Dette Technique Legacy".

La fin du "Waterflow" (Adieu `getServerSideProps`)

Le défaut structurel du Pages Router était la séparation forcée entre la donnée (getServerSideProps) et l'UI (le composant Page). Cela créait un goulot d'étranglement : la page ne pouvait pas commencer à s'afficher tant que toutes les données n'étaient pas chargées.

L'App Router, avec les React Server Components (RSC), permet de colocaliser la donnée et le composant. Vous n'attendez plus la base de données pour afficher le Header. Vous streamez le contenu. En termes de Core Web Vitals (TTFB et LCP), c'est une différence qui ne se rattrape pas avec des optimisations superficielles.

Les Layouts Imbriqués (Nested Layouts)

Rappelez-vous de la gymnastique mentale nécessaire dans _app.js pour avoir une Sidebar persistante sur certaines pages et pas d'autres. C'était du bricolage. L'App Router a introduit les Layouts imbriqués natifs. C'est une réponse architecturale propre : chaque section de votre URL (/dashboard/settings) peut avoir son propre layout qui ne se re-rend pas lors de la navigation. Moins de re-renders, moins de code client, meilleure UX.

Server-First par défaut

Dans le Pages Router, tout était Client-Side par défaut (hydraté), sauf si vous faisiez des efforts contraires. Résultat : des bundles JavaScript énormes. Dans l'App Router, tout est Serveur par défaut. Le code ne part vers le client que si vous ajoutez explicitement "use server" ou "use client". C'est un changement de philosophie : on envoie du HTML, pas du JS. Pour le mobile et les connexions 4G, c'est le jour et la nuit.

La stratégie de Migration (Le "Strangler Pattern")

Si vous avez une énorme codebase en Pages Router, ne réécrivez pas tout demain. Next.js permet la cohabitation des deux routeurs. La stratégie gagnante en 2026 est celle du "Strangler Fig" :

Tout nouveau module est développé dans /app.
Les pages existantes sont migrées une à une, uniquement quand elles nécessitent une refonte fonctionnelle.
Ne touchez pas au code qui marche et qui ne bouge pas.

Conclusion

Le Pages Router a été un excellent serviteur. Il a popularisé le SSR. Mais l'App Router est l'avenir standardisé de React. S'accrocher au Pages Router aujourd'hui, c'est comme refuser de passer aux Hooks en 2019. Vous vous coupez de l'innovation et vous rendez votre projet obsolète avant même sa mise en production.

La fin du "Waterflow" (Adieu getServerSideProps)

Les Layouts Imbriqués (Nested Layouts)

Server-First par défaut

La stratégie de Migration (Le "Strangler Pattern")

Conclusion

La fin du "Waterflow" (Adieu `getServerSideProps`)

Blog

Tous les articles

Next.js : App Router vs Pages Router (Pourquoi le débat est clos en 2026)