Clients en double : que comparer avant de fusionner

Pour examiner les clients en double, comparez d’abord l’identité et la fonction de chaque fiche ; décidez ensuite si une fusion est nécessaire. Un enregistrement dans les ventes et un autre dans la facturation peuvent être corrects. Ce qui manque est peut-être une correspondance fiable entre les deux.

Le problème apparaît lorsque l’administration trouve deux historiques similaires et que quelqu’un propose de garder « le plus complet ». Une fiche peut contenir le contact actuel ; l’autre, les références utilisées par une intégration. Choisir en fonction du nombre de champs remplis ne résout pas ce conflit. Ce guide fournit une matrice et un journal de décisions pour examiner le cas avant de le modifier.

Une fiche par outil peut être la bonne solution

Distinguez la même entité représentée dans deux systèmes de deux enregistrements redondants au sein d’un seul. Le premier cas peut nécessiter une table de correspondance ; le second, une enquête sur l’origine du doublon. Aucun des deux n’autorise la suppression d’une ligne par son nom.

Définissez également ce que représente chaque enregistrement : organisation, personne de contact, établissement ou compte commercial. Une personne travaillant dans une entreprise n’est pas un doublon de cette entreprise. Deux établissements ne doivent pas non plus être fusionnés si votre activité nécessite de les traiter séparément.

Cette vérification s’inscrit dans la préparation d’une migration, mais elle est également utile sans changer d’outil. Son résultat peut être de conserver deux fiches et d’expliquer leur relation.

Conservez l’origine avant de normaliser

Travaillez sur une copie en lecture seule. Pour chaque ligne, enregistrez le système, l’espace de travail, le type d’enregistrement, l’identifiant original et la date d’extraction. CRM / W1 / account / A17 identifie quelque chose de différent de BILL / W1 / account / A17 : répéter le numéro ne prouve pas qu’il s’agit du même client.

Maintenez les valeurs originales et créez des colonnes auxiliaires pour comparer les espaces, les majuscules ou les variantes connues du nom. Ne supprimez pas les suffixes, départements ou références qui peuvent distinguer les entités. Un champ vide signifie « sans donnée », pas « correspond à un autre vide ».

Notez l’origine de chaque signal. Un code commun a plus de valeur si vous savez qui l’a attribué et si vous avez vérifié sa correspondance. Un code copié lors d’une importation erronée peut propager la même erreur aux deux fiches. La date de dernière édition ne rend pas automatiquement une valeur correcte.

Une matrice avec trois résultats et quatre cas

L’exemple suivant est entièrement fictif. Tous les enregistrements appartiennent à l’espace W1 ; les codes ORG et EV sont des références d’exercice, et non des identifiants fiscaux ni des données clients. Les preuves décrites sont supposées disponibles uniquement pour illustrer le raisonnement.

N’attribuez pas de pourcentages de confiance inventés. « Probable » ouvre une vérification : ce n’est pas une fusion approuvée. « Cas ambigu » maintient le blocage et explique ce qui manque. Même si vous confirmez l’identité, il reste à décider s’il est nécessaire de modifier quoi que ce soit.

L’absence de commandes sur une fiche ne prouve pas non plus qu’elle est en trop : il peut s’agir d’une nouvelle inscription ou représenter une autre fonction. Classez avec des preuves, pas avec le nombre de champs vides.

La table des alias n’exécute pas une fusion

Supposons que le responsable résolve le premier cas : A17 et B62 représentent ORG-07, mais les deux outils nécessitent leur fiche. La décision est de les conserver et d’enregistrer leur correspondance. Dans une feuille indépendante, ENTITY-F07 peut être votre référence de travail :

system,workspace,record_type,source_id,entity_key,review_id
CRM,W1,account,A17,ENTITY-F07,R-01
BILL,W1,account,B62,ENTITY-F07,R-01

Ces colonnes sont un modèle créé pour cet exercice, non un format d’importation de Frihet ni un ordre pour un connecteur. entity_key regroupe les identités vérifiées ; source_id conserve la référence originale. Un alias ne modifie pas les outils par sa seule existence dans une feuille.

Ne regroupez pas les personnes, les entreprises et les établissements sous la même clé. Et ne combinez pas par transitivité sans vérification : si A ressemble à B et B ressemble à C, vous n’avez pas encore démontré que A et C sont identiques.

Enregistrez une décision qu’une autre personne peut réviser

Copiez cette fiche pour chaque paire. Conservez la proposition précédente lorsque la décision change, avec une nouvelle version qui la remplace.

Révision : R-01 / version 1
Références complètes : CRM/W1/account/A17 ; BILL/W1/account/B62
Preuve : EV-01 ; correspondance ORG-07 vérifiée par le responsable
Conflit : contact responsable différent ; valeur en vigueur confirmée dans EV-05
Décision : conserver les deux fiches et enregistrer la correspondance ENTITY-F07
Responsable de la révision : ROLE-OPS
Action dans les outils : aucune
En attente : vérifier comment le connecteur utilise cette correspondance
Remplace : aucune révision antérieure

Les codes sont fictifs. En utilisation réelle, référencez des preuves accessibles à celui qui doit les vérifier et évitez de copier des données personnelles inutiles dans la feuille. Si une modification est autorisée ultérieurement, enregistrez séparément la personne qui a effectué la modification, le moment, les références antérieures et le résultat observé. « Approuvé », « exécuté » et « vérifié » sont des états distincts.

Cet historique est révisable, pas une garantie de retour à l’état antérieur. Rectifier une décision écrite ne reconstruit pas automatiquement les données déjà modifiées.

Ce qu’il faut vérifier chez le fournisseur avant de fusionner

Le comportement dépend du produit et du type d’enregistrement. HubSpot documente qu’une fusion ne peut pas être annulée et que les identifiants, propriétés et associations suivent des règles spécifiques. Ne supposez pas que l’ID que vous avez marqué comme principal survive toujours intact.

Shopify avertit également que l’opération n’est pas réversible et exclut certains profils, comme ceux qui ont ou ont eu des contrats d’abonnement. Ces exemples ne décrivent pas le comportement de Frihet ni de votre autre fournisseur.

Avant toute action irréversible, répondez aux questions suivantes :

• Cette combinaison de types est-elle prise en charge et avez-vous les permissions appropriées ?
• Quelles valeurs sont conservées, lesquelles sont écartées et quel ID le résultat aura-t-il ?
• Que se passe-t-il avec l’historique, les relations et les références externes ?
• Que fera la synchronisation : reconnaître le changement, recréer une fiche ou échouer ?
• Quelle récupération existe réellement et qu’est-ce que votre copie ne couvre pas ?

Lisez la portée des intégrations (en anglais) et vérifiez le contrat du connecteur utilisé. Une fonction de lecture ne prouve pas qu’il sache propager les fusions.

Clôturez le cas en vérifiant également son origine

Si une fusion est autorisée, convenez d’abord de la manière de limiter ses effets sur les systèmes connectés. Faites un essai avec des données synthétiques dans un environnement de test compatible ; si cela n’existe pas, maintenez le blocage jusqu’à ce que les incertitudes soient résolues avec le fournisseur. Une exportation isolée ne prouve pas que vous pouvez tout restaurer.

Après une modification autorisée, comparez les champs et les références avec ce qui était prévu et vérifiez la synchronisation suivante avant d’étendre le lot. Si le résultat est incertain, enquêtez avant de répéter l’action.

Dans la gestion des clients de Frihet, l’exportation de la liste au format CSV est disponible. Elle peut servir de base à une vérification ; elle ne signifie pas que ce modèle peut être importé ni que les clients peuvent être fusionnés automatiquement.

Clôturez en notant pourquoi le doublon est apparu : saisie manuelle, importation ou règle du connecteur, s’il y a des preuves. Si vous ne le savez pas encore, laissez un responsable et une vérification en suspens. Deux fiches conservées avec une relation claire sont un résultat valide ; une liste plus courte sans historique explicable ne l’est pas.

Sources consultées le 14 septembre 2026. Vérifiez la documentation en vigueur de votre fournisseur avant toute modification.