Ce que doit maîtriser un développeur NestJS, des guards aux transactions

NestJS donne une structure à un back-end Node.js, avec des modules, de l'injection de dépendances et des décorateurs qui rappellent Angular ou Spring. En entretien, on vérifie que la personne sait ce que ces décorateurs déclenchent, et ce qui reste du Node.js pur en dessous.

Recevoir la fiche complète

Mis à jour le Par l'équipe Delectus4 min de lecture

La fiche Développeur NestJS : technologies, chaîne du poste, une question et la grille d'évaluation

Le développeur NestJS écrit des API REST ou GraphQL en TypeScript, souvent sur PostgreSQL avec TypeORM ou Prisma, parfois en microservices reliés par RabbitMQ ou Kafka. Beaucoup d'offres sont full-stack, avec React, Angular ou Vue côté front. Pour préparer un entretien technique de développeur NestJS, partez de ce que le framework cache : l'ordre d'exécution des guards et des pipes, la durée de vie des providers, la gestion des transactions.

Un profil Angular retrouve vite les modules et l'injection de dépendances, un profil Spring aussi. Cela suffit pour écrire du code qui compile. La production demande autre chose : un calcul qui bloque la boucle d'événements, un provider en scope REQUEST qui ralentit toute l'API, un corps de requête qui arrive en base sans validation. Ces sujets se repèrent en posant des cas, rarement en demandant des définitions.

Pensez aussi à la version. NestJS 12 publie ses paquets en ESM et demande Node 20.19 ou 22.12 au minimum, et les nouveaux projets partent sur Vitest. Le PDF reprend l'entretien en six axes et 30 questions, avec un cas de 20 minutes et une grille de notation.

Ce qu'on trouve dans une application NestJS

NestJS 11 et 12

Le framework, écrit en TypeScript, qui tourne au-dessus d'Express ou de Fastify. NestJS 11 est passé à Express 5. NestJS 12 publie ses paquets en ESM, demande Node 20.19 ou 22.12 au minimum et accepte les schémas Standard Schema (Zod, Valibot) pour la validation. Demandez sur quelle version la personne travaille.

Modules, providers et injection de dépendances

L'application se découpe en modules qui déclarent leurs contrôleurs et leurs services (les providers). Nest crée ces objets et les injecte là où on en a besoin. Par défaut chaque provider est unique dans l'application, et changer ce comportement a des effets sur la performance.

Guards, interceptors, pipes et filtres

Les étapes qu'une requête traverse avant et après le code métier. Les guards décident si la requête passe (authentification, rôles), les pipes valident et transforment les données, les interceptors entourent l'appel (logs, cache, format de réponse), les filtres transforment les erreurs en réponses HTTP.

TypeORM, Prisma, MikroORM ou Mongoose

Les outils d'accès aux données. TypeORM et MikroORM travaillent avec des classes d'entités, Prisma génère un client typé à partir d'un schéma, Mongoose sert pour MongoDB. Les migrations, les transactions et les requêtes N+1 sont les sujets à creuser.

Microservices et transports

Le paquet @nestjs/microservices relie des services par TCP, Redis, NATS, MQTT, RabbitMQ, Kafka ou gRPC. Un service peut répondre à des requêtes ou traiter des événements. Les doublons et l'ordre des messages restent à la charge du développeur.

BullMQ, CQRS et tâches planifiées

@nestjs/bullmq met des traitements longs en file sur Redis, @nestjs/schedule lance des tâches à heure fixe, @nestjs/cqrs sépare commandes, requêtes et événements. On les rencontre dès que l'application dépasse le simple CRUD.

GraphQL et OpenAPI

@nestjs/graphql construit une API GraphQL avec Apollo ou Mercurius, en partant du code ou du schéma. @nestjs/swagger génère la documentation OpenAPI d'une API REST à partir des contrôleurs et des DTO. Le front s'appuie sur l'un ou l'autre.

Jest, Vitest et Supertest

Nest fournit un module de test qui remplace les dépendances par des simulations. Supertest appelle l'application comme un vrai client pour les tests de bout en bout. Les nouveaux projets ESM de NestJS 12 utilisent Vitest, beaucoup de projets existants restent sur Jest.

Les offres de développeur NestJS sont souvent full-stack, avec React, Angular, Vue ou Next.js côté front, et certaines ajoutent Kafka, RabbitMQ, Redis, Docker et Kubernetes. Un profil Angular a l'avantage de connaître déjà les modules et l'injection de dépendances, un profil Express celui de connaître Node.js sans la couche du framework. Les deux peuvent convenir. Le premier doit montrer qu'il connaît la boucle d'événements et les limites de Node.js, le second qu'il sait structurer une application qui grossit. Sur un poste de tech lead, ajoutez l'architecture entre services et l'exploitation sur Kubernetes.

Ce qu'un développeur NestJS doit savoir faire seul

  • Modules, providers et injection de dépendances
  • Cycle d'une requête : guards, pipes, interceptors
  • TypeScript, validation et contrats d'API
  • Accès aux données, transactions et performance SQL
  • Microservices, files BullMQ et événements
  • Tests, boucle d'événements et exploitation Node.js

Questions techniques NestJS, avec la réponse attendue

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

  1. Question 1 · confirmé

    Une route est protégée par un guard, avec un interceptor de log et un ValidationPipe. Dans quel ordre tout cela s'exécute-t-il, et où placez-vous le contrôle des rôles ?

    Une bonne réponseMiddleware, puis guards, puis interceptors (partie avant), puis pipes, puis le handler, puis la partie après des interceptors. Les exception filters interviennent en cas d'erreur. Les rôles se contrôlent dans un guard qui lit, avec le Reflector, les métadonnées posées par un décorateur @Roles() sur la méthode ou le contrôleur. Un bon profil enregistre le guard en global avec APP_GUARD.

    Signal d'alerteVérifier les rôles dans un middleware, qui ne sait pas quel handler sera appelé, ou dans chaque méthode de service.

  2. Question 2 · senior

    Un collègue a passé un provider en scope REQUEST pour connaître l'utilisateur courant. Depuis, les temps de réponse ont augmenté. Que s'est-il passé ?

    Une bonne réponseLe scope REQUEST remonte la chaîne d'injection : tous les providers et contrôleurs qui dépendent de ce service deviennent eux aussi request-scoped et sont recréés à chaque requête. Les alternatives : passer l'utilisateur en paramètre avec un décorateur @CurrentUser(), ou utiliser AsyncLocalStorage, par exemple avec nestjs-cls. Il cite les durable providers pour le multi-tenant.

    Signal d'alerteNe pas savoir que le scope se propage, ou chercher la cause du côté de la base de données.

  3. Question 3 · junior à confirmé

    Un client envoie role: 'admin' dans le corps d'une création de compte, et la valeur arrive en base. Comment l'empêchez-vous ?

    Une bonne réponseUn DTO décoré avec class-validator, et un ValidationPipe global avec whitelist: true pour retirer les champs inconnus, forbidNonWhitelisted: true pour les refuser en 400, transform: true pour obtenir une instance typée. Le corps de requête ne va jamais tel quel dans repository.save(). Avec NestJS 12, un schéma Zod ou Valibot passe aussi par le StandardSchemaValidationPipe.

    Signal d'alerteUne interface TypeScript sur le body comme seule protection, alors qu'elle disparaît à la compilation.

  4. Question 4 · confirmé

    Une création de commande écrit dans trois tables via trois services. Un plantage au milieu laisse des données à moitié écrites. Comment gérez-vous la transaction ?

    Une bonne réponseAvec TypeORM, dataSource.transaction() ou un QueryRunner, et l'EntityManager transmis aux services, ou une bibliothèque de transactions portée par le contexte (nestjs-cls avec son plugin transactionnel). Avec Prisma, une transaction interactive $transaction(). Les effets de bord (e-mail, message vers un broker) partent après le commit, ou via une table outbox.

    Signal d'alerteTrois save() séparés et un try/catch qui supprime à la main ce qui a été écrit. Ou une transaction ouverte pendant un appel HTTP externe.

  5. Question 5 · confirmé

    Sous charge, toute l'API ralentit dès qu'un utilisateur lance la génération d'un gros PDF. Que se passe-t-il ?

    Une bonne réponseNode exécute le JavaScript sur un seul thread. Un calcul synchrone long (génération de PDF, JSON.parse d'un gros fichier, bcrypt synchrone, expression régulière mal écrite) bloque la boucle d'événements et toutes les requêtes attendent. Il mesure le retard de la boucle (monitorEventLoopDelay de perf_hooks, Clinic.js) et déplace le calcul dans un worker_thread ou dans un job BullMQ traité par un processus séparé.

    Signal d'alerte« Node est multithread grâce à async », ou ajouter des instances sans comprendre la cause.

Recevez la fiche d'entretien complète en PDF

La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.

  • 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
  • Le niveau visé pour chaque question
  • Une mise en situation de 20 minutes et ce qu'on attend du candidat
  • La grille d'évaluation de 1 à 4, axe par axe

NestJS et Node.js : les points qui reviennent avant l'embauche

Quel niveau de TypeScript exiger d'un développeur NestJS ?

Un TypeScript strict au quotidien : génériques, unknown plutôt que any, types utilitaires, décorateurs. Le point le plus important tient en une idée : les types disparaissent à l'exécution. Une personne qui le sait valide les données entrantes avec class-validator ou un schéma, et ne fait pas confiance à une réponse d'API externe parce qu'elle est typée. Pour un junior, le mode strict et les génériques simples suffisent.

Un développeur Express ou Angular peut-il passer sur NestJS ?

Oui, et c'est fréquent. Le développeur Angular connaît déjà les modules, les décorateurs et l'injection de dépendances, il lui manque souvent Node.js côté serveur : boucle d'événements, flux, connexions à la base. Le développeur Express connaît Node.js et doit accepter la structure imposée par le framework. En entretien, posez au premier les questions sur la boucle d'événements, au second celles sur les modules et les scopes.

Test technique NestJS : à la maison ou en direct ?

Un exercice court en direct apprend plus qu'un projet à rendre. Donnez un petit dépôt NestJS avec un endpoint qui accepte n'importe quel champ, une requête N+1 et un guard mal placé, et demandez à la personne de le relire à voix haute. En une heure, vous voyez ce qu'elle repère seule et comment elle priorise. Un exercice à la maison peut compléter, à condition de rester court.

Quelle différence entre un développeur NestJS et un développeur Node.js ?

NestJS est un framework qui tourne sur Node.js. Un développeur NestJS est donc un développeur Node.js qui a l'habitude d'une architecture en modules avec injection de dépendances. Un poste Node.js sans précision peut utiliser Express, Fastify ou Hono, avec moins de structure. Si votre code est en NestJS, un bon profil Node.js s'y met vite. L'inverse demande de vérifier les bases de Node.js.

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.

Les fiches voisines

Toutes les fiches →

Voyez Delectus sur vos propres offres.

Commencez gratuitement. Passez à l'échelle quand vous êtes prêt.

Demander une démo

Votre ATS, connecté à Delectus

  • Workable
  • Teamtailor
  • iCIMS
  • Lever
  • SmartRecruiters
  • Jobvite
  • Greenhouse
  • Pinpoint