Les trois questions déterminantes pour décider d'une architecture multi-orgue
L'erreur courante est d'aborder la question "Un seul org ou plusieurs ?" comme une interrogation technique de capacité ou de performance. Dans la plupart des cas, la réponse technique existe au sein d'un seul org : les types d'enregistrements (Record Types), les profils (Profiles), les jeux d'autorisations (Permission Sets) et les règles de partage (Sharing Rules) sont suffisants pour séparer les unités commerciales sans fragmenter l'environnement lui-même. Salesforce prend en charge des dizaines de milliers d'utilisateurs et des millions d'enregistrements au sein d'un org unique — la capacité n'est presque jamais la véritable raison d'une scission.
La question réellement déterminante est celle de l'autonomie organisationnelle, et se décompose en trois vérifications :
- Autonomie réglementaire concrète — Existe-t-il une exigence légale ou contractuelle de séparation physique des données (par exemple, une entité juridique distincte avec une réglementation locale interdisant le partage d'infrastructure), se distinguant d'une séparation logique que l'on peut obtenir via le modèle de partage (Sharing Model).
- Rythme de changement incompatible — Une unité commerciale a-t-elle besoin de cycles de sortie (Release) fréquents et rapides, tandis qu'une autre exige une stabilité maximale et un audit rigoureux, de sorte que chaque sortie partagée devient une source constante de friction entre les équipes.
- Modèle de données intrinsèquement conflictuel, et pas seulement différent — Lorsque la même entité (par exemple « client » ou « commande ») a une définition de champ obligatoire, un flux d'approbation ou une structure de relations qui est physiquement contradictoire entre les unités, et non simplement différente dans sa présentation.
Si aucune de ces trois conditions n'est nettement remplie, la solution adéquate est un org unique avec une séparation logique. Une scission "juste au cas où" génère des coûts opérationnels fixes — double gestion des utilisateurs, double licences et double maintenance des intégrations — pour un problème qui aurait pu être résolu par une simple configuration.
Matrice de décision : Un seul org vs. plusieurs orgs
| Dimension | Un seul org avec séparation logique | Plusieurs orgs distincts |
|---|---|---|
| Coût licence et maintenance | Inférieur — une seule licence, gestion d'utilisateurs centralisée | Supérieur — double licence, double gestion des Releases |
| Customer 360 et vue unifiée | Naturel — toutes les données dans le même espace de requête | Nécessite une couche BI ou une intégration dédiée |
| Indépendance opérationnelle (unité) | Limitée — chaque Release impacte tout le monde | Totale — chaque unité gère son propre rythme |
| Conformité aux exigences réglementaires strictes | Impossible si l'exigence est une séparation physique | Seule solution répondant à l'exigence |
| Complexité de l'intégration inter-unités | Faible | Élevée — nécessite un Middleware ou ETL |
| Risque lors de fusions/scissions futures | Faible — simple modification des autorisations | Élevé — projet de migration complet |
En résumé : l'option par défaut devrait être un seul org, et la scission ne devrait être envisagée que si une réponse positive et claire à l'une des trois questions ci-dessus est établie, et non en réaction à des frictions organisationnelles temporaires.
Ce qui se produit réellement en cas de scission sans raison valable
Lorsqu'une organisation scinde un org pour des raisons politiques (une unité qui veut "sa propre maîtrise") et non pour de véritables raisons techniques, trois choses se produisent en un ou deux ans : premièrement, un enregistrement client en double est créé dans chaque org où cette entité commerciale apparaît, sans clé d'identification commune. Deuxièmement, tout changement au niveau de l'organisation (tel qu'une mise à jour du processus de sécurité ou l'implémentation d'un nouvel outil) devient un projet distinct dans chaque org, ce qui double le coût de toute modification future. Troisièmement, le reporting au niveau de l'entreprise nécessite une couche d'intégration qui n'était pas nécessaire au départ, et celle-ci est souvent construite sous pression après la découverte du problème, au lieu de faire partie de la planification.
C'est pourquoi l'un des principes directeurs de l'architecture Salesforce est d'examiner d'abord si le besoin organisationnel peut être satisfait par des autorisations et des règles de partage (Sharing Rules) au sein d'un org unique, et seulement ensuite d'envisager une scission.
Parcours progressif pour ceux qui doivent scinder
Quand l'une des trois vérifications est effectivement confirmée, la scission doit être effectuée dans un ordre qui minimise les risques :
1. Définissez une clé d'identification globale avant la scission
Avant de créer un deuxième org, un champ d'identifiant unique (numéro d'entreprise, ID client global ou code similaire) est établi, ce qui permettra à l'avenir de faire correspondre les enregistrements entre les environnements. Sans cela, toute tentative future d'unifier la vue client reposera sur la correspondance du nom et de l'adresse, ce qui génère des erreurs à grande échelle.
2. Choisissez un modèle d'intégration en fonction de l'orientation et du rythme des données
S'il s'agit d'une mise à jour périodique à des fins de reporting uniquement, un ETL planifié suffit. Si une visibilité en temps réel est nécessaire (par exemple, une vérification de crédit inter-unités), une API synchrone avec gestion des échecs et de la retransmission est requise. Le choix du modèle inadapté est la principale cause de rupture des intégrations cross-org sous charge — plus de détails sur ce sujet dans les modèles d'intégration Salesforce.
3. Planifiez l'identité et les autorisations d'accès à l'avance
Les utilisateurs travaillant dans les deux orgs (par exemple, les gestionnaires de compte globaux) nécessitent une solution d'identité gérée une seule fois et non deux utilisateurs distincts avec deux mots de passe. La planification du SSO entre les orgs évite que chaque modification des autorisations d'un utilisateur soit effectuée manuellement dans les deux environnements — le sujet est détaillé dans l'architecture SSO et d'identité dans Salesforce.
4. Testez les limites de l'API avant que l'intégration ne soit en production
Chaque appel entre deux orgs est comptabilisé dans les quotas d'API des deux côtés. Un trafic planifié sans test de volume peut atteindre les limites quotidiennes précisément lors des pics de charge, c'est-à-dire au moment où l'intégration est la plus nécessaire. Il est impératif de vérifier cela à l'avance par rapport aux limites et résilience de l'API Salesforce.
5. Désignez un "Owner" et un processus de gouvernance partagé pour les deux orgs
Une personne doit être responsable de la cohérence des décisions architecturales entre les environnements — structure des champs, conventions de nommage et politiques de changement. Sans une propriété centralisée, les deux orgs divergeront également au niveau des standards en moins d'un an, ce qui rendra toute intégration future plus coûteuse.
Scénario illustratif : un groupe d'assurance avec deux divisions
Le scénario est hypothétique et à visée illustrative. Un groupe d'assurance possédait une division d'assurance générale et une division d'assurance-vie, toutes deux opérant sous la même entité juridique mais avec des régulateurs différents et des cycles d'approbation de produits complètement distincts. La division d'assurance-vie exigeait un contrôle strict des changements avec approbation réglementaire pour chaque version (Release), tandis que la division d'assurance générale souhaitait publier des améliorations à un rythme hebdomadaire.
La proposition initiale était de scinder en un org séparé pour chaque division, mais l'examen des trois questions a révélé que seul le rythme réglementaire (vérification 2) était réellement présent — le modèle client et produit n'était pas contradictoire (vérification 3 négative), et il n'y avait pas d'exigence de séparation physique des données (vérification 1 négative). La solution choisie fut un org unique avec deux "chemins de diffusion" distincts au sein du même environnement — un Sandbox dédié et un processus d'approbation séparé pour la division d'assurance-vie, tout en utilisant un modèle de données commun pour un seul Customer 360. La scission complète fut évitée, ainsi que les coûts de maintenance doublés qui auraient dû être supportés pendant des années.
Risques courants et comment les éviter
- Scission "temporaire" qui devient permanente — Un Sandbox qui se transforme en environnement de production sans avoir subi un audit de sécurité. On l'évite en soumettant tout org contenant des données clients réelles à un processus de gouvernance formel, sans exception.
- Enregistrements dupliqués sans clé commune — Se produit lorsque la scission a lieu avant qu'un identifiant global ne soit défini. On l'évite en définissant le champ partagé comme condition préalable à la scission, et non comme une étape tardive.
- Quota API atteint en période de forte charge — Se produit lorsque l'intégration entre les orgs est planifiée sur la base d'un volume moyen et non du volume de pointe. On l'évite en effectuant des tests de charge avant la mise en production et en construisant un mécanisme de "Backoff".
- Dérive des standards entre orgs — Se produit lorsqu'il n'y a pas un seul "Owner" pour l'architecture partagée. On l'évite en désignant un petit comité de gouvernance qui approuve les changements de structure de données des deux côtés.
- Rapports de gestion peu fiables — Se produit lorsqu'on tente de calculer des KPI inter-organisations directement à partir de Salesforce sans couche d'unification. On l'évite en mettant en place une couche BI dédiée dès le premier jour de la scission, et non comme un projet de correction tardif.
Résumé
L'option par défaut est un seul org ; une scission est une exception qui nécessite une justification concrète basée sur l'un des trois critères — autonomie réglementaire effective, rythme de changement incompatible ou modèle de données physiquement conflictuel. Lorsque la justification existe, le succès de la transition se mesure par la préparation effectuée avant la scission : une clé d'identification globale, un modèle d'intégration approprié, une identité commune, la vérification des limites de l'API et une responsabilité claire sur les standards partagés. Une organisation qui néglige cette préparation n'économise pas de travail — elle ne fait que le reporter à un moment où la correction sera beaucoup plus coûteuse.