Les propriétaires fixent la politique, les architectes l'appliquent

🌐 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)

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Chapitre 5 de Data Architect, Partie 1 : Devenir architecte de données. Précédent : Comprendre les données de l’entreprise.

Dites « gouvernance des données » et les gens imaginent des réunions : des comités, des politiques, un document que personne ne lit. Je pose chaque fois une autre question : où la politique est-elle appliquée ?

Si la politique dit que seule la Finance peut modifier la raison sociale du client, qu’est-ce qui empêche quelqu’un d’autre de le faire ? Si elle dit que les équipes ne voient l’adresse d’un destinataire que pour leurs propres arrêts, et seulement le jour même, qu’est-ce qui rend cela vrai ? Si elle dit de conserver ceci sept ans, qu’est-ce qui le supprime au bout de sept ans ? Une politique sans point d’application n’est guère qu’un vœu. Ma position est simple : les propriétaires fixent la politique ; les architectes l’appliquent. Le propriétaire des données décide. Le système que conçoit l’architecte la rend mécaniquement vraie.

Et ne vous attendez pas à finir. La gouvernance n’est jamais terminée. Elle avance par flux et reflux, en tenant à l’écart le pire des mauvaises données. Elle est simple quand Salesforce est seul, et plus difficile, et plus nécessaire, quand Salesforce est un nœud du paysage que nous avons dessiné au chapitre 4. C’est pourquoi ce chapitre est venu en premier : le paysage vous dit jusqu’où la gouvernance doit aller.

Image générée par IA.

Les positions de ce chapitre

• Menez le programme à la manière dont l’entreprise fonctionne : centralisé, fédéré ou hybride ; l’architecte doit savoir qui valide une politique.
• Le propriétaire de l’enregistrement n’est pas le propriétaire des données. Le champ Propriétaire pilote l’attribution et l’accès ; la responsabilité des données appartient au métier.
• Une création ouverte ou verrouillée dépend de la gouvernance autour des données. Ouverte convient à la plupart des petites et moyennes organisations ; verrouillez-la quand les comptes sont maîtrisés dans un ERP ou synchronisés avec lui ; la voie médiane est un type d’enregistrement provisoire avec une conversion contrôlée vers le type gouverné.
• Si l’ERP maîtrise un champ, vous ne le modifiez pas, vous demandez à le modifier. Le golden record est hybride : les champs maîtres de l’ERP arrivent, les champs propres à Salesforce ne repartent jamais, et les flux bidirectionnels ont besoin d’une règle de collision.
• Classifiez les champs sensibles, pas tous les champs. Documentez largement ; classifiez délibérément ; conservez à la fois les métadonnées métier et les métadonnées techniques.
• Enseignez les réglementations. Beaucoup d’architectes n’ont jamais entendu parler des lois hors de leur propre région, et ces lois façonnent la conception des systèmes.
• Utilisez le modèle de consentement standard chaque fois que vous le pouvez, plutôt que de le reconstruire.
• Pour le droit à l’oubli, maîtrisez d’abord où vont les données personnelles. L’effacement est rare et difficile ; concevez pour que les données personnelles arrivent en peu d’endroits, puis traquez chaque copie : historique des champs, archives, copies analytiques, index de recherche et conversations des agents, avant que le délai n’expire.
• Shield est la réponse aux exigences réglementaires clés comme le chiffrement au repos, avec des compromis à prendre en compte dans la conception.
• Field Audit Trail quand c’est réglementé. L’historique standard des champs est la valeur par défaut.
• Mettez en place Event Monitoring avant d’en avoir besoin, et envoyez les événements en continu vers un référentiel comme Splunk. On ne veut pas tomber sur un problème et découvrir alors qu’on ne les capturait pas.

Le cycle de vie gouverné des données

Click to enlarge

Sept questions tout au long de la vie des données. Les outils soutiennent la politique ; ils ne la définissent pas.

Le parcours de ce chapitre

Six modules, chacun autonome.

1. La gouvernance se conçoit dans l’organisation. Propriétaires, data stewards et dépositaires ; centralisé, fédéré ou hybride ; propriétaire de l’enregistrement contre propriétaire des données ; transformer chaque politique en point d’application.
2. Empêcher les mauvaises données d’entrer. « Assez bon » comme définition métier ; création ouverte ou verrouillée, l’enregistrement provisoire et un type d’enregistrement par flux ; le golden record hybride et les bidirectionnels ; une décision de qualité à chaque frontière de données.
3. Connaître ses données : dictionnaire, lignage et classification. Métadonnées métier et techniques ; ce qu’elles signifient, d’où elles viennent, comment elles doivent être traitées, et pourquoi une classification sans application n’est que de la décoration.
4. Les lois sur la protection des données façonnent la conception. Les lois à connaître, ce qu’elles ont en commun (droits, transferts, notification des violations, responsabilité), et les questions qui leur survivent ; anonymisé contre pseudonymisé ; la conformité n’est pas un produit.
5. Le consentement et le droit à l’oubli. Le consentement comme donnée, le modèle de consentement standard, le délai attaché à chaque demande, et concevoir l’effacement avant que la première n’arrive.
6. Protéger, conserver et prouver. Les compromis du chiffrement, les sandboxes, la conservation, l’historique des champs et Field Audit Trail, et Event Monitoring mis en place avant le besoin.

Quand vous avez terminé, testez-vous avec le guide d’étude du chapitre : une liste de contrôle pour l’examen, les habitudes qui vont au-delà, les mots à connaître et quelques questions.

Ce qu’un architecte décide ici

• Qui possède chaque domaine de données important, et ce qui applique la politique de chaque propriétaire.
• Quelles mauvaises données sont tenues à l’écart, et lesquelles sont détectées, mises en quarantaine et corrigées plus tard.
• Quels champs sont sensibles, et ce que cette classification change.
• Où vont les données personnelles, à quoi elles peuvent servir, et comment elles sont retirées de chaque copie.
• Combien de temps les données et leur historique sont conservés, et quelles preuves existent de ce qui s’est passé.

Ce chapitre est un guide d’architecture, pas un avis juridique. Les équipes juridiques et conformité décident quelles lois s’appliquent et ce qu’elles exigent ; l’architecte transforme ces exigences en conception.

Au-delà de l’examen : la gouvernance a un nouveau consommateur, l’agent. La classification décide de ce qu’il peut récupérer, le consentement décide à quoi il peut utiliser les données, et le lignage et l’audit doivent aller jusqu’à ce qu’il a dit et fait. Chaque module se termine par ce que l’IA change pour sa partie du cycle de vie.

Pour aller plus loin

• Aide Salesforce, Data Classification Metadata Fields (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, Understand the Salesforce Consent Data Model (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Règlement (UE) 2016/679 (RGPD) (opens in a new tab), EUR-Lex, consulté le 2026-10-14.

Suivant : Données maîtres et identité