Dictionnaire, lignage et classification
Aussi en 28 langues
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Deutsch (Schweiz)
Module 3 sur 6 du chapitre Qualité et gouvernance des données, chapitre 5 du cours Data Architect. Chaque module est autonome. Précédent : Empêcher les mauvaises données d’entrer · Suivant : Les lois sur la protection des données façonnent la conception
La question à laquelle répond ce module : comment consigner ce que signifient les données, d’où elles viennent et à quel point elles sont sensibles ?
Vous héritez d’une organisation. Le compte a 900 champs, parmi lesquels Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c et Account_Status__c. Lequel vous dit si quelqu’un est réellement client ? Vous ouvrez les descriptions. Trois sont vides. Une dit « Customer Type ». Merci bien. Une dit qu’il vient de l’ERP ; un autre a été créé il y a six ans par quelqu’un parti depuis longtemps. Imaginez maintenant que vous n’êtes pas l’architecte mais une intégration, une équipe des rapports ou un agent. L’organisation a beaucoup de données. Cela ne veut pas dire qu’elle sait ce qu’elles signifient.
C’est là que les métadonnées deviennent de l’architecture, à travers trois questions liées mais différentes :
- Dictionnaire : que signifient ces données ?
- Lignage : d’où viennent-elles ?
- Classification : comment doivent-elles être traitées ?
Deux sortes de métadonnées
Section intitulée « Deux sortes de métadonnées »Les métadonnées sont de deux sortes, et il vous faut les deux. Les métadonnées métier disent ce que les données signifient pour l’entreprise : la définition, le propriétaire, les règles d’utilisation, leur degré de sensibilité. Les métadonnées techniques disent comment elles sont construites et comment elles circulent : l’objet et le champ, le type et la longueur, le nom d’API, le schéma, le mappage d’un système à l’autre, le lignage de la source à la cible. Le nom d’API et le type d’un champ disent à un développeur comment l’utiliser ; sa définition et son propriétaire disent à tous les autres s’il faut l’utiliser. Quand elles se contredisent, ou que l’une manque, c’est là que les intégrations et les rapports dérapent.
À savoir pour l’examen. Distinguez les métadonnées métier (sens, définitions, propriétaire, règles, sensibilité : le dictionnaire métier et la classification) des métadonnées techniques (objets, champs, types, noms d’API, schémas, mappages et lignage).
Commencez par le sens
Section intitulée « Commencez par le sens »Le chapitre 3 a posé la règle : chaque champ reçoit une description. Pas « Customer Status » pour un champ appelé Customer Status, mais quelque chose comme « La relation commerciale actuelle du partenaire avec Steve Trucking. Renseignée par l’ERP après l’activation. Ne pas utiliser pour la qualification des prospects. » Maintenant je sais ce qu’il signifie, d’où il vient et à quoi ne pas l’utiliser. C’est le début d’un dictionnaire métier : des définitions communes pour les données qui comptent. Qu’est-ce qu’un client ? Un client actif ? Que veut dire Livré ? Qu’est-ce qui compte comme ponctuel ? Cela paraît évident jusqu’à ce que vous réunissiez cinq services dans une salle : la Finance a une définition, les Ventes une autre, les Opérations une troisième, l’entrepôt de données une quatrième, et quelqu’un a construit un tableau de bord sur une cinquième. Le problème n’est pas que personne ne parle la même langue. C’est que l’entreprise ne s’est pas mise d’accord sur le sens.
Un dictionnaire peut vivre dans un tableur ou un outil de documentation, mais ses définitions importantes doivent se trouver près de l’endroit où les gens utilisent les données. Sur la plateforme, ce sont les descriptions de champ, le texte d’aide et les métadonnées de classification. En analytique, cela compte encore plus : « chiffre d’affaires » ne peut pas vouloir dire une chose sur le tableau de bord de la direction et une autre dans la requête d’un analyste. C’est à cela que sert une couche sémantique, et les modèles sémantiques de Data 360 contiennent des définitions gouvernées comme les métriques, les dimensions et les relations au-dessus des données physiques (Create a Semantic Model in Data 360 (opens in a new tab), en anglais). La technologie change ; l’exigence, non : les données importantes ont besoin d’un sens convenu.
Et commencez par le sens, pas par la technologie. Un dictionnaire qui commence par l’objet, le champ, le type et le nom d’API documente la mise en œuvre. Un dictionnaire qui commence par les termes métier documente l’entreprise :
| Terme métier | Signification | Où il est représenté |
|---|---|---|
| Partenaire distributeur | Un distributeur pour lequel Steve Trucking livre, sous contrat | Compte Salesforce ; client dans l’ERP financier |
| Livraison | Une livraison à un destinataire, à une adresse, un jour donné | RouteDesk aujourd’hui ; un ordre d’exécution une fois les livraisons passées dans Salesforce |
| Destinataire | La personne qui reçoit une livraison | Coordonnées du destinataire sur la livraison |
| Livrée | Terminée selon la définition opérationnelle convenue | Statut de livraison |
| Livraison ponctuelle | Terminée dans le créneau de livraison convenu | Métrique dérivée |
Un seul sens, de nombreuses représentations techniques.
Puis demandez d’où elles viennent
Section intitulée « Puis demandez d’où elles viennent »Une fois que je sais ce que signifie une valeur, je veux savoir d’où elle vient. C’est le lignage. La raison sociale d’un partenaire dans Salesforce : un commercial l’a-t-il tapée, l’ERP l’a-t-il envoyée, une intégration l’a-t-elle transformée, Data 360 l’a-t-il unifiée, a-t-elle été calculée, l’IA l’a-t-elle générée ? Cela change à quel point je m’y fie et ce que j’ai le droit d’en faire. Souvenez-vous des enregistrements provisoires du module 2 : deux comptes peuvent tous deux dire « Keystone », l’un créé hier par un commercial, l’autre venu de l’ERP avec un identifiant qui fait autorité. Même texte, lignage différent, traitement différent.
Le lignage n’est pas seulement le diagramme de mille tables d’un ingénieur de données. Pour les données importantes, je veux répondre à des questions pratiques : où ont-elles commencé, quel système fait autorité, qu’est-ce qui les a transformées, quels systèmes en ont reçu des copies, qu’est-ce qui les a modifiées en dernier, et puis-je remonter d’une valeur dérivée jusqu’à ses sources ? Le paysage du chapitre 4 dit que les systèmes sont connectés. Le lignage dit ce qui est arrivé aux données en chemin.
Une partie du lignage est gratuite : l’ID ERP sur le compte, Créé par et Dernière modification par, les journaux d’intégration, les documents de mappage. Data 360 ajoute à ses objets de données des champs de lignage qui consignent la source de données et l’objet source de chaque enregistrement (Data Lineage Fields (opens in a new tab), en anglais). Mais ne supposez pas que le lignage apparaît parce que les systèmes sont intégrés. Parfois, le lignage le plus utile tient en un champ : Système source = Keystone. Et si la source compte pour la gouvernance, rendez-la mécaniquement fiable, renseignée par l’intégration, pas tapée par une personne.
Les données dérivées ont plus que toutes les autres besoin de lignage. Disons que Steve Trucking calcule un risque de retard de livraison à partir de la position du camion, du créneau de livraison et de l’historique de la tournée, et que la répartition s’en sert pour établir les priorités. D’où vient « élevé » ? Ajoutez un agent qui dit à un destinataire « votre livraison a du retard », et vous devez savoir sur quoi il s’est fondé, et à quel point c’était à jour. Plus vous passez des valeurs stockées aux valeurs calculées, unifiées, prédites et générées, plus le lignage compte.
La classification répond à une autre question
Section intitulée « La classification répond à une autre question »Maintenant : comment doivent-elles être traitées ? Nom du destinataire, adresse de livraison, numéro de téléphone, notes de livraison, statut de livraison, numéro de camion, centre de distribution, partenaire distributeur, photo : ils ne sont pas tous aussi sensibles. « En cours de livraison » n’est pas un numéro de téléphone, et un code de centre de distribution n’est pas une photo de l’intérieur du domicile de quelqu’un. Salesforce vous permet de le consigner sur chaque champ, standard ou personnalisé : Data Owner, Field Usage, Data Sensitivity Level et Compliance Categorization (Data Classification Metadata Fields (opens in a new tab), en anglais). Le chapitre 3 les appelait les champs de taxonomie, et expliquait pourquoi ils comptent : marquez un champ comme PII ou RGPD et des processus peuvent le trouver, des outils de masquage jusqu’à la couche de confiance IA de Salesforce, qui peut empêcher les valeurs marquées d’atteindre un grand modèle de langage. Une mise en garde du chapitre 3 : Salesforce désactive désormais ce masquage pour les agents, parce qu’il peut retirer le contexte dont un agent a besoin (Classifiez ce qui compte : les champs de taxonomie). La classification doit donc toujours piloter les autres contrôles.
Ma position ici est délibérée : classez les champs sensibles, pas tous les champs. Je ne veux pas qu’on passe trois mois à classer des milliers de champs pour que quelqu’un puisse annoncer « 100 % classés » sans que personne ne s’en serve. Le numéro de téléphone du destinataire : oui. L’adresse du domicile : oui. Les notes de livraison qui peuvent contenir des codes de portail et « chien dans le jardin » : oui. Les photos qui peuvent montrer des personnes ou un domicile : absolument. Un libellé d’affichage interne ? Ce n’est pas là que doit aller l’énergie de la gouvernance. Cela ne rend pas acceptables les champs non documentés. Deux travaux différents : la documentation est large ; la classification est délibérée. C’est ce qui garde son sens à la classification.
Une taxonomie que les gens peuvent utiliser
Section intitulée « Une taxonomie que les gens peuvent utiliser »La classification a besoin d’un vocabulaire, une taxonomie. Les valeurs par défaut de Salesforce vont de Public, Internal, Confidential, Restricted à MissionCritical ; votre organisation peut vouloir ses propres libellés. Je ne les impose pas. Gardez-les compréhensibles : s’il y a 47 catégories et que personne en dehors de l’équipe protection des données ne sait distinguer la catégorie 31 de la 32, elle n’aide pas. Une bonne taxonomie relie un libellé à un comportement. Si un champ est une donnée personnelle sensible, qui peut le voir, peut-il aller dans une sandbox, quitter la région, apparaître dans l’analytique, combien de temps est-il conservé, un agent peut-il l’utiliser ? Là, la classification travaille.
Une classification sans application n’est que de la décoration
Section intitulée « Une classification sans application n’est que de la décoration »Marquez le numéro de téléphone du destinataire comme sensible sans rien changer d’autre, et vous avez écrit de la documentation. Utile, mais la gouvernance va plus loin : la classification doit piloter les autorisations, le masquage, le chiffrement, la conservation, le consentement, le déplacement des données, l’usage des sandboxes, l’audit et l’accès de l’IA. Une partie relève de la décision de conception de l’architecte ; certaines plateformes appliquent désormais les balises et les classifications directement dans des politiques, comme le fait la gouvernance de Data 360 (Data Governance in Data 360 (opens in a new tab), en anglais). Et marquer un champ Restricted n’empêche personne de le lire. La classification dit comment un champ doit être traité ; la sécurité le rend effectif. L’ordre est le suivant : identifier les données, les comprendre, classer ce qui compte, puis appliquer les contrôles que cette classification exige.
Trois questions sur vos données, et la troisième doit piloter quelque chose.
Les données de référence ont aussi besoin de métadonnées
Section intitulée « Les données de référence ont aussi besoin de métadonnées »Codes pays, statuts de livraison, codes de centres de distribution, identifiants de partenaires, motifs d’annulation : ils paraissent simples jusqu’à ce que deux systèmes ne soient pas d’accord. L’un dit CANCELLED, un autre CANCELED, un troisième CNCL, un quatrième 9. Les données de référence ont besoin de définitions, d’un propriétaire, d’une source, d’un cycle de vie quand les valeurs changent, et de correspondances quand les systèmes les représentent différemment. De petites valeurs peuvent piloter de très gros processus. Le chapitre 6 va plus loin.
Les trois ensemble
Section intitulée « Les trois ensemble »Prenez le numéro de téléphone du destinataire. Dictionnaire : le numéro qui sert à joindre la personne qui reçoit une livraison donnée. Lignage : issu du manifeste du partenaire distributeur. Classification : donnée personnelle. Les questions d’architecture deviennent alors possibles : l’équipe peut-elle le voir, et pendant combien de temps (le dossier dit seulement pour ses propres arrêts, et seulement le jour même) ; peut-il aller dans une sandbox ; Snowflake en a-t-il besoin ; un agent peut-il l’utiliser ; que se passe-t-il une fois la livraison terminée ?
Prenez maintenant le statut de livraison. Dictionnaire : l’état opérationnel actuel de la livraison. Lignage : renseigné par le processus de livraison de Steve Trucking et renvoyé à chaque partenaire par sa propre intégration. Classification : opérationnel, non sensible. Données différentes, traitement différent. C’est tout l’enjeu.
Je ne traite pas les métadonnées comme une documentation produite une fois la vraie architecture terminée. Si je ne sais pas dire ce que signifie un champ, je ne comprends pas le modèle de données. Si je ne sais pas d’où vient une valeur, je ne comprends pas les intégrations. Si je ne sais pas si elle est sensible, je ne comprends pas la sécurité. Les métadonnées décrivent l’architecture, et parfois la pilotent.
Au-delà de l’examen : ce que l’IA change. La classification devient l’interrupteur qui décide de ce qu’un agent peut récupérer ou répéter, et le lignage doit aller jusqu’à la réponse ou l’action de l’agent. Si un agent dit à un destinataire que la livraison est en retard, l’architecture doit pouvoir dire sur quoi il s’est fondé, d’où cela vient, et si l’agent avait le droit de l’utiliser. « Quelque part dans Salesforce » n’est pas un lignage, et « données clients » n’est pas une classification.
Ce qu’un architecte décide ici
Section intitulée « Ce qu’un architecte décide ici »- Quels termes métier ont besoin de définitions gouvernées, pour que les systèmes et les équipes ne donnent pas plusieurs sens à un même mot.
- Comment les valeurs importantes gardent assez de lignage pour montrer leur source, leur autorité et leurs transformations.
- Quels champs portent un sens de sensibilité ou de conformité et reçoivent donc une classification explicite.
- Quelle taxonomie l’organisation utilise, et si les gens peuvent l’appliquer de façon cohérente.
- Comment la classification pilote de vrais contrôles au lieu de rester inutilisée.
Avant de gouverner des données, sachez ce que vous avez : ce qu’elles signifient, d’où elles viennent, comment elles doivent être traitées. Documentez largement, classez délibérément, gardez le lignage là où il compte. Sinon, vous ne gouvernez pas les données. Vous les avez, c’est tout.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Aide Salesforce, Data Classification Metadata Fields (opens in a new tab) (en anglais), consulté le 2026-10-14.
- Aide Salesforce, Data 360 : Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) et Create a Semantic Model in Data 360 (opens in a new tab) (en anglais), consulté le 2026-10-14.