Rapprochement homonymique : retrouver et dédoublonner ses clients

Un client se réinscrit, son ancien contrat reste introuvable

Une entreprise possède des centaines de milliers, voire des millions de fiches clients. Un ancien client revient et crée un compte avec une autre adresse email, un prénom abrégé ou son nom d’usage. L’inscription aboutit, mais son ancien contrat reste rattaché à une autre fiche. Le service client voit deux dossiers et doit reconstituer leur lien.

Le rapprochement homonymique recherche les fiches susceptibles de désigner une même personne, même lorsque leurs informations ne correspondent pas exactement. Il combine les ressemblances entre plusieurs champs, par exemple le nom, les prénoms, la date et le lieu de naissance ou les coordonnées, pour proposer des candidats à vérifier. On parle aussi de rapprochement d’identités ou de record linkage.

J’ai développé en Java un algorithme de rapprochement d’utilisateurs chez Crédit Logement, de son prototype à son industrialisation, pendant mon CDI chez Coreoz. Ce sujet concerne bien d’autres bases clients. Je présente ici les difficultés qu’il faut traiter et une démarche pour les aborder. Les exemples sont fictifs ; les règles et outils décrits ne constituent pas une description de l’implémentation interne de Crédit Logement.

Pourquoi le nom, le prénom et l’email ne suffisent pas

Une première règle consiste à chercher une égalité sur plusieurs informations brutes : nom, prénom, email, téléphone, date de naissance (DDN) ou ville de naissance. C’est une base utile pour les cas où les données sont identiques. Mais exiger que tous ces champs correspondent écarte aussi des clients dont les informations ont changé ou ont été saisies autrement.

• Nom de naissance et nom d’usage : une cliente peut avoir souscrit sous son nom de naissance, puis revenir avec un nom marital. Comparer uniquement le nom courant manque le lien avec l’ancien dossier.
• Plusieurs prénoms : Jean Marie Yves MARTIN peut apparaître comme Jean MARTIN ou Marie MARTIN. Un prénom présent dans une liste est un indice à recouper avec les autres champs.
• Noms et prénoms composés : Jean-Marie, Jean Marie et Jean–Marie peuvent différer par les espaces ou le caractère utilisé pour le tiret. Leur ressemblance mérite d’être examinée sans perdre la forme d’origine.
• Accents et casse : Élodie LE LOUËT et Elodie Le Louet peuvent représenter la même saisie sous des formes différentes.
• Fautes d’orthographe : MARTIN et MARTNI peuvent venir d’une inversion de lettres. Deux noms proches peuvent aussi appartenir à des personnes différentes.
• Plusieurs noms de famille : une personne enregistrée comme GARCIA MARTIN peut utiliser un seul de ses noms lors d’une autre inscription. Réduire systématiquement tous les noms à leur premier élément fait perdre cette information.

Un email peut changer, un téléphone être partagé au sein d’un foyer ou réattribué. À l’inverse, deux homonymes peuvent partager une date et une ville de naissance. Une correspondance exacte apporte un indice dont la force dépend du contexte, de sa fiabilité et de son ancienneté.

Normaliser les valeurs tout en conservant les originaux

La préparation conserve la valeur reçue et construit, à côté, des formes destinées à la comparaison. Elle harmonise la casse, les espaces et certaines ponctuations, puis produit une variante sans accents. Les noms affichés et les données de référence gardent leur orthographe. Le W3C rappelle combien la structure des noms varie selon les personnes et les cultures : une règle de découpage unique risque d’introduire ses propres erreurs.

Pour des prénoms multiples, comparer la séquence complète et ses éléments permet d’identifier un recouvrement partiel. Il faut conserver la distinction entre un prénom composé et plusieurs prénoms lorsque la source la fournit. Le même principe s’applique aux noms de naissance, d’usage et aux anciens noms connus. Retrouver deux noms totalement différents nécessite une information qui les relie ou d’autres indices concordants ; supprimer les accents ne résout pas ce cas.

Les autres champs demandent leurs propres règles. Un téléphone doit être interprété avec son pays ; une date doit avoir un format non ambigu. Une ville de naissance peut être rapprochée d’un référentiel avec son pays, si ces données sont disponibles. Pour l’email, éviter d’effacer globalement les points ou les suffixes : leur signification dépend du fournisseur. Une valeur absente doit rester distincte d’une valeur différente, et deux champs vides n’apportent aucune preuve d’identité.

Comment constituer un dataset de comparaison fiable ?

Un dataset de comparaison est un jeu de paires de fiches dont la relation a été examinée. Chaque paire associe les données comparées à une décision de référence, avec son motif, sa source et sa date de validation. Cette référence permet de vérifier les résultats de l’algorithme. Un ancien rapprochement automatique ne devient pas une vérité de référence sans contrôle.

La sélection couvre les sources et les parcours qui alimentent réellement la base : inscriptions récentes, anciens contrats, imports ou saisies du service client. Elle comprend des noms fréquents, des noms et prénoms multiples, des changements de nom, des fautes et des champs absents. Les données utilisées restent limitées aux informations nécessaires à la comparaison, dans un environnement dont les accès sont maîtrisés.

• Même personne : des doublons confirmés, y compris lorsque les noms ou les coordonnées diffèrent. Ils servent à vérifier que le rapprochement retrouve les variantes attendues.
• Personnes différentes : des paires faciles à distinguer, mais aussi des homonymes ou des membres d’un foyer qui partagent certaines coordonnées. Ces cas proches mettent les faux positifs à l’épreuve.
• Indécidable : des paires pour lesquelles les éléments disponibles ne permettent pas de conclure. Elles restent identifiées comme telles et ne sont pas forcées dans une des deux autres classes pour calculer un taux de réussite.

La validation métier s’appuie sur les éléments disponibles, sans prendre le score de l’algorithme comme preuve. Les consignes d’annotation précisent ce qui justifie chaque décision et la façon de résoudre un désaccord. Une seconde lecture des cas ambigus aide à repérer les interprétations différentes. La documentation de Splink décrit l’évaluation à partir de paires étiquetées et rappelle que la représentativité de l’échantillon conditionne celle des mesures.

Des variantes synthétiques complètent les cas confirmés : suppression d’un accent, inversion de lettres ou retrait d’un prénom. Leur origine reste traçable. Elles vérifient des comportements précis, mais ne reproduisent pas à elles seules la diversité des erreurs de production. Les cas difficiles peuvent aussi être surreprésentés dans un jeu de régression ; ses résultats restent distincts des estimations obtenues sur un échantillon représentatif du trafic réel.

Le jeu de réglage sert à ajuster les règles et les seuils. Un lot d’évaluation reste réservé au contrôle des résultats. Lorsque l’identité de référence est connue, toutes les fiches et variantes d’une même personne restent dans un seul lot, puis les paires sont formées à l’intérieur de chaque lot. Cela évite de retrouver la même identité des deux côtés et de surestimer la capacité à traiter de nouveaux cas. Les recommandations de scikit-learn sur les groupes et les fuites de données expliquent ce principe, également utile pour des règles ajustées manuellement.

La version du dataset accompagne celle des règles : cas ajoutés, annotations corrigées et répartition des lots restent traçables. Un ajout issu d’une erreur de production enrichit le jeu de régression. Dès qu’un lot d’évaluation sert à corriger les règles, il ne constitue plus un contrôle indépendant de ces corrections ; un nouveau lot réservé permet de les évaluer.

Comment calculer un score de similarité sur plusieurs champs ?

Le calcul compare les champs séparément avant de combiner les indices. Pour un nom, on peut distinguer égalité complète, égalité après normalisation, recouvrement partiel et proximité orthographique. Un prénom partiellement retrouvé apporte une autre information. Une date de naissance identique peut renforcer le candidat, tandis qu’une date différente et vérifiée constitue une contradiction à examiner.

Les trigrammes, fragments de trois caractères, constituent une possibilité pour mesurer la proximité de textes. PostgreSQL propose cette approche dans pg_trgm, avec des index pour les recherches de similarité. Ce type d’outil aide à retrouver des orthographes proches ; il ne suffit pas à reconnaître une personne ni à gérer seul les changements de nom.

La combinaison peut reposer sur des règles pondérées ou sur un modèle probabiliste. Un accord sur une valeur très fréquente est généralement moins discriminant qu’un accord rare. Les champs liés entre eux demandent aussi de la prudence : un email construit à partir du nom ne fournit pas forcément une preuve indépendante. Splink documente une approche où chaque niveau de comparaison apporte un poids favorable ou défavorable au rapprochement.

Un score de similarité de 0,92 ne signifie pas automatiquement 92 % de chances qu’il s’agisse de la même personne. Une probabilité issue d’un modèle doit elle aussi être évaluée sur les données concernées. Les poids et les seuils se choisissent avec un jeu de cas validés, les erreurs observées et le coût métier d’une mauvaise décision. Un pourcentage affiché sans cette explication donne une assurance trompeuse.

Un exemple : Jean MARTIN correspond-il à l’ancien dossier ?

Prenons une situation fictive. Le dossier A porte Jean Marie Yves MARTIN, une date et une ville de naissance, ainsi qu’un ancien email. Le nouveau compte B porte Jean MARTIN, les mêmes informations de naissance et un email différent. Le système retrouve le nom et un des prénoms ; les données de naissance renforcent la candidature. Le changement d’email peut être cohérent avec le temps écoulé.

Un dossier C porte aussi Jean MARTIN, mais sa date de naissance vérifiée est différente. Une comparaison limitée au nom et au prénom risque de privilégier C parce que son prénom correspond exactement. La comparaison de plusieurs champs rend la contradiction visible. Si la date de B est absente, cette absence n’a ni la force d’un accord ni celle d’un désaccord.

Le résultat utile indique les raisons de la proposition : nom identique, prénom partiel, naissance concordante, coordonnées différentes. S’il reste plusieurs candidats plausibles, le système conserve cette ambiguïté. Choisir mécaniquement le premier résultat trié fait disparaître une information nécessaire à la décision.

Comment rechercher dans une base de plusieurs millions de clients ?

Comparer chaque paire d’une base d’un million de fiches représente 499 999 500 000 comparaisons, avant même de calculer les ressemblances. Pour une nouvelle inscription, un parcours complet de la base à chaque requête pose un autre problème de coût et de latence. Il faut d’abord sélectionner un ensemble de candidats, puis appliquer la comparaison détaillée.

Cette sélection, souvent appelée blocking, peut cumuler plusieurs chemins : coordonnées identiques, date de naissance associée à un élément du nom, ou recherche indexée sur des variantes de nom avec un autre champ. Réunir les résultats de plusieurs chemins évite de faire dépendre toute la recherche d’un seul champ potentiellement erroné. La documentation de Splink explique ce compromis entre volume de comparaisons et capacité à retrouver les vrais liens.

Un candidat écarté à ce stade échappe au calcul du score. La sélection des candidats et leur classement s’évaluent donc séparément, avec une attention aux blocs très volumineux formés par des noms fréquents. Préparer les formes normalisées et utiliser des index adaptés peut réduire le travail ; le temps de réponse se mesure sur la base, l’infrastructure et les volumes réels.

Retrouver un ancien contrat ne donne pas le droit d’y accéder

La recherche produit une hypothèse de correspondance. Lors d’une inscription, le rattachement d’un contrat et l’accès à ses documents demandent une vérification adaptée. Une personne connaissant le nom et la date de naissance d’un tiers ne doit pas pouvoir récupérer son dossier grâce à un score élevé. Le contrôle d’identité et les droits d’accès constituent des étapes distinctes.

Selon le contexte, le parcours oriente vers une récupération de compte, une vérification par un canal déjà établi ou une intervention habilitée du service client. Le choix des informations visibles avant cette vérification demande aussi de l’attention : afficher le détail des candidats expose leurs données personnelles. Le niveau de contrôle dépend des informations et des opérations accessibles après le rattachement.

Dédoublonner la base existante demande un traitement dédié

Mettre en place le rapprochement à l’inscription limite la création de nouveaux doublons. Les fiches déjà accumulées restent à traiter. Le dédoublonnage historique reprend la préparation des données et la recherche de candidats, cette fois sur l’ensemble du stock. Il produit des propositions à examiner avant toute modification des comptes.

Les doublons peuvent former des groupes de plusieurs fiches. Attention à la transitivité : A ressemble à B et B ressemble à C ne prouve pas que A et C désignent la même personne. Un email de foyer partagé peut créer un pont entre deux personnes différentes. Chaque groupe demande une vérification des accords et des contradictions avant d’être considéré comme une identité unique.

Un premier passage sans fusion produit les propositions, avec la version des règles, leurs raisons et une estimation de la charge de revue. Le traitement reprend par lots et tient compte des fiches modifiées entre l’analyse et la décision. Les refus de rapprochement déjà validés restent conservés, avec une possibilité de réexamen si de nouvelles informations apparaissent.

Quel compte conserver lors du dédoublonnage ?

Une fois le doublon confirmé, il reste à définir le compte de référence. Garder le plus ancien préserve une continuité d’identifiant. Garder celui qui porte le plus de contrats peut limiter certains déplacements de références. Privilégier le plus complet conserve davantage de champs, mais leur quantité ne prouve pas leur exactitude. Ces critères doivent être arbitrés avec les responsables métier et les applications concernées.

Choisir A comme compte conservé ne signifie pas garder toutes les valeurs de A. La règle doit préciser, champ par champ, ce qui est repris : une adresse récemment confirmée, un nom issu d’une source de référence, un téléphone encore valide. Lorsque deux informations fiables se contredisent, la fusion peut nécessiter une vérification supplémentaire. Une absence de valeur ne doit pas écraser une information fiable.

Certains objets ont besoin de règles spécifiques. Des consentements ou des préférences de communication ne se combinent pas par un simple “oui” prioritaire. Les identifiants de connexion et les moyens d’authentification demandent aussi un traitement explicite. Une proposition de fusion doit montrer ces choix avant exécution, avec la possibilité de la refuser ou de la reporter.

Une interface de comparaison pour décider de fusionner A dans B

Lorsque les cas ambigus sont fréquents, une interface métier permet de comparer les fiches côte à côte. L’opérateur voit les données d’origine, les différences et les indices qui ont conduit au rapprochement. Pour un groupe de plusieurs comptes, il faut rendre visibles tous les membres et leurs contradictions, sans masquer une fiche derrière une comparaison deux à deux.

• Afficher les identifiants, les noms et prénoms complets, les coordonnées et les informations de naissance utiles à la décision, selon les habilitations de l’opérateur.
• Préciser la source et la date de vérification des données lorsqu’elles sont disponibles, ainsi que les contrats et historiques rattachés.
• Expliquer le score par champ et signaler les désaccords, les données manquantes et les autres candidats possibles.
• Proposer “Personnes différentes”, “À vérifier” et la confirmation du doublon, puis le choix du compte conservé et des valeurs reprises.
• Prévisualiser le résultat : fusionner A dans B conserve B comme référence et réoriente les liens de A selon les règles convenues ; fusionner B dans A conserve A.

L’opérateur comprend la décision proposée sans recalculer mentalement toutes les règles. Un motif, l’auteur et la date de validation permettent ensuite de retrouver l’origine de la fusion. Pour une opération sensible, une seconde validation peut être justifiée par son impact. Le report d’un dossier reste possible lorsque les éléments disponibles ne permettent pas de trancher.

La fusion doit rester cohérente dans tout le système d’information

Un identifiant client peut être utilisé par le CRM, les contrats, la facturation, le support, les exports ou des partenaires. Supprimer une ligne en base sans traiter ces références peut laisser des objets orphelins et des systèmes qui continuent à écrire sous l’ancien identifiant. Il faut inventorier les dépendances et définir la résolution des anciens identifiants vers le compte conservé.

La fusion des fiches client n’implique pas celle des contrats : une même personne peut légitimement en posséder plusieurs. Les documents, paiements et événements historiques doivent garder leur provenance. Une table de correspondance entre anciens identifiants et identifiant de référence peut aider à préserver ces liens, sous réserve que les applications qui la consomment suivent la même règle.

Dans une seule base, une transaction peut regrouper les modifications compatibles. Entre plusieurs applications, il faut organiser leur propagation, les reprises après échec et les contrôles de cohérence. Une opération relancée ne doit pas déplacer deux fois un contrat ni réappliquer une fusion achevée. Une modification concurrente doit provoquer un nouveau contrôle plutôt qu’écraser silencieusement la fiche examinée.

La procédure de correction d’une fusion erronée se définit avant le premier lot. Conserver les valeurs antérieures et les liens déplacés aide à préparer cette correction. Le retour arrière peut devenir complexe après de nouvelles opérations ou des échanges externes ; une sauvegarde seule ne suffit pas à garantir une séparation automatique des comptes. La procédure se teste sur les dépendances réellement concernées.

Comment mesurer les faux positifs et les doublons manqués ?

Un faux positif rapproche deux personnes différentes ; un faux négatif laisse séparées deux fiches d’une même personne. L’ONS recommande d’évaluer la qualité par la précision et le rappel. La précision mesure la part de vrais liens parmi ceux proposés ; le rappel mesure la part des vrais liens retrouvés. Le nombre de rapprochements, pris seul, ne renseigne pas sur leur justesse.

Examiner uniquement les meilleurs scores surestime la qualité. Il faut aussi échantillonner les résultats refusés et les cas absents de la sélection de candidats ; sinon, on ignore une partie des doublons manqués. Sans connaissance exhaustive des vrais liens, le rappel reste une estimation sur un périmètre à documenter. Les erreurs et la charge de revue doivent être suivies par type de cas et par source de données.

Les seuils dépendent de la décision qui suit. Proposer une piste à un opérateur et fusionner automatiquement deux comptes n’ont pas le même coût en cas d’erreur. Une phase d’observation analyse les propositions sans modifier les données, avant la validation de lots limités. Les règles évoluent ensuite sur la base des erreurs constatées et d’une capacité de contrôle définie avec le métier.

Par où commencer un projet de rapprochement client ?

Le cadrage part d’un parcours précis, par exemple le client qui se réinscrit et ne retrouve pas son contrat. L’équipe métier réunit des cas connus, identifie les informations fiables et définit les vérifications nécessaires avant un rattachement. Ce premier périmètre permet de discuter des erreurs acceptables et des conséquences d’une fusion sur des dossiers concrets.

La première livraison peut être une liste de candidats expliqués, sans modification automatique. Elle permet de vérifier si les anciens dossiers sont retrouvés, combien de propositions restent ambiguës et ce qu’un opérateur doit voir pour décider. Avant d’activer les fusions, il reste à convenir des règles de conservation, à vérifier les références dans le SI et à essayer la procédure de correction d’une mauvaise fusion.

Sources et liens utiles

• Mon expérience de rapprochement homonymique chez Crédit Logement
• W3C : diversité des noms personnels et implications pour les formulaires et bases
• ONS : qualité du rapprochement, faux positifs, précision et rappel
• Splink : sélectionner les paires candidates avec plusieurs règles de blocking
• Splink : interpréter les poids de comparaison et les probabilités du modèle
• Splink : évaluer les rapprochements à partir de paires étiquetées
• scikit-learn : séparer les groupes entre réglage et évaluation
• PostgreSQL : similarité de textes et index avec pg_trgm
• Choisir des tests à partir des comportements coûteux à casser
• Reprendre un projet en comprenant ses usages et ses dépendances
• Discuter d’un rapprochement ou d’un dédoublonnage dans votre application