Dédoublonner une base clients avant migration avec l'IA

Dédoublonner une base clients avant une migration consiste à identifier les fiches qui décrivent la même entité sous des formes différentes, à décider laquelle doit survivre, puis à fusionner leurs historiques sans rien perdre. C'est une étape distincte de la migration elle-même : migrer d'abord et trier ensuite revient à recopier le problème dans un outil neuf, où il devient encore plus coûteux à corriger.

Toute base clients de PME accumule des doublons sur dix ou quinze ans d'activité : la même entreprise saisie avec trois raisons sociales différentes, avec ou sans sa forme juridique, avec une faute de frappe qui échappe à toute recherche exacte, une adresse écrite de trois façons, un contact personne physique et une fiche société qui désignent en réalité la même relation commerciale.

Cet article détaille la méthode pour traiter ces doublons avant de basculer vers un nouvel outil : d'où ils viennent, comment les détecter du plus simple au plus fin, ce que le SIRET et le SIREN apportent réellement, comment fusionner sans perdre l'historique, et comment éviter qu'ils reviennent une fois la migration terminée.

Pourquoi migrer les doublons est le pire choix possible

Face à une base clients ancienne, pleine de fiches redondantes, la tentation la plus fréquente est de migrer tel quel et de trier plus tard, une fois le nouvel outil en place. C'est presque toujours une mauvaise idée, pour trois raisons concrètes.

Les doublons se multiplient dans le nouvel outil au lieu de disparaître. Un nouvel outil s'accompagne souvent d'une nouvelle façon de saisir, de nouveaux champs, parfois de nouvelles personnes qui alimentent la base. Sans contrôle à la création, chaque doublon existant devient une source pour de nouveaux doublons, au lieu de rester un problème isolé et connu.

Ils faussent tout le reporting dès le premier mois. Un chiffre d'affaires par client, un nombre de clients actifs, un taux de rétention calculés sur une base pleine de doublons ne veulent rien dire. Personne ne s'en aperçoit tout de suite, ce qui est pire : la décision prise sur ce chiffre erroné, elle, est bien réelle.

Ils provoquent des relances en double et polluent toute synchronisation future. Un client relancé deux fois par deux commerciaux qui ignorent chacun l'existence de l'autre fiche perd confiance dans votre organisation. Et si ce nouvel outil doit un jour se synchroniser avec un autre logiciel, comme nous le détaillons dans notre article sur la synchronisation entre deux logiciels sans identifiant commun, chaque doublon existant complique le rapprochement au lieu de le simplifier.

La règle qui en découle est simple à énoncer, moins simple à appliquer sous la pression d'un calendrier de migration serré : le dédoublonnage se fait avant le basculement, jamais après. Notre article sur la méthode de migration de données pour PME situe cette étape dans l'ensemble du projet.

D'où viennent les doublons dans une base clients

Un doublon n'apparaît presque jamais par accident isolé. Il naît d'un mécanisme récurrent, et comprendre ce mécanisme aide à savoir où chercher avant même de lancer un outil de détection.

Plusieurs personnes qui saisissent sans se voir. Un commercial crée une fiche pour un prospect qu'il rencontre en salon. Trois semaines plus tard, un collègue crée la même fiche à partir d'un appel entrant, sans savoir qu'elle existe déjà. Aucun des deux n'a fait d'erreur : le système n'avait simplement pas de mémoire commune au moment de la création.

Les imports successifs. Chaque import de fichier Excel, chaque récupération d'un ancien logiciel, chaque campagne d'achat de fichiers ajoute son lot de fiches sans systématiquement vérifier ce qui existait déjà. Au bout de plusieurs imports étalés sur des années, la base ressemble à un empilement de couches géologiques plutôt qu'à un référentiel unique.

L'absence de contrôle à la création. Sans recherche préalable obligatoire avant d'enregistrer une nouvelle fiche, rien n'empêche techniquement de créer deux fois la même entité. C'est la cause racine derrière presque tous les autres mécanismes : un logiciel qui laisse créer sans vérifier fabrique des doublons par construction, indépendamment de la rigueur des personnes qui l'utilisent.

La fusion d'entités côté client. Un client rachète une autre société, change de raison sociale, ou fusionne deux établissements sous une seule structure juridique. Votre base, elle, continue de porter deux fiches distinctes pour une réalité qui n'en fait plus qu'une, jusqu'à ce que quelqu'un s'en aperçoise, souvent au moment d'une relance qui tombe mal.

Le même client présent dans plusieurs logiciels. Un client existe dans le CRM commercial et, séparément, dans le logiciel de facturation, chacun alimenté par une équipe différente à des moments différents. Ce n'est pas un doublon au sens strict d'un seul outil, mais le problème est identique au moment de fusionner les deux univers dans un même référentiel migré. Notre article sur la correspondance de champs entre deux logiciels traite ce cas de rapprochement inter-outils.

Détecter les doublons, du plus simple au plus fin

La détection se construit en couches. Chaque niveau capture une catégorie de doublons que le précédent laisse passer, et il est rarement utile de sauter directement au niveau le plus sophistiqué sans avoir traité les niveaux simples d'abord.

Normalisation préalable, avant tout rapprochement

Avant de comparer deux fiches, il faut les ramener à une forme comparable. Sans cette étape, même deux fiches parfaitement identiques dans les faits peuvent échapper à toute détection à cause d'une différence de forme.

• Casse et accents uniformisés (majuscules, minuscules, accents normalisés ou retirés selon la méthode).
• Formes juridiques isolées du nom (SARL, SAS, EURL, SA) pour comparer le cœur de la raison sociale indépendamment de son statut.
• Abréviations de voie harmonisées (avenue, av., av devenant une seule forme cible ; boulevard, bd suivant la même logique).
• Espaces, ponctuation et caractères parasites nettoyés (doubles espaces, tirets superflus, apostrophes de styles différents).

Cette étape ne détecte aucun doublon à elle seule. Elle prépare le terrain pour que les étapes suivantes comparent des données réellement comparables, plutôt que des variantes de forme qui masquent une identité de fond.

Correspondance exacte sur identifiants forts

Une fois les libellés normalisés, la détection la plus fiable reste la correspondance exacte sur un identifiant fort : SIRET, numéro de TVA intracommunautaire, email, ou téléphone. Deux fiches qui partagent le même SIRET sont, dans l'immense majorité des cas, la même entité.

Le problème, en pratique, c'est que ces identifiants forts sont rarement complets sur une base ancienne. Un email change, un numéro de téléphone se réattribue, et le SIRET, souvent facultatif à la création, est laissé vide par la moitié des commerciaux pressés. Cette limite conduit directement au niveau suivant.

Rapprochement flou et sémantique quand les libellés divergent

Quand les identifiants forts manquent, il reste la raison sociale, l'adresse et le nom du contact. Une distance de chaîne (par exemple de type Levenshtein ou Jaro-Winkler) repère les fautes de frappe et les variantes proches : "Dupont Bâtiment" et "Duppont Batiment" se ressemblent suffisamment pour être proposées comme doublons probables.

Un rapprochement multichamp pondéré combine plusieurs signaux à la fois, raison sociale, code postal, secteur d'activité, pour calculer un score de confiance global plutôt que de trancher sur un seul champ. Deux fiches peuvent avoir une raison sociale légèrement différente mais un score global très élevé une fois l'adresse et le secteur pris en compte ensemble.

Enfin, le rapprochement sémantique par embeddings intervient quand les libellés divergent complètement à l'écrit tout en désignant la même entité : "Sté Dupont Bâtiment" et "Groupe DB Construction" pour la même entreprise après un changement de nom commercial. Un modèle de langage capture cette proximité de sens là où une distance de chaîne échoue, parce qu'il n'y a presque aucune ressemblance de caractères entre les deux libellés.

Le rôle du SIREN et du SIRET dans la détection

En France, le SIREN identifie une entreprise et le SIRET identifie un établissement précis de cette entreprise. C'est, en théorie, l'identifiant le plus fiable pour rapprocher deux fiches qui désignent la même structure juridique, bien plus fiable qu'une raison sociale qui peut s'écrire de dix façons différentes.

En pratique, dans une base client de PME accumulée sur plusieurs années, ce champ est souvent le maillon faible plutôt que la solution évidente :

• Il est fréquemment absent. Le SIRET n'est pas toujours un champ obligatoire à la création, et beaucoup de fiches anciennes n'en portent tout simplement pas.
• Il est parfois mal saisi. Confusion entre SIREN (9 chiffres) et SIRET (14 chiffres), erreur de frappe sur un des chiffres, ou copie d'un ancien numéro devenu invalide après une fusion ou une cessation d'activité côté client.
• Il change quand l'établissement change. Un déménagement de siège ou l'ouverture d'un nouvel établissement génère un nouveau SIRET pour la même entreprise, ce qui peut créer un faux négatif si la comparaison se fait uniquement sur ce champ.

L'intérêt d'un enrichissement depuis la base Sirene de l'INSEE (répertoire officiel des entreprises et établissements français, disponible en open data sur le site de l'INSEE) est de retrouver un SIRET fiable à partir de la raison sociale et de l'adresse quand le champ est vide ou incertain dans votre base. Cet enrichissement complète la détection, il ne la remplace pas : une raison sociale mal orthographiée peut échouer à retrouver le bon établissement dans Sirene aussi bien que dans votre propre base, d'où l'intérêt de combiner cet enrichissement avec les techniques de rapprochement flou vues plus haut.

La fusion, l'étape dangereuse

Détecter un doublon est réversible : on peut toujours revoir une proposition avant de valider. Fusionner deux fiches, en revanche, est une opération qui touche à l'irréversible si elle n'est pas conçue avec précaution. C'est l'étape où un dédoublonnage bien pensé peut quand même causer plus de dégâts que le problème initial.

Quel enregistrement survit, quel champ on garde

Le réflexe le plus courant, garder systématiquement la fiche la plus récente, n'est pas toujours le bon choix. Une fiche créée récemment peut être moins complète qu'une ancienne fiche enrichie au fil des années par plusieurs commerciaux. La bonne pratique consiste à définir des règles de survivance par champ plutôt que par fiche entière : garder le SIRET de la fiche la plus ancienne et la plus stable, mais l'email et le nom du contact de la fiche la plus récemment mise à jour, par exemple.

Ce que l'on fait des historiques rattachés aux deux fiches

Chaque fiche doublon porte souvent son propre historique : factures, échanges commerciaux, tickets de support, opportunités en cours. La fusion doit rattacher l'intégralité de cet historique à la fiche qui survit, sans en perdre un seul élément au passage. C'est l'étape la plus souvent négligée par un dédoublonnage manuel ou mal outillé, et celle qui cause le plus de plaintes après coup : un client qui découvre que son historique de commandes a disparu perd confiance bien plus vite qu'il ne l'aurait perdue avec une fiche en double.

Pourquoi la fusion doit être journalisée et réversible

Une fusion automatique sans trace est un pari risqué. La bonne pratique consiste à conserver, pour chaque fusion réalisée, quelles fiches ont été combinées, quels champs ont été gardés de quelle source, et à quel moment. Cette journalisation permet de revenir en arrière si une fusion s'avère erronée, ce qui arrive, même avec un système bien réglé, sur une petite proportion des cas.

Une fois la base migrée, une vérification distincte reste nécessaire pour s'assurer que rien ne s'est perdu pendant l'opération elle-même : notre article sur les contrôles à effectuer après une migration de données détaille cette étape de validation post-migration, complémentaire du dédoublonnage.

Validation humaine, RGPD et empêcher le retour des doublons

La file d'arbitrage humain

Aucun système de détection, aussi bien réglé soit-il, ne doit fusionner seul les cas ambigus. La bonne pratique consiste à séparer les propositions en deux catégories : les rapprochements à très forte confiance, qui peuvent être fusionnés automatiquement selon des règles validées à l'avance, et les cas incertains, qui partent dans une file d'arbitrage soumise à une personne qui connaît la base.

Le dimensionnement de cette file dépend directement de la qualité de la base de départ : une base ancienne, alimentée par de nombreuses personnes sans contrôle, génère naturellement plus de cas ambigus qu'une base récente et disciplinée. Chaque décision prise dans cette file d'arbitrage doit, dans l'idéal, venir enrichir les règles de détection pour les prochains lots, plutôt que de rester une décision isolée sans effet sur la suite du traitement.

RGPD : une bonne occasion d'appliquer les durées de conservation

Le dédoublonnage n'est pas, en soi, une obligation issue du RGPD. Mais une migration de base clients est un moment naturel pour appliquer le principe de minimisation des données et les durées de conservation que votre entreprise s'est fixées : une fiche inactive depuis plusieurs années, sans contrat ni échange récent, mérite d'être archivée ou supprimée plutôt que recopiée telle quelle dans le nouvel outil. Le dédoublonnage et la revue de conservation avancent naturellement en parallèle, puisque tous deux consistent à examiner chaque fiche avant de la faire passer dans le nouveau système. Pour les cas sensibles, ce cadrage reste à valider avec un conseil juridique, notamment pour les durées de conservation propres à votre secteur. Notre article sur la sécurité des données et la checklist RGPD pour une PME couvre ce sujet plus largement.

Empêcher les doublons de revenir dans le nouvel outil

Un dédoublonnage réussi au moment de la migration ne vaut rien s'il n'est pas protégé dans la durée. Trois garde-fous simples évitent de reconstituer le même problème quelques mois plus tard :

• Contrôle à la création. Le nouvel outil doit chercher automatiquement les fiches proches avant de laisser valider une nouvelle fiche, sur les mêmes techniques que celles utilisées pour le dédoublonnage initial.
• Identifiant obligatoire quand il est disponible. Rendre le SIRET ou l'email obligatoire à la création, quand la nature du client le permet, réduit fortement le nombre de doublons créés par simple absence de vérification.
• Recherche avant saisie plutôt qu'après coup. La personne qui saisit doit voir apparaître les fiches proches avant de valider, pas découvrir le doublon des semaines plus tard lors d'un contrôle qualité.

C'est ce cadrage complet, détection, fusion sécurisée et garde-fous après migration, que nous mettons en place dans le cadre de notre offre de migration et reprise de données : diagnostiquer le niveau réel de doublonnage, choisir les techniques adaptées au volume et à la qualité des identifiants disponibles, puis livrer une base propre et protégée contre le retour du problème.

Quand la base contient aussi des champs libres et des commentaires non structurés hérités de l'ancien outil, leur reprise pose des questions différentes de celles du dédoublonnage : notre article sur la reprise d'historique et de champs libres avec l'IA traite ce cas spécifique.

Questions fréquentes sur le dédoublonnage d'une base clients avant migration

Pour aller plus loin

• Migrer les données d'un logiciel : méthode pour une PME : la démarche complète dans laquelle s'inscrit le dédoublonnage.
• Les contrôles à effectuer après une migration de données : vérifier que rien ne s'est perdu pendant la fusion et le transfert.
• Reprendre l'historique et les champs libres avec l'IA : le cas des commentaires et notes non structurés hérités de l'ancien outil.
• Correspondance de champs entre deux logiciels avec l'IA : rapprocher deux structures de données différentes avant de les fusionner.
• Rendre ses données prêtes pour l'IA en entreprise : la qualité de base qui conditionne tout projet d'IA ultérieur.