Salesforce peut porter une vision commerciale très riche, mais contrats, commandes et factures engagent souvent un ERP, une finance ou une application métier. Le risque classique est de laisser plusieurs systèmes créer ou modifier des objets proches sans règle claire de propriété.
Une opportunité gagnée, un contrat signé, une commande créée et une facture émise peuvent représenter la même réalité à des étapes différentes. Sans clé stable, chaque système finit par raconter sa version.
Une intégration Salesforce API robuste doit donc séparer création, validation, consultation et preuve. Salesforce doit aider le commerce à lire la situation, pas devenir un ERP parallèle.
Le sujet est particulièrement sensible dans les organisations où le commerce avance vite et où la finance contrôle ensuite les écarts. Si le flux ne donne pas une preuve claire, chaque équipe reconstruit l’historique depuis son outil.
Le cadrage doit donc partir des décisions irréversibles : signature, validation, création de commande, émission de facture, correction, avoir et annulation. Ces étapes méritent des clés et statuts plus stricts qu’un simple enrichissement de fiche.
Le risque à éliminer
Si une opportunité gagnée peut créer deux commandes ou si une facture peut revenir sans référence stable, l’intégration n’est pas prête pour la production.
Pourquoi contrats, commandes et factures divergent
Le commerce raisonne en opportunités et contrats. L’ERP raisonne en commandes, articles, factures et écritures. La finance raisonne en preuves, montants, taxes et paiements.
Ces visions ne sont pas contradictoires, mais elles doivent être reliées par des règles explicites.
Nommer le responsable de chaque objet
Le contrat, la commande et la facture n’ont pas toujours le même responsable. Salesforce peut initier, l’ERP peut valider, la finance peut contrôler et le support peut consulter.
Cette séparation doit être documentée pour éviter les mises à jour contradictoires.
Définir les clés anti-doublon
La clé externe est la protection principale contre la double création. Elle doit relier opportunité, contrat, commande et facture sans dépendre d’un intitulé modifiable.
Le connecteur doit reconnaître une opération déjà traitée et renvoyer un statut lisible plutôt que relancer une écriture.
Cadrer le contrat avant la commande
Le contrat peut porter durée, conditions, engagements, prix, volumes, dates et validations. Tout ne doit pas nécessairement devenir une commande immédiatement.
L’intégration doit dire quand un contrat est assez validé pour produire une opération aval, et quels champs restent informatifs.
Créer la commande sans réécrire l’opportunité
Une commande créée dans l’ERP ne doit pas modifier l’historique commercial sans règle. Elle doit renvoyer une preuve, un statut et une référence.
Le deal Salesforce garde la lecture commerciale ; l’ERP garde l’exécution opérationnelle.
Renvoyer la facture comme preuve
Les équipes commerciales ont besoin de savoir si la facture existe, si elle est bloquée ou si elle a été corrigée. Elles n’ont pas besoin de toute la complexité comptable dans Salesforce.
Le bon retour expose le statut, la référence, la date, le montant utile et la cause d’erreur si elle existe.
Afficher des statuts actionnables
Un statut doit aider une action : compléter un contrat, valider une adresse, corriger un compte, attendre l’ERP, relancer la finance ou escalader un incident.
Les statuts trop techniques forcent les commerciaux à demander une traduction. Les statuts trop vagues cachent la cause.
Reprendre une écriture sensible
La reprise doit être conservative. Avant de rejouer une création de commande ou de facture, le flux doit vérifier si une écriture équivalente existe déjà.
Chaque rejeu doit laisser une trace : qui l’a déclenché, sur quelle référence, avec quel résultat et quelle action restante.
Gouverner commerce, ERP et finance
Les équipes doivent partager une matrice simple : qui crée, qui valide, qui corrige, qui consulte et qui supporte chaque objet.
- Séparer création, validation et consultation.
- Tracer chaque écriture sensible avec une clé stable.
- Renvoyer les blocages au bon propriétaire métier.
- Empêcher les retries de créer des doublons.
- Auditer régulièrement les écarts entre Salesforce et ERP.
Cette matrice doit être testée sur des cas inconfortables : contrat modifié après signature, commande refusée par l’ERP, facture corrigée, avoir partiel, fusion de comptes ou changement de propriétaire commercial.
Si l’intégration ne sait pas expliquer ces scénarios, elle paraîtra fiable sur le flux nominal mais fragile dès que le business vivra ses exceptions normales.
Le bon niveau de gouvernance n’alourdit pas le projet. Il évite que Salesforce devienne un lieu de correction informelle où chacun “répare” sa partie sans que l’ERP ou la finance comprenne la suite.
Conclusion : Salesforce reste lisible, l’ERP reste fiable
Une intégration Salesforce robuste ne transforme pas le CRM en ERP. Elle fait circuler les preuves nécessaires aux équipes commerciales sans dupliquer les responsabilités.
Cette frontière réduit les doublons, clarifie les statuts et rend les reprises plus simples. Pour le socle volume et événements, l’article Salesforce API : Bulk, CDC et webhooks complète cette lecture.
