Ingestion en streaming avec le SDK Data Cloud

Pour les cas d'usage où la fraîcheur de la donnée est critique — personnalisation en temps réel, déclenchement d'un parcours marketing suite à une action utilisateur, alimentation d'un score de scoring dynamique — le batch et même l'Ingestion API classique ne suffisent pas. Data Cloud propose un SDK d'ingestion streaming permettant d'envoyer des événements individuels avec une latence de l'ordre de la seconde. Voici comment l'implémenter correctement côté client.

Streaming vs batch vs Ingestion API : quelle différence réelle

Il est important de ne pas confondre trois modes qui semblent proches :

• Batch : traitement différé, fréquence de minutes à heures, optimisé pour le volume.
• Ingestion API (REST) : appels synchrones ponctuels, adaptés à des lots de quelques centaines de records envoyés à la demande.
• Streaming SDK : connexion persistante ou quasi persistante, envoi d'événements unitaires ou en micro-lots, avec un objectif de latence sub-seconde à quelques secondes.

Le Streaming Ingestion SDK cible typiquement les Engagement DLO (événements web, clics, interactions app mobile) plutôt que les données de référence (profils, produits), qui restent mieux servies par du batch ou du CDC.

Mise en place côté client

Le SDK (disponible en JavaScript pour le web et en versions serveur) s'appuie sur le même connecteur d'ingestion que l'API REST, mais expose une interface orientée événement plutôt que payload complet. L'intégration typique côté web ressemble à ceci :

import { DataCloudStreamingClient } from '@salesforce/data-cloud-sdk';

const client = new DataCloudStreamingClient({
  orgId: '00Dxx0000001gPz',
  connectorApiName: 'WebEngagementEvents'
});

client.sendEvent({
  eventType: 'page_view',
  userId: 'anon-98213',
  timestamp: Date.now(),
  properties: { pageUrl: '/produits/offre-premium' }
});

Chaque appel sendEvent est mis en file localement puis expédié en arrière-plan, avec un mécanisme de retry en cas d'échec réseau. Cette abstraction évite au développeur front-end de gérer manuellement les têtes d'authentification et le batching réseau.

Gestion de l'identité et réconciliation

Un point critique du streaming est la résolution d'identité : les événements arrivent souvent sous un identifiant anonyme (cookie, device ID) avant qu'un utilisateur ne soit authentifié. Il faut prévoir :

1. Un identifiant anonyme stable envoyé sur chaque événement avant login.
2. Un événement d'identification explicite (identify) au moment du login, liant l'ID anonyme à l'identifiant CRM/Contact.
3. La configuration côté Data Cloud d'une règle d'Identity Resolution qui unifie les deux identités dans le Unified Individual.

Sans cette réconciliation, les événements pré-login restent orphelins et n'enrichissent jamais le profil unifié du client.

Débit, ordonnancement et perte de messages

Le streaming introduit des contraintes que le batch n'a pas :

• Pas de garantie d'ordre strict entre événements envoyés depuis des sessions différentes ; si l'ordre métier compte (par exemple un panier avant un paiement), il faut inclure un timestamp applicatif fiable plutôt que de se reposer sur l'ordre d'arrivée réseau.
• Débit maximal par connecteur : au-delà d'un seuil d'événements par seconde (variable selon l'édition), les événements excédentaires sont throttlés ou rejetés — un pic de trafic (campagne, Black Friday) doit être anticipé avec le support Salesforce si les volumes attendus sont élevés.
• Perte de messages en cas de coupure réseau : le SDK gère un buffer local avec retry exponentiel, mais ce buffer n'est pas infini ; en cas de perte de connexion prolongée côté client (mobile en zone blanche), des événements peuvent être définitivement perdus si l'app est fermée avant le flush.

Pour les événements à forte valeur métier (achat, conversion), ne comptez jamais uniquement sur le streaming : dupliquez la capture côté système transactionnel et réconciliez a posteriori via un flux batch de contrôle.

Observabilité du flux streaming

Contrairement au batch, il n'existe pas d'exécution "de job" à surveiller ponctuellement : la supervision doit être continue. Les leviers disponibles :

• Les métriques d'ingestion exposées dans Data Cloud (volume d'événements par heure, taux d'erreur) à comparer à une baseline attendue.
• Le logging côté client SDK (callbacks onError, onRetry) pour tracer les échecs d'envoi avant même qu'ils n'atteignent Data Cloud.
• Des alertes sur chute anormale de volume, souvent plus révélatrices d'un problème (bug de déploiement front, blocage CSP) qu'une hausse.

Le streaming SDK complète efficacement une architecture d'ingestion hybride : données de référence en batch ou CDC, événements comportementaux en streaming. C'est cette combinaison qui permet à Data Cloud d'alimenter des cas d'usage de personnalisation en temps réel tout en gardant une base de données fiable et complète.