Quand une ETI déploie Salesforce, une question revient systématiquement, souvent trop tard : qui est maître de la donnée client ? Le CRM devient vite le point de contact le plus visible avec la donnée, mais visibilité ne veut pas dire autorité. Confondre l'outil le plus utilisé avec le système source de vérité conduit à des doublons, des conflits de mise à jour et une confiance dégradée dans les chiffres. Cet article aide à clarifier la place de Salesforce dans un référentiel client unique (RCU) et à cadrer la gouvernance avant l'intégration.
Référentiel client unique : de quoi parle-t-on ?
Le référentiel client unique désigne la source de vérité qui centralise et fiabilise l'identité et les attributs d'un client (raison sociale, SIREN/SIRET, adresses, contacts, consentements, hiérarchie de comptes). Son objectif est simple : que chaque application du SI parle du même client avec la même définition. Dans une ETI, ces données sont souvent dispersées entre l'ERP, l'outil de facturation, la plateforme e-commerce, le service client et Salesforce.
Un RCU ne se réduit pas à un tableau de correspondances. Il implique des règles : quelle application crée un client, laquelle peut modifier son adresse de facturation, comment sont réconciliés les doublons, quelle donnée fait foi en cas de conflit. Ces règles définissent qui est maître — au sens de la propriété fonctionnelle — de chaque champ.
Salesforce est-il un CRM ou un référentiel ?
Salesforce est d'abord un outil d'exploitation de la relation commerciale et de service. Il excelle à orchestrer des interactions (opportunités, cas, campagnes), mais il n'est pas conçu, par nature, pour arbitrer la vérité de données réglementées comme la facturation ou le statut juridique d'une entreprise. Beaucoup de projets échouent parce qu'ils demandent implicitement au CRM de jouer un rôle de MDM (Master Data Management) sans en avoir posé les fondations.
Trois configurations coexistent selon les organisations :
- Salesforce maître de la donnée commerciale : comptes, contacts, pistes et opportunités sont créés et arbitrés dans le CRM.
- Salesforce consommateur : l'ERP ou un MDM dédié reste maître des données clients « officielles » (SIRET, adresses de facturation, conditions de paiement), Salesforce les reçoit.
- Modèle mixte champ par champ : le plus fréquent en ETI, où la propriété est répartie selon les attributs.
Le modèle mixte est réaliste, mais c'est aussi le plus exigeant : il oblige à documenter, champ par champ, l'application source et le sens de synchronisation.
Pourquoi la question de la maîtrise se pose si tôt
Dès la phase de cadrage, l'absence de réponse claire crée des dégâts en cascade. Si deux systèmes peuvent créer un compte sans règle de déduplication, vous obtenez des doublons. Si deux systèmes peuvent modifier une adresse sans hiérarchie, vous obtenez des écrasements silencieux. Et si personne ne sait quel chiffre fait foi, les rapports de direction deviennent contestables.
La donnée d'identité d'entreprise est un bon exemple. Les identifiants SIREN et SIRET ainsi que les statuts d'établissement sont disponibles via des sources publiques comme la base Sirene diffusée sur data.gouv.fr par l'INSEE. S'appuyer sur ces référentiels officiels pour normaliser l'identité client réduit fortement les divergences entre applications — à condition de décider quel système consomme et propage cette donnée.
Ne laissez jamais l'intégrateur décider seul de la propriété de la donnée pour des raisons techniques. Le choix du système maître est une décision métier et de gouvernance : il engage la responsabilité sur la facturation, la conformité RGPD et le reporting. Une matrice de propriété non validée par le métier est un risque, pas un raccourci.
Construire une matrice de propriété des données
L'outil de cadrage le plus utile est une matrice simple, lisible par le métier comme par la DSI. Pour chaque champ ou groupe de champs, on précise :
- Le système maître : qui détient l'autorité de création et de modification.
- Le sens de synchronisation : unidirectionnel ou bidirectionnel, et à quelle fréquence.
- La règle de conflit : que se passe-t-il si deux systèmes modifient le même champ.
- La règle de déduplication : clé de rapprochement (SIREN, e-mail, identifiant interne).
- Le responsable métier : la personne qui arbitre en cas de doute.
Cette matrice devient le contrat de référence entre les équipes. Elle guide les développements d'intégration, sert de base aux tests de recette et évite les débats techniques sans fin. Elle documente aussi les zones grises — souvent les adresses, les hiérarchies de comptes et les consentements — qui méritent une attention particulière.
Trois architectures possibles pour le RCU
Salesforce comme hub central
Salesforce concentre la donnée commerciale et sert de point de vérité pour les comptes et contacts. Adapté quand la relation client est au cœur du métier et que l'ERP joue un rôle secondaire côté client. Attention à ne pas y déverser des données réglementées qu'il n'a pas vocation à arbitrer.
Un MDM dédié en amont
Un outil de MDM (ou l'ERP) tient le rôle de source de vérité et distribue la donnée fiabilisée à Salesforce et aux autres applications. Plus robuste pour des SI complexes ou multi-marques, mais plus coûteux et plus long à mettre en œuvre.
Le modèle réparti documenté
Aucun système unique n'est maître de tout : la propriété est répartie par domaine, appuyée sur une matrice et des flux d'intégration maîtrisés. C'est le compromis le plus courant en ETI. Sa réussite dépend entièrement de la qualité de la documentation et de la discipline de synchronisation.
Aller plus loin
Ce que cela change pour le choix de votre partenaire
La façon dont un intégrateur aborde cette question est révélatrice. Un prestataire qui propose immédiatement de « tout mettre dans Salesforce » sans interroger l'ERP, la facturation et la conformité privilégie sa zone de confort technique. À l'inverse, un partenaire solide commence par cartographier vos systèmes existants, vos flux et vos responsabilités métier avant de proposer une architecture.
Pour comparer objectivement les approches, il est utile de faire porter la sélection sur des critères vérifiables : capacité à documenter une matrice de propriété, expérience d'intégration ERP/Salesforce, maîtrise des API et des mécanismes de synchronisation, et méthode de reprise de données. C'est précisément le rôle d'un tiers de confiance comme INTEGREER : qualifier le besoin à partir de données publiques et de critères factuels, pour aider à cadrer avant d'engager le budget.
Une checklist avant de lancer l'intégration
- Avez-vous listé toutes les applications qui créent ou modifient des données client ?
- Une matrice de propriété champ par champ est-elle validée par le métier ?
- Les clés de déduplication (SIREN, e-mail) sont-elles définies ?
- Les règles de conflit sont-elles écrites et testées ?
- Les données d'identité s'appuient-elles sur des sources officielles fiables ?
- Le sens et la fréquence de synchronisation sont-ils explicites pour chaque flux ?
Répondre à ces questions avant le développement évite les reprises coûteuses et les litiges sur le périmètre. La gouvernance de la donnée n'est pas un livrable annexe : c'est la fondation sur laquelle repose la confiance dans votre CRM.