La stratégie d'organisation est une décision de paysage

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 5 sur 6 du chapitre Comprendre les données de l’entreprise, chapitre 4 du cours Data Architect. Chaque module est autonome. Précédent : Dessiner le paysage des systèmes · Suivant : Le paysage de Steve Trucking

La question à laquelle répond ce module : une organisation ou plusieurs, et où s’exécute-t-elle ?

Quand j’enseigne à des candidats CTA, je leur dis que la plus grande décision d’un scénario se prend dans les cinq ou dix premières minutes : combien d’organisations Salesforce avons-nous ? Une grande organisation ? Des organisations régionales pour l’Amérique du Nord, l’EMEA et l’APAC ? Des organisations séparées pour des unités commerciales séparées ? Une organisation spéciale pour un pays qui a ses propres règles ? Et directement liée à cela : où ces organisations s’exécutent-elles ?

Ce ne sont pas des détails d’administration. Ils changent l’endroit où vivent les données, les intégrations, les rapports, l’identité, et la façon dont les gens du monde entier atteignent le système. C’est pourquoi je traite la stratégie d’organisation comme une décision de paysage, et pourquoi je la prends en premier.

Commencez avec une seule organisation

Ma position de départ est simple : commencez avec une seule organisation. Pas parce qu’une seule organisation est toujours la bonne réponse, mais parce que j’ai besoin d’une raison pour en ajouter une autre. Une seule organisation me donne un seul endroit pour les données clients partagées, un seul modèle de sécurité, un seul endroit où déployer, un seul ensemble d’intégrations, un seul endroit pour les rapports. Et une seule organisation peut quand même prendre en charge des unités commerciales, des pays, des processus, des types d’enregistrement, des applications, des modèles de partage et des expériences différents.

Je n’ajoute donc pas une organisation parce que l’Europe fait les choses un peu différemment, ou qu’une division a son propre processus de vente, ou que les unités commerciales ne s’entendent pas. Ce sont des exigences, pas des frontières d’organisation. La question est : quelle force est assez puissante pour justifier une autre organisation ?

Plusieurs organisations ont un coût

Coupez une organisation en trois (Amérique du Nord, Europe, Asie-Pacifique) et vous n’avez pas dessiné trois jolies boîtes ; vous avez créé de nouvelles questions. Où vit un client mondial ? S’il opère dans deux régions : deux copies, et laquelle le possède ? Comment fait-on des rapports à l’échelle mondiale ? L’ERP s’intègre-t-il aux trois, l’entrepôt de données reçoit-il trois flux, le fournisseur d’identité se connecte-t-il aux trois ? Déployons-nous la même fonctionnalité trois fois et gardons-nous trois modèles de données alignés ? Si un agent a besoin d’une vue mondiale d’un client, à quelle organisation demande-t-il ?

Revenez au paysage du module 4. Une boîte Salesforce en devient trois, et chaque flèche est à redessiner. Le multi-organisation n’est pas une erreur. Il n’est jamais gratuit.

Cherchez les vraies frontières

Qu’est-ce qui peut justifier une autre organisation ? Des frontières assez réelles pour façonner l’architecture : la résidence des données, la réglementation, la séparation juridique, des modèles opérationnels réellement différents, une acquisition qui n’a pas encore convergé, une contrainte d’hébergement régionale, une gouvernance très différente, parfois le volume ou l’isolation. La liste n’est pas complète. L’essentiel est de distinguer « ces groupes sont différents » de « ces groupes ont besoin d’une frontière d’architecture ». La seconde barre est bien plus haute.

La géographie n’est pas automatiquement une stratégie d’organisation

« Nous opérons dans 30 pays, il nous faut donc 30 organisations. » Non. La géographie compte quand elle apporte une exigence d’architecture. Une entreprise peut avoir des utilisateurs partout dans le monde sur une architecture commune. Alors je ne compte pas les pays ; je demande ce qui vient avec eux. Où les données peuvent-elles être stockées ? Où peuvent-elles être traitées ? Y a-t-il des limites au transfert de données personnelles hors des frontières ? Des engagements contractuels sur la résidence ? Une région a-t-elle besoin d’un service ou d’un hébergeur Salesforce différent ? « Il y a un bureau en Allemagne » ne suffit pas à lui seul.

L’hébergement fait partie du dessin

C’est là que la plateforme moderne rend le paysage plus intéressant. Hyperforce exécute Salesforce sur une infrastructure de cloud public dans des régions du monde entier, ce qui donne aux clients plus de choix et de contrôle sur l’endroit où résident leurs données (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), en anglais). Alors quand j’étiquette une boîte « Salesforce, Europe », cet emplacement peut compter.

Mais soyez précis. Choisir où vit une organisation n’est pas une promesse que chaque octet de chaque service y reste. Salesforce invite les clients à examiner la documentation de confiance et de conformité d’Hyperforce, y compris les sous-traitants supplémentaires des services qu’ils achètent (même source). Ne dites donc pas « nous sommes sur Hyperforce dans le pays X, donc tout reste dans le pays X ». Sachez quels services vous utilisez réellement, et quelle exigence vous satisfaites. Et remarquez ce que vous choisissez : la région, pas le cloud qui est dessous. Hyperforce tourne sur AWS, avec Google Cloud à partir de fin 2026, et c’est Salesforce qui décide sur quel fournisseur se trouve une organisation ; un client qui a une raison réglementaire documentée d’en éviter un s’adresse à son équipe de compte (même source).

Ne jouez pas à l’avocat

C’est aussi là que les architectes doivent connaître leur rôle. Si quelqu’un dit « le droit européen de la protection des données exige une organisation séparée », je ne l’accepterai pas aveuglément. Je ne vais pas non plus m’improviser avocat de l’entreprise et déclarer que ce n’est pas le cas. Je demanderai : quelle exigence précise satisfaisons-nous ? Le lieu de stockage des données, le lieu de traitement, le transfert transfrontalier, qui peut y accéder pour le support, un contrat, une politique interne ? Ensuite, je travaille avec les équipes protection des données, sécurité, conformité et juridique pour traduire cette exigence en architecture. N’inventez pas d’exigences juridiques, et ne les ignorez pas. Traduisez-les.

Quand l’Europe a sa propre organisation

Voici une frontière que je vois dans des scénarios réels. Une entreprise a une forte présence aux États-Unis et une forte présence en Europe : deux grandes bases de clients, deux opérations de ventes et de service, et un programme européen de protection des données construit autour du RGPD. Le RGPD ne dit pas « il vous faut une organisation Salesforce séparée ». Il fixe des règles pour les données personnelles, y compris pour savoir quand elles peuvent être transférées hors de l’UE (RGPD, chapitre V (opens in a new tab)). Mais cette entreprise, en travaillant avec ses équipes protection des données et juridique, décide que les données personnelles de ses clients européens doivent vivre dans une organisation hébergée en Europe, gérée par son équipe européenne, sous sa gouvernance européenne. C’est une vraie exigence, et c’est la leur, pas la mienne.

Désormais, « une grande organisation mondiale » n’est plus une préférence. Il y a une frontière sur le paysage, Salesforce AMER et Salesforce EMEA, et je dois la dessiner. Et la deuxième organisation n’est jamais juste une boîte de plus.

Click to enlarge

Deux organisations, AMER et EMEA. L’ambre, c’est ce qu’ajoute la deuxième organisation : pas une boîte de plus, mais chaque flèche une nouvelle fois.

Parcourez de nouveau les flèches

Avec plus d’une organisation, parcourez de nouveau le paysage. L’ERP envoie-t-il les produits à chaque organisation ? Chacune renvoie-t-elle les commandes ? Où les clients sont-ils maîtrisés, et leurs données peuvent-elles traverser les régions ? La couche d’intégration est-elle mondiale ou régionale ? Quel fournisseur d’identité connecte quels utilisateurs ? Où vont les données analytiques ?

Trois endroits montrent le coût le plus vite :

Les rapports. Le PDG veut un pipeline mondial. Dans une seule organisation, c’est un rapport Salesforce. Dans trois, c’est un problème de rapports d’entreprise : répliquer, envoyer à l’entrepôt de données, fédérer ? À quel point les données doivent-elles être à jour, et les organisations définissent-elles seulement le « pipeline » de la même façon ? L’analytique vit là où vivent les données, et si vous séparez volontairement les données opérationnelles, vous devez concevoir comment les analyses se rejoignent.

Les données maîtres. Un client mondial achète aux États-Unis, en Allemagne et au Japon. Trois organisations, donc probablement trois comptes. Comment savez-vous que c’est la même entreprise ? Quel est l’identifiant mondial, et qui le possède ? Si une région change l’adresse, doit-elle se propager ? Quels attributs sont mondiaux et lesquels régionaux ? La stratégie d’organisation ne résout pas l’identité ; elle change le problème d’identité. C’est le chapitre 6.

L’intégration. Une organisation : Salesforce, la couche d’intégration, l’ERP. Trois organisations : trois connexions dans la couche d’intégration, peut-être une avec son propre hébergeur et sa propre connectivité, certains flux partagés, certains régionaux, certaines données autorisées à traverser et d’autres non. Même le réseau peut changer : si l’entreprise a besoin d’une connectivité privée dédiée vers Hyperforce (sur AWS, Salesforce recommande AWS Direct Connect ; même FAQ Hyperforce), chaque organisation et chaque hébergeur du dessin est une connexion de plus à planifier. L’endroit où s’exécute une organisation peut changer la façon dont le reste de l’entreprise l’atteint.

Une organisation ou plusieurs, c’est une décision que vous prenez maintenant, au début, sur le paysage. La façon dont les organisations partagent ensuite les données (Salesforce Connect inter-organisations, intégration entre elles, Data 360), c’est la mécanique, et le chapitre 14, Une organisation ou plusieurs ? (coming soon), la couvre.

Si vous concevez tout le modèle de données et toute l’architecture d’intégration et n’entendez qu’ensuite « au fait, il faut trois organisations », vous n’avez pas fait un petit ajustement. Vous avez changé l’architecture. C’est pourquoi la décision vient en premier.

Ne séparez pas juste pour rapetisser les boîtes

Une grande organisation paraît compliquée : beaucoup d’unités, d’objets, d’utilisateurs, d’intégrations. Quelqu’un dit : « Ce ne serait pas plus propre si chacun avait sa propre organisation ? » Le dessin serait peut-être plus propre. L’entreprise, peut-être pas. Vous avez échangé une complexité interne contre une complexité distribuée : synchronisation, données en double, identité entre organisations, rapports mondiaux, plusieurs pipelines de livraison, intégrations et automatisations dupliquées, et la gouvernance de tout cela. Parfois, c’est quand même le bon échange. Mais séparé ne veut pas dire simple.

Et une seule organisation n’est pas gratuite non plus. La gouvernance partagée compte davantage, les équipes peuvent s’affecter mutuellement, les frontières de sécurité demandent une conception soignée, le modèle de données doit servir de nombreux groupes, les livraisons demandent de la coordination, et les règles régionales peuvent contraindre tout le monde. Ce n’est donc pas « Steve dit toujours une seule organisation ». Mon parti pris de départ est une seule organisation ; puis je cherche l’exigence assez forte pour m’en faire changer.

Rendez la décision visible

Si la stratégie d’organisation compte, ne dessinez pas un nuage Salesforce générique. Dessinez les organisations et étiquetez-les (AMER, EMEA, ce qui est réel), notez l’exigence d’hébergement ou de résidence derrière chacune, et parcourez les connexions. Un autre architecte doit pouvoir voir pourquoi chaque frontière existe. Si je ne sais pas expliquer pourquoi il y a trois boîtes Salesforce, je n’ai pas fini de prendre la décision.

Steve Trucking a une seule organisation, aux États-Unis, et rien dans son dossier n’en demande une autre. Mais gardez ce module en tête pour le projet final : une acquisition qui arrive avec sa propre organisation est exactement le genre de frontière qui met ces questions à l’épreuve.

Au-delà de l’examen : ce que l’IA change. Un agent peut rendre une frontière d’organisation invisible pour l’utilisateur. En dessous, l’architecture doit toujours décider à quelle organisation ou à quel système l’agent peut demander, quelles données peuvent traverser les régions, et quelle réponse fait autorité. L’IA peut cacher la complexité dans l’expérience ; elle ne supprime ni la gouvernance ni la frontière.

Ce qu’un architecte décide ici

• S’il y a une vraie raison d’architecture d’avoir plus d’une organisation, plutôt que de résoudre les différences à l’intérieur d’une seule.
• Où s’exécute chaque organisation, et quelle exigence de résidence, réglementaire, contractuelle ou métier la place là.
• Quelles données peuvent franchir les frontières d’organisation et de région, où les données maîtres font autorité, et comment fonctionne l’identité mondiale.
• Comment l’intégration, l’identité, l’analytique et les rapports changent quand une boîte Salesforce en devient plusieurs.
• Si le bénéfice de la séparation vaut l’architecture distribuée qu’elle crée.

Quand je lis un scénario, je cherche d’abord cette décision : une organisation ou plusieurs, hébergées où, et imposées par quoi ? Répondez à cela, et le reste du paysage commence à prendre forme.

Pour aller plus loin

• Aide Salesforce, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (en anglais), consulté le 2026-10-14.
• EUR-Lex, Règlement (UE) 2016/679, règlement général sur la protection des données (opens in a new tab), chapitre V (transferts de données à caractère personnel vers des pays tiers), consulté le 2026-10-14.