Étude de cas
Architecture Customer 360 pour une marque de mode mondiale
Portefeuille CRM de 2M€+ livré dans les délais avec 50+ risques stratégiques neutralisés
Le problème
Lacoste devait unifier son architecture CRM mondiale autour d'une vision Customer 360 : une vue unique et complète de chaque client à travers caisses en boutique, e-commerce, marketing, service, fidélité et comptes B2B wholesale. La mission impliquait de piloter un portefeuille de 2 M€+, d'aligner six entités métier derrière une vision architecturale unique, de mobiliser une équipe de 30 personnes et d'obtenir la validation du comité exécutif mondial pour une feuille de route à 5 ans.
Ce que j’ai fait
Une couche de données client unifiée a été conçue avec identité canonique, relations de foyer et schémas d'ingestion par canal. Un processus structuré en amont a cartographié plus de 50 risques stratégiques avec des plans d'atténuation définis avant le début de la livraison. La feuille de route à 5 ans a été construite pour la communication au comité exécutif : phases d'investissement claires, jalons de capacités, liens explicites entre architecture et résultats métier.
En un coup d'œil
- Client
- Lacoste
- Secteur
- Luxe · Retail
- Mission
- 7 mois
- Mon rôle
- Lead Solution Architect, Customer 360 et Gouvernance de programme
- Clouds Salesforce
- Sales Cloud · Service Cloud · Marketing Cloud · Commerce Cloud
- Résultat
- 50+ risques stratégiques neutralisés
Avant / Après
- Six entités métier, six versions du même dossier client.
- Intégrations point à point entre caisses, e-commerce, marketing, service, fidélité, wholesale.
- Aucune définition canonique du client partagée par les six entités métier.
- Aucun processus structuré d'identification des risques ; conditions d'échec apparaissant tard dans la livraison.
- Aucun engagement du comité exécutif sur une direction architecturale pluriannuelle.
- Couche de données client unifiée avec identité canonique sur les six canaux.
- Schémas d'ingestion définis par source plutôt qu'intégrations au cas par cas.
- Six entités métier alignées derrière une définition architecturalement cohérente.
- 50+ risques identifiés en amont, tous résolus avant de devenir des problèmes de livraison.
- Validation par le comité exécutif mondial d'une feuille de route digitale à 5 ans.
Situation
Lacoste, la maison de mode française, devait unifier son architecture CRM mondiale autour d’une vision Customer 360 : une vue unique et complète de chaque client à travers tous les points de contact et canaux. La mission consistait à piloter un portefeuille CRM de plus de 2 M€ et à obtenir la validation du comité exécutif mondial pour une feuille de route digitale à 5 ans qui définirait l’usage de Salesforce par Lacoste pour la demi-décennie suivante.
Les enjeux étaient élevés. Les programmes de niveau comité exécutif font l’objet d’un scrutin différent des missions de livraison standard. Chaque décision architecturale serait visible par les personnes qui contrôlaient le budget, le calendrier et la décision de poursuivre. La réussite devait être définie avant qu’une seule ligne de configuration ne soit écrite.
Six entités métier portaient le programme : retail en boutique, e-commerce, marketing, service, fidélité et B2B wholesale. Chacune produisait sa propre version du même client, sur son propre modèle de données, à sa propre cadence de mise à jour. La fonction architecture devait livrer une définition du « client » sur laquelle les six pouvaient s’accorder, puis concevoir la couche de données qui la faisait tenir.
Défi
« Customer 360 » est simultanément l’objectif le plus cité en CRM d’entreprise et le plus difficile à concrétiser. Il exige d’unifier des données générées par des systèmes fondamentalement différents : caisses en point de vente, plateformes e-commerce, automatisation marketing, service client, programmes de fidélité et comptes B2B wholesale. Chaque système génère sa propre version du même client. Chacun fonctionne avec son propre modèle de données, ses propres identifiants et sa propre cadence de mise à jour. Les unifier n’est pas un travail de configuration. C’est un problème d’architecture.
Le défi organisationnel était à la mesure du défi technique. Six entités métier devaient s’aligner derrière une vision architecturale unique. Une équipe transversale de 30 personnes devait exécuter en parallèle à travers plusieurs chantiers. Tout défaut d’alignement se serait traduit par un échec au lancement, et le programme n’avait aucune tolérance pour cette issue étant donné sa visibilité au niveau du comité exécutif.
Le profil de risque était également structurel. Les programmes de cette envergure font typiquement apparaître les conditions d’échec tardivement, après un investissement significatif, quand les modifications de périmètre sont coûteuses et la patience organisationnelle épuisée. La fonction architecture devait identifier et résoudre ces risques avant qu’ils ne deviennent des problèmes de livraison, et non après.
Ce que j'ai dit au comité exécutif mondial lors de la revue de kickoffAu moment où nous serons en pleine livraison, les décisions architecturales seront figées. Soit nous les prenons délibérément maintenant, avec la couche de données comme cible, soit les six entités métier les prendront par défaut via leurs propres systèmes.
Action
La fondation architecturale reposait sur une couche de données client unifiée résolvant l’identité à travers les six canaux : boutique, en ligne, wholesale, service, fidélité et marketing. Plutôt que de pallier les manques par des intégrations point à point entre systèmes existants, l’architecture a été conçue autour d’un dossier client unique faisant référence, avec des schémas d’ingestion bien définis pour chaque source.
Couche de données client unifiée
Définition canonique du client validée par les six entités métier. Règles de résolution d'identité combinant correspondance déterministe (identifiant fidélité, e-mail), relations de foyer et attributs de possession produit. Structure d'historique d'engagement partagée entre canaux. Champs obligatoires versus optionnels définis par point de contact, pour que chaque canal sache ce qu'il devait apporter et ce qu'il pouvait déléguer.
Architecture des risques et continuité opérationnelle
Processus structuré en amont cartographiant les 50+ risques stratégiques : intégration technique, qualité de données, alignement organisationnel, livraison prestataire, dépendances calendaires. Chaque risque catégorisé par sévérité et probabilité, avec un propriétaire nommé et un plan d'atténuation ou de contingence défini avant le démarrage de la livraison. Le registre fonctionnait en processus continu pendant la livraison, avec des protocoles d'escalade qui prévenaient l'apparition tardive.
Alignement des parties prenantes et feuille de route comité exécutif
La fonction architecture fournissait le cadre de résolution lorsque les entités métier avaient des exigences contradictoires. La feuille de route à 5 ans a été conçue pour la communication au comité : phases d'investissement claires, jalons de capacités, liens explicites entre architecture et résultats métier. La validation exigeait un engagement métier, pas seulement une approbation technique.
Définir « client » a pris plus de temps que configurer les intégrations. Six entités métier, chacune avec des perspectives légitimes mais différentes, devaient s’accorder sur règles de résolution d’identité, relations de foyer, attributs de possession produit et structure d’historique d’engagement. La fonction architecture tenait la ligne sur le modèle canonique et laissait à chaque entité de l’espace pour l’étendre là où son canal exigeait vraiment des champs locaux. Le résultat : un modèle que six entités possèdent, pas un compromis que personne ne respecte.
Résultat
Le portefeuille CRM de plus de 2 M€ a été livré dans les délais avec l’architecture Customer 360 opérationnelle dans les six entités métier. Les 50+ risques stratégiques identifiés en amont ont été résolus avant d’atteindre la phase de livraison. Aucun n’est devenu bloquant pour le lancement. Les six entités ont atteint l’alignement derrière l’architecture unifiée.
Le comité exécutif mondial a validé la feuille de route digitale à 5 ans, apportant l’engagement organisationnel qu’une architecture pluriannuelle requiert. L’équipe transversale de 30 personnes a exécuté la transformation avec une clarté de vision que les programmes multi-parties prenantes atteignent rarement.
L’architecture Customer 360 a également établi une fondation de données qui anticipe la direction de Salesforce. Data Cloud a été conçu précisément pour livrer la vue client unifiée qui a été architecturée chez Lacoste : résolution d’identité cross-canal, profil unifié comme base de toute activation, segmentation temps réel remplaçant les traitements par lots. La réflexion architecturale est identique, que l’implémentation repose sur de l’intégration sur mesure ou sur Data Cloud. La différence réside dans la rapidité d’exécution. Avec Data Cloud, la résolution d’identité et l’unification qui nécessitaient des mois en sur-mesure se configurent désormais en semaines. Les décisions architecturales sur ce qui définit un client, comment les canaux se relient et ce qu’exige le modèle d’activation ne changent pas.
Recul
Ce motif fonctionne quand le scrutin est élevé, quand l’alignement entre entités métier n’est pas négociable, et quand la direction accepte que la couche de données soit la décision architecturale plutôt qu’une conséquence en aval. C’est le bon choix quand une feuille de route comité exécutif est en jeu et que l’architecture doit dépasser les choix d’implémentation du moment.
Cela fonctionne moins bien quand il n’y a pas de budget de scrutin pour le travail amont sur les risques. Les registres de risques se compriment sous la pression et perdent leur valeur s’ils sont traités comme un livrable ponctuel plutôt que comme un contrôle continu.
À faire plus tôt : la définition canonique du client. Six entités métier peuvent en débattre pendant des mois une fois la livraison lancée. La fixer avant le kickoff est ce qui a rendu chaque décision d’intégration ultérieure possible sans rejouer la fondation.
Technologies utilisées : Salesforce Sales Cloud, Service Cloud, Marketing Cloud, couche d’intégration sur mesure, conception d’architecture de données, méthodologie de feuille de route stratégique, cadre de gestion des risques
Glossaire
- Customer 360
- Une vue unique et complète d'un client à travers chaque canal et point de contact. Dans le cas de Lacoste : caisses en boutique, e-commerce, automatisation marketing, service, fidélité, B2B wholesale. Définie à la couche d'architecture, pas à la couche de reporting.
- Résolution d'identité
- Le processus de rapprochement de plusieurs dossiers source (ticket de caisse, compte e-commerce, carte de fidélité, dossier de service) vers un seul client réel. Combine la correspondance déterministe sur identifiants partagés avec le regroupement probabiliste pour les points de contact anonymes.
- Architecture des risques
- Un processus structuré qui cartographie les risques d'un programme (intégration technique, qualité de données, alignement organisationnel, livraison prestataire, dépendances calendaires), classe chacun par sévérité et probabilité, et lui attribue un plan d'atténuation ou de contingence avant le démarrage de la livraison. Fonctionne en continu pendant la livraison, pas en exercice unique.
- Feuille de route comité exécutif
- Un plan programme pluriannuel construit pour la communication exécutive. Phases d'investissement, jalons de capacités et liens explicites entre décisions architecturales et résultats métier. La validation exige non seulement une approbation technique mais un engagement métier sur la direction.
Questions fréquentes
- Les intégrations point à point entre six canaux ne livrent pas Customer 360. La couche de données client unifiée est la décision architecturale ; les canaux sont des points d'intégration vers elle. Commencer par un canal aurait verrouillé l'architecture sur la définition d'entité de ce canal particulier. Concevoir la couche de données d'abord obligeait les six entités métier à s'accorder sur ce qui définit un client avant tout travail sur les canaux. Cet alignement est la partie lente. Le faire d'abord est ce qui a rendu le reste rapide.
- Deux choix de conception. Le statut des risques était suivi en continu, pas à dates fixes, avec des protocoles d'escalade qui se déclenchaient avant qu'un risque ne devienne un problème de livraison. Et chaque risque avait un propriétaire nommé, avec un plan d'atténuation ou de contingence défini, pas un libellé générique « à surveiller ». Le registre était le document de travail des décisions de risque, pas un livrable pour les parties prenantes. C'est ce qui l'a gardé honnête.
- Les programmes suivis au comité exécutif portent une visibilité que les missions de livraison standard n'ont pas. Chaque décision architecturale est visible des personnes qui contrôlent le budget et le calendrier. La réussite doit être définie avant la configuration. La feuille de route à 5 ans devait communiquer phases d'investissement, jalons de capacités et lien entre architecture et résultats métier dans le langage du comité. Une architecture qui ne survit pas à ce niveau de scrutin ne reçoit pas de validation.
- L'architecture a été conçue pour la fondation que Data Cloud a été précisément construit pour livrer : résolution d'identité cross-canal, profil unifié comme base de l'activation, segmentation temps réel remplaçant les traitements par lots. La réflexion est identique, que l'implémentation repose sur de l'intégration sur mesure ou sur Data Cloud. Avec Data Cloud, la résolution d'identité et l'unification qui prenaient des mois en sur-mesure se configurent en semaines. Les décisions architecturales sur ce qui définit un client, comment les canaux se relient et ce qu'exige le modèle d'activation ne changent pas.
- Les décisions de fond se transposent. Définir le client canonique avant le travail d'intégration, cartographier les risques avant la livraison, concevoir pour le modèle d'activation plutôt que pour les systèmes sources. Ce qui change, c'est le poids d'une feuille de route comité exécutif. Les programmes plus petits peuvent porter la même rigueur architecturale à un coût de processus plus faible. Le coût du travail amont sur les risques est faible à toutes les échelles ; le coût des conditions d'échec qui apparaissent tard a la même forme, en valeur absolue plus petite.
Réserver l'appel
On saura en 30 minutes
si je peux vous aider.
Pas de slides. Pas de pitch deck. Apportez le diagramme d'architecture ou décrivez le problème avec vos mots. Je vous dirai si je suis le bon profil et combien coûte la prochaine étape — avant que vous ayez fini votre café.
- Réponses sous 24 heures, toujours
- Si je ne suis pas le bon profil, je vous oriente vers quelqu'un qui l'est
- Aucune relance par email sauf si vous le demandez