5 signes indiquant que votre produit SaaS a besoin d'une véritable architecture multi-tenant

La plupart des produits SaaS démarrent avec un modèle de données qui prend techniquement en charge plusieurs clients mais n'a pas été conçu pour cela : une base de données partagée unique avec une colonne customer_id ajoutée après coup. Cela fonctionne bien, jusqu'au jour où cela ne fonctionne plus, et ce moment tend à survenir au pire moment possible : en plein cycle de vente à une grande entreprise.

Le premier signe est un prospect qui interroge sur les garanties d'isolation des données lors d'une revue d'achat. Le deuxième est un ingénieur devant écrire un script ponctuel pour corriger des données ayant fui entre tenants. Le troisième est une dégradation imprévisible des performances des requêtes à mesure que le volume de données de votre plus gros client augmente et commence à affecter tous les autres sur les mêmes tables.

Le quatrième signe est le besoin de configurations par client, de feature flags, de champs personnalisés, de politiques de rétention différentes, et le constat que le schéma actuel n'a nulle part où les intégrer proprement. Le cinquième est un client demandant un environnement dédié ou des garanties de conformité spécifiques que votre architecture ne peut pas fournir proprement.

La sécurité au niveau des lignes, appliquée dans la couche base de données plutôt que seulement dans le code applicatif, est ce qui referme réellement la faille d'isolation. Une convention côté application du type « toujours filtrer par tenant_id » fonctionne jusqu'à ce qu'une requête quelque part l'oublie, et c'est précisément cet unique oubli qui devient l'incident qui finit en revue de sécurité. Les politiques de sécurité au niveau des lignes dans Postgres (ou l'équivalent dans votre base de données) font de la frontière d'isolation quelque chose que la base de données applique, même si le code applicatif contient une erreur.

Tester l'isolation doit être offensif, pas seulement fonctionnel. Il ne suffit pas de vérifier que le tenant A voit les données du tenant A ; il faut des tests qui tentent activement de faire voir au tenant A les données du tenant B via chaque chemin de code, y compris les tâches en arrière-plan, les couches de cache et les index de recherche, précisément les endroits où se cachent réellement les failles d'isolation.

La migration elle-même est davantage un problème de séquencement qu'un problème d'ingénierie. Nous commençons généralement par les tables les plus à risque (celles qui montrent déjà des symptômes de performance ou de fuite), ajoutons une indexation consciente des tenants et des politiques de sécurité au niveau des lignes derrière un feature flag, validons face au trafic de production en mode fantôme, puis basculons table par table plutôt qu'en une seule mise en production.

Rien de tout cela n'implique une reconstruction complète. Une véritable architecture multi-tenant est généralement une migration incrémentale : sécurité au niveau des lignes, indexation consciente des tenants et une frontière d'isolation claire, réalisée par phases derrière le produit que vos clients utilisent déjà. La version coûteuse est celle réalisée sous pression, en pleine négociation, plutôt qu'en amont de celle-ci.