Comment structurer une org Salesforce unique pour gérer plusieurs filiales ?

Une ETI qui grandit par croissance externe ou par création de filiales se pose vite la question de l'architecture Salesforce : faut-il une org unique partagée, ou une org par entité ? Ce choix structurant engage la gouvernance des données, les coûts de licences et la capacité à consolider le reporting. Le prendre trop tard, une fois les données déjà chargées, coûte cher à corriger. Voici les critères et mécanismes à connaître avant de trancher.

Org unique ou multi-org : le premier arbitrage

Salesforce permet deux grandes approches pour gérer un groupe multi-entités.

• Org unique : toutes les filiales partagent la même instance. On cloisonne les données par le modèle de partage. Avantage : reporting consolidé natif, coûts d'administration mutualisés, processus harmonisés. Inconvénient : gouvernance centralisée obligatoire, limites de personnalisation partagées entre entités.
• Multi-org : une org par filiale. Avantage : autonomie totale de chaque entité (personnalisation, calendriers de release). Inconvénient : consolidation manuelle ou via un outil tiers, coûts multipliés, gouvernance de groupe complexe.

En pratique, l'org unique est souvent privilégiée quand les filiales partagent des processus proches et que le groupe veut un pilotage centralisé. La multi-org se justifie lorsque les entités sont très hétérogènes, réglementées différemment, ou destinées à être cédées.

Cloisonner les données dans une org unique

La question centrale de l'org unique est : comment garantir qu'une filiale ne voit pas les données d'une autre, tout en permettant à la direction groupe de tout consolider ? Salesforce dispose pour cela d'un modèle de partage à plusieurs niveaux.

Le paramètre de partage par défaut

On définit d'abord l'accès par défaut de chaque objet (Organization-Wide Defaults). Pour un contexte multi-filiales, il est généralement réglé sur Privé, afin qu'aucun enregistrement ne soit visible par défaut hors de son propriétaire.

La hiérarchie des rôles

La hiérarchie des rôles fait remonter automatiquement la visibilité vers les niveaux supérieurs. On peut ainsi créer une branche par filiale, avec une direction groupe placée au sommet qui voit l'ensemble, tandis que chaque commercial ne voit que son périmètre.

Les règles de partage et les territoires

Des règles de partage permettent d'ouvrir la visibilité de façon ciblée entre équipes lorsque c'est nécessaire (par exemple pour un compte partagé entre deux filiales). La gestion des territoires (Enterprise Territory Management) peut compléter le dispositif lorsque le découpage est complexe.

Gérer les spécificités locales : devises, langues, calendriers

Un groupe multi-filiales est souvent multi-pays. Salesforce prend en charge nativement plusieurs dimensions.

• Multidevise : l'activation du multidevise permet de saisir des montants dans la monnaie locale et de consolider dans une devise de référence via des taux de change. Cette activation est structurante et difficile à annuler : elle doit être décidée au cadrage.
• Langues : les libellés d'interface, listes de sélection traduites et modèles d'e-mails peuvent être proposés dans les langues des filiales via le Workbench de traduction.
• Fuseaux horaires et calendriers fiscaux : chaque utilisateur a son fuseau ; un calendrier fiscal personnalisé peut être défini au niveau de l'org pour aligner le reporting.

Attention : le calendrier fiscal est unique par org. Si les filiales ont des exercices comptables décalés, cela peut militer pour une architecture multi-org.

Consolidation, référentiels et gouvernance

L'un des bénéfices majeurs de l'org unique est le reporting consolidé sans effort d'intégration. Encore faut-il partager des référentiels communs.

• Référentiels partagés : catalogue produits, segmentation, nomenclatures. Un socle commun est indispensable pour agréger les chiffres. Les spécificités locales se gèrent via des champs ou listes complémentaires.
• Données de compte inter-filiales : un même client peut être servi par plusieurs entités. Prévoir une hiérarchie de comptes et des règles de dédoublonnage évite les doublons et les conflits de propriété.
• Gouvernance : une org unique impose un comité de gouvernance groupe qui arbitre les demandes d'évolution, car toute modification impacte potentiellement toutes les entités. Un modèle de type center of excellence est recommandé.

Licences et coûts

Le choix d'architecture a un impact direct sur les coûts. En org unique, les licences sont mutualisées et l'administration centralisée réduit les frais récurrents. En multi-org, chaque instance a son propre contrat, ses éditions et ses administrateurs, ce qui multiplie les coûts fixes. À l'inverse, l'org unique peut nécessiter des éditions supérieures ou des fonctionnalités avancées (partage complexe, territoires) qui ont un coût. L'arbitrage doit intégrer le TCO sur plusieurs années, pas seulement le prix des licences la première année.

Points de vigilance avant de décider

• Anticiper les cessions : si une filiale est destinée à être vendue, extraire ses données d'une org unique est complexe. La multi-org facilite la séparation.
• Limites de la plateforme : nombre de champs personnalisés, de règles, de types d'enregistrement. Une org qui accumule les spécificités de nombreuses filiales peut atteindre certaines limites.
• RGPD et souveraineté : selon les pays, des contraintes de localisation ou de séparation des données peuvent orienter vers la multi-org.
• Décision irréversible : multidevise, calendrier fiscal et modèle de partage sont coûteux à modifier après coup. D'où l'importance d'un cadrage rigoureux.

La bonne architecture dépend de votre degré de centralisation, de la diversité de vos filiales et de votre trajectoire de croissance. Pour objectiver ce choix sans biais commercial, INTEGREER peut vous mettre en relation avec des intégrateurs indépendants capables de challenger votre modèle cible. La démarche est neutre et sans engagement.