La réponse brève
La « Source de Vérité » n'est pas une question technique, mais une question d'autorité : qui, au sein de l'organisation, est habilité à déterminer qu'une valeur donnée est correcte. Lorsque cette décision n'est pas prise explicitement, elle l'est tacitement – par la personne qui a rédigé la dernière intégration.
La règle centrale : la propriété est définie au niveau du champ, et non au niveau du système. Tenter de déclarer « l'ERP est la source de vérité pour le client » échoue dès que le service client met à jour un numéro de téléphone dans Salesforce et que la synchronisation nocturne annule cette mise à jour.
Trois questions décisives pour la propriété
Pour chaque entité, puis pour chaque groupe de champs, il convient de se demander : où la donnée a-t-elle été créée pour la première fois, qui est habilité sur le plan métier à la modifier, et qui porte la responsabilité en cas d'erreur. Dans les trois cas, la réponse devrait être le nom d'un rôle, et non le nom d'un système. Le système découle du rôle.
Quand les réponses désignent deux rôles différents, c'est presque toujours le signe que deux champs différents ont été fusionnés en un seul.
Exemple de matrice de propriété
| Entité / Champ | Source de Vérité | Salesforce | Direction de Synchronisation |
|---|---|---|---|
| Nom légal, N° d'identification, Conditions de paiement | ERP | Lecture seule | ERP → Salesforce |
| Contact, Rôle, Préférences | Salesforce | Modification | Salesforce → Systèmes Marketing |
| Catalogue de produits et Prix de base | ERP / PIM | Lecture seule | ERP → Salesforce |
| Offre de prix et Remise approuvée | Salesforce | Modification | Salesforce → ERP |
| Commande confirmée et État de livraison | ERP | Lecture seule | ERP → Salesforce |
| Solde débiteur et État de recouvrement | Système financier | Lecture seule | Financier → Salesforce |
| Activité, Requêtes et Communication | Salesforce | Modification | Pas de synchronisation externe |
Ce tableau représente le livrable. Il est concis, se trouve dans un seul document et toute nouvelle intégration est évaluée par rapport à lui avant d'être développée.
Distinction entre la Représentation et l'Autorité
La plupart des tensions entre systèmes disparaissent lorsque l'on comprend que la représentation d'une donnée n'exige pas sa duplication. Un solde débiteur affiché à un vendeur n'a pas besoin d'être un champ dans Salesforce mis à jour chaque nuit ; il peut s'agir d'une vue distante ou d'une couche de fédération.
Chaque champ dupliqué représente un engagement opérationnel : synchronisation, échec, écart et temps. Avant de dupliquer, demandez-vous si une automatisation ou un rapport historique est requis. Sinon, il est préférable d'afficher plutôt que de copier. Une explication plus approfondie de cette approche est disponible dans Zero Copy et Fédération dans Data 360.
Conflits : Décider à l'avance, pas en temps réel
Même lorsque la propriété est claire, des situations de mise à jour concurrente surviennent. Trois règles possibles : priorité du système (le propriétaire l'emporte toujours), dernier horodatage, ou marquage pour traitement manuel. La troisième règle est la plus sûre pour les champs sensibles – à condition qu'il existe une file d'attente de traitement avec un propriétaire, et non un simple enregistrement de journal qui s'accumule.
Scénario : Une organisation avec deux vérités pour une seule adresse
Une entreprise de services d'infrastructures gérait l'adresse client dans deux systèmes : un ERP pour la facturation et un système de service sur le terrain pour la planification des techniciens. Les deux étaient synchronisés avec Salesforce de manière bidirectionnelle. Le résultat : une adresse qui basculait constamment, et des techniciens qui se rendaient à l'adresse de facturation.
La solution n'a pas été de corriger la synchronisation, mais de décomposer l'entité. Deux champs distincts ont été définis : une adresse de facturation sous la propriété de l'ERP, et une adresse de service sous la propriété du système de terrain. Les deux étaient en lecture seule dans Salesforce, avec un lien pour la demande de modification acheminée vers le propriétaire approprié. Le nombre d'appels de service clos comme « adresse incorrecte » a diminué significativement au cours du trimestre suivant.
La leçon : Lorsque des systèmes « se disputent » un champ, il s'agit souvent de deux données métier différentes qui ont reçu le même nom.
Application : Du document à la réalité
Une matrice de propriété n'est effective que si elle est mise en œuvre à trois niveaux : la sécurité au niveau du champ (Field-Level Security) qui empêche les modifications du côté qui n'est pas le propriétaire, un utilisateur d'intégration avec des autorisations limitées aux champs qu'il possède uniquement, et un rapport mensuel qui présente les champs mis à jour contrairement à la politique. Ce dernier rapport révèle d'anciennes intégrations dont personne ne se souvient.
La documentation de la signification de chaque champ est directement liée au Data Mapping pour la migration.
Risques courants et actions préventives
| Risque | Manifestation concrète | Action préventive |
|---|---|---|
| Propriété au niveau du système | Contradictions au sein de la même entité | Décision au niveau du champ ou du groupe de champs |
| Synchronisation bidirectionnelle par défaut | Valeurs qui alternent | Unidirectionnel + lecture du côté opposé |
| Duplication inutile | Des dizaines de champs synchronisés sans consommateur | Afficher au lieu de copier |
| Document sans application | La politique s'effrite en quelques mois | Autorisations de champ + surveillance des anomalies |
| Pas de file d'attente de conflits | Les contradictions s'accumulent en silence | File de traitement avec propriétaire et SLA |
Comment mesurer le succès
| Domaine | Ce qui est mesuré | Fréquence de vérification |
|---|---|---|
| Cohérence | Taux d'incohérence dans les champs clés entre les systèmes | Mensuel |
| Anomalies de politique | Écritures dans un champ en dehors du propriétaire défini | Mensuel |
| Conflits | Nombre et temps de résolution des éléments en file d'attente | Hebdomadaire |
| Impact opérationnel | Incidents causés par des données incorrectes | Trimestriel |
La construction et l'application d'une matrice de propriété sont réalisées dans le cadre de nos services d'intégrations et de données.
Liste de contrôle pour la détermination de la Source de Vérité
- ☐ Liste des entités centrales de l'organisation
- ☐ Pour chaque entité : où a-t-elle été créée, qui est autorisé, qui est responsable en cas d'erreur
- ☐ Propriété déterminée au niveau du champ ou du groupe de champs
- ☐ Direction de synchronisation explicite pour chaque groupe
- ☐ Chaque champ copié satisfait au critère « il a un consommateur »
- ☐ Règle de résolution des conflits choisie et documentée
- ☐ Une file de traitement manuel existe avec un propriétaire et un SLA
- ☐ La sécurité au niveau des champs (Field-Level Security) est conforme à la matrice
- ☐ L'utilisateur d'intégration est limité aux champs qu'il possède
- ☐ Un rapport mensuel est généré pour les écarts par rapport à la politique
Ressources professionnelles
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Intégrations et Données — https://hpi.pro/integrations-data