Une source de vérité par attribut
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 1 sur 6 du chapitre Données maîtres et identité, chapitre 6 du cours Data Architect. Chaque module est autonome. Suivant : Les quatre façons de maîtriser les données
La question à laquelle répond ce module : que veut vraiment dire « source unique de vérité » ?
Il y a une phrase que j’entends sans arrêt : « Il nous faut une source unique de vérité. » D’accord. Pour quoi ? Le client ? Ce n’est pas assez précis. Prenez un compte. Qui possède le nom du client, son adresse de facturation, sa limite de crédit, son responsable de compte, son niveau de support, ses préférences marketing ? Ces réponses ne désignent pas le même système. L’ERP peut contrôler la raison sociale, l’adresse de facturation et la situation de crédit ; Salesforce le responsable de la relation et les attributs commerciaux ; une autre plateforme le consentement. Alors quand quelqu’un me dit « Salesforce est notre source unique de vérité pour le client », ma question suivante est : quelle vérité ?
La vérité appartient à un attribut
Section intitulée « La vérité appartient à un attribut »Le premier principe des données maîtres est celui-ci : l’autorité s’attribue par attribut, pas par enregistrement. Un compte peut vivre dans Salesforce sans que Salesforce fasse autorité pour chacun de ses champs. Sept champs sur un enregistrement, deux autorités :
| Attribut | Système qui fait autorité |
|---|---|
| Raison sociale, adresse de facturation, ID client ERP, limite de crédit | ERP |
| Responsable de compte, indicateur de compte stratégique, niveau de succès client | Salesforce |
Un enregistrement ; la vérité est distribuée. C’est normal. « Système d’enregistrement = Salesforce » ne le décrit pas. Un modèle d’autorité, si.
Créé, modifié, référencé, et à quelle vitesse ?
Section intitulée « Créé, modifié, référencé, et à quelle vitesse ? »Quand j’enseigne les données maîtres, je reviens sans cesse aux mêmes questions pour chaque donnée importante : où est-elle créée, où est-elle modifiée, où est-elle référencée, et quelle est sa latence de changement ? Elles mettent l’architecture au jour très vite. (Vous avez rencontré les trois premières au chapitre 4, en classant les types de données ; c’est ici qu’elles font leur vrai travail.)
Prenez un actif. Un client commande trois vélos. Salesforce a l’opportunité et ses lignes, et la commande part vers l’ERP. L’ERP l’exécute, et c’est là que les actifs sont créés : trois vélos, trois numéros de série, renvoyés à Salesforce. Des mois plus tard, le client appelle au sujet de l’un d’eux, et le support référence l’actif dans une requête. Maintenant, quelqu’un doit corriger un attribut. Lesquels Salesforce peut-il modifier, et lesquels appartiennent à l’ERP qui les a créés ? Et quand l’ERP en change un, à quelle vitesse Salesforce doit-il le savoir ? Un actif, quatre questions, et les réponses ne sont pas les mêmes pour chaque champ.
Disons que la raison sociale est créée dans l’ERP et référencée dans Salesforce, et qu’un commercial remarque qu’elle est fausse. Doit-il la corriger dans Salesforce ? Si l’ERP possède le champ, modifier la copie ne corrige rien. Au mieux, la prochaine synchronisation l’écrase ; au pire, les deux systèmes ne sont plus d’accord et personne ne sait lequel croire. Si le métier veut que le commercial lance la correction, c’est différent : Salesforce fournit l’expérience, envoie une demande à l’ERP, l’ERP effectue ou approuve le changement, et la valeur qui fait autorité revient. C’est une architecture très différente de celle qui laisse Salesforce modifier le champ de son propre chef.
La latence fait aussi partie de la vérité. L’ERP change la situation de crédit d’un client à 10 h ; Salesforce la synchronise chaque nuit ; à 15 h, un commercial regarde Salesforce. La valeur est-elle fausse ? Elle est périmée. Si la valeur change une fois par an et qu’un jour de retard ne coûte rien, une synchronisation nocturne convient. Si elle décide si vous acceptez une commande d’un million de dollars aujourd’hui, non. L’autorité dit d’où vient la vérité ; la latence dit à quelle vitesse les autres doivent apprendre qu’elle a changé. Deux décisions distinctes.
Système d’enregistrement, d’engagement, de référence
Section intitulée « Système d’enregistrement, d’engagement, de référence »Le vocabulaire du chapitre 4 aide ici. Un système d’enregistrement maintient la version qui fait autorité. Un système d’engagement est l’endroit où les gens travaillent avec elle. Un système de référence fournit des données qu’un autre système utilise sans les posséder. Salesforce peut être le système d’engagement de la relation client pendant que l’ERP reste le système d’enregistrement de ses attributs juridiques et financiers. Ce n’est pas une faiblesse de l’architecture ; c’est l’architecture. L’erreur, c’est de prétendre qu’un seul système doit tout posséder pour que le diagramme ait l’air plus simple.
Le golden record hybride
Section intitulée « Le golden record hybride »Cela change ce que veut dire « golden record ». Le chapitre 5 a introduit l’idée en empêchant les mauvaises données d’entrer ; ici, c’est le cœur de la conception. Les gens imaginent un enregistrement magique unique dont chaque champ est maîtrisé au même endroit. C’est parfois la conception. Sur Salesforce, je vois plus souvent un hybride : une partie du compte maîtrisée ailleurs et copiée dedans (raison sociale, numéro client ERP, adresse de facturation, situation de crédit), et une partie qui n’existe que parce que Salesforce en a besoin (responsable de compte, stratégie d’opportunité, niveau de succès client, notes de relation). Les champs de l’ERP entrent pour que les gens puissent les utiliser. Les champs Salesforce ne repartent jamais, parce que l’ERP ne s’en soucie pas. C’est parfaitement raisonnable, tant que tout le monde sait lequel est lequel.
Rendez l’autorité visible
Section intitulée « Rendez l’autorité visible »Alors je rends l’autorité externe évidente dans le schéma. Si SAP contrôle un champ, il reçoit un préfixe : sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. C’est la même idée que le préfixe erp_ du chapitre 4. Utilisez le nom du système quand cette autorité est précise et stable, et un préfixe générique quand le sens compte plus que le fournisseur du moment. L’essentiel est que, six mois plus tard, quelqu’un qui lit le modèle puisse voir : ce n’est pas juste un champ Salesforce de plus ; un autre système possède cette valeur. Ne forcez pas les gens à redécouvrir l’autorité en faisant de la rétro-ingénierie sur les intégrations.
Construisez une carte des autorités
Section intitulée « Construisez une carte des autorités »Pour les données maîtres importantes, je veux une carte des autorités : pour chaque attribut clé, qui le crée, qui possède la décision métier, quel système fait autorité, et qui ou quoi peut le modifier. Quatre questions différentes :
| Attribut | Créé par | Propriétaire métier | Système qui fait autorité | Peut le modifier |
|---|---|---|---|---|
| Raison sociale | Finance | Finance | ERP | Le processus financier |
| Limite de crédit | Finance | Finance | ERP | L’équipe crédit |
| Responsable de compte | Opérations commerciales | Ventes | Salesforce | La direction commerciale |
| Niveau de support | Opérations du service | Service | Salesforce | La direction du service |
| Consentement | Le client | Protection des données | Plateforme de consentement | Le client, un processus approuvé |
Remarquez que le propriétaire métier et le système qui fait autorité ne sont pas la même chose. Un système ne possède pas une politique ; les personnes, si. Le système stocke et applique le résultat. C’est encore le chapitre 5 : les propriétaires fixent la politique ; les architectes l’appliquent.
Un client. Beaucoup d’attributs. Une autorité pour chacun.
L’autorité change au fil du cycle de vie
Section intitulée « L’autorité change au fil du cycle de vie »Un commercial rencontre un prospect dont l’ERP n’a jamais entendu parler et crée le compte dans Salesforce. À ce moment-là, Salesforce fait autorité pour le nom, l’adresse, les contacts et la qualification. Le prospect devient client ; l’ERP crée le client officiel et attribue le numéro client, la raison sociale, l’adresse de facturation et le crédit. L’autorité s’est déplacée. Salesforce n’avait pas tort avant ; le cycle de vie a changé. C’est le schéma provisoire → gouverné du chapitre 5 : avant la conversion, Salesforce possède le prospect ; après, l’ERP possède les attributs gouvernés, et Salesforce continue de posséder les siens. Alors « quel système possède le compte ? » est une question faible. Demandez : quel système possède cet attribut, à ce moment du cycle de vie ?
Une copie n’est pas une autorité
Section intitulée « Une copie n’est pas une autorité »Nous copions les données de l’ERP dans Salesforce parce que les gens en ont constamment besoin. Cela fait de Salesforce une copie locale pratique, pas le maître, et l’architecture doit se comporter en conséquence : lecture seule pour les utilisateurs, actualisée par l’intégration, étiquetée avec sa source, modifiée uniquement par une demande, vérifiée par une réconciliation quand la copie dérive. La copie est utile. L’autorité ne s’est pas déplacée.
La confiance demande plus qu’une valeur
Section intitulée « La confiance demande plus qu’une valeur »« Adresse de facturation : 123 Main Street. » Devez-vous lui faire confiance ? Je veux des signaux de confiance : d’où elle vient, quand elle a été confirmée pour la dernière fois, quel système l’a fournie, et qui ou quoi l’a modifiée en dernier : une personne, une intégration, un agent ? Maintenant, l’ERP dit 123 Main Street, Salesforce dit 125, et un fichier partenaire dit « 123 Main St., Suite 200 ». Laquelle est juste ? Ne répondez pas « prenez la plus récente ». Peut-être. Mais « la plus récente » est elle-même une règle qui suppose que celui qui a modifié en dernier mérite de gagner. Cela peut être vrai, ou terrible. Le module 3 s’y attaque. La confiance vient de l’autorité et de la provenance, pas du fait de trouver un champ rempli.
Steve Trucking : à qui est cette vérité ?
Section intitulée « Steve Trucking : à qui est cette vérité ? »Un partenaire distributeur envoie une livraison, et plusieurs vérités se cachent dans cette seule transaction. La référence de commande du partenaire est celle du partenaire ; Steve Trucking la garde pour rapprocher les mises à jour, mais n’en devient pas le maître. Le statut de livraison (arrivée, livrée, installée, incident) est celui de Steve Trucking ; le partenaire le reçoit, mais recevoir un statut ne fait pas du partenaire l’autorité sur ce qui s’est passé dans le camion. Et le destinataire est le client du partenaire. Le partenaire fournit le nom, l’adresse, le téléphone et les notes de livraison parce que Steve Trucking en a besoin pour livrer. Cela ne fait pas de Steve Trucking le maître de l’identité de cette personne, et cette distinction détermine la conception du destinataire au point de contrôle.
Une livraison, deux autorités.
L’endroit où vivent les données et qui possède leur vérité sont des questions différentes. Salesforce peut détenir le numéro client ERP sans le posséder ; Snowflake peut détenir le statut de livraison sans en être le maître opérationnel ; une plateforme de données client peut unifier des identités sans posséder chaque attribut. Un agent peut lire les trois, et cela ne l’autorise certainement pas à décider lequel est vrai.
Au-delà de l’examen : ce que l’IA change. Les agents transforment l’autorité par attribut en règle d’exécution. Une personne voit une mauvaise adresse de facturation et sait « ça vient de SAP ; je ne dois pas la modifier ici ». Un agent à qui l’on dit « mets à jour l’adresse de facturation du client » ne le saura pas, sauf si nous le concevons ainsi. Il a besoin de la même carte des autorités que l’architecte : avoir accès à un champ ne fait pas de ce champ le bon endroit où écrire.
Ce qu’un architecte décide ici
Section intitulée « Ce qu’un architecte décide ici »- Quel système fait autorité pour chaque attribut important, plutôt qu’un seul système pour tout un enregistrement.
- Où chaque attribut est créé, modifié et référencé, et à quelle vitesse ses changements doivent circuler.
- Qui fixe la politique de chaque attribut, et quelles personnes, intégrations ou agents peuvent le modifier.
- Comment l’autorité externe se voit dans le modèle : préfixes de nommage, autorisations, comportement des intégrations.
- Comment l’autorité se déplace au fil du cycle de vie, par exemple quand un prospect devient un client gouverné par l’ERP.
Une source unique de vérité ne veut pas dire une seule organisation, un seul ERP, une seule plateforme MDM ou un seul enregistrement géant. Cela veut dire que pour chaque information gouvernée, l’architecture peut dire où se trouve la valeur qui fait autorité, et que chaque autre système sait comment se comporter en conséquence. Ce n’est pas une source unique de vérité. C’est une architecture de la vérité.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Salesforce Architects, Data 360 Architecture (opens in a new tab) (en anglais), consulté le 2026-10-14.