Architecture multi-tenant : le guide pour les fondateurs de SaaS

Le terme revient dans chaque discussion technique autour d'un logiciel par abonnement : l'architecture multi-tenant. Derrière ce mot se cache une question simple : comment une seule plateforme peut-elle servir des centaines de clients tout en garantissant que chacun ne voit que ses propres données ? Ce guide explique les trois approches possibles, leurs compromis et les questions à poser à votre équipe ou votre prestataire, sans jargon inutile.

Tenant, multi-tenant : de quoi parle-t-on ?

Un tenant (locataire) est un client de votre SaaS : une entreprise, une agence, un cabinet, avec ses utilisateurs et ses données. Une architecture multi-tenant fait cohabiter tous ces locataires sur la même application et la même infrastructure, à l'inverse d'une installation séparée par client (*single-tenant*). C'est ce partage qui rend le modèle SaaS rentable : une seule version à maintenir, un seul déploiement, des coûts d'hébergement mutualisés.

Le revers du partage, c'est le risque : une erreur dans une requête peut afficher les données d'un client à un autre. Toute l'architecture multi-tenant consiste à rendre cette erreur impossible, ou au moins très difficile.

Les trois modèles d'isolation des données

1. Base partagée, tables partagées

Tous les clients partagent les mêmes tables ; chaque ligne porte un identifiant de tenant. C'est le modèle le plus simple à exploiter et le moins coûteux : une seule base, des migrations uniques, des sauvegardes globales. Il demande en revanche une rigueur absolue : chaque requête doit filtrer par tenant, sans exception. Les bases modernes comme PostgreSQL offrent des mécanismes (politiques de sécurité au niveau des lignes) qui appliquent ce filtre automatiquement, ce qui réduit fortement le risque d'oubli.

2. Base partagée, schémas séparés

Chaque client dispose de son propre schéma (jeu de tables) dans une base commune. L'isolation est plus forte, les exports et suppressions par client sont simples. Le prix : des migrations à appliquer sur chaque schéma et une complexité qui augmente avec le nombre de clients.

3. Une base par client

Isolation maximale, performances prévisibles, possibilité d'héberger certains clients dans une région ou chez un fournisseur précis. C'est le modèle exigé par certains grands comptes ou secteurs réglementés. En contrepartie, l'exploitation est lourde : des dizaines ou centaines de bases à migrer, surveiller et sauvegarder. Il se justifie rarement pour un MVP.

Quel modèle choisir pour un SaaS qui démarre ?

Dans la grande majorité des cas, le premier modèle (base partagée, identifiant de tenant sur chaque table, politiques de sécurité au niveau des lignes) est le bon choix : simple, économique, et suffisant jusqu'à des milliers de clients. L'essentiel est de concevoir le modèle de données avec le tenant dès le premier jour : ajouter cette notion après coup sur des tables existantes est une opération longue et risquée.

Au-delà de la base : ce que le multi-tenant implique

• Comptes et rôles : un utilisateur appartient à un tenant (parfois plusieurs), avec des permissions propres à chaque espace.
• Fichiers et documents : les fichiers envoyés doivent être rangés et protégés par tenant, pas simplement cachés par une URL difficile à deviner.
• Configuration par client : logo, devise, langue, règles métier spécifiques, sans dupliquer le code.
• Facturation : chaque tenant a son plan, son essai, ses factures et ses limites d'usage.
• Performances : un client très actif ne doit pas ralentir les autres (limites de débit, files d'attente pour les traitements lourds).
• Export et suppression : un client doit pouvoir récupérer ses données et demander leur effacement, ce qui est aussi une exigence de protection des données.

Sécurité : les contrôles à mettre en place

1. Un filtre par tenant appliqué au niveau de la base ou d'une couche d'accès unique, jamais réparti dans chaque écran.
2. Des tests automatisés qui tentent d'accéder aux données d'un autre tenant et doivent échouer.
3. Des journaux d'activité (qui a fait quoi, quand, dans quel espace).
4. Des sauvegardes testées, avec la capacité de restaurer un seul client si nécessaire.
5. Une revue de sécurité avant le lancement et à chaque évolution majeure.

Nous détaillons la protection des données personnelles, y compris les obligations marocaines et européennes, dans sécurité et protection des données pour un SaaS au Maroc.

Scalabilité : grandir sans tout reconstruire

Une architecture multi-tenant bien conçue grandit par paliers : un serveur et une base au départ, puis des réplicas de lecture, un cache, des traitements asynchrones, et, si un grand compte l'exige, la possibilité de déplacer un tenant sur une infrastructure dédiée. L'important est que ces paliers soient possibles sans réécrire l'application. C'est ce que nous visons dans chaque projet de développement SaaS : des fondations simples au lancement, mais prêtes pour la suite.

Exemple concret : le modèle de données d'un SaaS de rendez-vous

Pour rendre les choses tangibles, imaginons un SaaS de prise de rendez-vous vendu à des cabinets. Chaque cabinet est un tenant. Le modèle de données comporte une table des organisations (les tenants), une table des utilisateurs rattachés à une organisation avec un rôle, puis les tables métier : patients, praticiens, rendez-vous, factures. Chacune de ces tables métier porte une colonne `organisation_id`. Une politique de sécurité au niveau des lignes, définie une fois dans la base, impose que toute lecture ou écriture ne concerne que les lignes de l'organisation de l'utilisateur connecté. Un développeur qui oublierait le filtre dans une requête obtiendrait un résultat vide, pas les données d'un autre cabinet.

Les fichiers (ordonnances scannées, documents) sont stockés dans un espace de stockage objet, dans un dossier par organisation, et servis par des liens signés à durée limitée. Les tâches lourdes (envoi de rappels en masse, exports) passent par une file d'attente qui traite les organisations une par une, pour qu'un cabinet qui exporte dix ans d'historique ne bloque pas les autres.

Lier plans, limites et multi-tenant

Le tenant est aussi l'unité de facturation. Chaque organisation porte son plan, sa date de fin d'essai, son état (actif, en période de grâce, suspendu) et ses limites (nombre de praticiens, de rendez-vous par mois, d'utilisateurs). L'application vérifie ces limites au bon endroit : à la création d'un praticien, pas dans chaque écran. Quand un client change de plan, la mise à jour se fait sur une seule ligne. Cette centralisation rend possibles les remises, les prolongations d'essai et les offres spéciales depuis un back-office, sans toucher au code.

Les grands comptes et la demande d'instance dédiée

Tôt ou tard, un client important demandera « son propre serveur » ou un hébergement dans un pays précis. Avec une architecture où le tenant est partout et où la configuration (base de données, stockage, région) est définie par environnement, répondre à cette demande consiste à déployer une seconde instance de la même application avec sa propre base, pour un seul client. Le code reste identique ; seule la configuration change. Sans cette discipline, la demande se transforme en projet de plusieurs mois. Facturez ce service en conséquence : une instance dédiée coûte plus cher à exploiter qu'un tenant sur la plateforme commune.

Migrer une application mono-client vers le multi-tenant

1. Ajouter une table des organisations et y créer le client existant comme premier tenant.
2. Ajouter la colonne de tenant à chaque table métier, la remplir pour les données existantes, puis la rendre obligatoire.
3. Rattacher chaque utilisateur à son organisation et introduire les rôles.
4. Mettre en place le filtre structurel (politiques au niveau des lignes ou couche d'accès unique) et les tests d'isolation.
5. Déplacer la configuration codée en dur (logo, règles, modèles de documents) vers des paramètres par organisation.
6. Ajouter la facturation par organisation et le parcours d'inscription en autonomie.
7. Répéter la migration sur un environnement de test, puis basculer.

Cette démarche est détaillée, avec les aspects métier et commerciaux, dans transformer un logiciel métier en SaaS.

Les questions à poser à votre prestataire

• Comment les données de chaque client sont-elles isolées, et comment cette isolation est-elle testée ?
• Que se passe-t-il si un client demande l'export ou la suppression de toutes ses données ?
• Comment un client très actif est-il empêché de dégrader les performances des autres ?
• Comment seront appliquées les évolutions du modèle de données une fois des clients en production ?
• Pourra-t-on héberger un client dans une région ou chez un fournisseur particulier s'il l'exige ?

Vous préparez un SaaS et voulez valider son architecture avant de développer ? Parlons-en : un échange suffit souvent pour écarter les choix qui coûtent cher plus tard.