Qu'est-ce que Next.js ?

Qu'est-ce que Next.js ?

Next.js est un méta-framework React de qualité production développé et maintenu par Vercel. "Méta-framework" signifie qu'il se situe au-dessus de React (la bibliothèque d'UI) et ajoute les préoccupations de production que React lui-même ne livre pas : routing, rendu côté serveur, optimisation de build, gestion d'images, chargement de polices, routes API, intégration de déploiement. À partir de 2026, Next.js est le défaut de facto pour construire des applications React sérieuses — choisi par Vercel elle-même, OpenAI, Notion, TikTok, Twitch, GitHub Copilot et le Dashboard Stripe.

La ligne de version majeure actuelle est Next.js 14/15+ (2024-2026), construite autour du App Router (le nouveau système de routing qui intègre les React Server Components) et du serveur de dev Turbopack. L'ancien Pages Router (Next.js 12 et inférieur) reste supporté pour les projets legacy mais aucun nouveau développement ne devrait le viser.

Le modèle de rendu hybride

La fonctionnalité tueuse de Next.js est le mélange de stratégies de rendu par route au sein d'une seule application. Choisissez le bon mode de rendu pour chaque page :

SSR (Server-Side Rendering)

La page est rendue sur le serveur pour chaque requête. Meilleur pour le contenu personnalisé (dashboards connectés) ou les pages où les données changent à chaque visite. Augmente le TTFB mais garantit du contenu frais.

SSG (Static Site Generation)

La page est rendue au moment du build et servie comme fichier statique. TTFB le plus rapide possible, passe à l'échelle pour des milliards de requêtes via CDN. Meilleur pour les pages marketing, blogs, docs. Nécessite un rebuild pour mettre à jour.

ISR (Incremental Static Regeneration)

Hybride : les pages sont statiques mais Next les régénère en arrière-plan après un intervalle configurable (par ex., "toutes les 60 secondes"). Meilleur pour le contenu qui change occasionnellement (pages produit, articles d'actualité, listings). Combine la vitesse SSG avec la fraîcheur SSR.

Streaming SSR avec React Server Components (RSC)

Le défaut moderne du App Router. Le HTML rendu côté serveur est diffusé en streaming au client dès qu'il est prêt, avec hydratation côté client sélective pour les composants interactifs. Meilleur pour les apps complexes de récupération de données où certaines sections prennent plus de temps que d'autres.

Rendu côté client (CSR) statique uniquement

Shell pré-rendue + récupération de données côté client. Utilisé pour les routes hautement interactives (dashboards) où le SEO n'importe pas et vous voulez une navigation à la sensation SPA.

Le App Router (Next.js 13+)

Le App Router a introduit les React Server Components dans le développement React mainstream. Concepts clés :

• Server Components par défaut. Les composants récupèrent les données sur le serveur, rendent en HTML et n'envoient pas de JavaScript au navigateur. C'est le plus grand gain de taille de bundle depuis des années.
• Client Components opt-in via la directive 'use client'. Utilisés pour les parties interactives (formulaires, gestionnaires de clic, useState).
• Routing basé sur les fichiers via le répertoire app/. app/blog/[slug]/page.tsx sert /blog/.
• Layouts via les fichiers layout.tsx. Persistants à travers les navigations dans leur sous-arbre.
• UI de chargement et d'erreur via loading.tsx et error.tsx. Limites Suspense automatiques.
• Server Actions pour les mutations : définissez une fonction serveur, appelez-la depuis un composant client, pas besoin de route API.
• Routes parallèles et interceptantes pour des layouts avancés (modales, panneaux côte à côte).

Ce qui livre dans la boîte

• Routing basé sur les fichiers — structure de répertoires = structure d'URL.
• Optimisation d'images via <Image /> — WebP/AVIF automatique, tailles responsives, lazy loading, intégration CDN.
• Optimisation de polices via next/font — Google Fonts auto-hébergées avec zéro layout shift.
• Routes API / Route Handlers — endpoints backend dans le même projet. Compatibles avec le runtime edge.
• Middleware — tourne au edge avant les routes. Auth, tests A/B, routing par géolocalisation.
• Support CSS intégré — Modules, Tailwind, Sass, adaptateurs CSS-in-JS.
• TypeScript par défaut — routing type-safe, server actions, layouts.
• Turbopack — serveur dev basé Rust (remplaçant webpack), encore en stabilisation en 2026.
• Internationalisation (i18n) — routing intégré pour les URLs préfixées par locale.

Next.js vs. alternatives

Pièges courants de Next.js

• Marquer tout comme 'use client'. Annule les bénéfices de taille de bundle de RSC. Lift state up pour garder la plupart des composants rendus côté serveur.
• Hypothèses de cache incorrectes. Next 13+ a un cache par défaut agressif ; les routes qui devraient être dynamiques sont rendues statiquement. Utilisez dynamic = 'force-dynamic' ou revalidate explicitement.
• Mélanger App Router et Pages Router incorrectement. Ils peuvent coexister pendant la migration mais les routes en conflit cassent silencieusement. Migrez complètement quand vous le pouvez.
• Oublier <Image />. Le <img> natif contourne l'optimisation de Next. Utilisez toujours next/image pour les images.
• Usage intensif d'imports dynamiques pour de petits composants. Chaque import dynamique est un aller-retour réseau. Réservez pour les bundles vraiment grands.
• Fonctionnalités Vercel-uniquement. Certaines fonctionnalités (Edge Middleware, ISR) fonctionnent partout mais sont accordées Vercel. Next.js auto-hébergé fonctionne bien mais vous implémentez la plomberie de déploiement.
• Sur-récupération dans les layouts. Une récupération de layout tourne à chaque navigation de page en dessous. Élevez les récupérations dans des routes spécifiques quand possible.

Déployer Next.js

• Vercel — première partie. Déploiements zéro-config, toutes les fonctionnalités fonctionnent. Le défaut pour les nouvelles apps Next.js.
• Auto-hébergé (Node) — next build + next start. Toutes les fonctionnalités supportées. Utilisez quand vous devez tourner sur AWS/GCP/Azure avec contrôle total.
• Auto-hébergé (Docker) — guide officiel pour Next.js containerisé. Courant en entreprise.
• Export statique — output: 'export' génère un site entièrement statique. Perd ISR/server-actions/routes-API mais déploie sur n'importe quel CDN.
• Cloudflare Pages, Netlify, AWS Amplify — plateformes tierces avec adaptateurs Next.js. La plupart des fonctionnalités fonctionnent avec des réserves.

FAQ : Next.js

Devrais-je utiliser App Router ou Pages Router pour de nouveaux projets ?

App Router. Le Pages Router est en mode maintenance. App Router est l'avenir de Next.js et reçoit de nouvelles fonctionnalités.

Next.js est-il uniquement pour React ?

Oui — Next.js est spécifique à React. Vue a Nuxt ; Svelte a SvelteKit ; Solid a Solid Start. Chaque méta-framework se spécialise dans sa bibliothèque UI.

Ai-je besoin de Vercel pour utiliser Next.js ?

Non. Next.js est open source et auto-hébergeable. Vercel est l'entreprise qui le maintient (et offre l'hébergement par défaut), mais le framework fonctionne partout où Node tourne. ~50% des grandes apps Next.js ne sont pas sur Vercel.

Quel est l'impact en taille de bundle de Next.js ?

Le framework ajoute ~70-90KB gzippé à votre JS initial. RSC et l'hydratation sélective dans App Router réduisent significativement ceci pour l'utilisateur, puisque beaucoup de composants n'envoient pas de JavaScript du tout.

Comment Next.js gère-t-il le SEO ?

Excellement — Next.js a été construit pour le SEO. SSR/SSG garantissent que les pages sont crawlables. L'API metadata intégrée génère <title>, <meta>, OpenGraph, JSON-LD. L'optimisation d'images et de polices améliore les Core Web Vitals.

Puis-je utiliser Next.js avec TypeScript ?

Next.js livre avec TypeScript par défaut ; create-next-app génère un projet TypeScript à moins que vous ne désactiviez. Les APIs du framework sont type-safe de bout en bout.

Qu'est-ce que Turbopack ?

Le bundler basé Rust de Vercel qui remplace webpack dans le mode dev de Next.js. Encore en stabilisation pour les builds de production (2026). Cold starts et HMR significativement plus rapides.

Comment LoadFocus se rapporte aux applications Next.js

Les apps Next.js bénéficient de l'optimisation côté serveur mais dépendent toujours de la latence backend pour les routes SSR et des taux de hit de cache edge pour ISR. Les tests de vitesse de site web LoadFocus mesurent les Core Web Vitals sur votre app Next.js déployée depuis 30+ localisations. Les tests de charge valident que les endpoints SSR et Server Actions tiennent sous trafic concurrent réaliste — la partie de l'app qui n'auto-scale pas via le caching statique.