Le fichier source contient 180 000 clients, mais la cible n’en attend que 146 000. Une requête groupe les e-mails normalisés, conserve la ligne la plus récente et supprime les autres avant le chargement.
La douleur apparaît après la recette : contrats orphelins, tickets rattachés au mauvais compte, consentements disparus et identifiants ERP devenus introuvables. Le symptôme et premier signal faible surviennent lorsque plusieurs règles donnent des survivants différents ; un second se voit quand les doublons partagent un contact mais pas la même entité juridique, avant que les écarts ne contaminent facturation et support.
Le vrai enjeu n’est pas de réduire le nombre de lignes, mais de reconstruire une identité canonique sans détruire les faits qui lui sont attachés. Vous allez comprendre comment décider les fusions, préserver relations, historiques et identifiants, puis prouver qu’une relance ou un rollback produit le même résultat.
Le développement web sur mesure doit traiter cette opération comme une transformation de graphe gouvernée. La déduplication devient un produit de migration auditable, plutôt qu’une requête de nettoyage exécutée juste avant la bascule.
Dans quel cas les doublons menacent une migration
Un doublon menaçant porte des relations ou des identifiants dont la collision peut modifier un droit, un montant, une chronologie ou une obligation. Deux fiches marketing vides n’ont pas le même risque que deux comptes porteurs de contrats actifs.
Qualifier l’impact avant la ressemblance
Le profilage compte factures, commandes, consentements, droits, incidents, documents et références externes par candidat. Il distingue aussi les relations exclusives, cumulables ou historiquement successives afin d’estimer le coût d’une mauvaise fusion.
La priorité croise probabilité de doublon et effet irréversible. Un groupe très probable sans dépendance peut être automatisé plus tôt qu’un groupe ambigu dont une fusion déplacerait un contrat ou exposerait des données. Contre-intuitivement, le coût caché principal vient souvent d’une fusion trop confiante, car sa charge support et ses corrections dépassent celles d’une revue ciblée.
Séparer duplication et coexistence légitime
Une même adresse peut représenter un foyer, un siège partagé ou un site de livraison. Un e-mail générique peut appartenir à plusieurs établissements, tandis qu’un changement de raison sociale peut être une succession historique et non un doublon.
À refuser : considérer une égalité normalisée comme une preuve suffisante. La règle doit expliquer pourquoi deux lignes décrivent la même identité métier au même instant et dans le même périmètre juridique.
Définir le référentiel et ses dépendances réelles
Le référentiel ne s’arrête pas à sa table principale. Il comprend clés étrangères, tables d’association, journaux, fichiers, index de recherche, caches, exports, systèmes abonnés et références imprimées dans des documents immuables.
Cartographier les liens entrants et sortants
Pour chaque relation, l’inventaire nomme propriétaire, cardinalité, sémantique, contrainte, volumétrie, mode de reprise et preuve attendue. Les liens polymorphes ou stockés en JSON sont cherchés explicitement, car le schéma relationnel ne les révèle pas.
Les intégrations externes indiquent si elles connaissent la clé interne, une clé métier ou leur propre identifiant. Une référence non modifiable peut imposer la conservation d’un alias durable au lieu d’une substitution destructrice.
Définir le système autoritaire par attribut
Une identité n’a pas toujours une source unique. Le CRM peut gouverner le contact, l’ERP la facturation, le contrat la raison sociale historique et le fournisseur d’identité certains attributs vérifiés.
La matrice d’autorité inclut période et condition de validité. Une source aujourd’hui prioritaire ne doit pas réécrire rétroactivement une valeur qui expliquait une facture ou une décision ancienne.
Séparer identité métier et ligne survivante
L’identité canonique est une décision métier durable ; la ligne survivante reste un choix d’implémentation. Confondre les deux pousse à garder arbitrairement l’enregistrement le plus ancien ou le plus rempli, même lorsque ses valeurs sont fausses.
Créer une clé canonique indépendante
Le modèle attribue un nouvel identifiant canonique ou choisit une clé stable selon une règle documentée. Toutes les anciennes clés deviennent des alias, avec origine, période, état et décision de rattachement.
Cette séparation autorise une correction ultérieure sans changer l’identité publique. Elle évite aussi que l’identifiant d’un outil source devienne accidentellement la vérité partagée par tous les consommateurs.
Nommer les états de décision
Un groupe peut être proposé, confirmé automatiquement, confirmé manuellement, refusé, séparé ou en attente de preuve. Chaque état possède acteur autorisé, justification minimale et conséquences sur le chargement.
La décision n’écrase jamais les candidats. Elle conserve version de règle, facteurs concordants, contradictions, données examinées et identité cible afin qu’un audit puisse reproduire le raisonnement.
Produire des candidats explicables et révisables
Comparer toutes les lignes entre elles devient rapidement impraticable. Le blocking crée des ensembles plausibles à partir de clés stables ou normalisées, puis le matching évalue plusieurs preuves à l’intérieur de ces ensembles.
Combiner règles fortes et signaux faibles
Un identifiant fiscal vérifié ou une clé fournisseur stable peut constituer une preuve forte selon le domaine. Nom, téléphone, adresse et proximité phonétique restent des signaux à combiner, jamais des verdicts isolés.
Le moteur expose valeur brute, forme normalisée, provenance, score par facteur et contradictions. Une date de création incompatible ou deux identifiants exclusifs distincts peuvent bloquer la fusion malgré une forte proximité nominale.
Calibrer sur un corpus représentatif
Le corpus contient vrais doublons, homonymes, foyers, franchises, changements historiques et données incomplètes. Les seuils sont comparés par segment, car une règle efficace sur les particuliers peut être dangereuse sur les entreprises multi-établissements.
La revue mesure faux positifs, faux négatifs, volume manuel et gravité des erreurs. Le bon seuil minimise le risque métier total, pas seulement la distance entre deux chaînes.
Former des groupes sans fusion transitive aveugle
Si A ressemble à B et B à C, A ne ressemble pas nécessairement à C. Une fermeture transitive automatique peut assembler progressivement un groupe incohérent autour de valeurs génériques ou partagées.
Vérifier la cohérence de chaque cluster
Le groupe contrôle contradictions fortes, nombre d’identités exclusives, périodes de coexistence et densité des relations. Une fusion exige que chaque membre soit compatible avec le canon, pas seulement relié à un voisin.
Les clusters volumineux ou présentant une faible cohésion sont scindés ou envoyés en revue. Une adresse collective et un standard téléphonique ne doivent pas créer une super-identité contenant plusieurs sociétés.
Geler la version du groupe traité
La proposition stocke les membres et leurs versions de données. Si une source modifie un candidat avant application, la précondition échoue et le groupe est recalculé plutôt que fusionné sur une photographie périmée.
Cette frontière protège les reprises concurrentes et rend la décision déterministe. Le batch ne doit jamais ajouter silencieusement un nouveau membre à un groupe déjà approuvé.
Réattacher les relations sans changer leur sens
La fusion remplace plusieurs extrémités par une identité canonique, mais chaque relation conserve son rôle, sa période et sa provenance. Une simple mise à jour de clé étrangère peut créer doublons d’association ou cardinalités interdites.
Appliquer une politique par type de lien
Les commandes et tickets s’additionnent ; une préférence active peut exiger arbitrage ; un rôle exclusif peut signaler une contradiction ; une adresse historique reste attachée avec ses dates. La politique nomme fusion, conservation parallèle ou blocage.
Avant écriture, une simulation calcule les collisions de contraintes uniques, relations dupliquées et changements de cardinalité. Chaque collision reçoit une décision explicite au lieu d’être résolue par le premier enregistrement rencontré.
Préserver les relations auto-référentes
Hiérarchies, parrains, groupes et liens parent-enfant peuvent pointer entre candidats du même cluster. Le transformateur interdit les boucles nouvelles, supprime seulement les auto-liens devenus sans sens et conserve leur trace.
Le contrôle compare le graphe avant et après : nombre de composantes, profondeurs, cycles, rôles et relations sans destination. Une différence attendue est justifiée dans le manifeste de migration.
Conserver historique, provenance et chronologie
L’historique explique pourquoi une donnée ou une décision existait. Le compacter dans la ligne canonique fait perdre auteur, ordre, source et contexte, puis empêche support ou audit de reconstruire un état passé.
Distinguer état courant et faits immuables
Le canon expose les valeurs courantes, tandis que les événements, versions ou snapshots restent reliés à leurs identités d’origine et au canon. Une table de correspondance permet les lectures historiques sans réécriture mensongère.
Les dates métier, dates système et dates de migration restent séparées. Le chargement ne présente jamais sa propre date comme la date de création ou de modification fonctionnelle de l’objet.
Documenter la provenance de chaque valeur
Chaque attribut survivant indique source, identifiant d’origine, instant, règle et éventuelle validation humaine. Une valeur calculée conserve ses entrées pour pouvoir être recalculée avec la même version.
Cette provenance rend la fusion contestable et corrigeable. Sans elle, une adresse canonique apparemment complète peut provenir d’un ancien devis plutôt que du dernier contrat vérifié.
Maintenir tous les identifiants externes utiles
Les identifiants ERP, CRM, support, IAM ou partenaire ne sont pas des doublons à écraser. Ils représentent des espaces de clés différents et permettent encore rapprochement, synchronisation ou lecture d’archives.
Modéliser source, portée et validité
La table d’alias contient système, type d’objet, identifiant externe, canon, période et statut. Une contrainte unique s’applique dans le bon espace, jamais sur la valeur brute partagée entre systèmes indépendants.
Un identifiant réattribué par une source exige une période ou une version. Le connecteur doit savoir si un message ancien se rattache au canon historique ou à l’identité actuellement associée.
Maintenir une traduction bidirectionnelle
Les flux entrants résolvent l’ancien identifiant vers le canon ; les sorties choisissent l’identifiant attendu par leur destination. Cette traduction reste disponible après la bascule et produit une erreur explicite lorsqu’elle devient ambiguë.
Les appels, exports et journaux incluent canon et clé externe concernée. Le support peut ainsi retrouver un dossier depuis n’importe quelle référence connue sans deviner quelle ligne a survécu.
Décider la valeur survivante attribut par attribut
« Le plus récent gagne » ignore autorité, complétude et validité. Une valeur plus récente peut venir d’un import faible, tandis qu’une valeur ancienne reste contractuellement ou légalement pertinente.
Écrire une matrice de survivance
Chaque attribut possède sources autorisées, priorité, critères de qualité, règle temporelle, traitement du vide et condition d’escalade. Les collections définissent aussi déduplication, ordre et conservation historique.
Une contradiction forte bloque l’attribut ou le groupe selon son impact. La migration ne remplace pas un identifiant vérifié par une valeur incertaine uniquement pour obtenir un canon entièrement rempli.
Séparer absence et effacement volontaire
Une valeur nulle peut signifier inconnue, non applicable ou supprimée à la demande. La normalisation conserve cette sémantique afin qu’un enregistrement incomplet ne ressuscite pas une donnée volontairement effacée.
Le résultat indique, pour chaque valeur, candidat retenu et candidats écartés. Les opérations peuvent expliquer le choix et son contexte sans relire toutes les lignes sources initiales.
Construire un crosswalk durable et idempotent
Le crosswalk relie chaque ancienne clé à l’identité canonique et à la décision qui l’a produite. Il sert au chargement, aux mises à jour tardives, au rollback, au support et à la réconciliation.
Versionner décision et état d’application
Une ligne contient source, ancienne clé, canon, version de règle, empreinte des entrées, statut, lot et instant. La contrainte empêche deux canons actifs pour la même clé dans une même portée.
entity_crosswalk(
source_system, source_key, canonical_id,
decision_version, input_fingerprint,
applied_batch, valid_from, valid_to
)Les entrées sont inventaire et décisions gelées ; les sorties sont correspondances et anomalies. Le job garantit idempotence et journalisation, écrit par lots transactionnels, enregistre les checkpoints et reprend après le dernier lot confirmé.
Refuser une reprise divergente
Une deuxième exécution avec les mêmes entrées doit produire le même canon et aucune relation supplémentaire. Si empreinte ou règle change, le système crée une nouvelle décision révisée plutôt que modifier silencieusement l’ancienne.
L’idempotence couvre données, liens et effets externes. Un export déjà envoyé est identifié par lot et destination afin qu’une reprise technique ne rediffuse pas une fusion.
Traiter les écritures concurrentes pendant la bascule
Une migration longue coexiste souvent avec des créations et corrections dans le legacy. Ignorer ces écritures produit un canon périmé dès son activation, tandis qu’un gel total peut être impossible opérationnellement.
Choisir une stratégie de capture explicite
Gel court, journal de changements, double écriture contrôlée ou delta final répondent à des contraintes différentes. La stratégie précise ordre, déduplication, retard maximal et responsabilité lorsque source et cible divergent.
Un changement sur une ligne membre invalide la proposition ou alimente une règle de rebase. Il ne doit jamais être écrasé par le snapshot ancien simplement parce que le batch termine plus tard.
Protéger la fenêtre de cutover
La bascule vérifie dernier offset capturé, absence de lot incomplet, disponibilité du crosswalk et équilibre des écritures. Une barrière empêche les deux systèmes d’accepter simultanément une nouvelle identité sans résolution commune.
La méthode s’aligne sur le point de non-retour d’une bascule legacy : les critères techniques et métier fixent ensemble la dernière décision réversible et son autorité d’approbation.
Répéter la migration sans accumuler les fusions
Une usine de migration doit être relancée sur des snapshots successifs. Les décisions déjà stables sont réutilisées, les nouveaux candidats sont évalués et les changements de règle restent comparables.
Séparer calcul et application
La phase de calcul produit propositions, survivance, relations futures et anomalies sans toucher la cible. La phase d’application consomme un manifeste approuvé dont l’empreinte interdit toute modification tardive.
La conception d’une usine de migration apporte versionnement, checkpoints et répétabilité. La déduplication y devient une étape adressable, mesurée et rejouable avec ses propres artefacts.
Comparer les deltas entre répétitions
Le rapport montre groupes nouveaux, fusions retirées, canons changés, valeurs survivantes différentes et relations affectées. Une variation importante exige une cause de données ou de règle avant promotion.
Les décisions manuelles sont réinjectées comme règles bornées ou exceptions versionnées. Elles ne disparaissent pas à la répétition suivante et ne contaminent pas des groupes non concernés.
Préparer un rollback qui restaure aussi les liens
Restaurer seulement la table canonique ne suffit pas si les contrats, tickets ou exports pointent déjà vers ses clés. Le rollback doit couvrir graphe, alias, effets externes et écritures survenues après bascule, avec responsabilité, seuil d’arrêt et traçabilité de chaque compensation.
Conserver les inverses nécessaires
Le manifeste enregistre anciennes destinations, valeurs remplacées, relations créées ou fusionnées et lots externes émis. Les opérations savent ce qui est automatiquement inversable et ce qui exige compensation métier.
Une fusion ne supprime physiquement aucune source pendant la période de sécurité. Les lignes deviennent inactives ou archivées avec contrôle d’accès, afin de permettre enquête et restauration sans les exposer aux parcours normaux.
Tester le retour avec des écritures nouvelles
Le scénario ajoute contrat et correction après bascule, puis déclenche le rollback. La procédure décide comment redistribuer ces nouveaux faits entre anciennes identités sans fabriquer une chronologie incohérente.
Le succès exige navigation, soldes, droits et recherches corrects dans le système restauré. Un rollback techniquement terminé mais suivi de relations orphelines reste un échec.
Prouver cardinalités, soldes et navigation métier
Une baisse du nombre de lignes est attendue, mais elle ne prouve ni l’exactitude des canons ni la conservation des faits. La validation compare invariants techniques et parcours métier avant chaque promotion.
Équilibrer chaque catégorie de relation
Le contrôle compte relations avant, relations fusionnées selon règle, relations après, anomalies et exclusions justifiées. Les totaux de montants, droits actifs et documents restent égaux lorsque la fusion ne doit pas les modifier.
Les tests traversent canon vers commandes, commande vers canon, ancienne clé vers canon et système externe vers cible. Ils couvrent aussi recherche, export, support et consultation historique.
Échantillonner selon le risque
La revue choisit grands clusters, contradictions, relations exclusives, fort impact financier et règles nouvelles. Un échantillon aléatoire complète cette sélection pour détecter une classe d’erreur non anticipée.
Chaque preuve référence snapshot, lot, règle et requête reproductible. Les écarts sont triés entre défaut de donnée, défaut de décision et défaut d’application afin de corriger au bon niveau.
Erreurs fréquentes qui détruisent de l’information
Les erreurs les plus graves produisent souvent une cible apparemment propre. Elles réduisent le volume tout en supprimant la possibilité d’expliquer, corriger ou réconcilier les identités.
Six décisions à refuser en revue
- Garder le plus récent : cette règle ignore autorité, effacement volontaire, provenance et validité historique de chaque attribut fusionné.
- Supprimer les perdants : les anciennes clés, preuves et relations deviennent introuvables, ce qui bloque support, audit et rollback.
- Fermer transitivement : une chaîne de ressemblances assemble des entités incompatibles qui ne partagent aucune preuve commune suffisante.
- Réécrire tous les historiques : le canon actuel remplace mensongèrement l’identité qui existait au moment du fait enregistré.
- Ignorer les deltas : les corrections survenues pendant le batch sont écrasées ou rattachées à une identité déjà dépassée.
- Valider par comptage : la baisse attendue masque relations orphelines, montants dupliqués et identifiants externes devenus ambigus.
Le signal d’arrêt prioritaire est une collision sur contrat, droit, identité exclusive ou somme financière. Le lot reste réversible tant que la cause n’est pas expliquée et sa correction répétée sur le même snapshot.
Cas concret : quatre clients, deux sociétés et un contrat
Quatre lignes partagent téléphone et domaine e-mail. Deux représentent la même société après changement de CRM, une appartient à sa filiale et la dernière à un ancien salarié désormais client particulier.
Former deux canons et refuser une fusion
Identifiant fiscal, contrat et période confirment la fusion des deux premières lignes. La filiale garde son canon malgré l’adresse commune ; l’ancien salarié reste séparé, car son e-mail personnel et ses achats ne décrivent pas la société.
Le contrat, les factures et les tickets des deux premières lignes sont réattachés selon leurs politiques. Les identifiants des deux CRM restent des alias vers le canon, tandis que la raison sociale ancienne conserve sa période.
Prouver le résultat de bout en bout
La simulation montre quatre sources, trois canons, aucun contrat orphelin et aucun solde modifié. Les recherches par chaque ancien identifiant retrouvent le bon dossier, sans exposer la filiale ou l’ancien salarié.
Une correction concurrente du téléphone invalide seulement le groupe concerné. Le recalcul conserve la décision fiscale, actualise la valeur survivante et produit le même graphe après une seconde exécution.
Plan d’action : industrialiser la fusion en huit semaines
Le déploiement progresse du périmètre et des preuves vers l’application réversible. Chaque étape produit un artefact vérifiable avant de toucher davantage de relations métier.
Semaines 1 à 4 : graphe, candidats et décisions
La première moitié sécurise le sens des données avant toute fusion physique. Chaque livrable est relu par les propriétaires métier et technique responsables des invariants concernés.
- Semaine 1 : inventorier tables, relations cachées, systèmes externes, identifiants, propriétaires et invariants financiers ou juridiques.
- Semaine 2 : profiler doublons, contradictions, clusters, cardinalités et impacts, puis constituer un corpus de vérité représentatif.
- Semaine 3 : définir canon, règles de candidats, cohérence des groupes, matrice de survivance et états de décision audités.
- Semaine 4 : modéliser crosswalk, politiques de relations, provenance, deltas et contraintes idempotentes avant toute application réelle.
Semaines 5 à 8 : répétition, bascule et preuve
- Semaine 5 : exécuter un dry-run complet, analyser collisions et deltas, puis corriger règles plutôt que résultats individuels cachés.
- Semaine 6 : appliquer une cohorte réversible, vérifier relations, historique, alias et navigation depuis chaque système consommateur.
- Semaine 7 : provoquer reprise, écriture concurrente et rollback, puis réconcilier chaque effet avec le manifeste versionné du lot.
- Semaine 8 : répéter sur snapshot frais, faire approuver les écarts et ouvrir la bascule avec seuils d’arrêt et propriétaires disponibles.
La sortie exige décisions explicables, crosswalk complet, relations équilibrées, historique consultable, reprise identique et rollback testé. Un référentiel plus petit sans ces preuves n’est pas encore fiable.
Le go final est attribué par domaine et non par un taux global de doublons supprimés. Une seule relation financière ou un consentement sans provenance suffit à maintenir la population concernée en quarantaine, sans bloquer les cohortes indépendantes déjà réconciliées.
Guides complémentaires : profilage, identité et usine
La déduplication s’appuie sur une connaissance mesurée des sources, une doctrine d’identité et un pipeline répétable. Ces ressources couvrent les trois dépendances qui précèdent une fusion sûre.
Relier découverte, décision et exécution
Le profilage avant migration révèle domaines et anomalies, puis la résolution d’identités évite de confondre homonymes, foyers et sociétés liées pendant chaque arbitrage critique.
L’usine de migration de données transforme ces décisions en lots versionnés, répétables et réconciliés. Le même manifeste relie alors analyse, fusion, chargement et preuve de sortie.
Conclusion : dédupliquer signifie préserver la preuve
Une déduplication fiable ne choisit pas seulement un survivant. Elle reconstruit un canon, traduit toutes les anciennes clés et conserve le sens de chaque relation dans le temps.
La qualité se démontre par crosswalk, provenance, cardinalités, répétabilité et rollback. Ces mécanismes permettent de corriger une décision sans effacer les faits qui l’avaient précédée.
Pour cadrer et mettre en œuvre cette transformation, notre expertise en développement web sur mesure relie modèle de données, règles métier, pipeline de migration et recette afin que le nouveau référentiel soit plus cohérent sans devenir moins explicable.
