Les données de référence, ou données maîtres, sont les informations qui décrivent les entités durables de l’entreprise : clients, fournisseurs, articles, sites, salariés. Le MDM (Master Data Management, gestion des données de référence) consiste à garantir qu’il en existe une version unique, exacte et partagée par tous les outils. Pour une PME ou une ETI, cela ne passe pas forcément par une plateforme spécialisée : un référentiel désigné, des règles de saisie, un contrôle automatique des identifiants officiels et des synchronisations propres suffisent dans la plupart des cas. Le point le plus important n’est pas technique : chaque domaine de données doit avoir un responsable.
Cet article explique comment reconnaître un problème de données de référence, quelle architecture choisir selon votre taille, et comment lancer la démarche sans en faire un projet interminable.
Qu’appelle-t-on données de référence ?
On distingue classiquement deux familles de données dans une entreprise :
- Les données de référence décrivent des entités qui durent : un client, un fournisseur, un article, un entrepôt, un collaborateur. Elles changent peu et sont utilisées partout.
- Les données transactionnelles décrivent des événements : une commande, une facture, une livraison, un pointage. Elles s’accumulent en grand nombre et pointent toutes vers des données de référence.
Cette dépendance explique tout. Une adresse de facturation erronée dans une fiche client contamine chaque facture émise vers ce client. Un article créé deux fois sous deux codes fausse les stocks, les statistiques de vente et les réapprovisionnements. La gestion des données de référence fait d’ailleurs partie des domaines de connaissance du DAMA-DMBOK, le corpus de référence des professionnels de la gestion des données.
Les symptômes d’un problème de données de référence
Vous n’avez pas besoin d’un audit pour savoir si le sujet vous concerne. Ces signaux suffisent :
- le même client existe sous plusieurs noms (« SARL Martin », « Martin SARL », « Ets Martin ») avec des conditions différentes ;
- le chiffre d’affaires par client ne correspond pas entre le CRM, l’ERP et la comptabilité ;
- un article a des désignations ou des unités différentes selon l’outil (carton, pièce, palette) ;
- les commerciaux tiennent leur propre fichier, « parce que le CRM n’est pas à jour » ;
- un fournisseur a changé de coordonnées bancaires et l’information n’a été corrigée que dans un outil sur trois ;
- chaque nouvelle intégration entre deux outils commence par des semaines de rapprochement manuel.
Le dernier point est souvent le déclencheur : c’est en voulant synchroniser le CRM et l’ERP qu’on découvre l’ampleur des doublons.
Pourquoi les données divergent-elles ?
Les données de référence se dégradent pour trois raisons structurelles, et les connaître évite de traiter seulement les symptômes.
Plusieurs points de création. Un client peut être créé par un commercial dans le CRM, par l’ADV dans l’ERP, par le site e-commerce lors d’une commande en ligne. Chaque porte d’entrée applique ses propres règles, ou aucune.
Des définitions différentes. Pour le commerce, un « client » est un groupe avec lequel on négocie. Pour la comptabilité, c’est une entité juridique qu’on facture. Pour la logistique, c’est une adresse de livraison. Martin Fowler décrit ce phénomène dans son article sur les contextes délimités : un même mot recouvre des modèles différents selon le domaine, et l’intégration doit organiser la correspondance plutôt que nier la différence.
Personne n’est responsable. Quand une donnée appartient à tout le monde, personne ne la corrige. Chaque équipe contourne le problème localement, souvent dans un tableur.
Quelle architecture de référentiel pour une PME ou une ETI ?
Il existe quatre grandes façons d’organiser un référentiel. Les noms viennent du monde des grands comptes, mais la logique s’applique à toutes les tailles.
| Modèle | Principe | Adapté quand | Point d’attention |
|---|---|---|---|
| Outil maître désigné | Un outil existant (souvent l’ERP) fait foi ; les autres reçoivent des copies | PME avec un ERP central et quelques outils autour | Les créations hors de l’outil maître doivent passer par lui |
| Registre (index) | Un index relie les identifiants des différents outils sans déplacer les données | Outils nombreux qu’on ne peut pas modifier | Ne corrige pas la qualité, seulement le rapprochement |
| Consolidation | Les données sont copiées, dédoublonnées et consolidées dans un référentiel pour l’analyse | Besoin de reporting fiable sans toucher aux outils opérationnels | Les outils sources restent incohérents entre eux |
| Référentiel central | Un service dédié crée et diffuse les données de référence à tous les outils | ETI multi-sites, plusieurs ERP, forte exigence de qualité | Plus structurant : demande une vraie gouvernance |
Pour la majorité des PME, le premier modèle est le bon point de départ : désigner l’ERP comme référentiel des clients facturés, des articles et des fournisseurs, fermer les autres portes de création, et diffuser les données par des intégrations fiables. Une ETI multi-sociétés ou issue de rachats successifs, avec plusieurs ERP, aura plus souvent intérêt à un service de référentiel dédié, développé sur mesure et exposé par API, qui devient la seule porte d’entrée pour créer un client ou un article.
S’appuyer sur les identifiants officiels
Le moyen le plus efficace de fiabiliser un référentiel est de l’ancrer sur des identifiants qui existent en dehors de l’entreprise.
Pour les clients et fournisseurs : SIREN et SIRET
Le SIREN identifie une entreprise (l’unité légale), le SIRET identifie chacun de ses établissements. L’Insee précise que le SIRET est un identifiant de 14 chiffres, dont la première partie est le SIREN de l’unité légale. Distinguer les deux évite une erreur fréquente : créer une fiche client par établissement alors qu’il s’agit de la même entreprise, ou l’inverse.
Ces identifiants permettent de contrôler la saisie (format, existence) et d’enrichir automatiquement la fiche à partir des données publiques de la base Sirene, consultables notamment via l’Annuaire des Entreprises de l’État. Ils sont devenus incontournables avec la réforme de la facturation électronique : le SIREN du client fait partie des nouvelles mentions obligatoires des factures, rappelées par Service Public Entreprendre.
Pour les produits : le GTIN
Le GTIN (Global Trade Item Number), géré par GS1, est l’identifiant international des articles commerciaux : c’est le numéro porté par le code-barres. Pour une entreprise de négoce ou de distribution, l’utiliser comme clé de rapprochement avec les catalogues fournisseurs évite une grande partie des doublons d’articles. Les références internes restent utiles, mais elles doivent pointer vers ce standard.
Mettre en place la gouvernance : qui décide de quoi ?
La gouvernance des données est l’ensemble des rôles et des règles qui décident comment une donnée est créée, modifiée, contrôlée et supprimée. Elle peut tenir sur une page.
- Nommer un responsable par domaine : clients, fournisseurs, articles. C’est un rôle métier, pas informatique.
- Écrire la définition de chaque entité : qu’est-ce qu’un client chez nous ? une entité juridique, un établissement, un groupe ?
- Lister les champs obligatoires et leurs règles de contrôle (format du SIRET, unité de vente parmi une liste fermée, pays normalisé).
- Définir le circuit de création : qui peut créer, qui valide, en combien de temps. Un circuit trop lent pousse les équipes à contourner le référentiel.
- Fixer les règles de fusion et d’archivage : que devient l’historique quand deux fiches sont fusionnées ? quand une fiche inactive est-elle archivée ?
- Mesurer la qualité chaque mois avec quelques indicateurs simples : taux de fiches sans SIREN, nombre de doublons suspects, délai moyen de création.
Pour les contacts, qui sont des données personnelles, cette gouvernance rejoint une obligation légale : l’article 5 du RGPD, publié par la CNIL, exige des données « exactes et, si nécessaire, tenues à jour ». Nous détaillons les autres implications dans notre article sur le RGPD dans une application métier.
Par où commencer sans lancer un grand projet ?
Un projet MDM qui veut tout traiter d’un coup s’enlise. Procédez par domaine et par paliers.
- Choisissez un domaine qui fait mal aujourd’hui, le plus souvent les clients.
- Mesurez l’état initial : nombre de fiches, doublons probables, champs clés manquants.
- Nettoyez l’existant : rapprochement automatique sur les identifiants, puis arbitrage humain des cas douteux.
- Fermez les portes : un seul point de création, avec contrôles à la saisie et recherche de doublons avant création.
- Diffusez les données propres vers les autres outils, avec l’identifiant du référentiel stocké partout.
- Passez au domaine suivant une fois le premier stabilisé.
Le nettoyage de l’existant mérite une attention particulière : c’est l’équivalent d’une migration de données, avec les mêmes exigences de sauvegarde, de traçabilité et de validation métier.
Ce qu’il faut retenir
Un référentiel unique n’est pas un luxe de grand groupe : c’est la condition pour que vos outils, vos intégrations et vos tableaux de bord disent la même chose. Pour une PME ou une ETI, la démarche est d’abord organisationnelle (un responsable, des définitions, des règles), puis technique (un outil maître, des contrôles, des synchronisations).
Vos données clients, articles ou fournisseurs divergent d’un outil à l’autre ? Décrivez votre situation dans notre diagnostic de projet : il prend deux minutes et nous revenons vers vous avec une première analyse.
