API
Intégration API Salesforce sur mesure : fiabiliser CRM, ERP et opérations
Dawap conçoit, reprend et supervise votre intégration Sales Cloud ou Service Cloud avec ERP, e-commerce, support, BI et applications métier. Un dossier témoin sécurise external ID, autorité des champs, upsert, quotas, événements et reprise avant d’étendre les objets.
- Autorité définie champ par champ
- Upsert retrouvé après timeout
- Quota et replay lisibles par le run
Premier échange centré sur un Account ou une Opportunity qui diverge entre Salesforce et le SI.
APIs, données et infrastructures que nos projets savent connecter
Du besoin métier au run mesurable
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
actionnable
Réponse immédiate
Une intégration API Salesforce sur mesure relie le CRM au SI sans abandonner l’autorité des objets au dernier écrivain.
Dawap définit les objets et champs maîtres, les external IDs, les règles d’upsert, les droits OAuth, le canal REST, Bulk ou événementiel, puis conserve chaque tentative et son effet. Sales Cloud ou Service Cloud peut ainsi échanger avec l’ERP, l’e-commerce, le support et la BI sans créer de doublons après timeout ni sacrifier les flux urgents à un backfill.
- Préférer une External Client App pour une nouvelle intégration ; qualifier les Connected Apps existantes comme un périmètre legacy à maintenir ou migrer.
- Employer REST ou Composite pour le transactionnel, Bulk API 2.0 pour les jobs asynchrones volumineux et Pub/Sub pour Platform Events ou Change Data Capture.
- Attacher chaque Account, Contact, Opportunity, Case ou custom object à un external ID, une autorité et des champs inscriptibles.
- Relire le record, le job ou la position d’événement avant une reprise lorsque l’effet de l’appel reste ambigu.
Record authority ledger · scénario illustratif
Deux systèmes proposent. Le contrat décide champ par champ.
L’organisation, les comptes, montants, identifiants et consommations ci-dessous sont fictifs. Ce registre illustre une autorité explicite entre Salesforce, ERP et middleware.
01 · Propositions
Deux changements arrivent au même instant
Sales Cloud · humainCorrection commerciale
- Phone
- +33 4 72 … 91
- StageName
- Closed Won
Proposition Écrire le contact et la décision commerciale.
ERP · événementMise à jour gestion
- PaymentTerm__c
- NET_30
- CreditStatus__c
- VALIDATED
Proposition Écrire la condition et le statut de crédit.
Collision volontairement refuséeL’ERP propose aussi Phone, mais ne possède pas ce champ.
QUARANTAINE02 · Matrice d’autorité
Account 001…Q7M après arbitrage
ACCOUNT FICTIFMaison Atlas Europe
UPSERT RETROUVÉ- Phone
- +33 4 72 … 91 Sales CloudAPPLIQUÉ
- PaymentTerm__c
- NET_30 ERPAPPLIQUÉ
- CreditStatus__c
- VALIDATED ERPAPPLIQUÉ
- Lifecycle__c
- CUSTOMER MiddlewareCALCULÉ
- Phone · ERP
- +33 1 40 … 08 Non autoriséIGNORÉ
- 09:42:10Clé résolueCLIENT-8041 retrouvé
- +18 msOwners appliqués4 champs autorisés
- +306 msUpsert envoyécorrélation SF-82…M4
- +2,1 sRecord relutimeout neutralisé
- +84 msEffet verrouilléune commande ERP
Quatre repères à vérifier dans votre org avant de figer l’architecture
Salesforce recommande désormais les External Client Apps pour les nouvelles intégrations ; les Connected Apps existantes continuent de fonctionner mais leur création est restreinte depuis Spring ’26.
REST et Composite servent les opérations transactionnelles ; Bulk API 2.0 exécute ingest ou query asynchrones ; Pub/Sub publie ou consomme Platform Events et Change Data Capture.
Les événements sont retenus pendant une fenêtre documentée de 72 heures ; le replay ID est opaque et ne doit pas être calculé comme une séquence métier.
Service Cloud reste ici un produit CRM Salesforce, pas une infrastructure cloud. Aucun projet publié ci-dessous ne cite Salesforce ; objets, édition, licences, allocations, règles et accès doivent être vérifiés dans votre org.
Premier lot recommandé
Une org Salesforce, deux objets, un external ID et un effet aval.
Apportez l’Account ou l’Opportunity qui se duplique, diverge ou crée deux commandes. Le cadrage rend owners, canaux, quotas et reprise lisibles avant d’ouvrir le reste du CRM.
Quand le CRM devient une vérité concurrente
Un Account peut être correct dans Salesforce et faux pour la facturation, le support ou la prochaine reprise.
La difficulté n’est pas d’appeler un endpoint. Elle est de décider qui crée, qui enrichit, qui refuse et comment retrouver un effet quand CRM, ERP et commerce écrivent le même dossier.
01
Autorité
Deux systèmes corrigent le même champ avec deux raisons valides
L’owner est défini par objet et parfois par champ. Une écriture sans autorité devient une anomalie visible, pas une mise à jour silencieuse.
02
Unicité
Le timeout masque un upsert déjà accepté
External ID, tentative, réponse et relecture sont corrélés avant tout nouvel effet afin de ne pas dupliquer Account, Contact ou commande.
03
Capacité
Un backfill consomme la marge des flux commerciaux
REST, Composite, Bulk API 2.0 et Pub/Sub sont arbitrés selon délai, volume, dépendances, quota, replay et impact métier.
Contrats d’un CRM connecté
Six contrats empêchent Salesforce de devenir le dernier écrivain qui gagne.
Salesforce porte des objets riches et plusieurs canaux d’intégration. La cohérence dépend encore des autorités, identifiants, transitions et preuves décidés avec les systèmes voisins.
L’external ID précède l’upsert
La clé métier, son unicité, son cycle de vie et le record Salesforce associé sont vérifiés avant toute création ou fusion.
L’application et l’utilisateur technique ont un rôle borné
External Client App, OAuth, scopes, permission sets, rotation et révocation sont séparés des droits fonctionnels du middleware.
L’owner peut changer selon l’objet et le champ
Salesforce peut posséder le stage commercial, l’ERP la condition de paiement et le support le Case sans écrasement croisé.
Transaction, volume et événement ne partagent pas le même rail
REST/Composite, Bulk API 2.0 et Pub/Sub sont choisis selon délai, dépendances, volume, résultat attendu et capacité de replay.
La réponse technique est rapprochée du record métier
Record ID, erreurs de champ, job, quota et événement sont reliés à la décision qui autorise clôture, rejet ou reprise.
Chaque reprise relit l’état courant
Le connecteur vérifie record, job, position d’événement et action humaine avant de rejouer un effet potentiellement déjà produit.
Méthode objet–autorité–effet
Signer la matrice d’écriture avant de choisir les endpoints Salesforce.
Dawap part du dossier qui diverge ou se duplique. Sales, service, finance, data et IT nomment les objets, champs, autorités, transitions, identifiants, validations, capacités et preuves. Les API sont ensuite affectées à des décisions déjà assumées.
Distinguer l’autorité
Savoir quel système peut créer, enrichir, décider ou refuser chaque champ.
Retrouver l’effet
Relire le record ou le job avant une nouvelle écriture après timeout.
Protéger la capacité
Réserver une marge aux parcours urgents pendant les imports et backfills.
Rejouer avec preuve
Conserver corrélation, résultat, erreur et décision humaine sous le même dossier.
Premier lot Salesforce
Faire converger un Account et une Opportunity avant de brancher tout le CRM.
On choisit une org Salesforce, un périmètre métier, deux objets, un external ID et un effet aval. Le lot est accepté lorsque l’owner de chaque champ est lisible, qu’un timeout ne produit pas de doublon et que commerce, gestion et support retrouvent la même décision.
1 org Salesforce
2 objets
1 external ID
1 effet aval
5 contre-tests
Sorties attendues
Carte source–middleware–Salesforce–ERP–support avec owner et droit d’écriture pour chaque étape.
Contrat Account et Opportunity : external ID, champs maîtres, relations, validation rules, statut et effet aval.
Matrice REST/Composite–Bulk API 2.0–Pub/Sub avec délai, volume, dépendances, quota et replay attendu.
Cinq contre-tests : règle de validation, doublon candidat, timeout après upsert, quota sous seuil et événement ancien.
Journal expurgé reliant dossier, external ID, record ID, job ou replay ID, tentative, quota et verdict.
Recette sales–service–finance–IT, balance attendu–appliqué–refusé–à reprendre, alertes et runbook.
Recette Salesforce–SI
Trois scénarios doivent converger vers une décision défendable, pas seulement un statut API.
Ces scénarios et leurs valeurs sont illustratifs. Ils doivent être rejoués sur votre org, vos objets, vos règles et vos allocations. Aucun projet public ci-dessous n’est présenté comme une intégration Salesforce livrée.
L’ERP et Salesforce modifient deux champs du même compte.
- Scénario terrain
- Le commercial corrige le téléphone pendant que la gestion change la condition de paiement. Une synchronisation objet complet écraserait une donnée pourtant légitime.
- Architecture
- Autorité par champ, payload partiel, version source, précondition, journal de décision et file de conflit.
- Livrable
- Fixture concurrente, matrice d’owner, diff avant–après et preuve du champ volontairement ignoré.
- Décision
- Appliquer chaque modification autorisée et isoler la collision sans perdre les deux propositions.
- Résultat vérifiable
- Téléphone et condition de paiement convergent vers leur source de vérité respective.
Le client ne sait pas si l’Opportunity a été écrite.
- Scénario terrain
- La réponse se perd après l’appel REST. Rejouer immédiatement pourrait produire un record concurrent ou un effet ERP doublé.
- Architecture
- External ID stable, corrélation, relecture par clé, verrou d’effet et reprise séparée du déclenchement aval.
- Livrable
- Deux fixtures réseau, preuve de relecture, balance de records et commande de reprise ciblée.
- Décision
- Retrouver le record et son effet aval avant d’autoriser toute nouvelle mutation.
- Résultat vérifiable
- Une Opportunity et une seule commande restent rattachées au dossier source.
Un job Bulk consomme la marge des flux commerciaux.
- Scénario terrain
- Le rattrapage historique accélère alors que les nouveaux leads et Cases doivent continuer à circuler. Le quota global ne reflète pas la priorité métier.
- Architecture
- Budget par file, seuil de suspension, job Bulk suivi, trafic urgent réservé et reprise au prochain créneau.
- Livrable
- Jeu de charge, courbe de consommation, seuils, job ID, alertes et runbook de pause.
- Décision
- Suspendre le backfill avant de dégrader les parcours prioritaires puis reprendre sur preuve de capacité.
- Résultat vérifiable
- Les flux urgents restent disponibles et le rattrapage termine sans reprise aveugle.
Sales Cloud, Service Cloud, Marketing Cloud ou Commerce Cloud ?
Le nom Salesforce ne suffit pas : l’owner dépend de l’objet et du parcours.
Cette offre possède le CRM Sales Cloud et Service Cloud connecté au SI. Les produits marketing, commerce et les infrastructures cloud gardent leurs propres données, API et risques.
Le besoin part d’Accounts, Contacts, Opportunities, Cases ou custom objects
L’offre cadre l’intégration Sales Cloud/Service Cloud, les external IDs, les écritures, les canaux API et le run.
Le besoin part des audiences, Data Extensions, journeys ou messages
La landing Marketing Cloud possède l’activation marketing et ses handoffs avec le CRM.
Le besoin part du catalogue, des promotions, paniers ou commandes e-commerce
La landing Commerce Cloud possède le moteur commerce et son intégration retail.
Frontières de responsabilité
Orienter chaque objet Salesforce vers l’équipe qui peut réellement le défendre.
Le CRM possède le dossier commercial et support ; l’ERP la gestion, Marketing Cloud l’activation et Commerce Cloud le parcours de vente numérique.
Pour Art’Sacs, activité reprise depuis par France Appro, Dawap a relié Aster et PrestaShop afin de transformer le catalogue fournisseur, synchroniser les quantités, enrichir les fiches et préparer les commandes dropshipping. Les tâches, états et erreurs donnent aux équipes un flux pilotable plutôt qu’une synchronisation opaque.
Ciama sélectionne quatre lecteurs spécialisés pour collecter commandes et variantes Shopify ou Wix, puis les normalise dans deux modèles communs. Le pipeline protège le compte et le canal, décide entre ajout et mise à jour, distribue les écritures et sécurise la désactivation après un snapshot complet.
Questions d’achat
Questions fréquentes avant une intégration Salesforce API
Réponses sur Sales Cloud, Service Cloud, External Client Apps, REST, Bulk API 2.0, Pub/Sub, external IDs et premier lot.
01Que couvre une intégration API Salesforce sur mesure ?
Elle relie les objets Sales Cloud ou Service Cloud à l’ERP, l’e-commerce, le support, la BI ou une application métier avec external IDs, autorités, mapping, droits, quotas, traces et reprises.
02External Client App ou Connected App pour Salesforce ?
Pour une nouvelle intégration, Salesforce recommande une External Client App. Une Connected App existante peut continuer à fonctionner, mais sa politique, ses scopes, son utilisateur technique et sa trajectoire de migration doivent être qualifiés.
03Quand utiliser REST, Composite, Bulk API 2.0 ou Pub/Sub ?
REST ou Composite convient au transactionnel et aux dépendances bornées, Bulk API 2.0 aux volumes asynchrones, et Pub/Sub aux Platform Events ou Change Data Capture. Le choix dépend du délai, du résultat attendu, du quota et du replay.
04Comment éviter les doublons Salesforce après un timeout ?
On conserve un external ID stable, la tentative et la corrélation, puis on relit le record ou le job avant toute nouvelle mutation. L’effet aval, par exemple une commande ERP, possède son propre verrou.
05Comment protéger les limites API Salesforce ?
Les flux sont classés par criticité, une marge est réservée au temps réel, les jobs Bulk sont pilotés et les réponses de limite déclenchent attente, alerte ou suspension plutôt qu’un retry agressif.
06Quel premier lot Salesforce recommandez-vous ?
Une org Salesforce, un périmètre métier, un Account, une Opportunity, un external ID et un effet aval. On exerce règle de validation, doublon, timeout, quota et événement ancien avant d’ajouter d’autres objets.
Salesforce API · Sales Cloud · Service Cloud
Votre prochain objet Salesforce peut-il prouver qui l’a écrit, pourquoi et comment le reprendre ?
Dawap peut cadrer ce dossier témoin puis construire le middleware, la trace et le run qui protègent Sales Cloud ou Service Cloud jusque dans les timeouts, conflits et backfills.
Auditer mes flux Salesforce