Un même client peut exister dans Salesforce, l’ERP, le site web, l’outil de support et la plateforme marketing. Chaque système détient une partie de la réalité. Le CRM connaît les interlocuteurs et les opportunités, l’ERP connaît les factures, le support connaît les incidents et le produit connaît les usages.
Data 360 promet de rendre ces données utilisables ensemble. Mais « créer une source de vérité » ne signifie pas copier toutes les tables dans un nouveau réservoir. Il faut décider quelles sources font autorité, comment rapprocher les identités, quelle fraîcheur est nécessaire et quelles équipes ont le droit d’activer chaque donnée.
Voici une méthode pour cadrer Salesforce Data 360 autour d’un résultat métier, sans fabriquer un nouveau silo coûteux et difficile à gouverner.
Data Cloud s’appelle désormais Data 360
Salesforce a renommé Data Cloud en Data 360 le 14 octobre 2025. La documentation officielle Data 360 précise que le nom a changé, mais que les fonctionnalités restent les mêmes pendant la transition. Il est donc normal de rencontrer encore « Data Cloud » dans certaines interfaces ou documentations.
Data 360 sert à connecter des données structurées et non structurées, à les harmoniser, à rapprocher des identités et à les rendre activables dans Salesforce, les analyses, les automatisations et Agentforce. La plateforme peut ingérer des données ou, selon la source et le besoin, y accéder sans les recopier grâce aux mécanismes Zero Copy.
Cette définition est importante : Data 360 est une couche de mise en contexte et d’activation. Ce n’est ni un remplacement automatique de l’ERP, ni une promesse de supprimer tous les doublons, ni une gouvernance qui se configure toute seule.
Une source de vérité n’est pas forcément un système unique
Le terme « source de vérité » prête à confusion. Dans une architecture réelle, plusieurs systèmes peuvent rester propriétaires de données différentes :
- l’ERP demeure la référence pour une facture comptabilisée ;
- Salesforce demeure la référence pour le propriétaire commercial d’un compte ;
- l’outil de support demeure la référence pour l’état d’un incident ;
- le site ou le produit demeure la référence pour un événement d’usage récent.
Data 360 peut relier ces informations dans un profil unifié sans prétendre que toutes sont nées dans le même système. La documentation d’architecture Salesforce décrit une couche harmonisée fondée sur des Data Model Objects. Ces objets structurent une vue commune, tandis que les données sources conservent leur lignée.
La vraie source de vérité est donc un contrat : pour chaque donnée utile, une définition, une source d’autorité, une règle de rapprochement, une fréquence de mise à jour et un propriétaire.
Dans quels cas Data 360 devient pertinent ?
Data 360 mérite une étude lorsque plusieurs conditions sont réunies :
- La même personne ou société existe dans plusieurs systèmes utiles à une décision.
- Le rapprochement doit être répété et industrialisé, pas réalisé ponctuellement dans un fichier.
- Les équipes doivent activer la vue unifiée dans Salesforce, Agentforce, une segmentation, une analyse ou une automatisation.
- La fréquence de mise à jour a un impact métier clair.
- Les volumes, sources ou règles dépassent ce qu’une intégration simple peut gérer proprement.
Exemple : un responsable de compte veut savoir qu’un client stratégique utilise moins le produit, a ouvert deux incidents critiques et approche de son renouvellement. Ces signaux vivent souvent dans trois systèmes. Les réunir au bon moment peut déclencher une action de rétention utile.
À l’inverse, si le problème principal est une liste de comptes en doublon dans une seule org Salesforce, un chantier de qualité de données et de gouvernance peut suffire. Ajouter une plateforme sans corriger la définition des données déplacerait simplement le problème.
Un audit Salesforce permet justement de distinguer le besoin d’unification du besoin de nettoyage ou de simplification.
Partir de la décision, pas des connecteurs
La première question d’un cadrage Data 360 ne devrait pas être « quelles sources pouvons-nous connecter ? ». Elle devrait être « quelle décision ou action voulons-nous améliorer ? »
Formulez un cas d’usage observable :
- prévenir un responsable de compte lorsqu’un risque de renouvellement apparaît ;
- donner à un agent de service le contexte produit et contractuel d’un client ;
- éviter deux sollicitations marketing incompatibles ;
- proposer une prochaine action fondée sur les échanges et l’usage réel ;
- réconcilier un contact web avec un compte déjà connu.
Puis décrivez la donnée minimale nécessaire. Cette discipline réduit les coûts, accélère le pilote et rend la réussite mesurable. Elle évite la collecte « au cas où », qui augmente la complexité sans créer de décision supplémentaire.
Les six couches d’une architecture Data 360 utile
1. Les systèmes sources et leurs propriétaires
Inventoriez les données nécessaires au cas d’usage, pas toutes les tables disponibles. Pour chaque attribut, indiquez le système de référence, l’équipe responsable, la fréquence de mise à jour et le niveau de sensibilité.
Deux systèmes peuvent porter des valeurs différentes sans qu’aucun soit défectueux. Une adresse de livraison et une adresse de facturation ne doivent pas être fusionnées par ressemblance. La définition métier vient avant le mapping technique.
2. Le mode de connexion
Une donnée peut être ingérée physiquement, interrogée sans copie ou mise en cache selon son volume, sa fréquence et son usage. La page officielle sur la connectivité Zero Copy de Data 360 explique que le choix se fait par flux : l’accès direct peut éviter une réplication complète, tandis qu’une copie ou un cache peut rester pertinent pour certaines performances et activations.
Zero Copy ne signifie pas « zéro architecture ». Il faut toujours contrôler les droits, les requêtes, la latence, la disponibilité de la source et le coût d’usage.
3. Le mapping et l’harmonisation
Les données connectées doivent être mappées vers un modèle commun. C’est ici que l’on définit qu’un identifiant client ERP, un Account Salesforce et un compte produit décrivent potentiellement la même organisation.
Le mapping ne doit pas seulement aligner des colonnes. Il doit documenter le sens, les formats, les unités, les valeurs de référence et les transformations. Une date, un montant ou un statut mal interprété peut rendre tout le profil cohérent en apparence, mais faux dans les décisions.
4. La résolution d’identité
Data 360 crée des profils unifiés à partir de règles de correspondance et de réconciliation. Le module Trailhead sur les profils unifiés et la résolution d’identité rappelle qu’un profil unifié relie des identifiants provenant de plusieurs sources. Il ne transforme pas magiquement toutes les sources en un enregistrement unique.
Les règles doivent être testées sur des vrais cas : homonymes, adresses partagées, changements d’entreprise, emails génériques et valeurs absentes. Une règle trop stricte crée des profils séparés à tort. Une règle trop large fusionne deux personnes différentes, ce qui est plus grave.
5. La gouvernance et les droits
Une vue complète du client ne doit pas devenir une vue accessible à tous. Il faut définir les espaces de données, classifications, politiques d’accès et usages autorisés. L’architecture de gouvernance Data 360 décrit une logique de contrôle par politiques, contexte et attributs.
Les droits doivent suivre la finalité. Un commercial peut avoir besoin d’un score de risque sans accéder au détail d’un incident sensible. Un agent IA peut utiliser une information pour choisir une action sans être autorisé à la révéler dans une réponse.
6. L’activation et la preuve de valeur
Une donnée unifiée qui ne change aucune action reste une donnée de plus à maintenir. Le pilote doit se terminer dans un processus : alerte, segment, Flow, écran, recommandation, rapport ou contexte Agentforce.
Mesurez alors le résultat économique : dossiers mieux routés, temps de recherche réduit, doublons évités, opportunités détectées, erreurs de ciblage supprimées ou risque client traité plus tôt.
Exemple de pilote : détecter un risque client exploitable
Prenons un client B2B dont les données sont réparties entre Salesforce, un outil produit et une solution de support.
Le pilote peut suivre ce parcours :
- Sélectionner un segment limité de comptes actifs.
- Connecter le statut contractuel, deux indicateurs d’usage et les incidents ouverts.
- Mapper les identifiants et documenter les sources de référence.
- Tester les règles de rapprochement sur un échantillon validé par les équipes.
- Calculer un indicateur simple de risque, explicable et réversible.
- Afficher le contexte utile sur le compte Salesforce.
- Créer une tâche pour le responsable uniquement lorsque les critères sont réunis.
- Comparer les alertes aux décisions humaines pendant quelques semaines.
Le pilote ne cherche pas à produire une vision universelle du client. Il cherche à prouver qu’un contexte unifié améliore une transition précise, du signal à l’action.
Cette logique complète les workflows IA autour du CRM : l’automatisation devient plus pertinente lorsque le signal est défini, sourcé et gouverné.
Les erreurs qui transforment Data 360 en nouveau silo
Connecter toutes les sources avant de choisir l’usage
Cette approche maximise le volume de données, pas la valeur. Elle retarde les premières activations et multiplie les mappings sans propriétaire.
Confondre rapprochement et vérité
Un profil unifié dépend des règles choisies. Il doit conserver la lignée des sources et permettre d’expliquer pourquoi deux identités ont été rapprochées.
Négliger le coût de consommation
Les flux, transformations, résolutions d’identité, requêtes et activations n’ont pas tous le même coût. Il faut estimer le volume traité et suivre le coût par résultat utile, plutôt que seulement le nombre de lignes connectées.
Oublier les cas négatifs
Un test qui ne contient que des clients faciles valide surtout la démonstration. Ajoutez des homonymes, emails partagés, comptes fusionnés, suppressions, retards de synchronisation et accès refusés.
Donner la même vue à tous
L’unification ne supprime pas le besoin de moindre privilège. La gouvernance doit accompagner le modèle dès le pilote, pas être ajoutée après l’ouverture des usages.
Les indicateurs d’un pilote réussi
Le tableau de bord devrait combiner qualité, usage et économie :
- précision des rapprochements validée sur échantillon ;
- taux de faux rapprochements et de profils séparés à tort ;
- délai entre la mise à jour source et l’information exploitable ;
- part des données critiques avec propriétaire et définition ;
- nombre d’actions réellement déclenchées grâce au contexte unifié ;
- temps humain économisé, corrections comprises ;
- erreurs ou sollicitations contradictoires évitées ;
- consommation Data 360 par cas traité ;
- taux d’utilisation du contexte dans Salesforce ou Agentforce.
Le volume de profils unifiés n’est pas un résultat métier. C’est un moyen. Le résultat apparaît lorsqu’une équipe décide ou agit mieux.
Data 360 et Agentforce : dans quel ordre avancer ?
Agentforce a besoin d’un contexte correct, actuel et pertinent. Data 360 peut fournir ce contexte lorsqu’il doit être construit à partir de plusieurs systèmes. Mais tous les agents n’exigent pas une unification large.
Commencez par le cas d’usage Agentforce, identifiez les données nécessaires, puis décidez si Salesforce seul suffit, si une intégration ciblée convient ou si Data 360 apporte une vraie valeur. Notre retour sur Agentforce dans une PME montre pourquoi ce cadrage évite les pilotes séduisants mais impossibles à industrialiser.
Cadrer avant d’acheter ou de connecter
Cloud Girafe accompagne les entreprises qui veulent relier Salesforce à leurs autres systèmes sans ajouter une couche opaque. Nous pouvons cadrer le premier cas d’usage Data 360, identifier les sources de référence, tester les règles d’identité, définir la gouvernance et chiffrer un pilote mesurable.
L’objectif n’est pas de centraliser pour centraliser. Il est de rendre un contexte fiable disponible au bon moment, pour une action que l’entreprise sait expliquer et mesurer.
