Un responsable vendeur ouvre l’export de ses commandes et reçoit pendant quelques secondes le fichier d’une autre enseigne. La requête applicative filtrait correctement la base principale, mais la clé du cache ne contenait pas l’organisation. Le contrôle d’accès réussi à l’écran n’a donc pas protégé la donnée générée en arrière-plan.
Le problème devient un risque de fuite : dans le même système, un administrateur gère trois établissements, une agence opère pour deux vendeurs et le support doit reproduire un incident. Les rôles seuls ne suffisent plus : il faut savoir pour quelle organisation, quel périmètre et quelle durée chaque action est autorisée.
Le vrai enjeu d’une marketplace opérateur multi-tenant est de préserver une frontière d’organisation à travers toutes les surfaces, pas seulement dans les tables métier. Contre-intuitivement, ajouter tenant_id partout ne garantit rien si l’identité, les files, le stockage objet ou l’observabilité perdent le contexte.
Vous allez comprendre comment choisir les frontières, propager un contexte fiable, appliquer les droits et prouver l’absence de fuite. Le dispositif couvre requêtes synchrones, événements, fichiers, cache, recherche, support, migrations et incidents avec des owners et des scénarios de rollback.
Définir la frontière de tenant
Nommer l’unité réellement isolée
Le tenant peut être un vendeur, une entreprise cliente, un groupe ou une marque selon le modèle. Il ne doit pas être confondu avec un utilisateur ou un établissement. L’équipe liste données, règles, facturation et administration qui appartiennent à cette unité.
Une organisation peut posséder plusieurs boutiques, tandis qu’un prestataire intervient sur plusieurs organisations. Le modèle sépare tenant, organization, business_unit et user. Les relations portent statut, période et délégation plutôt qu’un raccourci dans le profil.
Classer les objets par portée
Chaque objet est global, tenant-scoped, partagé explicitement ou dérivé. Une catégorie de référence peut être globale ; un prix vendeur reste tenant-scoped ; un appel d’offres peut être partagé entre participants nommés. La classification détermine stockage et autorisation.
Le registre indique owner, identifiant de tenant, source de vérité et règle de partage. Une nouvelle entité ne part pas en développement sans cette décision. Le comité sécurité révise les exceptions partagées, qui sont les chemins de fuite les plus probables.
Modéliser identités et organisations
Résoudre le contexte après authentification
L’authentification prouve une identité ; elle ne choisit pas toujours le tenant actif. La session contient l’utilisateur, puis une sélection validée produit un tenant_context signé et à durée bornée. Le serveur recalcule les appartenances sensibles au lieu de croire un identifiant envoyé par le navigateur.
Le changement d’organisation invalide caches locaux et formulaires ouverts. L’interface affiche clairement nom, environnement et rôle actifs. Une action créée avant le changement est refusée si son contexte ne correspond plus, même lorsque l’utilisateur appartient aux deux tenants.
Gérer délégations et cycles de vie
Invitation, activation, suspension, départ et délégation sont des états historisés. Une agence reçoit une relation limitée à certaines fonctions et dates ; elle ne devient pas membre permanent du vendeur. Les accès hérités d’un groupe sont visibles dans le back-office.
Par exemple, si un collaborateur quitte une agence, alors ses sessions et jetons sont révoqués pour tous les mandats associés. Les tâches déjà lancées conservent une trace d’auteur mais ne gagnent aucun droit futur. Un owner côté organisation confirme les accès critiques.
Appliquer les autorisations partout
Combiner rôle, ressource et contexte
Le rôle donne une capacité générale ; la politique vérifie tenant, ressource, état et relation. « Voir les commandes » devient voir les commandes du tenant actif, éventuellement d’un établissement délégué et seulement pendant le mandat. La décision est centralisée dans un service testable.
Contrôleur, commande CLI, consumer et export appellent la même politique. Une route interne n’est pas implicitement sûre. Les entrées comprennent acteur, tenant, action et ressource ; la sortie fournit autorisation, motif, version de règle et identifiant de décision.
Refuser par défaut et réduire les privilèges
Une ressource sans contexte ou une action inconnue est refusée. Les comptes techniques obtiennent des scopes ciblés et des audiences précises. Les secrets ne sont jamais partagés entre tenants lorsque leur usage permet d’agir au nom d’une organisation.
Le parcours privilégié demande justification et durée. Si un rôle d’administrateur n’a pas été utilisé pendant la fenêtre définie, alors il rejoint une revue. Les droits retirés invalident jetons, sessions et jobs planifiés liés au périmètre.
Porter le tenant dans le modèle de données
Utiliser des clés impossibles à oublier
Les entités tenant-scoped portent une clé non nulle et leurs contraintes uniques l’incluent. Une référence de commande unique par vendeur devient (tenant_id, order_reference). Les clés étrangères empêchent de rattacher une ligne d’un tenant à la commande d’un autre.
Les repositories exigent un objet de contexte plutôt qu’un paramètre optionnel. Les méthodes globales sont rares, nommées et réservées à des services autorisés. Le code review repère les requêtes brutes, agrégations et jointures qui contournent cette convention.
Traiter les partages explicitement
Dupliquer une donnée de référence peut dériver ; la partager sans contrôle peut fuir. Une table d’accès relie ressource, tenant bénéficiaire, droit, émetteur et expiration. La politique vérifie cette relation sans changer la propriété initiale.
Un scénario crée deux tenants avec des identifiants métier identiques, puis tente lecture, modification et rattachement croisé. Si une contrainte ou une requête retourne la ressource voisine, alors la livraison est bloquée. Les fixtures multi-tenant deviennent obligatoires.
La preuve minimale exécute cent permutations entre les deux organisations sur chaque repository sensible. Si une seule lecture renvoie un objet voisin, ou si le compteur agrégé diffère du périmètre attendu, alors le pipeline échoue et publie la requête fautive. Le seuil de fuite toléré reste strictement nul.
Choisir une isolation de stockage
Arbitrer table, schéma ou base séparée
Une base partagée avec clé tenant simplifie les opérations et convient souvent au démarrage. Des schémas ou bases séparés renforcent certaines frontières mais multiplient migrations, connexions et restaurations. Le choix dépend du risque, des volumes, de la réglementation et des besoins d’extraction.
Une stratégie hybride peut isoler les tenants sensibles tout en gardant un modèle commun. Le routeur de connexion utilise le contexte validé, jamais un nom fourni librement. Le registre mappe tenant, emplacement, version et clés sans exposer les secrets au code métier.
Prévoir sauvegarde, restauration et sortie
Restaurer toute une base pour récupérer un seul vendeur peut réintroduire des données d’autres tenants. Le runbook définit export filtré, vérification, chiffrement et réconciliation. Une restauration en environnement isolé précède toute réinjection ciblée.
Le test annuel sélectionne un tenant, reconstruit commandes et pièces, puis compare comptes et empreintes. Le RPO et le RTO sont mesurés au périmètre promis. Un départ produit un paquet portable et une suppression vérifiée selon les obligations conservées.
Sécuriser API et événements
Propager un contexte vérifié
L’API déduit le tenant du jeton et de la ressource ; un header client seul ne fait pas autorité. Les logs gardent tenant, acteur et décision sans données sensibles. Les réponses ne révèlent pas l’existence d’une ressource voisine par un message différent.
Les événements embarquent tenant_id, type, version, corrélation et producteur. Le consumer valide le contrat et recharge les droits nécessaires. Une dead-letter queue conserve le contexte pour la reprise ; un opérateur ne peut pas rejouer l’événement sous un autre tenant.
Garantir idempotence et ordre local
La clé d’idempotence inclut tenant et opération. Deux vendeurs peuvent employer la même référence sans collision. Le séquencement est garanti par agrégat ou tenant lorsque le métier le requiert, pas globalement au prix d’un blocage généralisé.
Par exemple, si un webhook ancien tente de réactiver une offre suspendue, alors sa version est rejetée et le motif journalisé. Le monitoring distingue duplicata attendu, conflit de version et contexte absent. Le retry ne transforme jamais une erreur d’autorisation en succès.
Isoler fichiers, recherche et cache
Nommer et autoriser les objets
Les fichiers vivent sous un préfixe tenant non devinable, mais le chemin ne remplace pas l’autorisation. Le téléchargement passe par une décision serveur puis une URL signée courte. Métadonnées, miniatures et exports portent la même propriété.
Un antivirus ou transformateur reçoit contexte et destination attendue. Sa sortie ne devient publique qu’après contrôle. La politique de rétention supprime fichier, versions et liens temporaires ; le journal prouve le résultat sans conserver le contenu supprimé.
Inclure le tenant dans chaque index
Une clé de cache contient tenant, ressource, langue et version de politique. L’invalidation ne touche que le bon espace. Les caches partagés refusent toute entrée construite sans contexte afin d’éviter qu’une première réponse nourrisse le tenant suivant.
L’index de recherche stocke la portée et applique un filtre obligatoire côté serveur. Suggestions, facettes et compteurs sont testés, car ils peuvent révéler des noms sans retourner le document. Les jobs de réindexation traitent une cohorte et vérifient le nombre par tenant.
Scénario de recette : le cache est chauffé avec le profil du vendeur A, puis la même URL logique est demandée par le vendeur B. Si le nom, une facette ou un compteur de A apparaît, alors le déploiement s’arrête, les clés sont purgées et leur constructeur est corrigé avant nouveau canary.
Borner administration et support
Préférer la vue contrôlée à l’impersonation
Le support consulte d’abord une vue technique expurgée : statuts, corrélations et décisions. L’impersonation n’est ouverte que lorsqu’elle est nécessaire, avec ticket, motif, approbation éventuelle et expiration. Un bandeau permanent signale le tenant observé.
Les actions sensibles restent interdites ou demandent une élévation distincte. La session d’assistance ne peut pas exporter en masse ni modifier les droits. Son début, ses lectures critiques et sa fin alimentent un audit accessible à la sécurité.
Séparer administration globale et locale
Un administrateur de plateforme configure le socle ; un administrateur tenant gère ses membres et paramètres. Les interfaces, routes et policies restent séparées. Un compte local compromis ne doit pas atteindre une fonction globale par simple modification d’URL.
Les opérations de masse affichent périmètre, nombre ciblé et échantillon avant confirmation. Si un filtre tenant manque, alors la commande refuse de démarrer. Le rollback restaure les valeurs par journal de changement, sans écraser les modifications ultérieures légitimes.
Observer sans exposer
Corréler les signaux au bon périmètre
Métriques, traces et logs portent un identifiant tenant pseudonymisé lorsque nécessaire. Les dashboards opérationnels filtrent avant agrégation détaillée. Un vendeur ne voit jamais le volume ou les erreurs de son voisin via une page de statut personnalisée.
Les alertes détectent contexte absent, refus croisés, volume inhabituel et divergence entre tenant de session et ressource. Chaque alerte possède owner, seuil et runbook. L’échantillonnage des traces ne retire pas les événements de sécurité indispensables.
Rendre les preuves auditables
Une décision d’accès conserve acteur, tenant, action, ressource, résultat et version de politique. Les données fonctionnelles sensibles sont masquées. L’accès aux journaux suit lui-même une politique et une durée de conservation.
Si le taux de contexte absent dépasse zéro sur une route tenant-scoped, alors le déploiement est stoppé. Le tableau relie commit, service et appels concernés. Cette mesure transforme une convention de code en garde-fou exploitable.
Déployer configuration et migrations
Versionner les paramètres par tenant
Fonctionnalités, plafonds et intégrations sont des configurations typées avec défaut, portée, version et date d’effet. Une valeur locale ne copie pas toute la configuration globale. L’écran montre héritage, override et owner.
Le déploiement utilise une cohorte de tenants, des métriques et un kill switch. Une activation ne change pas le schéma attendu avant que les consommateurs soient compatibles. Le rollback remet la version précédente et conserve les écritures déjà produites selon un contrat documenté.
Migrer sans mélanger les organisations
Une migration volumineuse progresse par tenant et checkpoint. L’entrée, le nombre lu, le nombre écrit, les erreurs et la version sont journalisés. La file peut suspendre un tenant problématique tout en continuant les autres.
Le script vérifie avant/après : nombre d’objets, propriétés et références croisées. Si une clé étrangère pointe vers un autre tenant, alors le batch est annulé et placé en quarantaine. Aucune correction automatique ne devine le propriétaire.
Tester les fuites et répondre
Construire une matrice d’isolation
Les tests créent au moins deux tenants, des utilisateurs multi-appartenances, des homonymes et des objets partagés. Ils couvrent lecture, écriture, liste, export, cache, recherche, fichier, événement et administration. Chaque nouvel endpoint hérite de cette matrice.
Des tests property-based permutent tenants et identifiants. Le pipeline échoue si une réponse, une facette ou un temps de réponse révèle le voisin. Un pentest complète la couverture sur les chemins d’énumération et les outils internes.
Contenir une fuite présumée
Le runbook coupe la surface concernée, préserve les preuves, identifie tenants source et exposés puis révoque liens et jetons. Il évite les requêtes exploratoires qui étendent l’accès. Sécurité possède l’incident ; juridique et communication interviennent selon les faits.
Scénario : si un export contient une ligne d’un autre tenant, alors la génération est suspendue, les fichiers dérivés invalidés et la cohorte examinée par empreintes. Le retour en service exige cause corrigée, test régressif, rotation utile et décision formalisée.
Adapter la méthode et éviter les erreurs
Pour qui cette méthode convient
Elle convient aux marketplaces B2B ou B2C où plusieurs vendeurs, réseaux, acheteurs ou agences partagent une plateforme. Un petit produit peut retenir une base partagée, à condition d’appliquer contexte et tests sur toutes les surfaces. La sophistication suit le risque, pas le discours commercial.
Produit classe les objets ; architecture choisit les frontières ; sécurité gouverne policies et incidents ; équipes applicatives propagent le contexte ; SRE instrumente ; support applique les sessions contrôlées. Chaque responsabilité possède une sortie vérifiable.
Erreurs fréquentes en architecture multi-tenant
Faire confiance au tenant envoyé par le client, filtrer uniquement les listes, oublier les exports asynchrones, partager les clés de cache et donner au support un super-compte permanent sont les erreurs classiques. Elles créent des chemins différents autour d’une même frontière.
Une autre erreur consiste à choisir une base par tenant sans financer migrations, sauvegardes et restauration. L’isolation d’infrastructure ne remplace pas l’autorisation fonctionnelle. Le modèle retenu doit être exploitable un dimanche pendant un incident.
Plan d’action pour une marketplace multi-tenant
Semaines 1 à 4 : frontières et politiques
La première semaine inventorie utilisateurs, organisations, délégations et objets. L’équipe classe chaque donnée et dessine cinq parcours sensibles : connexion, export, recherche, webhook et support. Elle cherche où le contexte naît, change ou disparaît.
La deuxième attribue owners et écrit politiques. Les semaines trois et quatre renforcent contraintes, repositories, clés de cache et stockage objet. Une bibliothèque commune expose contexte et décision ; la matrice de tests crée deux tenants et bloque les lectures ou écritures croisées. Chaque exception documente son bénéficiaire, son approbateur, sa durée et la preuve attendue pour la supprimer. Le comité signe cette liste avant le canary.
Semaines 5 à 8 : canary et preuve
La cinquième semaine active l’instrumentation sur une cohorte. Le monitoring suit contextes absents, refus, caches, exports et files. Les migrations progressent par tenant avec checkpoint. Un kill switch retire la fonctionnalité sans supprimer les données produites.
Les semaines six et sept rejouent lien signé, cache chaud, événement ancien, délégation expirée et impersonation. La huitième exécute sauvegarde-restauration et incident de fuite présumée. Le go exige zéro accès croisé, des journaux interprétables et un rollback réalisé par l’équipe de run.
- À faire d’abord : nommer le tenant et classifier chaque objet du pilote.
- À tester ensuite : listes, identifiants directs, exports, caches et fichiers entre deux tenants.
- À différer : les délégations complexes avant la preuve du rôle local.
- À refuser : toute opération tenant-scoped dont le contexte ou la décision ne sont pas traçables.
Guides complémentaires pour l’opérateur
Structurer données et back-office
Le catalogue PIM marketplace aide à distinguer références globales et offres propres aux vendeurs.
Les écrans du back-office opérateur structurent membres, files, décisions et sessions de support.
Borner le premier périmètre
La méthode pour ouvrir une première catégorie aide à limiter tenants et objets du canary.
Le MVP marketplace avant ouverture permet de prioriser identité, commande et exploitation avant les délégations avancées.
Conclusion : une frontière vérifiable
Une marketplace multi-tenant fiable définit son unité d’isolation et la porte de l’identité jusqu’aux traitements asynchrones.
Autorisation, clés de données, fichiers, recherche, cache et observabilité appliquent le même contexte. Les partages restent explicites et temporaires.
La matrice de tests et les scénarios d’incident prouvent la frontière au lieu de la supposer. Le choix de stockage reste subordonné à une exploitation maîtrisée.
Pour concevoir cette architecture et ses garde-fous, Dawap peut vous accompagner dans votre marketplace opérateur.
