À propos de plusieurs environnements ou clients en ligne

Les applications d’engagement client (Dynamics 365 Sales, Dynamics 365 Customer Service, Dynamics 365 Field Service, Dynamics 365 Marketing) vous offrent des possibilités d’isoler vos accès utilisateur et données. Pour la plupart des entreprises, l’ajout et l’utilisation de plusieurs environnements Power Platform fournit un ensemble adapté de fonctionnalités et de facilité de gestion. Les entreprises avec des entités distinctes qui souhaitent séparer le répertoire des licences peuvent envisager d’utiliser plusieurs clients. Plusieurs environnements sont accessibles à tous les utilisateurs du client. Plusieurs clients doivent inviter d’autres utilisateurs clients en tant qu’utilisateurs invités pour leur accorder l’accès.

Utilise plusieurs environnements

Les environnements sont similaires à un grand immeuble de bureaux, dont les étages sont organisés en fonction des fonctionnalités de l’entreprise. Envisagez chaque étage de l’immeuble comme une application (Ventes/Service/Marketing, Gestion des fournisseurs, Gestion des biens) et considérez chaque unité au sein de chaque étage comme un environnement lié à un objectif spécifique tel que Production, Formation, Tests et Développement.

Plusieurs environnements comme unités dans une création.

Plusieurs environnements sont nécessaires lorsque la séparation est requise pour les données, les plug-ins, les workflows ou les ressources d’administration qui ne peuvent pas être facilement isolés en utilisant des divisions.

Déploiement de plusieurs environnements

Un client type n’a qu’un seul client. Un client peut inclure un ou plusieurs environnements ; toutefois, un environnement est toujours associé à un client unique.

Déploiement du client unique.

Cet exemple utilise deux environnements pour trois équipes : Sales, Marketing et Services.

Les équipes Sales et Marketing partagent un environnement pour que les informations de prospect puissent être facilement accessibles par les deux. L’équipe Services a son propre environnement afin que les tickets et garanties puissent être gérés séparément des campagnes et autres événements liés aux ventes.

Vous pouvez fournir l’accès à un environnement ou les deux facilement. Les utilisateurs Sales et Marketing peuvent être limités à leur environnement tandis que les utilisateurs Services ayant un accès étendu peuvent mettre à jour des enregistrements d’escalades de support relatifs aux comptes dans les deux environnements.

Client unique avec plusieurs environnements :

  • Chaque environnement du client reçoit sa propre base de données SQL.

  • Les données ne sont pas partagées entre les environnements.

  • Voir Capacité de stockage de Microsoft Dataverse pour savoir comment le stockage est partagé entre les environnements.

  • Les environnements d’un client unique sont créés par défaut dans la zone géographique où ils se sont connectés à leur compte. De plus, le créateur de l’environnement peut choisir de créer l’environnement dans une zone géographique différente ; les zones géographiques autorisées seront affichées pour que l’utilisateur puisse les choisir. Dans certaines circonstances, les utilisateurs devront pouvoir voir ou sélectionner toutes les zones géographiques prises en charge par Power Platform.

  • La consommation de stockage est comptabilisée et suivie sur tous les environnements joints à un client.

  • Vous pouvez configurer des groupes de sécurité distincts pour les environnements si vous souhaitez contrôler qui peut voir et accéder à un environnement.

  • Un utilisateur sous licence peut potentiellement accéder à tous les environnements associés au client. L’accès est contrôlé par l’appartenance au groupe de sécurité de l’environnement.

Pourquoi utiliser plusieurs environnements ?

Voici les cas d’utilisation courants pour le déploiement à plusieurs environnements. Prenez en compte ces exemples lorsque vous choisissez le type de déploiement qui correspond le mieux aux exigences de votre entreprise.

Gestion des données de base

Dans ce scénario, un ensemble de données « maître » permet la gestion des modifications par le biais d’une source centrale de données principales. Cette méthode nécessite que les données de base centrales soient synchronisées avec tous les environnements de telle sorte que chaque environnement ait accès à la dernière version des informations principales. Les modifications requises pour les informations peuvent être effectuées directement dans le système principal. Sinon, les utilisateurs peuvent accéder explicitement au système principal ou recueillir les modifications de l’environnement local, ces modifications étant ensuite transmises à l’environnement principal.

Demander à ce que ces modifications soient faites de façon centralisée peut fournir un contrôle centralisé des modifications. Par exemple, il est possible d’effectuer des vérifications antifraude pour s’assurer que les changements sont effectués uniquement par une équipe centrale et non par des équipes locales qui pourraient autrement bénéficier d’un changement, comme d’une modification des limites de crédit. Cela fournirait un deuxième niveau d’autorisation et de vérification des modifications qui évite à une seule personne ou à un groupe de personnes qui travaillent en étroite collaboration de collaborer pour lutter contre une fraude. Envoyer une demande à une autre équipe indépendante peut fournir une protection contre les fraudes potentielles.

Sécurité et confidentialité

Des différences dans la législation régionale, par exemple l’Union européenne (UE) ou nationale peuvent entraîner des variations dans les exigences de sécurisation des données ou de maintien de la confidentialité des données entre les différentes régions ou pays d’un déploiement. Dans certains cas, les restrictions législatives / réglementaires rendent illégal l’hébergement de données en dehors des frontières d’un pays ou d’une région, et relever ce défi est particulièrement critique dans certains secteurs d’activité.

Par exemple, considérez les restrictions du secteur de la santé sur le partage des informations des patients. Certaines réglementations de l’UE exigent que toutes les informations collectées sur la santé des personnes résidant dans l’UE soient conservées et partagées uniquement à l’intérieur des frontières de l’UE, tandis que des données similaires collectées sur les personnes aux États-Unis (US) sont conservées à l’intérieur des frontières américaines. Tenez également compte des restrictions du secteur bancaire concernant le partage des informations client. En Suisse, par exemple, les réglementations rendent illégal le partage des informations concernant les clients en dehors des frontières nationales.

Évolutivité

Bien qu’un environnement unique puisse évoluer et soutenir la croissance de l’entreprise d’un client, avec des volumes de données ou des niveaux de complexité très élevés, des considérations supplémentaires entrent en jeu. Par exemple, dans des environnements avec des volumes extrêmes et / ou une utilisation importante de la Planification de service, la mise à l’échelle de SQL Server peut nécessiter une infrastructure compliquée et coûteuse qui est prohibitive ou extrêmement difficile à gérer.

Il existe de nombreux scénarios pour lesquels il existe une répartition fonctionnelle naturelle des besoins en capacités. Dans ce cas, la délégation des charges de travail par la création de scénarios d’évolution basés sur ces fractionnements fonctionnels peut satisfaire les besoins en volumes plus élevés à l’aide d’une infrastructure de produits.

Ajouter un environnement à votre abonnement

Pour plus d’informations sur la façon d’ajouter un environnement à votre client, voir Créer et gérer des environnements.

Déploiement partagé au sein d’une architecture mutualisée

Les entreprises internationales dont les modèles régionaux ou nationaux diffèrent peuvent utiliser les abonnés pour tenir compte des variations d’approche, de taille du marché ou de respect des contraintes légales et réglementaires.

Déploiement à plusieurs clients.

Cet exemple inclut un deuxième abonné pour Contoso Japan.

Les comptes d’utilisateurs, les identités, les groupes de sécurité, les abonnements, les licences et le stockage ne peuvent pas être partagés entre les clients. Tous les clients peuvent avoir plusieurs environnements associés à chaque client spécifique. Les données ne sont pas partagées entre les environnements ou les clients.

Clients multiples :

  • Dans un scénario de plusieurs clients, un utilisateur sous licence associé à un client peut uniquement accéder à un ou plusieurs environnements mappés au même client. Pour accéder à un autre client, un utilisateur doit être invité en tant qu’utilisateur invité et peut avoir besoin d’une licence distincte.

  • Chaque client a besoin des administrateurs Microsoft Power Platform avec des informations d’accès uniques, et chaque affilié client gérera son client séparément dans la console administrateur.

  • Plusieurs environnements d’un client sont visibles à partir de l’interface si l’administrateur a accès.

  • Vous ne pouvez pas réaffecter de licences entre les inscriptions d’abonnés. Un affilié inscrit peut utiliser la réduction de licence sous une seule inscription et ajouter des licences à une autre inscription pour plus de facilité.

  • La fédération Active Directory locale ne peut pas être établie avec plusieurs clients à moins que vous disposiez de domaines de niveau supérieur que vous devez fédérer avec différents clients (par exemple Contoso.com et Fabricam.com).

Pourquoi utiliser plusieurs clients ?

Localisation fonctionnelle

Ce scénario se présente généralement dans les organisations ayant des exigences fonctionnelles qui se chevauchent mais sont séparées. Voici quelques exemples courants :

  • Organisations avec différentes divisions commerciales, chacune avec un marché ou un modèle de fonctionnement différent.

  • Les entreprises internationales dont les modèles régionaux ou nationaux diffèrent pour tenir compte des variations d’approche, de taille du marché ou de respect des contraintes légales et réglementaires.

    Dans ces types d’environnements d’entreprise, une organisation a souvent un ensemble commun de fonctionnalités permettant aux régions, pays ou secteurs d’activité spécifiques d’avoir un certain niveau de localisation sur les éléments suivants :

  • Capture d’informations. Par exemple, la capture des codes postaux aux États-Unis serait en corrélation avec la capture des codes postaux au Royaume-Uni.

  • Formulaires, workflows.

Distribution physique

Pour les solutions professionnelles qui doivent prendre en charge des utilisateurs qui sont physiquement distribués sur de grandes distances, notamment pour les déploiements mondiaux, l’utilisation d’un environnement unique peut ne pas convenir à cause des implications (par exemple la latence WAN) associées à l’infrastructure via laquelle les utilisateurs se connectent, pouvant sensiblement impacter l’expérience utilisateur. La distribution d’environnements pour fournir aux utilisateurs un accès plus local peut réduire ou résoudre les problèmes de WAN, car l’accès se produit sur des connexions réseau plus courtes.

Ajouter un déploiement partagé au sein d’une architecture mutualisée sous le programme de licence en volume

Pour un déploiement partagé au sein d’une architecture mutualisée, vous devez disposer d’un avenant pour plusieurs clients. Un avenant pour plusieurs clients est un avenant ajouté au contrat de licence en volume utilisé pour acheter des licences. Contactez votre commercial ou revendeur Microsoft pour obtenir cet avenant.

Contraintes d’une architecture mutualisée

Les administrateurs qui souhaitent déployer et gérer plusieurs clients doivent connaître les points suivants :

  • Les comptes d’utilisateurs, les identités, les groupes de sécurité, les abonnements, les licences et le stockage ne peuvent pas être partagés entre les clients.

  • Un seul domaine ne peut être fédéré qu’avec un seul abonné.

  • Chaque abonné doit avoir son propre espace de noms ; les espaces de noms UPN ou SMTP ne peuvent pas être partagés entre les abonnés.

  • Si une organisation Exchange locale existe, vous ne pouvez pas diviser cette organisation entre plusieurs abonnés.

  • Une liste d’adresses globale consolidée ne sera pas disponible, sauf si elle est gérée explicitement en aval de la synchronisation.

  • La collaboration entre les clients est limitée à la fédération de Lync et aux fonctions de fédération d’Exchange.

  • L’accès à SharePoint entre les clients n’est pas possible. Bien que cela puisse être résolu avec l’accès du partenaire, l’expérience utilisateur est perturbée et les aspects des licences s’appliquent.

  • Il ne peut pas y avoir de comptes en double sur les abonnés ou sur les partitions dans Active Directory local.

Voir aussi

Blog : Qu’est-ce qu’un client ?
Vue d’ensemble des environnements