Un backend Express qui démarre en cinq minutes, on adore. Le même backend six mois plus tard, avec quinze fichiers de routes empilés et personne dans l’équipe qui ose toucher au fichier app.js devenu monstrueux : là, on aime beaucoup moins. Vous avez déjà vécu ça ? C’est précisément le vide que NestJS vient combler. Un cadre posé, TypeScript de bout en bout, et le sentiment agréable de retrouver ses petits même après trois mois d’absence.
Qu’est-ce que NestJS, et à quoi sert-il ?
NestJS est un framework Node.js pour construire des applications côté serveur, principalement des API et des microservices, en TypeScript. Créé en 2017 par Kamil Myśliwiec, il apporte à Node ce qui manque le plus à Express une fois qu’un projet dépasse quelques dizaines de routes : une architecture prête à l’emploi.
Le pitch tient en une phrase. Node.js excelle sur les backends légers, mais ne dit rien sur la façon d’organiser le code. Où mettre la validation des entrées ? La logique métier reste dans les handlers de routes ou vit dans des services séparés ? Comment tester sans monter tout le serveur ? Comment un nouveau développeur trouve ses repères en trois jours plutôt qu’en trois semaines ?
NestJS répond à toutes ces questions, avec une architecture inspirée d’Angular et des frameworks Java comme Spring.
Le projet est open source sous licence MIT, cumule plus de 70 000 étoiles GitHub et 3 à 4 millions de téléchargements npm par semaine. Il est utilisé en production par Mercedes-Benz, Adidas, Roche et O2 Czech Republic (qui fait tourner plus de 30 microservices NestJS sur une codebase de 3,5 millions de lignes TypeScript). Autant dire que le framework tient la route à l’échelle !
Les avantages et spécificités du framework
NestJS repose sur quelques idées fortes, à connaître avant de se lancer. Voici celles qui font vraiment la différence à l’usage.
Une architecture modulaire, du sol au plafond
Chaque fonctionnalité vit dans son propre module. Un module « users » contient tout ce qui touche aux utilisateurs (contrôleur, service, tests), un module « orders » tout ce qui touche aux commandes. Chaque module est autonome, testable, remplaçable. C’est ce qui permet à un projet NestJS de vieillir bien : à trois mois comme à trois ans, la structure reste lisible.
Trois briques imbriquées : module, contrôleur, service
Toute la mécanique de NestJS tient sur trois concepts, faciles à mémoriser
- Le contrôleur reçoit les requêtes HTTP et retourne les réponses, sans logique métier.
- Le service contient la logique métier (calculs, accès base de données, appels d’API).
- Le module rassemble le tout.
Concrètement :
// users/users.controller.ts
import { Controller, Get, Post, Body } from '@nestjs/common';
import { UsersService } from './users.service';
import { CreateUserDto } from './dto/create-user.dto';
@Controller('users')
export class UsersController {
constructor(private readonly usersService: UsersService) {}
@Get()
findAll() {
return this.usersService.findAll();
}
@Post()
create(@Body() dto: CreateUserDto) {
return this.usersService.create(dto);
}
}Les décorateurs (@Controller, @Get, @Post) déclarent tout de manière visuelle. Un fichier NestJS se lit en trois secondes, même pour quelqu’un qui arrive sur le projet.
L’injection de dépendances : le fil rouge du framework
Vous avez remarqué le constructeur du contrôleur ? constructor(private readonly usersService: UsersService) {}. Nulle part vous n’avez écrit new UsersService(). C’est NestJS qui s’en charge automatiquement : il détecte les dépendances déclarées dans les constructeurs et fournit les bonnes instances au bon moment.
Résultat, un code plus court, plus lisible, et surtout testable en isolation (vous remplacez une dépendance par un mock en une ligne). C’est un concept qu’on retrouve dans Angular côté front et dans Spring en Java, et c’est ce qui distingue le plus radicalement NestJS du reste de l’écosystème Node.
TypeScript de bout en bout
NestJS est conçu autour de TypeScript. Typage strict, autocomplétion partout, détection des erreurs à la compilation plutôt qu’en production. Le framework tourne aussi en JavaScript pur, mais 90 % de sa valeur (typage, décorateurs, injection de dépendances) tient à TypeScript.
À noter donc pour votre équipe : sans TS, la moitié du bénéfice s’évapore.
Une compatibilité totale avec l’écosystème Node.js
Sous le capot, NestJS utilise Express par défaut (ou Fastify, au choix) comme adaptateur HTTP. Autrement dit, tout l’écosystème npm reste utilisable : Passport pour l’authentification, Prisma ou TypeORM pour la base de données, Bull pour les files d’attente, Swagger pour la doc.
NestJS ne remplace pas Node, il l’organise.
Un positionnement progressif
C’est une force souvent sous-estimée. NestJS est « progressif » au sens où vous pouvez commencer petit et enrichir au fil de l’eau : un simple contrôleur pour démarrer, puis un service, puis un DTO validé, puis un module d’authentification, puis des tests, puis des microservices…
Le framework grandit avec votre projet, sans imposer toute sa complexité dès le premier jour.
Pour quel type de projets ?
NestJS n’est pas le bon outil pour tout, et c’est justement ce qui en fait un choix crédible.
Il brille sur les projets destinés à durer et à grossir : API REST ou GraphQL amenées à passer de 3 à 200 endpoints, applications SaaS métier, extranets, plateformes multi-tenant, architectures microservices, backends d’applications mobiles.
Bref, tout ce qui va être maintenu plus de six mois par une équipe de plusieurs développeurs. La rigueur de la structure y devient un atout net : chaque nouveau membre trouve ses repères en une demi-journée, quel que soit le projet.
Il est en revanche disproportionné sur les petits projets : un webhook à trois routes, un POC de 48 heures, un script one-shot. Dans ces cas-là, un Express nu (voire du Hono, plus léger encore) livrera plus vite, et la puissance de NestJS ne servira à rien.
Côté profil, NestJS s’adresse à des développeurs backend qui ont déjà quelques bases en Node.js et TypeScript. Ce n’est pas le meilleur premier framework pour découvrir la programmation web, mais c’est un excellent choix pour un développeur qui vient d’Angular (l’inspiration est directe), de Java Spring ou de .NET (l’injection de dépendances y est une seconde nature).
Pour un dev Express expérimenté, la transition prend une à deux semaines, avec des bénéfices sensibles dès le premier projet.
Comment débuter avec NestJS ?
La mise en route se fait avec le CLI officiel, qui génère un projet complet avec la structure de base et un contrôleur de démonstration.
npm i -g @nestjs/cli
nest new mon-api
cd mon-api
npm run start:devLe serveur tourne sur localhost:3000, avec rechargement automatique à chaque modification. La commande nest generate resource users crée ensuite un module complet (contrôleur, service, DTO, tests) avec les bonnes conventions en une seule ligne. Un accélérateur qu’on ne réalise vraiment qu’au bout de la dixième fois.
Une bonne pratique dès le départ : valider les données entrantes avec un DTO. Voici à quoi ressemble un objet de validation, associé au décorateur @Body vu plus haut :
// users/dto/create-user.dto.ts
import { IsString, IsEmail, MinLength } from 'class-validator';
export class CreateUserDto {
@IsString()
@MinLength(2)
readonly name: string;
@IsEmail()
readonly email: string;
}Un passage par le pipe de validation dans main.ts, et NestJS rejette automatiquement toute requête mal formée, avec un message d’erreur clair. Zéro ligne de validation dans vos contrôleurs, zéro possibilité d’oubli.
Un bon exemple de la philosophie NestJS : le framework gère le transverse, vous écrivez la logique métier.
La v12, sortie en 2026 : ce qui change pour les nouveaux projets
NestJS 12 est arrivée en 2026 et modernise la stack en profondeur. Trois points à retenir :
- Migration complète vers ESM (les modules JavaScript modernes remplacent le vieux format CommonJS).
- Toolchain modernisée : Vitest à la place de Jest pour les tests, oxlint à la place d’ESLint pour le lint, Rspack à la place de Webpack pour le bundling.
- Et le support natif de Zod ou Valibot dans les décorateurs de routes, pour ceux qui préfèrent une approche fonctionnelle aux DTO class-validator.
Pour un nouveau projet, partez directement sur la v12 : le CLI pose les bonnes questions dès le départ.
NestJS sur votre CV de freelance
Un mot pour ceux qui bossent en indépendant. NestJS pèse sur le marché des missions backend Node, et pas qu’un peu.
C’est aujourd’hui le framework Node.js le plus demandé sur les missions à structure d’entreprise, notamment dès qu’il y a du long terme ou du microservice.
Les offres qui listent « NestJS + TypeScript + PostgreSQL » sont légion, et souvent bien mieux rémunérées que les missions Express classiques.
FAQ – NestJS
NestJS est-il gratuit ?
Oui, entièrement, sous licence MIT. Le framework, le CLI et l’écosystème officiel sont open source et gratuits. Seule la formation NestJS Courses (portée par le créateur) est payante, avec plus de 200 leçons pour aller au fond des choses.
Faut-il connaître TypeScript avant d’apprendre NestJS ?
Oui, sans détour. NestJS est possible en JavaScript pur, mais 90 % de sa valeur (typage strict, décorateurs, injection de dépendances) tient à TypeScript. Une base solide en TS avant de bifurquer vers NestJS fait gagner beaucoup de temps.
Quelle est la différence entre NestJS et Express ?
Express est un framework HTTP minimaliste qui vous laisse tout organiser à la main. NestJS utilise Express (ou Fastify) sous le capot et ajoute une architecture complète par-dessus. Express gagne sur la simplicité initiale, NestJS gagne sur la maintenabilité à long terme.
NestJS convient-il aux petits projets ?
Rarement. Sur un webhook, un POC ou une API de trois routes, un simple Express fait le job plus vite. NestJS prend tout son sens à partir de plusieurs dizaines d’endpoints, d’une équipe de plusieurs développeurs, ou d’un projet appelé à durer.
