Hiérarchies et données à double sens

🌐 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 5 sur 6 du chapitre Données maîtres et identité, chapitre 6 du cours Data Architect. Chaque module est autonome. Précédent : Une carte n’est pas une décision · Suivant : Point de contrôle 1 : Steve Trucking

La question à laquelle répond ce module : comment gérer des données que plus d’un système maintient ?

L’architecture facile : l’ERP possède le client, Salesforce en reçoit une copie, terminé. Les vraies entreprises ne sont pas aussi nettes. L’ERP possède le client juridique et Salesforce la relation commerciale ; une division vit dans SAP, une division rachetée dans un autre ERP ; les prospects n’existent que dans Salesforce. Puis quelqu’un veut que les utilisateurs Salesforce mettent à jour un champ contrôlé par l’ERP, et les flèches commencent à pointer dans les deux sens. Comme je le dis quand j’enseigne cela : « Le plus difficile, ce sont les bidirectionnels. » Pas parce qu’envoyer des données dans les deux sens est techniquement difficile, mais parce qu’une fois que les deux systèmes participent au changement, vous devez être extrêmement précis sur l’autorité.

Des données à double sens ne veulent pas dire deux maîtres

L’ERP possède l’adresse de facturation, copiée dans Salesforce. Un commercial apprend du client qu’elle a changé, et le métier veut qu’il la mette à jour sans quitter Salesforce. Raisonnable. Les données circulent maintenant ERP → Salesforce et Salesforce → ERP. Salesforce devient-il copropriétaire de l’adresse de facturation ? Non. Le sens d’une intégration ne décide pas de l’autorité. Le commercial ne modifie pas la copie de Salesforce. Du point de vue de l’architecture, il demande à modifier la valeur qui fait autorité. Vous ne modifiez pas le champ de l’ERP ; vous demandez à le modifier. Salesforce est l’interface ; l’ERP reste le maître.

Cela change la conception. Si Salesforce possédait le champ, on enregistre et c’est fini. Si l’ERP le possède, « enregistrer » veut dire que Salesforce envoie l’adresse proposée, que l’ERP la valide et l’accepte, met à jour son maître, et renvoie la valeur qui fait autorité. Ce n’est qu’alors que la valeur gouvernée a changé : demander → valider → accepter → publier, et non « mettre à jour les deux systèmes en espérant qu’ils restent synchronisés ».

Click to enlarge

Une intégration bidirectionnelle ne crée pas une autorité bidirectionnelle.

Quand le maître dit non

L’ERP rejette le changement : le client est inactif, l’adresse enfreint une règle de l’ERP, l’utilisateur n’a pas le droit de modifier les adresses légales, l’ERP est en panne, ou quelqu’un d’autre a modifié le client entre-temps. Si Salesforce affichait déjà la nouvelle adresse, nous avons maintenant deux vérités, et le module 1 nous a déjà dit laquelle l’emporte : celle de l’ERP. L’architecture a donc besoin d’un état demandé, pas encore accepté : une valeur proposée séparée, un indicateur « modification en attente », ou l’attente de la confirmation avant de l’afficher. Le mécanisme dépend du cas d’usage. La règle, non : ne laissez jamais une demande rejetée se transformer en vérité concurrente.

Boucles et collisions

Voici un classique. L’ERP met à jour Salesforce ; l’intégration de Salesforce voit un changement et l’envoie à l’ERP ; l’ERP voit une mise à jour et la renvoie. Vous avez construit une boucle très coûteuse. Une bonne conception à double sens sait où un changement a commencé, si le maître l’a accepté, et s’il s’agit d’un nouveau changement métier ou simplement de l’écho d’un changement déjà traité : identifiants de source, horodatages, métadonnées d’intégration, traitement idempotent. Le chapitre sur l’intégration va en profondeur. Le principe des données maîtres est simple : sachez si vous êtes à l’origine d’un changement ou si vous le reflétez.

Puis les collisions. Vous en avez rencontré une au chapitre 5 : un commercial demande Steve’s Plumbing LLC pendant que quelqu’un dans l’ERP tape Steve’s Plumbing L.L.C. (Protégez l’enregistrement gouverné). En voici une autre. Salesforce propose 125 Main Street ; presque au même moment, un utilisateur de l’ERP la change en 130. Laquelle l’emporte ? Il n’y a pas de réponse technique universelle. Peut-être l’ERP l’emporte-t-il toujours parce qu’il possède le champ ; peut-être la demande Salesforce va-t-elle dans une file de revue ; peut-être le dernier changement accepté l’emporte-t-il ; peut-être l’ERP rejette-t-il toute mise à jour dont la valeur de départ a changé. C’est de la concurrence d’accès, mais en dessous se trouve une décision d’autorité, et aucun modèle d’intégration ne peut vous sauver si personne n’a décidé qui peut effectuer le changement qui fait autorité.

Et un seul champ, c’est le cas simple. Une adresse, c’est une rue, une ville, un code postal. Salesforce envoie une nouvelle rue pendant que l’ERP vient de changer la ville. Laissez-vous passer la rue toute seule ? Ou traitez-vous l’adresse comme une seule transaction, pour que les champs passent tous ensemble ou aucun, et rejetez-vous le changement entier ? Décidez quels champs voyagent en groupe avant la première collision, pas après.

Chaque fois que je vois une intégration à double sens, je demande que se passe-t-il quand les deux côtés modifient la même donnée ? Si la réponse est « ça n’arrivera probablement pas », nous n’avons pas fini. Laquelle l’emporte, rejetons-nous, mettons-nous en file, comparons-nous les versions, faisons-nous une revue ? Le champ doit-il seulement être modifiable aux deux endroits ? Parfois, la meilleure conception à double sens supprime un sens pour un attribut donné : Salesforce peut demander ; seul l’ERP publie la valeur acceptée. Les données circulent toujours dans les deux sens, mais un seul système maîtrise le champ. Cette différence est capitale.

Les hiérarchies sont aussi des données maîtres

Les relations peuvent aussi être des données maîtres. Une société mère mondiale avec des régions Amérique du Nord et Europe, chacune avec des filiales par pays : la hiérarchie elle-même porte un sens. Qui est la société mère ? Quelle filiale se trouve sous quelle entité juridique ? Quels comptes remontent jusqu’au client mondial ? Cela pilote les rapports, les territoires, la tarification, les contrats, l’exposition au crédit, le service, l’accès aux données et l’analytique. Une hiérarchie peut compter autant que les enregistrements qu’elle contient, et elle a besoin de la même gouvernance. (L’examen cite la gestion des hiérarchies ; on l’oublie facilement.)

Sur Salesforce, les hiérarchies de comptes se construisent avec le champ Compte parent. La vue de hiérarchie Lightning affiche jusqu’à 2 000 comptes, et seulement ceux que l’utilisateur a le droit de voir ; les comptes personnels ne sont pas pris en charge dans la hiérarchie ; et le champ Site du compte distingue les implantations d’une entreprise (Considerations for Using Account Hierarchy (opens in a new tab), en anglais). Mais le champ Compte parent ne répond pas à la question d’architecture : qui possède la hiérarchie ?

À savoir pour l’examen. Connaissez les bases de la hiérarchie de comptes : elle se construit avec le champ Compte parent ; la vue Lightning affiche jusqu’à 2 000 comptes, seulement ceux que l’utilisateur peut voir ; les comptes personnels ne sont pas pris en charge ; et le champ Site du compte distingue les implantations d’une entreprise.

Une hiérarchie, plusieurs maîtres

D’après mon expérience, les hiérarchies ont une maîtrise partagée. Les entités nord-américaines viennent de SAP, les européennes d’un autre ERP, les nouveaux prospects sont construits dans Salesforce, et une filiale rachetée n’a pas encore migré. Qui possède la hiérarchie ? Cela dépend de la branche. Chaque ERP contrôle sa branche ; Salesforce contrôle les relations des prospects jusqu’à leur conversion. C’est une architecture légitime, tant que tout le monde sait où sont les frontières. Décidez branche par branche.

Click to enlarge

L’autorité sur une hiérarchie peut s’attribuer branche par branche.

Alors ne laissez pas le champ Compte parent cacher l’autorité. Un utilisateur change le parent d’une filiale dans Salesforce. Techniquement trivial. Du point de vue de l’architecture, vient-il de changer la structure juridique de l’entreprise ? Si l’ERP maîtrise cette branche, probablement pas, donc Salesforce doit le bloquer, ou le transformer en demande de modification. Ou peut-être que Salesforce garde légitimement une hiérarchie commerciale pendant que l’ERP garde la hiérarchie juridique. Alors peut-être ne devraient-elles pas du tout être la même relation.

Une entreprise peut avoir plusieurs hiérarchies valides : juridique, de facturation, commerciale, de service, géographique. La société mère mondiale signe le contrat, les régions reçoivent leur propre service, la facturation passe par une entité financière partagée, les ventes gèrent par région. Quelle est la vraie hiérarchie ? Toutes ; elles répondent à des questions différentes. L’erreur est de supposer qu’il doit y en avoir une seule. Il doit y avoir une autorité claire pour chaque type de relation : le principe d’attribut du module 1, appliqué aux relations.

Et toutes les relations parent-enfant ne sont pas des données maîtres. Regrouper les livraisons du jour sur une tournée est une relation, mais elle est transactionnelle, un événement opérationnel. Une hiérarchie de clients décrit une relation commerciale durable. Les deux ressemblent à du parent-enfant dans un modèle ; elles n’ont pas le même cycle de vie. Demandez ce que signifie la relation et combien de temps ce sens dure.

Un client, deux ERP

Quand j’enseigne cela, je demande à la salle : qui a déjà travaillé avec un client qui a un seul Salesforce et plus d’un ERP ? Les mains se lèvent à chaque fois. Demandez pourquoi, et les ERP se révèlent découpés par région (un pour l’Amérique du Nord, un pour l’Europe), par fonction (une entreprise de plomberie rachète une entreprise d’électricité, et chacune garde son propre ERP), ou simplement par l’histoire : l’activité a été rachetée, et personne ne l’a encore migrée.

Prenez Steve’s Plumbing comme client. Il fait des affaires en Amérique du Nord, donc l’ERP nord-américain a une fiche client pour lui. Puis il ouvre un bureau à Munich, et l’ERP européen crée sa propre fiche client, avec son propre numéro client. Même entreprise, deux enregistrements, deux ID. Comment est-ce que je représente cela dans une seule organisation Salesforce ? J’ai vu trois façons de faire.

Une hiérarchie de comptes. Steve’s Plumbing est le parent, avec Steve’s Plumbing North America et Steve’s Plumbing Europe comme comptes enfants, chaque enfant représentant la fiche d’un ERP. Le hic : les enfants ne sont plus vraiment Steve’s Plumbing. Ce sont Steve’s Plumbing qui fait des affaires dans une région, et, comme nous venons de le voir, une hiérarchie porte un sens.

Des comptes pairs. Deux comptes côte à côte, chacun avec un champ qui dit à quel ERP il appartient : un code société, une région. Rien n’est caché. Le coût apparaît dans les rapports : pour voir Steve’s Plumbing dans le monde entier, il vous faut quelque chose qui dise que ces deux comptes sont la même entreprise.

Un compte, avec un enfant par ERP. Un seul Steve’s Plumbing, et un objet enfant avec un enregistrement par ERP qui porte l’ID client de cet ERP. Deux ERP ou dix. Les commerciaux voient un seul client et passent une seule commande ; en coulisses, des flows décident vers quel ERP part chaque ligne : les travaux d’électricité vers l’ERP de l’électricité, la plomberie vers l’ERP de la plomberie. Mais il vous faut maintenant décider quel ERP est principal pour les valeurs partagées, comme le nom et l’adresse, et ce qui se passe quand le client existe dans un ERP et pas dans l’autre.

Click to enlarge

Un client, deux ERP : trois façons de le représenter dans Salesforce.

Demandez comment ils synchronisent leurs ERP

Alors, laquelle ? D’abord : quelle part de la structure des ERP les commerciaux doivent-ils voir ? S’ils ont toujours su que l’Amérique du Nord et l’Europe sont des activités séparées, parce qu’ils se connectent à l’un ou l’autre ERP, ne la leur cachez pas. Reportez cette structure dans Salesforce sous forme de comptes pairs. Si le métier veut un seul Steve’s Plumbing face aux ventes, vous vous orientez vers un compte avec un enfant par ERP.

Puis vient la question qui tranche vraiment, et elle ne se tranche pas dans Salesforce. Je demande au client : comment gardez-vous ces deux enregistrements synchronisés entre vos ERP ? Pas ce qui est local à chaque ERP, comme le solde ; ça, c’est transactionnel. Je parle des données maîtres : la raison sociale, les adresses. S’il a une équipe qui garde les deux ERP synchronisés, nous pouvons les réunir en un seul compte. S’il n’arrive pas à les garder synchronisés dans ses propres ERP, comment peut-il attendre de nous que nous les gardions synchronisés dans Salesforce ? Alors ce sont des comptes pairs, ou une hiérarchie.

Souvenez-vous de ce qu’est un ERP. Ce sont des systèmes massifs qui demandent des années de mise en place, et ils viennent avec leur propre façon de gérer les données maîtres. Ce n’est pas Salesforce qui va les piloter. Nous ne contrôlons pas les ERP. Nous contrôlons la façon dont nous les représentons dans Salesforce.

Le MDM au milieu

Certains clients ont déjà résolu ce problème avant notre arrivée. Une grande entreprise, de nombreuses années d’activité, plusieurs ERP : ils ont rencontré ce problème bien avant Salesforce et ont placé un produit MDM dédié au milieu pour faire l’intermédiaire entre les ERP. C’est le MDM en coexistence ou centralisé du module 2. Salesforce ne se branche alors plus sur chaque ERP. Il pointe vers un seul endroit, le hub MDM, et obtient une représentation unique du client. Ne vous attendez pas à en croiser souvent, cela dit. Ce sont de gros projets de mise en œuvre à part entière ; en toutes mes années, je n’ai travaillé avec un tel hub que deux ou trois fois. Et même avec le hub, vous pouvez encore avoir besoin de cet objet enfant, pour que chaque commande sache vers quel ERP elle part.

Click to enlarge

Le MDM au milieu : Salesforce pointe vers un seul endroit.

Steve Trucking : à qui est la hiérarchie ?

Un partenaire distributeur a sa propre structure : société mère, divisions régionales, centres de distribution, magasins. Steve Trucking possède-t-il cette hiérarchie ? Non ; le partenaire fait autorité pour sa propre organisation. Mais Steve Trucking peut avoir besoin de sa propre vue commerciale de ces mêmes sites, pour les contrats, la gestion de compte, le service et les rapports, peut-être un compte enfant pour chaque centre de distribution sous le partenaire. Deux hiérarchies légitimes, deux autorités. Nommez-les, et ne prétendez pas qu’un seul arbre représente chaque relation.

Rendez les frontières visibles

Chaque fois que l’autorité est partagée, je veux que la frontière soit visible : nommage des champs, métadonnées des enregistrements, identifiants des systèmes sources, autorisations, comportement des intégrations, documentation. Ce que je ne veux pas, c’est un développeur qui lit cinq intégrations pour découvrir que « ces valeurs de Compte parent viennent de SAP, sauf pour les prospects, sauf pour l’Europe ». Ce n’est pas un modèle d’autorité maintenable. Si la hiérarchie a une maîtrise partagée, documentez le partage. Si l’autorité change à la conversion, documentez le changement. Si Salesforce peut demander un changement mais pas l’effectuer, rendez-le évident dans l’expérience.

Dans Salesforce, cela commence par un champ. Il faut un champ qui dit clairement qu’il s’agit de données maîtres : la clé de l’ERP, ou un indicateur « données maîtres ». Pilotez la modifiabilité des champs à partir de ce champ, pas d’un type d’enregistrement ; avec Dynamic Forms, vous n’avez plus besoin d’un type d’enregistrement pour afficher les champs de l’ERP en lecture seule (chapitre 5, Un type d’enregistrement par flux). Vous pouvez autoriser la création d’enregistrements en dehors du maître, mais surveillez les modifications.

Au-delà de l’examen : ce que l’IA change. Un client dit à un agent : « changez notre adresse de facturation pour 125 Main Street. » Le champ est là, dans Salesforce. L’agent doit-il le mettre à jour ? Pas si l’ERP le possède. Un agent a besoin d’une autorité d’écriture, pas seulement d’un accès au champ : son action doit encoder le chemin approuvé, soumettre une demande de modification et dire « j’ai soumis la modification pour traitement », et non affirmer à tort « j’ai mis à jour votre adresse de facturation ».

Ce qu’un architecte décide ici

• Si une modification dans Salesforce change une donnée qui fait autorité ou demande un changement au système qui la possède.
• Comment les flux à double sens distinguent les changements d’origine des échos, et gèrent les rejets, les collisions, la latence et les pannes.
• Qui possède chaque hiérarchie, branche par branche s’il le faut.
• Pour un client détenu dans plusieurs ERP : une hiérarchie, des comptes pairs, ou un compte avec un enfant par ERP, selon la manière dont le client garde ses ERP synchronisés.
• Si des hiérarchies concurrentes sont en réalité des relations légitimes différentes : juridique, de facturation, commerciale, de service.
• Comment les frontières d’autorité et les chemins d’écriture approuvés sont rendus visibles pour les utilisateurs, les intégrations, les développeurs et les agents.

L’autorité partagée n’est pas le problème. L’autorité ambiguë, si. Plusieurs ERP peuvent maîtriser des branches différentes, Salesforce peut maîtriser certains attributs et demander des changements sur d’autres, et plusieurs hiérarchies peuvent décrire une même entreprise. Tout cela fonctionne, tant que pour chaque attribut et chaque relation importants, vous pouvez dire qui le possède, qui peut le modifier, où se fait le changement qui fait autorité, et ce qui se passe quand les systèmes ne sont pas d’accord. Si vous ne le pouvez pas, une flèche à double sens de plus sur le diagramme n’y changera rien.

Pour aller plus loin

• Aide Salesforce, Considerations for Using Account Hierarchy (opens in a new tab) (en anglais), consulté le 2026-10-14.