Next.js App Router en production : ce que nous avons appris après 10 projets clients

L'App Router est stable depuis Next.js 13.4 et est maintenant le point de départ par défaut pour les nouveaux projets. Après avoir livré dix projets clients dessus — allant de simples sites marketing à des dashboards SaaS multi-locales — nous avons une image claire de là où il livre et là où il crée des problèmes que le Pages Router n'avait pas.

Ce n'est pas un tutoriel. C'est un compte rendu honnête des décisions, erreurs, et leçons de l'utilisation en production.

Le modèle de cache est puissant et déroutant

Le modèle de cache de l'App Router est la chose la plus importante à comprendre avant d'écrire une ligne de code. C'est aussi la source des bugs les plus déroutants que nous avons vus en production.

Il y a quatre couches de cache :

1. Mémoïsation de requête — déduplique les appels fetch identiques dans un seul arbre de rendu
2. Cache de données — persiste les réponses fetch entre les requêtes
3. Cache de route complète — cache l'output rendu des routes statiques
4. Cache du router — cache côté client des segments de route préchargés

Le problème n'est pas que ces caches existent. C'est qu'ils interagissent d'une manière non évidente jusqu'à ce que vous déboguiez un bug où un utilisateur voit des données périmées après une action qu'il vient d'effectuer.

Ce que nous avons appris :

• Taguez chaque fetch dépendant du cache avec tags et utilisez revalidateTag après les mutations
• cache: 'no-store' est approprié pour les données vraiment dynamiques, pas comme solution générale à la confusion du cache
• Le cache de route complète s'applique uniquement aux routes générées statiquement
• unstable_cache est suffisamment stable pour la production malgré le nom

Composants serveur vs. client : la décision que nous prenons à chaque fois

Les composants doivent être des composants serveur quand :

• Ils fetchen des données
• Ils accèdent à des ressources serveur-seulement (bases de données, système de fichiers, variables d'environnement)
• Ils ne contiennent aucune interactivité et aucune API navigateur

Les composants doivent être des composants client quand :

• Ils utilisent des hooks React (useState, useEffect, useContext)
• Ils ont besoin d'APIs navigateur (window, localStorage)
• Ils ont des gestionnaires d'événements qui s'exécutent dans le navigateur

La règle pratique : poussez la limite 'use client' aussi profond que possible. Une page qui est 80 % contenu statique avec un bouton interactif devrait être un composant serveur avec un seul composant bouton 'use client'.

Gains de performance de l'App Router

Streaming. L'App Router supporte le streaming HTML via les frontières Suspense de React. Sur un projet client, cela a réduit le time-to-first-meaningful-paint de 2,8s à 0,9s sur mobile pour une page analytics lourde en données.

Fetch parallèle de données. Les composants serveur à différents niveaux de l'arbre fetchent des données simultanément. Un layout qui fetche les données utilisateur et une page qui fetche du contenu s'exécutent en parallèle.

Vercel vs. auto-hébergé : les vrais compromis

Ce qui fonctionne mieux sur Vercel : Edge runtime, optimisation d'image, ISR avec invalidation de cache distribuée.

Ce qui fonctionne bien n'importe où : SSR standard, génération statique, composants serveur (sans edge runtime), toutes les routes API standard.

Pour la plupart des projets clients, Vercel est le bon choix. Nous auto-hébergeons uniquement quand un client a des exigences de résidence des données (UE uniquement), une infrastructure existante, ou une structure de coût où le pricing Vercel ne fonctionne pas à l'échelle.

Quand nous atteignons encore le Pages Router

Projets legacy. Migrer une grande codebase Pages Router vers l'App Router est un effort d'ingénierie significatif avec peu de retour business pour les sites stables.

Équipes non familières avec l'App Router. Pour les projets où le client prendra le développement post-lancement, Pages Router réduit le risque de passation.

Compatibilité de bibliothèques tierces. La plupart des bibliothèques majeures supportent maintenant l'App Router, mais certaines ne le font pas. Vérifiez toujours avant de commencer un projet App Router avec une exigence de bibliothèque inhabituelle.

Les patterns que nous avons établis

Le fetch de données vit dans des composants serveur ou des route handlers — jamais dans des composants client sauf pour les données côté client uniquement.

Chaque fetch a une politique de cache explicite — soit cache: 'no-store' pour les données dynamiques, soit une période de revalidation et un tag pour l'invalidation.

'use client' exporte uniquement des composants interactifs.

Les layouts fetchent les données partagées une fois — session utilisateur, données de navigation, et config globale sont fetchés dans le layout racine.

L'UI d'erreur et de chargement sont toujours définis — error.tsx et loading.tsx à chaque niveau de segment de route.

Le résumé honnête

L'App Router est une amélioration genuinement pour les applications qui bénéficient de son architecture : streaming, fetch parallèle, cache granulaire, et layouts partagés.

Pour les sites marketing statiques, l'amélioration est minimale. Le Pages Router fonctionne bien et est plus simple. L'App Router ajoute de la complexité qui ne se rembourse que quand vous avez besoin de ce qu'il fournit.

---

Vous construisez en Next.js et vous heurtez à la complexité de l'App Router ? Démarrez une conversation — nous avons traversé la plupart des modes d'échec et pouvons vous aider à les naviguer.