Synchroniser deux logiciels sans identifiant commun

Synchroniser deux logiciels sans identifiant commun consiste à remplacer l'égalité stricte, impossible faute de clé partagée, par un rapprochement par approximation noté d'un score de confiance. Ce score détermine trois zones : un rapprochement automatique au-dessus d'un premier seuil, un refus de rapprochement en dessous d'un second, et une validation humaine pour tout ce qui se trouve entre les deux. C'est la seule méthode qui évite à la fois de laisser passer des doublons et de fusionner par erreur deux clients ou deux produits distincts.

C'est aussi le cas le plus fréquent en PME. Un CRM et un ERP achetés à des années d'écart, un fournisseur dont les libellés produits ne ressemblent en rien à ceux de votre catalogue, une raison sociale écrite de trois façons différentes selon qui a saisi la fiche : dans la vraie vie, la clé unique et fiable qu'on souhaiterait avoir n'existe presque jamais. La créer après coup, en reprenant des milliers de fiches à la main, est un projet en soi qu'aucune équipe ne mène jusqu'au bout.

Cet article détaille les méthodes de rapprochement disponibles, du plus simple au plus coûteux, la manière de construire et de calibrer un score de confiance, comment dimensionner la file de validation humaine pour qu'elle ne devienne pas un second travail à plein temps, et comment rendre chaque rapprochement réversible pour se prémunir du vrai danger : le faux positif qui fusionne deux entités qui n'auraient jamais dû l'être.

Pourquoi la clé commune manque presque toujours entre deux logiciels

Sur le papier, rapprocher deux bases de données semble simple : il suffirait qu'un champ identique existe des deux côtés. En pratique, ce champ n'existe presque jamais, et ce n'est pas un oubli, c'est la conséquence logique de la façon dont les logiciels arrivent dans une PME.

Le CRM a été choisi par l'équipe commerciale il y a quelques années. L'ERP ou le logiciel de facturation a été acheté séparément, par une autre équipe, avec sa propre logique de numérotation. Personne n'a anticipé, au moment de l'achat, qu'il faudrait un jour faire dialoguer les deux : le sujet n'était tout simplement pas sur la table.

Trois raisons concrètes expliquent l'absence de clé fiable :

• Le code client d'un logiciel ne veut rien dire pour l'autre. Chaque outil génère ses propres identifiants internes, sans lien entre eux, sauf à avoir été explicitement mappés à l'installation.
• Le SIRET n'est pas toujours saisi, ni saisi correctement. Un champ facultatif à la création de fiche reste vide dans une part significative des cas, et un particulier ou une profession libérale n'en a tout simplement pas.
• La raison sociale se saisit de plusieurs façons. "Sté Dupont Bâtiment", "SARL DUPONT BAT" et "Dupont Bâtiment (ex-Dupont Frères)" désignent la même entreprise pour un humain, mais trois chaînes de caractères totalement différentes pour une base de données.

Le même problème existe côté produits : le libellé fournisseur d'une référence n'a souvent aucun mot commun avec la désignation utilisée dans votre catalogue ou votre ERP. "Profilé alu anodisé 40x40 L=3m" chez le fournisseur peut correspondre à "Tube carré aluminium 4cm" dans votre système, sans qu'aucune règle de correspondance exacte ne puisse les relier.

Face à ce constat, la tentation naturelle est de créer la clé manquante : ajouter un champ SIRET partout, imposer une nomenclature produit unique, reprendre l'historique fiche par fiche. C'est une bonne idée sur le principe, et un projet lourd dans les faits, souvent estimé à des dizaines d'heures de saisie manuelle sur une base de plusieurs milliers de lignes, sans garantie d'exhaustivité une fois terminé. C'est précisément ce que le rapprochement automatique par approximation permet d'éviter, ou du moins de réduire fortement.

Les méthodes de rapprochement, du plus simple au plus coûteux

Il n'existe pas une seule technique de rapprochement, mais une progression. Chaque méthode répond à un niveau de dissimilarité différent entre les deux libellés à comparer. Inutile de partir sur la plus sophistiquée si la plus simple suffit déjà à couvrir une bonne partie des cas.

La première étape, souvent négligée, consiste à normaliser les deux chaînes avant toute comparaison : mise en minuscules, suppression des accents et de la ponctuation, retrait des formes juridiques (SARL, SAS, Sté), suppression des espaces multiples. Une fois normalisés, "SARL DUPONT BAT." et "Sté Dupont Bat" deviennent identiques, et une simple égalité de chaînes les rapproche sans le moindre calcul complexe. Cette étape à elle seule résout souvent une part importante des cas dans une base par ailleurs raisonnablement propre. Elle ne suffit toutefois jamais seule : dès qu'une vraie variante orthographique ou un vocabulaire différent apparaît, il faut passer aux méthodes suivantes.

Distance de chaîne : Levenshtein et Jaro-Winkler

Quand la normalisation ne suffit pas, la comparaison passe par une mesure de similarité de chaîne. La distance de Levenshtein compte le nombre minimal d'opérations (ajout, suppression, substitution de caractère) pour transformer une chaîne en une autre : plus le nombre est faible, plus les deux textes se ressemblent. Elle capture bien les fautes de frappe et les petites variantes ("Dupond" contre "Dupont").

La distance de Jaro-Winkler fonctionne différemment : elle donne davantage de poids aux caractères communs situés en début de chaîne, ce qui la rend particulièrement adaptée aux noms propres et raisons sociales, où le début du nom porte le plus d'information distinctive. C'est souvent elle qui est privilégiée pour comparer des noms d'entreprise ou de personne.

Ces deux méthodes partagent une limite : elles raisonnent caractère par caractère. Elles ne comprennent rien au sens des mots, seulement à leur forme. "Immeuble" et "Bâtiment" leur paraissent totalement différents alors qu'un humain les jugerait proches dans un certain contexte.

Rapprochement multi-champs pondéré

Un seul champ, aussi bien traité soit-il, reste fragile. La méthode qui gagne en robustesse combine plusieurs signaux avec un poids différent pour chacun : par exemple 40 % pour la similarité du nom normalisé, 30 % pour la correspondance du code postal, 20 % pour un email ou un numéro de téléphone partiel, 10 % pour la ville. Le score final est une moyenne pondérée de ces similarités partielles.

Cette approche encaisse mieux les cas limites : une entreprise a déménagé, donc son adresse a changé, mais son nom et son SIRET partiel concordent toujours suffisamment pour maintenir un score de confiance élevé. C'est la méthode la plus utilisée en pratique pour un rapprochement de fiches clients ou fournisseurs, car elle ne repose jamais sur un seul champ jugé infaillible.

Rapprochement sémantique par embeddings

Quand deux libellés n'ont littéralement aucun mot en commun mais désignent la même réalité, comme l'exemple du profilé aluminium plus haut, aucune méthode lexicale ne peut les relier : il n'y a rien à comparer caractère par caractère. C'est le cas où le rapprochement par embeddings devient nécessaire.

Le principe : un modèle transforme chaque libellé en vecteur numérique qui représente son sens plutôt que sa forme. Deux textes au sens proche produisent des vecteurs proches dans cet espace, même sans un seul mot partagé. La proximité se mesure alors par une similarité cosinus entre les deux vecteurs. Nous détaillons le fonctionnement technique de cette méthode dans notre article sur les embeddings et la recherche sémantique en entreprise.

C'est la méthode la plus coûteuse en mise en œuvre (elle suppose de générer et stocker des vecteurs, et d'interroger une base vectorielle), et c'est aussi la seule qui fonctionne quand le vocabulaire diverge complètement entre les deux systèmes. Elle n'est pas la première brique à poser : elle vient compléter les méthodes lexicales sur les cas qu'elles ne couvrent pas.

Pour un cas voisin, celui où deux logiciels ont des schémas de champs différents plutôt que des libellés différents, notre article sur la correspondance de champs entre deux logiciels détaille comment faire correspondre les structures avant même de comparer les valeurs.

Construire un score de confiance et placer les deux seuils

Une fois la méthode de comparaison choisie, chaque paire candidate (une fiche de A, une fiche de B) obtient un score de confiance, en général entre 0 et 1 ou 0 et 100. Ce score seul ne sert à rien tant qu'on n'a pas décidé ce qu'on en fait. C'est le rôle des deux seuils.

Le seuil haut définit le score au-dessus duquel le rapprochement se fait automatiquement, sans intervention humaine. Il doit être fixé de façon prudente : mieux vaut laisser passer quelques rapprochements évidents en validation manuelle que d'automatiser un cas ambigu qui se révèle faux.

Le seuil bas définit le score en dessous duquel aucun rapprochement n'a lieu, jamais, même en suggestion. Sous ce seuil, les deux fiches sont considérées comme distinctes par défaut. Ce seuil protège contre le bruit : sans lui, le système finirait par proposer des centaines de paires sans aucun rapport réel, ce qui rendrait la validation humaine inutilisable.

Entre les deux se trouve la zone de doute, traitée dans la section suivante. Le calibrage exact de ces seuils dépend du coût respectif d'un faux positif et d'un faux négatif dans votre contexte : fusionner deux clients à tort coûte plus cher, en général, que laisser deux fiches doublonnées un peu plus longtemps.

La zone grise : dimensionner la file de validation humaine

Entre le seuil haut et le seuil bas se trouve la zone grise : les paires dont le score est trop incertain pour être tranché automatiquement dans un sens ou dans l'autre. Cette zone ne disparaît jamais complètement, mais elle doit rester gérable, sous peine de devenir un second travail à plein temps qui reproduit exactement le problème qu'on cherchait à résoudre.

Le dimensionnement se joue sur trois leviers :

• La largeur de l'écart entre les deux seuils. Plus l'écart est étroit, plus la zone grise est réduite, mais plus elle risque de laisser passer de vrais rapprochements dans la case "refusé" par excès de prudence. C'est un arbitrage à ajuster après observation des premiers résultats, pas à fixer arbitrairement au départ.
• La présentation des cas à valider. Une file de validation efficace montre les deux fiches côte à côte, avec les champs qui ont fait pencher le score en surbrillance, pas une liste brute d'identifiants illisibles. Une décision doit pouvoir se prendre en quelques secondes par cas.
• Le regroupement par lot. Traiter cinquante cas similaires (même type d'écart, même origine probable) d'un coup va plus vite que de les examiner un par un dans un ordre aléatoire.

Sur ce dernier point, la question de savoir qui valide, à quelle fréquence, et selon quelles règles de priorité, rejoint un sujet plus large que nous traitons en détail dans notre article sur où placer la validation humaine dans une automatisation. Le principe général s'applique ici sans exception : plus l'action est irréversible, comme la fusion de deux fiches clients, plus la validation humaine doit rester systématique sur les cas incertains, même si cela ralentit le traitement.

L'apprentissage : chaque arbitrage humain réduit la zone grise

Un rapprochement de données n'est pas un projet qu'on livre une fois puis qu'on oublie. Il s'améliore avec l'usage, à une condition précise : que chaque décision humaine soit enregistrée, pas seulement appliquée.

Concrètement, chaque fois qu'une personne confirme ou rejette un rapprochement proposé dans la zone grise, cette décision doit s'inscrire dans une table de correspondance persistante : "SARL DUPONT BAT" est bien la même entité que "Dupont Bâtiment (ex-Dupont Frères)", validée le tel jour par telle personne. La prochaine fois que ce même rapprochement se présente, il n'a plus besoin de repasser par la validation humaine : la règle est acquise.

C'est ce mécanisme, et non une amélioration automatique du modèle sous-jacent, qui fait diminuer la charge de validation au fil du temps. Sur les premières semaines d'un rapprochement entre deux bases anciennes et hétérogènes, la zone grise peut représenter une part significative des cas. Une fois les variantes récurrentes de la base identifiées et enregistrées, le volume de nouveaux cas ambigus se stabilise à un niveau nettement plus faible, propre aux nouvelles fiches créées après la mise en place.

Cette logique d'apprentissage par capitalisation des décisions rejoint la question plus générale de la préparation des données pour un usage IA, que nous abordons dans notre article sur les données prêtes pour l'IA en entreprise.

Le vrai danger : le faux positif, et comment le rendre réversible

Un rapprochement manqué coûte une ressaisie ou un doublon de plus, un désagrément mineur et récupérable. Un faux positif, c'est-à-dire un rapprochement automatique erroné qui fusionne deux entités distinctes, coûte beaucoup plus cher : il pollue les deux systèmes à la fois, avec un historique de commandes, de factures ou d'échanges attribué à la mauvaise fiche.

C'est le vrai danger de ce type de projet, bien plus que la lenteur d'un rapprochement partiel. Trois principes de conception limitent ce risque :

• Ne jamais fusionner physiquement les fiches d'origine. Un rapprochement crée un lien entre deux identifiants, dans une table dédiée, sans jamais supprimer ou réécrire les données sources dans le CRM ou l'ERP d'origine. Le lien peut être défait, les fiches d'origine restent intactes.
• Tracer l'origine de chaque rapprochement. Automatique au-dessus du seuil haut, ou validé manuellement, avec la date et l'auteur. En cas d'anomalie découverte plus tard, on sait immédiatement d'où vient l'erreur et combien de cas similaires elle a pu affecter.
• Prévoir une procédure de défusion. Un rapprochement erroné détecté après coup doit pouvoir être annulé en une opération simple, qui restaure l'état antérieur dans les deux systèmes, plutôt que de nécessiter une reprise manuelle complète.

Cette exigence de traçabilité et de réversibilité rejoint directement les principes que nous appliquons pour le rapprochement automatique entre bon de commande, livraison et facture, où une erreur de correspondance a des conséquences financières directes et doit rester corrigeable sans reprise manuelle intégrale.

C'est ce type de projet que nous cadrons dans le cadre de notre offre de connecteur sur mesure entre logiciels : choisir la ou les méthodes de rapprochement adaptées à vos libellés réels, calibrer les seuils sur un échantillon de vos propres données, et construire une file de validation dimensionnée pour rester gérable au quotidien plutôt qu'un chantier permanent.

Standard ou sur mesure : ce que peut faire un connecteur classique

Un connecteur no code ou un outil d'intégration standard sait très bien synchroniser deux logiciels quand une clé fiable existe des deux côtés. Il ne sait pas, en revanche, décider qu'une entreprise écrite de trois façons différentes est la même entité, ni pondérer plusieurs champs entre eux, ni apprendre des arbitrages passés. Ces fonctions demandent une couche de rapprochement construite spécifiquement pour vos données, qui vient s'ajouter au flux de synchronisation plutôt que de le remplacer.

La question de savoir quand un connecteur standard suffit et quand un développement dédié devient nécessaire dépend directement de la propreté des identifiants disponibles : nous la détaillons dans notre article sur connecteur standard ou développement sur mesure. En règle générale, l'absence d'identifiant commun est précisément le signal qui fait basculer vers une solution sur mesure, car aucun outil standard du marché ne devine seul quelles fiches désignent la même réalité.

Une fois la couche de rapprochement en place, la circulation de la donnée entre les deux logiciels redevient un problème classique de synchronisation, traité en détail dans notre article sur supprimer la double saisie entre deux logiciels métier : quel outil est propriétaire de quelle donnée, et dans quel sens elle doit circuler une fois les deux fiches identifiées comme équivalentes.

Questions fréquentes sur la synchronisation sans identifiant commun

Pour aller plus loin

• Embeddings et recherche sémantique en entreprise : le fonctionnement technique du rapprochement sémantique en détail.
• Correspondance de champs entre deux logiciels : faire correspondre les structures de données avant de comparer les valeurs.
• Structurer des données non structurées avec l'IA : la méthode quand la donnée de départ n'est même pas dans un champ exploitable.
• Où placer la validation humaine dans une automatisation : dimensionner le contrôle humain sur toute automatisation à risque.
• Rapprocher bon de commande, livraison et facture : un cas concret où le rapprochement automatique a un impact financier direct.
• Connecteur standard ou développement sur mesure : quand un outil no code suffit et quand il ne suffit plus.
• Supprimer la double saisie entre deux logiciels métier : la synchronisation une fois les fiches correctement identifiées.