Études & Réflexions › Le référentiel de données : la fondation invisible de tout pilotage

Il existe une scène qui se rejoue dans presque toutes les entreprises. Deux personnes arrivent en réunion avec un chiffre. Ce n'est pas le même. Elles ont toutes les deux raison, et la réunion prévue pour décider se transforme en réunion pour réconcilier.

Le réflexe est d'accuser les outils. Le tableur du contrôle de gestion contre l'extraction du système de paie, le logiciel commercial contre la comptabilité. Ce n'est presque jamais le bon diagnostic. Les outils calculent correctement ; ils ne calculent simplement pas sur les mêmes objets, parce que personne n'a jamais écrit ce qu'était un objet.

Un référentiel de données, c'est cela : l'ensemble des définitions partagées qui font qu'un service, un salarié, un client ou un mois désignent la même chose partout dans l'entreprise. C'est la couche la moins visible du pilotage, et celle dont l'absence coûte le plus cher.

Ce qu'est un référentiel, et ce qu'il n'est pas

Un référentiel de données est un ensemble de listes de valeurs autorisées, assorties de règles de rattachement et d'un propriétaire identifié. Rien de plus. La liste officielle des services de l'entreprise, avec leur code, leur libellé, leur rattachement hiérarchique et leur date d'ouverture ou de fermeture, est un référentiel. La liste des motifs d'absence avec leur définition précise en est un autre.

Ce n'est pas un entrepôt de données. L'entrepôt stocke des faits, le référentiel définit les catégories dans lesquelles ces faits se rangent. On peut avoir un entrepôt parfaitement construit et des données inexploitables, parce que le même service y apparaît sous quatre codes différents selon la source.

Ce n'est pas non plus un projet informatique. La difficulté d'un référentiel n'est jamais technique. Elle est organisationnelle : il faut que quelqu'un tranche, dans l'entreprise, ce qu'est un effectif présent, et que cette décision s'impose ensuite aux ressources humaines comme au contrôle de gestion. C'est un travail d'arbitrage, pas de développement.

Un référentiel utile se reconnaît à une propriété concrète : il permet de répondre sans discussion à la question « d'où vient cette valeur et qui l'a décidée ». Chaque entrée porte une définition écrite en une phrase, un propriétaire, une date d'entrée en vigueur. Trois attributs, pas davantage, mais aucun des trois n'est facultatif : une définition sans propriétaire ne se maintient pas, un propriétaire sans date d'effet ne permet pas de reconstituer l'historique.

Enfin, ce n'est pas un document mort. Un référentiel qui n'est pas mis à jour à chaque réorganisation devient rapidement plus dangereux que son absence, parce qu'il donne une fausse assurance de cohérence.

Quatre symptômes d'une absence de référentiel

L'absence de référentiel ne se déclare jamais comme telle. Elle se manifeste par des symptômes qu'on attribue à autre chose.

La réunion de réconciliation. Une part significative du temps de réunion est consacrée à expliquer pourquoi deux chiffres diffèrent, avant de pouvoir parler du fond. Quand ce temps dépasse le quart de la réunion, le problème est structurel.

Le chiffre officieux. Chaque service maintient sa propre version « juste » des données, en parallèle du système officiel qu'il juge faux. Ces fichiers parallèles sont le signe le plus fiable d'un référentiel défaillant : les gens n'inventent pas de doublons par plaisir, ils compensent une définition qu'ils ne reconnaissent pas.

La question qui n'a pas de réponse rapide. « Combien de personnes travaillent sur le site de Lyon ? » devrait se répondre en quelques secondes. Quand la réponse demande deux jours et trois interlocuteurs, ce n'est pas un problème d'outil, c'est qu'il n'existe pas de définition unique de « travailler sur un site ».

Le rapport qui se refait à la main. Un état produit automatiquement puis systématiquement retouché avant diffusion signale que le référentiel utilisé par l'outil ne correspond pas à celui que la direction reconnaît. La retouche manuelle est un correctif de référentiel qui ne dit pas son nom, et elle disparaît avec la personne qui la pratique.

L'historique impossible. Comparer l'effectif d'aujourd'hui à celui d'il y a trois ans devient impossible parce que l'organisation a changé et que personne n'a conservé la correspondance entre l'ancienne et la nouvelle structure. C'est le symptôme le plus coûteux, parce qu'il détruit rétroactivement toute capacité d'analyse de tendance.

Les trois objets à normaliser en priorité

Une entreprise manipule des dizaines d'objets. Trois seulement méritent l'effort initial, parce que presque toutes les analyses les croisent.

La structure organisationnelle

C'est l'objet le plus structurant et le plus instable. Il exige un identifiant technique stable, distinct du libellé : un service qui change de nom garde son code, ce qui préserve l'historique. Il exige aussi des dates de validité, parce que la structure de 2024 et celle de 2026 doivent pouvoir coexister dans le référentiel pour permettre les comparaisons.

La règle qui évite le plus de dégâts : ne jamais réutiliser un code libéré. Un code de service fermé reste fermé pour toujours. Le réemploi d'un code crée des fusions silencieuses d'historique, quasi indétectables une fois installées.

Le calendrier de gestion

Objet apparemment trivial, en pratique source d'écarts massifs. Qu'est-ce qu'un mois ? Le mois calendaire, le mois de paie, le mois comptable après clôture ? Les trois existent dans la plupart des entreprises et ne coïncident pas. Un même événement peut ainsi tomber en juin pour la paie et en juillet pour la comptabilité.

Le référentiel calendaire doit expliciter la correspondance entre ces mailles et désigner celle qui fait foi pour chaque type d'analyse. Sans cela, les écarts de fin de trimestre restent inexplicables.

L'identité des tiers

Clients, fournisseurs, salariés. La question est celle de l'identifiant unique. Pour les entreprises, le numéro SIRET fournit une clé nationale fiable, disponible gratuitement via la base SIRENE de l'INSEE, ce qui évite d'inventer une nomenclature maison. Pour les salariés, l'identifiant du système de paie fait généralement autorité.

Ces trois objets ont une propriété commune : ils servent d'axes de lecture à presque toutes les analyses. Le chiffre d'affaires se lit par tiers, par période et par entité ; la masse salariale par service, par mois et par salarié. Normaliser ces trois axes rend cohérentes des dizaines d'analyses d'un coup, alors que normaliser un objet périphérique n'en améliore qu'une.

Le piège habituel est le doublon commercial : la même entreprise saisie trois fois avec trois orthographes. Il ne se résout pas par le nettoyage ponctuel, mais par une règle de création qui impose la vérification avant saisie.

Qui est propriétaire de quoi

Un référentiel sans propriétaire désigné se dégrade en quelques mois. C'est la partie la moins technique et la plus déterminante du dispositif.

La propriété se définit par objet, pas globalement. La direction des ressources humaines est propriétaire de la structure organisationnelle et du référentiel des emplois. La direction financière est propriétaire du calendrier de gestion et du plan analytique. La direction commerciale est propriétaire du référentiel client. Cette répartition suit une règle simple : est propriétaire celui qui subit le plus directement les conséquences d'une donnée fausse.

Le propriétaire assume trois obligations concrètes : arbitrer les demandes de création et de modification, publier les changements avant leur entrée en vigueur, et conserver l'historique des versions. La deuxième obligation est celle qu'on oublie le plus souvent, et c'est celle qui protège les analyses en cours.

Ce dispositif de responsabilité est le cœur de ce que recouvre la gouvernance des données. Beaucoup d'organisations abordent ce sujet par le comité et la charte, alors qu'il commence par une question beaucoup plus prosaïque : qui a le droit de créer un nouveau code service, et qui doit en être informé.

Construire un référentiel sans projet à deux cents jours

La tentation du référentiel exhaustif est la principale cause d'échec. Vouloir normaliser tous les objets avant d'en utiliser un seul produit des chantiers de dix-huit mois qui n'aboutissent pas. La méthode qui fonctionne procède par usage.

• Partir d'une question réelle. Choisir une analyse que la direction réclame et qui échoue aujourd'hui faute de données cohérentes. C'est elle qui définit le périmètre du premier référentiel, pas l'inverse.
• Normaliser le strict nécessaire. Pour cette question précise, quels objets doivent être définis ? Généralement deux ou trois, pas quinze. On les définit, on les documente, on les publie.
• Faire trancher, pas consulter. Les définitions concurrentes ne se concilient pas par consensus. Elles se tranchent par le propriétaire désigné, en trente minutes, avec un arbitrage écrit et daté.
• Livrer l'analyse. La démonstration de valeur doit intervenir en quelques semaines. C'est elle qui finance politiquement l'extension du référentiel aux objets suivants.
• Étendre par traction. Chaque nouvelle question fait apparaître les objets suivants à normaliser. Le référentiel grandit par besoin réel, ce qui garantit qu'il reste utilisé.

Un point mérite d'être explicite : chaque arbitrage doit produire une trace écrite courte, indiquant la définition retenue, celle qui a été écartée et la raison. Ce document de quelques lignes évite que la question soit rouverte tous les six mois par un nouvel arrivant, ce qui est le mode d'érosion le plus fréquent des référentiels jeunes.

Cette approche par l'usage donne un référentiel partiel mais vivant, ce qui vaut infiniment mieux qu'un référentiel complet et ignoré. Elle rejoint la logique de progression décrite dans le diagnostic de maturité data : on avance par paliers utilisables, pas par grands sauts.

Pourquoi l'IA rend le sujet critique

Le référentiel était jusqu'ici un sujet de confort analytique. L'entrée de l'intelligence artificielle dans les processus de gestion en fait un sujet de fiabilité.

La raison tient à une différence de comportement en cas de données incohérentes. Un tableau croisé produit sur des données mal référencées donne un résultat visiblement bizarre : un total qui ne tombe pas juste, une ligne « non affecté » anormalement grosse. L'analyste le voit et enquête. Un modèle de langage interrogé sur les mêmes données produit une phrase parfaitement formée, assortie d'un chiffre plausible, sans aucun signal d'alerte.

Le même mécanisme joue sur les modèles prédictifs. Un modèle entraîné sur un historique où le service commercial a changé trois fois de code apprend des ruptures qui n'ont aucune réalité métier, et projette ces artefacts dans ses prévisions. La qualité du modèle ne compense jamais l'absence de référentiel ; elle la rend plus difficile à détecter.

C'est particulièrement vrai pour les dispositifs de type recherche augmentée sur documents internes, où la réponse produite emprunte son autorité à la source citée. Si la source repose sur des catégories floues, l'autorité est empruntée à tort.

La conséquence pratique est simple à formuler : le référentiel n'est plus un préalable souhaitable aux projets d'intelligence artificielle appliqués à la gestion, il en est la condition de fiabilité. Une organisation qui investit dans l'IA avant d'avoir normalisé ses trois objets prioritaires industrialise ses propres incohérences.

Le coût de l'inaction

Le coût d'un référentiel absent ne figure sur aucune ligne budgétaire, ce qui explique qu'il soit rarement traité. Il se répartit en trois postes, tous réels.

Le temps de réconciliation. Chaque analyse produite dans une organisation sans référentiel comporte une phase de vérification et d'explication des écarts. Cette phase est invisible parce qu'elle est diffuse, mais elle se paie en jours de contrôle de gestion et en heures de réunion de direction.

La décision retardée. Quand un chiffre est contesté, la décision qu'il devait éclairer est reportée. Ce report a un coût propre, développé dans le coût caché de la non-décision, et il est d'autant plus pernicieux qu'il se présente comme de la prudence.

La perte de confiance. C'est le poste le plus lourd et le plus long à reconstituer. Une direction qui a été contredite deux fois par des chiffres divergents cesse de s'appuyer sur les données et revient à l'intuition. Le dispositif de pilotage, quel qu'en soit le coût, devient alors décoratif.

Rapporté à ces trois postes, l'effort de normalisation initial est modeste : quelques semaines pour les trois objets prioritaires, puis un entretien continu de faible intensité. Le rapport est rarement aussi favorable sur les autres chantiers de pilotage.

FAQ

Quelle différence entre un référentiel de données et un entrepôt de données ?

L'entrepôt de données stocke des faits : des ventes, des heures travaillées, des écritures comptables. Le référentiel définit les catégories dans lesquelles ces faits se rangent : la liste officielle des services, celle des motifs d'absence, celle des familles de produits. Les deux sont indépendants. On peut disposer d'un entrepôt techniquement irréprochable et de données inexploitables, parce que le même service y apparaît sous plusieurs codes selon la source. À l'inverse, un référentiel solide rend exploitables des données stockées dans des outils très ordinaires.

Par quel objet commencer quand on part de zéro ?

Par la structure organisationnelle, dans la quasi-totalité des cas. C'est l'objet que croisent presque toutes les analyses, financières comme sociales, et c'est aussi le plus instable puisqu'il change à chaque réorganisation. Deux règles suffisent pour le rendre robuste : un identifiant technique stable distinct du libellé, de sorte qu'un changement de nom ne casse pas l'historique, et des dates de validité permettant à plusieurs versions de la structure de coexister. Le calendrier de gestion et l'identité des tiers viennent ensuite.

Faut-il un logiciel dédié pour gérer un référentiel ?

Non, et commencer par l'achat d'un outil est l'erreur classique. La difficulté d'un référentiel est organisationnelle, pas technique : il faut que quelqu'un tranche ce qu'est un effectif présent et que cette décision s'impose à tous les services. Un tableur versionné, publié à date fixe et doté d'un propriétaire identifié rend le service attendu pendant longtemps. L'outil dédié devient utile quand le nombre d'objets et la fréquence des mises à jour rendent la diffusion manuelle ingérable, pas avant.

Qui doit être propriétaire d'un référentiel ?

La propriété se définit objet par objet, jamais globalement, et suit une règle simple : est propriétaire celui qui subit le plus directement les conséquences d'une donnée fausse. Les ressources humaines pour la structure organisationnelle et les emplois, la direction financière pour le calendrier de gestion et le plan analytique, la direction commerciale pour le référentiel client. Le propriétaire assume trois obligations : arbitrer les créations et modifications, publier les changements avant leur entrée en vigueur, conserver l'historique des versions.

Pourquoi l'intelligence artificielle rend-elle le référentiel plus critique ?

Parce qu'elle supprime les signaux d'alerte. Une analyse classique produite sur des données incohérentes donne un résultat visiblement anormal : un total qui ne tombe pas juste, une catégorie « non affecté » démesurée. L'analyste le remarque. Un modèle de langage interrogé sur les mêmes données produit une phrase bien formée assortie d'un chiffre plausible, sans aucune anomalie apparente. Les modèles prédictifs souffrent d'un défaut symétrique : entraînés sur un historique aux catégories mouvantes, ils apprennent des ruptures sans réalité métier et les projettent dans leurs prévisions.

Brice Béchet

Consultant en pilotage des organisations

Contrôleur de gestion sénior, data scientist et créateur d'effectivo.fr, application de prévision stratégique des effectifs (Anticipez. Simulez. Décidez), j'accompagne les organisations à structurer leurs données et optimiser leur pilotage.

En savoir plus LinkedIn