Pourquoi Nest.js est mon défaut backend (et les 3 cas où je le quitte)

Le défaut n'est pas un dogme, c'est un point de départ économique

Quand un projet démarre sans contrainte technique imposée, je pars sur Nest.js. Pas parce que c'est le framework le plus rapide ou le plus à la mode — parce que c'est celui qui me fait perdre le moins de temps à réinventer une structure sur chaque nouveau projet client. Modules, providers, guards, pipes : la structure est déjà là, et elle tient encore quand l'équipe grossit derrière moi.

Ce que la structure imposée résout vraiment

Sur un projet Express nu, chaque dev senior réinvente sa propre organisation de dossiers. Ce n'est pas un problème à un développeur. Ça en devient un dès qu'un deuxième dev rejoint, ou que je reprends un projet après plusieurs mois d'absence. Nest.js impose une convention de découpe par domaine que je peux garder minimale au début et faire évoluer vers de l'hexagonal quand le projet le justifie — sans tout réécrire.

@Module({
  imports: [VehiculeModule, VenteModule, ReprisModule],
  controllers: [],
  providers: [],
})
export class AppModule {}

Cette convention n'est pas gratuite : elle coûte un peu de boilerplate au démarrage (decorators, injection de dépendances, modules à déclarer). Mais ce coût est payé une fois, au début, alors que le coût d'une structure ad hoc qui dérive se paie à chaque nouvelle feature, indéfiniment.

Les 3 cas où je quitte Nest.js

Un besoin temps réel lourd et central au produit. Nest gère très bien les WebSockets pour des features secondaires — un chat, des notifications. Mais si le produit EST du temps réel (matching, trading, jeu multi-joueur avec état partagé), je vais chercher un runtime pensé pour ça dès le départ plutôt que d'empiler des adaptateurs sur un framework HTTP-first.

Une équipe déjà experte sur un autre stack, avec une deadline serrée. Si je reprends un projet dont l'équipe interne connaît Django ou Laravel depuis des années, et que la mission est un audit + renfort ponctuel plutôt qu'une réécriture, imposer Nest.js casserait leur vélocité pour mon confort. Le bon choix technique sert l'équipe qui va vivre avec, pas mes habitudes.

Une contrainte serverless-first stricte côté client. Sur une architecture pensée uniquement en fonctions courtes et stateless (Lambda, Cloudflare Workers), le modèle modulaire de Nest apporte plus de friction que de valeur — les frameworks légers pensés pour ce contexte démarrent plus vite et pèsent moins sur le cold start.

Ce que je ne fais pas

Je n'impose jamais hexagonal dès le premier commit sous prétexte que "c'est propre". La découpe par bounded contexts, je la sors quand le domaine devient assez complexe pour la justifier — pas avant. Un MVP à trois entités n'a pas besoin de ports et d'adapters, il a besoin de sortir vite et de rester lisible.

Le stack par défaut n'est pas une opinion figée. C'est le point de départ le moins cher à changer d'avis dessus.