Next.js 16 et les RSC : que change le passage à App Router ?

On a migré 12 produits clients sur App Router + RSC depuis Next.js 14. Voici ce que la théorie ne dit pas, et ce qu'on referait exactement pareil.

Ce qui change vraiment

L'inversion par défaut : tout est server, on opt-in client. Ça paraît anodin mais ça change la façon de réfléchir aux composants. On ne se demande plus 'où est mon state', on se demande 'ai-je vraiment besoin de state'.

Sur Mouvplus, on est passé de 340 Ko de JS initial à 84 Ko après refonte. Pas parce qu'on a fait du tree-shaking magique, mais parce que 60 % des composants n'ont plus besoin d'être client.

Les pièges qu'on a rencontrés

• useEffect qui mute des données provenant du serveur — symptôme : flickering au mount. Solution : passer la donnée en prop et oublier l'effect.
• Composants tiers qui ne déclarent pas 'use client'. Wrapper minimum pour les forcer côté client.
• Hydration mismatch sur le thème dark/light — il faut suspendre l'app jusqu'à ce que next-themes ait choisi (suppressHydrationWarning + class côté html).
• Cookies + fetch dans un RSC = revalidate cassé. Préférer un route handler pour lire des cookies.

Le verdict performance

Sur 12 projets refondus en App Router : LCP médian divisé par 2,3, INP divisé par 4, score Lighthouse moyen passé de 64 à 96. Le gain ne vient pas du framework — il vient de la discipline qu'il impose.

Ce qu'on garde en client

À peu près 15 % du code : formulaires, animations, dropdowns, providers state global, éditeurs riches. Le reste tourne en RSC. Et c'est suffisant pour les Core Web Vitals.

Conclusion

App Router + RSC ne sont pas une révolution. C'est une fenêtre qui pousse à écrire du code plus serveur, plus simple, plus rapide. Si vous démarrez un Next.js aujourd'hui, c'est le défaut. Si vous êtes sur Pages Router, la migration vaut le coût — pour la performance, pour le DX, pour le futur.