Deux commerciaux convertissent chacun leur Lead Salesforce vers le même compte. Le CRM retrouve bien les deux contacts, mais le middleware ouvre deux clients dans l’ERP, ou ne sait plus à quelle fiche rattacher la prochaine demande. La conversion a réussi ; le problème se situe dans le rapprochement des identités. Le correctif commence par retrouver le compte cible et sa correspondance ERP, avant toute nouvelle création.
En pratique, une conversion ne signifie pas nécessairement qu’un nouvel Account a été créé. Salesforce permet de réutiliser un compte existant et restitue son identifiant dans le résultat. Deux Leads peuvent donc mener au même client déjà connu. Conserver seulement l’ancien identifiant de Lead, ou déduire un nouveau client de chaque succès, fait perdre cette convergence au moment où le dossier passe du commercial à la gestion.
Le laboratoire proposé rapproche deux conversions fictives d’un client existant, puis introduit une correspondance contradictoire sur le second Lead. Il produit des propositions en lecture seule : aucun appel Salesforce, aucune création ni fusion ERP. Ses 52 contrôles montrent pourquoi le conflit doit retenir tous les dossiers qui rejoignent ce compte, tout en laissant un autre compte qualifié suivre son propre traitement.
Dawap intervient sur les échanges API entre CRM, ERP et applications métier pour définir ces correspondances et leurs conditions de reprise. Une intégration Salesforce adaptée à votre organisation commerciale permet de distinguer conversion du prospect, identification du client et autorisation des opérations qui suivront.
Pour qui : des clients ERP se dédoublent après conversion des Leads
Partir du dossier que la gestion ne sait plus rattacher
Le symptôme peut apparaître sans erreur de transport : les fiches sont présentes, les contacts existent et le connecteur annonce une opération réussie. Pourtant, une commande rejoint un client récemment créé alors que les factures précédentes appartiennent à un autre. Il faut conserver les identifiants de cette exécution, puis comparer le Lead d’origine, le compte Salesforce obtenu et la référence réellement utilisée dans l’ERP.
Le coût caché dépasse une fiche supplémentaire. Les équipes peuvent devoir rapprocher un encours, rechercher l’historique d’un client ou expliquer pourquoi deux dossiers portant le même nom suivent des règles différentes. Il ne faut pas conclure que tous les homonymes doivent être fusionnés : une même enseigne peut couvrir plusieurs entités ou comptes de facturation. Le diagnostic porte d’abord sur les correspondances que votre modèle avait prévues.
Limiter la règle au modèle commercial effectivement retenu
Notre profil suppose qu’un compte Salesforce qualifié possède une seule cible client dans le périmètre ERP étudié. Ce choix n’est pas une règle universelle du CRM. Si un Account représente un groupe avec plusieurs sociétés facturées séparément, il faut une clé supplémentaire et un arbitrage métier. Choisir le premier client trouvé sous le même nom masquerait cette différence au lieu de la résoudre.
Le programme utilise des identités fictives et un périmètre déclaré. Il ne découvre ni l’organisation Salesforce authentifiée ni la société ERP concernée. En production, ces dimensions doivent accompagner le mapping. Le cas des Person Accounts et les changements de compte après une fusion restent hors de ce laboratoire ; ils demandent une qualification spécifique avant de réutiliser ses décisions.
Le compte issu de la conversion peut déjà posséder son client ERP
Lire le compte retourné plutôt que recréer depuis le Lead
La référence SOAP convertLead distingue la création d’un compte et l’utilisation d’un accountId existant. Le résultat doit donc être confronté à la demande conservée. Si l’Account était imposé, un autre identifiant reçu exige une revue de corrélation. S’il ne l’était pas, il faut encore rechercher sa correspondance, sans supposer qu’aucun traitement antérieur ne l’a déjà relié.
Le contactId répond à une autre question : quelle personne est associée à cette conversion ? Deux contacts distincts ne justifient pas deux clients de gestion. L’opportunité reste également un objet séparé et peut être absente du parcours. Le connecteur doit conserver ces rôles, plutôt que ranger tous les identifiants retournés dans une seule colonne dont la signification dépendrait de l’appel précédent.
Ne pas confondre identité cible et enrichissement des champs
Réutiliser un compte ne signifie pas que toutes ses données seront remplacées par celles du Lead. Les règles natives de conversion et les mappings configurés par l’administrateur déterminent les champs transférés. Un middleware qui attend un écrasement général peut donc créer un second dossier pour contourner une adresse ou un attribut resté inchangé, alors que le problème concerne la règle d’enrichissement.
La recherche d’identité doit être séparée de cette correction. Retrouver d’abord le client ERP attendu, puis décider quels champs peuvent évoluer et qui en reste responsable. L’analyse des échanges Salesforce entre contrats, commandes et factures prolonge cette distinction lorsque le rattachement entraîne des opérations dont l’historique doit rester explicable.
Retrouver la conversion sans la déclencher une seconde fois
Conserver le plan envoyé et les résultats par position
La documentation LeadConvertResult associe chaque résultat à la position correspondante de la demande. Le connecteur conserve donc l’ordre des Leads, leur référence métier et le compte éventuellement demandé. Une liste de réponses réordonnée indépendamment de ce plan ne peut plus être interprétée comme si les positions étaient restées identiques.
Notre lecteur exige l’identité du Lead pour une réussite et vérifie celle d’un échec lorsqu’elle est fournie. Un échec sans cette identité reste rattaché par sa position documentée ; il ne devient pas une réussite par défaut. Une ligne positive doit fournir compte et contact cohérents avec le profil. Une quantité de résultats inattendue ou une contradiction d’identité retient la cohorte locale, sans affirmer ce que Salesforce a réellement exécuté.
Distinguer la lecture d’un Lead converti d’une nouvelle conversion
Un Lead converti peut encore être interrogé, selon la référence native de l’objet Lead. Les champs de conversion servent à retrouver ses cibles lorsque la réponse initiale manque. Une absence dans une recherche de l’interface ne démontre pas une suppression. Vérifier le compte technique, les accès et le chemin de lecture avant d’envoyer une nouvelle mutation pour tenter de retrouver une identité.
Modifier le libellé Status ne remplace pas l’appel de conversion. Il faut aussi qualifier les valeurs converties de LeadStatus dans l’organisation, plutôt que recopier aveuglément un libellé d’exemple. Le programme ne réalise aucune de ces lectures natives : il commence après l’acquisition des éléments utiles. La conservation d’une réponse fiable évite précisément d’utiliser une nouvelle écriture comme outil de diagnostic.
Rapprocher les Leads par compte avant de proposer leurs liens ERP
Garder les références de prospection sans les transformer en clients
Dans la recette, PROSPECT-01 et PROSPECT-02 désignent deux dossiers locaux envoyés pour conversion. Ce ne sont pas deux clients ERP. Les Leads et contacts fictifs restent distincts, tandis que leurs résultats désignent account-A. L’inventaire local connaît déjà son client CLI-100. Le rapport peut proposer deux rattachements vers cette même cible, sans demander deux créations pour maintenir artificiellement le nombre de fiches.
Le drapeau actif du client appartient à cet inventaire de laboratoire. Il ne prouve ni l’autorisation de facturer, ni l’ouverture du crédit, ni la validation des données légales. Une proposition de correspondance résout une identité dans un périmètre donné. Les contrôles commerciaux et financiers restent nécessaires avant de libérer les traitements qui consommeront cette référence.
Retenir tout le groupe lorsqu’un ancien lien contredit la cible
Ajoutons maintenant un lien antérieur du second Lead vers CLI-200. Le premier dossier semblait pouvoir rejoindre CLI-100, mais traiter les lignes une à une publierait une décision avant de découvrir le conflit partagé. Notre politique locale regroupe d’abord les réussites par Account, puis retient les deux propositions. Elle ne choisit pas quel client financier doit disparaître.
Un autre Account, relié séparément à un client qualifié, peut conserver sa proposition. Cette indépendance porte sur le rapport local, pas sur l’atomicité d’une conversion SOAP. Des comptes CRM distincts peuvent aussi partager une cible ERP si le mapping fourni le prévoit explicitement. Le programme n’ajoute aucune contrainte inverse qui forcerait un client ERP différent pour chaque compte Salesforce.
Exercice corrigé : deux propositions vers un seul client existant
Exécuter une analyse en lecture seule sur des valeurs inventées
Le programme Python complet utilise uniquement la bibliothèque standard. Il fabrique des valeurs déjà décodées qui ressemblent aux champs utiles d’un résultat SOAP ; il ne lit aucun XML et n’appelle aucun SDK. Les libellés lead-A et account-A ne sont pas des identifiants Salesforce valides. L’exercice ne certifie donc pas le décodage ni l’identité d’une réponse réelle. Il ne contrôle pas non plus l’appartenance réelle du contact au compte ; ce point exige une qualification auprès du CRM.
python3 lead_customer_inventory.pyLa sortie contient les décisions par Lead et les noms des 52 contrôles exécutés. Dans le nominal, elle expose deux fois CLI-100 comme cible proposée, avec deux références de prospection conservées. Dans le scénario contradictoire, les deux lignes passent en attente sans cible proposée. Le fichier n’effectue aucune écriture de stockage, aucune création de client et aucune fusion de données.
Comparer les décisions avant d’ouvrir une phase d’écriture
| Scénario local | Propositions vers des clients existants |
|---|---|
| Deux Leads vers account-A qualifié | Deux liens proposés vers CLI-100 |
| Ancien lien du second Lead vers CLI-200 | Aucune proposition pour account-A |
| Conflit sur A, compte B indépendant qualifié | Une proposition reste possible pour B |
| Aucun mapping client pour le compte cible | Aucune création déduite du succès CRM |
| Résultats inversés sans inverser la demande | Toute la cohorte reste à examiner |
Les contrôles couvrent aussi le client inactif ou inconnu, les correspondances dupliquées, les identités contradictoires et l’opportunité facultative. Un échec natif qualifié reste visible pour son Lead, tandis qu’une réussite indépendante peut produire sa proposition. Les entrées sont comparées à leur copie initiale après les scénarios, et une nouvelle analyse identique retrouve le même rapport sans effet supplémentaire. Cette stabilité ne démontre aucune idempotence des écritures qu’un système distant pourrait effectuer ensuite.
Le résultat constitue une pièce de rapprochement, pas une instruction directement exécutable dans l’ERP. Avant toute application, il reste à vérifier la fraîcheur des inventaires, les modifications concurrentes et les droits de la personne qui valide. Une décision calculée sur une photographie ancienne ne devient pas valable indéfiniment parce que son format est stable ou que les tests locaux sont réussis.
Séparer une conversion inconnue d’un conflit entre clients connus
Ne pas présenter une preuve incomplète comme un échec confirmé
Le transport déclaré incomplet, une réponse absente ou une ligne hors du profil empêchent de qualifier la cohorte. Le rapport local retient alors les dossiers avec une raison d’incertitude. Il ne conclut pas que les comptes n’existent pas et ne déclenche aucune reprise. L’équipe doit rechercher les effets réels avant de choisir entre relire, corriger une correspondance ou préparer une nouvelle demande.
Une liste d’erreurs explicite et correctement corrélée produit au contraire un état d’échec pour le Lead concerné. Les règles de retry restent à définir selon sa cause ; le laboratoire ne transforme pas tout refus en incident transitoire. Cette séparation évite de mélanger une conversion refusée, une réponse perdue et une réussite qui rejoint un ancien client différent de celui attendu.
Qualifier le périmètre avant d’interpréter les identifiants
Les libellés d’organisation séparent les inventaires locaux, sans authentifier aucun environnement. Une correspondance d’un autre périmètre ne remplace pas la cible recherchée. Le lecteur conserve également la casse des références métier. Il ne valide pas les formats natifs de quinze ou dix-huit caractères et ne calcule pas leur équivalence ; cette qualification appartient au client Salesforce et au contrat d’identité utilisé en amont.
Un champ explicite de compte personne associé sort du profil retenu. Son absence ne suffit cependant pas à prouver que l’Account réel est un compte entreprise. Il faut vérifier ce type avant d’utiliser la politique proposée. De même, un compte regroupant plusieurs sociétés ERP nécessite un modèle de correspondance plus précis ; ajouter une exception silencieuse au premier client trouvé ferait seulement disparaître l’alerte.
Erreurs fréquentes qui recréent un client après une conversion réussie
Compter les Leads convertis comme des nouveaux clients. Le premier signal faible est une croissance des fiches ERP alignée sur les conversions, alors que plusieurs résultats ciblent le même Account déjà relié. Comparer les comptes distincts, les cibles retrouvées et les créations réellement autorisées. Une hausse des succès techniques ne démontre pas une hausse du nombre de clients à ouvrir dans la gestion.
Utiliser le contact ou le nom comme identité du client. Le second signal faible est une référence ERP qui change lorsque le contact commercial change, sans modification du compte concerné. Le nom reste utile pour rechercher une anomalie, mais il ne remplace pas une clé qualifiée. Le contrat doit séparer personne, société représentée, dossier de prospection et compte de facturation.
Accepter la première ligne avant d’examiner les autres Leads du compte. Un conflit découvert ensuite peut impliquer une fiche déjà utilisée par les ventes ou la finance. Regrouper les dossiers avant de proposer leur libération, puis conserver les identités contradictoires pour arbitrage. Supprimer un ancien lien pour faire passer la recette ne répare ni les factures ni les échanges qui l’ont déjà consommé.
Rejouer la conversion pour obtenir une réponse plus lisible. La priorité consiste à retrouver l’exécution initiale et les enregistrements autorisés à la lecture. Le diagnostic Salesforce sur les identifiants reçus avant une annulation Composite traite une autre ambiguïté de résultat. Il ne remplace pas ce rapprochement de Leads vers un compte, et ses paramètres transactionnels ne doivent pas être transposés à SOAP.
Plan d’action : corriger le rattachement avant de libérer les dossiers
Faire instruire la même exécution par le CRM et la gestion
L’administrateur Salesforce identifie le chemin de conversion, les règles de validation et les automatismes concernés. L’intégrateur retrouve le plan et les transformations du SDK vers le mapping. Son contrat d’entrée et sa journalisation doivent conserver l’ordre des Leads et les références transmises. Le référent ERP vérifie les clients existants, leur périmètre et les documents déjà associés. La responsabilité d’une éventuelle fusion financière doit être nommée séparément de celle qui corrige le connecteur.
Prioriser un groupe de dossiers dont les références sont retrouvables. Conserver les dépendances nécessaires à leur traitement, puis différer les mutations que leur seule identité ne suffit pas à autoriser. Le seuil de reprise doit être explicite : chaque dossier de la cohorte retenue possède une cible expliquée, ou une exception visible avec un responsable. Aucun objectif de débit ne justifie d’effacer les conflits restants.
- Retrouver la demande de conversion et distinguer Lead, Account, Contact et éventuelle Opportunity dans les résultats conservés.
- Rapprocher les comptes cibles des clients ERP dans la bonne organisation et le bon périmètre de gestion.
- Regrouper les Leads d’un même compte et vérifier les anciennes correspondances avant de proposer des liens supplémentaires.
- Rejouer en recette le compte partagé, le conflit tardif, le résultat incomplet et le compte indépendant déjà qualifié.
- Faire arbitrer les clients contradictoires avec la gestion, sans lancer de création ou de fusion pour masquer l’écart.
- Définir la validation des propositions, les contrôles de fraîcheur et la procédure de retour arrière avant toute application réelle.
Préparer le retour arrière sans perdre l’origine des dossiers
Le runbook indique comment suspendre la sortie des propositions, retenir la queue concernée et retrouver la version du mapping utilisée. Un rollback de configuration peut restaurer le contrat précédent entre producteur, SDK et consommateur. Il ne défait aucune fusion ni écriture ERP déjà réalisée. La correction doit donc préserver les références d’origine et les preuves de chaque décision appliquée.
La recette mesure les dossiers rapprochés, ceux qui restent en attente et le délai de traitement des exceptions. Le budget utile dépend du nombre de conflits réellement à instruire, des documents touchés et des équipes nécessaires. Notre analyse sans écriture ne démontre aucune économie chiffrée. L’élargissement attend une procédure praticable pour reprendre les cas refusés, plutôt qu’un simple compteur de réponses positives.
Projets liés : conserver les identités entre un portail client et l’ERP
Corim Solutions : retrouver les objets connus dans Colline
Pour Corim Solutions, Dawap a relié un portail client à l’ERP Colline avec des correspondances de comptes, licences et contacts. Les objets synchronisés conservent leur identifiant externe pour être retrouvés lorsque leurs informations descriptives changent. Le projet Corim de synchronisation avec Colline présente ce raccordement et le suivi des exécutions, jusqu’à la ressource qui demande une intervention.
Cette réalisation concerne un portail et Colline ; elle ne constitue pas un exemple de conversion Salesforce. Son intérêt ici porte sur la continuité des identités et la lisibilité des reprises. Retrouver l’objet déjà connu, séparer les contacts de leurs comptes et garder la trace d’une synchronisation sont des décisions concrètes à cadrer lorsque plusieurs applications utilisent le même référentiel client.
Conserver la preuve de conversion jusqu’aux échanges métier suivants
Préserver les différences entre réponse SOAP et événement de changement
Une réponse LeadConvertResult et un événement CDC ne fournissent pas le même contrat de lecture. La référence des changements émis lors d’une conversion décrit les champs concernés et précise que ConvertedDate ne contient pas l’heure. Ce champ seul ne permet donc pas d’ordonner toutes les opérations d’une journée ni de reconstruire une version précise du rapprochement.
Si le connecteur suit ensuite les modifications par CDC, l’analyse Salesforce sous charge avec Bulk, CDC et Pub/Sub replace ces événements dans leur propre contrat d’exploitation. Une observation de changement doit rester reliée à son périmètre et à sa source. Notre lecteur de résultats SOAP ne remplace ni son décodage ni le mécanisme de reprise du consommateur.
Garder une architecture lisible lorsque plusieurs équipes écrivent
Un même client peut être enrichi par le commercial, le site et l’ERP après sa conversion. Il faut alors expliquer qui peut changer son identité, son responsable ou ses attributs. La présentation du SDK Salesforce dans une architecture Symfony aborde ce cadre général. Le rapprochement étudié ici en précise une décision : conserver les lignées de prospection lorsque plusieurs Leads convergent.
La journalisation et l’observabilité doivent montrer la référence d’entrée, le compte retourné, la cible proposée et la raison de retenue éventuelle. Les anciennes associations restent consultables pour comprendre une correction ultérieure. Cette trace ne doit pas servir à contourner une validation métier : retrouver une identité et décider de fusionner deux clients sont deux opérations dont les conséquences et les autorisations diffèrent.
Conclusion : conserver la lignée des Leads sans multiplier les clients
Paradoxalement, plusieurs conversions réussies peuvent confirmer un seul client déjà connu. Le lien utile est celui qui explique cette convergence tout en conservant les dossiers d’origine. Le nombre de contacts ou d’opportunités n’impose pas le nombre de fiches ERP. Le plan conservé et les résultats corrélés permettent de retrouver les rôles de chaque identité avant de décider quoi transmettre.
Les 52 contrôles du laboratoire produisent deux propositions vers un client existant, retiennent un groupe contradictoire et préservent l’indépendance d’un autre compte qualifié. Ils exercent une politique de lecture sur des données inventées. Ils ne créent aucun client, ne certifient pas les informations d’une organisation réelle et n’autorisent aucune fusion de documents financiers.
Si vos dossiers passent de Salesforce à la gestion sans cible stable, notre expertise des connecteurs Salesforce et des correspondances ERP aide à qualifier les identités et les exceptions avec vos équipes. La reprise doit rendre chaque rattachement explicable avant de libérer les commandes ou les demandes qui en dépendent.
Pour revoir ce passage entre prospection et gestion, Dawap propose un accompagnement en intégration API de vos logiciels métier. Le travail peut couvrir le contrat de conversion, les inventaires de correspondances, une recette des comptes partagés et une procédure de correction que les équipes CRM et ERP pourront réellement appliquer.
