Vous ne savez pas vraiment combien de clients vous avez

Une question utile : combien de clients uniques votre organisation a-t-elle réellement ? Pas combien d'enregistrements. Pas combien de lignes dans le CRM. Combien de personnes réelles et distinctes. La plupart des organisations produisent un chiffre en quelques secondes. Très peu peuvent le défendre lorsqu'on leur demande de le réconcilier avec la plateforme email, l'ERP, le système de facturation et l'entrepôt de données. Le nombre change. Parfois d'un facteur deux.

La question à laquelle la plupart des organisations ne peuvent pas répondre

Le problème devient visible dès qu'une équipe projet tente de construire une vue unifiée — un référentiel client unique, un dossier collaborateur consolidé, un catalogue produits maître. Elle extrait les données de trois systèmes et découvre que la même entité existe sous des identifiants différents dans chacun, avec trois orthographes du nom, deux adresses, et un indicateur actif/inactif qui ne signifie pas la même chose selon le système consulté. La réponse à "combien avons-nous de X uniques ?" devient : on ne sait pas exactement. Et l'imprécision n'est pas marginale.

Pourquoi cela arrive — et ce n'est jamais un hasard

Cela arrive parce que les systèmes sont construits en séquence, pas de concert. Le CRM est arrivé en premier. Puis l'ERP, puis l'entrepôt de données, chacun avec sa propre logique de clé primaire et sa propre tolérance aux doublons. Personne n'avait formellement la responsabilité des données maîtres sur l'ensemble du périmètre. Personne n'a jamais défini ce que "unique" signifiait au niveau de l'entité — non pas parce que la question a été ignorée, mais parce qu'au moment de la construction de chaque système, elle semblait être le problème de quelqu'un d'autre. L'architecture technique a hérité d'un vide conceptuel. Et ce vide s'élargit à chaque nouveau système ajouté.

Le vrai coût ne se lit pas dans les rapports

Le coût visible, ce sont les emails marketing en double et les tableaux de bord légèrement inexacts. Le coût réel est ailleurs. Des demandes d'effacement RGPD qui nécessitent un traitement manuel dans cinq systèmes plutôt qu'un seul appel API. Des audits de conformité où répondre à "qui a accès aux données de ce client ?" demande trois semaines d'investigation. Des modèles de machine learning entraînés sur une population artificiellement gonflée par les doublons et artificiellement fragmentée par des identifiants incohérents. Dans les services financiers, les RH ou la santé — où "entité unique" est un concept réglementaire autant que technique — la dette est structurelle, pas cosmétique.

Ce que définir un identifiant unique implique vraiment

Un identifiant unique n'est pas un livrable technique. C'est le résultat d'une décision de gouvernance qui précède toute ingénierie. Avant de construire le moindre pipeline, quelqu'un doit répondre : quels attributs définissent cette entité comme unique ? Quelles sont les règles de fusion de deux enregistrements qui pourraient représenter la même personne ? Qui traite les exceptions ? Que se passe-t-il quand la règle produit une réponse qui contredit ce qu'une direction métier croit vrai ? À grande échelle — au sein d'un groupe comptant des dizaines de filiales avec des SIRH différents et des définitions de "collaborateur" différentes — ce travail de gouvernance prend systématiquement plus de temps que l'ingénierie data qui suit. C'est normal. Corriger une définition erronée avant la construction du pipeline coûte une fraction de ce que cela coûte après.

L'effet cascade sur la qualité des données

Les bénéfices en aval d'un identifiant unique bien gouverné se cumulent. Les analyses deviennent fiables parce que les dénombrements de population sont exacts. La conformité RGPD devient systématique parce que l'identification des personnes concernées est non ambiguë. Le reporting est cohérent parce que les différents systèmes référencent la même entité avec la même clé. La qualité des données d'entraînement IA s'améliore parce que la population modélisée reflète la réalité plutôt que des années de dette de déduplication accumulée. Rien de tout cela ne nécessite une nouvelle infrastructure. Cela nécessite une décision de gouvernance qui a été différée.

À quoi ressemble un modèle de données maîtres mature

Quatre composantes sont nécessaires : une définition canonique de chaque type d'entité, un jeu de règles de déduplication documenté et versionné, un processus de gouvernance pour les exceptions et les cas limites, et un mécanisme de propagation qui distribue l'identifiant maître aux systèmes dépendants. Ce jeu de règles n'a pas besoin d'être parfait pour apporter de la valeur. Un identifiant unique fiable à 95 % partagé entre tous les systèmes vaut infiniment plus que cinq systèmes maintenant chacun leur propre version de la réalité. L'objectif n'est pas la perfection. C'est une définition partagée de la réalité sur laquelle toute l'organisation peut construire.

Par où commencer

Choisissez une entité — celle qui génère le plus de douleur de réconciliation en pratique. Cartographiez tous les systèmes dans lesquels elle existe. Documentez la logique de clé primaire dans chacun. Comptez les enregistrements qui ne peuvent pas être rapprochés entre deux systèmes sans intervention manuelle. Ce nombre est votre dette de gouvernance. Et comme toute dette, elle ne diminue pas d'elle-même.