Situation
Suntory Global Spirits, l’un des leaders mondiaux des spiritueux haut de gamme, remplaçait ses processus de vente manuels, gérés par tableurs, en Corée et à Taïwan par Salesforce Consumer Goods Cloud. Il s’agissait d’un déploiement en terrain vierge : aucune infrastructure CRM existante, aucune donnée à migrer, aucune configuration de base sur laquelle itérer. Chaque décision architecturale devait être prise à partir de zéro.
Le projet couvrait simultanément quatre centres géographiques : le siège du client en Espagne définissait la stratégie, la capacité de développement offshore était répartie entre le Royaume-Uni et l’Inde, et deux équipes locales en Corée et à Taïwan allaient effectivement utiliser la plateforme. Chaque centre avait ses propres priorités, sa propre interprétation des exigences et sa propre compréhension de ce que « terminé » signifiait.
Les enjeux étaient clairs : Consumer Goods Cloud allait devenir le socle opérationnel utilisé par les commerciaux terrain en Corée et à Taïwan pour gérer leurs tournées, exécuter les visites en point de vente, saisir les commandes et remonter les données d’exécution au siège. Si l’architecture ne reflétait pas le fonctionnement réel de ces marchés, la technologie serait rejetée au moment de l’adoption, quelle que soit la qualité de sa réalisation.
Défi
Les déploiements en terrain vierge présentent une catégorie de défis architecturaux que les migrations ne posent pas. Dans une migration, il existe une base de référence, même imparfaite, qui définit les contours du problème. En terrain vierge, chaque décision de conception crée un précédent. Le modèle de données choisi au premier jour détermine ce qui sera possible ou non au quatre-vingt-dixième.
Consumer Goods Cloud ajoute sa propre complexité. Le produit est conçu pour l’exécution des ventes terrain : planification des tournées, modèles d’audit en point de vente, gestion des commandes et analyses d’exécution commerciale. Mais « conçu pour » ne signifie pas « préconfiguré ». Les objets et processus standards exigent des décisions architecturales conséquentes : hiérarchies de comptes pour les enseignes de distribution, structures du catalogue produits, conception des modèles de visite, fonctionnement mobile hors connexion — avant de ressembler à une plateforme de vente terrain fonctionnelle.
La coordination entre quatre zones géographiques aggravait cette difficulté. Le siège en Espagne détenait la gouvernance stratégique et contrôlait les décisions. Le Royaume-Uni et l’Inde disposaient de la capacité de développement et travaillaient sur des fuseaux horaires différents. La Corée et Taïwan détenaient la connaissance opérationnelle — la réalité terrain qu’aucun cahier des charges ne capture pleinement. Le risque était que l’architecture soit conçue pour satisfaire les exigences du siège, construite par des équipes offshore n’ayant jamais rencontré un commercial terrain coréen, et livrée à des utilisateurs dont le flux de travail réel n’avait jamais été correctement compris.
Le désalignement du périmètre dans les programmes multi-géographies n’échoue pas de manière visible. Il échoue silencieusement : une plateforme qui fonctionne techniquement mais que les équipes terrain ne font pas confiance, n’utilisent pas, et finissent par contourner.
Action
Définition de l’architecture et conception du flux commercial
La première phase a été l’architecture avant la configuration. Avant tout paramétrage de Consumer Goods Cloud, le modèle de données commercial a été défini : comment Suntory Corée et Taïwan conceptualisaient leur hiérarchie de comptes (enseignes nationales, distributeurs régionaux, points de vente individuels), comment les produits s’articulaient dans le catalogue de vente, ce qu’une « visite » signifiait en termes opérationnels, et comment les données d’exécution devaient remonter vers le reporting du siège.
Ce travail a été mené dans les deux sens : du siège vers le terrain pour définir les standards globaux non négociables, et des équipes locales vers le siège pour capturer la réalité opérationnelle que ces standards devaient prendre en compte. Le livrable était une spécification architecturale que le siège et les marchés locaux avaient examinée et validée avant le début du développement.
La configuration de Consumer Goods Cloud a ensuite été construite selon cette spécification : hiérarchie de comptes, catalogue produits, structures de tournées, modèles de visite et flux de gestion des commandes. Le fonctionnement mobile hors connexion a été configuré dès le départ — les commerciaux terrain des deux marchés travaillaient dans des environnements de distribution où la connexion réseau n’était pas fiable.
Passerelle de livraison intercontinentale
Le risque structurel de livraison résidait dans le fossé entre la prise de décision du siège et la réalité des marchés locaux, avec la médiation d’une équipe de développement offshore éloignée des deux. Le rôle que j’ai joué était celui de couche de traduction : convertir les directives stratégiques du siège en spécifications de développement techniquement sans ambiguïté, et convertir les exigences opérationnelles des marchés locaux en périmètre que le siège accepterait.
Cela a nécessité de travailler simultanément sur trois fuseaux horaires et de maintenir l’alignement entre des parties prenantes aux priorités contradictoires. Lorsque le siège poussait pour un modèle de visite globalement standardisé, les marchés locaux objectaient avec des différences opérationnelles légitimes. Lorsque l’équipe offshore interprétait les exigences de manière ambiguë, les tests des marchés locaux mettaient en lumière l’écart. La fonction d’architecture consistait à absorber ces conflits avant qu’ils ne deviennent des échecs de livraison.
Chaque exigence touchant aux opérations des marchés locaux a été validée directement avec les équipes terrain en Corée et à Taïwan — pas via des relais au siège, pas via des cahiers des charges, mais à travers des sessions de travail avec les personnes qui allaient utiliser la plateforme. Cela a permis de capturer les nuances opérationnelles que les processus d’expression de besoins descendants manquent systématiquement.
Déploiement et transfert de compétences
Les tests d’acceptation utilisateur ont été structurés par marché, avec les responsables locaux validant les flux de travail de leur marché avant acceptation. La formation a été dispensée sous forme de sessions spécifiques par rôle et par flux de travail : comment un commercial terrain coréen exécute une visite en point de vente avec Salesforce, et non comment Consumer Goods Cloud fonctionne en tant que produit.
Un transfert de compétences structuré vers les administrateurs Salesforce locaux en Corée et à Taïwan a garanti que les équipes responsables du support continu comprenaient les décisions architecturales et pouvaient maintenir la plateforme sans dépendance vis-à-vis de l’équipe projet.
Résultat
Consumer Goods Cloud a été déployé en production en Corée et à Taïwan en quatre mois, sans aucun désalignement de périmètre entre la vision stratégique du siège et l’exécution sur les marchés locaux. Toutes les exigences des marchés locaux ont été livrées — non pas comme un compromis sur les standards globaux, mais comme une prise en compte architecturalement rigoureuse de la réalité opérationnelle au sein du cadre global.
La coordination de livraison sur quatre zones géographiques a produit une plateforme que les équipes terrain des deux marchés ont adoptée. Le véritable test d’un déploiement Consumer Goods Cloud ne se joue pas à la recette fonctionnelle — il se joue au moment où les commerciaux terrain ferment leur tableur et ouvrent Salesforce à la place. En Corée et à Taïwan, c’est ce qu’ils ont fait.
L’architecture a établi un socle numérique propre. Aucune dette technique héritée, aucune personnalisation non documentée, aucune complexité d’intégration accumulée par des années de croissance non planifiée. Consumer Goods Cloud sur ces marchés est positionné pour l’extension — des agents Agentforce optimisant la planification des tournées, analysant les données d’exécution commerciale en temps réel et suggérant les prochaines actions prioritaires lors des visites en point de vente sont techniquement réalisables sur cette fondation dès le premier jour. L’architecture a été conçue pour être prête pour l’IA avant même que la capacité IA ne figure sur la feuille de route du projet.
Technologies utilisées : Salesforce Consumer Goods Cloud, Salesforce Mobile (configuration hors connexion), Sales Cloud, types d’enregistrement standards et personnalisés, moteur de modèles de visite, gestion des tournées, configuration du porte-documents mobile hors connexion
Related Case Studies
Gouvernance unifiée sur 3 000+ points de vente
Vue client unifiée sur 3 000+ points de vente grâce à une architecture multi-cloud
Unified Governance Across 3,000+ Retail Touchpoints
Unified customer view across 3,000+ retail touchpoints with multi-cloud architecture