Next.js : Le Framework React pour la Production

Next.js a transformé la manière dont nous construisons des applications React. Développé par Vercel, ce framework ajoute à React toutes les fonctionnalités nécessaires pour la production : rendu côté serveur, génération statique, routage, optimisation d'images et bien plus. En 2026, Next.js est devenu le choix par défaut pour tout nouveau projet React sérieux. Chez MapWay, nous l'utilisons pour les interfaces web de nos produits cartographiques.

L'App Router : le nouveau paradigme

L'App Router, introduit dans Next.js 13 et stabilisé depuis, représente un changement fondamental dans l'architecture des applications Next.js. Basé sur les React Server Components, il permet de rendre des composants entièrement côté serveur, réduisant drastiquement le JavaScript envoyé au client. Les layouts partagés, le streaming de contenu et les loading states natifs améliorent l'expérience utilisateur de manière significative.

Le système de fichiers détermine le routage : chaque dossier dans app/ représente un segment d'URL, et chaque fichier page.tsx représente une page. Les fichiers layout.tsx, loading.tsx et error.tsx permettent de définir des comportements à chaque niveau de la hiérarchie sans répétition de code. Cette convention élimine le besoin d'un routeur tiers et rend la structure du projet immédiatement lisible.

Server Components vs Client Components

La distinction entre Server Components et Client Components est la clé de voûte de Next.js moderne. Par défaut, tous les composants sont des Server Components : ils s'exécutent sur le serveur, peuvent accéder directement à la base de données et aux fichiers, et n'envoient aucun JavaScript au navigateur. Seuls les composants qui nécessitent de l'interactivité (événements, état, hooks) doivent être marqués avec "use client".

Pour une application cartographique comme TMaps, cette architecture est idéale. La carte interactive est un Client Component (elle nécessite des interactions utilisateur), tandis que la liste des résultats de recherche, les métadonnées et la structure de la page sont des Server Components. Le résultat : un chargement initial rapide avec un minimum de JavaScript côté client.

Les stratégies de rendu

Rendu statique (SSG)

Par défaut, Next.js pré-rend les pages au moment du build. Le HTML est généré une fois et servi depuis un CDN, offrant des temps de chargement minimaux. C'est la stratégie idéale pour les pages de contenu comme les articles de blog, les pages produit et les pages marketing. Le site MapWay que vous consultez utilise cette approche pour des performances optimales.

Rendu dynamique (SSR)

Pour les pages qui dépendent de données en temps réel ou de l'utilisateur connecté, Next.js génère le HTML à chaque requête côté serveur. Le streaming permet d'envoyer progressivement le HTML au navigateur, affichant d'abord le shell de la page puis le contenu dynamique via des Suspense boundaries. Cette technique élimine les pages blanches et améliore les Core Web Vitals.

ISR (Incremental Static Regeneration)

L'ISR combine le meilleur des deux mondes : les pages sont pré-rendues statiquement puis revalidées en arrière-plan selon un intervalle configurable. Quand les données changent, la prochaine requête reçoit la version cache puis déclenche une régénération. C'est parfait pour les catalogues, les dashboards et les pages de listing qui changent régulièrement mais ne nécessitent pas un rendu en temps réel.

API Routes et Server Actions

Next.js permet de créer des endpoints API directement dans le projet, éliminant le besoin d'un serveur backend séparé pour de nombreux cas d'usage. Les Route Handlers dans le dossier app/api/ exposent des fonctions GET, POST, PUT, DELETE qui gèrent les requêtes HTTP. Pour les mutations de données simples, les Server Actions permettent d'appeler des fonctions serveur directement depuis un formulaire sans créer d'endpoint API.

Attention cependant : pour les applications complexes avec beaucoup de logique métier, nous recommandons toujours un backend dédié. Chez MapWay, les API Routes de Next.js servent de proxy vers nos microservices backend, ajoutant une couche d'authentification et de cache côté frontend.

Optimisations intégrées

next/image : optimisation automatique des images avec redimensionnement, conversion en WebP/AVIF et lazy loading natif.
next/font : chargement optimisé des polices Google ou locales avec élimination du FOUT (Flash of Unstyled Text).
next/link : pré-chargement intelligent des pages liées pour une navigation instantanée.
Metadata API : gestion déclarative du SEO avec génération automatique des balises meta, Open Graph et JSON-LD.
Bundle analyzer : visualisation de la taille de chaque module pour identifier les dépendances lourdes.

SEO et Core Web Vitals

Le SEO est l'un des arguments majeurs de Next.js par rapport à une SPA React classique. Le rendu côté serveur garantit que les moteurs de recherche reçoivent du HTML complet, indexable immédiatement. La Metadata API permet de définir les balises meta à chaque niveau de la hiérarchie, avec héritage et surcharge. Les Core Web Vitals (LCP, FID, CLS) sont naturellement optimisés grâce au SSR, au streaming et aux optimisations d'images et de polices intégrées. Pour nos sites chez MapWay, les scores Lighthouse sont systématiquement supérieurs à 90.

Déploiement

Next.js se déploie de multiples manières. Vercel, créé par les auteurs de Next.js, offre l'intégration la plus fluide avec déploiement automatique sur chaque push Git, preview deployments pour les pull requests et analytics intégrés. Mais Next.js n'est pas limité à Vercel : le mode standalone génère un serveur Node.js autonome déployable dans n'importe quel conteneur Docker, sur AWS, GCP ou tout autre hébergeur.

Pour l'export statique (output: 'export'), Next.js génère des fichiers HTML/CSS/JS déployables sur n'importe quel CDN ou hébergeur statique, comme nous le faisons pour certains de nos projets chez MapWay. Le choix de la stratégie de déploiement dépend des fonctionnalités utilisées : SSR et API Routes nécessitent un serveur Node.js, tandis que SSG pur peut être servi statiquement.