Pour un groupe présent dans plusieurs pays, vaut-il mieux déployer une seule org Salesforce ou plusieurs orgs ?

Un groupe qui déploie Salesforce dans plusieurs pays fait face à une décision d'architecture structurante : concentrer toutes les filiales dans une org unique ou en déployer plusieurs. Ce choix engage la gouvernance, les coûts, la capacité de reporting consolidé et la marge de manœuvre des équipes locales pour plusieurs années. Le revenir en arrière est coûteux : mieux vaut trancher lors du cadrage, sur des critères objectifs plutôt que sur des préférences d'équipe.

Comprendre ce qu'est une « org » Salesforce

Une org (organisation) est une instance Salesforce autonome : elle possède ses propres données, ses paramètres, ses profils, ses automatisations et ses limites techniques (limites d'API, de stockage, de personnalisation). Deux orgs ne partagent pas nativement leurs données : toute consolidation passe par une intégration ou une remontée dans un outil tiers.

Le terme « multi-org » désigne un modèle où chaque pays, région ou entité juridique dispose de sa propre instance. À l'inverse, l'org unique regroupe l'ensemble des filiales, la séparation des données se gérant alors par le modèle de partage (rôles, hiérarchies, business units, territoires).

Les arguments en faveur de l'org unique

L'org unique est aujourd'hui le modèle privilégié par une majorité de groupes, pour plusieurs raisons concrètes :

• Vision consolidée : un client, un partenaire ou un produit existe une seule fois. Le reporting groupe et la détection de doublons inter-pays sont directement possibles.
• Coût de maintenance réduit : une seule instance à administrer, à faire évoluer et à mettre à jour. Les développements et automatisations sont mutualisés.
• Processus harmonisés : un socle commun facilite l'alignement des pratiques commerciales et la mobilité des utilisateurs entre entités.
• Licences et administration : une gouvernance centralisée simplifie la gestion des accès et la négociation contractuelle.

La séparation des données entre pays reste possible dans une org unique grâce au modèle de partage, aux record types, aux page layouts par profil et aux traductions multilingues natives.

Quand le multi-org se justifie

Le multi-org n'est pas un choix par défaut, mais il répond à des situations réelles :

• Autonomie forte des filiales : entités récemment acquises, processus très divergents, absence de volonté d'harmonisation à court terme.
• Contraintes réglementaires ou de résidence des données : certaines juridictions imposent une localisation ou un cloisonnement stricts. À vérifier avec vos juristes et au regard du RGPD (voir la CNIL pour l'Union européenne).
• Limites techniques atteintes : très gros volumes de données ou d'automatisations pouvant saturer les limites d'une seule org.
• Cycles de déploiement indépendants : une filiale qui doit évoluer sans dépendre du calendrier du groupe.

Le prix à payer est réel : duplication des développements, coûts d'administration multipliés, et surtout un chantier d'intégration pour consolider les données au niveau groupe.

Les critères de décision à poser en cadrage

Plutôt que de trancher sur une conviction, structurez l'analyse autour de questions factuelles :

1. Degré de standardisation des processus : les pays partagent-ils un cycle de vente, un catalogue produit, une segmentation commune ?
2. Besoin de vision 360° client au niveau groupe : avez-vous des clients communs à plusieurs pays ?
3. Exigences réglementaires : résidence des données, cloisonnement, secteurs régulés.
4. Maturité et volonté des filiales : capacité à adopter un socle commun.
5. Volumes de données et d'utilisateurs : anticiper les limites techniques.
6. Trajectoire de croissance : acquisitions prévues, ouvertures de marché.

Une approche fréquente et pragmatique consiste à démarrer sur une org unique avec un socle commun (template), tout en autorisant des variantes locales encadrées. Le multi-org reste réservé aux entités dont les contraintes sont incompatibles avec ce socle.

Les modèles hybrides et le rôle de la gouvernance

Entre les deux extrêmes existent des approches intermédiaires. Le modèle par template définit un socle groupe déployé dans chaque org (en multi-org) ou décliné par business unit (en org unique), garantissant une cohérence sans imposer une uniformité totale. Dans tous les cas, la clé de réussite est la gouvernance : qui décide des évolutions, qui arbitre entre besoins locaux et standard groupe, comment sont gérées les montées de version.

Sans instance de gouvernance claire, une org unique dérive vers un empilement de règles contradictoires, et un multi-org vers des instances qui divergent au point de rendre toute consolidation impossible.

Comment sécuriser ce choix

Cette décision mérite un cadrage dédié, associant DSI, directions métier des pays concernés et expertise Salesforce sur les limites techniques et le modèle de partage. Il est utile de challenger l'architecture proposée par un intégrateur : certains poussent le multi-org par facilité de découpage projet, d'autres l'org unique par simplicité de maintenance. L'arbitrage doit rester le vôtre, appuyé sur vos critères.

INTEGREER est une plateforme neutre de mise en relation. Nous vous orientons, sans engagement, vers des intégrateurs capables de conduire ce cadrage d'architecture multi-pays et de confronter les scénarios org unique et multi-org à vos contraintes réelles, afin que la décision soit documentée et durable.