Doublons CRM et ERP : corriger les fiches sans recréer le problème
Accueil›Blog›Qualité des données
D’où viennent les doublons, quelle source doit faire foi, et comment les corriger sans que la prochaine synchronisation les recrée.
Un client, quatre versions
Ce qui se passe quand chaque outil décide seul de ce qui est vrai.
Faire le diagnostic
À retenir
- Un doublon est un symptôme. La cause est presque toujours un flux qui recrée la fiche, pas une erreur de saisie isolée.
- Il n’y a pas toujours une seule source de vérité. Le CRM peut faire foi sur la relation commerciale, l’ERP sur la facturation.
- La clé de rapprochement décide de tout. L’e-mail et la raison sociale échouent ; un identifiant stable comme le SIREN tient.
- Fusionner avant de cadrer revient à nettoyer une base qui se re-salira dans la semaine.
Un doublon ne ressemble jamais à un problème. Il ressemble à un détail : une relance envoyée deux fois, une facture adressée au mauvais interlocuteur, un chiffre d’affaires qui ne correspond pas d’un tableau de bord à l’autre. Pris un par un, ces écarts se corrigent à la main. Accumulés, ils finissent par faire douter de tout ce que le CRM affiche.
La réaction habituelle consiste à lancer un grand nettoyage. Il soulage quelques semaines, puis les doublons reviennent, parce que la cause n’a pas été touchée. Cet article part de l’inverse : comprendre d’où viennent les fiches en double, décider quelle source fait foi, et seulement ensuite corriger — de façon à ce que la correction tienne.
Le doublon visible n’est que le dernier maillon
Deux fiches identiques se repèrent facilement. Le risque commence plus tôt, au moment où chaque outil nomme, identifie et met à jour le même client selon ses propres règles.
Le CRM peut utiliser l’adresse e-mail, l’ERP un numéro de compte et l’outil de support un nom de société saisi librement. Une synchronisation transmet alors des valeurs sans garantir qu’elles décrivent la même entité.
Avant de fusionner deux fiches, cherchez le flux capable de les recréer demain.
D’où viennent la plupart des doublons
- Les imports de fichiers. Une liste de salon, un fichier de prospects, une extraction d’un ancien outil : chaque import crée des fiches sans vérifier qu’elles existent déjà, sauf si une règle de dédoublonnage a été configurée avant.
- Les synchronisations sans clé commune. Quand deux outils échangent des fiches sans identifiant partagé, le connecteur ne peut pas savoir qu’« ACME FR » et « ACME France » sont la même société. À chaque doute, il en crée une nouvelle.
- La saisie parallèle. Le commerce crée le compte dans le CRM, la comptabilité dans l’ERP, le support dans son outil. Chacun fait bien son travail, et l’entreprise se retrouve avec trois fiches.
- Les changements d’organisation. Rachats, regroupements de filiales, changements de raison sociale : l’entreprise change de nom, pas toujours de fiche.
Dans les quatre cas, la fiche en double n’est pas une erreur humaine à corriger mais le résultat logique d’un processus. Tant que ce processus reste en place, il produit de nouveaux doublons au rythme de ses exécutions.
Ce que coûtent vraiment les doublons
Le coût se voit rarement sur une seule ligne. Il se diffuse : un commercial qui appelle un client déjà suivi par un collègue, une relance de paiement envoyée à une adresse périmée, une campagne adressée deux fois au même décideur.
Le coût le plus lourd est ailleurs. Quand les chiffres du CRM et ceux de l’ERP divergent, la direction cesse de s’en servir pour décider, et les tableurs parallèles reprennent leur place. Le système existe toujours, mais plus personne ne lui fait confiance.
Définir la donnée qui fait foi, champ par champ
Il n’existe pas toujours une seule application de référence. Le CRM peut maîtriser le propriétaire commercial tandis que l’ERP maîtrise les conditions de paiement.
Écrire la règle sur une page
La règle de référence tient rarement en plus d’une page. Pour chaque donnée clé — raison sociale, SIREN, adresse de facturation, propriétaire commercial, conditions de paiement — elle précise trois choses : quel système fait foi, qui a le droit de la modifier, et dans quel sens la valeur circule lors des synchronisations.
Tant que ce document n’existe pas, chaque connecteur applique sa propre logique, et c’est souvent celle du dernier qui écrit.
Le cas particulier des contacts
Pour les entreprises, un identifiant officiel comme le SIREN règle la question. Pour les personnes, il n’existe pas d’équivalent. L’adresse e-mail reste le meilleur indice, mais elle change quand quelqu’un quitte l’entreprise, et une même personne peut en utiliser deux.
La bonne pratique consiste à combiner plusieurs champs — e-mail, nom, entreprise de rattachement — et à réserver la fusion automatique aux cas où ils concordent tous.
Traiter les doublons sans les recréer
Le nettoyage intervient après le cadrage. Cette séquence évite de choisir arbitrairement une fiche gagnante ou de perdre des relations utiles.
- Cadrer Lister les objets, les systèmes et les équipes concernés.
- Mesurer Quantifier les doublons certains, probables et à examiner.
- Arbitrer Définir les champs conservés, enrichis ou soumis à validation.
- Corriger Fusionner, rediriger les relations et conserver une trace.
- Prévenir Bloquer les créations incohérentes et surveiller les flux.
Deux points font la différence au moment de corriger. D’abord, distinguer les doublons certains des doublons probables : les premiers partagent un identifiant stable et peuvent être fusionnés en lot ; les seconds se ressemblent sans preuve formelle et demandent une validation humaine.
Ensuite, fusionner ne veut pas dire supprimer. Une fusion bien menée rattache à la fiche conservée tout ce qui dépendait des autres — opportunités, tickets, factures, historique des échanges — et garde la trace de ce qui a été regroupé, pour pouvoir expliquer un écart six mois plus tard.
Empêcher les doublons de revenir
Une base nettoyée ne reste propre que si les portes par lesquelles entraient les doublons sont fermées.
À la création
Un contrôle qui cherche une fiche existante avant d’en créer une nouvelle — sur le SIREN pour une entreprise, sur plusieurs champs pour un contact — évite l’essentiel des créations inutiles, que la saisie soit manuelle ou automatique.
Dans les flux
Chaque synchronisation doit utiliser la clé de rapprochement retenue et refuser de créer une fiche quand elle ne trouve pas de correspondance certaine. Mieux vaut une fiche en attente de validation qu’un doublon silencieux. Les imports suivent la même règle.
Dans l’organisation
Une donnée sans propriétaire se dégrade. Nommer, pour chaque donnée clé, la personne ou l’équipe qui en répond, et relire chaque semaine les fiches nouvellement créées, suffit souvent à repérer un flux défaillant avant qu’il n’ait produit des centaines de fiches.
Choisir la prochaine action selon le risque
Trois situations, trois points de départ. Le diagnostic en tête d’article vous indique la vôtre.
Dans la plupart des cas, le bon point de départ est un état des lieux court : mesurer le volume de doublons probables, lister les flux qui créent des fiches, et identifier les données qui n’ont pas de propriétaire. C’est par là que commencent les projets que nous menons chez Mirakl ou Orhatek : réconcilier les référentiels avant de toucher aux fiches.
Ce travail prend quelques jours. Il transforme une impression diffuse — « nos données ne sont pas fiables » — en une liste d’écarts mesurés, de causes identifiées et de décisions à prendre.
Pour aller plus loin, découvrez notre offre d’intégration CRM, notre accompagnement d’intégration ERP et nos expertises data.
Les questions les plus fréquentes
Regardez quand et d’où ils apparaissent. S’ils arrivent en série après une synchronisation ou un import, c’est un flux qui les recrée ; s’ils sont isolés et dispersés, c’est plutôt la saisie. Dans le premier cas, corriger les fiches ne suffit pas : il faut corriger le flux.
Un identifiant stable attribué à l’entreprise, comme le SIREN en France. L’adresse e-mail identifie une personne et disparaît quand elle part ; la raison sociale varie selon la saisie. Pour les contacts, combinez plusieurs champs plutôt que de vous fier à un seul.
Non, la source qui fait foi se définit champ par champ. Le CRM peut faire foi sur le propriétaire commercial et l’ERP sur les conditions de paiement. L’essentiel est que la règle soit écrite et appliquée par les synchronisations.
En bloquant les créations incohérentes à la source et en surveillant les flux. Vérifiez l’existence d’une fiche avant toute création, imposez la clé de rapprochement dans les synchronisations et contrôlez régulièrement les nouveaux enregistrements.
