Le choix entre une org Salesforce et plusieurs se discute comme une question de conception technique et se tranche par la gouvernance. Il surgit en général lors d’une acquisition, d’un audit de conformité ou quand une business unit réclame son propre environnement, rarement lors d’une revue délibérée. Les questions qui le décident relèvent du modèle opérationnel : qui possède les définitions de données partagées, qui peut livrer quand, et quelle org fait foi pour quel objet. Répondez d’abord à celles-là, la topologie suivra.
Ce que suppose une org unique
Une org unique suppose que l’organisation s’accorde sur une seule définition de l’Account, un seul jeu d’étapes d’Opportunity et un seul ensemble de règles de cycle de vie, et qu’une instance de gouvernance peut refuser une variante locale. Elle suppose aussi des releases coordonnées : toutes les équipes qui déploient dans l’org partagent sandboxes, fenêtres de déploiement et tests de non-régression.
Quand l’activité est homogène, l’échange en vaut la peine : un modèle de données, un processus de release, un reporting sans intégration. Quand elle ne l’est pas, le coût apparaît dans le modèle de permissions, dans des présentations de page qui se multiplient et dans des automatisations qui se ramifient pour gérer des processus en réalité différents. Un test simple consiste à lister les branches conditionnelles de la hiérarchie des comptes, du modèle de partage et des automatisations qui n’existent que parce que les business units diffèrent. Quand cette liste ne cesse de grandir, l’org fait tourner plusieurs systèmes dans une même base.
Sanofi (client Cognizant, 2021-2022) illustre la consolidation : six systèmes migrés vers une org Salesforce unique. Une consolidation de ce type avance la question des définitions. Chaque source porte sa propre version d’un client ou d’un produit, et l’org unique n’en accepte qu’une. Cette négociation précède la migration des enregistrements, qui vient en dernier. La note sur la migration de données Salesforce décrit ce qu’il faut prouver avant la bascule.
Une org unique a aussi besoin d’un propriétaire. Sans propriété nommée des objets personnalisés, des Flows et des classes Apex, les dépendances deviennent opaques et les équipes évitent les composants qu’elles ne savent pas tester sans régression. L’org reste techniquement unique mais se fragmente dans les pratiques. La note sur le centre d’excellence Salesforce décrit la couche qui porte cette propriété.
Quand des orgs séparées se justifient
Des orgs séparées se justifient quand l’isolation est une exigence ferme. Une entité juridique soumise à un autre régime réglementaire peut avoir besoin d’une séparation des données et des accès plus facile à démontrer à un auditeur qu’un modèle de partage dans une org commune. Une société récemment acquise peut avoir besoin de sa propre org pendant la transition, parce qu’une migration forcée dans ses premiers mois est rarement réaliste. Des business units aux cycles de release incompatibles peuvent avoir besoin d’orgs distinctes pour que l’équipe la plus rapide ne soit pas calée sur le calendrier de la plus lente.
Le schéma à éviter est la multi-org comme raccourci de gouvernance : plusieurs orgs parce que personne n’a réussi à s’accorder sur un modèle de données commun. Le désaccord est reporté, et s’y ajoutent une couche d’intégration permanente, des processus de release séparés, des audits de permissions séparés et une deuxième équipe d’administration. Une org « temporaire » créée pour une acquisition ou un pilote devient aussi permanente par inertie, sauf si quelqu’un fixe une décision de sortie datée.
Le contrat de données entre orgs
Les définitions partagées ne disparaissent pas avec une deuxième org. Le programme Customer 360 multi-marchés de Lacoste (2023) couvrait six business units. Que des unités de ce type partagent une org ou en alimentent plusieurs, chacune a besoin de la même réponse : qui définit un client, et qui peut modifier cette définition. Dans une org unique, la réponse relève de la gouvernance. Entre plusieurs orgs, elle doit être écrite dans un contrat de données.
Un dispositif multi-org échoue rarement parce qu’une API n’existe pas. Il échoue quand deux équipes modifient la même valeur, chacune avec sa propre définition, sans règle pour arbitrer. Le contrat se tient par objet métier plutôt que par interface technique. Pour chaque attribut partagé, il nomme le système qui fait foi, les systèmes qui peuvent le lire, ceux qui peuvent proposer une correction sans l’écrire directement, et la règle appliquée quand 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 l’ancienne valeur à la synchronisation suivante. Soit la correction remonte vers le système qui fait foi avant toute diffusion, soit 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.
Le contrat dit aussi qui peut modifier les définitions partagées. L’ajout d’un champ facultatif peut en général être publié sans rien casser. Rendre un champ obligatoire, modifier un identifiant ou remplacer une liste de valeurs déclenche une revue de compatibilité avec chaque org consommatrice, une nouvelle version et une date de retrait pour ce qui est remplacé. Chaque interface a un propriétaire côté production, qui corrige la source, et un propriétaire côté consommation, qui confirme que le changement est absorbé.
Une couche de données centrale ne supprime pas ce travail. Salesforce a rendu Data Cloud One disponible en octobre 2024 pour partager des données Data Cloud avec plusieurs orgs. C’est une capacité de partage. Elle ne fait pas de la couche centrale le système opérationnel qui fait foi, et elle ne décide pas à qui appartient une adresse email.
Changer de cap
Revenir sur le choix coûte cher dans les deux sens, et le travail technique en est la partie maîtrisable. C’est au moment de s’accorder sur ce qui va où, sur le propriétaire des données de référence et sur le partage des processus communs que ces programmes s’enlisent.
Pour une séparation, commencez par les données, pas par la configuration. Cartographiez chaque objet et chaque dépendance d’intégration, nommez le propriétaire de chaque objet partagé après la séparation, et construisez l’intégration à côté de l’org existante plutôt qu’après. Faites tourner les deux en parallèle sur une période définie pour vérifier l’intégrité des données avant la bascule.
Pour une consolidation, la négociation du modèle de données passe en premier. Fusionner deux orgs sans modèle Account commun produit une org moins bonne que chacune des deux d’origine.
Pour une org temporaire, fixez les critères de sortie dès sa création : la date de la décision de la fusionner ou de la garder, et qui prend cette décision.
À vérifier
- Chaque objet partagé a un système qui fait foi et un propriétaire de sa définition, tous deux nommés.
- La raison de chaque org séparée est écrite : isolation réglementaire, acquisition en transition ou indépendance des releases.
- Toute org temporaire a une décision de sortie datée et un décideur.
- Les changements de définitions partagées passent par une revue de compatibilité avec les orgs consommatrices.
- Dans une org unique, une instance peut refuser une variante locale de l’Account ou des étapes d’Opportunity.