Le CRM contient « Société Martin », l’ERP « MARTIN SAS » et l’application support « Martin France ». Les trois fiches partagent une adresse, mais portent des contacts, contrats et statuts différents. Une synchronisation plus rapide ne résout rien : elle propage les divergences et peut remplacer une information correcte par la dernière valeur reçue.
Le symptôme devient métier lorsque deux équipes promettent des conditions différentes au même client, qu’un contrôle de crédit ignore une facture ou qu’un support ne retrouve qu’une partie de l’historique. La duplication ne casse pas seulement les flux ; elle divise l’identité, les droits et les décisions. Chaque correction locale risque de créer une quatrième version.
Le vrai enjeu est de distinguer les copies nécessaires d’un même objet des doublons qui prétendent chacun être cet objet. Il faut définir l’identité, attribuer l’autorité, rapprocher les références et rendre toute fusion réversible. La base peut empêcher certains doublons exacts, mais elle ne devine pas seule que deux raisons sociales proches désignent la même organisation.
Dans une démarche de développement web sur mesure, la qualité vient d’un contrat partagé entre métier, données et intégrations. Ce guide construit ce contrat, du diagnostic au run.
Distinguer copie technique et doublon métier
Une copie technique sert un usage : cache de lecture, index de recherche, projection analytique ou réplica. Elle conserve un identifiant canonique, sa source, sa version et une règle de rafraîchissement. Elle n’est pas autorisée à devenir une nouvelle identité parce qu’un utilisateur a corrigé son libellé localement.
Un doublon métier existe lorsque deux enregistrements revendiquent la même identité ou la même décision. Deux établissements d’un groupe ne sont pas forcément des doublons ; deux fiches créées pour le même établissement peuvent l’être. La granularité doit être écrite : personne, organisation, site, contrat, produit, variante ou équipement.
Les signaux faibles sont les recherches par plusieurs clés, les exports recollés dans un tableur, les références « ancienne » et « nouvelle », les adresses copiées et les corrections annulées par un flux. Mesurez les interventions et les objets orphelins avant de choisir un outil de matching.
- Une projection porte toujours l’identifiant canonique, la version source et sa fraîcheur.
- Un candidat rapproche deux identités sans modifier encore leurs relations.
- Un doublon confirmé reçoit une décision de fusion ou de maintien séparé.
- Une différence légitime reste modélisée comme organisation, établissement, variante ou contrat distinct.
Définir l’identité de l’objet
Séparer identifiant, attribut et preuve
L’identifiant interne reste opaque et stable. Les clés externes — numéro ERP, SIREN, GTIN, code fournisseur — sont rattachées avec leur système, périmètre et période. Le nom, l’adresse ou l’e-mail sont des attributs susceptibles de changer ; ils aident au rapprochement sans constituer toujours une clé.
Écrivez la règle d’identité avec des cas contradictoires. Deux sociétés partageant un standard téléphonique restent distinctes. Une société qui change de nom garde son identité. Un contrat renouvelé peut devenir un nouvel objet relié au précédent. Ces décisions sont métier, pas seulement techniques.
Poser les contraintes certaines
La base impose les unicités prouvées dans le bon périmètre. La documentation PostgreSQL sur les contraintes d’unicité rappelle qu’une combinaison de colonnes peut être unique et que les valeurs nulles ont un comportement spécifique, notamment avec NULLS NOT DISTINCT. Une contrainte mal définie peut donc laisser passer plusieurs absences ou bloquer deux clés légitimes.
Une contrainte empêche le retour du doublon exact sous concurrence ; elle ne remplace pas la normalisation ni la revue des proximités. Ajoutez-la après avoir qualifié l’historique et traité les conflits, sinon la migration échoue sans expliquer le métier.
Attribuer une autorité par attribut
« Le CRM est maître du client » est trop vague. Il peut posséder contacts et consentements, tandis que l’ERP possède compte comptable et conditions de paiement. Le référentiel commun porte l’identité et les relations. Chaque attribut a une entrée autorisée, une fréquence, une validation et un comportement lorsque la source manque.
Une correction dans un consommateur devient une demande vers l’autorité ou un override borné. L’override conserve motif, auteur, expiration et valeur source. Sans ce cycle, la prochaine synchronisation écrase la correction ou transforme le consommateur en maître implicite.
Contre-intuitivement, une « golden record » ne doit pas forcément contenir la valeur la plus récente. La date ne prouve ni la qualité ni l’autorité. Une adresse validée par un contrat peut primer sur une saisie CRM plus récente ; le dossier conserve la règle et la provenance qui ont produit le choix.
Synchroniser les copies sans créer de maîtres
Le message transporte identifiant canonique, clé source, version, date effective et champs autorisés. Le consommateur applique seulement les attributs de cette source. Une mise à jour partielle ne remplace pas un objet complet et une valeur absente ne signifie pas automatiquement suppression.
L’ordre et l’idempotence sont essentiels. Un événement ancien ne réécrit pas un état plus récent. Une reprise avec la même clé ne crée pas une nouvelle fiche. Lorsque le mapping manque, le message va dans une file d’analyse ; créer un objet « temporaire » sans rapprochement ne fait que déplacer le doublon.
La réconciliation compare identités, clés externes et versions entre systèmes. Elle produit une liste actionnable : référence inconnue, mapping multiple, objet absent ou attribut divergent. Le total d’enregistrements synchronisés n’est pas une preuve de cohérence.
Détecter avec règles et scores explicables
Normalisez pour comparer sans modifier la valeur source : casse, espaces, accents, téléphone, adresse et identifiants. Une règle exacte sur une clé forte peut proposer une fusion automatique. Une proximité de nom ou d’adresse crée un candidat, pas un verdict. Les faux positifs sont souvent plus coûteux qu’un doublon restant.
Le score affiche ses composantes : même identifiant légal, adresse proche, domaine e-mail, téléphone, contrat partagé. Il ne mélange pas des signaux dont le sens est inconnu. Le seuil est calibré sur un échantillon revu par le métier, avec précision, rappel et coût d’erreur.
Par exemple, un score supérieur à 95 peut automatiser uniquement si une clé forte concorde et qu’aucun attribut bloquant ne diverge. Entre 75 et 95, une revue humaine décide ; en dessous, le système surveille. Ces nombres sont locaux et doivent être ajustés aux objets et au risque.
Cas concret : deux fiches pour un client
Un groupe B2B découvre huit cent quarante candidats parmi soixante mille clients. Le CRM utilise l’e-mail du contact, l’ERP le numéro comptable et le portail un identifiant généré. Deux commerciaux ont créé séparément la même société, puis chacun a rattaché un contrat. Fusionner sur le nom ferait aussi disparaître des filiales homonymes.
L’équipe définit organisation, établissement et contact comme trois objets. Le SIREN identifie l’organisation française lorsqu’il est présent ; établissement et contrat gardent leurs clés. Le moteur crée des candidats à partir du SIREN, du domaine et de l’adresse normalisée. Les conflits de statut crédit ou de société de facturation interdisent l’automatisation.
Sur un échantillon de deux cents paires, le seuil initial produit trois faux rapprochements, jugés inacceptables. L’équipe exige alors une clé forte pour l’automatique et réserve les proximités à la revue. Le volume automatique baisse, mais aucune relation contractuelle n’est déplacée sans preuve.
Migrer les relations avant de fermer le doublon
La fusion choisit un identifiant canonique et crée des alias pour les anciennes références. Contacts, contrats, tickets et factures sont migrés par lots idempotents. Une balance compare nombre, montants et historiques avant et après. La fiche perdante devient redirection, pas suppression immédiate.
Le pilote traite cinquante paires et suit deux semaines. Le go exige zéro relation perdue, moins de dix minutes pour expliquer une fusion et aucune recréation par les trois flux. Ces seuils sont adaptés au risque client et à la capacité du support. La revue contrôle aussi les droits : un commercial ne gagne pas l’accès aux contrats de l’autre fiche uniquement parce que les organisations ont été rapprochées. Les consentements de contact restent attachés à leur preuve et ne sont jamais généralisés par commodité.
Fusionner sans effacer la preuve
La décision de fusion enregistre objets source, objet cible, règles, attributs retenus, auteur et date. Les anciennes clés restent des alias uniques. Une requête avec l’identifiant historique retrouve l’objet canonique. Ce mécanisme protège API, imports et liens envoyés avant la fusion.
Le rollback est possible tant que les écritures postérieures sont maîtrisées. Il ne consiste pas à restaurer une sauvegarde globale. Une compensation recrée les relations séparées depuis le journal de fusion et qualifie les nouvelles opérations. Au-delà d’un certain délai, une nouvelle séparation métier peut être plus sûre qu’un retour technique.
Les champs ne sont pas fusionnés par « non vide gagne ». Chaque famille suit sa règle d’autorité. Les valeurs écartées restent consultables dans le dossier d’audit pendant la durée utile. Les données personnelles inutiles suivent leur politique de conservation.
Prévenir la recréation par les flux
Chaque point de création recherche les clés fortes et les alias avant d’insérer. Sous concurrence, une contrainte ferme la course. L’API retourne l’objet existant ou un conflit actionnable. Un import de masse utilise la même logique, pas une voie rapide qui contourne le rapprochement.
Les systèmes externes reçoivent le mapping de fusion et confirment la prise en compte. Un export mensuel rare peut recréer l’ancienne fiche si sa référence n’a pas été propagée. Le registre des consommateurs et une période d’observation révèlent ces appels tardifs.
La déduplication n’est achevée que lorsque le taux de création de nouveaux candidats reste sous le seuil convenu et que les causes diminuent. Sinon, l’équipe nettoie en continu une fuite non réparée.
Maintenir un contrat de compatibilité pour les anciennes références
Les API acceptent temporairement une clé historique et retournent l’identifiant canonique avec une indication de redirection. Les imports consignent l’usage de l’alias, le système appelant et la date. Une référence dont aucun appel n’est observé pendant la période convenue devient candidate au retrait ; une référence encore active déclenche la correction du consommateur, pas la prolongation automatique de toutes les compatibilités. Ce suivi rend la fermeture progressive mesurable.
Instrumenter qualité et réconciliation
La mise en œuvre décrit entrées, sorties, responsabilités, dépendances, seuils et journalisation. L’instrumentation relie candidat, décision, fusion, alias et propagation. Le monitoring suit candidats nouveaux, auto-fusions, refus, recréations, mappings multiples et files en erreur.
Le rollback suspend les nouvelles fusions, laisse les migrations engagées atteindre un point cohérent et active la reprise documentée. La sortie exige une balance, une file qualifiée et la validation du propriétaire métier. Un seuil de faux positif déclenche immédiatement ce repli.
Les données de test couvrent homonymes, changement de nom, filiale, contact partagé, clé absente et concurrence. Elles sont synthétiques ou anonymisées. Le support recherche par toute ancienne référence et comprend la décision sans lire les tables brutes.
Pour qui la déduplication devient critique
Le sujet concerne les équipes produit, CRM, ERP, data et support lorsque plusieurs systèmes créent ou enrichissent clients, produits, contrats, sites ou équipements. Il devient critique avant une migration, une consolidation, un portail client ou un reporting réglementaire.
Une petite base avec une clé fiable peut se contenter de contraintes et d’une correction ponctuelle. Un moteur probabiliste serait disproportionné. À l’inverse, des objets à forte valeur, plusieurs sources et des relations juridiques exigent une revue et un journal de fusion.
Le métier définit l’identité et les erreurs inacceptables. La data calibre les signaux. La technique protège concurrence et propagation. Le run possède diagnostic et compensation. Aucun modèle automatique ne remplace ces responsabilités.
Erreurs fréquentes sur les doublons
Fusionner sur le nom
Les homonymes, filiales et changements de raison sociale rendent le nom insuffisant. Utilisez-le comme signal, puis exigez clés et contexte. Une fusion erronée peut exposer contrats ou données à la mauvaise organisation.
Choisir la dernière valeur
La récence ne remplace pas l’autorité. Conservez source, date effective et règle par attribut. Une correction fiable plus ancienne peut rester opposable face à une importation récente mais non validée.
Supprimer la fiche perdante
Les anciennes références continuent à circuler. Gardez un alias et une redirection, migrez les relations et observez les consommateurs. La suppression prématurée transforme le doublon en objets orphelins.
Décision : fusion automatique ou revue humaine
Bloc de décision. Automatisez une correspondance exacte sur une clé forte, dans un périmètre et sans conflit bloquant. Proposez une revue lorsque les signaux sont probabilistes. Refusez la fusion si l’identité métier reste ambiguë. Conservez deux objets reliés lorsque la différence est légitime.
Si le faux positif expose un contrat ou un droit, alors privilégiez la précision plutôt que le volume traité. En revanche, une copie technique portant le même identifiant canonique peut être rafraîchie automatiquement. À éviter : un score opaque qui déplace des relations sans motif.
- Commencer par les objets dont le doublon modifie une décision ou une exposition.
- Attendre avant d’automatiser tant que l’échantillon ne prouve pas son seuil.
- Conserver deux objets lorsque les clés fortes se contredisent ou que l’autorité reste inconnue.
- Élargir seulement après avoir fermé les voies de recréation.
Plan d’action sur six semaines
Semaines un à trois : définir et mesurer
Sélectionnez cent candidats et vingt objets sains. Fermez granularité, clés, attributs d’autorité et erreurs inacceptables. Cartographiez les créations et copies. Ajoutez les contraintes certaines après inventaire des conflits. Mesurez volume, interventions et coût métier.
Construisez le score explicable et faites revoir l’échantillon par deux personnes. Séparez seuil automatique, revue et rejet. Préparez alias, journal de fusion et balance des relations. Simulez une fusion et son annulation sur des données représentatives.
Semaines quatre à six : piloter et fermer les fuites
Traitez cinquante paires dans un périmètre. Propulsez les aliases vers les consommateurs et surveillez les anciennes références. Provoquez concurrence, message rejoué, export tardif et conflit d’autorité. Le support exécute diagnostic et compensation.
Comparez faux positifs, relations perdues, recréations et temps de traitement. Ajustez les règles sans réécrire les décisions passées. Étendez si les seuils locaux sont tenus et si la balance ferme chaque lot ; sinon, réduisez l’automatique et corrigez la source de création.
Avant le verdict, sélectionnez dix anciennes références et faites-les rechercher par le support, l’API et l’import. Chaque chemin doit retrouver l’objet canonique, afficher la raison de la fusion et préserver les droits. Le compte rendu sépare les anomalies de matching, de migration et de propagation. Il attribue une correction et une date à chacune, puis vérifie que la relance du lot reste idempotente. Cette recette empêche qu’un bon taux global masque un seul contrat rattaché au mauvais client.
- Définir l’identité et les clés dans leur périmètre.
- Calibrer les signaux sur un échantillon revu.
- Fusionner avec aliases, journal et balance.
- Fermer les recréations avant d’augmenter le volume.
Approfondir migration et référentiels
Après le premier lot, entretenez un tableau de santé par objet métier : créations quotidiennes, candidats détectés, paires revues, fusions annulées et anciennes références encore appelées. Une hausse des candidats après correction signale généralement une voie d’entrée oubliée, pas un moteur de matching trop faible. Reliez donc chaque nouvel écart à son système créateur et à la règle d’identité enfreinte. Cette boucle transforme la déduplication ponctuelle en contrôle durable, sans promettre une base immobile ni imposer la même tolérance à un prospect, un contrat et un bénéficiaire.
Nettoyer avant une migration
Le guide nettoyer la donnée avant migration aide à séparer bloquants, quarantaines et corrections reportables.
Choisir un référentiel commun
Pour décider centralisation et responsabilités, poursuivez avec le référentiel commun pour clients, produits, contrats ou sites. Ces lectures doivent être appliquées à un objet et à ses flux réels.
- Ne pas confondre qualité parfaite et identité exploitable.
- Conserver les références historiques pendant la transition.
- Mesurer la recréation, pas seulement le stock de doublons.
Conclusion : un objet, une identité
Une copie nécessaire reste saine lorsqu’elle référence une identité et respecte une autorité. Un doublon devient dangereux lorsqu’il porte sa propre décision, ses relations et ses corrections. Le traitement commence donc par le métier, pas par la similarité des chaînes.
Les clés, contraintes, scores et fusions ne valent qu’avec provenance, aliases et balance. Une revue humaine protège les cas ambigus. La réconciliation démontre que chaque système retrouve le même objet sans devenir maître par accident.
Commencez par les doublons qui exposent argent, droit ou promesse client. Fermez ensuite les voies de création. Le nombre de fiches baisse peut-être moins vite, mais la cohérence cesse de se dégrader.
- Une identité définie.
- Une autorité par attribut.
- Une fusion explicable et réversible.
Dawap peut accompagner ce chantier de développement web sur mesure : modèle d’identité, audit des doublons, contraintes, pipeline de fusion, réconciliation et préparation du run.
