Une opportunité passe à « gagnée », l’intégration appelle l’ERP, puis la réponse expire. Un opérateur relance : une deuxième commande apparaît. Quelques jours plus tard, Salesforce montre un montant signé alors que l’ERP a fractionné la livraison et émis un avoir. Le risque est concret : double livraison, relance client injustifiée et correction manuelle en pleine clôture. Ce type d’écart fait perdre la confiance bien avant de provoquer une panne visible.
Le vrai sujet n’est pas de copier davantage de champs. Il faut relier quatre preuves distinctes : l’engagement commercial, l’acceptation opérationnelle, la pièce financière et son règlement. Salesforce, l’ERP et la comptabilité n’ont ni les mêmes objets ni le même moment de vérité.
Contre-intuitivement, un miroir complet de la facture dans le CRM fragilise souvent le dispositif. Le commercial a besoin d’une synthèse actionnable et d’un lien fiable, pas d’une seconde comptabilité. Le bon arbitrage conserve dans Salesforce le contexte de vente et renvoie depuis l’ERP les références, statuts et exceptions utiles.
Dawap structure ce type d’intégration API autour des responsabilités, des external IDs, de l’idempotence et du rapprochement. L’objectif est qu’une reprise puisse expliquer si la commande existe avant d’essayer de la recréer.
Le test décisif
Coupez la réponse juste après la création ERP, puis rejouez le message. Si une deuxième commande peut apparaître, le flux n’est pas prêt pour une écriture financière.
Distinguer vente gagnée et exécution acceptée
Le stade gagné traduit une décision commerciale. Il ne prouve pas que le compte est facturable, que les articles sont reconnus, que le crédit est ouvert ou que la commande respecte les règles de l’ERP. Confondre ces états transforme les refus opérationnels en corrections de données.
Le cycle doit donc conserver un état intermédiaire : prêt à transmettre, reçu, accepté, rejeté ou en revue. Salesforce affiche l’état de l’exécution sans réécrire l’histoire de l’opportunité.
Définir le point de non-retour
Avant la transmission, certaines corrections restent commerciales : contact signataire, date souhaitée ou option retenue. Après acceptation ERP, prix, quantité ou entité juridique suivent un avenant, une modification de commande ou une annulation contrôlée.
Si un champ modifié après acceptation peut silencieusement réécrire la commande, alors le dossier n’a plus de version opposable. Le workflow bloque cette mutation et guide l’utilisateur vers la procédure appropriée.
Attribuer l’autorité de chaque donnée
Salesforce peut posséder l’opportunité, la relation commerciale et la version approuvée de l’offre. L’ERP possède la commande exécutable, les disponibilités, les livraisons et les factures. La finance possède les écritures, avoirs, lettrages et statuts de paiement.
Ce partage doit être adapté au SI réel. Une organisation peut utiliser les objets Salesforce standard, un CPQ, Revenue Cloud ou des objets personnalisés. L’intégration ne suppose jamais qu’un objet nommé « Contract » ou « Order » porte partout le même processus.
Écrire une matrice champ par champ
Pour chaque donnée, la matrice nomme la source autoritaire, les lecteurs, le moment de figement et la règle de correction. Le montant attendu peut venir de l’offre avant commande, puis le montant facturé vient exclusivement de l’ERP.
Le middleware refuse une écriture dans le mauvais sens. La méthode pour corriger une donnée intégrée en conservant son histoire relie la demande, son approbation et les effets à reprendre. Une facture renvoyée dans Salesforce informe le commerce ; cette copie ne lui donne pas l'autorité de réécrire la pièce engagée dans l'ERP.
Construire des clés anti-doublon
L’identifiant Salesforce relie l’objet source, mais ne suffit pas toujours à décrire l’opération. Une opportunité peut produire plusieurs commandes, et un contrat renouvelé peut conserver le même compte. La clé d’opération encode le type, la version approuvée et le périmètre juridique.
Dans Salesforce, un champ External ID marqué unique permet un upsert sûr : aucune correspondance crée, une correspondance met à jour, plusieurs correspondances provoquent une erreur. Côté ERP, une contrainte équivalente doit protéger la création de commande.
Séparer identité d’objet et identité de tentative
La commande possède une référence durable ; chaque appel possède un identifiant de corrélation. Le premier empêche le doublon métier, le second permet de suivre retries, latence et réponses sans confondre plusieurs tentatives.
Une clé calculée depuis le nom du compte, la date ou le montant reste fragile. Ces valeurs peuvent changer et se répéter. La clé est attribuée avant le premier appel, stockée des deux côtés et jamais recyclée.
Figer une version contractuelle exécutable
Le contrat transmis n’est pas un agrégat mouvant de champs. Il correspond à une version approuvée avec entité vendeuse, compte facturé, devise, lignes, quantités, prix, taxes attendues, période et conditions particulières.
Les documents restent dans leur système documentaire ; le payload transporte les valeurs structurées nécessaires et la référence du document signé. L’ERP vérifie ses propres règles avant d’accepter.
Gérer l’avenant sans écraser l’original
Un avenant crée une nouvelle version ou une opération de modification reliée à la précédente. Il ne remplace pas rétroactivement les données qui ont produit une commande ou une facture existante.
Le différentiel indique ce qui change et sa date d’effet. Si la commande a déjà commencé, alors l’ADV décide entre modification, annulation partielle et nouvelle commande. Le connecteur ne tranche pas cette conséquence seul.
Créer la commande ERP une seule fois
La création commence par les précontrôles : compte ERP certain, adresses valides, références articles reconnues, devise autorisée, conditions de paiement disponibles et version contractuelle approuvée. Un rejet de ces règles reste fonctionnel et ne doit pas être retenté automatiquement.
Le middleware publie ensuite une commande avec clé d’idempotence. La sortie attendue comprend référence ERP, statut d’acceptation et détail des rejets. Une réponse HTTP réussie sans référence exploitable ne ferme pas le traitement.
Traiter le timeout après écriture
Après un timeout, le retry interroge l’ERP avec la clé externe. Si la commande existe, il enregistre sa référence et termine la corrélation. Si elle n’existe pas, il peut retenter. Si la lecture est impossible, l’opération reste en attente.
Le test de production simule précisément cette frontière. Deux tentatives doivent laisser une seule commande, une chronologie complète et aucun doute sur le statut visible dans Salesforce.
Par exemple, pour une commande de 48 000 € dont l’appel expire après l’écriture, le seuil de 15 minutes sans référence déclenche une lecture ERP et suspend toute nouvelle création liée au même contrat. Si la référence est retrouvée, alors le flux rattache l’existant au lieu de rejouer.
Gérer commandes et factures partielles
Une opportunité ne correspond pas nécessairement à une commande, et une commande peut produire plusieurs livraisons ou factures. Forcer une relation un-à-un conduit à écraser des références ou à perdre les reliquats.
Le modèle conserve une collection de commandes ERP reliées à la version contractuelle. Chaque commande expose son montant, son exécution et son reste à servir. Le total commercial est rapproché, pas recopié comme statut unique.
Calculer le reste sans inventer un statut
Le reste à commander, livrer ou facturer se calcule depuis des quantités et montants comparables. Les annulations et avoirs sont des mouvements explicites, pas des valeurs négatives ajoutées sans origine.
Si une ligne est partiellement livrée, Salesforce peut afficher « en cours d’exécution » et la prochaine date connue. Il ne doit pas déduire « terminé » du seul fait qu’une première facture existe.
Renvoyer factures, avoirs et paiements
L’ERP ou le système financier reste la source des numéros de facture, dates d’émission, montants comptables et avoirs. Salesforce reçoit une projection commerciale : pièce émise, montant, devise, échéance, statut synthétique et lien vers la source autorisée.
Un paiement ne doit pas être assimilé à la simple réception d’une notification PSP. Le statut « payé » vient du rapprochement financier ou de la règle explicitement choisie avec la finance.
Conserver le lien brut–net
Le montant du deal, la commande, la facture, l’avoir et l’encaissement répondent à des questions différentes. Le mapping conserve leurs références et n’écrase pas le montant signé avec le net encaissé.
Une facture annulée reste visible avec son avoir ou sa pièce de remplacement. Supprimer la première référence casse l’audit et empêche le commercial d’expliquer la chronologie au client.
Afficher des statuts commerciaux fiables
Les statuts Salesforce doivent déclencher une action : à compléter par le commerce, en revue ADV, accepté par l’ERP, partiellement exécuté, bloqué pour crédit ou facturé. Un statut « erreur » sans cause ni responsable ne sert pas le terrain.
Le détail technique reste dans l’observabilité. Le CRM affiche le code métier, l’objet concerné, la dernière mise à jour fiable et l’équipe attendue. Une nouvelle tentative ne remet pas arbitrairement le statut au vert.
Empêcher les retours en arrière silencieux
Chaque transition possède une version ou un horodatage de source. Un ancien événement ne peut pas remplacer un état plus récent. Les transitions impossibles passent en quarantaine avec les deux preuves comparées.
Si une correction manuelle est autorisée, elle conserve auteur, motif, ancienne valeur et durée de validité. Le prochain flux ne doit pas l’effacer sans examiner cette décision humaine.
Reprendre une écriture au bon endroit
Une erreur réseau peut être retentée avec backoff. Un compte inconnu, une ligne invalide ou un plafond de crédit exige une correction métier. Une référence déjà utilisée exige une lecture de l’existant, pas une nouvelle clé opportuniste.
Le message de dead-letter conserve payload, schéma, tentative, réponse et identifiants de corrélation. Le runbook explique les conditions d’un retry, d’un abandon, d’une compensation ou d’une reprise manuelle.
Séparer transaction Salesforce et transaction ERP
Une requête Composite Salesforce peut regrouper des sous-requêtes et, selon allOrNone, annuler leur traitement dans Salesforce. Elle ne crée pas pour autant une transaction distribuée avec l’ERP. Le rollback d’un système n’annule pas magiquement l’autre.
La cohérence inter-systèmes repose sur des états durables, une outbox ou une queue, des commandes idempotentes et des compensations explicites. Cette architecture accepte qu’une étape soit temporairement en attente sans mentir au CRM.
Réconcilier CRM, ERP et finance
Le flux temps réel ne prouve pas à lui seul l’exhaustivité. Une réconciliation quotidienne rapproche versions transmises, commandes créées, factures émises, avoirs et statuts retournés. Elle classe les différences par cause et impact.
Les cas utiles sont : source sans cible, cible sans source, montant divergent, statut ancien et relation manquante. Chaque écart possède un owner ; aucun script de correction ne modifie les pièces financières sans validation.
Mesurer la qualité par les exceptions
Le tableau de bord suit doublons empêchés, commandes sans retour, factures orphelines, avoirs non propagés, âge de la plus vieille divergence et temps de résolution. Un taux de succès de 99,8 % reste mauvais si le reliquat porte les plus grosses commandes.
Le coût caché comprend les heures de rapprochement, les relances client incorrectes et les clôtures retardées. Relier ces impacts aux causes techniques permet de prioriser les corrections du contrat plutôt que d’accumuler des rustines.
Cas concret : si une facture de plus de 10 000 € reste sans commande source pendant 24 heures, alors la réconciliation ouvre une anomalie finance, bloque sa propagation commerciale et conserve les deux références. Ce seuil empêche qu’une pièce orpheline soit présentée comme un revenu correctement rattaché.
Pour qui cadrer ce cycle quote-to-cash
Ce dispositif concerne les entreprises qui pilotent la vente dans Salesforce et exécutent commandes, livraisons ou facturation dans un ERP. Il devient prioritaire lorsque les équipes recréent manuellement les commandes ou vérifient chaque facture dans plusieurs outils.
Faire décider ventes, ADV, ERP et finance
Les ventes définissent l’engagement et la visibilité nécessaire. L’ADV valide les conditions d’exécution. L’équipe ERP possède commandes et livraisons. La finance définit facture, avoir et paiement. L’administrateur Salesforce garantit le modèle CRM.
Leurs décisions sont inscrites dans une matrice RACI et un dictionnaire d’états. Le support sait alors qui peut corriger une référence, autoriser un replay ou expliquer un blocage au client.
Différer si la version approuvée est introuvable
Il faut différer la création automatique lorsqu’aucune version figée ne permet de reproduire le prix, les lignes et l’entité signataire. Un deal gagné avec des champs encore modifiables n’est pas une commande fiable.
Le pilote peut commencer sur une offre simple, une entité juridique et un type de commande. Les renouvellements, acomptes ou facturations multi-entités arrivent après validation de ce parcours de base.
Plan d’action sur un flux de commande
Jours 1 à 10 : autorité, versions et clés
Sélectionner un type de contrat et suivre dix dossiers réels de Salesforce jusqu’à la facture. Documenter les objets présents dans cette org, les champs obligatoires, les transformations manuelles et les moments où une référence devient stable. Pour chaque dossier, comparer la version signée, la commande et la pièce comptable afin de faire apparaître les conventions jusque-là implicites.
Écrire la matrice d’autorité et le contrat d’entrée : version approuvée, external ID, compte ERP, lignes, devise et date d’effet. La sortie comprend référence de commande, statut, rejets et corrélation. Les responsabilités de correction sont nommées. Une revue avec ventes, ADV et finance valide aussi les transitions interdites et les données qui ne doivent jamais revenir dans Salesforce.
Jours 11 à 30 : pilote, reprise et rapprochement
Activer le flux sur un périmètre borné avec queue, idempotence, journalisation et monitoring. Tester timeout après écriture, doublon, compte absent, ligne rejetée, commande partielle et facture corrigée. Chaque scénario produit une sortie lisible dans Salesforce. Le tableau de bord relie la tentative technique au contrat, à la commande et à l’owner capable d’agir.
Lancer ensuite la réconciliation quotidienne et mesurer les exceptions pendant deux cycles de facturation. Si une commande reste sans référence plus de quinze minutes, alors la création suivante pour le même contrat est bloquée. L’extension exige zéro doublon et un owner pour chaque écart restant. Un replay complet sur les données du pilote vérifie enfin que les clés résistent à une reprise globale.
- Figer la version contractuelle qui autorise l’exécution.
- Créer la clé d’opération avant le premier appel ERP.
- Rechercher la commande après tout timeout incertain.
- Conserver factures et avoirs comme pièces reliées, jamais écrasées.
- Rapprocher quotidiennement CRM, commandes et écritures financières.
Erreurs fréquentes entre CRM et ERP
Les erreurs les plus coûteuses consistent à utiliser le stade gagné comme ordre d’exécution, à relancer après timeout sans lire la cible, ou à prendre le montant d’opportunité pour un montant comptable.
Utiliser le nom comme clé de rapprochement
Les noms de comptes, contrats et offres changent et ne sont pas uniques. Un rapprochement textuel peut associer la facture d’une filiale au mauvais dossier ou confondre deux renouvellements.
Les external IDs uniques et les relations explicites sont obligatoires pour automatiser. Une correspondance approximative reste une proposition soumise à revue et ne déclenche aucune écriture financière.
Faire du CRM une seconde comptabilité
Recopier chaque détail fiscal, lettrage et correction multiplie les points de divergence. Le CRM expose la synthèse utile à la relation client et renvoie vers la pièce de référence selon les droits.
Le gain se mesure au nombre de questions commerciales résolues sans solliciter la finance, pas au nombre de colonnes synchronisées. Une projection plus petite, datée et fiable vaut mieux qu’un miroir incomplet.
- Ne pas rouvrir un deal pour représenter un avoir comptable.
- Ne pas remplacer une ancienne facture par sa correction.
- Ne pas supposer qu’un rollback Salesforce annule l’ERP.
- Ne pas automatiser un renouvellement sans nouvelle version approuvée.
Approfondir Salesforce et la reprise
Le modèle exact dépend des produits Salesforce activés et des objets personnalisés de l’organisation. La description des sObjects, leurs champs et leurs contraintes doit faire partie de l’inventaire technique.
La page intégrateur Salesforce API aide à cadrer le premier flux, les droits, les clés et les scénarios de reprise avec l’ERP.
Vérifier les garanties d’écriture
La documentation officielle précise le comportement des upserts et des requêtes composites. Elle doit être lue avec la version d’API utilisée, puis confrontée aux validations, flows et triggers propres à l’org.
Les pages Salesforce sur l’upsert par external ID et le comportement allOrNone donnent les garanties à traduire dans les tests.
- Salesforce sous charge : Bulk, CDC et Pub/Sub
- Salesforce API : architecture et limites
- Réconcilier les écarts entre source et cible
Conclusion : relier les preuves sans dupliquer les objets
Une opportunité gagnée, une commande acceptée, une facture émise et un paiement rapproché sont quatre faits différents. Les relier produit une vue fiable ; les confondre crée des statuts trompeurs.
Les versions contractuelles, external IDs uniques et clés d’idempotence protègent les écritures. La lecture de la cible après timeout et la réconciliation quotidienne rendent la reprise sûre.
Salesforce doit montrer au commerce ce qui est signé, exécutable et bloqué sans devenir un second ERP. La valeur vient d’une synthèse actionnable, reliée à la bonne preuve et à son owner.
Dawap peut vous accompagner sur cette chaîne d’intégration API : modèle d’autorité, mapping Salesforce–ERP, idempotence, tests d’échec, observabilité et rapprochement jusqu’à la facture.
