Guide : architecture d'une plateforme B2B multi-locataire

Une plateforme B2B sert plusieurs entreprises clientes à la fois, chacune avec ses utilisateurs, ses données et ses règles. Les décisions prises dans les premières semaines, sur l'isolation des clients, les rôles ou la façon de compter l'argent, sont celles qui coûtent le plus cher à changer ensuite. Ce guide résume les choix que nous faisons, et pourquoi, sur les plateformes de banque professionnelle, de paiement et de gestion que nous construisons.

Trois questions avant de choisir une architecture

1. Quelle est la limite de responsabilité entre clients ? Une entreprise ne doit jamais voir les données d'une autre, même en cas de bogue. C'est le point de départ, pas une option.
2. Quelles règles ne doivent jamais être violées ? Un solde qui ne peut pas devenir négatif sans autorisation, une facture qui ne change plus une fois émise, une opération qui n'est exécutée qu'une seule fois.
3. Qui exploitera la plateforme ? Une petite équipe a besoin d'un système simple à déployer et à observer ; la sophistication se paie chaque jour en exploitation.

Monolithe modulaire ou microservices

Les deux fonctionnent, à condition d'être modulaires. Un monolithe bien découpé en modules, avec des frontières claires et une seule base de données, reste le choix le plus économique pour démarrer. Les microservices deviennent pertinents quand des parties du système évoluent à des rythmes différents, exigent des ressources différentes ou doivent être isolées pour la sécurité (par exemple, tout ce qui touche aux paiements).

• Avantages du monolithe modulaire : un déploiement, des transactions simples, un débogage direct.
• Avantages des microservices : isolation des pannes, montée en charge ciblée, équipes autonomes.
• Coût commun : sans frontières explicites entre modules, les deux finissent en enchevêtrement. Écrire les contrats entre modules, tester ces contrats, et garder une passerelle unique côté client sont les vrais garde-fous.

Le multi-locataire : isoler sans dupliquer

Trois modèles existent pour séparer les données des clients :

• Une base par client : isolation maximale, coût d'exploitation élevé, migrations à répéter autant de fois qu'il y a de clients.
• Un schéma par client dans une même base : bon compromis pour quelques dizaines de clients, plus fragile au-delà.
• Une ligne par client, avec un identifiant de locataire sur chaque enregistrement : le plus courant, à condition que l'identifiant soit imposé par le socle et jamais laissé au soin de chaque requête.

Quel que soit le modèle, le locataire courant doit venir de l'authentification, être propagé automatiquement à chaque accès aux données, et faire l'objet d'un test qui tente délibérément de lire les données d'un autre client.

Contrôle d'accès : rôles, permissions, journal

Le contrôle d'accès par rôles (RBAC) reste le plus lisible pour des utilisateurs métier : un rôle regroupe des permissions, un utilisateur reçoit des rôles par entreprise. Les règles dépendantes des données (un manager ne valide que les dépenses de son équipe) s'expriment par des conditions ajoutées aux permissions, sans basculer dans un système d'attributs difficile à auditer.

• Les permissions sont vérifiées côté serveur, à un seul endroit, jamais uniquement dans l'interface.
• Chaque action sensible est journalisée avec l'auteur, le locataire, l'objet et l'avant/après.
• Les rôles d'exploitation interne (support, administration) sont distincts des rôles clients et soumis au même journal.

L'argent et les invariants

Quand la plateforme manipule de l'argent, trois règles évitent la plupart des accidents : représenter les montants en entiers (centimes) et jamais en nombres à virgule flottante ; tenir un grand livre en partie double, où chaque mouvement a une contrepartie et où le solde se déduit des écritures plutôt que d'être modifié directement ; rendre chaque opération idempotente, avec une clé fournie par l'appelant, pour qu'un réessai réseau ne l'exécute pas deux fois.

Observabilité et exploitation

• Des journaux structurés, avec l'identifiant de requête et le locataire, corrélés entre services.
• Des indicateurs de santé par service et une page d'état interne.
• Des données de référence chargées au démarrage et versionnées, pour des environnements reproductibles.
• Un script d'installation unique, qui met un environnement complet en route en quelques minutes : c'est le meilleur test de la simplicité du système.

Liste de contrôle

• L'isolation entre clients est imposée par le socle et couverte par un test négatif.
• Les invariants métier sont écrits et vérifiés par des tests avant toute nouvelle fonctionnalité.
• Les permissions sont centralisées côté serveur et journalisées.
• Les montants sont des entiers, le grand livre est en partie double, les opérations sont idempotentes.
• Un environnement complet se lance avec une commande.
• Les frontières entre modules ou services sont documentées et testées.
• Une simulation de bout en bout (du premier utilisateur à la première facture) est rejouée à chaque version.

Conclusion

Une plateforme B2B tient par ses règles invisibles. Les fixer d'abord permet ensuite d'ajouter des modules vite et sans peur. C'est l'approche que nous avons suivie sur la plateforme SIIC, et que nous proposons dans nos développements sur mesure. Pour parler de votre architecture, contactez-nous.