Une maison de luxe, un club de golf, un réseau alumni : trois clients avec des membres différents, des règles différentes, des administrateurs différents. Tous sur la même plateforme. Comment garantir que les données de chaque organisation restent dans son propre périmètre, même en cas d'anomalie logicielle ?
Le problème d'isolation
La première décision d'architecture dans un système multi-tenant est de choisir entre trois approches :
- Une base de données par tenant : isolation maximale, portée par l'infrastructure elle-même. Le coût opérationnel est plus élevé et les migrations doivent être appliquées sur chaque instance.
- Un schéma par tenant dans une même base : compromis courant, mais la gestion des migrations reste lourde et les bases de données relationnelles gèrent mal des centaines de schémas.
- Une base partagée avec discriminant : toutes les organisations partagent les mêmes tables, chaque ligne porte un identifiant de tenant. Simple à opérer, et l'isolation repose alors entièrement sur la discipline du code.
Nous avons choisi la première option : une base de données dédiée par client et par environnement. La frontière entre deux organisations est posée sous l'application, dans l'infrastructure. Le coût opérationnel de ce choix est absorbé par l'automatisation : Terraform crée chaque environnement à l'identique et un pipeline de déploiement commun livre la même version à tous.
Une instance RDS dédiée par client
Chaque client dispose de sa propre instance Amazon RDS, hébergée en région AWS eu-west-3 (Paris). Chaque instance est :
- accessible uniquement depuis le réseau privé de la plateforme ;
- chiffrée au repos ;
- protégée contre la suppression accidentelle ;
- sauvegardée automatiquement, avec 15 jours de sauvegardes conservées ;
- déployée en Multi-AZ pour les productions qui le demandent.
L'application d'un client détient uniquement les identifiants de sa propre base. Une requête mal écrite reste donc confinée au périmètre de l'organisation concernée.
Secrets, clés et paiements séparés
La base dédiée est la pièce maîtresse, et elle s'accompagne d'autres frontières propres à chaque client :
- Un secret dédié dans AWS Secrets Manager : identifiants de base et configuration sensible de l'organisation.
- Une clé de chiffrement dédiée : les données personnelles sont chiffrées au niveau applicatif en AES-256, avec un contrôle d'intégrité HMAC-SHA256. Chaque client a sa propre clé.
- Un compte Stripe Connect dédié : les flux financiers de chaque organisation restent dans son propre compte.
- Des fichiers médias rangés par client : photos et documents sont stockés dans Amazon S3 sous un préfixe propre à chaque organisation, chiffrés, avec l'accès public bloqué, et distribués via CloudFront.
La configuration par client
Chaque organisation a des règles différentes. Un réseau alumni peut autoriser les dons sans transaction monétaire. Un club de sport peut imposer une validation manuelle de chaque annonce avant publication. Une maison de luxe peut plafonner les prix pour éviter les reventes spéculatives. Plutôt que de multiplier les branches conditionnelles dans le code métier, nous centralisons ces paramètres dans la configuration de chaque client.
Les paramètres actuels incluent notamment :
- Activation de la validation manuelle des annonces
- Plafond de prix par catégorie
- Mode fair-play (limitation du nombre d'annonces actives simultanées par membre)
- Activation des échanges sans transaction (troc ou don)
- Click & collect activé ou désactivé
- Service concierge (prise en charge logistique par l'organisation)
- Validation des nouveaux membres (manuelle, whitelist email, SSO)
- Niveau de modération automatique des contenus
SSO par organisation
La grande majorité de nos clients souhaitent que les membres s'authentifient avec leurs identifiants d'entreprise ou d'institution, plutôt que de créer un nouveau mot de passe pour la marketplace. Plusieurs modes d'accès coexistent selon le type d'organisation :
- SSO OpenID Connect : pour les organisations dotées d'un fournisseur d'identité, comme Okta
- Passkeys (WebAuthn) : connexion par empreinte, visage ou code de l'appareil
- Lien magique : un lien signé (HMAC-SHA256), à usage unique, valable 5 minutes
- Whitelist de domaine email : inscription ouverte à quiconque possède une adresse
@organisation.com - Validation manuelle : l'administrateur de l'organisation approuve chaque demande d'accès
La configuration SSO appartient à chaque client et vit dans son propre environnement.
Modération indépendante
Chaque organisation dispose de son propre espace d'administration, branché sur sa propre base. Ses modérateurs voient les annonces, transactions et membres de leur organisation, et uniquement ceux-là. Vingt-deux rôles permettent de doser finement les droits de chacun, du modérateur d'annonces au responsable financier.
Les actions de modération (validation, rejet, suspension d'un membre, suppression d'une annonce) sont journalisées dans la base de l'organisation, qui conserve ainsi sa propre piste d'audit.
Ce que cette architecture permet
L'intérêt d'une base par client apparaît à l'exploitation comme en audit :
- Une charge confinée : l'activité d'une organisation reste dans son instance, et chaque base est dimensionnée selon l'usage réel du client.
- Des sauvegardes par client : une restauration concerne une seule organisation, à un instant choisi dans la fenêtre de sauvegarde.
- Une réversibilité nette : à la fin d'un contrat, les données d'un client forment un ensemble identifiable, exportable puis supprimable d'un bloc.
- Un audit lisible : un DSI peut vérifier que sa base, son secret et sa clé de chiffrement lui sont propres.
La contrepartie, c'est un parc de bases à maintenir. L'automatisation la rend soutenable : chaque nouvel environnement naît de la même définition, et chaque évolution est appliquée partout par le même pipeline. C'est un investissement d'ingénierie que nous considérons comme fondamental.