Le connecteur Salesforce CRM est presque toujours le premier Data Stream configuré dans un projet Data Cloud, puisque le CRM (Sales Cloud, Service Cloud) reste la source de vérité pour les données Contact, Account et Opportunity dans la majorité des organisations. Cette intégration est native et ne nécessite pas d'ETL intermédiaire, mais elle comporte plusieurs subtilités qu'il faut maîtriser pour éviter de dupliquer inutilement de la donnée ou de créer des incohérences entre CRM et Data Cloud.
Depuis Data Cloud > Data Streams > New > Salesforce CRM, vous sélectionnez la connexion à l'org (l'org courant ou un org externe connecté via Salesforce Connected App), puis l'objet à ingérer. Ce connecteur fonctionne pour les objets standards (Contact, Account, Lead, Opportunity, Case) comme pour les objets custom, à condition que l'utilisateur d'intégration ait les droits d'accès nécessaires sur ces objets et leurs champs.
Une erreur fréquente en début de projet consiste à ingérer massivement tous les objets CRM "au cas où". Il vaut mieux partir du cas d'usage cible et remonter :
Cette approche limite la consommation de crédits de traitement liée à l'ingestion et réduit le risque de mapper des champs sensibles (RH, financiers) sans besoin métier réel.
Contact et Account doivent typiquement être catégorisés en Profile, tandis que Case, Opportunity ou Task, qui représentent des événements ou transactions liés à un profil, sont souvent catégorisés en Engagement. Le mapping automatique proposé par Data Cloud pour Contact vers Individual et Contact Point Email/Phone couvre l'essentiel, mais vérifiez systématiquement les champs custom, qui ne sont jamais mappés automatiquement et doivent être ajoutés manuellement au DMO correspondant, ou à un DMO custom relié si nécessaire.
Un piège classique consiste à recréer dans Data Cloud, sous forme de Calculated Insight, une métrique qui existe déjà comme champ de formule ou rapport dans le CRM. Avant de construire une nouvelle métrique dans Data Cloud, demandez-vous si elle a besoin de la puissance de traitement du lakehouse (croisement de multiples sources, gros volumes, Engagement temporel) ou si un champ de formule Salesforce classique suffit. Data Cloud apporte de la valeur là où le modèle transactionnel classique atteint ses limites : gros volumes, données multi-sources, historique événementiel dense.
Le sens de la synchronisation n'est pas automatiquement bidirectionnel. Par défaut, le Data Stream CRM ingère les données du CRM vers Data Cloud ; pour renvoyer une donnée calculée dans Data Cloud (un score, un segment) vers un champ CRM, il faut une configuration explicite additionnelle, comme un Data Action déclenchant un Flow de mise à jour, ou l'usage des Calculated Insight Related Lists en lecture seule sur la fiche.
Le Refresh Type choisi pour chaque objet CRM (Full, Incremental, Continuous) doit correspondre à la volatilité réelle de la donnée. Un objet Contact, mis à jour occasionnellement, peut tourner en Incremental toutes les heures ; un objet Case, plus volatile en contexte de service client réactif, bénéficiera d'un rythme plus fréquent voire Continuous si le cas d'usage (par exemple un agent Agentforce consommant le contexte en direct) l'exige. Gardez en tête que chaque run consomme des crédits : calibrez la fréquence sur le besoin réel plutôt que sur le maximum technique disponible.
Après la mise en place initiale, comparez systématiquement un échantillon de données entre le CRM source et le DMO résultant dans Data Cloud > Data Explorer : nombre d'enregistrements cohérent, valeurs de champs clés identiques, absence de doublons inattendus. Cette validation croisée, simple mais souvent négligée sous la pression du planning, évite de découvrir un problème de mapping une fois que l'Identity Resolution et les segments ont déjà été construits sur des fondations erronées.
Notre équipe DevToSpace accompagne vos projets Data Cloud, de l'ingestion à l'activation vers Marketing Cloud Next.
Parler à un expert