Deux clients partagent un nom, une adresse ancienne et le même téléphone familial. Une fusion automatique les transforme en une seule personne, puis rattache le contrat professionnel de l’un au dossier de crédit de l’autre. Le problème n’apparaît pas pendant le chargement : il devient visible lorsque le support ouvre la fiche cible et expose des droits ou des documents au mauvais titulaire.
Un signal faible se voit quand une clé de rapprochement fusionne beaucoup plus de fiches dans une région. Un autre apparaît lorsqu’un « doublon » possède deux activités simultanées, avant que la recette ne découvre des soldes incompatibles. Vous allez comprendre comment séparer égalité, appartenance et simple ressemblance, puis décider quelles paires peuvent être fusionnées sans risque.
Le vrai enjeu n’est pas de maximiser un taux de déduplication. Le développement web sur mesure d’une refonte doit préserver les identités nécessaires aux droits, contrats, historiques et obligations. Chaque rapprochement exige donc une preuve, une portée et une voie de retour.
Dans quel cas la résolution d’identités devient critique
Le chantier devient critique lorsque plusieurs CRM, ERP, portails ou acquisitions ont créé leurs propres identifiants. Il l’est aussi quand les utilisateurs du legacy dupliquent une fiche pour contourner un blocage, gérer un établissement ou conserver un ancien état.
Relier le risque à l’effet de la fusion
Fusionner deux abonnés à une newsletter porte un impact différent de fusionner deux titulaires de droits ou deux comptes débiteurs. Le périmètre commence par les objets qui déplacent argent, accès, consentement, garantie ou responsabilité.
Si une référence autoritative couvre toutes les sources, alors le rapprochement peut rester déterministe. En revanche, si les identifiants ont été réutilisés ou jamais propagés, la résolution devient une décision probabiliste à calibrer et à superviser.
Le coût complet d’une fausse fusion comprend enquête, restauration, notification éventuelle et perte de confiance. Celui d’un doublon conservé comprend traitement répété et vision fragmentée. La première erreur étant souvent irréversible, son seuil doit être plus exigeant.
Définir la frontière entre personne, foyer, établissement et société
Une adresse commune ne prouve pas une personne commune. Deux établissements peuvent partager SIREN sans partager SIRET ; une holding et sa filiale appartiennent au même groupe sans constituer le même débiteur. Le modèle cible doit représenter ces relations au lieu de les aplatir.
Écrire les identités utiles au domaine
Le vocabulaire distingue individu, organisation, établissement, compte, contact et rôle. Une personne peut être contact de plusieurs sociétés ; un foyer peut regrouper des personnes sans devenir propriétaire de leurs contrats ; une organisation peut changer de nom sans changer d’identité légale.
Les responsables métier valident les frontières, la sécurité décrit les droits, tandis que l’équipe data vérifie leur représentation dans les sources. Une ambiguïté de modèle n’est jamais résolue par un seuil statistique.
À refuser : choisir comme entité la table la plus pratique. La table « client » peut mélanger personne, compte de facturation et point de livraison ; la fusion technique reproduirait ce défaut dans la cible.
Hiérarchiser les preuves avant d’écrire une règle de fusion
Les preuves se classent selon leur autorité, leur stabilité et leur portée. Un identifiant légal vérifié, une référence contractuelle ou un identifiant d’identité géré valent davantage qu’un email, un téléphone ou une adresse saisis librement.
Documenter ce que chaque attribut démontre
Le tableau des preuves précise source, date, processus de validation, unicité attendue, fréquence de réutilisation et populations exclues. Un email professionnel peut être réattribué ; un mobile peut être familial ; un numéro légal peut être absent pour certaines structures étrangères.
Les preuves négatives comptent également : deux dates de naissance différentes, deux identifiants légaux valides ou deux activités concurrentes interdisent une fusion même si plusieurs coordonnées correspondent.
Chaque règle conserve ses champs contributifs et contradictoires. Le support peut ainsi comprendre pourquoi une paire a été fusionnée, liée ou isolée sans interpréter une valeur de score opaque.
Commencer par les correspondances déterministes réellement sûres
Les règles déterministes couvrent les cas où une même référence stable traverse plusieurs sources. Elles produisent une classe de confiance élevée, à condition de vérifier l’unicité et les collisions historiques avant de les appliquer.
Tester les clés sur les données et dans le temps
Le profil mesure valeurs partagées, réutilisées après suppression, mal formées et présentes sur plusieurs types d’entité. Une clé déclarée unique dans l’ERP peut avoir été copiée lors d’un import manuel ou contenir des zéros génériques.
Une règle sûre peut combiner source, pays, type d’entité et identifiant. Elle est exécutée atomiquement, journalisée et testée sur des cas limites. Les paires en contradiction rejoignent une file de revue au lieu de forcer l’autorité théorique.
Par exemple, si 0,3 % des SIREN apparaissent sur des fiches déclarées « personne », alors l’équipe bloque ces fiches, corrige leur type et ne généralise la fusion qu’après disparition de l’incohérence.
Normaliser sans effacer les différences discriminantes
La normalisation rapproche casse, accents, civilités, formats téléphoniques et espaces. Elle conserve la valeur brute, la règle appliquée et la version, afin qu’une décision puisse être reproduite après évolution du référentiel.
Adapter la règle au type de champ
Les noms utilisent translittération contrôlée, prénoms composés et ordre culturel ; les adresses séparent voie, numéro, complément et pays ; les entreprises gèrent forme juridique sans la confondre avec la raison sociale.
Supprimer tous les caractères ou mots fréquents crée des collisions. « Martin Conseil » et « Martin Conseils » peuvent être deux sociétés ; deux appartements d’un immeuble ne partagent pas la même adresse complète.
Contrairement à ce que suggère un nettoyage agressif, davantage de normalisation ne produit pas toujours une meilleure résolution. Elle augmente parfois le rappel en détruisant précisément le signal qui protégeait les homonymes.
Réduire les comparaisons avec un blocage explicable
Comparer chaque fiche à toutes les autres devient coûteux et crée des candidats absurdes. Le blocking rassemble uniquement des paires plausibles à partir de plusieurs clés larges : préfixe phonétique et code postal, domaine email et nom, identifiant légal partiel ou téléphone normalisé.
Multiplier les passes sans enfermer les cas rares
Une seule clé de blocage manque les déménagements ou les erreurs de saisie. Plusieurs passes produisent une union de candidats, puis le score détaillé décide. Chaque passe mesure couverture des doublons annotés et volume de paires générées.
Les entrées sont les représentations normalisées et la version des règles ; les sorties sont des couples candidats avec le motif de sélection. Le worker assume performance et traçabilité, tandis que la décision de fusion appartient à la couche de résolution.
Un seuil de volume protège la CI et le run de migration. Si une valeur générique crée plus de 50 000 candidats, alors elle est exclue du blocage et signalée comme anomalie source plutôt que saturer mémoire et temps utile.
Sur une usine Symfony et PostgreSQL, chaque worker lit un lot borné, écrit ses couples candidats avec une contrainte unique puis publie son curseur de reprise. Le traitement reste idempotent après timeout, tandis que la journalisation associe snapshot, commit applicatif, version de normalisation et durée à chaque partition exécutée.
Construire un score calibré sur des paires annotées
Le score combine similarités et contradictions avec des poids appris ou décidés. Il ne vaut que pour une population, une version de données et un coût d’erreur connus. Un seuil copié d’un autre domaine n’offre aucune garantie.
Mesurer précision, rappel et zone d’ambiguïté
Un corpus de paires contient doublons certains, homonymes, foyers, sociétés liées et cas incertains. Deux réviseurs annotent indépendamment les situations sensibles, puis documentent leur désaccord au lieu de fabriquer une vérité artificielle.
Le seuil automatique vise une précision très élevée sur les entités à risque. Une seconde zone envoie les paires en revue ; le reste demeure séparé. Le rappel est récupéré plus tard par d’autres règles sans sacrifier la sécurité.
Si la précision tombe sous 99,9 % sur les titulaires de droits, l’automatisation est refusée. Les paires déterministes continuent, les ambiguïtés attendent et le modèle est corrigé avant une nouvelle cohorte.
Ajouter la temporalité aux adresses, contacts et rôles
Deux fiches peuvent partager une adresse à des périodes différentes. Une personne change de société, un téléphone est réattribué et une filiale devient indépendante. Ignorer les dates transforme une relation successive en identité commune.
Comparer des intervalles plutôt que des valeurs isolées
Chaque attribut porte début, fin, source et confiance lorsque ces informations existent. La concordance simultanée renforce une paire ; une concordance séparée de dix ans peut indiquer une succession ou une donnée obsolète.
Les événements métier aident à reconstruire la chronologie : signature, déménagement, fusion juridique, transfert de portefeuille. Une valeur courante ne doit pas écraser l’historique utile à la preuve.
Le pipeline conserve l’instant auquel sa décision a été prise. Un nouveau snapshot peut rouvrir une paire si un identifiant autoritatif apparaît, mais il ne réécrit pas silencieusement les versions déjà utilisées en recette.
Utiliser le graphe pour distinguer égalité et relation
Le graphe représente personnes, organisations, établissements, comptes, contrats et coordonnées. Ses arêtes portent rôle et période. Il révèle qu’une adresse ou un dirigeant partagé relie deux sociétés sans les rendre identiques.
Empêcher la transitivité aveugle des rapprochements
Si A ressemble à B et B à C, A n’est pas nécessairement C. Une chaîne peut traverser un standard téléphonique ou une adresse de siège utilisée par de nombreuses entités. Le moteur recalcule la cohérence du cluster avant chaque ajout.
Les composantes trop grandes, les cycles incohérents et les liens contradictoires déclenchent une alerte. Un cluster de 300 personnes partageant un contact générique est une anomalie de donnée, pas un client unique.
Le graphe permet aussi de conserver les relations utiles après séparation : appartenance à un groupe, membre d’un foyer, ancien contact ou mandataire. La cible gagne en sens sans fausse fusion.
Matrice de décision entre fusion, lien, revue et séparation
La décision croise preuve positive, contradiction, impact et possibilité de réparation. Elle fournit un résultat actionnable plutôt qu’une simple probabilité.
Attribuer une conduite stable à chaque classe
- À fusionner : référence autoritative commune, aucune contradiction et type d’entité identique ; conserver les deux sources et la règle gagnante.
- À lier : relation prouvée entre foyer, contact, établissement ou groupe, mais identités autonomes et droits séparés.
- À revoir : score intermédiaire, preuve manquante ou conflit résolvable ; présenter les faits utiles sans dévoiler inutilement les données sensibles.
- À séparer : identifiants autoritatifs distincts, activités simultanées incompatibles ou contradiction sur un attribut fort, même si plusieurs coordonnées se ressemblent.
- À bloquer : fusion à fort impact impossible à annuler proprement ; corriger d’abord le modèle, les relations ou la provenance.
D’abord viennent les correspondances déterministes. Ensuite la revue des fortes valeurs métier. Les paires à faible impact peuvent être traitées plus tard ; un objectif de volume ne doit jamais abaisser le seuil des droits ou paiements.
Construire le golden record sans écraser les sources
La fusion crée un identifiant cible et des règles de survivance par attribut. Elle ne copie pas simplement la fiche la plus récente : chaque champ choisit la source la plus autoritaire, la plus fraîche et compatible avec son usage.
Conserver provenance et valeurs concurrentes
Le nom légal peut venir du référentiel vérifié, le téléphone du portail confirmé et l’adresse de facturation du contrat actif. Les anciennes valeurs restent historisées avec source, intervalle et motif de remplacement.
Les relations sont rattachées selon leur propre identité. Contrats, consentements, paiements et documents ne sont jamais déplacés par une mise à jour générique de clé sans contrôle d’intégrité et rapport de rapprochement.
Le golden record expose la décision actuelle, tandis que le journal permet de reconstruire le chemin. Une correction dans la source peut être réingérée sans effacer les choix déjà signés.
Les chargements utilisent une table de correspondance versionnée entre identifiants legacy et pivot cible. Une clé étrangère n’est réécrite qu’après validation de son propriétaire, puis les comptages et sommes de contrôle prouvent qu’aucun contrat, document ou mouvement n’a disparu entre les deux graphes.
Le rapport de réconciliation mesure aussi la couverture des clés étrangères, le taux d’orphelins avant et après transformation, ainsi que les relations réattribuées à une identité différente. Toute variation non expliquée bloque la promotion du lot, même lorsque le nombre total de lignes reste identique.
Préparer la dé-fusion et la réparation des relations
Une fausse fusion sera un jour découverte. La réversibilité exige de connaître l’origine de chaque attribut et relation, ainsi que les effets produits depuis la fusion. Restaurer deux lignes ne suffit pas si des factures ou droits ont été recalculés.
Tester un scénario de séparation avant la bascule
Le runbook identifie cluster, décision, objets affectés, écritures postérieures et consommateurs. Il crée deux nouvelles identités, réattribue les éléments prouvés, isole les ambiguïtés puis réconcilie les soldes et accès.
L’opération possède approbation, dry-run, sauvegarde et rollback. Le monitoring vérifie files, caches, index de recherche et intégrations qui auraient propagé l’ancien identifiant.
Contre-intuitivement, prévoir la dé-fusion améliore la règle initiale : l’équipe découvre les dépendances cachées et évite d’automatiser une décision dont elle serait incapable de réparer l’impact.
La recette automatise au minimum une fusion, une reprise après panne et une séparation complète. Elle vérifie base SQL, cache, index de recherche, files asynchrones et exports, avec un rollback reproductible si une dépendance conserve encore l’ancien pivot.
Erreurs fréquentes qui créent une identité fausse
Fusionner sur email, téléphone ou adresse unique confond réutilisation et identité. Appliquer une transitivité automatique transforme un contact partagé en cluster géant. Optimiser seulement le rappel sacrifie les homonymes.
Éliminer les décisions impossibles à expliquer
Un score sans contributions, un seuil sans corpus annoté et une fusion sans version rendent la recette invérifiable. Une correction directe dans la cible détruit la capacité à rejouer le pipeline.
Autre erreur : choisir un survivant global. La meilleure fiche administrative n’est pas nécessairement la meilleure source de contact ou de consentement. Les règles s’écrivent par attribut et par processus.
Enfin, masquer les ambiguïtés sous une valeur « client principal » ne résout rien. Elles doivent rester visibles, attribuées et compatibles avec une migration partielle ou un accès historique contrôlé.
Cas concret : homonymes, foyer commun et groupe de sociétés
Une entreprise de services possède deux clients homonymes à la même adresse familiale, plus trois sociétés dont le dirigeant et le standard sont communs. L’ancienne règle fusionne les personnes sur nom-adresse et les sociétés sur téléphone.
Remplacer deux fusions par des identités et relations prouvées
Les personnes restent séparées grâce à leurs références contractuelles et dates de naissance. Une relation de foyer explique l’adresse. Les sociétés conservent leurs identifiants légaux et établissements, puis sont reliées au même groupe et au même contact.
Le corpus de recette inclut les cinq entités et leurs cas voisins. Le pipeline migre contrats et factures vers le bon titulaire, conserve le standard comme coordonnée partagée et bloque une ancienne pièce impossible à attribuer.
Après trois répétitions, aucune fausse fusion n’est trouvée sur 12 000 paires annotées et 99,4 % des doublons certains sont résolus. Le reliquat passe en revue avant le go plutôt que baisser le seuil.
Plan d’action pour résoudre les identités en six semaines
Le plan commence sur une entité à fort impact et un périmètre représentatif. Il sépare découverte, calibration et intégration afin qu’un score prometteur ne soit jamais confondu avec une migration sûre.
Semaines 1 à 3 : frontières, preuves et candidats
La première revue confronte les définitions de personne, compte, foyer et organisation aux décisions réellement prises dans l’application. Tout attribut susceptible d’ouvrir un droit ou de déplacer un contrat est classé comme preuve critique et non comme simple indice de similarité.
- Semaine 1 : définir personnes, organisations, établissements, comptes et relations, puis inventorier droits, contrats et conséquences d’une fausse fusion.
- Semaine 2 : profiler identifiants et coordonnées, versionner normalisations, établir preuves positives et négatives puis constituer un corpus de paires annotées.
- Semaine 3 : implémenter règles déterministes, passes de blocage et graphe de candidats, avec métriques de couverture, collisions et clusters anormaux.
Semaines 4 à 6 : décision, survivance et réversibilité
La seconde revue mesure séparément faux rapprochements et identités manquées sur les populations à risque. Le comité documente la zone d’abstention, la capacité quotidienne de revue humaine et le délai maximal pour défaire une fusion déjà propagée.
- Semaine 4 : calibrer score et zones de décision par population, faire revoir les ambiguïtés et refuser l’automatisation lorsque la précision reste sous le seuil signé.
- Semaine 5 : construire golden records, provenance et rattachement des relations, puis réconcilier droits, soldes, documents et anciens identifiants.
- Semaine 6 : exécuter une cohorte, provoquer une fausse fusion, tester dé-fusion et rollback, puis décider l’extension selon précision et capacité de réparation.
La sortie exige frontières validées, précision mesurée, aucune contradiction silencieuse, provenance complète et séparation testée. Le pourcentage de fiches supprimées ne constitue jamais une preuve.
Guides complémentaires : profilage, usine et bascule
La résolution dépend de données profilées, d’un pipeline répétable et d’une réconciliation capable de vérifier les relations après chargement. Ces ressources replacent l’identité dans la trajectoire complète.
Relier diagnostic, transformation et décision de go
Le profilage avant migration révèle domaines, identifiants et orphelins. L’usine de migration versionne transformations, répétitions et réconciliation.
La méthode de reprise d’un logiciel métier cadre la bascule, tandis que la parité fonctionnelle choisie évite de transporter les anciennes conventions d’identité sans les questionner.
Conclusion : une fusion doit rester prouvable et réversible
Deux enregistrements semblables ne deviennent une seule entité que si leurs preuves, leur type et leur histoire sont compatibles. Les foyers, groupes et contacts partagés doivent être reliés, pas aplatis.
Une résolution fiable commence par les cas déterministes, calibre les ressemblances sur des paires réelles, conserve les contradictions et construit le golden record sans effacer sa provenance.
Pour sécuriser ce chantier, notre accompagnement en développement web sur mesure relie modèle cible, données, tests, QA et bascule afin que chaque identité migrée reste explicable, réconciliable et réparable.
