Salesforce API : Bulk, CDC, Pub/Sub et SI sous charge

Une importation de comptes démarre, le consommateur ERP ralentit et le retard grimpe sans alerte. Le lendemain, les commerciaux voient des statuts anciens, tandis qu’un rejeu massif consomme encore plus de capacité. Ce symptôme ne vient pas seulement d’un quota Salesforce : il révèle une architecture qui ne distingue ni la charge de rattrapage, ni les changements courants, ni la capacité du système aval.

Le vrai enjeu est de choisir un mode de transport avec sa preuve de reprise. REST traite une interaction ciblée, Bulk API 2.0 exécute un travail asynchrone sur une masse, Change Data Capture publie les changements d’enregistrements et Pub/Sub API permet de les consommer avec un contrôle de flux. Aucun de ces mécanismes ne décide seul de la priorité métier.

Contre-intuitivement, une architecture plus rapide peut aggraver l’incident : elle transmet plus vite une pointe que l’ERP, le data warehouse ou le moteur de facturation ne sait pas absorber. Le bon arbitrage associe chaque flux à une fraîcheur utile, un budget de volume, une clé d’idempotence et une procédure de réconciliation.

Dawap accompagne les entreprises sur ce cadrage d’intégration API : inventaire des objets, choix REST/Bulk/CDC, contrat d’événement, test de charge et runbook de reprise. La priorité consiste à savoir ce qui s’est passé avant de remettre du débit.

Partir de la charge métier, pas du connecteur

Le volume moyen masque les situations dangereuses : reprise après maintenance, import marketing, fusion de comptes, correction globale ou changement de règle d’automatisation. Le dimensionnement doit décrire le pic plausible, sa durée et le retard acceptable pour chaque famille de données.

Un statut d’opportunité peut attendre quelques minutes ; une commande validée ou une suspension de service peut exiger un traitement prioritaire. Mettre ces événements dans la même file impose au plus critique le rythme du plus bruyant.

Quantifier une pointe de bout en bout

L’entrée du calcul est le nombre d’enregistrements touchés, pas seulement le nombre de transactions initiées. Une opération peut produire plusieurs changements liés et déclencher d’autres automatismes. La sortie attendue est un temps de résorption, avec la capacité Salesforce, celle du middleware et celle du système cible.

Si la file contient 60 000 changements et que l’aval n’en traite durablement que 100 par seconde, alors dix minutes constituent déjà un minimum théorique, hors erreurs et appels d’enrichissement. Ce calcul simple rend visible un retard que le taux de succès global dissimule.

Choisir REST, Bulk, CDC ou Pub/Sub

REST convient à une lecture ou une écriture synchrone dont l’appelant attend le résultat. Bulk API 2.0 convient aux ensembles volumineux acceptant un job asynchrone. CDC décrit les créations, modifications, suppressions et restaurations ; Pub/Sub transporte ces événements vers le consommateur.

Ces briques sont complémentaires. Une réplication commence souvent par une copie initiale Bulk, continue avec CDC et se réconcilie périodiquement par une requête. Une commande interactive peut rester sur REST sans partager son budget avec un chargement analytique.

Associer chaque mode à un engagement

Le contrat précise la fraîcheur, le volume, l’ordre utile, la stratégie de doublon et la conduite à tenir après timeout. Si l’appelant doit confirmer immédiatement une écriture unique, REST est naturel. Si le résultat peut être consulté plus tard et comporte des milliers de lignes, Bulk évite une boucle d’appels unitaires.

Un changement quasi temps réel ne signifie pas « appel garanti une fois ». Le consommateur d’événements reste responsable du curseur, de l’idempotence, du traitement partiel et du rattrapage lorsque le delta n’est plus disponible.

Utiliser Bulk API 2.0 pour les masses

Bulk API 2.0 Ingest accepte des données CSV et exécute de façon asynchrone les insertions, mises à jour, upserts ou suppressions. Le client crée un job, charge les données, signale la fin de l’upload, surveille l’état puis récupère séparément les lignes réussies, échouées ou non traitées.

Bulk Query traite aussi des requêtes SOQL asynchrones et découpe les grands jeux de résultats lorsque l’objet le permet. Le job n’est toutefois pas une transaction métier globale : une partie des lignes peut réussir alors qu’une autre est rejetée.

Conserver le manifeste du lot

Chaque job possède un manifeste interne avec identifiant, objet, opération, external ID, version du mapping, empreinte du fichier et périmètre temporel. Les résultats Salesforce sont archivés avec ce manifeste afin de rejouer uniquement les lignes corrigées.

Un upsert n’est sûr que si l’external ID est stable et unique. En l’absence de cette garantie, la reprise reste en quarantaine : relancer tout le fichier peut fabriquer des doublons ou écraser une correction effectuée entre-temps.

Consommer les changements avec CDC

Change Data Capture publie des changements sur les objets Salesforce utiles au processus aval. Le cadrage des échanges Salesforce et de leur reprise replace le choix événementiel dans le contrat CRM–ERP. Le middleware doit qualifier la nature du changement avant d'autoriser une écriture, plutôt que considérer toute donnée reçue comme une nouvelle fiche complète.

Les événements suivent l’ordre des transactions validées. Lorsqu’une transaction produit plusieurs changements, transactionKey et sequenceNumber aident à reconstituer leur relation. Ils ne dispensent pas de gérer des traitements concurrents dans le consommateur.

Filtrer sur une décision aval

Copier chaque changement de champ crée du bruit et consomme les allocations d’événements. Le filtre conserve les modifications qui changent une décision : compte activé, opportunité gagnée, adresse validée ou contrat suspendu. Les changements cosmétiques peuvent attendre la réconciliation.

L’origine du changement doit aussi être examinée afin d’éviter une boucle. Si le middleware écrit dans Salesforce puis réagit à son propre événement sans garde-fou, il peut renvoyer la même donnée vers l’ERP et déclencher une nouvelle écriture.

Remplacer le faux webhook par Pub/Sub

Salesforce ne livre pas CDC comme un webhook HTTP classique appelant librement une URL. Pub/Sub API expose une interface gRPC sur HTTP/2, avec des messages Avro, pour publier et recevoir les événements de plateforme et les changements CDC. Cette différence modifie l’authentification, la connexion et la reprise.

Dans une souscription en lecture, le client indique combien d’événements il a la capacité de recevoir. La documentation Salesforce fixe actuellement à 100 le nombre maximal demandé à la fois sur un flux de souscription. Ce plafond n’est pas un objectif de lot : le consommateur choisit une valeur compatible avec sa mémoire et son temps de traitement.

Gérer la connexion comme une ressource durable

Le client surveille les keepalives, la date du dernier événement, les fermetures de flux et le renouvellement du token OAuth. Il persiste le replay ID après le traitement utile, pas dès la réception, sinon un arrêt entre les deux perd la possibilité d’une reprise propre.

Le replay ID est opaque et n’est pas garanti contigu. On ne l’incrémente pas et on ne l’utilise pas comme identifiant métier. La clé de déduplication combine l’objet, l’enregistrement, le type de changement et la preuve conservée par le traitement.

Appliquer le backpressure du SI cible

Le contrôle de flux Pub/Sub protège le client à l’entrée, mais pas automatiquement l’ERP situé plusieurs étapes plus loin. Le middleware doit mesurer sa file interne, limiter la concurrence et cesser de demander de nouveaux événements lorsque l’aval ralentit.

Les flux critiques et les enrichissements secondaires utilisent des files distinctes. Une commande ou une suspension de compte ne doit pas attendre derrière une mise à jour de préférence marketing. La priorité est définie par l’impact, pas par l’ordre d’arrivée seul.

Fixer des seuils sur l’âge et la capacité

Un seuil de 70 % de capacité aval peut réduire la concurrence ; à 85 %, le consommateur arrête les familles non critiques ; à 95 %, il suspend toute demande supplémentaire et alerte l’owner. Ces valeurs sont calibrées par un test de charge, pas copiées d’un autre projet.

La mesure décisive reste l’âge du plus ancien changement non appliqué. Une file courte peut être bloquée depuis deux heures sur une erreur métier, alors qu’une grande file en cours de résorption ne menace pas encore le service.

Rendre les traitements idempotents

Le payload CDC indique ce qui a changé ; il ne garantit pas que la cible accepte encore cette transition. Le contrat traduit donc l’événement en commande aval avec entrées obligatoires, version de schéma, règle d’ordre et sortie attendue.

Une écriture cible conserve l’identifiant Salesforce et la clé d’opération. Après un timeout, le retry commence par rechercher cette clé. Si l’opération existe, il rapproche son statut ; si elle est absente, il peut écrire ; si son état est ambigu, il l’isole.

Tester la frontière la plus dangereuse

Le test coupe la réponse après que l’ERP a validé l’écriture. Le retry reçoit alors le même message et doit aboutir à une seule opération. Cette simulation prouve l’idempotence mieux qu’un test où l’appel échoue avant toute modification.

La journalisation relie replay ID, identifiant d’enregistrement, version du mapping, tentative, réponse cible et décision finale. Les données sensibles sont masquées, mais la trace permet au support de distinguer absence, doublon et accusé perdu.

Combiner replay et réconciliation

Salesforce conserve actuellement les événements de plateforme et CDC pendant 72 heures. Un replay ID permet de reprendre dans cette fenêtre, mais sa disponibilité au-delà n’est pas garantie. Le curseur ne remplace donc jamais une copie de référence.

La documentation Salesforce précise aussi que CDC s’appuie sur un système distribué et ne constitue pas une piste d’audit transactionnelle infaillible. La réconciliation compare périodiquement les identifiants, versions ou dates de modification afin de détecter un delta manquant.

Prévoir trois chemins de reprise

Une coupure courte reprend au dernier replay ID. Une interruption encore couverte par la rétention relit une plage puis déduplique. Une indisponibilité plus longue déclenche une extraction Bulk bornée et une comparaison avec la cible avant de réouvrir le flux courant.

Le runbook indique qui choisit le chemin, comment figer les écritures concurrentes et quel contrôle ferme l’incident. Rejouer sans connaître l’état cible est interdit, car la restauration du transport peut multiplier les incohérences métier.

Budgéter quotas, droits et dépendances

Les allocations dépendent de l’édition, des licences et des fonctionnalités activées dans l’organisation. Le cadrage relève les limites réelles de l’org plutôt que d’inscrire une valeur générique dans l’architecture.

Les droits comptent autant que les quotas. Le compte d’intégration doit accéder aux objets et champs nécessaires, sans permissions excessives. Une rotation de secret, une expiration de certificat ou une sandbox rafraîchie sont traitées comme des scénarios d’exploitation.

Isoler les budgets par usage

Les appels interactifs, les imports, les reprises et les extractions analytiques ne partagent pas aveuglément la même enveloppe. Le monitoring suit leur consommation par client et par objet afin qu’un rattrapage data ne dégrade pas un parcours commercial.

Si le budget disponible passe sous le seuil de sécurité, alors les traitements secondaires s’arrêtent d’abord. La décision et son owner sont documentés avant l’incident ; le support ne choisit pas seul quel flux sacrifier.

Superviser l’âge réel du retard

Un tableau de bord utile relie santé technique et conséquence métier : connexion Pub/Sub, événements demandés et reçus, retard du curseur, profondeur des queues, erreurs par motif, lignes Bulk rejetées et objets non réconciliés.

Le nombre de messages par seconde ne dit pas si une opportunité critique est bloquée. L’alerte combine l’âge, le type d’objet et le statut métier, puis pointe vers une action du runbook.

Fermer l’incident par une preuve

Le retour au vert exige que le consommateur ait rattrapé le direct, que la dead-letter queue soit expliquée et que la réconciliation ne trouve plus d’écart sur la fenêtre touchée. Vider la file ne suffit pas si des rejets ont été ignorés.

Le coût caché se mesure en heures de correction, opportunités retardées, imports relancés et contrôles manuels. Cette mesure justifie les travaux de fiabilisation bien mieux qu’un objectif abstrait de temps réel.

Pour qui construire cette architecture

Ce cadrage concerne les organisations dont Salesforce alimente un ERP, un entrepôt de données, une plateforme de service ou plusieurs applications internes. Il devient prioritaire quand les imports récurrents croisent des flux continus ou lorsque le support ne peut plus expliquer un retard.

Réunir CRM, plateforme et système aval

L’administrateur Salesforce connaît les objets et automatismes. L’équipe plateforme possède le consommateur et les files. Le responsable du SI cible définit sa capacité et les transitions acceptables. Le métier classe les objets selon leur impact.

Ces responsabilités forment une matrice RACI pour l’activation d’un objet, le changement de mapping, le rejeu et l’arrêt d’urgence. Aucun retry important ne doit dépendre d’une approbation introuvable.

Différer quand la source de vérité reste contestée

Si Salesforce et l’ERP peuvent modifier le même statut sans règle d’autorité, CDC accélère seulement le conflit. Le chantier commence par décider qui écrit, dans quel état et selon quelle transition.

Un pilote reste possible sur un objet dont l’owner et la clé sont stables. Cette limite permet d’éprouver la charge, la reprise et l’observabilité sans attendre que toute la gouvernance CRM soit résolue.

Plan d’action sur un objet critique

Jours 1 à 10 : mesurer et contractualiser

Choisir un objet dont le retard possède un impact clair. Relever les volumes moyens, les pics d’import, la taille des lots, la fraîcheur attendue et la capacité mesurée du système aval. Cartographier les automatismes Salesforce susceptibles de multiplier les changements.

Définir les entrées, la sortie, l’external ID, le schéma, l’owner et le comportement après timeout. Tester un cas nominal, un doublon, une erreur de validation, une réponse perdue et un consommateur ralenti. Le critère de sortie est une preuve lisible pour chaque scénario.

Jours 11 à 30 : charger, couper et reprendre

Réaliser la copie initiale ou le rattrapage par Bulk, puis activer CDC/Pub/Sub sur un périmètre borné. L’instrumentation suit replay ID, profondeur, âge du retard, erreurs et consommation. Le seuil d’arrêt est validé avec le métier avant l’ouverture.

Couper volontairement le consommateur, reprendre dans la fenêtre de rétention, puis simuler une coupure plus longue avec extraction Bulk et réconciliation. Le passage à l’objet suivant exige deux cycles complets sans doublon, sans perte inexpliquée et avec un temps de résorption compatible avec l’engagement. Le compte rendu associe chaque mesure à la configuration effectivement testée.

• Séparer chargement initial, delta continu et réconciliation.
• Persister le replay ID seulement après le traitement utile.
• Limiter la demande d’événements à la capacité réelle du consommateur.
• Récupérer et traiter les résultats partiels des jobs Bulk.
• Relier chaque alerte à un owner, un seuil et une action de runbook.

Erreurs fréquentes sous charge

Les incidents récurrents viennent rarement d’un manque d’endpoints. Ils apparaissent lorsqu’un traitement unitaire est étendu à une masse, qu’un curseur est pris pour une sauvegarde ou qu’un accusé de réception est confondu avec une application métier.

Traiter CDC comme une piste d’audit

CDC sert la synchronisation de systèmes aval, pas la conservation exhaustive et perpétuelle de tous les changements. La rétention est temporaire et Salesforce recommande d’autres mécanismes pour les besoins d’audit.

Une copie de référence, des contrôles de cohérence et la trace des décisions du middleware restent indispensables. Sans eux, l’équipe sait qu’elle a consommé un flux, mais pas que la cible reflète le bon état.

Relancer avant d’avoir lu l’état cible

Un timeout ne prouve pas l’absence d’écriture. Renvoyer un message ou un fichier entier sans rechercher les clés d’opération transforme un incident de communication en doublons métier.

La reprise commence par une lecture, classe les cas absents, réussis, rejetés ou ambigus, puis choisit l’action. Le rollback porte sur la règle ou le lot maîtrisé ; il ne consiste pas à effacer indistinctement ce qui a été chargé.

• Ne pas utiliser REST en boucle pour remplacer un job Bulk.
• Ne pas supposer que les replay IDs sont des numéros continus.
• Ne pas demander des événements plus vite que l’aval ne les traite.
• Ne pas fermer un incident avant la réconciliation du périmètre.

Sources et guides Salesforce

Les capacités, éditions et allocations évoluent. Les pages officielles doivent être vérifiées avec la version d’API et l’organisation réellement utilisées avant de figer un dimensionnement.

Pour transformer ces choix en architecture exploitable, la page intégrateur Salesforce API permet de cadrer objets, accès, reprise et premier pilote.

Croiser documentation et retour d’exploitation

La documentation décrit les garanties de la plateforme ; un test sur la sandbox puis sur un volume représentatif mesure les performances de la chaîne complète. Les deux sources sont nécessaires pour fixer un engagement.

Les références officielles sur Bulk API 2.0 Ingest, la conservation des événements CDC et le contrôle de flux Pub/Sub précisent les comportements à tester.

• Salesforce API : architecture d’intégration
• Salesforce, contrats, commandes et factures
• Construire un runbook d’incident API

Ne pas déduire la fin d’un export du nombre annoncé

Avant de changer de transport pour augmenter le volume, vérifiez que le connecteur suit réellement les résultats de son interface actuelle. Un total repris depuis l’enveloppe d’une requête peut faire apparaître une extraction terminée alors que seule la première réponse a été reçue. Une augmentation de capacité ne corrige pas cette interprétation du résultat.

L’anatomie du compteur Salesforce comparé aux pages effectivement reçues sépare annonce, occurrences, identités distinctes et confirmations de sortie. Ses huit situations fictives ne testent aucun locator réel ni stockage durable. Elles donnent un contrôle préalable au choix d’architecture, puis un périmètre à éprouver avec le consommateur aval.

Conclusion : choisir une reprise avant un transport

REST, Bulk API 2.0, CDC et Pub/Sub répondent à des charges différentes. Le bon assemblage sépare interaction, masse et delta, puis protège chaque système selon sa capacité réelle.

Le replay couvre une interruption bornée ; la réconciliation couvre les écarts et les coupures longues. L’idempotence, la lecture de l’état cible et les résultats partiels Bulk empêchent la reprise de fabriquer un nouvel incident.

Une architecture mature sait ralentir, isoler un objet, expliquer le retard et rattraper sans perdre le flux courant. Sa qualité se mesure à l’âge du plus ancien changement utile et au temps nécessaire pour retrouver un état réconcilié.

Dawap peut vous aider à cadrer et éprouver ce dispositif d’intégration API : choix du transport, contrats, test de charge, monitoring, rollback et reprise sur des scénarios Salesforce concrets.