Qu’est-ce que Next.js ? Guide pour débutants

Qu’est-ce que Next.js (en mots simples)

Next.js est un framework basé sur React et Node.js qui facilite la création d’applications web modernes (overview). Il propose un stack full‑stack dans un seul repo : pages frontend, endpoints backend, et options de rendu comme SSR et SSG. C’est pourquoi il est populaire pour le SaaS : performance, SEO et APIs dans le même codebase (why developers use Next.js).

Ce que Next.js fournit par défaut

Routing basé sur les fichiers

• Les routes sont générées à partir de la structure de fichiers (file-based routing).
• Exemple : pages/about.js devient /about.

Server-Side Rendering (SSR)

• Les pages peuvent être rendues côté serveur à chaque requête (SSR basics).
• Améliore le premier chargement et le SEO. React hydrate côté client.

Static Site Generation (SSG)

• Les pages peuvent être générées au build time (SSG).
• Idéal pour les pages marketing et la doc qui changent peu.

API Routes intégrées

• Les endpoints backend vivent dans le même repo (API routes).
• Pas besoin d’un serveur séparé au début.

Code splitting et optimisation automatique

• Chaque page charge uniquement le JS/CSS dont elle a besoin (optimizations).
• Minification, tree‑shaking et optimisation d’images intégrés.

DX sans configuration

• TypeScript, CSS et Sass sont pris en charge nativement.
• Vous pouvez vous concentrer sur le produit (DX overview).

Routing et layouts dans Next.js

Next.js mappe les dossiers et fichiers en URLs automatiquement. Un fichier pages/user/settings/notifications.js devient /user/settings/notifications. Les routes dynamiques fonctionnent de la même façon : [id].js dans pages/posts/ mappe sur /posts/123.

Next.js supporte aussi les layouts réutilisables. Avec l’App Router, vous pouvez définir des layouts imbriqués par dossier, comme app/dashboard/layout.js, et toutes les pages sous /dashboard/* l’utilisent (nested layouts). Parfait pour un SaaS avec site marketing + dashboard.

Server Components vs Client Components (simple)

Next.js (surtout 13+) distingue où un composant s’exécute :

Server Components

• Rendus côté serveur, HTML envoyé au navigateur.
• Aucun JS client n’est envoyé (server vs client components).
• Idéal pour le rendu rapide et les données sensibles.

Client Components

• S’exécutent dans le navigateur et gèrent l’interactivité.
• Nécessitent la directive "use client" en haut du fichier (client components).
• Indispensables pour clics, formulaires, graphiques, animations, etc.

En pratique, on combine : server components pour la structure et les données, client components pour les widgets interactifs. Cela donne vitesse + UX.

API Routes intégrées : le backend dans le même repo

Next.js permet de créer des endpoints au même endroit que l’UI. Tout fichier dans pages/api/ (Pages Router) ou app/api/ (App Router) devient un endpoint HTTP. Exemple :

// pages/api/hello.js
export default function handler(req, res) {
  res.status(200).json({ greeting: "Hello from Next API" });
}

Une requête vers /api/hello exécute ce code côté serveur et renvoie du JSON. Sur Vercel, ces routes deviennent des fonctions serverless. Le code dans pages/api n’est jamais envoyé au navigateur (API routes are server-only), vous pouvez donc garder vos secrets et accéder à la base en sécurité.

Petit exercice : lancez pnpm dev, puis ouvrez http://localhost:3000/api/health (après avoir créé api/health). Si vous voyez { "status": "ok" }, votre frontend et backend tournent ensemble.

C’est pourquoi beaucoup d’équipes démarrent avec un seul repo Next.js : UI + API synchronisés, pas de CORS, types partagés. Et si vous grandissez, vous pouvez toujours ajouter un backend dédié. Ce n’est pas tout‑ou‑rien.

Tradeoffs : quand vous n’avez pas besoin de Next.js

Next.js est puissant, mais pas obligatoire :

• Sites très simples : une landing statique peut être plus simple en HTML ou Vite. Next.js peut sembler surdimensionné, même s’il scale très bien (is it overkill?).
• Backend déjà existant : si vous voulez uniquement une UI client et que le SSR/SEO n’est pas critique, un React plus léger suffit. Next.js reste un bon choix si vous aimez ses conventions.
• Backends spécialisés : si vous faites du traitement lourd, des microservices, ou plusieurs frontends sur la même API, vous pouvez garder un backend séparé et utiliser Next.js pour l’UI (separate backend?).

Malgré tout, beaucoup de SaaS démarrent et grandissent avec Next.js. Par exemple, sushi-templates.com utilise Next.js pour tout. Le framework offre un workflow full‑stack et permet d’ajouter des services externes seulement quand c’est nécessaire (why it’s a game-changer).

Conclusion et prochaines étapes

Next.js est à la fois accessible et puissant. Il unifie routing, rendu et APIs backend dans un seul codebase pour vous laisser vous concentrer sur le produit.

Pour l’essayer :

1. Créez un projet avec npx create-next-app@latest ou un template.
2. Lancez pnpm dev.
3. Ajoutez api/health et ouvrez http://localhost:3000/api/health.

Ensuite, créez des pages via le routing par fichiers, utilisez des server components pour le rendu rapide, et ajoutez des client components pour l’interactivité. Next.js gère le reste.

Références

• Contentful Blog – Next.js vs React: https://www.contentful.com/blog/next-js-vs-react/
• Dev.to – Next.js overview and tradeoffs: https://dev.to/hamzakhan/why-nextjs-is-an-all-time-game-changer-for-web-development-a-technical-perspective-1bgf
• Reddit r/nextjs discussion (features): https://www.reddit.com/r/nextjs/comments/v01uy1/why_should_i_use_next_other_than_ssr/
• Stack Overflow – Next vs separate backend: https://stackoverflow.com/questions/78349307/ssr-and-api-layer-in-nextjs
• LogRocket – Next.js layouts: https://blog.logrocket.com/guide-next-js-layouts-nested-layouts/
• Dev.to – Server vs client components: https://dev.to/oskarinmix/server-components-vs-client-components-in-nextjs-differences-pros-and-cons-389f