Rapprochement de fichiers B2B : traiter les correspondances ambiguës sans écraser ses données

Le croisement de deux bases de données B2B constitue une étape sensible lors de la préparation d'un fichier de prospection ou de la mise à jour d'un outil de gestion commerciale. Une mauvaise approche du rapprochement provoque fréquemment des fusions destructrices, la disparition de numéros d'appels directs ou l'écrasement accidentel de l'historique commercial d'un compte client.

Lorsqu'un algorithme compare deux tables de données, la correspondance entre deux lignes n'est pas toujours évidente. À côté des concordances parfaites et des rejets indiscutables existe une zone intermédiaire complexe. Cette catégorie regroupe les correspondances ambiguës, qui présentent des indices contradictoires ou partiels. Traiter ces anomalies exige d'abandonner les fusions automatiques forcées pour structurer un tri en trois flux distincts : les paires confirmées, les enregistrements inédits et la file de contrôle manuel.

Les clés exactes disponibles pour le rapprochement B2B

Une clé exacte repose sur un identifiant invariant garantissant qu'une ligne de la table source désigne rigoureusement la même entité juridique ou technique qu'une ligne de la table cible. En France, le répertoire légal met à disposition des professionnels des identifiants normalisés.

Le numéro SIREN identifie chaque entreprise par une séquence invariable de neuf chiffres. Comme l'indique la documentation de l'Insee sur le numéro Siren, ce matricule n'encode aucune information descriptive sur les activités de l'unité légale et identifie l’unité légale, personne physique ou morale, et n’est pas réutilisé après sa disparition. Il permet un rattachement à cette unité, sans identifier un siège ou un groupe économique.

Dès qu'une opération commerciale requiert une localisation géographique précise ou la gestion d'un réseau commercial multi-sites, l'utilisation du SIRET devient incontournable. Selon les spécifications publiées par l'Insee sur le numéro Siret, cet identifiant à quatorze chiffres associe le numéro SIREN au numéro interne de classement (NIC) propre à chaque établissement actif ou fermé. Rapprocher deux tables au niveau SIREN alors que le fichier source répertorie des adresses locales distinctes expose à une agglomération erronée de plusieurs implantations sous une même fiche d'établissement.

Dans les applications de relation client, les clés administratives sont parfois absentes des formulaires en ligne ou des fiches de contact. Les plateformes logicielles utilisent donc des identifiants techniques spécifiques. Par exemple, la documentation technique sur la déduplication de fiches HubSpot explique que le système s'appuie nativement sur l'adresse email pour les contacts individuels et sur le nom de domaine internet pour les fiches d'entreprises. Cette même documentation précise que sans identifiant unique, chaque nouvelle ligne peut générer un enregistrement autonome lors d'un import de masse, et que les créations d'entreprises via certaines interfaces de programmation (API) ne bénéficient pas d'une déduplication automatique sur le nom de domaine.

Les indices complémentaires et la normalisation préalable

Lorsque les fichiers à croiser ne partagent aucun identifiant unique universel, le rapprochement s'effectue à l'aide d'un faisceau d'indices textuels. Ces champs exigent une standardisation stricte avant toute tentative de calcul de similarité, car de simples écarts typographiques faussent les algorithmes de détection.

La raison sociale d'une entreprise subit fréquemment des variations selon les opérateurs de saisie. Préparer ce champ nécessite d'appliquer une chaîne de nettoyage invariable : conversion de l'intégralité du texte en lettres minuscules, suppression des accents et des caractères diacritiques, retrait de la ponctuation usuelle, puis élimination systématique des mentions de structure juridique telles que SARL, SAS, SASU, SA, SCI ou EURL. L'abréviation des termes génériques comme « Société » ou « Compagnie » doit être uniformisée.

L'adresse géographique constitue un second niveau de filtrage déterminant. Le code postal et la commune fournissent une assise territoriale solide pour discriminer deux homonymes. Une concordance de nom patronymique ou commercial constatée dans deux départements éloignés n'a généralement pas la même signification qu'une ressemblance textuelle partagée au sein d'une commune de faible superficie. Il convient cependant d'isoler les codes postaux spéciaux de type cedex pour les ramener au code postal géographique standard avant toute jointure spatiale.

Le nom de domaine associé au site web de l'organisation constitue un marqueur discriminant remarquable pour corroborer une raison sociale. Toutefois, son interprétation demande des précautions : plusieurs filiales opérationnelles d'un même groupe peuvent partager la même vitrine numérique institutionnelle, tandis qu'une entité peut posséder plusieurs noms de domaine secondaires redirigeant vers un site principal.

Isoler les cas ambigus selon trois statuts d'appariement

Une politique de gestion des données saine refuse la décision binaire automatique lorsqu'un seuil de ressemblance n'est pas pleinement atteint. Tout processus de croisement doit orienter les données vers trois catégories hermétiques :

• Correspondance certaine : concordance stricte d'un identifiant légal invariant (SIREN pour le siège, SIRET pour l'établissement local) ou alignement conjoint d'une raison sociale normalisée et d'une adresse géographique vérifiée.
• Absence de correspondance : aucun indice commun suffisant, aucun identifiant partagé, score de ressemblance nominale inférieur au seuil de vigilance technique.
• Candidat ambigu : indices contradictoires, tels qu'un nom de domaine identique associé à des adresses postales situées dans des départements distincts, ou une raison sociale quasi similaire implantée dans la même localité avec des codes d'activité économique divergents.

L'évaluation des candidats ambigus mobilise généralement une fonction de distance textuelle, telle que la distance de Levenshtein ou l'indice de Jaro-Winkler. Lorsqu'une comparaison textuelle produit un résultat intermédiaire, la ligne ne doit être ni rejetée ni fusionnée sans contrôle humain. L'enregistrement est extrait vers une file de revue spécifique sous le statut de candidat ambigu.

Exemple illustratif : arbitrer deux entreprises fictives proches

Pour illustrer ce mécanisme d'arbitrage sans ambiguïté, prenons un exemple délibérément fictif. Un fichier prospect externe comportant deux lignes doit être rapproché de la base installée d'un CRM d'entreprise sans identifiant SIRET préalablement renseigné.

Dans ce scénario fictif, la première ligne source « Transports Martin Express SAS » partage le nom de domaine de la fiche interne A, mais possède une raison sociale légèrement plus longue et une domiciliation dans le 7e arrondissement de Lyon alors que la fiche interne A est répertoriée dans le 3e arrondissement. L'algorithme automatique ne peut affirmer s'il s'agit d'un déménagement récent du siège, d'un établissement secondaire ou d'une société sœur partageant l'infrastructure informatique.

Concernant la seconde ligne source « Martin Express Logistique », la commune de Saint-Étienne est partagée avec la fiche interne B, avec un ordre de mots inversé dans la raison sociale et un nom de domaine distinct. Forcer une fusion automatique écraserait potentiellement les coordonnées de deux entreprises juridiquement indépendantes. Les orienter vers la file d'arbitrage évite ce risque irréversible.

Décider sans écraser la source : structuration de la table d'arbitrage

Le traitement des cas ambigus ne s'effectue jamais directement dans les tables opérationnelles de production. L'opérateur exporte les candidats vers un classeur de travail autonome conçu pour conserver l'historique intégral de chaque version.

Pour maintenir une traçabilité parfaite et permettre une réinjection automatisée post-arbitrage, la table de revue doit afficher en vis-à-vis les colonnes sources et cibles ainsi que les métadonnées de décision :

• id_source : identifiant technique de la ligne dans le fichier d'origine.
• id_crm_cible : identifiant technique invariant généré par le CRM de destination.
• score_similarite : valeur numérique traduisant le niveau d'affinité textuelle calculé.
• statut_decision : menu fermé contenant obligatoirement les choix « Valider fusion », « Rejeter et créer nouveau », « Ignorer la ligne ».
• regle_enrichissement : directive technique précisant si la mise à jour complète uniquement les cellules vides ou si elle met à jour certains champs validés manuellement.
• motif_operateur : note d'audit concise explicitant la justification de la décision retenue (par exemple : vérification du SIREN au greffe ou confirmation d'un site secondaire).

Cette rigueur empêche qu'un collaborateur ne modifie une cellule sans justification traçable. Si l'arbitrage conclut qu'il s'agit de deux structures juridiques indépendantes, la ligne source est versée au flux d'insertion d'une nouvelle fiche CRM, sans toucher à la fiche cible existante. Si l'arbitrage valide l'identité commune, l'import utilise l'identifiant interne du CRM pour rattacher les attributs enrichis sans dupliquer l'enregistrement principal.

Sécuriser les flux d'intégration dans le système CRM

Une fois les décisions d'arbitrage validées dans le classeur de contrôle, l'intégration technique s'organise en deux phases séquentielles strictes afin de prévenir les erreurs de chargement.

La première phase traite les créations pures. Les enregistrements sans équivalence et les candidats ambigus dont la fusion a été rejetée font l'objet d'un import de création. Aucun identifiant CRM préexistant n'est envoyé lors de cette opération. L'outil génère ainsi de nouvelles fiches propres sans risque d'altérer les entités déjà enregistrées.

La seconde phase applique les mises à jour sur les fiches validées. Dans ce mode opératoire, l’identifiant interne du CRM (Record ID) est utilisé pour les mises à jour. D’autres clés uniques peuvent être admises selon l’objet, le logiciel et son paramétrage. Pour empêcher l'effacement de données précieuses, la règle de chargement doit interdire le remplacement d'un champ déjà renseigné par une cellule vide provenant du fichier importé. Seuls les champs historiquement vacants reçoivent les nouvelles valeurs validées lors de l'arbitrage.

Déléguer la fiabilisation de ses bases de prospection

La conception d'algorithmes de déduplication, la standardisation d'adresses hétérogènes et le traitement manuel de volumes conséquents de données ambiguës mobilisent des compétences techniques pointues et un temps considérable au détriment des actions de vente directes.

Pour sécuriser vos migrations de données, vos intégrations de fichiers d'enrichissement ou la refonte de votre référentiel clients, faire appel à une structure spécialisée permet de mettre en place des contrôles et sauvegardes adaptés à la préservation de votre capital informationnel. Composée de sept experts de la donnée B2B, l'équipe de La Fabrique B2B réalise des travaux d'enrichissement sur mesure, de déduplication complexe et de restructuration technique de fichiers, proposés sur devis personnalisé selon les spécificités de votre environnement informatique.