Comment je choisis ma stack technique : mon framework de décision

"Tu utilises quoi comme techno ?" n'est pas la bonne question

C'est la première question qu'on me pose sur un nouveau projet. Elle part d'une bonne intention mais elle inverse l'ordre des choses. La techno n'est jamais le point de départ — elle est la conséquence d'un domaine, d'une équipe et d'une contrainte d'exploitation qu'on n'a pas encore posés sur la table.

Mon défaut sur un projet sans contrainte imposée : Nest.js, Postgres, Authentik self-hosted, Coolify + VPS. Ce n'est pas une préférence esthétique. C'est le socle qui me fait perdre le moins de temps à réinventer une structure à chaque nouveau projet — et celui que je sais faire évoluer sans tout casser. Mais un défaut qu'on n'interroge jamais devient un dogme, et un dogme technique finit toujours par coûter cher à quelqu'un d'autre que celui qui l'a choisi.

Les critères qui font vraiment bouger le choix

La nature du domaine. Un outil de gestion transactionnel (facturation, CRM, back-office) et une plateforme avec du temps réel central (matching, chat, état partagé multi-utilisateurs) n'ont pas la même forme de contrainte. Le premier tolère un framework HTTP-first classique. Le second demande un runtime pensé pour la connexion persistante dès le départ — s'obstiner sur Nest.js par habitude là-dessus, c'est empiler des adaptateurs sur un outil qui n'a pas été conçu pour ça.

Qui va vivre avec le code après moi. Si je reprends un projet dont l'équipe interne maîtrise Django ou Laravel depuis des années, et que la mission est un renfort ponctuel plutôt qu'une réécriture, imposer ma stack casserait leur vélocité pour mon confort. Le bon choix technique sert l'équipe qui reste, pas mes habitudes de la semaine.

La contrainte d'hébergement. Sur un produit qui doit rester souverain (Coolify + VPS Hetzner par défaut), l'architecture doit rester simple à opérer par une petite équipe. Sur une contrainte serverless-first stricte imposée par le client, un framework modulaire comme Nest.js apporte plus de friction que de valeur — des outils plus légers démarrent plus vite et pèsent moins sur le cold start.

La présence ou non d'IA au cœur du produit. Un produit qui orchestre des appels LLM (Anthropic, DeepSeek) avec du streaming, du cache sémantique et des fallbacks a besoin d'une couche d'orchestration explicite (Langchain, Langraph) — pas d'un simple wrapper HTTP autour d'une API.

Ce que la structure imposée résout, concrètement

Sur un projet Express nu, chaque dev senior réinvente sa propre organisation de dossiers. Ce n'est pas un problème à un seul 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.

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

Une convention de découpe par domaine, gardée minimale au début, peut évoluer vers de l'hexagonal quand le domaine devient assez complexe pour le justifier — sans réécriture complète. Ce coût de structure est payé une fois, au démarrage. Le coût d'une organisation ad hoc qui dérive se paie à chaque nouvelle fonctionnalité, indéfiniment.

Ce que je ne fais jamais

Je n'impose pas hexagonal dès le premier commit sous prétexte que "c'est propre" — un MVP à trois entités n'a pas besoin de ports et d'adapters, il a besoin de sortir vite et de rester lisible. Je ne choisis pas non plus une techno parce qu'elle est récente ou qu'elle m'intéresse personnellement : mes intérêts de curiosité technique passent après la maintenabilité du produit sur les trois années qui suivent la livraison.

La stack n'est jamais la conversation d'ouverture. C'est la conclusion — une fois qu'on sait ce que le produit doit vraiment faire, pour qui, et qui devra le faire tourner après moi.