Qu'est-ce qui est considéré comme un doublon et qu'est-ce qui ne l'est pas ?

Il s'agit d'une décision commerciale, pas technique. Deux succursales d'une même entreprise peuvent être deux enregistrements légitimes pour les ventes et un seul pour la facturation. Avant d'exécuter un outil de dédoublonnage, il est crucial de définir, au niveau de l'entité, si l'unité commerciale est une entreprise, un site ou un contrat.

Faut-il nettoyer avant ou après le chargement des données ?

Il est impératif de nettoyer avant. Un enregistrement dupliqué déjà chargé crée des relations (activités, requêtes, opportunités), rendant toute fusion ultérieure risquée et susceptible d'entraîner une perte d'historique. Après le chargement, seule une application continue des règles demeure, et non un nettoyage de masse.

Que faire lorsque deux enregistrements contiennent des informations différentes, et les deux sont valides ?

Il faut construire un "Golden Record" au niveau du champ, et non de l'enregistrement. Pour chaque champ, une règle de priorité est définie : système source préféré, valeur la plus récente, ou valeur validée. Cela garantit de ne pas perdre une adresse correcte simplement parce que le deuxième enregistrement a été désigné comme le vainqueur.

Les règles de correspondance (Matching Rules) de Salesforce sont-elles suffisantes ?

Elles sont suffisantes pour la prévention continue lors de la saisie manuelle, mais pas pour un nettoyage de masse avant une migration. Pour le nettoyage initial, un outil ou un script effectuant un "Fuzzy Matching" sur la normalisation de texte est nécessaire, permettant une revue humaine des zones grises avant la fusion.

Quel pourcentage de doublons est considéré comme 'normal' ?

Dans les bases de données existantes et non gérées, on observe généralement 8% à 20% de doublons au niveau des contacts et 3% à 10% au niveau des comptes. L'objectif pratique n'est pas zéro, mais un seuil convenu (par exemple, moins de 2%) avec un processus qui empêche une nouvelle dégradation.

Dédoublonnage avant Salesforce : Stratégie de

La réponse courte

La déduplication échoue lorsqu'elle est considérée comme une opération de nettoyage ponctuelle. En réalité, elle implique trois décisions fondamentales : définir ce qui constitue une identité, déterminer qui l'emporte en cas de conflit, et établir des mesures pour empêcher la réapparition du problème. L'outil technique n'est que la partie la plus simple.

L'erreur courante consiste à exécuter une correspondance floue (Fuzzy Matching) sur les noms, à obtenir une liste de 12 000 correspondances possibles et à tenter de les résoudre manuellement sous la pression des délais. L'approche efficace est l'inverse : réduire d'abord l'espace de décision à l'aide d'identifiants robustes, et ne laisser à la révision humaine que la zone grise.

La planification générale de la migration est décrite dans Migration de données vers Salesforce.

Trois niveaux de correspondance

Couche	Base de correspondance	Action
Clé forte	Numéro de TVA, identifiant de système source, email vérifié	Fusion automatique
Clé complexe	Nom normalisé + ville + téléphone normalisé	Fusion automatique avec score élevé
Similitude textuelle	Nom uniquement, adresse libre	Révision humaine uniquement

Pour un projet bien géré, le rapport est le suivant : environ 70% des doublons sont résolus à la première couche, environ 20% à la deuxième, et 10% seulement nécessitent une intervention humaine. Si la majorité des correspondances atteignent la troisième couche, cela indique un manque de normalisation, et non nécessairement des données particulièrement mauvaises.

Normalisation avant comparaison

Avant toute comparaison, des colonnes d'aide normalisées sont créées sans modifier les données d'origine : suppression des suffixes d'entreprise (SARL, Ltd), uniformisation des espaces et des apostrophes, formatage des numéros de téléphone au format E.164, mise en minuscules des emails avec suppression des étiquettes après le signe plus, et adresse segmentée en rue/numéro/ville. Dans certaines langues, un traitement est ajouté pour l'orthographe complète ou abrégée et les acronymes.

La normalisation seule permet généralement de réduire d'un tiers à la moitié les doublons "difficiles" avant même l'application d'un algorithme de similitude.

Golden Record au niveau du champ

La décision "quelle enregistrement survit" n'est pas la plus importante. La plus importante est "quelle valeur survit dans chaque champ". Il faut établir une politique concise : informations de facturation provenant de l'ERP, coordonnées du système où la dernière activité a été enregistrée, statut client du système opérationnel. Chaque champ a une source préférée unique, et une trace est conservée pour chaque valeur rejetée.

Sans une telle politique, chaque fusion est une décision prise par l'opérateur à ce moment-là, et il sera impossible d'expliquer par la suite pourquoi une adresse a disparu.

Que se passe-t-il avec les relations et l'historique ?

La fusion d'enregistrements affecte les activités, les opportunités, les Cases, les fichiers et les autorisations. Avant une exécution de masse, il est impératif de définir explicitement : où vont les activités, ce qu'il advient des opportunités ouvertes pour le même client provenant de deux enregistrements, et qui devient le propriétaire après la fusion, car un changement de propriétaire modifie à la fois la visibilité et les rapports de commissions.

La règle pratique : pas de fusion avant qu'un rapport "qu'est-ce qui a changé" ne soit reproductible, et que les identifiants source soient conservés dans un champ distinct pour permettre une investigation des mois plus tard.

Scénario : un importateur avec 210 000 contacts

Un importateur B2B entame sa migration avec 210 000 Contacts provenant de trois systèmes. La première exécution d'un outil de similitude a renvoyé 31 000 paires suspectes, un nombre ingérable pour une révision humaine.

L'équipe a fait une pause et a inversé l'ordre. D'abord, les emails et téléphones ont été normalisés : 14 000 paires ont été automatiquement résolues via une clé forte. Ensuite, il a été décidé que l'unité commerciale était le site client et non l'entreprise, ce qui a retiré de la liste 6 000 paires légitimes – des succursales distinctes du même réseau. Il restait 4 200 paires pour la couche intermédiaire, dont 3 800 ont été résolues avec un score élevé. Seulement 400 paires ont nécessité une révision humaine, et deux personnes les ont traitées en trois jours.

La leçon n'était pas le choix de l'outil. Elle était que la définition de l'unité commerciale – site versus entreprise – a réduit plus de bruit que toute amélioration algorithmique.

Prévention : pourquoi les doublons réapparaissent-ils ?

Trois sources principales réintroduisent des doublons après le déploiement (Go Live) : la saisie manuelle sans Matching Rules actifs, les intégrations qui créent un enregistrement au lieu de le mettre à jour (Upsert sur un External ID résout la plupart d'entre elles), et les formulaires Web-to-Lead sans vérification d'existence. Si ces trois points ne sont pas résolus, le taux de doublons reviendra à son niveau initial en un à deux ans.

Risques courants et actions préventives

Risque	Comment il se manifeste	Action préventive
Fusion agressive	Des clients distincts sont fusionnés et ne peuvent être séparés	Seuil de score élevé + révision de la "zone grise"
Aucune définition d'identité	Débat récurrent sur ce qui constitue le même client	Décision documentée au niveau de l'entité
Perte d'historique	Activités et opportunités disparues lors de la fusion	Rapport "Ce qui a changé" et conservation des identifiants source
Nettoyage sans prévention	Les doublons réapparaissent en quelques mois	`Matching Rules`, `Upsert` et formulaires sécurisés
Nettoyage après chargement	Chaque fusion impacte des relations vivantes	Nettoyer à l'étape de `Staging`

Comment mesurer le succès

Domaine	Ce qu'il faut mesurer	Fréquence de vérification
Unicité	Taux de doublons estimé par entité	Hebdomadaire pendant la migration, trimestriel par la suite
Précision de la fusion	Pourcentage de fusions annulées ou corrigées manuellement	À chaque vague de fusion
Prévention	Nouveaux enregistrements bloqués comme doublons lors de la saisie	Mensuel
Impact commercial	Requêtes doubles aux clients, précision des rapports clients	Trimestriel

Un accompagnement professionnel pour l'établissement des règles d'identité et de prévention est disponible dans le cadre des services d'intégration et de données.

Liste de vérification avant d'exécuter une fusion

Ressources professionnelles

Salesforce Data 360 — https://www.salesforce.com/data/
Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
HPI Pro – Intégrations et Données — https://hpi.pro/integrations-data

Dédoublonnage de données avant implémentation Salesforce : Une stratégie pratique