Une architecture multi-org échoue rarement parce qu’une API n’existe pas. Elle échoue lorsque deux équipes modifient la même donnée, chacune avec une définition différente de sa valeur et aucune règle pour arbitrer le conflit.
Le contrat de données Salesforce multi-org est le document opérationnel qui ferme cette faille. Il ne remplace ni MuleSoft, ni Data Cloud, ni les règles de partage. Il établit ce que chaque flux est autorisé à transporter, qui en répond, comment un changement est annoncé et ce qui se passe lorsqu’une livraison échoue.
Salesforce indique que l’org qui porte la licence Data 360 détermine le lieu de provisionnement et donc la région. Son guide recommande de limiter le nombre d’instances, en privilégiant Data Cloud One dans une configuration multi-org, et de n’en créer plusieurs qu’en cas d’exigence de conformité, de résidence ou d’autonomie (Data 360 Provisioning). Ce choix ne définit pourtant ni le propriétaire d’un email, ni le délai acceptable pour une correction, ni la règle de reprise d’un flux. C’est le rôle du contrat.
La propriété d’une donnée précède le choix du flux
Le problème n’est pas de synchroniser un contact entre deux orgs. Le problème, c’est de savoir quelle org peut créer, corriger ou supprimer une valeur lorsque les deux équipes ont besoin de la même personne, du même compte ou de la même commande.
Une organisation peut choisir une org commerciale qui crée la relation client, une org de service qui tient les interactions, et une couche de données qui prépare des vues pour l’analyse ou l’activation. Cette répartition est défendable. Elle devient dangereuse dès que chaque destination peut réécrire les mêmes attributs sans ordre de priorité.
Le contrat commence donc par un registre, maintenu par objet métier plutôt que par interface technique. Pour chaque attribut partagé, il doit nommer :
- le système qui fait foi ;
- les systèmes qui peuvent le lire ;
- les systèmes qui peuvent proposer une correction sans l’écrire directement ;
- le motif et la fréquence de propagation ;
- la règle appliquée lorsqu’une valeur source est absente, invalide ou en conflit.
Prenons un numéro de téléphone. Si l’org de service peut le corriger après un échange avec le client, l’org commerciale ne doit pas réémettre une ancienne valeur à la prochaine synchronisation. Deux options existent : la correction est renvoyée vers la source qui fait foi avant toute diffusion, ou le contrat prévoit une règle de priorité documentée avec une trace d’audit. Le pire choix est d’accepter un écrasement silencieux parce que le flux a techniquement réussi.
Cette frontière compte davantage avec Data Cloud. Salesforce a annoncé la disponibilité générale de Data Cloud One en octobre 2024 pour partager des données Data Cloud avec plusieurs orgs Salesforce et activer des fonctions CRM alimentées par une instance centrale (annonce Salesforce Developers). La source établit une capacité de partage centralisé. Elle n’établit pas qu’une organisation doit centraliser toutes ses données ni que la couche centrale devient automatiquement le système de référence opérationnel.
Un contrat exploitable contient des règles de changement
Un schéma de données n’est pas stable parce qu’il a été validé en comité. Il change lorsqu’une équipe ajoute une valeur autorisée, rend un champ obligatoire, renomme un code ou modifie la signification d’un statut existant. Ces changements peuvent rester invisibles dans l’org qui les produit et casser une automatisation à l’autre extrémité.
Le contrat doit donc inclure une version et une procédure de compatibilité. Une modification additive, comme l’ajout d’un champ facultatif, peut souvent être publiée sans interrompre les consommateurs. Rendre ce champ obligatoire, modifier un identifiant ou remplacer une liste de valeurs doit déclencher une revue de compatibilité. La question n’est pas administrative : quelles automatisations, mappings ou contrôles de qualité lisent déjà cette donnée ?
Chaque interface inter-org mérite au minimum quatre éléments vérifiables :
- Un identifiant fonctionnel stable. L’identifiant technique d’un enregistrement Salesforce ne suffit pas toujours si la donnée doit survivre à une migration ou à une consolidation.
- Un schéma versionné avec les champs, formats, valeurs admises et données sensibles.
- Un propriétaire de la production et un propriétaire de la consommation. Le premier corrige la source, le second confirme que le changement est absorbé.
- Une date de retrait pour tout champ ou événement remplacé, accompagnée d’un contrôle qui montre les consommateurs encore actifs.
Cette discipline est compatible avec l’outillage Salesforce sans être une promesse de produit. Salesforce indique que la page Release Updates recense les mises à jour qui concernent l’org et que certaines d’entre elles affectent les personnalisations existantes (Manage Release Updates). Dans une architecture multi-org, cette vérification doit couvrir les dépendances entre orgs et non seulement l’org où une équipe prépare son déploiement.
La résidence et les accès sont des limites de contrat
La résidence ne se résout pas par une phrase telle que “les données restent en Europe”. Cette phrase ne précise ni les objets concernés, ni les copies créées par un flux, ni les accès accordés aux opérateurs qui administrent la plateforme.
Le contrat doit isoler les données par niveau de sensibilité. Un identifiant pseudonymisé utile à un rapprochement n’appelle pas les mêmes règles qu’une adresse, un historique de service ou un attribut permettant une décision automatisée. Pour chaque catégorie, la DSI doit pouvoir répondre à quatre questions : où la donnée est-elle stockée, qui peut y accéder, quel flux l’exporte, et quel événement déclenche sa suppression ou sa correction ?
Data Cloud One permet de choisir les Data Spaces partagés avec les orgs compagnons (Data Cloud One Is Now Generally Available). Ce mécanisme peut matérialiser une séparation conçue par l’organisation. Il ne remplace pas la décision sur les équipes autorisées, les finalités admises ou le parcours d’un droit de rectification.
Le contrat ne constitue pas un avis juridique. Il fournit aux responsables sécurité, données et conformité une carte vérifiable des traitements techniques à examiner. Sans cette carte, un audit remonte une liste de connecteurs, pas une explication des responsabilités.
La reprise doit être définie avant le premier incident
Un flux inter-org n’est pas fiable parce qu’il dispose d’un mécanisme de relance. Une relance peut créer un doublon, rejouer une ancienne version ou propager une correction qui n’est plus valable. Il faut donc définir l’unité de reprise et le résultat attendu avant de décider combien de fois un système réessaie.
Pour un événement de création, l’identifiant d’idempotence doit empêcher une seconde exécution de créer un second objet. Pour une mise à jour, le consommateur doit savoir si l’événement le plus récent l’emporte, ou si certaines valeurs exigent une réconciliation manuelle. Pour une suppression, le contrat doit distinguer la suppression opérationnelle, l’anonymisation et la conservation imposée par une obligation métier ou réglementaire.
La ligne de contrôle la plus utile est souvent simple : un tableau de rapprochement qui compare, par flux, les événements produits, acceptés, rejetés et restés sans accusé de réception. Il ne mesure pas la qualité métier à lui seul. Il permet de voir qu’une interface est devenue silencieuse avant que les équipes découvrent des dossiers incomplets dans l’org cible.
Le propriétaire du flux doit également publier un seuil d’escalade. Pas un SLA décoratif. Un délai précis à partir duquel un rejet non traité devient un incident, avec l’équipe qui décide de la correction et l’équipe qui vérifie le retour à la normale.
Le contrat se teste dans le cycle de livraison
Un contrat qui vit dans un wiki est déjà en retard. Les règles qui peuvent être contrôlées doivent rejoindre le cycle de livraison : validation du schéma, test de compatibilité avec les versions encore supportées, contrôle des valeurs interdites et simulation d’un rejet.
Les contrôles ne doivent pas prétendre détecter toute erreur de sens. Ils peuvent en revanche empêcher les défauts répétables : champ obligatoire supprimé, valeur de statut non reconnue, payload incomplet, identifiant absent ou consommateur non déclaré.
Avant de créer une nouvelle intégration, une DSI peut exiger ce dossier de décision :
- le périmètre métier et l’org qui fait foi ;
- le contrat versionné et ses consommateurs connus ;
- les données soumises à une limite de résidence ou d’accès ;
- le scénario de reprise, y compris le traitement d’un doublon ;
- l’alerte qui révèle un flux dégradé ;
- le propriétaire qui autorise une rupture de compatibilité.
Cette exigence ralentit le premier flux. Elle évite que le dixième réinvente une autre définition du client, du consentement ou du statut de commande. L’article sur l’intégration multi-cloud Salesforce et MuleSoft situe ensuite cette gouvernance dans les choix de topologie et de responsabilité entre les couches.
Points clés
- Un contrat de données Salesforce multi-org attribue la propriété d’un attribut avant de choisir son mécanisme de synchronisation.
- Une instance Data Cloud centrale peut répondre à un besoin de partage, mais ne désigne pas à elle seule le système opérationnel qui fait foi.
- Les changements de schéma exigent une version, une revue des consommateurs et une date de retrait contrôlée pour les interfaces remplacées.
- Résidence, accès, correction et suppression doivent être décrits par catégorie de données, pas résumés par une promesse d’architecture.
- Un flux devient exploitable quand sa reprise, son idempotence et son seuil d’escalade sont testés dans le cycle de livraison.
