Le client est un courtier forex de détail établi en Asie du Sud-Est, au service d’une base de traders régionale majoritairement concentrée dans un seul pays — près de 97 % des clients enregistrés proviennent d’un marché domestique — avec, ailleurs dans la région, une longue traîne de traders expatriés. Son modèle d’acquisition est fortement porté par les IB : environ sept clients sur dix s’inscrivent via un partenariat avec un Introducing Broker, et un seul IB de premier plan a généré environ un tiers de l’ensemble des transactions de dépôt finalisées sur la plateforme.
Lorsque ce client a commencé à s’intéresser à Kenmore il y a plusieurs années, il exploitait déjà une activité forex et cherchait une plateforme capable de suivre la vitesse à laquelle il voulait tester de nouvelles marques orientées marché. Il ne voulait pas un déploiement « en une seule fois ». Il souhaitait une infrastructure qui lui permette de créer, renommer, mettre en veille et relancer des marques de trading au fur et à mesure de l’évolution de sa stratégie go-to-market — sans refaire la plateforme du back office à chaque fois.
Le premier déploiement Trader’s Room et CRM pour ce client a été réalisé en environ trois semaines, du contrat au système en production. Cette livraison incluait une Trader’s Room connectée à MetaTrader, un module IB multi-niveaux, l’intégration NinjaCharge en tant qu’agrégateur de paiements, un CRM avec des workflows personnalisés pour l’orientation des ventes et du support, la prise en charge multilingue et une couche de chat en direct.
La première marque régionale qui traverse le dataset pour cette étude de cas est passée en ligne au début du mois 1 de la période d’analyse. Dès le mois 2, le volume mensuel de dépôts avait dépassé le seuil que nous utilisons comme base pour mesurer la croissance indexée. Au mois 3, ce volume avait été multiplié par près de vingt par rapport à la base. Au mois 8, il avait atteint soixante-huit fois — le pic opérationnel.
Le CRM de Kenmore repose sur une notion que le client utilisait comme levier central de l’ensemble de sa stratégie de croissance : Regions. Une Region est une portion entièrement isolée et entièrement brandée de la plateforme, posée au-dessus du même back office. Chaque Region contient :
Ce qui reste unifié, c’est le cœur opérationnel : une seule équipe admin, une seule couche de reporting, un seul système de tickets, une seule hiérarchie IB, un seul pipeline KYC. Le client n’a jamais eu à choisir entre « on veut une nouvelle marque » et « on veut que notre équipe opérations reste productive dès le jour 1 ».
Pour ce courtier, cela signifiait qu’il pouvait tester des identités de marque à la manière dont la plupart des sociétés testent des landing pages — et il l’a fait. Sur l’ensemble de la relation, le client a déployé six marques régionales distinctes sur la plateforme Kenmore. Deux de ces marques font l’objet des données de cette étude de cas : une marque principale qui a porté le lancement, et une marque successeur commandée par le client environ dix mois plus tard pour tester une positionnement différent.
Le client est venu vers nous avec le besoin d’une Trader’s Room capable de gérer l’ouverture de comptes en direct et en démo, le téléversement des documents KYC, les demandes de dépôt et de retrait, ainsi que l’autonomie du trader pour les informations personnelles et l’historique du compte — le tout connecté à un CRM qui achemine l’activité entrante vers le bon personnel. Nous avons livré la Trader’s Room New Edition, avec le CRM intégré, en environ trois semaines. Au pic opérationnel, le système traitait plus de 1 100 tâches internes par mois — validations d’inscription, revues KYC, confirmations de dépôt, validations de retrait et ouvertures de comptes IB — sans outil de tickets séparé.
Les traders du client exécutent sur MT. Chaque Region de cette collaboration fonctionne avec son propre serveur de trading MT, configuré de façon indépendante. Lorsque le client a souhaité ajouter la deuxième Region, nous avons provisionné une connexion de service MT distincte afin que les deux marques ne partagent pas l’infrastructure de trading, même si elles partagent le back office. Les types de compte, les paliers de levier et les conventions de nommage des groupes sont définis par Region.
Le programme IB constitue le canal d’acquisition principal du client. Près de sept traders actifs sur dix sont attribués à un IB ou à un sous-IB. Kenmore a migré dès le jour 1 sa hiérarchie IB multi-niveaux existante vers la nouvelle plateforme, avec le suivi des URL de parrainage, des règles de commissions échelonnées, des options de partage des profits et une vue analytique « My IBs / My Traders » à l’intérieur de la Trader’s Room. Le système a été configuré de sorte qu’une lignée IB unique couvre les deux Regions — le client ne voulait pas fragmenter le suivi des commissions entre les marques.
NinjaCharge est l’agrégateur de paiements du client (une couche de routage située au-dessus des PSP, et qui n’est pas elle-même une PSP). Nous avons intégré plus de trente endpoints PSP derrière NinjaCharge sur des rails en devise locale — principalement VND pour le marché domestique, avec aussi des configurations pour MYR, THB, IDR et BTC pour les clients ailleurs dans la région. La visibilité PSP est contrôlée par Region : la deuxième Region est passée en ligne avec son propre ensemble PSP sélectionné, distinct de celui de la première Region. Parmi les plus de trente endpoints intégrés, environ deux tiers sont exposés publiquement dans la Trader’s Room à tout moment, le reste étant tenu en réserve.
Les dépôts passent par NinjaCharge avec une gestion automatisée des callbacks : le trader voit l’état en temps réel dans la Trader’s Room. Les retraits suivent un workflow manuel d’approbation piloté par des tâches dans le CRM, avec des règles de validation personnalisées demandées par le client (contrôles de solde, garde-fous de conversion de devise, vérification du nom du bénéficiaire selon le PSP). Tous les événements de dépôt et de retrait génèrent des tâches CRM, sont acheminés vers la bonne équipe d’opérateurs et sont réinjectés dans l’historique du compte du trader.
Le CRM est configuré avec six langues prises en charge, avec un texte maintenu par langue à la fois pour la Trader’s Room et pour les modèles d’e-mails. La détection de langue basée sur la zone géographique bascule le site orienté trader vers la bonne langue lors de la première visite.
Le client utilise des opérations de bonus et de crédit dans le cadre du parcours de commission IB et pour des campagnes promotionnelles. La plateforme permet d’ajuster les soldes en les routant via le même pipeline de tâches et d’approbations que les dépôts.
Chaque Region porte ses propres graphismes de marque — logo, palette de couleurs, header, footer, polices et CSS de thème personnalisé. Les deux Regions de ce dataset ont des identités visiblement différentes ; un trader qui atterrit sur l’une n’aurait aucun moyen de savoir qu’il s’agit du même CRM sous-jacent.
Un fil de développement sur mesure continu s’est déroulé en parallèle de la livraison du module standard tout au long de la mission. Le client avait des exigences spécifiques que le produit standard ne couvrait pas, et Kenmore a apporté corrections et améliorations à un rythme typique de quelques jours, et non de plusieurs semaines. Exemples tirés du journal de développement :
Le rythme de développement sur mesure fait partie de la raison pour laquelle le client est resté sur la plateforme pendant plusieurs années et plusieurs itérations de marque : lorsque son go-to-market évolue, la plateforme s’adapte en quelques jours, pas en quelques trimestres.
Vers le mois 10 de la fenêtre d’analyse — alors que la première Région continuait de publier des volumes de dépôts proches du pic — le client a commandé une deuxième Région. Le brief était simple : marque distincte, domaine distinct, serveur MT distinct, ensemble PSP distinct, mais géré par la même équipe dans le même CRM. Il voulait six semaines ; il a obtenu six semaines. Le détail :
Dès le début du mois 12, la deuxième Région enregistrait ses premiers traders. Au mois 14, elle avait atteint un niveau comparable à la première Région sur les nouvelles inscriptions mensuelles. Au mois 18, la deuxième Région traitait plus de volume de dépôts que la première. Au mois 20, la première Région avait été arrêtée et la deuxième Région portait 100% de toute la nouvelle activité — enregistrements, dépôts et comptes. La transition s’est faite sans changement de plateforme, sans migration de données, sans reformation des opérateurs : le même CRM, la même équipe d’administration, seule une autre Région a été activée.
C’est un cas d’école pour expliquer pourquoi l’architecture des Régions existe. La thèse de marque du client a évolué ; ses opérations n’avaient pas besoin d’évoluer.
En utilisant le mois 2 de la fenêtre d’analyse — le premier mois avec une activité de dépôt non négligeable — comme base d’index à 1× :
| Période | Indice du volume de dépôts | Notes |
|---|---|---|
| Mois 1 | 0,04× | Lancement en douceur |
| Mois 2 | 1,00× | Base |
| Mois 3 | 19,67× | Le premier cohorte IB passe en ligne |
| Mois 4 | 31,09× | |
| Mois 5 | 32,51× | |
| Mois 6 | 33,63× | |
| Mois 8 | 68,36× | Pic opérationnel (première Région) |
| Mois 10 | 33,39× | Pic en nombre de dépôts (227 sur un mois) |
| Mois 11 | 13,30× | La première Région ralentit ; deuxième Région commandée |
| Mois 14 | 6,86× | Deuxième Région en production |
| Mois 17 | 8,38× | La deuxième Région dépasse la première |
| Mois 18 | 24,33× | La deuxième Région porte le mouvement |
| Mois 20 | 42,90× | Pic propre à la deuxième Région ; première Région arrêtée |
La plateforme a absorbé deux vagues de croissance distinctes sur deux marques distinctes sans rien changer en dessous.
Les deux Régions présentent des caractéristiques de tunnel mesurables et différentes :
| Indicateur | Première Région | Deuxième Région |
|---|---|---|
| Part attribuée aux IB | 70,5% | 61,0% |
| Conversion des dépôts (inscrit → déposant) | 17,5% | 31,4% |
| Dépôts moyens par déposant | 6,4 | 5,5 |
La deuxième Région convertit les traders inscrits en déposants à un rythme presque deux fois supérieur à celui de la première Région. Même CRM sous-jacent, même équipe opérations, même couche PSP — marque différente, mix d’acquisition différent, comportement des traders différent. C’est un signal lisible que la thèse d’itération de marque du client fonctionnait.
Sur l’ensemble de la fenêtre d’analyse, le total des demandes de retrait représente un ratio d’environ 1,34:1 en équivalent USD par rapport aux dépôts effectivement réalisés. Notez que le côté dépôts et le côté retraits sont libellés dans des devises différentes et traités via des parcours opérationnels distincts — les dépôts transitent automatiquement par l’agrégateur PSP, tandis que les retraits passent par une file d’approbation manuelle — ainsi, ce ratio se lit le mieux comme : « la plateforme a maintenu un flux d’argent bilatéral équilibré, avec des traders payés à un rythme légèrement supérieur à ce qu’ils déposent dans n’importe quelle fenêtre donnée ». C’est une image de rétention saine pour un carnet de change de détail piloté par un IB.
Au pic opérationnel de fin d’Année 1, le CRM traitait plus de 1 100 tâches internes par mois — approbations d’inscription, revues KYC, confirmations de dépôt, approbations de retrait, ouvertures de comptes IB, tickets de support — le tout acheminé via un seul moteur de workflow. Le même moteur continue de gérer un volume plus faible et plus stable après la transition dans la Région.
Cet engagement est la démonstration la plus claire que nous ayons de ce que l’architecture des Régions de Kenmore permet. L’histoire n’est pas « nous avons déployé un CRM ». La plupart des fournisseurs de CRM peuvent déployer un CRM. L’histoire, c’est :
Délai de mise en ligne. La première Région du client est passée en production en environ trois semaines à partir du contrat. Leur deuxième Région — une marque entièrement distincte sur un serveur MT séparé, avec un ensemble PSP distinct — est passée en production en environ six semaines à partir du lancement, jusqu’à une QA entièrement terminée.
Itérations de marque sans re-plateformage. Lorsque la stratégie de mise sur le marché du client a évolué, ils n’ont pas migré. Ils ont ajouté une Région, l’ont montée en charge, puis ont laissé la Région précédente ralentir naturellement pendant que les IB et les traders basculaient. Aucune migration de données, aucune reformation des opérateurs, aucun temps d’arrêt.
Une équipe opérations unique pour plusieurs marques. Le même CRM, les mêmes équipes administratives, les mêmes workflows, le même pipeline KYC ont desservi simultanément deux Régions — et, à l’échelle de la relation plus large, en ont desservi six.
Rythme continu de développement sur mesure. Le produit standard de la plateforme n’a pas à s’adapter parfaitement « tel quel » en sortie de boîte. Des validateurs personnalisés, des workflows propres à la Région, des gestionnaires de taux en devise fixe, une logique de paiement spécifique PSP, ainsi qu’une longue traîne de petites améliorations ont été livrés avec une cadence de quelques jours. Le client capitalise sur une valeur sur mesure depuis des années.
Mise à l’échelle opérationnelle sous charge. La plateforme a absorbé une hausse de 68× du volume mensuel de dépôts sur une Région, puis un pic proche du même niveau dans une autre Région — simultanément, sur une infrastructure partagée, sans aucun remaniement architectural entre-temps.
C’est à quoi ressemble le moment où une société de courtage Forex cesse de considérer le CRM comme un déploiement fixe et commence à le voir comme une plateforme d’itération de marque.
| Métrique | Valeur |
|---|---|
| Temps de mise en ligne opérationnel (première Région) | ~3 semaines |
| Délai de mise en ligne pour la deuxième Région | ~6 semaines |
| Volume mensuel de dépôts au pic vs base | 68× |
| Pic de la deuxième Région vs base | 43× |
| Marques régionales actives sur un seul CRM | 6+ (à l’échelle de la relation plus large) |
| Points de terminaison PSP distincts intégrés via NinjaCharge | 30+ |
| Langues prises en charge | 6 |
| Connexions aux serveurs de trading MT | 2 (une par Région) |
| Part des clients attribuée aux IB | ~70% |
| Taux de confirmation par e-mail | ~89% |
| Taux d’approbation KYC | ~33% |
| Conversion Inscrit → Déposé | ~19% au total (~31% sur la deuxième Région) |
| Dépôts terminés moyens par déposant | 6+ |
| Ratio retrait/dépôt en équivalent USD | ~1,34:1 |
| Régions concurrentes sur le même CRM pendant la transition | 2 |
| Transition de Région : changement de marque avec aucune migration de données | ✓ |
L’architecture Regions de Kenmore permet aux courtiers de créer de nouvelles marques, de tester leur positionnement et de migrer leurs audiences — sans toucher au back office. Parlez-nous de votre activité.
Plusieurs marques. Un CRM. Zéro migration.
