Ingestion Data Cloud vs Salesforce Connect : quelle approche choisir ?

Face à une source de données externe, deux approches s'opposent souvent dans les décisions d'architecture Salesforce : ingérer la donnée dans Data Cloud (ou directement dans l'org via un connecteur), ou la laisser dans son système d'origine et y accéder à la volée via Salesforce Connect (données virtuelles, OData ou adaptateur personnalisé). Ce choix a des conséquences durables sur la performance, la fraîcheur et la complexité opérationnelle du système. Voici comment trancher.

Rappel du fonctionnement de Salesforce Connect

Salesforce Connect expose des données externes sous forme d'External Objects, consultables et parfois modifiables depuis l'interface Salesforce comme s'il s'agissait d'objets natifs, mais sans qu'aucune copie ne soit stockée dans l'org. Chaque affichage d'un enregistrement déclenche un appel en temps réel vers le système source, via un adaptateur :

• OData 2.0/4.0 Adapter : standard générique pour connecter des sources compatibles OData (SAP, bases exposant une API OData).
• Cross-Org Adapter : pour fédérer des données entre plusieurs orgs Salesforce.
• Custom Adapter (Apex Connector Framework) : pour des sources propriétaires, via développement Apex.

La donnée n'est jamais répliquée : elle est lue "live" à chaque consultation, ce qui garantit une fraîcheur parfaite mais dépend entièrement de la disponibilité et de la performance du système distant.

Ingestion : répliquer la donnée

À l'inverse, l'ingestion (via Ingestion API, Bulk API, connecteurs batch ou CDC) copie physiquement la donnée dans Data Cloud (DLO puis DMO) ou dans l'org Salesforce. La donnée devient une réplique, potentiellement transformée, indépendante de la disponibilité instantanée du système source au moment de la consultation.

Comparatif technique point par point

• Fraîcheur : Salesforce Connect offre une fraîcheur immédiate et garantie (donnée live) ; l'ingestion introduit un délai de latence dépendant de la fréquence de synchronisation (de la seconde en streaming à plusieurs heures en batch).
• Performance de requêtage : les données ingérées bénéficient de l'indexation et des capacités analytiques natives de Data Cloud (segmentation, jointures, Calculated Insights) ; les External Objects sont limités par les capacités de requêtage du système distant, souvent moins performant pour des volumes importants ou des agrégations complexes.
• Volumétrie : Salesforce Connect n'a pas de limite de stockage (rien n'est stocké côté Salesforce), idéal pour des historiques massifs consultés ponctuellement ; l'ingestion consomme du stockage Data Cloud proportionnel au volume répliqué.
• Disponibilité et résilience : une panne du système source rend les External Objects immédiatement inaccessibles ; les données ingérées restent disponibles même si la source est temporairement hors ligne.
• Capacités d'activation : seules les données ingérées dans Data Cloud peuvent alimenter des segments, de l'Identity Resolution et des activations vers les canaux marketing — les External Objects ne sont pas exploitables nativement par le moteur de segmentation Data Cloud.
• Coût d'API côté source : Salesforce Connect génère un appel au système distant à chaque consultation utilisateur, ce qui peut solliciter fortement l'API source en cas de fort trafic ; l'ingestion limite les appels source à la fréquence de synchronisation, indépendamment du volume de consultation côté Salesforce.

Cas d'usage typiques pour chaque approche

Privilégier Salesforce Connect quand :

• La donnée est volumineuse, rarement consultée, et une réplication complète serait disproportionnée (archives, historiques légaux).
• La fraîcheur en temps réel est non négociable et la source garantit une haute disponibilité (statut de commande, stock en temps réel).
• Le besoin se limite à un affichage contextuel ponctuel dans l'UI Salesforce, sans besoin de segmentation ou d'activation marketing.

Privilégier l'ingestion quand :

• La donnée doit alimenter la segmentation, l'Identity Resolution ou l'activation Data Cloud.
• Des analyses agrégées ou des jointures complexes sont nécessaires, plus performantes sur des données répliquées et indexées.
• La disponibilité de la donnée doit être garantie indépendamment de la disponibilité du système source.
• Le volume de consultation est élevé et un appel live systématique surchargerait le système source.

Ces deux approches ne sont pas mutuellement exclusives : il est courant d'ingérer les données de référence à forte valeur analytique (clients, commandes) tout en gardant en Salesforce Connect des données volumineuses à faible fréquence de consultation (historiques de logs, archives documentaires).

Un point d'architecture souvent négligé : la gouvernance

Au-delà des critères techniques, le choix a un impact sur la gouvernance des données : une donnée ingérée devient une copie à maintenir en cohérence avec la source (risque de désynchronisation), tandis qu'une donnée en Salesforce Connect reste sous l'entière responsabilité du système propriétaire, sans duplication de la responsabilité de qualité. Pour des données à caractère personnel soumises au RGPD, cette distinction compte également : une donnée ingérée nécessite sa propre politique de rétention et de suppression dans Data Cloud, distincte de celle du système source.

Le bon réflexe consiste à évaluer, pour chaque source, le besoin réel d'activation marketing et de fraîcheur avant de décider — et à ne pas ingérer par défaut une donnée qui pourrait rester virtuelle sans perte de valeur métier.