Multi-tenant en SaaS : silo, pool ou bridge — et le chemin entre les modèles

La décision la plus coûteuse avant votre premier client

Dans une plateforme SaaS, le modèle de tenancy est le point où se croisent l'économie unitaire, la posture de sécurité et la vélocité d'ingénierie. Il détermine combien coûte chaque client à servir, jusqu'où se propage un incident, ce que vous pouvez promettre à un auditeur et à quel point chaque migration future sera douloureuse. Les équipes passent des semaines à choisir un framework frontend et une après-midi sur le modèle de tenancy. Les proportions devraient être inversées : un framework se remplace, un modèle de tenancy se fige.

Trois modèles canoniques couvrent l'espace — silo, pool et bridge — et aucun n'est simplement le meilleur. Chacun échange de l'isolation contre du coût opérationnel. La question utile n'est pas de savoir quel modèle est le bon, mais quels compromis votre activité peut assumer aujourd'hui — et combien coûtera un changement d'avis plus tard.

Silo, pool, bridge — les vrais compromis

Les modèles diffèrent par ce qu'ils partagent et ce qu'ils dédient ; chaque mode de défaillance découle de ce choix.

• Silo — chaque tenant reçoit des ressources dédiées, en général une base de données et souvent du compute. Isolation maximale et récit de conformité le plus simple — mais un plancher de coût par tenant et un problème de flotte : deux cents tenants, ce sont deux cents bases à migrer, sauvegarder, corriger et surveiller.
• Pool — tous les tenants partagent l'infrastructure, séparés par un tenant_id. Le coût marginal par tenant tend vers zéro, mais l'isolation devient la responsabilité de l'application et une seule mauvaise requête peut dégrader tout le monde à la fois.
• Bridge — du compute partagé sur des données séparées (schéma ou base par tenant), ou une flotte à plusieurs niveaux : infrastructure mutualisée pour l'offre standard, silos dédiés pour les tenants réglementés ou enterprise.

Pour les produits B2B, notre choix par défaut est un modèle pool derrière une abstraction de tenancy stricte, avec le silo vendu comme un niveau premium facturé — jamais adopté par réflexe. Une infrastructure dédiée que personne ne paie n'est pas de l'architecture : c'est une subvention.

L'isolation est une défense en couches, pas une clause WHERE

Une colonne tenant_id plus la discipline des développeurs ne constitue pas une stratégie d'isolation ; il suffit d'un filtre oublié pour aboutir à une notification de violation de données. L'isolation doit tenir même quand un développeur se trompe — imposez-la donc à plusieurs niveaux indépendants.

• Résolvez le contexte du tenant une seule fois en bordure — sous-domaine, jeton ou en-tête — et propagez-le dans chaque requête, job et événement ; rien en aval ne doit le re-dériver.
• Rendez les requêtes inter-tenants impossibles à écrire par accident : des repositories ou des query builders qui exigent le périmètre du tenant par construction, pas par convention.
• Activez la row-level security dans la base comme filet de sécurité : un filtre oublié fait échouer la requête au lieu de divulguer un jeu de données.
• Chiffrez les champs réglementés avec des clés par tenant, afin que l'offboarding et les demandes de suppression deviennent des opérations sur des clés, pas des parcours de tables.
• Maintenez une suite de tests automatisés d'accès inter-tenants ; tout échec y est un incident de sécurité, pas un ticket de bug.

Voisins bruyants : un problème d'équité, pas de capacité

Dans un modèle pool, la capacité est partagée ; sans règles d'équité explicites, le plus gros tenant fixe la latence de tous les autres, et davantage de matériel ne fait que relever le plafond d'un ordonnanceur inéquitable. Mesurez la consommation par tenant dès le premier jour : une poignée de tenants génère l'essentiel de la charge, et l'on ne gouverne pas ce que l'on n'attribue pas.

• Appliquez des limites de débit et des quotas par tenant au niveau de l'API, intégrés à la tarification des offres, pour que les limites soient un levier commercial, pas une excuse.
• Plafonnez la concurrence par tenant dans les files d'attente en arrière-plan — l'import massif d'un tenant ne doit jamais retarder les webhooks d'un autre.
• Définissez des timeouts d'exécution et routez les requêtes analytiques vers des réplicas ; le chemin transactionnel n'est jamais le lieu du reporting.
• À l'échelle d'une flotte, l'architecture en cellules et le shuffle sharding limitent le rayon d'impact des surcharges et des défauts de déploiement.

Une observabilité qui sait prononcer le mot tenant

La première question de tout incident SaaS est : qui est touché ? Si votre télémétrie ne peut y répondre en quelques secondes, vous avez des tableaux de bord, pas de l'observabilité. Faites de l'identité du tenant une dimension de premier ordre dans les logs, les traces et les métriques, et gérez la cardinalité de façon délibérée : fidélité complète dans les logs et les traces, top N plus agrégats dans les métriques.

Définissez des SLO par tenant au moins pour votre offre la plus haute et mesurez la consommation en continu. Les mêmes données répondent aux questions du support en quelques minutes, alimentent la tarification à l'usage et révèlent les clients que vous servez discrètement à perte.

Concevez la migration avant d'en avoir besoin

Quel que soit le modèle de lancement, un tenant devra un jour déménager : un contrat enterprise exige un silo, ou une flotte de silos devient trop coûteuse à exploiter. Le chemin de migration fait partie de l'architecture, ce n'est pas une réflexion après coup.

• Conservez le tenant_id sur chaque ligne, même dans les bases en silo — consolider des données sans lui relève de l'archéologie.
• Gardez des schémas identiques d'un silo à l'autre ; la dérive de schéma transforme silencieusement une migration en réécriture.
• Routez les tenants via une abstraction stable qui associe chaque tenant à l'emplacement de ses données, afin que cet emplacement change sans toucher à l'application.
• Répétez le déménagement : export limité au tenant, bascule par réplication, une courte fenêtre de double écriture et un rollback vérifié.

Le modèle avec lequel vous lancez ne sera pas celui avec lequel vous finirez. Le rôle de l'architecture est de faire de ce changement un projet planifié, pas une urgence à l'échelle de l'entreprise.