Gouvernance unifiée sur 3 000+ points de vente

Situation

L’Occitane exploite un réseau retail de luxe de plus de 3 000 boutiques dans plus de 90 pays, avec trois clouds Salesforce câblés derrière. Sales Cloud gérait les comptes wholesale, Service Cloud le support à travers les régions, Marketing Cloud la fidélité et le CRM. Chacun avait pris sa forme propre au fil d’une décennie d’acquisitions, de déploiements régionaux et de décisions de plateforme localement justes à l’époque.

La conséquence visible : trois identités pour la même personne. Un client qui achetait en boutique à Paris, commandait en ligne à Tokyo et contactait le support à New York existait sous la forme de trois dossiers déconnectés, avec des identifiants différents, des historiques partiels et aucun contexte partagé. Les campagnes marketing exploitaient 30 à 40 % des données client disponibles. Les vendeurs ne voyaient pas l’historique d’achat en ligne. Les agents du service client traitaient les dossiers sans connaître le portefeuille produits.

Sur les 12 marchés APAC, le tableau était plus serré et plus douloureux. Les implémentations Salesforce régionales avaient divergé de l’architecture globale. Chaque marché avait développé ses propres patterns d’intégration, customisations de champs et modèle de données. Résultat : un environnement multi-cloud techniquement connecté et opérationnellement fragmenté.

Défi

Les clouds se parlaient. Le dossier client, lui, ne se parlait pas. Sales Cloud indexait sur l’identifiant de compte, Service Cloud sur le contact du dossier, Marketing Cloud sur l’e-mail. Aucune résolution d’identité systématique ne s’intercalait, de sorte que toute « vue unique » se reconstruisait à la main à chaque reporting.

L’intégration était batch nocturne et point à point. Marketing Cloud se synchronisait avec Sales Cloud la nuit. Service Cloud poussait les dossiers vers Sales Cloud via une API REST sur mesure. Le commerce restait entièrement hors écosystème Salesforce. La latence montait à 24 à 48 heures, chaque dépendance était un point d’échec potentiel, et aucune surface ne pouvait s’activer sur ce qu’un client venait de faire le matin même.

Le modèle de données portait par-dessus des années d’incohérence. Le nommage des champs différait d’un cloud à l’autre. La notion de « client » était modélisée de trois façons. Il n’existait aucun dictionnaire canonique, aucun propriétaire par entité, aucun contrôle de changement. Pour le programme Agentforce déjà à la feuille de route, cette fondation était insuffisante. Les agents intelligents ont besoin d’une vue client complète, actualisée, unifiée. Ils ne peuvent pas raisonner sur des fragments séparés par une fenêtre batch de 24 heures.

Ce que j'ai dit au comité de pilotage en semaine 3

Les agents finiront par atterrir. Le problème difficile n’est pas l’agent. C’est que le dossier client sur lequel il est censé agir n’existe pas encore.

Action

Le choix architectural a été de positionner Salesforce Data Cloud comme la couche de données client de l’ensemble du parc, plutôt que de construire une énième intégration entre clouds. Data Cloud devait ingérer depuis Sales, Service, Marketing et la plateforme e-commerce, résoudre les identités, porter le modèle canonique et activer en retour vers chaque surface depuis une seule source.

Avec la fondation de données en place, l’activation a été reconstruite sur trois surfaces. Marketing Cloud s’est reconnecté à Data Cloud pour la segmentation temps réel ; les segments sont passés de listes de contacts vieilles de 24 heures à des profils unifiés en direct. Experience Cloud a alimenté une nouvelle application mobile pour les vendeurs en boutique, posant une vue Customer 360 au point de vente. Service Cloud a reçu des fiches contextuelles Data Cloud, affichant historique d’achat et portefeuille produits directement dans la gestion des dossiers.

La couche de gouvernance est ce qui a fait tenir l’ensemble entre marchés. Un dictionnaire de données canonique définissait chaque entité partagée, désignait les propriétaires, fixait les règles de contrôle de changement. Des tableaux de bord qualité mesuraient complétude, exactitude et fraîcheur par cloud. Pour les 12 marchés APAC, un processus d’harmonisation a aligné les customisations régionales sur le modèle global, désigné des responsables de données régionaux et installé un monitoring de dérive pour que les écarts apparaissent en jours, pas à la prochaine migration.

Résultat

Le parc opère désormais sur un seul dossier client à travers les 3 000+ points de vente, boutique et digital combinés. La résolution d’identité a réduit les doublons de 85 % et produit un graphe client unique sur lequel chaque activation s’appuie.

Le marketing l’a senti en premier. Avec 2,5 fois plus de données complètes et une segmentation quasi temps réel, les campagnes ciblées ont gagné 40 % de conversion sur les deux premiers trimestres. Le temps de construction des segments est passé d’heures à minutes ; l’équipe a arrêté les vagues hebdomadaires et envoie aujourd’hui quotidiennement.

Les vendeurs ont adopté l’application Customer 360 rapidement. Ceux qui disposent de l’historique client complet réalisent 15 % de ventes incrémentales en plus grâce à des recommandations pertinentes. La résolution des dossiers au service client a baissé de 25 % : les agents ont cessé d’escalader pour trouver un contexte qui se trouve maintenant directement sur la fiche.

Le programme Agentforce qui dépendait de cette fondation est arrivé à l’heure. Trois pilotes ont été lancés sur le profil unifié, avec historique complet, activation temps réel et la même gouvernance que le reste du parc. Le dossier client est la contrainte que Agentforce révèle toujours, et L’Occitane l’a franchie avant que les agents n’entrent en service, pas après.

Recul

Ce motif fonctionne quand trois clouds ou plus partagent une entité client, quand la latence d’activation compte et quand la direction accepte que la fondation doit atterrir avant la couche suivante. C’est le bon choix quand un programme Agentforce ou Customer 360 figure déjà à la feuille de route, parce que la couche de données reste la contrainte de toute façon.

Cela fonctionne moins bien quand l’org n’a qu’un seul cloud et un seul marché en production. Le modèle canonique reste utile, mais le coût de Data Cloud face au bénéfice à cette échelle se justifie plus difficilement, jusqu’à ce qu’un second marché ou un second cloud devienne imminent.

À faire plus tôt : la couche de gouvernance. Les marchés dérivent le plus vite dans les 18 mois suivant un déploiement régional. Dictionnaire canonique, propriétaires nommés et monitoring de qualité au troisième mois épargnent la mission d’harmonisation au trentième.