La gouvernance se conçoit dans l'organisation

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

Image générée par IA

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

Module 1 sur 6 du chapitre Qualité et gouvernance des données, chapitre 5 du cours Data Architect. Chaque module est autonome. Suivant : Empêcher les mauvaises données d’entrer

La question à laquelle répond ce module : que signifie la gouvernance des données pour un architecte, et qui fait quoi ?

Quand les gens entendent gouvernance des données, ils pensent à des réunions : des comités, des politiques, des normes, un document qui explique qui est censé faire quoi avec les données. Tout cela peut faire partie d’un programme de gouvernance. En tant qu’architecte, une autre question m’intéresse : où la politique est-elle appliquée ?

Si la politique dit que seule la Finance peut modifier un champ, qu’est-ce qui l’applique ? Si elle dit que l’ERP possède la fiche client juridique, qu’est-ce qui empêche quelqu’un dans Salesforce de la modifier ? 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 réellement cela vrai ? Si elle dit de conserver ceci sept ans, qu’est-ce qui l’archive ou le supprime au bout de sept ans ? Une politique sans point d’application n’est guère qu’un vœu. La gouvernance devient de l’architecture quand ces décisions sont intégrées au système.

La gouvernance n’est jamais terminée

Mettons cela au clair tout de suite : on ne termine pas la gouvernance. Je l’ai vue avancer par flux et reflux. Une entreprise porte une vraie attention à la qualité des données, et les choses s’améliorent. L’attention se déplace ailleurs, et la qualité glisse. Une nouvelle intégration est mise en service, une unité commerciale change son processus, quelqu’un importe un fichier, l’entreprise en rachète une autre, un agent commence à écrire des enregistrements, et le problème change de nouveau. Le but n’est pas un état mythique où chaque enregistrement est parfait pour toujours. C’est de garder les données assez fiables pour le métier et de tenir à l’écart le pire des mauvaises données. C’est un travail continu.

Quand Salesforce est à peu près seul, la gouvernance veut dire nettoyer les données à un seul endroit. Quand il est un nœud du paysage du chapitre 4, elle devient plus difficile, et plus nécessaire. Maintenant le client vit dans Salesforce, l’ERP, l’entrepôt de données, les systèmes des partenaires, Data 360. Qui le possède ? Qui peut le modifier ? Quelle copie fait autorité, quels attributs peuvent circuler, combien de temps sont-ils conservés, et qui répond quand ils sont faux ? Ce ne sont pas des questions de configuration. Ce sont des questions de gouvernance qui deviennent de la configuration.

Le propriétaire de l’enregistrement n’est pas le propriétaire des données

Commencez par le mot propriétaire, parce que Salesforce le rend déroutant. Ouvrez un compte et vous voyez un Propriétaire : un commercial, par exemple. Le commercial possède-t-il les données du client ? Pas forcément. Sur Salesforce, un enregistrement d’un objet qui a un propriétaire appartient à un utilisateur ou à une file d’attente ; le propriétaire a un accès complet, et il pilote l’attribution et le partage à travers la hiérarchie des rôles et les règles de partage (Sharing and Record Access Features (opens in a new tab), en anglais). C’est la propriété de l’enregistrement : un mécanisme de la plateforme.

Le propriétaire des données est autre chose : la personne ou la fonction responsable des données en tant qu’actif de l’entreprise. La Finance peut posséder les informations juridiques du client, les Opérations le statut des livraisons, les RH les données des employés. Salesforce vous donne même un endroit pour le consigner : le champ de classification Data Owner sur chaque champ (Data Classification Metadata Fields (opens in a new tab), en anglais).

Chez Steve Trucking, le compte d’un partenaire distributeur peut appartenir au responsable commercial qui gère ce partenaire. Mais l’identité juridique du partenaire est gouvernée par la Finance et maîtrisée dans l’ERP financier. Les ventes, le service, les opérations et le portail partenaire ont tous besoin du compte ; rien de cela ne veut dire que le responsable commercial doit modifier l’identité juridique du partenaire une fois que la Finance l’a établie. J’ai vu des équipes regarder le champ Propriétaire et supposer qu’elles avaient résolu la propriété des données. Ce n’est pas le cas. L’attribution des enregistrements n’est pas la responsabilité métier.

Propriétaire, data steward, dépositaire

Trois rôles de gouvernance, trois métiers différents.

Le propriétaire des données fixe la politique. Il répond à ce que signifient les données, qui peut les créer et les modifier, quelle exactitude elles doivent avoir, combien de temps elles sont conservées, qui peut les voir, quel système fait autorité, et ce qui se passe quand elles sont fausses. L’architecte ne doit pas inventer ces réponses. C’est l’une de mes positions les plus fermes : les propriétaires fixent la politique ; les architectes l’appliquent. Si la Finance dit que la raison sociale ne peut changer que par le processus de l’ERP une fois le client actif, c’est une décision de gouvernance. La rendre mécaniquement vraie, c’est mon travail.

Le data steward la fait fonctionner. Le data steward (gestionnaire des données) est proche de la santé quotidienne des données : il surveille les signaux de qualité, examine les doublons, résout les exceptions, coordonne les corrections, tient à jour les définitions, repère le processus qui ne cesse de produire de mauvaises données. Deux autres missions reviennent au data steward. Quand deux équipes ne sont pas d’accord sur ce que signifie un champ, sur qui le possède ou sur qui peut le voir, le data steward porte le désaccord devant le propriétaire et veille à ce que la décision soit appliquée. Et le data steward développe la culture des données : il aide ceux qui saisissent et utilisent les données à comprendre ce qu’elles signifient et pourquoi les règles existent. Un data steward a besoin de plus qu’un nom sur un organigramme. Il lui faut du temps, de la visibilité, un processus, et l’autorité de faire corriger les problèmes. Sinon, « data steward » devient la huitième responsabilité de quelqu’un, regardée une fois par trimestre.

Le dépositaire fait tourner le système. Les administrateurs, les équipes plateforme, les équipes sécurité : ceux qui exploitent la technologie qui stocke et traite les données. Le propriétaire dit que seuls ces rôles peuvent les voir ; le dépositaire exploite les contrôles qui le rendent vrai. Les noms comptent moins que de rendre chaque responsabilité claire, et dans une petite organisation, une même personne peut porter deux casquettes.

Comment le programme fonctionne

Les programmes de gouvernance prennent en général trois formes. Centralisé : une seule équipe rédige les politiques et les normes pour tous les domaines. C’est cohérent, et cela peut devenir un goulot d’étranglement, loin de ceux qui font le travail. Fédéré (décentralisé) : chaque domaine, comme la finance, les ventes ou les opérations, gouverne ses propres données dans le cadre de quelques règles communes. C’est proche du travail, et les définitions divergent d’un domaine à l’autre. Hybride : une petite équipe centrale possède les normes et les définitions communes, et les propriétaires et data stewards des domaines gèrent leurs propres données. La plupart des grandes entreprises que j’ai vues finissent quelque part dans l’hybride. Pour l’architecte, la forme répond à une question pratique : qui valide une politique avant que je l’applique, et où vivent les définitions communes ?

À savoir pour l’examen. Connaissez les trois façons de mener un programme de gouvernance, centralisé, fédéré (décentralisé) et hybride, et ce que chacune implique pour savoir qui fixe la politique et où vivent les définitions communes.

Le RACI doit mériter sa place

Un RACI (qui est Responsable, qui Approuve, qui est Consulté et qui est Informé) aide, mais pas un tableur géant fait parce que la gouvernance « en exige un ». Je veux qu’il réponde à des questions d’architecture, à commencer par les trois du chapitre 4 (Les quatre questions derrière les catégories) : où les données sont-elles créées, où sont-elles modifiées, et où sont-elles référencées ? Ce sont souvent des systèmes différents. Prenez un produit : l’ERP le crée, Salesforce le référence, le portail l’affiche, l’entrepôt de données l’analyse. Maintenant, le métier change ce que veut dire « produit actif ». Où le changement commence-t-il, qui l’approuve, comment se propage-t-il, et quelles copies sont en lecture seule ? Si vous ne savez pas répondre, vous n’avez pas encore de gouvernance. Vous avez des copies. Un bon RACI met précisément cette ambiguïté au jour.

La gouvernance doit devenir mécanique

Le métier dit que seule la Finance peut modifier la raison sociale du client. Je ne veux pas que la réponse d’architecture soit « on le couvrira en formation ». La formation aide ; ce n’est pas de l’application. Il peut s’agir d’un accès au niveau du champ, d’une règle de validation, d’un champ que seule l’intégration écrit, ou d’un processus contrôlé au lieu de modifications directes. Le mécanisme dépend de l’exigence, mais il doit y en avoir un :

Politique de gouvernance	Le propriétaire qui décide	Point d’application possible
L’ERP possède l’identité juridique du client	Finance	Champs réservés à l’intégration, autorisations, validation
Seuls ceux qui en ont besoin voient les données personnelles	Protection des données, sécurité	Partage, autorisations, accès aux champs
Les identifiants clients sont uniques	Propriétaire métier	ID externe unique, règles de doublons
Les enregistrements gouvernés ne sont pas créés à la main	Propriétaire des données	Autorisations, automatisation, intégration
Les données sensibles ont une durée de conservation fixée	Protection des données, juridique	Un processus de conservation ou de suppression
Les changements importants doivent pouvoir être prouvés	Conformité	Historique des champs, piste d’audit
La source des données reste identifiable	Propriétaire des données	Un champ source, des métadonnées de lignage

Je dis point d’application possible exprès. Ce n’est pas un tableau pour choisir des fonctionnalités. C’est l’ordre de la réflexion : quelle est la politique, qui la possède, et qu’est-ce qui, dans l’architecture, la rend vraie ?

Click to enlarge

Les propriétaires fixent la politique ; les architectes l’appliquent.

Ne comptez pas sur la bonne conduite

« Ne modifiez jamais l’ID client de l’ERP. » Tout le monde le sait, jusqu’à ce que quelqu’un le fasse : par accident, par un chargement de données, par une automatisation, par une intégration, par un agent. Si le modifier abîmerait les données de l’entreprise, « s’il vous plaît, ne le faites pas » n’est pas le contrôle. Construisez le contrôle. Faire confiance, mais vérifier. Les personnes, les intégrations, les automatisations et l’IA font toutes des erreurs, alors l’architecture doit supposer qu’un jour quelque chose tentera ce que la politique interdit. Que se passe-t-il alors ?

La gouvernance franchit les frontières entre systèmes

Retour au paysage. L’ERP possède le client ; Salesforce, l’entrepôt de données et une plateforme de données client en détiennent des copies ; un partenaire en reçoit une partie. À quel système la politique s’applique-t-elle ? À tous. Salesforce peut bloquer correctement une modification de la raison sociale pendant qu’une intégration laisse un système en aval l’écraser. Salesforce peut supprimer des données personnelles que l’entrepôt de données détient encore. Un champ classé sensible dans Salesforce peut atterrir dans un champ texte non classé ailleurs. La gouvernance ne peut pas s’arrêter à la limite de l’organisation, parce que les données, elles, ne s’y arrêtent pas. C’est pourquoi le chapitre 4 est venu en premier : le paysage vous dit jusqu’où la gouvernance doit aller.

Gouvernez assez, pas tout

L’échec inverse est tout aussi réel. Nous découvrons que la gouvernance compte, alors nous verrouillons tout : personne ne peut créer, chaque changement demande une approbation. Les données sont gouvernées, et personne ne peut faire son travail. La gouvernance, c’est le contrôle approprié aux données : strict pour certaines, léger pour d’autres. Certains enregistrements peuvent être créés librement, d’autres demandent une approbation ; certains champs, presque tout le monde peut les modifier, d’autres seulement l’intégration. Le module suivant devient très concret à ce sujet.

Et parce que la gouvernance n’est jamais terminée, l’application a besoin de retours. Les doublons augmentent-ils ? Les champs obligatoires se remplissent-ils de n’importe quoi ? Les intégrations échouent-elles, les utilisateurs trouvent-ils des contournements, les exceptions augmentent-elles, les data stewards passent-ils toute la journée sur un seul problème ? Ces signaux vous disent si la conception fonctionne, et parfois que le contrôle, ou la politique, doit changer.

Au-delà de l’examen : ce que l’IA change. La gouvernance a un nouveau consommateur : l’agent. Le propriétaire des données décide toujours de ce qui peut être utilisé et pour quoi ; l’architecte le rend toujours applicable. Ce qui change, c’est la vitesse et l’échelle. Un agent lit, combine et exploite des données gouvernées bien plus vite qu’une personne, alors une politique qui n’existe que dans un document protège encore moins.

Ce qu’un architecte décide ici

• Qui est responsable de chaque domaine de données important, et en quoi cela diffère de la propriété des enregistrements.
• Qui assure l’intendance des données et qui les exploite comme dépositaire.
• Où les données importantes sont créées, modifiées, référencées et maîtrisées dans le paysage.
• Quel point d’application rend chaque politique importante mécaniquement vraie.
• Comment l’architecture montre si la gouvernance fonctionne, ou commence à glisser.

Quand j’entends une exigence de gouvernance, je la traduis. « L’ERP possède ceci. » « Seules ces personnes peuvent voir ceci. » « Nous devons prouver qui a modifié ceci. » « Conservez ceci sept ans. » À chaque fois : montrez-moi le point d’application. L’architecte ne décide pas de la politique. Nous concevons le système qui l’applique. C’est là que la gouvernance cesse d’être un document et devient de l’architecture.

Pour aller plus loin

• Aide Salesforce, Sharing and Record Access Features (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, Data Classification Metadata Fields (opens in a new tab) (en anglais), consulté le 2026-10-14.