La question revient à chaque projet SaaS, et la réponse par défaut du secteur — « une base par client, c’est plus sûr » — est presque toujours la plus coûteuse.
Les trois stratégies
Colonne d’identifiant client
Toutes les données cohabitent dans les mêmes tables, avec une colonne tenant_id. Le filtrage est appliqué globalement au niveau des modèles.
Avantages : une seule base à sauvegarder, à migrer et à surveiller ; coût d’infrastructure minimal ; requêtes analytiques transversales triviales.
Risques : une requête écrite manuellement qui oublie le filtre expose les données d’un autre client. C’est le seul vrai danger, et il se maîtrise par un filtrage global appliqué au modèle et par des tests d’étanchéité.
Un schéma PostgreSQL par client
Chaque client dispose de son propre schéma dans la même instance. L’isolation est structurelle : une requête ne peut pas atteindre un autre schéma sans changer explicitement de contexte.
Avantages : cloisonnement démontrable devant un auditeur ; restauration possible client par client.
Coûts : chaque migration doit être exécutée sur tous les schémas, ce qui devient lent au-delà de quelques centaines ; les statistiques transversales demandent des requêtes complexes.
Une base par client
Isolation maximale, y compris au niveau des sauvegardes et de la localisation des données.
Avantages : seule option acceptable pour certaines exigences réglementaires, hébergement par pays possible.
Coûts : exploitation nettement plus lourde et coût d’infrastructure qui croît linéairement avec le nombre de clients.
Comment nous tranchons
Trois questions suffisent dans la majorité des cas.
Combien de clients dans trois ans ? En dessous de quelques centaines, la colonne d’identifiant convient. Au-delà de plusieurs milliers, elle reste souvent le meilleur choix, à condition d’un partitionnement des grandes tables.
Y a-t-il une exigence réglementaire écrite ? Pas une inquiétude, une exigence formulée dans un texte ou un contrat. La différence est importante : nous avons vu des projets tripler leur coût d’exploitation pour une contrainte que personne n’avait jamais demandée.
La volumétrie est-elle très inégale ? Un client représentant 60 % du volume total justifie souvent d’être isolé, indépendamment de la stratégie retenue pour les autres.
Le test qui compte
Quelle que soit la stratégie, un jeu de tests doit vérifier explicitement l’étanchéité : créer deux clients, insérer des données pour chacun, puis tenter d’atteindre les données du premier depuis le contexte du second, par chaque point d’entrée — page, API, export, recherche, tâche planifiée.
Ce test est le seul qui rassure réellement. Il coûte une journée à écrire et se rejoue à chaque déploiement.