Comment construire une architecture SaaS multi-locataire — isolation de schéma, auth, facturation

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · multi-tenant SaaS architecture on AWS and GCP

La réponse en 60 secondes

L'architecture SaaS multi-locataire est une conception dans laquelle une seule instance d'application et une infrastructure partagée servent de nombreuses organisations clientes (locataires), tout en gardant les données de chaque locataire isolées de façon logique ou physique. La première décision, la plus lourde de conséquences, est le modèle d'isolation ; l'authentification, la facturation, la résidence des données et l'observabilité en découlent. Notre équipe de développement SaaS exploite les trois modèles ci-dessous en production.

Trois modèles d'isolation crédibles en 2026 :

1. Base de données partagée, schéma partagé, colonne tenant_id + Postgres RLS. Le choix par défaut. Le moins coûteux à opérer. Supporte plus de 10 000 locataires sur un seul cluster Aurora ou Neon. La migration vers un schéma par locataire est faisable ultérieurement, mais douloureuse.
2. Schéma par locataire (schémas Postgres distincts dans la même base de données). La mise à niveau entreprise. Utile pour les discussions sur l'« isolation logique » avec les auditeurs sans doubler le coût d'infrastructure. Supporte 200 à 2 000 locataires par cluster.
3. Base de données par locataire. Charges de travail réglementées, déploiements mono-locataire, clients payant 100 k€+/an. Coûteux à opérer, plus simple à supprimer proprement, plus facile à justifier lors d'audits réglementaires.

Choisissez (1) pour tout nouveau SaaS B2B, y compris pour les entreprises françaises ou belges qui démarrent. Ajoutez (2) au niveau entreprise dès que vous signez votre premier contrat qui pose la question « mes données sont-elles isolées de celles des autres clients ? » Réservez (3) aux secteurs réglementés ou aux contrats VIP dépassant 100 k€ ARR.

Trois modèles d'isolation — comparatif des compromis

Schéma partagé avec RLS — le choix par défaut

Le patron schéma partagé avec RLS est devenu le choix par défaut des ingénieurs seniors pour les nouveaux SaaS B2B en 2026. Voici comment il fonctionne :

1. Chaque table métier possède une colonne non nulle tenant_id uuid references tenants(id), indexée dans toutes les requêtes courantes.
2. La Row-Level Security Postgres est activée sur toutes les tables métier.
3. Chaque table dispose d'une politique RLS : USING (tenant_id = current_setting('app.tenant_id')::uuid).
4. Chaque handler de requête exécute SET LOCAL app.tenant_id = '...' au début de sa transaction, à partir du token d'authentification vérifié.
5. Le rôle de base de données utilisé par l'application a FORCE ROW LEVEL SECURITY activé, de sorte que même l'application ne peut pas contourner la politique sans changer de rôle.

Résultat : un bug SQL dans votre code ne peut pas exposer les données d'un locataire. La base de données refuse de retourner des lignes d'autres locataires quelle que soit la requête. Nous avons détecté de véritables bugs de cette façon lors d'audits clients — des requêtes qui auraient retourné les données d'autres locataires, bloquées par RLS, avec une erreur claire dans les logs.

Conseils de production tirés de nos projets de développement logiciel :

• Utilisez un pooler de connexions (PgBouncer en mode transaction-pooling) mais sachez que SET LOCAL se réinitialise à la fin de la transaction — c'est le comportement attendu.
• Pour les jobs en arrière-plan, définissez app.tenant_id dans le handler du job, ne faites jamais confiance au seul payload du job.
• Ajoutez un test de fumée en CI qui tente intentionnellement de lire la ligne d'un autre locataire et vérifie que 0 ligne est retournée.
• Les index composites doivent commencer par tenant_id — ex. (tenant_id, created_at) — pour la stabilité du plan de requête.

Schéma par locataire — la mise à niveau entreprise

Lorsque vous commencez à perdre des contrats entreprise face à la question « mes données sont-elles dans la même base que tous les autres clients ? », le schéma par locataire est l'étape suivante. Chaque locataire obtient son propre schéma Postgres (tenant_a1b2c3) avec l'ensemble complet des tables. L'application définit search_path au début de la transaction.

Avantages par rapport au schéma partagé :

• Isolation réelle au niveau du schéma. Un bug ne peut pas retourner les lignes d'un autre locataire.
• Sauvegarde et restauration par locataire simplifiées (dump d'un seul schéma).
• Suppression par locataire simplifiée (un seul DROP SCHEMA CASCADE).
• Réponse favorable aux auditeurs : « chaque client dispose d'un schéma logiquement séparé. »

Inconvénients :

• Les migrations doivent s'exécuter sur N schémas, en parallèle, avec une gestion appropriée des échecs. Outils : Sqitch, Flyway, ou un orchestrateur personnalisé.
• Les requêtes analytiques cross-locataires deviennent complexes (vous ne pouvez pas facilement faire un « SUM sur tous les locataires »). Résolvez ce problème avec une base de données analytique distincte alimentée via CDC.
• La taille du catalogue Postgres croît avec N locataires × N tables. Au-delà de ~2 000 schémas, le gonflement de pg_class commence à affecter le temps du planificateur.

Base de données par locataire — réglementée et isolée

Pour les secteurs réglementés (HealthTech, GovTech, défense, certaines charges financières) et pour les clients stratégiques payant 100 k€+/an, donnez à chaque locataire sa propre base de données — souvent son propre VPC et sa propre région. En France, le secteur de la santé implique également la certification HDS pour les données de santé.

C'est coûteux : 25–150 €/mois par locataire sur AWS RDS ou équivalent. La justification est que l'argument d'audit devient trivial, l'impact de tout bug est limité à un seul client, et les clients signant des contrats à six chiffres acceptent de payer pour l'isolation.

Opérationnellement, vous avez besoin de :

• Un pipeline IaC (Terraform, Pulumi) qui provisionne une nouvelle base de données, exécute les migrations, configure les sauvegardes et connecte l'observabilité pour chaque nouveau locataire.
• Une couche de routage par locataire (typiquement un Cloudflare Worker, une API gateway ou un routeur de sous-domaine en application) qui mappe l'ID du locataire à la chaîne de connexion à la base de données.
• Un pool de connexions par locataire, avec une éviction d'inactivité raisonnée.
• Un flux de dé-provisionnement robuste — suppression de la base de données, archivage de sa sauvegarde et nettoyage de son état IaC.

Authentification et identité à grande échelle

En 2026, il n'y a aucune bonne raison de développer sa propre authentification multi-locataire. Les solutions gérées ont toutes convergé vers le même ensemble de fonctionnalités :

Schéma courant en 2026 : Clerk ou Supabase pour la phase de démarrage ; ajout de WorkOS au niveau entreprise pour le SSO/SCIM. La vérification du token au niveau de l'API extrait l'ID du locataire et le rôle utilisateur ; le handler de requête définit le GUC Postgres.

Facturation, mesure et rapprochement

Un seul Stripe Customer par locataire. Les locataires sont liés aux clients Stripe via un stripe_customer_id stocké. Les abonnements sont gérés dans Stripe Billing. Pour les composants à l'usage :

• Émettez des événements d'utilisation depuis l'application vers un bus d'événements (SNS, Kafka, NATS) balisés avec l'ID du locataire, le nom du compteur, la quantité et une clé d'idempotence.
• Un worker agrège l'utilisation par locataire dans votre registre interne (table Postgres).
• Un job de réconciliation s'exécute chaque nuit, pousse les deltas vers Stripe Meters (ou Orb/Metronome/Lago) et génère un rapport quotidien de réconciliation.
• Exposez l'utilisation aux clients dans le produit — en temps réel, avec au maximum 60 secondes de décalage. Les clients ne feront pas confiance à une facture opaque.

Nous avons couvert le côté stratégique de la tarification dans Modèles de tarification SaaS en 2026 ; ceci est le côté ingénierie. Comptez 6 à 10 semaines pour une facturation mesurée de qualité production — pas deux.

Résidence des données UE selon le RGPD — la bonne approche

Si vous vendez en Europe — notamment aux entreprises françaises, belges ou luxembourgeoises dans des secteurs réglementés ou dans le secteur public —, « les données restent en UE » est une case à cocher dans les appels d'offres, pas un argument marketing. La bonne architecture exige la conformité au RGPD et aux exigences de la CNIL :

1. Deux clusters distincts : us-east-1 et eu-central-1 (ou eu-west-1 pour l'Irlande, eu-north-1 pour la Suède).
2. Chaque cluster dispose de son propre Postgres, stockage d'objets, files de messages, moteur de recherche et pile d'observabilité.
3. Mappage locataire-cluster dans un registre global minimal. Le flux de connexion redirige vers l'API régionale correcte.
4. Le fournisseur d'auth doit supporter la résidence UE (Clerk EU, WorkOS EU, Auth0 EU tenant).
5. Le fournisseur d'observabilité doit supporter l'UE (Datadog EU, Sentry EU, Grafana Cloud EU).
6. Ne divisez pas les lignes par région dans une seule base de données — les auditeurs et la CNIL ne l'acceptent pas.

Si vous intégrez des fonctionnalités IA, prenez également en compte la région du fournisseur de LLM : Anthropic propose des endpoints EU ; Bedrock supporte eu-central-1 pour Claude ; Azure OpenAI propose des régions EU pour GPT-4o. Consultez la conformité EU AI Act pour les aspects documentaires — notamment importants pour la transformation numérique des entreprises françaises soumises à la réglementation européenne.

Observabilité et SLO par locataire

Dans un SaaS multi-locataire, « l'API est lente » est une information inutile sans découpage par locataire. Ajoutez l'ID du locataire comme dimension de premier rang dans chaque métrique, log et trace :

• Traces OpenTelemetry avec l'attribut tenant.id sur chaque span.
• Tag Sentry tenant_id sur chaque erreur.
• Tableaux de bord Datadog/Grafana qui découpent la latence p50/p95/p99 et le taux d'erreur par locataire.
• Rapport quotidien automatisé des 10 locataires les plus bruyants.
• SLO par locataire pour vos 20 meilleurs comptes. Lorsque leur budget SLO est en danger, alertez leur CSM, pas seulement l'équipe d'ingénierie.

Sans observabilité par locataire, un seul locataire entreprise bruyant qui dégrade le p95 ressemble à un incident global. Avec elle, vous pouvez appeler le client en premier.

Chemins de migration et pièges courants

Vous finirez par migrer. Deux chemins réels que nous avons livrés :

1. Schéma partagé → schéma par locataire. Faisable mais douloureux. Les nouveaux locataires arrivent dans le schéma par locataire ; les locataires existants migrent par lots via double écriture + vérification + bascule. Comptez 6 à 14 semaines d'ingénierie pour une migration à 500 locataires.
2. Région unique → multi-région (résidence UE). Construisez d'abord le cluster UE, routez les nouveaux clients européens vers lui, migrez les clients UE existants via export + import + bascule avec une fenêtre de maintenance. 8 à 16 semaines.

Pièges que nous rencontrons régulièrement dans nos projets de développement logiciel en Europe :

• UUID sans v7. Les UUID aléatoires (v4) malmènent les index B-tree. Utilisez UUID v7 (ordonné par temps) pour toutes les nouvelles clés primaires.
• tenant_id manquant sur les tables annexes. Journal d'audit, pièces jointes, enregistrements de livraison de webhooks — tous ont besoin de tenant_id et tous ont besoin de RLS.
• Locataires anciens avec données gonflées. Un locataire avec 10 millions de lignes dans une table où la médiane est à 5 000 ralentit tout le monde via les buffers partagés. Déplacez-les vers un schéma ou une base de données dédié.
• Dérive des clients Stripe. La suppression d'un locataire sans annuler ses abonnements Stripe laisse des revenus fantômes et des maux de tête comptables.
• Fuite de jobs en arrière-plan. Un job déclenché pour le locataire A qui interroge le locataire B parce que le runner a oublié de définir le GUC. Définissez toujours le GUC à l'intérieur du handler du job, ne faites jamais confiance au seul payload.

FAQ

Qu'est-ce qu'une architecture SaaS multi-locataire ?

Une conception dans laquelle une seule instance d'application et une infrastructure partagée servent simultanément de nombreuses organisations clientes (locataires), tout en gardant les données de chaque locataire isolées de façon logique ou physique. La décision centrale est le modèle d'isolation : schéma partagé avec Row-Level Security, schéma par locataire ou base de données par locataire.

Quelle est la meilleure stratégie d'isolation des locataires pour un nouveau SaaS ?

Schéma partagé + Postgres RLS, avec tenant_id sur chaque table et le GUC défini par requête. C'est le plus simple à opérer, le moins coûteux à mettre à l'échelle, et le plus facile à migrer ultérieurement.

Comment gérer l'authentification dans un SaaS multi-locataire ?

Utilisez un fournisseur géré (Clerk, Auth0, WorkOS, Supabase Auth). Ajoutez WorkOS pour le SSO/SCIM entreprise au niveau business.

Où le tenant_id doit-il figurer dans le modèle de données ?

Sur chaque table, indexé, avec clé étrangère, appliqué par RLS. Sans exception.

Comment gérer la résidence des données en UE conformément au RGPD ?

Clusters UE et US distincts avec leurs propres bases de données, stockage et observabilité. Routage par locataire. Ne divisez pas les lignes dans une seule base de données.

Runtime serverless ou en conteneur ?

Conteneurs (Fargate, GKE Autopilot, Fly.io) pour l'API principale ; serverless pour les périphéries comme les webhooks et le traitement d'images.

Comment facturer proprement entre locataires ?

Un Stripe Customer par locataire, abonnements liés au tenant_id interne, événements mesurés via Stripe Meters ou Orb/Metronome. Réconciliation chaque nuit.

Construisez-le correctement du premier coup

Parlez-nous de votre modèle de location, de vos besoins d'isolation et de votre situation d'audit. Nous vous indiquerons l'architecture la moins coûteuse qui résiste à une croissance de 100× — y compris pour les exigences RGPD du marché européen.

Dernière mise à jour le 3 juillet 2026.