Référentiel Client Unique : construire une identité fiable avant la vue à 360°

Qu’est-ce qu’un Référentiel Client Unique ?

Un Référentiel Client Unique, ou RCU, organise une identification cohérente des clients et la gestion de leurs données de référence à travers plusieurs systèmes. Il peut s’appuyer sur une démarche de Master Data Management, ou MDM. Sa fonction est de relier les fiches qui représentent une même entité et de fournir des attributs de référence selon des règles explicites.

Il ne s’agit pas nécessairement de réunir tout l’historique relationnel dans une base unique. Les transactions peuvent rester dans leurs systèmes spécialisés, reliées par des identifiants stables. La vue à 360° devient alors une composition maîtrisée de données, et non une copie exhaustive de toutes les applications.

Notre recommandation : commencer par les ambiguïtés qui bloquent les décisions. Un service client qui ne retrouve pas un contrat et un directeur commercial qui additionne deux fois le même compte n’ont pas exactement le même besoin de référentiel.

Première décision : que désigne le mot client ?

Avant de dédoublonner, distinguez personne, foyer, entreprise, établissement, compte et contrat. Un foyer peut partager une adresse électronique ; une entreprise peut avoir plusieurs établissements ; une personne peut gérer plusieurs contrats. Ces relations ne sont pas des doublons.

En B2B, une consolidation au niveau de l’entreprise ne remplace pas une gestion des établissements. En B2C, fusionner deux personnes parce qu’elles utilisent le même téléphone familial peut mélanger leurs achats et leurs préférences. Une règle technique ne résout pas une définition métier absente.

Formalisez les entités, leurs relations et les usages autorisés de chaque niveau. Demandez à la finance, au commerce et au service client de qualifier ensemble un échantillon de cas ambigus. Les désaccords constituent la matière du modèle de référence, pas un détail à reporter après le choix de l’outil.

Créer un identifiant durable sans effacer les identifiants sources

L’identifiant du référentiel doit rester stable lorsque le client change de nom, de téléphone ou d’adresse électronique. Conservez une table de correspondance avec les identifiants des applications sources pour retrouver l’origine de chaque fiche et propager les corrections.

Évitez de faire de l’adresse électronique la clé universelle : elle peut changer, être partagée ou être erronée. Une égalité d’email constitue un signal à interpréter dans le contexte du système et de la population, pas une preuve universelle d’identité.

Prévoyez aussi le cycle de vie des liens. Lorsqu’une fusion est annulée, les systèmes consommateurs doivent pouvoir comprendre quels enregistrements appartiennent à nouveau à des entités distinctes. Un identifiant unique sans historique des rapprochements rend cette réparation beaucoup plus difficile.

Dédoublonner : arbitrer entre doublons restants et fausses fusions

Deux erreurs se font concurrence. Ne pas rapprocher deux fiches d’une même personne laisse un doublon. Fusionner deux personnes différentes crée une fausse identité. Le coût de la seconde peut être bien supérieur, notamment lorsqu’une interaction révèle des informations appartenant à une autre personne.

Définissez des règles déterministes pour les cas solides, puis réservez une revue humaine aux cas ambigus. Un score de similarité n’est pas, à lui seul, une probabilité fiable que deux fiches représentent le même client. Le seuil doit être évalué sur des cas qualifiés et adaptés à vos sources.

Construisez un jeu de validation avec des exemples positifs, négatifs et difficiles : homonymes, coordonnées partagées, changements d’adresse, fautes de saisie. Mesurez les fausses fusions et les doublons manqués séparément, puis vérifiez que les résultats restent acceptables lorsque de nouvelles sources arrivent.

Le golden record se construit attribut par attribut

Dans une démarche MDM, le golden record désigne une représentation de référence issue de règles de consolidation. Cela ne signifie pas qu’une application détient toujours la vérité sur tous les champs. L’adresse de facturation peut relever d’un processus différent de l’adresse de livraison ou des préférences de contact.

Pour chaque attribut critique, définissez la source prioritaire, les conditions de validation, la fraîcheur attendue et le traitement des conflits. La dernière valeur reçue n’est pas nécessairement la meilleure : une reprise de données ancienne peut arriver après une modification récente.

Conservez la provenance et la date utile à l’interprétation de la valeur. Préservez aussi la distinction entre valeur inconnue, valeur supprimée et valeur non applicable. Une règle qui remplace systématiquement un champ vide par une ancienne donnée peut annuler involontairement une correction.

Organiser la correction, pas seulement le chargement

Un RCU reste fiable si les erreurs sont détectées, arbitrées et corrigées au fil de l’eau. Nommez un responsable métier de la donnée et des personnes chargées des exceptions. Définissez qui peut fusionner, séparer, modifier une règle ou demander une correction à la source.

La file de revue doit être exploitable. Si les cas ambigus s’accumulent plus vite qu’ils ne sont traités, une automatisation supplémentaire ne résoudra pas toujours le problème : il faut parfois améliorer la collecte, simplifier une règle ou réduire le périmètre du pilote.

Pour les données personnelles, les principes du RGPD encadrent notamment l’exactitude, la minimisation et la durée de conservation. Intégrez ces contraintes dans les échanges entre applications et dans les procédures de rectification. Centraliser une identité ne rend pas automatiquement tous ses attributs nécessaires à tous les utilisateurs.

Les indicateurs qui révèlent la qualité réelle du RCU

Le taux de rapprochement est utile mais insuffisant. Il peut progresser précisément parce que les règles fusionnent trop largement. Nous recommandons un tableau de bord qui combine couverture, justesse et capacité de correction.

• Couverture : part des enregistrements sources rattachés à une identité de référence, suivie par source et par population.
• Justesse : fausses fusions constatées et doublons manqués sur un échantillon qualifié, avec un protocole de contrôle stable.
• Exploitation : nombre et ancienneté des cas en attente, délai de correction et propagation effective aux systèmes consommateurs.
• Utilité métier : temps nécessaire pour retrouver le bon client, incidents liés à l’identité et fiabilité du comptage des clients selon la définition retenue.

RCU et CDP : relier l’identité à l’action

Le RCU et la CDP peuvent se compléter : l’un fournit une identité gouvernée, l’autre assemble les informations nécessaires à des audiences et à des activations. Cette frontière doit être adaptée à votre architecture, car certaines solutions couvrent une partie des deux besoins.

Si une CDP effectue elle aussi des rapprochements, précisez lesquels sont des liens temporaires pour un parcours et lesquels peuvent modifier l’identité de référence. Une association entre un navigateur et un compte ne doit pas devenir, sans règle explicite, une fusion définitive de clients.

Pour démarrer, retenez deux sources, une population et un usage concret. Fixez les critères d’acceptation des rapprochements, testez une fusion puis son annulation et vérifiez le résultat dans un système consommateur. Ce petit périmètre teste les décisions les plus structurantes avant de généraliser le référentiel.