Quel mot veut dire quoi, exactement ?

Question concrète : quand le commerce dit « client actif », quand la finance dit « client facturé », et quand l’exploitation dit « client en cours », parle-t-on de la même chose ? Si la réponse hésite, vous n’avez pas un problème d’outil ; vous avez un problème de vocabulaire. L’Insee rappelle que les métadonnées définissent ce à quoi se réfère un chiffre et que la qualité d’une donnée tient à son aptitude à l’usage, pas à une vérité abstraite. De son côté, la CNIL relie la documentation des traitements à la réalité opérationnelle, via le registre et la cartographie.

paragraphs2?placeholder?ignore this line? no because format expects paragraphs array only

  • Un dictionnaire de données répond à une seule question par champ : que signifie-t-il, qui le crée, où vit-il, et dans quel cas peut-on s’y fier.
  • S’il manque cette base, chaque tableau de bord devient une réunion déguisée.
  • Le bon objectif n’est pas la perfection : c’est la même définition comprise par les équipes qui produisent, exploitent et contrôlent la donnée.

Le format minimal qui suffit vraiment

Commencez petit. Un dictionnaire utile tient dans un tableau partagé, pas dans une cathédrale documentaire. Pour chaque champ, gardez six colonnes : nom du champ, définition métier, type ou format, source, responsable, règles d’usage. L’Insee montre l’intérêt d’un référentiel qui structure et centralise les métadonnées avec des règles d’identification ; NIST définit les métadonnées comme des informations décrivant les caractéristiques des données, y compris leur structure et leurs usages acceptables.

paragraphs2?placeholder?ignore this line? no because format expects paragraphs array only

  • Nom du champ : terme court, stable, sans acronymes ambigus.
  • Définition métier : phrase simple, lisible par un commercial et un contrôleur de gestion.
  • Source : système ou fichier d’origine, pas une interprétation.
  • Responsable : une personne nommée, pas « l’équipe data ».
  • Règles d’usage : filtres, exceptions, calculs autorisés, cas interdits.
  • Statut : proposé, validé, obsolète.

Méthode en quatre ateliers, sans usine à gaz

Atelier 1, cadrage : choisissez un périmètre métier limité, par exemple les ventes, la facturation ou le support. La CNIL recommande de partir des traitements réels, des acteurs et des flux ; c’est exactement la bonne logique pour un dictionnaire. Atelier 2, collecte : demandez à chaque équipe les dix champs qu’elle utilise le plus, puis identifiez les doublons et les faux synonymes. Atelier 3, arbitrage : organisez une courte séance où un seul responsable tranche les divergences de définition, avec le métier concerné, la finance et l’IT. Atelier 4, publication : rangez la version validée dans un espace unique, visible, avec une date de révision et un propriétaire.

paragraphs2?placeholder?ignore this line? no because format expects paragraphs array only

  • Interdisez les champs « connus de tous » : ce sont précisément ceux qui créent le plus d’erreurs.
  • N’acceptez pas deux définitions pour le même terme sans un usage explicitement différent.
  • Ajoutez un exemple concret par définition : une valeur valide et une valeur invalide.

Exemple chiffré fictif : le champ « client actif »

Imaginons une PME de services avec 1 200 comptes. Le commerce appelle « client actif » tout compte ayant signé dans les 12 derniers mois ; la facturation ne retient que les comptes ayant émis au moins une facture depuis 90 jours ; le support considère actif tout client ayant ouvert au moins un ticket. Résultat : trois reporting, trois totaux, trois débats. Après un atelier de 45 minutes, l’entreprise fixe une seule définition par indicateur. Pour « client actif commercial », la règle devient : compte facturé au moins une fois et sans résiliation enregistrée. Les autres usages gardent leur propre libellé. En un mois, les écarts de synthèse baissent parce que chacun sait quel indicateur il consulte. C’est une inférence de méthode, pas une promesse magique : la clarté réduit les conflits, elle n’efface pas les données manquantes.

paragraphs2?placeholder?ignore this line? no because format expects paragraphs array only

  • Séparez les notions proches par l’usage, pas par l’intuition.
  • Documentez les exceptions avant qu’elles ne deviennent la règle.
  • Si un indicateur sert à piloter une décision, sa définition doit être figée avant le calcul.

Limites, gouvernance et bon sens d’entreprise

Un dictionnaire de données n’est pas un parapluie universel. Il ne corrige ni une saisie incomplète, ni un identifiant absent, ni un export Excel mal exporté. Il ne remplace pas non plus les obligations RGPD : dès lors qu’un champ peut identifier une personne physique, il entre dans le champ des données personnelles et doit être documenté avec le reste du traitement. Pour une PME, la limite principale est organisationnelle : si personne n’est propriétaire du vocabulaire, le dictionnaire meurt en quinze jours. La bonne gouvernance ressemble à cela : un sponsor dirigeant, un responsable métier par domaine, un arbitre en cas de conflit, et une revue mensuelle courte.

paragraphs2?placeholder?ignore this line? no because format expects paragraphs array only

  • Ne confondez pas dictionnaire de données et catalogue d’outils.
  • N’ouvrez pas dix chantiers : commencez par les 20 champs qui alimentent 80 % des décisions.
  • Gardez un historique des changements : un terme qui change sans trace crée de faux comparables.

Checklist actionnable sur 7 jours

Jour 1 — Propriétaire : direction ou DSI, selon votre taille. Résultat observable : un périmètre de départ écrit en une phrase. Jour 2 — Propriétaire : métier. Résultat observable : la liste des 20 champs les plus utilisés. Jour 3 — Propriétaire : data/IT. Résultat observable : un tableau partagé avec les six colonnes minimales. Jour 4 — Propriétaire : métiers concernés. Résultat observable : trois définitions ambiguës requalifiées ou séparées. Jour 5 — Propriétaire : DPO si données personnelles, sinon référent conformité. Résultat observable : les champs sensibles repérés. Jour 6 — Propriétaire : sponsor. Résultat observable : une version 1 validée et datée. Jour 7 — Propriétaire : chaque équipe utilisatrice. Résultat observable : un test simple où deux personnes trouvent la même définition sans se téléphoner.

  • Si le test échoue, la documentation est encore trop technique.
  • Si le test réussit, publiez la version 1 et programmez la version 2.
  • Le bon critère de réussite n’est pas la beauté du document, mais la baisse visible des désaccords.