Faut-il migrer tout le site d'un coup vers l'App Router ?

Non, et c'est justement l'intérêt de la démarche. Next.js autorise la coexistence des répertoires app/ et pages/ dans un même projet : vous migrez route par route, en production, sans big bang. En cas de conflit sur un même chemin, l'App Router prend la priorité. Une migration incrémentale répartit le risque au lieu de le concentrer sur une seule mise en production.

Quel est le principal piège d'une migration vers l'App Router ?

Le comportement de cache. Le modèle de mise en cache de l'App Router diffère profondément de celui du Pages Router, et ses valeurs par défaut ont évolué au fil des versions majeures de Next.js — depuis Next.js 15, les requêtes fetch ne sont plus mises en cache par défaut. Une migration réussie commence par expliciter la stratégie de cache attendue pour chaque route plutôt que de se fier aux défauts.

Les Server Components remplacent-ils totalement les composants React classiques ?

Non. Dans l'App Router, les composants sont des Server Components par défaut, ce qui réduit le JavaScript envoyé au navigateur. Mais tout ce qui nécessite de l'interactivité — état local, gestionnaires d'événements, hooks de navigateur — doit rester un Client Component, déclaré par la directive "use client". Les deux modèles cohabitent dans un même arbre de composants.

Migrer vers l'App Router Next.js : La Méthode Sans Régression

Pourquoi la question se pose maintenant

L'App Router de Next.js est stable depuis la version 13.4, publiée en mai 2023. Trois ans plus tard, il n'est plus une nouveauté à surveiller mais le modèle par défaut : la documentation officielle, les exemples, les intégrations tierces et l'essentiel de l'écosystème sont désormais écrits pour lui.

Rester sur le Pages Router n'est pas un problème immédiat — il reste supporté. Le coût est ailleurs, et il est progressif : votre équipe travaille sur un modèle que la documentation illustre de moins en moins, les nouvelles fonctionnalités du framework y arrivent en second, et le recrutement se fait sur des compétences décalées. C'est une dette technique silencieuse, qui ne provoque aucune panne mais alourdit chaque évolution.

Ce qui change réellement

La migration n'est pas un simple déplacement de fichiers. Trois ruptures structurent le travail.

Les composants s'exécutent sur le serveur par défaut

Dans l'App Router, un composant est un Server Component sauf mention contraire. Il s'exécute côté serveur, n'est jamais envoyé au navigateur, et peut interroger directement une base de données ou une API interne. Le bénéfice est mesurable sur le poids du bundle JavaScript, donc sur les temps de chargement.

En contrepartie, tout ce qui relève de l'interactivité — useState, useEffect, un onClick, l'accès à window — impose de basculer le composant en Client Component via la directive "use client". L'erreur fréquente consiste à poser cette directive trop haut dans l'arbre : tout le sous-arbre repart alors côté client et le gain disparaît. La bonne pratique est de descendre "use client" au plus près du composant réellement interactif.

Le chargement des données quitte les fonctions spéciales

getServerSideProps, getStaticProps et getInitialProps n'existent plus. Le chargement de données se fait directement dans un composant serveur asynchrone, avec un await sur votre source de données. Le code gagne en lisibilité : la donnée est récupérée là où elle est consommée, sans passer par un objet props intermédiaire.

Les conventions de fichiers remplacent la configuration

| Pages Router | App Router | | --- | --- | | _app.tsx + _document.tsx | app/layout.tsx | | next/head | API Metadata (export const metadata) | | next/router | next/navigation | | pages/api/* | Route Handlers (app/api/*/route.ts) | | — | loading.tsx, error.tsx, not-found.tsx |

Le passage de next/router à next/navigation mérite une attention particulière : ce n'est pas un simple changement d'import. Le hook useRouter y expose une API différente, et l'accès aux paramètres passe par usePathname et useSearchParams. Tout composant lisant router.query doit être réécrit, pas seulement réimporté.

La méthode : migrer route par route

Le point décisif est que les répertoires app/ et pages/ coexistent dans un même projet. Vous n'avez pas à choisir entre tout migrer et ne rien migrer.

Créez le socle. Un app/layout.tsx racine porte les balises <html> et <body>, les polices et les métadonnées globales.
Commencez par une route à faible risque. Une page légale, un formulaire de contact, un article de blog : peu de trafic, peu d'interactivité, régression facile à détecter.
Migrez par valeur décroissante de risque. Les pages à fort trafic ou à enjeu de conversion — tunnel de commande, espace client — passent en dernier, une fois l'équipe rodée au modèle.
Vérifiez sur le HTML généré, pas sur les sources. À chaque route migrée, contrôlez le rendu réel : balises <title> et canoniques, données structurées, redirections. Une régression SEO se voit dans le HTML produit, rarement dans le code.

Le piège qui coûte le plus cher : le cache

C'est l'écart le plus mal anticipé. L'App Router introduit un modèle de mise en cache à plusieurs niveaux, et ses valeurs par défaut ont changé au fil des versions majeures : depuis Next.js 15, les requêtes fetch ne sont plus mises en cache par défaut, à l'inverse du comportement introduit avec l'App Router.

Concrètement, une équipe qui migre en s'appuyant sur les défauts obtient soit des pages figées affichant des données périmées, soit une charge serveur qui explose parce que plus rien n'est mutualisé. Aucun des deux symptômes n'apparaît en développement local.

La parade est méthodique plutôt que technique : pour chaque route, décidez explicitement de la fraîcheur attendue — statique, revalidée à intervalle, ou strictement dynamique — et rendez ce choix visible dans le code. Une migration réussie est une migration où le comportement de cache est documenté route par route, pas déduit.

Passez à l'action

Une migration vers l'App Router est un investissement rentable quand elle est menée par incréments et validée sur le rendu réel. Elle devient coûteuse quand elle est traitée comme un chantier monolithique livré en une fois.

Securium Agency accompagne les migrations Next.js de bout en bout : audit de l'existant, plan de migration priorisé par le risque, exécution route par route et contrôle des régressions SEO à chaque étape. Demandez un audit gratuit de votre application : nous évaluons l'effort réel et vous remettons une trajectoire chiffrée, sans engagement.