Développer une plateforme SaaS multi-locataire : les décisions d’architecture qui comptent

L’architecture multi-locataire (multi-tenant) n’est pas une fonctionnalité que l’on greffe une fois les premiers clients arrivés : c’est une architecture à laquelle on s’engage dès le premier jour, ou que l’on paie chèrement plus tard. Les décisions que vous prenez en matière d’isolation, de données et de facturation façonnent tout ce qui suit.

Une plateforme multi-locataire sert de nombreux clients (les locataires) à partir d’une seule application et d’une seule infrastructure, tout en gardant isolées les données et l’expérience de chacun. Bien conçue, elle est invisible pour les utilisateurs et efficace à exploiter. Mal conçue, elle laisse fuiter des données, ralentit et devient impossible à faire évoluer en toute sécurité.

Le choix central porte sur la manière d’isoler les données des locataires : une base de données partagée avec un identifiant de locataire sur chaque ligne, un schéma par locataire ou une base de données par locataire. La base partagée avec identifiant de locataire est celle qui passe le mieux à l’échelle et coûte le moins, mais elle exige un contrôle rigoureux de chaque requête. Une base de données par locataire offre l’isolation la plus forte et est parfois imposée par la conformité, au prix de coûts d’exploitation plus élevés. La plupart des SaaS B2B commencent par une isolation partagée, avec un cloisonnement par locataire strict et systématiquement appliqué.

La facturation par abonnement, les formules, les sièges, le comptage de l’usage et les droits d’accès ne sont pas une intégration à greffer après coup : ils touchent votre modèle de données, vos autorisations et la surface de votre produit. Décider tôt de la correspondance entre formules et fonctionnalités (les droits d’accès) vous évite de disperser la logique tarifaire dans tout le code par la suite.

• Un cloisonnement par locataire appliqué au niveau de la couche de données, pas seulement dans l’interface.
• Une authentification, des rôles et des autorisations conçus pour des équipes, pas pour des utilisateurs isolés.
• Un modèle de droits d’accès qui relie proprement les formules aux fonctionnalités.
• Une observabilité par locataire, pour voir et déboguer l’expérience d’un client précis.

Si les fondations sont bonnes, la croissance est un problème de montée en charge. Si elles sont mauvaises, la croissance impose une réécriture – généralement au pire moment, précisément quand les clients arrivent.