Développement de plateformes de marketplace multi-pays

Pourquoi la duplication échoue

La manière évidente de se lancer dans un nouveau pays consiste à copier le déploiement et à changer les paramètres. C’est rapide, et pendant un temps cela convient. Le problème arrive au troisième marché, lorsque chaque nouvelle fonctionnalité doit être développée, testée et publiée trois fois, et que les trois bases de données ont discrètement divergé.

À ce stade, le coût de consolidation est devenu tel que la plupart des équipes continuent de dupliquer, et l’expansion ralentit au rythme de ce que l’équipe technique peut porter.

Le pays comme frontière de tenant

L’alternative consiste à traiter le pays comme le tenant de premier niveau dès le premier jour. Devise, règles fiscales, catégories, pièces justificatives exigées, et prestataires de paiement, de livraison et de SMS disponibles deviennent de la configuration par marché plutôt que du code par marché.

Ouvrir un nouveau pays devient alors une tâche d’administration : un administrateur le crée, sélectionne les prestataires disponibles, définit les règles fiscales et publie. Aucun déploiement, aucune duplication, aucune seconde base de données.

Ce que cela implique

• Devise, fiscalité et règles tarifaires par pays
• Prestataires de paiement et de livraison sélectionnés par marché
• Catégories et pièces justificatives localisées
• Modèle de permissions couvrant les périmètres global, pays et commerçant
• Une identité client unique utilisable sur toutes les boutiques
• Boutiques en marque blanche sur les domaines des commerçants
• Une recherche dont le coût reste maîtrisé à mesure que le catalogue grandit

Ce que nous avons construit

Kolloh est une plateforme structurée exactement de cette manière : neuf applications dans un monorepo, avec un modèle de permissions à six rôles couvrant super-administrateur, administrateur pays, modérateur, propriétaire de commerce, personnel et client. L’autorité d’un administrateur pays s’arrête à son propre marché ; les modérateurs en reçoivent un sous-ensemble délimité.

Les commerçants disposent de boutiques en marque blanche sur leurs propres domaines — une vue filtrée et thématisée des mêmes données plutôt qu’une copie dupliquée, de sorte qu’une amélioration de la plateforme atteint toutes les boutiques en même temps. La recherche s’appuie sur Meilisearch auto-hébergé, retenu après comparaison du coût des services de recherche facturés à l’usage aux volumes attendus.

Un service Python distinct assure la prévision de la demande, la détection d’anomalies et l’estimation de la valeur vie client, afin que les opérateurs voient ce qui se passe sur l’ensemble des marchés et pas seulement à l’intérieur d’un seul.

Des décisions à prendre tôt

Deux choix sont coûteux à revenir. Le premier est de savoir si l’identité client est partagée entre marchés ou cloisonnée — le partage est presque toujours le bon choix, mais il doit être prévu dès la conception. Le second concerne les e-mails transactionnels : les envoyer depuis l’infrastructure de la plateforme plutôt que depuis le domaine de chaque commerçant paraît tatillon jusqu’au jour où le premier commerçant configure mal son SPF et où ses confirmations de commande cessent d’arriver.