Prérequis

Qu’est‑ce que Next.js ? Le guide du débutant

Pourquoi Next.js convient au SaaS : routage, SSR/SSG et routes API dans un seul dépôt — un guide complet et accessible.

Qu’est‑ce que Next.js ? Le guide du débutant

Next.js est un framework construit sur React et Node.js qui facilite le développement d’applications web modernes (aperçu). En bref, Next.js fournit une solution tout‑en‑un pour créer des plateformes SaaS (Software‑as‑a‑Service) en combinant frontend et backend dans un seul projet. Il offre nativement le routage, le rendu côté serveur (SSR), la génération statique (SSG) et des routes API, afin que vous puissiez vous concentrer sur les fonctionnalités plutôt que sur la configuration (pourquoi les devs utilisent Next.js). Cette combinaison explique la popularité de Next.js pour les apps SaaS : vous obtenez des pages rapides, compatibles SEO, ainsi que des endpoints backend — le tout dans un seul codebase.

Ce que Next.js fournit par défaut

L’un des grands avantages de Next.js est tout ce qu’il apporte sans configuration. Points clés :

Routage basé sur les fichiers : Pas besoin d’installer un routeur séparé (type React Router) — Next.js crée automatiquement des routes selon vos fichiers et dossiers (file‑based routing). Par exemple, un fichier pages/about.js devient la page /about. Cette convention rend l’organisation intuitive et évite de déclarer les routes à la main.

Rendu côté serveur (SSR) : Next.js peut rendre des pages sur le serveur à chaque requête et envoyer au client du HTML déjà formé (bases du SSR). Résultat : chargement initial plus rapide et meilleur SEO. Après réception, React « hydrate » la page pour l’interactivité côté navigateur.

Génération de site statique (SSG) : Pour les pages qui n’ont pas besoin d’être dynamiques à chaque requête, Next.js peut les pré‑construire au build (SSG). Elles se chargent très vite (et restent SEO‑friendly) car servies telles quelles par un CDN/serveur, sans rendu à la volée. Idéal pour marketing, docs, et contenus peu changeants.

Routes API intégrées : Next.js permet de créer des endpoints backend en ajoutant simplement des fichiers dans un répertoire api (API routes). Ces routes tournent sur Node.js (ou en serverless) au sein de votre app Next.js. Vous pouvez gérer formulaires, requêtes BD, authentification, etc., sans monter un serveur Express séparé — l’API vit dans le même projet que le frontend.

Découpage automatique du code et optimisations : Next.js segmente automatiquement le JavaScript par page et optimise les assets (optimisations). Chaque page ne charge que le JS/CSS nécessaire, au lieu d’un gros bundle unique. À la clé : des pages plus rapides. Minification, tree‑shaking et optimisation d’images sont inclus — inutile de configurer Webpack ou Babel.

Expérience développeur « zéro config » : Next.js supporte TypeScript nativement, le CSS/Sass intégrés, et s’imbrique bien avec les bibliothèques courantes (état, style, data fetching, etc.) (DX). L’objectif : démarrer immédiatement sur les features, avec un setup minimal.

En résumé, Next.js vous offre un framework React full‑stack : routage, bundling et rendu sont gérés pour vous, « il ne vous reste qu’à écrire vos composants » (discussion). Un vrai gain pour les équipes SaaS : vous allez plus vite, avec des fondamentaux solides (perf et SEO).

Modèle de routage et layouts dans Next.js

Next.js utilise un routage basé sur les fichiers qui mappe votre structure de dossiers aux chemins d’URL. Chaque fichier ou dossier dans pages (ou le nouveau app) devient une route. Par exemple, pages/user/settings/notifications.js génère /user/settings/notifications. Ce routeur intégré évite la configuration manuelle et aligne vos URLs sur votre structure de projet.

Définir des routes revient à créer des fichiers. Les routes dynamiques sont gérées : un fichier [id].js dans pages/posts/ devient /posts/123. Next.js gère aussi le code‑splitting et les liens, donc la navigation est fluide et sans rechargement complet.

Next.js introduit aussi la notion de layouts pour gérer les sections répétées. Avec l’App Router (v13), on peut définir des layouts imbriqués au niveau des dossiers. Par exemple, app/dashboard/layout.js peut définir une sidebar et un header communs — toutes les pages sous /dashboard/* utilisent automatiquement ce layout (nested layouts). Pratique pour distinguer un layout « marketing public » et un layout « appli connectée ».

En clair, le routage et les layouts Next.js permettent de bâtir des apps multi‑pages sans douleur : structure d’URL propre (utile pour l’UX et le SEO) et composants communs faciles à maintenir, sans avoir à bidouiller des routeurs externes.

Server Components vs Client Components (en clair)

Avec Next.js 13+, vous croiserez « Server Component » et « Client Component ». Cela concerne la façon dont React/Next.js rendent vos composants.

Server Components : des morceaux d’UI qui s’exécutent sur le serveur (avant que le navigateur ne reçoive quoi que ce soit). Ils rendent du HTML côté serveur, envoyé tel quel au client. Point important : aucun JS React pour ces composants n’est expédié au navigateur (server vs client). C’est très rapide et idéal pour afficher des données (fetch côté serveur) ou du contenu non interactif. En contrepartie, ils ne gèrent pas les interactions (pas de onClick, pas de mises à jour côté client) puisqu’aucun JS n’est chargé.

Client Components : les composants React « classiques » qui tournent dans le navigateur. Indispensables pour l’interactivité — boutons, formulaires, animations, etc. Ils embarquent du JavaScript côté client pour fonctionner (client components). Cela permet des UI riches, mais augmente le bundle et peut ralentir légèrement le premier chargement. Dans Next.js, on marque un composant client avec la directive : "use client" en tête du fichier.

En pratique, une page Next.js combine souvent les deux : structure et contenu rendus par des server components (perf et SEO), et widgets interactifs en client components. Par exemple, sur un dashboard, la majeure partie du contenu peut être côté serveur (affiché immédiatement et en sécurité), tandis qu’un graphique zoomable ou un formulaire réactif sera côté client.

À retenir : Server Components = rendu serveur (pas de JS côté client, idéal pour vitesse et contenu « statique ») ; Client Components = rendu navigateur (nécessaires à l’interactivité). Next.js privilégie par défaut les server components, et vous « opt‑in » aux client components quand nécessaire. Cela permet de n’envoyer au navigateur que le strict nécessaire — un superpouvoir pour équilibrer vitesse et richesse dans un SaaS.

Routes API intégrées : votre backend dans le même dépôt

Fonctionnalité phare pour le SaaS : les routes API. D’ordinaire, on créerait un serveur séparé (Express/Nest) pour gérer données, formulaires, auth, etc. Avec Next.js, vous pouvez souvent éviter cette couche — il suffit de définir des endpoints backend à côté de vos pages front.

Dans un projet Next.js, tout fichier placé sous pages/api/ (Pages Router) ou app/api/ (App Router) devient un endpoint HTTP. Par 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écutera ce handler côté serveur et renverra { "greeting": "Hello from Next API" } en JSON. Puissant : votre UI React et votre API vivent dans le même codebase. Créez des endpoints pour récupérer des infos utilisateur, enregistrer un formulaire, ou un « health check » — sans déployer de serveur séparé. Déployé sur Vercel, chaque route API devient automatiquement une fonction serverless.

Les routes API permettent de démarrer un SaaS sans backend séparé. UI Next.js + routes API Next.js suffisent souvent au début (accès BD/tiers inclus). Vous partagez code, config et types avec le front, ce qui accélère le dev. Et comme ces routes tournent côté serveur, vos secrets (clés API, URL de base de données) restent hors du navigateur.

À noter : le code sous pages/api n’est jamais envoyé au client (serveur uniquement). Vous bénéficiez d’un backend sans alourdir le bundle front.

Exemple concret : créez api/health.js qui renvoie { status: "ok" }. Lancez pnpm dev puis visitez http://localhost:3000/api/health : vous verrez la réponse JSON. 🎉 Une preuve rapide que votre app Next.js sert aussi une logique backend.

Bien sûr, en grandissant, vous intégrerez peut‑être une base externe ou une logique plus complexe. Les routes API peuvent appeler ces BDs ou des APIs tierces. Et si un jour vous les trouvez trop limitées, rien n’empêche d’ajouter un service backend dédié. Beaucoup d’équipes couvrent néanmoins une large part de leurs besoins avec les routes API pour des apps petites à moyennes.

Compromis : quand vous n’avez peut‑être pas besoin de Next.js

Avec toutes ces fonctionnalités, on peut se demander : Next.js est‑il toujours le bon choix ? Excellent outil, oui, mais intéressant d’identifier les cas où il peut sembler « trop ».

Next.js est‑il « overkill » pour un projet très simple ? Pour une page unique très statique, Next.js peut sembler plus lourd que nécessaire. Un setup plus simple (React + Vite, voire HTML statique) peut suffire. Next.js ajoute une légère courbe d’apprentissage et un process de build. Cela dit, il est conçu pour évoluer avec vous : même s’il paraît « trop » au départ, il ne vous bloquera pas — et si votre site grossit, vous serez content·e d’avoir ses capacités (overkill ?).

Peut‑on construire un SaaS sans backend séparé ? Oui — beaucoup le font. Les routes API intégrées signifient qu’on n’a pas besoin d’un serveur à part au début. Votre app Next.js peut gérer l’UI et servir des données JSON/formulaires via ces routes. Rien n’empêche d’appeler des APIs externes si vous préférez (backend séparé ?). Garder UI + API dans un seul dépôt évite la complexité CORS, la duplication de modèles et les déploiements multiples.

Quand pourriez‑vous ne pas avoir besoin de Next.js du tout ? Si votre app n’a aucun besoin de SSR ni de file‑based routing, et qu’elle est 100 % client‑side (outil interne, jeu), un setup React plus léger peut convenir. Si vous avez déjà un backend complet et que le front est entièrement côté client sans enjeu SEO, des équipes choisissent CRA ou Vite + React. Next.js brille quand vous voulez un framework full‑stack opiniâtre ; si vos besoins sont ultra simples ou très atypiques, ces opinions peuvent sembler restrictives.

En résumé, Next.js est un excellent choix pour la plupart des apps web — et clairement pour du SaaS — grâce à son approche holistique. Parfois « overkill » pour une page statique, mais rarement un mauvais choix, et il vous prépare à la croissance.

Conclusion et prochaines étapes

Next.js propose une façon à la fois accessible et puissante de construire des applications web. Il simplifie le travail en fournissant routage, optimisations de rendu et capacités backend prêtes à l’emploi. Pour un projet SaaS, cela signifie mettre votre idée en ligne plus vite, avec moins de pièces mobiles.

Envie d’essayer ? Lancez un serveur de dev (pnpm dev) et visitez http://localhost:3000/api/health (après avoir créé une route api/health). Vous verrez une réponse JSON — preuve que votre app Next.js sert à la fois l’UI et une API. Ensuite, ajoutez des pages via le routage par fichiers, privilégiez les server components pour la vitesse, et saupoudrez de client components pour l’interactivité. Next.js gère le reste.

Bon code, et bienvenue dans l’univers Next.js — où vos compétences React vont plus loin et où bâtir un SaaS full‑stack devient un plaisir plutôt qu’un casse‑tête !

Références

SaaS 101 : ce que signifie vraiment « Software as a Service »

Une introduction au modèle Software‑as‑a‑Service (SaaS) — comprendre ce que signifie le SaaS, comment il fonctionne, ses principaux avantages, et pourquoi c’est devenu une façon dominante de livrer des logiciels à l’ère du cloud.

Qu’est‑ce qu’un middleware ? Guide débutant

Comprendre le middleware, pourquoi il aide dans un SaaS, et comment notre middleware Next.js gère l’i18n et les IDs de requête — avec des pistes de personnalisation.

On this page

Qu’est‑ce que Next.js ? Le guide du débutant
Ce que Next.js fournit par défaut
Modèle de routage et layouts dans Next.js
Server Components vs Client Components (en clair)
Routes API intégrées : votre backend dans le même dépôt
Compromis : quand vous n’avez peut‑être pas besoin de Next.js
Conclusion et prochaines étapes
Références