Notre stack : Nuxt, PostgreSQL, Docker — et les cas où nous vous la déconseillerions

Les articles « notre stack » tournent facilement à la vitrine. Celui-ci a une règle : pour chaque choix, dire ce qu'il nous coûte et dans quel cas nous conseillerions autre chose. Une stack n'est pas un palmarès de technologies — c'est un ensemble de compromis choisis pour un contexte : le nôtre est un studio qui édite plusieurs produits SaaS avec une petite équipe, sur infrastructure auto-hébergée.

La règle d'or : une seule stack, partout

Notre décision la plus structurante n'est pas une technologie, c'est une contrainte : tous nos produits partagent exactement la même stack, versions comprises. Nuxt 4 (Vue 3) et son serveur Nitro, PostgreSQL 16, Redis 7, Drizzle comme ORM, Vitest et Playwright pour les tests, Docker Compose et Caddy au déploiement, TypeScript strict de bout en bout, le tout en monorepo avec un catalogue de versions unique.

Le gain est opérationnel : n'importe qui de l'équipe ouvre n'importe quel produit et retrouve les mêmes patterns ; une montée de version se fait une fois ; un correctif de sécurité se propage partout en une pull request. Le coût est réel aussi : chaque brique doit convenir à tous les usages — nous renonçons à « le meilleur outil pour chaque cas » au profit de « un très bon outil pour tous nos cas ».

Nuxt/Vue plutôt que Next/React : un choix d'équipe, pas de vérité

Techniquement, Next.js/React et Nuxt/Vue jouent dans la même catégorie : SSR et statique route par route, écosystème riche, recrutement possible. Nous avons choisi Vue pour la lisibilité de ses composants et Nuxt parce que son serveur intégré (Nitro) nous évite un backend séparé pour la plupart des produits : routes d'API, tâches, middleware — un seul processus à déployer.

// server/api/leads.post.ts — un endpoint d'API dans l'app Nuxt,
// même processus que le rendu des pages, zéro service séparé.
export default defineEventHandler(async (event) => {
  const lead = leadSchema.parse(await readBody(event));
  await db.insert(leads).values(lead);
  return { ok: true };
});

Où nous conseillerions autre chose : si votre équipe vit dans React, choisissez Next — la maîtrise de l'équipe pèse plus lourd que tout écart entre frameworks. Et si votre besoin est un site éditorial pur, un générateur statique simple (Astro, voire du HTML) fera mieux que n'importe quel framework applicatif.

PostgreSQL + Drizzle : l'ennui comme qualité

Une base par produit, jamais partagée entre services — les produits communiquent par événements signés, pas en lisant la base du voisin. PostgreSQL parce qu'il couvre tout notre spectre (relationnel strict, JSONB quand un document se justifie, recherche correcte) ; Drizzle parce que le schéma vit en TypeScript, migrations générées et versionnées :

export const leads = pgTable('leads', {
  id: text('id').primaryKey(),
  email: text('email').notNull(),
  consentement: boolean('consentement').notNull().default(false),
  creeLe: timestamp('cree_le', { withTimezone: true }).notNull().defaultNow(),
});

Ce que ce choix nous coûte : l'exploitation est à nous — sauvegardes, restaurations testées, mises à jour majeures. Nous l'assumons parce que la compétence existe dans l'équipe ; sans elle, une base managée serait plus raisonnable (nous le disons sans détour dans notre comparatif d'hébergement).

Docker Compose + Caddy : le déploiement sans orchestrateur

Pas de Kubernetes : chaque produit est un docker-compose.yml (app, Postgres, Redis) derrière Caddy qui gère TLS et reverse proxy. La protection contre la surcharge n'est pas l'autoscaling mais le capping applicatif : quotas par organisation, rate limiting, plafonds de ressources par conteneur. Nos environnements de dev exécutent les mêmes services que la prod — une règle née d'un incident, racontée dans nos coulisses : aucun chemin de code ne doit s'exécuter pour la première fois en production.

Les limites : pas d'élasticité automatique (nous dimensionnons avec de la marge), une montée en charge au-delà d'un serveur qui demanderait un vrai chantier, et une astreinte de fait. À l'échelle d'un produit B2B en croissance raisonnable, ce compromis nous va ; pour un produit à pics massifs et imprévisibles, il serait mauvais.

Ce qu'il faut retenir

Notre stack optimise trois choses : la vitesse de livraison d'une petite équipe, l'uniformité entre produits, et l'indépendance d'exploitation. Elle sacrifie l'élasticité automatique et l'optimum local de chaque brique. Si vos contraintes ressemblent aux nôtres — équipe réduite, plusieurs produits, coûts à maîtriser — elle est un bon point de départ. Si votre équipe maîtrise un autre écosystème, que votre trafic est imprévisible ou que l'exploitation n'est pas votre métier, la même démarche (une stack unique, ennuyeuse et cohérente) appliquée à d'autres briques vous servira mieux que la copie de nos choix.