Un dictionnaire des données utile relie chaque champ à sa définition métier, son format, son origine, ses règles de calcul et son responsable. Dans un socle décisionnel, il devient le support de la recette, de la reprise des rapports et de la réconciliation des écarts lors d’une évolution.
En bref
- Un dictionnaire des données ne se limite pas à la liste des colonnes d’une table : il documente les métadonnées, les règles de gestion et les usages décisionnels.
- Le format doit permettre à la fois la lecture par les équipes métier et le contrôle technique par les équipes BI, ETL et base de données.
- Une définition sans source, sans propriétaire ni date de validation devient vite inutilisable lors d’une recette ou d’une migration.
- La tenue à jour doit être intégrée au workflow de changement, pas confiée à une révision annuelle isolée.
Ce contenu s’adresse aux responsables BI, chefs de projet décisionnel et équipes de recette qui doivent documenter un infocentre, un entrepôt de données ou un modèle sémantique. Il ne traite pas de gouvernance juridique des données personnelles, sujet qui relève du DPO et des équipes compétentes.
Que doit contenir un dictionnaire des données exploitable en décisionnel ?
Un dictionnaire des données exploitable commence par une identification sans ambiguïté de l’objet décrit. Une mesure de chiffre d’affaires, une colonne de statut client ou une date de livraison ne peuvent pas être documentées seulement par leur nom technique. Le lecteur doit savoir où l’objet est stocké, qui l’alimente, dans quels rapports il apparaît et selon quelle règle il est calculé.
Dans un univers BusinessObjects, le nom visible dans Web Intelligence peut différer du nom de colonne physique, du mapping ETL et de l’intitulé utilisé par la direction financière. C’est précisément à cet endroit que le dictionnaire évite les erreurs de reprise. Sans cette correspondance, un objet nommé « CA net » peut être reconstruit avec un périmètre de factures différent de celui du rapport historique.
Les métadonnées qui expliquent réellement un champ
Le contenu minimal doit distinguer l’identifiant technique, le libellé métier, la description, le type, la taille et le format de restitution. Un entier, un décimal à deux positions, une date ISO ou une chaîne de trente caractères ne produisent pas les mêmes contrôles. Cette précision limite les écarts lors du chargement d’une table cible ou de la publication d’un modèle sémantique.
La description métier doit aller plus loin qu’un intitulé reformulé. Pour une mesure de marge, elle doit préciser les composants inclus et exclus. Pour un statut client, elle doit indiquer si la valeur provient du CRM, d’un référentiel tiers ou d’une règle calculée dans le flux. Une phrase telle que « montant de la marge » ne permet aucune recette sérieuse.
Le dictionnaire doit aussi faire apparaître les contraintes. Une valeur obligatoire, un domaine de valeurs autorisées, une clé primaire, une clé étrangère ou une règle de non-nullité changent la manière de contrôler les données. Une colonne de code pays peut contenir deux lettres, trois lettres ou un libellé libre selon le système source. Cette différence semble mineure jusqu’au moment où un rapprochement échoue sur plusieurs milliers de lignes.
| Élément documenté | Information attendue | Usage dans un socle décisionnel | Risque si l’information manque |
|---|---|---|---|
| Nom métier | Libellé compris par les utilisateurs et définition précise | Recherche d’un indicateur dans un univers ou un modèle sémantique | Deux indicateurs proches sont confondus dans les rapports |
| Origine | Application source, table, flux ETL et fréquence de chargement | Analyse d’un écart entre source et restitution | Les équipes cherchent le défaut au mauvais endroit |
| Format | Type, longueur, séparateur, devise, décimales et règle d’arrondi | Reprise d’une colonne calculée ou contrôle de restitution | Les écarts sont attribués à tort à la cible |
| Règle de calcul | Formule, filtre, période et exclusions appliquées | Recette d’une mesure financière ou commerciale | Le nouveau rapport couvre un périmètre différent |
| Responsable | Propriétaire métier et interlocuteur technique | Validation d’une évolution ou d’une anomalie | La décision reste bloquée faute d’arbitrage |
Le tableau précédent croise le contenu attendu, son usage et le risque opérationnel. Il est plus utile qu’une liste théorique, car il place chaque métadonnée face à une situation de projet. Dans un chantier de migration, la colonne « origine » sert souvent à séparer un défaut de source d’une erreur de mapping.
Les relations entre objets doivent être décrites avec le même niveau de précision. Une dimension Client reliée à une table de factures peut produire des doublons si le grain de la relation n’est pas connu. Dans un modèle sémantique, la cardinalité et le sens de filtrage modifient directement les résultats affichés par les visuels.
La documentation doit enfin indiquer le contexte d’utilisation. Un champ peut être présent dans la base mais réservé à un contrôle technique, tandis qu’un autre sert à calculer un indicateur diffusé chaque mois. Cette séparation évite de reprendre des colonnes sans usage réel et aide à identifier les objets qui doivent entrer dans la recette.
Le dictionnaire devient particulièrement utile lorsqu’il est rapproché de l’inventaire des rapports. Un infocentre bien délimité peut contenir moins de tables qu’un entrepôt complet, mais ses définitions métier doivent être aussi rigoureuses. Une colonne non documentée ne pose pas seulement un problème de classement : elle fragilise la décision prise à partir d’elle.
Quel format de dictionnaire des données choisir selon le périmètre ?
Le format d’un dictionnaire des données dépend d’abord de l’usage attendu. Une feuille de calcul peut convenir pour inventorier un périmètre limité avant une migration. Elle atteint toutefois ses limites lorsque plusieurs équipes modifient les définitions, lorsque les objets dépassent quelques centaines de lignes ou lorsque les règles de calcul doivent être reliées aux flux ETL et aux rapports.
Le document PDF figé est rarement adapté à la maintenance. Il donne une photographie exploitable pour un audit, mais il devient obsolète dès qu’une colonne, un filtre de sécurité ou une règle de calcul évolue. Un export PDF peut être conservé comme pièce de validation, sans devenir la source de référence.
Une structure lisible par le métier et contrôlable par la technique
Pour un parc décisionnel, le format le plus robuste sépare plusieurs niveaux. Le premier niveau décrit les domaines métier, comme ventes, achats, stocks, production ou finance. Le deuxième recense les entités et les mesures. Le troisième rattache ces objets aux tables, aux mappings, aux univers, aux modèles sémantiques et aux rapports qui les utilisent.
Cette structuration évite une documentation conçue comme un annuaire de colonnes. Une mesure « commandes facturées » doit être liée à son grain, à sa période d’alimentation et à ses exclusions. Si les avoirs sont retirés dans un flux ETL, mais réintégrés par une colonne calculée dans un rapport, la règle doit apparaître avec son emplacement exact.
Un format tabulaire reste très efficace lorsqu’il respecte des normes de nommage. Les identifiants techniques peuvent être normalisés avec un préfixe de domaine, tandis que les libellés métier restent lisibles. Le point important n’est pas de multiplier les abréviations : il est de pouvoir retrouver le même objet dans une source, une cible et une restitution.
- Commencez par fixer le grain de chaque objet, par exemple une ligne de facture, une commande, un client ou un jour.
- Documentez ensuite les champs utilisés dans les indicateurs et non toutes les colonnes techniques sans distinction.
- Ajoutez l’origine exacte, y compris le nom du flux, de la requête ou de la table intermédiaire.
- Décrivez les règles de calcul avec les filtres, les exclusions et les règles d’arrondi.
- Associez une date de validation et un responsable à chaque définition ayant une portée métier.
Dans une migration BusinessObjects vers Power BI ou Qlik Sense, ce format facilite le rapprochement entre les objets sources et les mesures cibles. Le sujet ne consiste pas à transposer mot pour mot les objets d’univers. Il s’agit de vérifier quelle logique doit survivre, quel filtre doit être déplacé dans la mesure et quelle règle historique doit être abandonnée après validation métier.
La comparaison entre cibles décisionnelles ne remplace pas ce travail. Le choix entre les outils dépend du parc, des usages et des contraintes de diffusion, comme l’explique cette analyse consacrée à Power BI, Qlik Sense et BusinessObjects. Quelle que soit la cible, un modèle sémantique sans définitions stabilisées reproduit les ambiguïtés de l’ancien socle sous une autre interface.
Les formats lisibles par machine ont leur place lorsque la documentation doit être intégrée aux chaînes de déploiement. CSV, YAML ou tables de référentiel permettent de contrôler les champs obligatoires, de comparer deux versions et de publier une documentation. Ils ne remplacent pas le texte métier. Un champ peut être techniquement complet tout en restant incompréhensible pour le contrôleur de gestion qui doit valider la mesure.
DBT illustre cette séparation. La documentation générée à partir des modèles, sources et tests offre une base utile pour décrire les transformations. La documentation officielle de dbt, consultée en mars 2026, précise que les descriptions sont renseignées dans les fichiers du projet puis rendues dans un site de documentation. L’automatisation publie ce qui a été écrit ; elle ne crée ni la définition métier ni l’arbitrage sur le périmètre d’un indicateur.
Un bon format ne résout donc pas une absence de décision. Il rend cette absence visible, ce qui est déjà préférable à une règle enfouie dans un rapport Web Intelligence ou dans une requête SQL non versionnée.
Comment documenter les règles de calcul sans masquer les écarts de chiffres ?
La partie la plus sensible du dictionnaire concerne les règles de calcul. Les colonnes physiques sont souvent connues des équipes techniques. Les différences qui bloquent une recette viennent plutôt des filtres, des jointures, des périodes de référence, des valeurs exclues et des conditions appliquées à un objet d’univers ou à une mesure.
Une mesure de chiffre d’affaires peut, par exemple, exclure les factures annulées, filtrer certains statuts de commande et retenir la date de comptabilisation plutôt que la date d’expédition. Chaque choix est défendable s’il est formulé, tracé et validé. Le problème commence lorsque la règle n’existe que dans un rapport historique consulté par une personne qui ne participe pas au projet.
Décrire une mesure avec son périmètre réel
La formule doit être écrite dans le dictionnaire avec une formulation compréhensible et avec sa traduction technique. La formulation métier précise ce qui est compté. La traduction technique nomme les champs utilisés, les conditions, les jointures et les éventuels calculs intermédiaires. Les deux lectures servent à des moments différents de la recette.
Pour une marge commerciale, la description peut indiquer que l’indicateur correspond aux ventes nettes diminuées du coût d’achat, hors écritures de régularisation identifiées par un code comptable donné. La documentation technique doit ensuite indiquer où se trouvent ces exclusions. Si elles sont appliquées dans un flux Informatica PowerCenter, dans une requête BW ou dans une condition d’objet BusinessObjects, la localisation change la stratégie de reprise.
Les écarts entre ancien et nouveau socle doivent être prévus, pas niés. Un changement de fuseau horaire, un arrondi déplacé, une dimension mise à jour plus tôt ou une jointure corrigée peut faire varier un résultat. La recette doit définir une tolérance, un périmètre de comparaison et une méthode d’explication. Aucun dictionnaire sérieux ne promet que deux restitutions produiront mécaniquement les mêmes chiffres.
| Point de contrôle | Ancien socle | Cible décisionnelle | Vérification attendue |
|---|---|---|---|
| Date de référence | Date de facture ou date de comptabilisation selon le rapport | Colonne de date utilisée par la mesure | Comparer les mêmes périodes et documenter la règle retenue |
| Statut de transaction | Condition d’objet, filtre de rapport ou filtre ETL | Filtre dans le modèle ou dans la mesure | Tester séparément les statuts exclus et inclus |
| Arrondi | Arrondi au niveau ligne ou total | Règle appliquée dans la mesure cible | Comparer l’effet sur un échantillon puis sur le total |
| Jointure | Contexte d’univers ou requête source | Relation du modèle sémantique | Contrôler les doublons et les lignes non rapprochées |
Ce tableau doit être relié au dictionnaire des données et non produit uniquement pour la réunion de recette. Chaque contrôle renvoie à une définition et à un objet documenté. Lorsque la direction financière questionne un écart, le projet doit pouvoir répondre en partant du périmètre et non d’une interprétation orale.
Une méthode de comparaison utile consiste à préparer un échantillon de lignes détaillées, puis à comparer les agrégats par période, entité et statut. Si le total diffère, l’équipe descend au grain le plus fin disponible. Le dictionnaire indique alors quels identifiants permettent ce rapprochement, par exemple numéro de facture, code article, société et date comptable.
Les rapports n’ont pas tous la même valeur de reprise. Un rapport ouvert rarement mais porteur d’une règle de gestion non documentée peut devoir être étudié avant d’être retiré. À l’inverse, un rapport largement consulté mais composé d’indicateurs déjà couverts par le nouveau modèle peut être remplacé sans reprise écran pour écran. La documentation sert à arbitrer cette différence.
Les sujets de performance doivent rester distingués des règles métier. Une solution in-memory en BI peut modifier les temps de réponse ou les possibilités de modélisation, mais elle ne définit pas le périmètre d’un chiffre d’affaires. Mélanger les deux conduit à faire valider une contrainte technique comme si elle était une règle de gestion.
Une mesure n’est prête pour la bascule que lorsque sa formule, ses exclusions, sa source, sa date de validation et son protocole de contrôle figurent dans la même documentation. Sans cela, l’équipe compare des résultats sans disposer du vocabulaire nécessaire pour expliquer l’écart.
Comment organiser la tenue à jour du dictionnaire des données ?
La tenue à jour échoue lorsque le dictionnaire est traité comme un livrable de fin de projet. La documentation est alors remplie au moment où les équipes cherchent déjà à clôturer la recette. Les définitions sont incomplètes, les responsables ne sont plus disponibles et les changements opérés en cours de chantier ne sont pas intégrés.
La mise à jour doit au contraire faire partie du processus de changement. Toute évolution d’une table, d’un mapping, d’une mesure, d’un objet d’univers ou d’un filtre de sécurité doit déclencher une vérification de la documentation associée. Cette règle paraît administrative jusqu’au premier incident où un rapport affiche une rupture de série sans explication disponible.
Attribuer une responsabilité sans créer un goulot d’étranglement
Chaque définition métier doit avoir un propriétaire identifié. Ce propriétaire ne rédige pas nécessairement les détails techniques, mais il valide le sens de l’indicateur, son périmètre et son utilisation. Les équipes BI maintiennent la correspondance avec les sources, les flux et les modèles. Cette séparation évite qu’un administrateur technique tranche seul une question de règle comptable.
Le workflow de modification doit comporter une demande, une analyse d’impact, une validation, une date d’effet et une trace de version. La demande peut être légère pour une correction de libellé. Elle doit être plus formelle lorsqu’un changement modifie une mesure diffusée à la direction, un filtre de population ou une règle d’historisation.
Un historique lisible doit indiquer ce qui a changé et pourquoi. « Mise à jour du champ » ne permet aucune analyse. « Exclusion des transactions de test à compter du chargement de mars, appliquée dans le flux de préparation » donne une information vérifiable, utile lors d’une comparaison de périodes.
- La revue mensuelle doit cibler les objets modifiés dans les flux, les univers et les modèles sémantiques depuis la dernière publication.
- La revue trimestrielle peut contrôler les définitions des indicateurs diffusés aux directions métier et les rapports les plus consultés.
- Une revue avant bascule doit vérifier les objets du périmètre de recette, les droits d’accès et les règles d’historisation.
- Une revue après incident doit compléter la documentation lorsque l’analyse révèle une règle jusqu’alors implicite.
La périodicité ne dispense pas d’une mise à jour au fil de l’eau. Une revue trimestrielle ne corrigera pas à temps une règle modifiée dans un ETL la veille d’une clôture. La bonne pratique consiste à intégrer un contrôle documentaire dans le ticket de changement et dans le circuit de déploiement.
Le dictionnaire doit rester accessible aux personnes qui en ont besoin, avec des droits adaptés à son contenu. Les informations portant sur l’accès à des données sensibles ou les habilitations nominatives doivent être traitées avec prudence. Les obligations relatives à la protection des données personnelles dépassent le périmètre décisionnel traité ici et doivent être examinées avec le DPO.
Une base documentaire isolée du projet finit souvent par être abandonnée. Il est préférable de relier les objets documentés aux tickets, aux scripts de transformation, aux spécifications de rapport et aux cas de recette. L’utilisateur qui détecte un écart doit pouvoir passer du rapport concerné à la définition de la mesure, puis à son origine technique.
Le format choisi doit également faciliter la recherche. Une documentation structurée par domaines, entités et indicateurs est plus durable qu’un fichier unique contenant plusieurs milliers de lignes sans filtre ni convention. Les normes de nommage et la qualité des libellés réduisent la charge de recherche, sans remplacer la responsabilité des propriétaires.
Une documentation mise à jour au même rythme que le socle ne garantit pas l’absence d’écart. Elle garantit en revanche que l’écart peut être attribué à une règle, une source ou une modification identifiable, ce qui change la qualité de l’arbitrage.
Dans quel ordre construire un dictionnaire des données pour une migration ?
La construction doit partir des usages réellement critiques et non d’une ambition de recensement exhaustif immédiat. Dans un parc de plusieurs centaines de rapports, documenter toutes les colonnes avant d’identifier les restitutions encore utilisées consomme du temps sans réduire le risque de bascule. Le premier objectif consiste à isoler les indicateurs, dimensions et règles dont dépend le pilotage.
Les logs de consultation, lorsqu’ils existent et couvrent une période suffisamment longue, permettent de séparer les rapports actifs des rapports abandonnés. Leur interprétation demande de la prudence. Un rapport trimestriel ou annuel peut sembler inactif sur une période trop courte, alors qu’il reste requis pour une clôture ou un audit.
Commencer par l’inventaire des objets qui portent une décision
Le premier lot doit regrouper les rapports diffusés régulièrement, les indicateurs financiers, les suivis opérationnels et les tableaux utilisés lors des instances de pilotage. Pour chacun, le dictionnaire doit relier le visuel ou le tableau à ses mesures, dimensions, filtres et sources. Cette cartographie établit un périmètre de recette défendable.
Le deuxième lot couvre les règles techniques qui ne sont visibles dans aucun rapport. Il peut s’agir d’un mapping de code, d’une règle de dédoublonnage, d’un calcul de date ou d’un filtre appliqué dans un flux. Ces règles déterminent parfois le résultat final plus fortement que la présentation du rapport elle-même.
Le troisième lot concerne les objets à retirer ou à archiver. Cette décision doit être documentée avec un motif clair : absence d’usage observé, doublon fonctionnel, donnée source supprimée ou indicateur remplacé. Archiver une définition reste préférable à la supprimer sans trace, surtout lorsqu’un contrôle ultérieur demande d’expliquer une série historique.
| Lot de travail | Périmètre prioritaire | Documentation attendue | Décision produite |
|---|---|---|---|
| Lot 1 | Rapports et indicateurs de pilotage | Règles de calcul, filtres, sources et propriétaire métier | Construction du périmètre de recette |
| Lot 2 | Flux ETL, mappings et règles de préparation | Transformations, fréquence et contrôles de qualité | Analyse des écarts et reprise technique |
| Lot 3 | Rapports peu consultés ou redondants | Motif d’archivage, dépendances et date de décision | Réduction du périmètre à migrer |
| Lot 4 | Objets créés ou modifiés pendant le chantier | Version, date d’effet et validation | Maintien de la cohérence jusqu’à la bascule |
Le tableau organise la charge par valeur décisionnelle, et non par ordre alphabétique des tables. Cette approche ne dispense pas de documenter les éléments techniques nécessaires. Elle évite surtout de consacrer les premières semaines à des objets que personne ne consultera dans la cible.
Une estimation de charge peut être menée à partir du volume d’objets prioritaires. Un périmètre de 80 indicateurs, 40 dimensions et 25 règles de transformation ne représente pas 145 entrées équivalentes. Une mesure financière complexe peut demander plusieurs échanges métier et plusieurs cas de recette, alors qu’une dimension de code stable peut être documentée en peu de temps. Les ratios doivent donc être distingués par complexité dans le dossier projet.
La cible choisie influe sur la profondeur de documentation attendue. Une migration vers un modèle sémantique central demande une description rigoureuse des mesures et relations. Une cible s’appuyant sur un entrepôt de données externe demande aussi de documenter les transformations entre les sources et les tables de consommation. Le rôle d’une plateforme telle que Snowflake comme cible décisionnelle doit être examiné sous cet angle : elle héberge ou organise des données, mais elle ne remplace pas la définition des indicateurs consommés.
Avant de lancer une reprise massive, sortez la liste des rapports actifs, les définitions des indicateurs critiques et les mappings associés. Si ces trois éléments ne se rejoignent pas dans une documentation cohérente, la migration n’est pas encore dimensionnée.
Un dictionnaire des données est-il la même chose qu’un modèle de données ?
Non. Le modèle décrit notamment les tables, les relations et le grain des données. Le dictionnaire complète cette représentation avec les définitions métier, les formats, les sources, les règles de calcul, les usages et les responsables.
Quel format utiliser pour démarrer un dictionnaire des données ?
Une feuille structurée peut convenir pour cadrer un périmètre limité, à condition d’imposer des colonnes obligatoires, des conventions de nommage et un historique des modifications. Un référentiel partagé devient préférable lorsque plusieurs équipes doivent le maintenir.
Faut-il documenter toutes les colonnes d’un entrepôt de données ?
Le périmètre doit commencer par les objets utilisés dans les rapports, les mesures critiques, les dimensions et les règles de transformation qui influencent les chiffres. Les colonnes techniques peuvent être ajoutées progressivement selon leur impact sur la maintenance et la recette.
Qui valide les définitions métier dans le dictionnaire ?
Le responsable métier valide le sens, le périmètre et l’usage de l’indicateur. Les équipes BI et techniques valident l’origine, le mapping, le format et l’implémentation dans les flux ou le modèle sémantique.
À quel moment faut-il mettre à jour le dictionnaire des données ?
La mise à jour doit être déclenchée par chaque changement qui affecte une source, une transformation, une règle de calcul, un filtre, une relation ou une restitution. Des revues périodiques complètent ce contrôle au fil de l’eau.
Le dossier complet Socles BI hérités : auditer le parc réel avant de le migrer
