Diagramme d'architecture SaaS multi-tenant : modèles silo, pool et pont

Dessinez un produit SaaS multi-tenant comme la plupart des équipes dessinent n'importe quel système, et il ressemblera trait pour trait à un système mono-tenant : une passerelle, quelques services, une base de données. La propriété la plus importante du système, à savoir quelles données de quel client peuvent se retrouver où, n'apparaît nulle part. C'est pourtant elle qui conditionne les décisions les plus difficiles : comment isoler les locataires (tenants), comment servir les gros clients, comment fonctionne l'onboarding et ce qu'un voisin bruyant (noisy neighbor) peut casser.

Ce guide montre comment rendre la dimension multi-tenant visible sur un diagramme d'architecture : le vocabulaire, ce qu'il faut montrer, les modèles silo, pool et pont (bridge), et un exemple qui combine ressources partagées et ressources dédiées.

Le vocabulaire

Les termes ci-dessous sont courants dans les écrits sur l'architecture SaaS, y compris dans les recommandations SaaS d'AWS :

• Locataire (tenant). Une organisation cliente, avec ses propres utilisateurs et ses propres données.
• Plan de contrôle (control plane). Les services qui gèrent les locataires au lieu de servir le produit : onboarding, registre des locataires (tenant registry), identité, mesure de la consommation et facturation.
• Plan d'application (application plane). Le produit lui-même : les services et les stockages de données que les locataires utilisent au quotidien.
• Contexte locataire (tenant context). L'ID de locataire qui accompagne chaque requête, le plus souvent sous forme de claim dans le jeton d'accès.
• Silo. Des ressources dédiées à un seul locataire, comme une base de données séparée ou une stack complète.
• Pool. Des ressources partagées par de nombreux locataires, séparées par des politiques et par l'ID de locataire.
• Pont (bridge). Un mélange des deux : par exemple du calcul partagé avec des bases de données dédiées pour certains locataires.

Ce que le diagramme doit montrer

1. D'où vient le contexte locataire. Le fournisseur d'identité et le claim du jeton qui porte l'ID de locataire.
2. Où l'isolation est appliquée. Pas « dans le code », mais à un endroit précis : une politique de sécurité au niveau des lignes (row-level security), un schéma par locataire, une base de données séparée, une politique IAM.
3. Quelles ressources sont partagées et lesquelles sont dédiées. Indiquez sur chaque stockage de données et chaque service s'il est en pool ou en silo.
4. Comment une requête trouve ses ressources. Le routage ou la recherche (lookup) qui envoie un locataire vers la bonne base de données ou la bonne stack.
5. Comment les locataires sont créés. Le flux d'onboarding qui écrit dans le registre et provisionne les éventuelles ressources dédiées.

Silo, pool et pont

Modèle	Ce qui est partagé	Points forts	Coûts
Silo	Rien dans le plan d'application	Isolation forte, réglages par locataire, réponses de conformité plus simples	Coût par locataire plus élevé, davantage de déploiements à exploiter
Pool	Calcul et données, séparés par l'ID de locataire	Faible coût par locataire, un seul déploiement	L'isolation dépend de chaque requête et de chaque politique ; voisins bruyants
Pont	Certaines couches partagées, d'autres dédiées	Investir dans l'isolation là où elle compte	Deux chemins à construire, tester et dessiner

Beaucoup de produits démarrent en pool, puis déplacent leurs plus gros clients ou les plus réglementés vers des silos, ce qui transforme le système en pont. Le diagramme doit rendre cette séparation évidente.

L'exemple : des locataires en pool et un silo entreprise

Un produit d'analytics B2B compte des centaines de locataires standard et un client entreprise, Globex, qui exige sa propre base de données :

• Les utilisateurs se connectent via un fournisseur d'identité qui connaît les locataires. Leur jeton d'accès porte tenant_id.
• La passerelle API valide le jeton et transmet le contexte locataire à l'API d'analytics.
• L'API d'analytics cherche le niveau d'offre (tier) et la base de données du locataire dans le registre des locataires.
• Les locataires standard partagent une base PostgreSQL mutualisée, où la sécurité au niveau des lignes filtre chaque requête par tenant_id.
• Globex dispose d'une base de données dédiée, provisionnée par le service d'onboarding à la création du locataire.

Deux cadres séparent le plan de contrôle du plan d'application, et les étiquettes des stockages de données indiquent quel modèle d'isolation s'applique. Un relecteur peut désormais poser les bonnes questions : que se passe-t-il si le registre tombe, et qui peut changer le niveau d'offre d'un locataire ?

Règles pour les diagrammes multi-tenant

Dessinez des niveaux d'offre, pas des locataires

Ne dessinez jamais une boîte par client. Dessinez un chemin par niveau d'offre ou par modèle de déploiement, et nommez un locataire d'exemple si cela aide, comme Globex ci-dessus.

Indiquez le contexte locataire sur les liens

Écrivez comment le locataire est identifié à chaque étape : JWT tenant_id, header X-Tenant-Id set by the gateway, tenant_id in the message. Les jobs en arrière-plan et les consommateurs d'événements ont eux aussi besoin du contexte locataire, et c'est là qu'il se perd le plus souvent.

Montrez où l'isolation est appliquée

« Isolé par ID de locataire » est une promesse ; une politique de sécurité au niveau des lignes, un schéma par locataire ou un compte séparé est un mécanisme. Inscrivez le mécanisme sur le stockage de données ou ajoutez un nœud Politique à côté.

Montrez les limites par locataire

Les limites de débit, les quotas et les limites de concurrence par locataire sont ce qui permet à un système en pool de protéger les locataires les uns des autres. Notez-les sur la passerelle et sur les services qui les appliquent.

Gardez la mesure de la consommation et la facturation dans le plan de contrôle

Les événements d'usage par locataire alimentent la mesure de la consommation et la facturation. Dessinez-les dans le plan de contrôle, pour que le plan d'application reste concentré sur le traitement des requêtes.

Erreurs fréquentes

• Pas de plan de contrôle. L'onboarding, le registre des locataires et l'identité font partie du cœur de l'architecture ; ce ne sont pas des outils d'administration.
• Isolation par convention. Une note qui dit « chaque requête filtre par locataire » n'est pas un contrôle. Montrez la politique qui l'impose.
• Routage invisible. Si certains locataires utilisent des ressources différentes, dessinez la recherche qui en décide.
• Chemins asynchrones oubliés. Les files d'attente, les tâches planifiées et les exports d'analytics qui perdent l'ID de locataire sont une source classique de fuites.
• Un diagramme géant. Gardez la résidence des données (régions), le déploiement et la vue logique sur des diagrammes séparés.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez deux nœuds Cadre du pack Base, Control plane et Application plane.
3. Ajoutez deux nœuds Boîte du pack Base pour les utilisateurs standard et ceux de Globex, un Fournisseur d'identité du pack Sécurité, une Passerelle API du pack Cloud et des nœuds Conteneur du pack Modèle C4 pour le service d'onboarding et l'API d'analytics.
4. Ajoutez des nœuds Postgres du pack Données pour le registre des locataires, la base mutualisée et la base dédiée, avec le modèle d'isolation dans l'étiquette.
5. Étiquetez les liens avec le contexte locataire et passez le lien de provisionnement en tirets.

L'exemple utilise 11 nœuds de diagramme, ce qui tient dans l'offre Free. Pour la couche cloud et réseau en dessous, consultez le diagramme de VPC AWS et la page de cas d'usage cloud.

FAQ

Quel modèle d'isolation choisir ? Partez des exigences de vos clients et de votre coût par locataire. Le pool est le moins cher à exploiter, le silo le plus facile à expliquer à un auditeur sécurité, et le pont vous permet de proposer les deux. Écrivez la justification sur le diagramme.

Comment représenter des centaines de locataires ? On ne les représente pas. Montrez chaque niveau d'offre ou modèle de déploiement une seule fois, et laissez la liste des locataires dans le registre, là où elle a sa place.

Chaque locataire a-t-il besoin de son propre diagramme ? Non. Un diagramme par architecture, avec les niveaux d'offre dessus. Un locataire entreprise en silo peut avoir son propre diagramme de déploiement s'il tourne dans un compte ou une région à part.

Comment représenter la résidence des données ? Avec des cadres de région sur un diagramme de déploiement séparé, chacun contenant les stacks ou les bases de données des locataires qui doivent y rester.

Où placer les clés de chiffrement par locataire ? À côté des stockages de données qu'elles protègent, sous forme de nœud du pack Sécurité ou de note, avec le service de gestion des clés qui les conserve.

Commencez gratuitement — un siège, sans carte bancaire.