Architecture d'une plateforme B2B pour le suivi d'affiliation et l'attribution des revenus
Lors du développement d'une plateforme B2B commerciale dans le domaine du suivi d'affiliation et de l'attribution des revenus, l'un des défis principaux consistait à concevoir un backend capable de traiter un flux continu d'événements e-commerce externes sans compromettre la logique métier interne.
Concrètement, cela impliquait de séparer un noyau métier stable d'une couche d'intégration à forte charge. Sans cette séparation, les pics de trafic externes — commandes, mises à jour de statut, événements marketplace — auraient directement impacté les parties critiques du système comme la logique de commissions ou les règles financières.
Séparation du noyau métier et de la couche d'intégration
L'architecture reposait sur deux couches indépendantes.
Le noyau métier gérait tout ce qui devait rester stable : structures d'entreprise, hiérarchies de rôles, règles de commissions et logique financière. Cette partie du système devait être prévisible et strictement contrôlée.
La couche d'intégration, en revanche, traitait les données externes — événements entrants, flux de synchronisation et interactions marketplace. Elle était conçue pour absorber la charge et la variabilité sans propager cette complexité dans le noyau métier.
Cette séparation a permis de faire évoluer le système sous forte charge tout en maintenant la cohérence des processus internes.
RBAC et espace de travail multi-niveaux
Un autre élément important du système était le modèle d'espace de travail interne et de contrôle d'accès.
Pour une plateforme B2B multi-utilisateurs, nous avons implémenté un système Role-Based Access Control (RBAC) à plusieurs niveaux.
Le contrôle d'accès était appliqué non seulement au niveau de l'interface, mais aussi sur les routes, les opérations de données et les endpoints API. C'était essentiel car différents rôles — propriétaires d'entreprise, managers, opérateurs, agents, observateurs — interagissent tous avec le même système de manières très différentes.
À mesure que le nombre de rôles et d'entités augmentait, ce modèle a permis de garder le comportement prévisible plutôt que chaotique.
Architecture API hybride
La couche API suivait une approche hybride.
Pour les opérations standard, les endpoints CRUD étaient générés à partir des modèles du domaine et d'une infrastructure partagée. Cela maintenait un développement rapide et cohérent.
Mais pour la logique critique — opérations financières, agrégations, tableaux de bord, routage personnalisé — tout était implémenté manuellement. C'étaient les parties où perdre le contrôle n'était pas envisageable.
Au final, cet équilibre entre automatisation et contrôle manuel a permis d'avancer rapidement sans introduire d'instabilité dans le système.