Multi-Tenancy dans le Banking SaaS : Patterns d'Architecture et Pièges à Éviter
Guide pratique sur l'architecture multi-tenant pour les plateformes bancaires SaaS : modèles silo, pool et bridge, isolation des bases de données, sécurité des données, problème du voisin bruyant, conformité ACPR, AMF, RGPD, SecNumCloud et DORA, et anti-patterns fréquents à éviter.
Ce que signifie la multi-tenancy dans le banking SaaS
Une architecture multi-tenant désigne une configuration dans laquelle une seule instance d'application sert plusieurs clients indépendants - les tenants - depuis une infrastructure partagée. Chaque tenant dispose de son propre espace logique : ses propres comptes, sa propre configuration, ses propres données. Rien de cela ne déborde dans l'espace d'un autre tenant. L'opérateur de la plateforme maintient une seule base de code, et non une copie par client.
Pour un produit SaaS grand public, la multi-tenancy est un choix d'ingénierie classique. Pour une plateforme bancaire SaaS, elle revêt un poids différent. Les tenants sont des entités régulées. Leurs données comprennent des relevés de transactions, des données personnelles de clients, des conclusions AML et l'état du grand livre. Une fuite de données entre tenants n'est pas un ticket de support - c'est un incident réglementaire pouvant entraîner des sanctions, des obligations de notification et des dommages réputationnels qui peuvent fermer le business d'un client.
Pourquoi les banques et EME choisissent le SaaS
Lancement plus rapide, investissement initial réduit, pas d'équipe infrastructure propre et accès à une couche de conformité maintenue en continu, sans reconstruire les mêmes fondations à chaque fois.
L'exigence d'isolation
L'ACPR, l'AMF et les lignes directrices de l'EBA attendent que les données des tenants soient séparées de façon logique ou physique. La façon dont vous y parvenez conditionne toutes les autres décisions architecturales.
Le spectre des compromis
Plus d'isolation coûte plus cher en exploitation. Plus de partage est moins cher mais limite les clients que vous pouvez servir. Le bon choix se situe quelque part entre les deux, selon le profil de votre clientèle.
En France, l'ACPR et l'AMF appliquent des exigences précises sur l'externalisation des systèmes d'information bancaires, notamment à travers l'arrêté du 3 novembre 2014 sur le contrôle interne et les lignes directrices de l'EBA sur l'externalisation. La qualification SecNumCloud de l'ANSSI, bien que non obligatoire, représente le niveau de confiance le plus élevé pour les services cloud en France et est de plus en plus recommandée pour les données sensibles des établissements financiers. DORA, en vigueur depuis janvier 2025, s'ajoute à ce cadre avec des obligations de résilience opérationnelle numérique et de gestion des risques liés aux tiers ICT.
Discutons de votre projet et voyons comment nous pouvons lancer votre projet. produit bancaire numérique ensemble
Demander une démoModèles de tenancy : silo, pool et bridge
Il existe trois modèles fondamentaux. La plupart des plateformes bancaires en production aboutissent à une variante du troisième, mais comprendre les trois rend les compromis concrets.
| Modèle | Ce que cela signifie | Niveau d'isolation | Coût d'exploitation | Meilleure adéquation |
|---|---|---|---|---|
| Silo | Chaque tenant dispose de sa propre base de données dédiée, d'un cluster de calcul ou d'une pile complète. | Physique - maximum | Élevé - évolue linéairement avec le nombre de tenants | Titulaires de licence bancaire complète, grandes fintechs régulées avec exigences d'audit |
| Pool | Tous les tenants partagent la même base de données et le même schéma. Une colonne Tenant ID dans chaque table filtre les lignes. | Logique - le plus bas | Bas - le plus efficace | Produits SaaS à faible risque ; moins adapté au banking sans contrôles supplémentaires |
| Bridge | Couche applicative partagée, mais schémas séparés ou clusters BD dédiés par niveau de tenant. Les tenants premium bénéficient d'une plus grande isolation. | Mixte - configurable par niveau | Moyen - surcoût partagé, coût des ressources par palier | La plupart des plateformes bancaires servant une clientèle mixte |
BD-par-tenant vs. schéma partagé est une question liée mais distincte. Dans une configuration BD-par-tenant, les données de chaque tenant résident dans une base de données physiquement séparée. Les requêtes inter-tenants sont structurellement impossibles. Les migrations nécessitent un déploiement progressif sur N bases de données. Dans un schéma partagé, toutes les tables sont dans une seule base de données, les lignes portent un Tenant ID, et une clause WHERE manquante fait la différence entre une requête correcte et une violation de données.
Avantages de BD-par-tenant
- L'isolation physique satisfait la plupart des vérifications d'audit ACPR sans contrôles supplémentaires
- Les données du tenant peuvent résider dans une région cloud spécifique pour le respect du RGPD et des exigences de résidence des données
- Une compromission de la BD d'un tenant n'affecte pas les autres
- Sauvegarde et restauration indépendantes par tenant
Avantages du schéma partagé
- Une seule migration se déploie partout simultanément
- Le coût d'infrastructure par tenant baisse significativement à l'échelle
- Les analyses inter-tenants (agrégées, anonymisées) sont plus simples à construire
- La gestion du pool de connexions est bien plus facile à opérer
La plupart des plateformes bancaires SaaS matures utilisent aujourd'hui une approche bridge : une couche applicative partagée, des schémas ou bases de données séparés par tenant (ou par niveau de tenant) et un registre de métadonnées qui mappe chaque requête entrante au bon datastore. La couche applicative n'interroge jamais "tous les tenants" - elle résout le contexte du tenant depuis le token de requête et route vers un seul datastore.
Isolation des données et sécurité pour les tenants régulés
Pour une plateforme bancaire, l'isolation n'est pas qu'une question de performance - c'est une exigence de conformité. L'ACPR, l'AMF, les lignes directrices de l'EBA sur l'externalisation, DORA et le RGPD attendent que les données d'une entité régulée ne puissent pas être lues, modifiées ou supprimées par une autre. La façon de le démontrer dépend du modèle d'isolation choisi.
Row-Level Security (RLS)
Des politiques au niveau de la base de données qui appliquent un filtrage par tenant sur chaque requête, indépendamment de ce qu'envoie l'application. Si un bug applicatif envoie une requête sans filtre Tenant ID, la base de données renvoie zéro lignes plutôt que les données d'un autre tenant. Le RLS est le filet de sécurité sous un schéma partagé.
Bring Your Own Key (BYOK)
Chiffrement au repos avec des clés par tenant. Même sur une infrastructure partagée, les données chiffrées d'un tenant ne peuvent pas être lues par un autre. Le BYOK est de plus en plus requis par les tenants régulés et par les juridictions appliquant des règles strictes de souveraineté des données, notamment en France avec la stratégie cloud de confiance.
Contexte de tenant dans l'IAM
Les tokens d'authentification (JWT, OAuth) intègrent le Tenant ID comme claim. L'API gateway valide ce claim sur chaque requête et le propage tout au long de la chaîne d'appels. Une requête qui arrive sans claim de tenant valide est rejetée avant de toucher la moindre couche de données.
Résidence des données sous RGPD
Le RGPD exige que les données personnelles européennes restent dans l'EEE. Une plateforme bancaire SaaS qui sert des clients en France, en Allemagne et en Espagne doit démontrer que les données de chaque tenant sont stockées et traitées dans la bonne juridiction. BD-par-tenant dans des régions cloud géographiquement fixées est la solution la plus claire.
DORA, obligatoire dans toute l'UE depuis janvier 2025, ajoute une dimension de risque liée aux tiers ICT. Si votre plateforme bancaire SaaS est classifiée comme fournisseur ICT critique, les superviseurs de vos tenants - dont l'ACPR - peuvent conduire des visites de supervision directe. La documentation de l'architecture, les contrôles d'isolation et les procédures de réponse aux incidents deviennent des preuves dans ce processus.
En France, la stratégie cloud de confiance du gouvernement, structurée autour de SecNumCloud, place la protection des données financières sensibles comme priorité nationale. Les établissements bancaires français qui externalisent vers un SaaS doivent évaluer si leur fournisseur peut documenter des garanties équivalentes, même sans certification SecNumCloud stricto sensu. La CNIL peut également être impliquée dès lors que des données personnelles de résidents français sont traitées.
Le voisin bruyant, la mise à l'échelle et les compromis de coût
Le problème du voisin bruyant survient quand la charge de travail d'un tenant consomme une part disproportionnée des ressources partagées et dégrade les performances de tous les autres. Sur une plateforme bancaire, cela peut signifier des retards de traitement des transactions, des requêtes de solde plus lentes ou des timeouts d'API durant le cycle de réconciliation de fin de mois d'un grand tenant.
| Technique d'atténuation | Comment ça fonctionne | Compromis |
|---|---|---|
| Quotas de ressources | Limites de CPU, mémoire et IOPS par conteneur de tenant ou pool de connexions BD | Plafonne les performances de pointe pour les grands tenants ; peut nécessiter un réglage par niveau |
| Rate limiting | Limitation des requêtes au niveau de l'API par tenant, appliquée au gateway | Protège les services partagés mais peut bloquer les tenants à fort volume sans capacité dédiée |
| Routage par niveau de tenant | Les tenants premium sont routés vers des clusters haute performance dédiés ; les tenants standard partagent des pools optimisés en coût | Ajoute de la complexité de routage ; la frontière de niveau doit être bien définie dans les contrats |
| Décharge vers file asynchrone | Les opérations batch (réconciliation, génération de relevés) vont dans une file séparée, pas sur le chemin de l'API temps réel | Ajoute de la latence pour le travail batch ; les réponses temps réel restent protégées |
| Isolation BD-par-tenant | Les requêtes de chaque tenant s'exécutent contre leur propre BD ; pas d'I/O partagée | Élimine le voisin bruyant au niveau BD mais augmente le coût d'infrastructure |
La leçon pratique du fonctionnement des plateformes bancaires à grande échelle : concevez pour la charge de travail du tenant le plus lourd attendu dès le premier jour, pas pour le tenant moyen. Un seul grand client effectuant un batch de fin de mois peut révéler des goulots d'étranglement dans la base de données qui étaient invisibles à 10% de charge. La planification de capacité tenant compte de la charge du tenant au P99, et non au P50, évite la plupart des incidents en production.
Pièges courants et anti-patterns
La plupart des défaillances de multi-tenancy dans le banking SaaS tombent dans un petit nombre de patterns récurrents. Les reconnaître tôt coûte moins cher que de les découvrir lors d'un incident en production ou d'un audit réglementaire.
Il y a un méta-pattern derrière tous ces pièges : traiter l'isolation comme une réflexion après coup. Les décisions de conception de multi-tenancy prises dans le premier sprint d'une plateforme sont très difficiles à inverser une fois que de vrais clients sont à bord. Le coût de bien faire l'isolation dès le départ représente quelques semaines de travail d'architecture supplémentaire. Le coût de la remettre en place après un incident de données se mesure en mois de remédiation et en éventuelles actions réglementaires.
Comment Crassula gère la multi-tenancy
Crassula sert plus de 150 entreprises régulées - établissements de monnaie électronique, établissements de paiement et titulaires de licences bancaires - sur une seule plateforme. L'architecture multi-tenancy reflète des années de service à de vrais clients à travers de vrais audits réglementaires dans toute l'UE, y compris en France sous supervision ACPR.
Séparation des données par tenant
Les données financières de chaque client Crassula sont séparées logiquement au sein de la plateforme, avec le contexte de tenant appliqué à chaque couche depuis l'API gateway jusqu'au datastore. L'accès aux données inter-tenants est structurellement empêché, pas seulement contrôlé par politique.
Chiffrement et gestion des clés
Les données au repos et en transit sont chiffrées. Pour les tenants ayant des exigences plus strictes en matière de gestion des clés, y compris les clients dans des juridictions avec des attentes BYOK ou des exigences de souveraineté numérique proches du SecNumCloud, des configurations de chiffrement par client sont disponibles.
RGPD et résidence des données
Crassula traite les données en conformité avec le RGPD. Pour les clients ayant des exigences spécifiques de résidence des données, la plateforme prend en charge des configurations alignées sur les attentes réglementaires de l'UE et les orientations des superviseurs nationaux, dont l'ACPR et la CNIL.
Piste d'audit
Chaque action est enregistrée avec le contexte de tenant, l'identité de l'utilisateur, le timestamp et l'IP. La piste d'audit est immuable et couvre le cycle de vie complet de chaque enregistrement financier - requis pour l'AML, le reporting réglementaire et les revues de conformité côté client.
Préparation à DORA
En tant que prestataire ICT de services pour des entités régulées, Crassula maintient une documentation et des contrôles alignés sur les exigences de risques ICT tiers de DORA, soutenant les propres obligations DORA des clients face à l'ACPR et à l'AMF.
Évolutivité par conception
L'architecture de la plateforme gère une large gamme de tailles de tenants, des fintechs en phase initiale aux titulaires de licences établis. L'allocation des ressources évolue avec les besoins du client sans dégrader les performances des autres tenants.
Si vous évaluez des plateformes bancaires SaaS et souhaitez comprendre comment l'isolation, le chiffrement et les contrôles réglementaires sont mis en oeuvre - ou si vous concevez votre propre architecture multi-tenant et souhaitez comparer des approches - parlez à notre équipe. Nous sommes heureux d'en détailler les spécificités.
FAQ
La multi-tenancy signifie qu'une seule plateforme bancaire sert plusieurs clients indépendants (tenants) depuis une infrastructure partagée - chacun avec ses propres comptes, sa propre configuration et ses propres données, sans chevauchement. Pour l'opérateur de la plateforme, cela signifie maintenir une seule base de code plutôt qu'une copie par client. Pour les clients, cela signifie un embarquement plus rapide, un coût réduit et une couche de conformité et de sécurité maintenue en continu. L'exigence critique en banque est que l'isolation des données des tenants soit appliquée à chaque couche : API gateway, logique applicative et datastore.
L'isolation physique (modèle silo, BD-par-tenant) est la plus défendable lors d'un audit ACPR car l'accès aux données inter-tenants est structurellement impossible. Elle est cependant aussi la plus coûteuse à exploiter. La plupart des plateformes bancaires SaaS régulées utilisent une approche bridge : infrastructure applicative partagée avec des schémas ou bases de données séparés par tenant (ou par niveau de tenant), plus Row-Level Security comme filet de sécurité au niveau base de données. Le bon modèle dépend des obligations réglementaires de votre base de clients.
Les principaux mécanismes sont : (1) des bases de données séparées par tenant pour que les requêtes ne puissent physiquement pas traverser les frontières ; (2) des politiques Row-Level Security (RLS) au niveau base de données qui filtrent par Tenant ID sur chaque requête ; (3) le Tenant ID intégré dans les tokens d'authentification (claims JWT), validé au niveau de l'API gateway et propagé à travers chaque appel de service ; (4) des clés de chiffrement par tenant gérées via KMS ou HSM ; (5) la segmentation réseau au niveau de l'infrastructure. Une plateforme bancaire mature combine les cinq.
Les cinq les plus courants : (1) logique de tenant dispersée dans le code applicatif plutôt que résolue depuis un registre central - ajouter un tenant nécessite des changements de code ; (2) clauses WHERE manquantes dans des requêtes de schéma partagé renvoyant les données de plusieurs tenants ; (3) planification de capacité basée sur le tenant moyen alors qu'un ou deux grands tenants dominent la charge réelle ; (4) clés de chiffrement partagées entre tous les tenants - une compromission affecte tout le monde ; (5) logs d'audit sans contexte de tenant, rendant la revue réglementaire impossible. Tous ces patterns sont bien moins coûteux à traiter en phase de conception qu'après un incident en production.
Oui, quand elle est correctement mise en oeuvre. L'arrêté du 3 novembre 2014 sur le contrôle interne, les lignes directrices de l'EBA sur l'externalisation, DORA (obligatoire depuis janvier 2025) et le RGPD n'interdisent pas le SaaS multi-tenant. Ils exigent que les entités régulées puissent démontrer l'isolation des données, la complétude de la piste d'audit, les contrôles d'accès et la résilience opérationnelle - et que les contrats d'externalisation accordent des droits d'audit clairs à l'ACPR et à l'établissement. Une plateforme bancaire multi-tenant bien conçue satisfait ces exigences et peut fournir la documentation probatoire que les superviseurs comme l'ACPR et la CNIL attendent.
