1. Origine
Next.js a été publié en 2016 par l'équipe de Guillermo Rauch, alors ZEIT et aujourd'hui Vercel, pour combler une limite structurelle de React : React sait décrire une interface, mais ne dit rien du routage, du rendu serveur ou du chargement des données. Chaque projet réinventait donc sa propre plomberie, avec ses propres bugs.
Next.js a apporté des conventions : routage par fichiers, rendu serveur clé en main, build unifié. L'App Router, introduit en 2022, a marqué un second tournant avec les React Server Components : par défaut, un composant s'exécute sur le serveur et n'envoie au navigateur que son HTML.
2. Utilité
Un site vitrine n'a pas besoin de Next.js, et le dire d'emblée évite beaucoup de complexité inutile. Le framework devient pertinent quand le projet devient une application : comptes utilisateurs, données propres à chaque visiteur, écrans qui dépendent d'un état, formulaires à plusieurs étapes, tableaux de bord.
Sa force est de couvrir tout ce spectre sans changer d'outil : une page marketing peut être prégénérée et mise en cache au bord du réseau, pendant que le tableau de bord voisin est rendu à la demande derrière une authentification. Chez Studio Relief, c'est vers Next.js qu'on se tourne quand le besoin dépasse le site de contenu et demande une vraie application React.
3. Fonctionnalités
Next.js réunit dans un seul projet ce qui demandait auparavant un assemblage de bibliothèques : routage, rendu, accès aux données, API et optimisation des assets.
- App Router : routage par dossiers, layouts imbriqués, états de chargement et d'erreur déclarés par segment de route
- React Server Components : les composants s'exécutent sur le serveur par défaut, le JavaScript envoyé au navigateur se limite à ce qui est réellement interactif
- Server Actions : des fonctions serveur appelées directement depuis un formulaire, sans écrire de route d'API intermédiaire
- Rendu à la carte : statique, serveur, ou revalidation incrémentale qui régénère une page en arrière-plan après un délai ou un signal
- Route Handlers pour les API REST, les webhooks et les intégrations tierces, dans le même dépôt que l'interface
- Middleware exécuté avant la requête : redirections, internationalisation, contrôle d'accès
- next/image et next/font : optimisation automatique des images et chargement des polices sans décalage de mise en page
- Métadonnées et SEO gérés par route, avec génération des images Open Graph
- Turbopack : compilation incrémentale rapide en développement, même sur les gros projets
4. Cas concrets
→ Sur une plateforme avec espace membre, la vitrine publique est prégénérée pour la vitesse et le référencement, tandis que l'espace connecté est rendu à la demande après vérification de la session. Le tout dans un même projet, avec les mêmes composants et la même charte.
→ Sur un catalogue à fort volume, la revalidation incrémentale permet de servir des pages statiques ultra-rapides tout en les régénérant automatiquement quand les données changent : pas de rebuild complet du site à chaque modification de prix ou de stock.
5. Prix
Next.js est gratuit et open-source sous licence MIT, et peut être déployé n'importe où : Vercel, Cloudflare, Netlify ou un serveur Node classique. Le framework est développé par Vercel, ce qui explique l'intégration particulièrement fine avec leur plateforme, sans jamais l'imposer.
6. Questions fréquentes
Next.js ou Astro pour mon projet ?
La question se tranche sur la part d'interactivité. Si le site sert d'abord à publier du contenu, Astro donne un résultat plus léger avec moins de complexité. Si l'utilisateur se connecte, manipule des données et passe l'essentiel de son temps dans des écrans dynamiques, Next.js est le bon outil.
Faut-il obligatoirement déployer sur Vercel ?
Non. Vercel offre l'intégration la plus complète puisque la même équipe développe les deux, mais Next.js tourne sur Cloudflare, Netlify, AWS ou un simple serveur Node. Le choix de l'hébergeur se fait sur les contraintes du projet, pas sur une dépendance technique.
L'App Router remplace-t-il définitivement le Pages Router ?
L'App Router est la direction officielle et reçoit les nouvelles fonctionnalités. Le Pages Router reste supporté et parfaitement viable sur les projets existants : la migration se fait progressivement, les deux peuvent même cohabiter dans un même projet.
