Multi-tenant avec NestJS : nos patterns

Le multi-tenant est simple sur un slide et cruel en prod. Chez IDLABS IO, on le livre surtout pour des SaaS B2B où une fuite de données entre clients est inacceptable. Voici les patterns NestJS qu’on réutilise - et ceux qu’on a abandonnés.

Pour le cycle idée → prod, croisez infra minimale en six semaines. Si le tenant porte aussi un corpus IA, lisez RAG en production.

Ce qu’on isole vraiment

Trois niveaux, dans l’ordre :

1. Identité du tenant (sous-domaine, header, JWT claim) - résolue une seule fois par requête.
2. Données - chaque requête SQL / ORM filtre le tenantId (ou schéma dédié).
3. Ressources - quotas, rate limits, storage, files d’attente.

Oublier le point 3, c’est avoir un SaaS qui marche jusqu’au premier client bruyant.

Résolution de tenant (NestJS)

Pattern qu’on préfère :

• un middleware / guard qui résout le tenant avant les controllers ;
• injection d’un TenantContext request-scoped ;
• interdiction d’accéder à la DB sans ce contexte (sauf jobs admin explicites).

@Injectable({ scope: Scope.REQUEST })
export class TenantContext {
 tenantId!: string;
}

Les jobs async reçoivent le tenantId dans le payload - jamais « le dernier tenant du process ».

Données : schéma partagé vs schéma par tenant

Notre défaut : schéma partagé + RLS ou filtre systématique dans la couche repository. Sur Cabineto-like, on ajoute des tests qui tentent d’accéder à une ressource d’un autre tenant et doivent échouer.

Quotas et multi-tenant « honnête »

Sans quotas, le multi-tenant n’est qu’une colonne. On instrumente :

• requêtes / minute ;
• stockage fichiers ;
• seats / utilisateurs actifs ;
• appels LLM (si agents ou RAG).

Voir aussi nos services backend.

Pièges récurrents

• Caches globaux sans clé tenant.
• Webhooks qui écrivent sans re-vérifier le tenant.
• Migrations qui backfillent mal le tenant_id.
• Admin « god mode » branché trop tôt sans audit log.

FAQ

NestJS est-il adapté au multi-tenant

Oui, via guards, providers request-scoped et une couche repository stricte. Le framework ne remplace pas la discipline sur les filtres.

Faut-il une base par client

Rarement. Commencez par un schéma partagé avec isolation stricte ; réservez DB/schéma dédiés aux contraintes compliance.

Comment tester l’isolation

Des tests d’intégration qui créent deux tenants et vérifient qu’aucune lecture/écriture croisée n’est possible.

Où placer le tenantId

Dans le JWT / header résolu une fois, puis propagé via un contexte request-scoped - jamais lu ad hoc dans chaque service.

Un SaaS multi-tenant à cadrer ? Contactez-nous. À lire : idée → prod, audits techniques, backend IDLABS IO.