Référentiels et master data finance

Les référentiels financiers organisent les codes, les définitions et les relations nécessaires pour lire les données de la même manière dans toute l'entreprise. Les master data finance décrivent les objets auxquels les montants sont rattachés, tandis que les données transactionnelles enregistrent les opérations et leurs valeurs. Leur gestion consiste à maintenir un langage commun, avec des responsables identifiés et des changements contrôlés.

• Donner un sens partagé aux données. Un compte doit désigner la même nature économique dans les analyses qui le mobilisent. Une entité doit être identifiable sans ambiguïté, même si son nom change. Un centre de coût, unité à laquelle sont rattachées des charges et une responsabilité de gestion, doit avoir un périmètre explicite. Cette cohérence ne signifie pas supprimer tous les besoins locaux : elle consiste à relier les particularités locales à une lecture commune, sans effacer leur sens.
• Organiser les relations, pas seulement les listes. Une dimension est un axe d'analyse, comme le compte, l'entité ou le produit ; un membre est un élément de cet axe. Une hiérarchie organise ces membres en niveaux de regroupement, et un attribut décrit une propriété d'un membre, comme son responsable ou son pays. Ces éléments déterminent les regroupements disponibles et la manière dont les résultats sont expliqués. Une liste de codes sans relations ni règles d'utilisation reste donc insuffisante.
• Maîtriser la vie du modèle. Toute création, modification ou désactivation doit préciser qui décide, quand le changement s'applique et quelles analyses sont concernées. La gouvernance des données, ensemble des responsabilités et règles de décision sur les données, évite que chaque équipe entretienne sa propre vérité. L'objectif n'est pas d'immobiliser le modèle, mais de le faire évoluer sans rendre les comparaisons historiques incompréhensibles.

Sans référentiels maîtrisés, la direction financière consacre une part importante de son travail à interpréter les codes plutôt qu'à expliquer la performance. Un même client existe sous plusieurs noms ; un compte local change de catégorie selon le fichier utilisé ; un centre de coût fermé continue à recevoir des charges. Les montants peuvent être correctement extraits et pourtant mal regroupés.

Des analyses qui ne se recoupent pas

Un tableau des ventes par produit et un tableau des ventes par activité peuvent diverger si les produits ne sont pas rattachés aux mêmes familles. La difficulté ne vient alors ni du calcul ni de l'affichage, mais de la définition des objets. Le reporting, production structurée d'informations pour suivre et expliquer l'activité, devient un exercice de rapprochement manuel entre fichiers concurrents.

Des comparaisons historiques trompeuses

Lorsqu'un service change de direction, rattacher rétroactivement toutes ses charges au nouveau responsable peut donner l'impression que l'ancienne direction a réduit ses dépenses. À l'inverse, conserver uniquement l'ancienne organisation empêche de lire les résultats selon la structure actuelle. Il faut choisir et documenter la vue utilisée, plutôt que mélanger les deux lectures.

Des décisions et des traitements fragilisés

Une règle de calcul peut être juste tout en s'appliquant au mauvais périmètre. Une charge affectée à une catégorie incorrecte modifie la rentabilité apparente d'une activité. Des données non reconnues peuvent aussi être rejetées, ou absorbées dans une rubrique générique qui masque le problème.

Le référentiel ne corrige pas une facture erronée ou une écriture comptable incorrecte. Il résout une autre difficulté : identifier les objets, expliciter leurs relations et appliquer des règles cohérentes. Cette distinction aide à adresser chaque anomalie au bon responsable, sans demander à la finance de réparer seule tous les défauts des systèmes sources.

La mécanique repose sur un cycle commun : identifier, relier, contrôler, approuver et diffuser. Le MDM, ou Master Data Management, désigne l'organisation et les moyens utilisés pour gérer les données maîtres de façon cohérente ; il ne se réduit pas à un logiciel. Le MDM peut couvrir plusieurs domaines, dont la finance.

1. Identifier chaque objet. Un identifiant, code qui distingue un objet de manière unique dans un périmètre donné, est associé à un libellé et à une définition. Le libellé peut évoluer ; l'identifiant reste stable tant que l'objet conserve son identité. Si les codes locaux se répètent, l'identification doit aussi tenir compte du système source ou de l'entité.

2. Décrire les propriétés et les relations. Chaque membre reçoit les attributs nécessaires et ses rattachements hiérarchiques. Le modèle précise les champs obligatoires, les valeurs admises et les relations permises. Une entité juridique et une activité commerciale peuvent constituer deux dimensions distinctes plutôt qu'un seul arbre artificiel.

3. Relier les codes locaux au langage commun. Le mapping, table de correspondance entre des codes sources et des catégories cibles, traduit les particularités des systèmes locaux. Une règle peut dépendre du compte, de l'entité et de sa période de validité. Le mapping comptable doit conserver assez de contexte pour éviter les correspondances ambiguës.

4. Contrôler puis approuver. Les vérifications recherchent les doublons, les champs manquants, les parents inconnus et les correspondances contradictoires. Un parent est le membre de regroupement auquel un autre membre est directement rattaché dans une hiérarchie. Un responsable métier valide le sens économique ; l'équipe technique vérifie que la structure peut être utilisée par les applications.

5. Publier et conserver l'historique. Le versionnement, conservation des états successifs d'un objet ou d'un modèle, permet de retrouver les règles appliquées à une date donnée. La diffusion aux applications consommatrices est suivie, avec une procédure de correction en cas d'échec. Une modification n'est terminée que lorsque sa prise en compte est confirmée.

Dans cet exemple entièrement fictif, un groupe composé des entités Alpha et Beta prépare une analyse mensuelle de sa marge. Chaque entité dispose de son propre plan de comptes, c'est-à-dire de la liste organisée des comptes utilisés pour enregistrer et classer ses opérations comptables. Les montants ci-dessous sont exprimés en euros et les charges sont présentées comme des valeurs positives.

Le chiffre d'affaires (CA) correspond aux ventes réalisées sur la période. La marge sur coûts variables est égale au chiffre d'affaires moins les coûts variables, c'est-à-dire les coûts qui évoluent avec le volume d'activité dans le périmètre étudié. On suppose ici que les charges du tableau sont intégralement variables et que toutes les opérations à analyser y figurent.

| Entité | Compte local | Nature économique | Montant | Correspondance initiale | |---|---|---|---:|---| | Alpha | VENTES_A | Ventes | 100 000 | CA | | Beta | VENTES_B | Ventes | 80 000 | CA | | Alpha | ACHATS_A | Coûts variables | 40 000 | Coûts variables | | Beta | ACHATS_B | Coûts variables | 20 000 | Non renseignée |

Avant correction

Le traitement initial exclut de l'analyse les lignes sans correspondance, sans pour autant supprimer les opérations sources. Le CA affiché est donc : 100 000 + 80 000 = 180 000 €. Les coûts variables affichés sont de 40 000 €. La marge affichée est : 180 000 − 40 000 = 140 000 €.

Le taux de couverture des correspondances, calculé ici sur les couples entité-compte présents dans le tableau, est : 3 / 4 × 100 = 75 %. Ce taux mesure la couverture des codes, pas la part des montants couverts.

Après correction

Le responsable financier de Beta confirme que ACHATS_B relève des coûts variables. La correspondance est approuvée pour la période analysée, puis les données sont rechargées.

Les coûts variables deviennent : 40 000 + 20 000 = 60 000 €. La marge correcte est : 180 000 − 60 000 = 120 000 €. La surestimation initiale était donc : 140 000 − 120 000 = 20 000 €. La couverture des correspondances atteint : 4 / 4 × 100 = 100 %.

Le contrôle final confirme que les ventes restent inchangées et que les charges sources sont toutes représentées. Le référentiel n'a pas modifié l'économie du groupe : il a rétabli une lecture complète et correcte de ses opérations.

Le déploiement doit partir d'un usage financier précis, puis élargir progressivement le périmètre. Construire d'emblée un modèle pour tous les besoins augmente le risque de débats sans fin et de règles inutilisées.

1. Cadrer l'usage et les frontières. Choisir un besoin prioritaire : analyse des charges, budget ou suivi des ventes. Identifier les applications sources et les analyses destinataires. Livrable : une note de cadrage précisant le périmètre, les utilisateurs et les critères d'acceptation.

2. Inventorier les objets existants. Recenser codes, libellés, propriétaires, relations et fichiers de correspondance. Rechercher les doublons et les divergences de définition. Livrable : un inventaire accompagné d'une liste d'anomalies, chacune attribuée à un responsable.

3. Concevoir le modèle cible. Définir les dimensions, les attributs obligatoires, les identifiants et les règles de validité. Distinguer les besoins communs des extensions locales. Livrable : un dictionnaire de données, document qui décrit le sens, le format et les règles d'utilisation de chaque donnée, complété par les hiérarchies et correspondances attendues.

4. Organiser les décisions. Nommer un propriétaire de données, responsable métier qui arbitre leur définition et leur qualité. Désigner un gestionnaire de données, personne qui instruit les demandes et assure leur entretien courant. Livrable : une matrice des responsabilités et un circuit d'approbation.

5. Nettoyer et tester sur un périmètre limité. Corriger les anomalies prioritaires, puis vérifier les regroupements sur des données réelles et des cas de changement. La recette utilisateur, validation du fonctionnement par les utilisateurs métier, doit inclure les totaux, les exceptions et les vues historiques. Livrable : un dossier de tests avec résultats et décisions.

6. Publier et organiser l'exploitation. Diffuser la version approuvée, former les utilisateurs et surveiller les premiers traitements. Livrable : une procédure de publication, un registre des changements et un tableau de suivi des incidents. Pour la planification budgétaire, préciser notamment comment les nouvelles structures s'articulent avec les budgets déjà approuvés.

Séparer identité, libellé et organisation

Un changement de nom ne doit pas créer artificiellement un nouvel objet. À l'inverse, une fusion de services ne se résume pas toujours à renommer un ancien code. Documenter ces distinctions évite les ruptures de comparaison et les réutilisations trompeuses d'identifiants.

Conserver le détail utile

Un regroupement financier ne doit pas faire disparaître les codes sources nécessaires à l'explication. Conserver la correspondance entre le détail local et la catégorie commune permet de revenir à l'origine d'un montant. La traçabilité, capacité à retrouver l'origine et les transformations d'une donnée, doit couvrir aussi les règles de rattachement utilisées.

Dater les changements

La date d'approbation, la date de publication et la date d'effet peuvent être différentes. Les enregistrer séparément évite d'appliquer une nouvelle organisation à une période qui ne la concernait pas. Pour les analyses historiques, préciser si l'on restitue l'organisation d'époque ou si l'on présente le passé selon l'organisation actuelle.

Prévoir plusieurs lectures sans mélanger les objets

Une entité peut être analysée par région, par activité ou selon un périmètre juridique. Des regroupements alternatifs peuvent répondre à ces besoins, à condition de définir les règles d'appartenance et d'éviter les doubles comptes dans les totaux. La hiérarchie doit refléter une question de gestion explicite, pas seulement un organigramme disponible.

Traiter les exceptions de façon visible

Une rubrique « non affecté » peut faciliter le diagnostic, mais elle doit avoir un responsable et une procédure de résolution. Les montants qu'elle contient ne doivent pas disparaître silencieusement des analyses. Selon la criticité de l'usage, une anomalie peut bloquer la publication ou être signalée avec une réserve explicite.

Enfin, associer finance, métiers et équipes informatiques dès la conception. La finance porte le sens des catégories financières ; les métiers connaissent les objets opérationnels ; les équipes informatiques assurent leur circulation. Aucun de ces rôles ne remplace les autres.

Confondre nettoyage ponctuel et gestion durable

Une liste corrigée devient rapidement obsolète si les créations suivantes ne sont pas contrôlées. Prévoir dès le départ le processus de demande, l'approbation et la surveillance des données diffusées. Le nettoyage initial est un point de départ, pas un mode de fonctionnement.

Imposer un modèle unique à tous les usages

Le périmètre juridique d'une entité ne coïncide pas nécessairement avec celui d'une activité commerciale. Tout faire entrer dans la même hiérarchie produit des regroupements artificiels. Séparer les axes et documenter leurs relations est souvent plus lisible qu'empiler les exceptions.

Utiliser le libellé pour identifier un objet

Une clé est un champ ou une combinaison de champs permettant d'identifier sans ambiguïté un objet ou de déterminer la correspondance applicable dans un périmètre donné. Deux objets peuvent avoir le même nom ; un même objet peut changer de nom. Les rapprochements fondés uniquement sur les libellés créent donc des associations fragiles. Utiliser un identifiant stable et conserver les anciens codes lorsque leur présence est utile pour retracer les échanges.

Appliquer une correspondance trop générale

Un code local peut avoir un sens différent selon l'entité ou le système source. Une règle basée uniquement sur ce code risque d'affecter des montants à la mauvaise catégorie. Une clé de correspondance peut combiner le système source, l'entité et le compte. Définir cette clé au niveau de précision réellement nécessaire, sans ajouter des critères sans utilité métier.

Écraser l'historique

Remplacer un rattachement ancien par le nouveau peut changer les analyses déjà publiées. Conserver les états successifs et décider explicitement si une période passée doit être retraitée. Toute nouvelle lecture doit être distinguée de la restitution d'origine.

Faire confiance à un contrôle purement technique

Une valeur peut respecter le format attendu tout en étant économiquement fausse. Un compte de ventes rattaché à des charges est techniquement exploitable, mais incorrect. Combiner contrôles de structure et validation métier, puis vérifier les résultats sur des cas connus.

Enfin, ne pas attribuer automatiquement à la finance la propriété de toutes les données utilisées dans ses analyses. Les produits ou les clients peuvent relever d'autres métiers ; la finance définit alors les attributs et regroupements dont elle a besoin, dans une gouvernance partagée.

Un KPI, ou indicateur clé de performance, mesure un aspect prioritaire d'un objectif. Pour les référentiels, les indicateurs doivent suivre la qualité du modèle et le fonctionnement du processus, sans confondre présence d'une donnée et justesse de son sens.

Indicateurs de qualité

• Complétude des attributs obligatoires = nombre de champs obligatoires renseignés / nombre de champs obligatoires attendus × 100. Le périmètre exclut les champs explicitement non applicables. Ce calcul ne prouve pas que les valeurs sont correctes.
• Couverture des correspondances = nombre de clés sources disposant d'une correspondance valide / nombre de clés sources attendues × 100. Définir la clé utilisée, par exemple entité et compte, ainsi que la période concernée.
• Taux de doublons confirmés = nombre d'enregistrements identifiés comme doublons surnuméraires / nombre total d'enregistrements examinés × 100. Un rapprochement de noms ne suffit pas : les doublons doivent être confirmés selon une règle métier.
• Taux de relations invalides = nombre de relations rejetées par les règles de contrôle / nombre de relations contrôlées × 100. Les contrôles peuvent porter sur l'existence du parent ou la cohérence des dates.

Indicateurs de processus

Le délai moyen de traitement = somme des durées entre réception d'une demande complète et publication / nombre de demandes publiées. Préciser si la durée est mesurée en temps calendaire ou en temps ouvré. Suivre aussi les demandes en attente : elles ne figurent pas dans cette moyenne et peuvent révéler un blocage.

Pour chaque ratio, un dénominateur nul doit conduire à afficher « non applicable », et non un taux artificiel. Les objectifs sont fixés selon les usages et leur criticité, sans seuil universel.

Livrables attendus

Le dossier de référence comprend le dictionnaire de données, les listes approuvées, les hiérarchies datées, les tables de correspondance et la matrice des responsabilités. Il inclut également le registre des changements, les résultats de contrôle et les preuves de publication. Chaque indicateur doit avoir un propriétaire, une fréquence de suivi et une action prévue en cas d'anomalie.

Un EPM, pour Enterprise Performance Management, est un ensemble de processus et de solutions de gestion de la performance, notamment pour planifier, analyser et produire les résultats financiers. Pour les référentiels, il apporte un cadre d'utilisation commun aux dimensions mobilisées par ces processus.

Des fonctions concrètes

Selon la solution et sa configuration, un EPM peut gérer des membres, des attributs et des hiérarchies, importer des correspondances et contrôler la validité des données chargées. Les mêmes axes peuvent servir à saisir un budget et à analyser les montants réalisés, ce qui réduit les rapprochements entre structures indépendantes.

Un workflow, circuit organisé de tâches et d'approbations, peut encadrer certaines demandes ou publications. Les droits d'accès peuvent limiter les modifications aux personnes habilitées. Des journaux de changement peuvent aider à retracer les interventions. Il faut toutefois vérifier la couverture exacte de ces fonctions : gérer une structure dans l'application ne signifie pas disposer d'une gouvernance complète des données maîtres.

Des solutions à examiner selon le besoin

OneStream, CCH Tagetik et Oracle EPM proposent des fonctions de structuration des modèles financiers dans leurs environnements de gestion de la performance. Anaplan mobilise des listes, des hiérarchies et des propriétés pour organiser ses modèles de planification. Les autres solutions sont à examiner selon les mêmes critères, sans déduire leur adéquation de leur seule présence dans une catégorie.

Un rôle à articuler avec les autres systèmes

L'EPM peut être propriétaire de certains regroupements de gestion sans devenir la source officielle des clients, produits ou entités juridiques. Il doit alors recevoir les données maîtres pertinentes et conserver ses propres enrichissements financiers.

L'évaluation porte sur des cas précis : changement de rattachement daté, rejet d'un code inconnu, comparaison historique et diffusion vers les applications concernées. Il faut vérifier ce qui est natif, ce qui demande une configuration et ce qui nécessite un dispositif complémentaire. L'outil facilite la discipline ; il ne décide pas du sens économique.

La maturité se mesure à la capacité de produire une lecture fiable, d'expliquer les changements et de résoudre les anomalies. Elle ne dépend pas uniquement du nombre d'applications ou du degré d'automatisation.

Débutant : des listes locales et une cohérence manuelle

Les équipes entretiennent leurs propres fichiers de comptes, de produits ou de centres de coût. Les correspondances sont corrigées lors de chaque production, souvent sans historique partagé. Les personnes expérimentées compensent les défauts du modèle grâce à leur connaissance du terrain.

Signes distinctifs : définitions implicites, identifiants réutilisés, demandes par messages dispersés et difficultés à expliquer un ancien rattachement. La priorité est de créer un dictionnaire commun, de désigner les responsables et de stabiliser les objets nécessaires à un usage prioritaire.

Intermédiaire : un modèle partagé et des changements encadrés

Les principales dimensions ont des définitions communes. Les créations et modifications suivent un circuit identifié. Les correspondances sont centralisées, les contrôles récurrents et les dates d'effet documentées. Certains échanges restent manuels, mais leur exécution est vérifiable.

Signes distinctifs : registre des changements, contrôles de complétude, propriétaires métier actifs et procédure de publication. La limite habituelle se situe dans la synchronisation entre applications et dans la gestion des vues historiques. La priorité est de fiabiliser ces échanges et de tester les changements de bout en bout.

Avancé : une cohérence suivie dans tout le cycle de vie

Les responsabilités sont partagées entre domaines, les versions sont conservées et les applications consommatrices confirment les mises à jour. Les vues historiques et actuelles sont distinguées. Les anomalies sont suivies jusqu'à leur résolution, avec une mesure de leur impact sur les analyses.

Signes distinctifs : traçabilité des décisions, contrôles métier et techniques articulés, procédure de retour à un état antérieur et documentation utilisée au quotidien. L'enjeu devient l'adaptation continue du modèle, sans multiplier les catégories inutiles. Un niveau avancé peut conserver des tâches manuelles dès lors qu'elles sont maîtrisées, proportionnées et documentées.

Cette checklist sert à préparer un déploiement, à revoir un référentiel existant ou à autoriser un changement important. Une réponse positive doit pouvoir être appuyée par une définition, une règle ou une preuve de contrôle, pas seulement par une habitude orale.

• [ ] Les usages prioritaires et les applications qui consomment le référentiel sont-ils identifiés ?
• [ ] Chaque objet possède-t-il une définition métier compréhensible par les équipes qui l'utilisent ?
• [ ] Les données maîtres sont-elles distinguées des opérations et des paramètres de calcul ?
• [ ] Les identifiants sont-ils uniques dans le périmètre retenu et protégés contre une réutilisation trompeuse ?
• [ ] Les libellés peuvent-ils évoluer sans rompre les correspondances ni les analyses historiques ?
• [ ] Les attributs obligatoires et les valeurs autorisées sont-ils documentés ?
• [ ] Les hiérarchies répondent-elles à des questions de gestion explicites, avec des règles évitant les doubles comptes ?
• [ ] Les correspondances tiennent-elles compte du système source, de l'entité et des dates lorsque cela est nécessaire ?
• [ ] Un propriétaire métier et un gestionnaire courant sont-ils désignés pour chaque domaine ?
• [ ] Le circuit de création, de modification et de désactivation prévoit-il une approbation adaptée au risque ?
• [ ] La date d'effet est-elle distinguée de la date de publication et de la date d'approbation ?
• [ ] Les périodes passées restent-elles reproductibles avec les règles qui leur étaient applicables ?
• [ ] Les données inconnues ou non affectées sont-elles visibles, attribuées et suivies jusqu'à leur résolution ?
• [ ] Les contrôles vérifient-ils le sens métier autant que la validité technique ?
• [ ] Les tests couvrent-ils les totaux, les regroupements alternatifs et les changements d'organisation ?
• [ ] La prise en compte d'une publication est-elle confirmée par les applications destinataires ?
• [ ] Une procédure permet-elle de corriger une diffusion erronée et d'en mesurer les conséquences ?
• [ ] Les indicateurs ont-ils un périmètre, une formule, un responsable et une action associée ?

Les réponses négatives alimentent un plan d'action. Prioriser les anomalies qui rendent une analyse fausse ou empêchent sa production avant celles qui concernent seulement le confort d'utilisation.

À retenir : les référentiels et les master data finance donnent un sens commun aux montants. Leur fiabilité repose sur des définitions partagées, des responsabilités explicites, des correspondances contrôlées et un historique exploitable. Le logiciel soutient cette organisation, mais ne remplace pas les décisions métier.

Quelle différence entre référentiel et données maîtres ?

Le référentiel est le cadre organisé : codes, définitions, relations et règles. Les données maîtres sont les objets décrits dans ce cadre, comme les comptes ou les entités. Dans la pratique, le mot « référentiel » peut aussi désigner la liste de ces objets. Il est donc utile de préciser le sens retenu dans la documentation du projet.

Faut-il centraliser toutes les données dans un outil unique ?

Pas nécessairement. Une source officielle peut être désignée pour chaque domaine, avec des échanges contrôlés vers les autres applications. L'essentiel est de savoir qui décide, quelle donnée fait autorité et comment les mises à jour se propagent. Un fichier central sans responsabilité ni contrôle peut rester aussi fragile que des listes locales.

Comment gérer un changement d'organisation ?

Conserver l'ancien rattachement, enregistrer le nouveau avec sa date d'effet et choisir la vue d'analyse attendue. La lecture selon l'organisation d'époque et la lecture du passé selon l'organisation actuelle répondent à des besoins différents. Elles peuvent coexister, mais doivent être nommées et ne pas être mélangées dans une même comparaison.

Un taux de complétude élevé garantit-il des analyses fiables ?

Non. Un champ renseigné peut contenir une valeur erronée, et une correspondance valide techniquement peut avoir un sens économique incorrect. Il faut combiner indicateurs, contrôles métier et vérifications des résultats. La présence des données est nécessaire, mais elle ne suffit pas à démontrer leur qualité.

Par quoi commencer lorsque les référentiels sont dispersés ?

Choisir un usage dont les difficultés sont visibles, inventorier les objets réellement utilisés et nommer leurs responsables. Stabiliser ensuite les définitions et les correspondances, puis tester les résultats avant publication. Cette démarche limitée produit un cadre réutilisable sans attendre de résoudre tous les domaines de données de l'entreprise.