Architecture multi-tenant

Principes d’isolation

Ressource	Stratégie	Remarques
Base de données	1 PostgreSQL par tenant	Mutualisation possible au niveau du cluster mais schémas isolés.
Stockage objet	1 bucket S3 par tenant	Séparation stricte des assets et exports.
Authentification	1 realm Keycloak par tenant	Support multi-organisation interne à un tenant.
Ingress	Domaine dédié	Certificats et routing configurés par tenant.
Cache	Redis partagé	Segmentation logique par tenant, app et version.

Partage intra-tenant

• Un tenant peut exposer plusieurs plateformes (domaines) avec branding distinct.
• Chaque plateforme agrège diverses applications (Insights/Impact) partageant un socle commun.
• Les ressources packagées dans une application (thèmes, data sources, modèles) sont verrouillées à la version publiée pour éviter les effets de bord.

Produits supportés

• Heva Insights : consomme intensivement le DataModel, le cache Redis et les composants UI packagés avec chaque app.
• Heva Impact (à venir) : exploitera les mêmes ressources d’isolation mais nécessitera des compute workers dédiés pour exécuter les simulations et stocker les scénarios.

Administration des ressources

• Provisioning initial : scripts automatisés pour instancier DB, bucket, realm et certificats.
• Catalogues internes : liste des data sources, thèmes et components approuvés pour le tenant.
• Politiques de réutilisation : duplication explicite entre tenants, partage libre au sein d’un tenant.

Observabilité tenant

• Métriques : consommation des quotas, latence des requêtes, taux de cache hit.
• Logs : centralisés mais étiquetés par tenant, app, version et nœud du DataModel.
• Traces : propagation des IDs de corrélation depuis l’UI jusqu’aux services backend.

En construction : documentation des stratégies de cloisonnement réseau (VPC, security groups, private links).