Données produits, fournisseurs et sites : construire des référentiels fiables

Commencer par les erreurs qui empêchent de travailler

Un fournisseur apparaît sous plusieurs codes, une commande porte sur un carton alors que le stock est tenu à l’unité, un site change de rattachement et les comparaisons annuelles deviennent incompréhensibles. Ces difficultés relèvent souvent des référentiels : les données qui décrivent durablement les objets utilisés dans plusieurs processus. Les corriger uniquement dans un rapport laisse les opérations exposées aux mêmes erreurs.

Le Master Data Management, ou MDM, associe organisation, règles et outils pour maintenir les données maîtres partagées. IBM distingue ces données, qui décrivent notamment produits et lieux, des transactions et des listes de codes de référence. Dans cet article, le mot référentiel désigne le dispositif qui gère ces objets métiers et leurs liens. Il ne suppose pas d’acheter une plateforme spécialisée.

Choisissez un résultat observable : rapprocher les dépenses fournisseurs, fiabiliser les quantités commandées ou reconstituer un périmètre de sites. Identifiez les équipes, les systèmes et les erreurs rencontrées. Pour chaque défaut, estimez fréquence, conséquence et effort de correction. Cette cartographie délimite le premier périmètre et évite de nettoyer simultanément tous les champs de toutes les applications.

Définir ce qu’une fiche représente avant de chercher les doublons

Deux lignes qui se ressemblent ne représentent pas nécessairement le même objet. Un groupe fournisseur, une société qui facture et un entrepôt de livraison sont liés, mais ne sont pas interchangeables. Écrivez la règle d’identité de chaque objet : qu’est-ce qui justifie une nouvelle fiche, et quel changement modifie seulement une fiche existante ?

En France, l’Insee distingue l’unité légale, entité juridique, de l’établissement, unité de production localisée qui en dépend. Un tiers fournisseur exprime aussi un rôle dans votre relation commerciale. Un site opérationnel peut désigner, selon votre organisation, un campus, une usine ou une zone de travail : documentez ses correspondances avec les établissements, sans imposer une équivalence automatique.

Côté produits, séparez la famille commerciale, la variante, l’article interne ou SKU et le conditionnement. Un carton et son contenu ne sont pas deux descriptions concurrentes d’une même unité de stock. Dans le système GS1, le GTIN identifie un article commercial ; les règles d’attribution prennent notamment en compte les niveaux de conditionnement et leurs changements.

Installer une identité stable et conserver les codes sources

Attribuez un identifiant interne stable à chaque objet maîtrisé, sans y encoder un nom, une région ou une catégorie susceptible de changer. Conservez à côté les identifiants externes et les codes de chaque application. Une table de correspondance relie ainsi le système source, son code local, l’objet de référence et, si nécessaire, la période pendant laquelle le lien est valide.

Le SIREN comporte neuf chiffres et identifie une unité légale ; le SIRET en comporte quatorze et identifie un établissement, avec le SIREN dans sa première partie. Ces identifiants répondent à deux niveaux différents. Ils ne constituent pas une clé universelle pour tous les fournisseurs internationaux ou tous les sites internes. Enregistrez le type d’identifiant, son autorité émettrice et son pays lorsque cela est pertinent.

Ne remplacez pas les codes historiques des transactions par un code global sans conserver la correspondance. Vérifiez qu’un code local réutilisé après une migration ne rattache pas les anciennes factures au mauvais tiers. Pour les produits, explicitez les relations entre SKU internes, références fournisseurs et GTIN, avec leur conditionnement. Une clé correctement formatée ne prouve ni l’existence actuelle de l’objet ni la justesse de son rattachement.

Définir qui décide, attribut par attribut

Désigner un responsable global du référentiel ne règle pas tous les désaccords. Les achats peuvent qualifier un fournisseur, la finance valider ses informations de paiement et les opérations maintenir ses lieux de livraison. Pour chaque attribut critique, identifiez le responsable métier qui arbitre, l’équipe qui effectue les corrections et l’application autorisée à publier la valeur.

Créez une fiche de règle courte : définition, source faisant autorité, validation attendue, fréquence de contrôle, procédure d’exception et destinataires. Le Data Owner porte les décisions de son domaine ; le Data Steward traite les anomalies et suit leur résolution. Ces rôles peuvent être exercés par des collaborateurs existants, à condition de leur réserver du temps et un pouvoir de décision explicite.

La valeur la plus récente n’est pas toujours la meilleure. Une synchronisation peut réintroduire un ancien nom ou écraser une donnée validée avec une saisie incomplète. Définissez les priorités par attribut, préservez la provenance et faites expirer les dérogations temporaires. Une modification sensible, comme des coordonnées de paiement, doit suivre un circuit de validation distinct d’un simple changement de libellé, selon les contrôles internes de l’organisation.

Contrôler la qualité au moment où elle devient utile

Un champ obligatoire n’est utile que s’il correspond à une exigence réelle. Séparez les données nécessaires à la création d’un brouillon, à l’activation d’un fournisseur et à l’émission d’une commande. Sinon, les utilisateurs renseignent des valeurs de substitution pour contourner le formulaire, puis ces valeurs deviennent des informations apparemment fiables.

Combinez les contrôles : format d’identifiant, valeurs autorisées, cohérence entre champs et intégrité des relations. Un coefficient de conversion doit être positif ; une unité de masse ne se convertit pas en volume sans information supplémentaire ; un article actif doit être rattaché à une catégorie valide. Pour un site, une date de fermeture antérieure à l’ouverture doit être examinée, pas corrigée arbitrairement.

Associez chaque anomalie à une action : bloquer la publication, demander une validation ou afficher une réserve. Mesurez la qualité sur les objets réellement utilisés, avec un dénominateur explicite : fournisseurs actifs sur la période, articles commandables ou sites du périmètre. Une complétude moyenne sur toute la base masque facilement un défaut critique. Suivez aussi la réapparition des erreurs après correction : elle signale souvent un processus source non maîtrisé.

Rapprocher les doublons sans fusionner des objets différents

Séparez la détection de candidats et la décision de fusion. Un rapprochement exact sur une clé pertinente peut fournir une preuve forte, sous réserve que cette clé soit correcte. La similarité d’un nom ou d’une adresse sert surtout à proposer des cas à examiner. Deux sociétés domiciliées au même endroit ne deviennent pas une seule entité.

Définissez trois traitements : rapprochement automatique pour les cas suffisamment établis, revue humaine pour les cas ambigus, maintien séparé lorsqu’une contradiction subsiste. Calibrez les règles sur des exemples validés par les métiers. Évaluez les faux rapprochements et les doublons manqués, par famille d’objets ; une réussite globale peut cacher des erreurs sur les fournisseurs internationaux ou les articles aux descriptions proches.

Préparez l’annulation d’une fusion avant de l’autoriser. Conservez les fiches sources, la justification, l’auteur, la version de règle et les relations déplacées. Une défusion doit permettre de rétablir les bonnes identités et de corriger les systèmes consommateurs. Elle n’annule pas magiquement les opérations déjà exécutées : les paiements, commandes ou analyses affectés exigent une vérification spécifique. Testez cette procédure sur un cas simulé avant d’industrialiser les rapprochements.

Gérer les changements sans réécrire silencieusement le passé

Formalisez un cycle de vie adapté : demandé, en cours de qualification, actif, suspendu, retiré. Un fournisseur suspendu peut rester nécessaire pour régler des factures existantes ; un produit arrêté peut encore avoir du stock ; un site fermé doit rester interprétable dans les séries historiques. Définissez donc les opérations autorisées pour chaque statut, au lieu d’appliquer un unique drapeau actif ou inactif.

Distinguez une correction d’erreur d’un changement réel. Rectifier une faute dans un nom et transférer un site vers une autre division n’ont pas le même effet sur l’historique. Conservez la date d’effet métier et la date d’enregistrement lorsque ce décalage importe. Les rattachements organisationnels, conversions et relations fournisseur-produit peuvent eux aussi nécessiter une période de validité.

Pour les restitutions, annoncez si l’analyse utilise le périmètre de l’époque ou l’organisation actuelle. Les deux vues peuvent être légitimes, mais répondent à des questions différentes. Archivez les versions utiles aux rapprochements, selon les règles de conservation applicables au contexte. Le référentiel doit permettre d’expliquer pourquoi un chiffre historique change ; une mise à jour ne doit pas rendre cette explication impossible.

Relier les domaines et organiser la diffusion des changements

La valeur apparaît souvent entre les domaines : tel fournisseur livre tel article, sous tel conditionnement, à tel site, pendant telle période. Modélisez cette relation comme une information à part entière. Le délai d’approvisionnement peut dépendre de ce couple fournisseur-article et du site destinataire ; le stocker seulement dans la fiche fournisseur impose une précision trompeuse.

Évitez également de confondre les hiérarchies. Un regroupement achats, une organisation financière et une géographie opérationnelle peuvent classer les mêmes objets différemment. Nommez chaque hiérarchie, attribuez-lui un responsable et contrôlez les rattachements incompatibles ou les cycles. Un modèle multidomaine conserve ces différences tout en permettant leurs rapprochements.

Pour chaque application consommatrice, fixez le sens des échanges, la fréquence utile et le traitement des rejets. Publier une nouvelle version ne prouve pas qu’elle a été appliquée partout. Prévoyez un identifiant de changement, des reprises sans duplication, une file d’erreurs attribuée et un contrôle de synchronisation. Testez aussi une mise à jour reçue en retard : elle ne doit pas écraser une version plus récente ni créer une boucle entre applications.

Exemple fictif : réconcilier achats et stocks sur plusieurs sites

Imaginons un industriel disposant de deux ERP. Le site A commande une pièce à l’unité ; le site B achète la même pièce en boîtes de dix. Le fournisseur figure sous deux codes locaux, et une société homonyme existe dans un autre pays. L’objectif initial est de comparer les quantités et les prix d’achat sur ce périmètre, sans modifier les transactions sources.

L’équipe valide d’abord l’identité du fournisseur réel, puis rattache les codes locaux à cette entité. Elle conserve la société homonyme séparément. Elle relie ensuite les articles à la pièce et à leurs conditionnements. La conversion en unités n’est autorisée qu’après validation de son coefficient et de sa période d’application.

• Le prix moyen est pondéré par les quantités normalisées ; additionner unités et boîtes donnerait un résultat inutilisable.
• La comparabilité dépend aussi des spécifications, de la devise, des conditions commerciales et de la période : le référentiel ne résout pas seul ces écarts.
• Aucune économie réalisée n’est revendiquée : l’exemple montre la construction d’une base de comparaison, préalable à une décision achats.

Choisir l’outillage après avoir défini le fonctionnement

Si un ERP maîtrise déjà les objets concernés et dessert correctement les autres applications, renforcer ses formulaires, validations et interfaces peut suffire. Si plusieurs systèmes doivent conserver leur autonomie, un registre de correspondances peut d’abord résoudre l’identité commune. Il ne suffit toutefois pas à imposer partout la même valeur ni à organiser toutes les modifications.

Une base consolidée peut fournir une vue commune pour l’analyse sans devenir le point de saisie opérationnel. Un dispositif central de création et de diffusion convient à d’autres besoins, avec des impacts plus importants sur les processus et la disponibilité. Déterminez explicitement qui écrit quoi et ce qui se passe lorsque le service central est indisponible.

Évaluez une solution spécialisée sur vos cas difficiles : création incomplète, conflit de sources, fusion erronée, changement rétroactif et reprise après incident. Incluez dans le coût les interfaces, la maintenance des règles et le travail des équipes métiers. Un outil qui détecte beaucoup d’anomalies sans permettre de les traiter crée surtout une file d’attente.

Livrer un premier périmètre et vérifier sa tenue dans le temps

Organisez le premier déploiement autour d’un usage, de quelques applications et de responsables disponibles. Commencez par les règles d’identité et l’état initial des erreurs ; construisez ensuite les correspondances, le circuit de validation et les contrôles. Faites fonctionner la solution sur des créations et des modifications réelles, pas uniquement sur un chargement initial nettoyé.

Avant extension, vérifiez cinq capacités : retrouver les codes sources, expliquer une valeur publiée, traiter un cas ambigu, reconstituer un état historique et corriger une mauvaise fusion. Ajoutez la preuve que les consommateurs reçoivent les changements dans le délai convenu. Ces critères rendent l’acceptation plus exigeante et plus utile qu’un simple taux de complétude.

Suivez quelques mesures reliées à l’activité : délai de création d’une fiche utilisable, anomalies critiques récurrentes, rapprochements corrigés, rejets de diffusion et temps passé à réconcilier les données. Comparez des périodes et des périmètres comparables, puis examinez les causes avec les métiers. L’extension à un autre domaine devient pertinente lorsque le fonctionnement courant tient sans dépendre en permanence de l’équipe projet.

Questions fréquentes