Laravel multi-locataire pour marketplaces et enseignes multi-marques : arbitrages architecturaux

Laravel multi-locataires recouvre deux problématiques très différentes souvent confondues.

Un marketplace regroupe de nombreux vendeurs indépendants qui ne se font pas confiance, avec des usages très inégaux, un onboarding en libre-service et une vitrine publique unique. Un groupe retail multi-marques compte quelques locataires sous un même propriétaire, des usages comparables, un onboarding maîtrisé et une vitrine distincte par marque. Ils partagent le terme locataire et presque rien d’autre.

Bien définir l’architecture suppose de clarifier ce que vous construisez, car plusieurs choix s’inversent selon le cas.

Résolution du locataire : la décision qui conditionne tout

Comment l’application identifie le locataire auquel appartient une requête. Trois réponses pratiques existent, non équivalentes.

• Domaine ou sous-domaine — brand-a.example.com, ou domaines totalement séparés. C’est la bonne solution pour le retail multi-marques, où chaque marque a besoin de sa propre identité, de sa propre surface SEO et de ses propres certificats.
• Préfixe de chemin — /sellers/acme/. Simple, économique, et tout reste sur un seul domaine, ce qui convient à une marketplace où seule la marque de la marketplace compte.
• Contexte utilisateur authentifié — aucun tenant dans l’URL. Adapté aux applications back-office, inadapté à tout ce qui expose une vitrine publique, car la même URL produit un rendu différent selon l’utilisateur et la mise en cache devient risquée.

Résolvez le tenant une seule fois, dans le middleware, avant toute autre exécution, et liez-le au conteneur. Chaque composant doit pouvoir demander qui est le tenant courant sans connaître la méthode de résolution — ce qui permet d’en changer ultérieurement.

Isolation des données

Nous avons couvert les trois modèles de multi-tenance — schéma partagé, schéma par tenant, base de données par tenant — et leurs implications économiques dans la comparaison des modèles de multi-tenance. Ici, seuls les aspects spécifiques à Laravel comptent.

Pour le schéma partagé, qui convient à la majorité des marketplaces :

• Appliquez la portée globalement, pas requête par requête. Les portées globales de Laravel fonctionnent, mais le contrôle le plus strict reste la sécurité au niveau des lignes dans la base de données — une portée globale peut être supprimée à la hâte par un développeur, une politique de base de données non.
• Rendez les requêtes sans tenant explicites. Faites lever une exception par votre modèle de base si aucun tenant n’est lié, afin qu’un job sans contexte échoue immédiatement au lieu de tout lire.
• Surveillez les requêtes brutes et le code de reporting. Les appels au query builder qui contournent Eloquent contournent aussi vos portées. C’est là que les fuites apparaissent.
• Indexez d’abord sur tenant_id dans les index composites, sinon chaque requête scanne plus que nécessaire.

Pour la base de données par tenant, adaptée aux groupes multi-marques avec de vrais besoins de séparation, la mécanique change : changement de connexion dans le middleware, migrations par tenant qui doivent tolérer les échecs partiels, et préfixe de cache et de file par tenant pour éviter toute fuite. Tout cela est bien documenté ; tout cela doit être automatisé avant d’avoir un volume réel de tenants, pas après.

Les files d’attente : point de rupture de la multi-location

C’est la partie la plus souvent mal implémentée, et celle qui génère les incidents les plus graves.

1. Sérialisez toujours le tenant dans le job. Un job qui résout le tenant à partir d’un contexte ambiant finira par s’exécuter dans le mauvais contexte, et l’erreur sera silencieuse et inter-tenant.
2. Restaurez le contexte du tenant au début de chaque job, et faites échouer immédiatement si le contexte ne peut être établi.
3. Isolez les tenants bruyants. Un vendeur important 200 000 produits ne doit pas retarder la confirmation de commande des autres. Séparez les files par type de charge au minimum, et appliquez des limites de débit par tenant si les tenants ne sont pas de confiance.
4. Faites itérer explicitement les commandes planifiées sur les tenants, avec une isolation des échecs par tenant — les données erronées d’un tenant ne doivent pas interrompre l’exécution globale.
5. Pensez aux jobs échoués. Une table de jobs échoués sans contexte de tenant est inutilisable à l’échelle, et relancer à l’aveugle conduit à des écritures inter-tenant.

Problèmes propres aux places de marché

Problèmes qu’un groupe multi-marques n’a jamais à résoudre :

• Gestion des paiements et règlements fractionnés. Une commande impliquant trois vendeurs correspond à un paiement et trois règlements, avec commission, remboursements, rétrofacturations et taxes correctement attribués. C’est souvent le problème métier le plus complexe, et il relève de la finance, non de l’ingénierie.
• Onboarding et vérification des vendeurs. Le libre-service implique des entrées non fiables à grande échelle — vérification d’identité, contrôle bancaire, détection de fraude.
• Contrôle qualité. Les données produits, images et prix proviennent de milliers de sources sans standard commun. Celui qui gère la qualité du catalogue contrôle l’expérience client.
• Planification équitable. Toute ressource partagée — files, indexation de recherche, limites d’API, génération de rapports — nécessite une politique d’équité, sinon le plus gros tenant monopolise la plateforme.
• Analytique à destination des vendeurs qui doit être rapide, isolée et incapable de révéler quoi que ce soit sur un autre vendeur.

Nous avons déjà construit ce type d’architecture — la marketplace multi-vendeurs de Scout Arabia et PriceGuru fonctionnent ainsi, sur une stack différente mais avec les mêmes problématiques structurelles. La plateforme e-commerce change ; la réconciliation des paiements reste identique.

Problèmes du commerce multi-marques

L’ensemble inverse :

• Catalogue partagé avec dérogations par marque. Un produit, vendu par trois marques, à trois prix, avec trois descriptions, et toute modification du produit de base doit se propager de façon prévisible.
• Reporting consolidé entre marques, tout en garantissant que chaque marque ne voit que ses propres données.
• Identité client partagée — ou non, délibérément. C’est d’abord une question juridique, avant d’être technique, et cela dépend de la juridiction.
• Thématisation par marque sans multiplier les bases de code. La discipline consiste à utiliser une bibliothèque de composants partagée avec des tokens de marque, et non à dupliquer les templates.
• Stock partagé entre marques, ce qui peut être un atout majeur ou une source de conflits constants selon le fonctionnement réel de l’entreprise.

Décisions à prendre avant d’écrire la moindre ligne de code

1. Un utilisateur peut-il appartenir à plusieurs tenants ? Adapter ce cas à un modèle d’authentification qui ne l’avait pas prévu est l’un des refactorings les plus complexes.
2. L’identifiant du tenant est-il public ? Dès qu’il apparaît dans les URLs et APIs, les clients s’y réfèrent et il ne vous appartient plus de le modifier.
3. Où stocker la configuration par tenant — dans les données du tenant ou dans un registre central ? Les deux approches fonctionnent ; les mélanger ne fonctionne pas.
4. Que se passe-t-il lors d’une fusion ou d’une scission de tenants ? Rare et difficile. Les marketplaces se rachètent ; les groupes de marques se restructurent.
5. Comment un tenant quitte-t-il la plateforme ? L’export complet et la suppression totale sont des obligations contractuelles dans la plupart des marchés, et il est bien plus difficile de les ajouter après coup.

C’est le travail que notre équipe Laravel réalise en amont de tout projet, dans le cadre de notre pratique plateforme Laravel. Pour les groupes de distribution, la structure multi-marques est la plus fréquente ; pour les plateformes de logistique ou de finance, on se rapproche généralement du modèle marketplace.

Commencez par valider le modèle

La résolution du tenant, l’isolation et le contexte de file sont des choix rapides à prendre mais coûteux à modifier. Nous les examinerons selon la structure que vous construisez réellement. Contactez notre équipe ; réponse sous un jour ouvré.