Rapprochement, fusion et survivance

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 3 sur 6 du chapitre Données maîtres et identité, chapitre 6 du cours Data Architect. Chaque module est autonome. Précédent : Les quatre façons de maîtriser les données · Suivant : Une carte n’est pas une décision

La question à laquelle répond ce module : comment trouver les doublons, et décider quelles valeurs survivent ?

Salesforce a deux contacts : Daniel Reyes, Dallas, d.reyes@example.com, et Dan Reyes, Dallas, d.reyes@example.com. La même personne ? Probablement. Devons-nous les fusionner ? C’est une autre question. Et si nous le faisons, quel numéro de téléphone, quelle adresse et quel titre survivent ? Encore une autre. Les architectes doivent garder trois décisions séparées :

• Le rapprochement : ces enregistrements représentent-ils la même chose ?
• La fusion : doivent-ils devenir un seul enregistrement ?
• La survivance : si nous combinons les données, quelles valeurs l’emportent ?

Le rapprochement vient en premier

Le chapitre 3 a couvert les règles de doublons et de correspondance de Salesforce, je ne vais donc pas réenseigner la mécanique. La question d’architecture est : quelle preuve est assez forte pour dire qu’ils sont peut-être identiques ? Pour une personne : e-mail, téléphone, nom plus adresse, un numéro client, une combinaison. Pour une entreprise : raison sociale, identifiant fiscal, ID client ERP, adresse, domaine web. Pas « Salesforce peut-il comparer ces champs ? » mais « quelle combinaison nous donne assez de confiance pour agir ? »

Et exact ne veut pas dire certain. Un e-mail partagé est un signal fort, pas une preuve : les familles partagent des adresses, les entreprises utilisent purchasing@company.com, les numéros de téléphone appartiennent à des foyers, les noms et les adresses ne sont pas uniques, et même les identifiants forts sont réutilisés, mal saisis ou recyclés. Le rapprochement n’est pas une comparaison de chaînes. C’est une affirmation sur l’identité.

Le coût de l’erreur

Quand j’enseigne cela, je change de domaine. Dans des données marketing automobiles, nous décidons à tort que deux Daniel Reyes sont la même personne, et le mauvais reçoit une offre pour un SUV. Pas terrible, mais peu risqué. Faites maintenant le même faux rapprochement dans des données médicales : les antécédents médicaux de deux personnes différentes combinés. Même erreur de rapprochement, conséquence complètement différente. C’est pourquoi il n’existe pas de seuil de rapprochement « bon » universel. Parfois, le plus grand risque est de rater un rapprochement ; parfois, c’est de combiner deux personnes qui ne sont pas les mêmes. Là où les faux rapprochements coûtent cher, je sous-rapproche délibérément.

Harmoniser, puis rapprocher, puis consolider

Le rapprochement dépend aussi de la forme des données. AZ, Arizona, Ariz. ; 6025550198, (602) 555-0198, +1 602 555 0198. L’harmonisation rend les valeurs comparables : formats standard, abréviations normalisées, codes mis en correspondance. Ensuite, vous rapprochez. Ce n’est qu’une fois qu’on sait que des enregistrements vont ensemble que vous consolidez leurs informations en une seule représentation. Harmoniser n’est pas rapprocher, rapprocher n’est pas fusionner, et consolider n’est pas forcément maîtriser.

Click to enlarge

Les décisions d’identité se prennent par étapes.

Un rapprochement n’exige pas une fusion

C’est l’une des distinctions les plus importantes du chapitre. Nous sommes sûrs que deux fiches client issues de deux anciens systèmes sont la même entreprise. Devons-nous les fusionner ? Non. Chacune peut porter une identité de système source ; des transactions historiques peuvent pointer vers chacune ; les auditeurs peuvent avoir besoin de la trace ; nous sommes peut-être encore en migration ; nous pouvons avoir besoin de savoir exactement ce que disait l’ancien système. Savoir que deux enregistrements sont la même chose ne nous oblige pas à les fondre en un seul. Nous pouvons les relier, et c’est souvent l’architecture la plus sûre.

Ma règle de fusion : un gagnant clair

Ma position : ne fusionnez que lorsqu’il y a un gagnant clair et que le doublon n’apporte rien que vous ayez besoin de garder. Un commercial a créé hier un compte en double ; l’original est clairement l’enregistrement établi. Bon candidat à la fusion. Changez maintenant la situation : nous avons importé des clients depuis un système hérité, avec leurs propres ID, des valeurs plus anciennes, peut-être des transactions ou des exigences d’audit qui y sont liées. Je suis beaucoup plus prudent. Gardez les doublons issus de chargements externes quand vous risquez d’avoir besoin de remonter aux anciennes valeurs, parce que la fusion détruit cet historique.

Ce que fait réellement une fusion Salesforce

Un lien dit « ceux-là vont ensemble ». Une fusion dit « ceux-là ne font plus qu’un », et sur Salesforce, c’est un vrai changement. Pour les comptes, vous sélectionnez jusqu’à trois enregistrements et en choisissez un comme principal ; vous choisissez lesquelles des valeurs de champs des autres garder, tandis que les champs masqués et en lecture seule viennent du principal. L’enregistrement fusionné garde le Créé par et la Date de création de l’enregistrement le plus ancien, quel que soit le principal. Les enregistrements non principaux vont à la Corbeille. Les enregistrements associés comme les activités passent à l’enregistrement fusionné, avec des exceptions. Dans Lightning, la fusion porte sur les doublons que détectent vos règles de doublons. Et pour les comptes personnels, les objets de point de contact ne prennent pas en charge la fusion : leurs relations sont perdues (Considerations for Merging Duplicate Accounts (opens in a new tab) ; Merge Duplicate Accounts in Lightning Experience (opens in a new tab), en anglais).

À savoir pour l’examen. Sachez ce que fait une fusion de comptes Salesforce : jusqu’à trois enregistrements ; un principal, dont les champs masqués et en lecture seule sont conservés ; le Créé par et la Date de création de l’enregistrement le plus ancien, quel que soit le principal ; les autres enregistrements vont à la Corbeille ; et pour les comptes personnels, les objets de point de contact ne sont pas fusionnés.

Vous n’avez pas besoin de connaître chaque cas limite pour prendre la décision. Vous avez besoin de la conséquence : après une fusion, les enregistrements indépendants du départ ont disparu. Le test de réversibilité du chapitre 1 s’applique : un lien est facile à défaire ; une fusion, non. Et un client est rarement seul : contacts, requêtes, opportunités, fichiers, enregistrements de consentement, enfants personnalisés, ID externes, références d’intégration. Avant de fusionner le parent, comprenez ce qui arrive à tout ce qui y est rattaché. Quand des doublons arrivent avec un chargement, je donne aux équipes trois choix pour les enfants : les déplacer vers l’enregistrement qui survit ; ne pas les charger du tout, si personne n’en a besoin ; ou les garder sur l’autre enregistrement, marqué inactif, pour qu’ils apparaissent toujours dans la recherche. Le premier, c’est ce qu’une fusion fait pour vous. Les deux autres gardent la trace, et c’est souvent tout l’intérêt.

La survivance : quelle valeur l’emporte ?

Des enregistrements vont ensemble, mais ils ne sont pas d’accord : Salesforce et la facturation disent 602-555-0100, l’ERP dit 602-555-0188. Les règles de survivance (survivorship) désignent le gagnant. Les plus courantes : la plus récente (la dernière mise à jour), la plus fréquente (la valeur sur laquelle s’accordent le plus de sources), et la priorité des sources (faire davantage confiance à telle source qu’à telle autre), plus des combinaisons, des seuils, des pondérations et des règles propres au métier. Aucune n’est juste par nature.

« La plus récente » n’est pas un réglage technique. C’est une déclaration de confiance : quand les systèmes ne sont pas d’accord, la valeur la plus récente a plus de chances d’être juste. Raisonnable pour un numéro de mobile. Terrible pour une raison sociale : si l’ERP la possède, peu m’importe que quelqu’un ait modifié la copie Salesforce il y a cinq minutes. « La plus fréquente » suppose que l’accord est une preuve, mais trois copies périmées en aval ne mettent pas en minorité le système d’enregistrement. « La priorité des sources » le dit franchement : nous faisons davantage confiance à cette source. La survivance relève donc de l’architecture et de la gouvernance, et chaque règle a besoin d’un propriétaire. Qui a décidé que l’adresse la plus récente l’emporte, ou que l’ERP passe avant Salesforce ?

Si la carte des autorités du module 1 dit déjà que l’ERP possède la limite de crédit, la survivance est facile : l’ERP l’emporte, pas besoin de calcul astucieux. Les cas difficiles sont les attributs dont l’autorité est partagée, floue ou fondée sur des indices plutôt que sur un maître unique. C’est là que les règles de survivance justifient leur existence.

Click to enlarge

Les règles de survivance sont des déclarations de confiance.

Seuils, revue et enrichissement

Certains rapprochements pèsent les indices : une correspondance d’ID client est très forte, un e-mail fort, un téléphone moyen, un nom similaire faible, une adresse similaire un appui. Au-dessus d’un score, c’est un rapprochement ; en dessous d’un autre, c’est différent ; entre les deux, une personne examine. L’algorithme n’est pas la leçon. Le seuil est votre tolérance à l’erreur, et il doit suivre le risque métier. Et quand les indices soulèvent la question sans la trancher, ne prétendez pas que le système sait. Envoyez en revue. C’est plus lent, et c’est très bien : l’automatisation n’a pas de valeur quand elle fusionne avec assurance deux clients différents.

L’enrichissement ajoute une autre question de provenance. Les données de référence postales, les codes sectoriels, les données d’entreprise (firmographics), les scores de risque externes améliorent les données maîtres, mais d’où vient chaque valeur, à quel point est-elle fiable et à jour, avons-nous le droit de l’utiliser pour cette finalité, contient-elle des données personnelles ? « Secteur = Transport » venant d’un fournisseur de données n’est pas la même chose que le client qui vous le dit. Gardez cette distinction.

Steve Trucking : semblable n’est pas identique

Deux partenaires distributeurs envoient des livraisons à John Smith, 123 Main Street, Columbus, avec le même numéro de téléphone. La même personne ? Probablement. Steve Trucking doit-il les unifier ? Souvenez-vous à qui ils appartiennent : ces destinataires sont les clients des partenaires, et un partenaire ne doit jamais voir ceux d’un autre. Un faux rapprochement mélangerait des données par-delà cette frontière. Soudain, ce n’est plus une question de qualité des données mais une question de protection des données et d’isolement, et c’est exactement pourquoi les seuils dépendent des conséquences. Le point de contrôle tranche. Pour l’instant : ne laissez pas la commodité du rapprochement prendre la décision métier.

Parfois, garder le désordre vous apprend quelque chose. Cet enregistrement vient de l’ancien système, celui-là de Salesforce, celui-ci de l’entreprise rachetée ; leurs ID, leur historique et le fait qu’ils n’étaient pas d’accord peuvent tous compter. Des données propres ont de la valeur. La traçabilité aussi. L’architecte décide ce qui compte le plus pour l’usage.

Au-delà de l’examen : ce que l’IA change. Un mauvais rapprochement voulait dire deux e-mails ou un historique de service éclaté. Maintenant, un agent trouve ce qu’il croit être le client et récupère ses commandes, ses requêtes, ses adresses et ses notes. Si deux personnes ont été rapprochées à tort, il peut agir sur les informations d’une personne pour le compte d’une autre. La décision de rapprochement fait désormais partie de la frontière de sécurité, et là où mélanger coûte cher, un rapprochement plus strict est la conception la plus sûre.

Ce qu’un architecte décide ici

• Quels indices suffisent pour signaler un doublon possible dans chaque domaine de données.
• Si un rapprochement confirmé devient une fusion, un lien ou une revue humaine.
• Quelles valeurs survivent au désaccord, et qui possède chaque règle de survivance.
• Quel risque de faux rapprochement le métier peut tolérer, face au risque de rapprochement manqué.
• Quelles identités sources, quel historique et quels enregistrements associés doivent être préservés avant toute fusion.

Rapprochez avec soin, fusionnez délibérément, choisissez les règles de survivance intentionnellement. Une fiche client propre ne vaut pas grand-chose si vous y êtes arrivé en combinant les mauvais clients.

Pour aller plus loin

• Aide Salesforce, Considerations for Merging Duplicate Accounts (opens in a new tab) et Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (en anglais), consulté le 2026-10-14.