Développer une stratégie d’environnement des locataires à adopter Power Platform à grande échelle
Le parcours d’adoption de chaque organisation Microsoft Power Platform est unique. Une stratégie d’environnement locataire jette les bases pour accélérer l’utilisation de manière gérable et sécurisée.
Ce livre blanc vous montre comment aligner votre Power Platform stratégie d’environnement locataire sur les capacités et la vision du produit. Vous apprenez comment utiliser au mieux les dernières fonctionnalités de la plate-forme pour mettre en œuvre une stratégie qui peut permettre votre adoption Power Platform pour atteindre l’échelle de l’entreprise.
Note
Vous pouvez enregistrer ou imprimer ce livre blanc en sélectionnant Imprimer dans votre navigateur, puis Enregistrer au format PDF.
Introduction
Power Platform permet aux organisations de créer des solutions low-code pour une innovation rapide. Ces solutions peuvent se concentrer sur la productivité des individus et des petites équipes, ou s’appliquer à l’ensemble de l’organisation. Ils peuvent également s’étendre aux processus métier, y compris aux clients et partenaires externes. Ces solutions sont prises en charge par des Power Platform environnements dans lesquels les ressources low-code sont créées, testées et utilisées. À mesure qu’une organisation augmente son adoption de Power Platform, la mise en œuvre d’une bonne stratégie d’environnement de locataire est essentielle pour la rendre gérable et sécurisée à mesure que le nombre d’environnements augmente.
Pour vous aider à mieux réussir, cet article vous guide sur la meilleure façon d’utiliser les fonctionnalités disponibles pour établir votre première stratégie d’environnement ou faire évoluer vos plans actuels. Nous décrivons également notre vision de la façon dont ces fonctionnalités sont censées fonctionner ensemble et comment elles évolueront pour une gestion Power Platform à grande échelle. Dans ce guide, nous expliquons comment acheminer correctement les nouveaux utilisateurs vers des environnements et des environnements de groupe afin d’appliquer de manière cohérente la gouvernance, les règles de sécurité et d’autres aspects importants d’une stratégie d’environnement de locataire. Nous fournissons également des étapes détaillées pour sécuriser votre environnement par défaut, ce qui constitue une première étape essentielle dans la mise en œuvre d’une stratégie d’environnement.
Bien que de nombreux Perspectives soient disponibles pour la gestion des environnements, l’approche de cet article s’aligne sur la dernière orientation produit de et utilise les fonctionnalités actuelles et les améliorations prévues à court terme. Power Platform Microsoft Ces conseils mis à jour peuvent vous aider à garantir que vous utilisez uniquement les fonctionnalités et options environnement qui sont stratégiques par rapport à la manière dont vous envisagez de gérer les environnements à grande échelle. Microsoft
MicrosoftLa vision stratégique du locataire environnement
De nombreuses organisations commencent leur Power Platform parcours avec des applications de productivité personnelle et des automatisations créées et exécutées dans un environnement central partagé appelé environnement par défaut. Ces ressources utilisent souvent uniquement les fonctionnalités de base incluses dans Microsoft 365 et n’utilisent pas toutes les fonctionnalités de Power Platform. À mesure que cette adoption initiale s’accélère, Microsoft offre aux organisations une rampe d’accès vers une stratégie environnement pour l’adoption à l’échelle de l’entreprise de toutes les Power Platform capacités. Ces fonctionnalités de gouvernance premium sont disponibles lorsque les utilisateurs disposent d’une licence premium Power Platform (Power Apps, Power Automate, Microsoft Copilot Studio et Dynamics 365). Le Power Platform modèle de maturité d’adoption peut fournir davantage d’informations pour aider les organisations à définir leur feuille de route pour parvenir à une adoption à l’échelle de l’entreprise au-delà de leur stratégie d’environnement. Cette approche peut aider les organisations à passer de la productivité personnelle de base à l’adoption à l’échelle de l’entreprise de Power Platform.
Power Platform les fonctionnalités d’administration, de gouvernance et de sécurité permettent aux organisations d’adopter et de gérer Power Platform pour la productivité de l’entreprise et l’utilisation des applications d’entreprise à grande échelle. L’utilisation d’environnements gérés active un ensemble de fonctionnalités premium qui permettent une visibilité et un contrôle accrus et réduisent l’effort manuel d’administration et de sécurisation des environnements. Grâce à ces fonctionnalités, vous pouvez garantir une application cohérente de vos politiques de gouvernance et de sécurité. Les administrateurs peuvent passer à une stratégie d’environnement à l’échelle de l’entreprise en utilisant ces fonctionnalités. Consacrer moins de temps et d’efforts à l’administration permet de réduire le coût total de possession (TCO) global de la plateforme à mesure que votre organisation augmente son utilisation.
Un élément clé de la transition vers l’échelle de l’entreprise consiste à améliorer la stratégie d’environnement central et partagé pour les créateurs en leur permettant d’utiliser plus facilement des environnements de développement personnels. Dans une stratégie d’environnement centralisé et partagé, les créateurs créent, utilisent et partagent des applications dans l’environnement par défaut. Cette stratégie peut entraîner un manque d’isolement et un empiètement des créateurs les uns sur les autres. Imaginez si tout le monde dans l’entreprise partageait un seul, OneDrive dossier pour tous leurs documents. Au lieu de cela, vous pouvez utiliser les fonctionnalités de l’environnement pour guider les créateurs vers leur propre environnement personnel où ils peuvent créer en toute sécurité leurs applications, protégées des créateurs travaillant sur des actifs non liés, avec une gouvernance simplifiée pour les administrateurs. Des collègues peuvent être ajoutés en tant que créateurs supplémentaires à ces environnements pour collaborer à la création de solutions.
Figure : Illustration d’une stratégie de routage environnement centrale partagée (à gauche) et d’une stratégie de routage environnement (à droite).
Les environnements créateur nouvellement créés peuvent être automatiquement ajoutés à un groupe qui applique des règles pour garantir que les environnements ont des politiques de gouvernance et de sécurité cohérentes. Les administrateurs peuvent gérer les exceptions en déplaçant l’environnement d’un créateur vers un groupe avec des règles assouplies.
Les ressources low-code créées par les créateurs représentent l’étape initiale du parcours de gestion du cycle de vie des applications (ALM) d’une ressource. Dans le cadre de cette étape initiale, il est important de capturer chaque version d’une ressource et de pouvoir la recréer, si nécessaire. Lorsque la ressource est prête à être partagée, le créateur peut utiliser l’intégration continue attachée à l’environnement de développement pour la promouvoir vers un environnement de production, où les utilisateurs peuvent exécuter la ressource indépendamment de toute activité continue du créateur.
Vous devez donner la priorité aux fonctionnalités intégrées de la plateforme pour gérer les environnements lorsque cela est possible, au lieu de créer vos propres outils. Si les fonctionnalités intégrées ne répondent pas aux exigences uniques de votre organisation, vous pouvez utiliser les outils d’administration de la plateforme pour créer des outils personnalisés. Vous devez évaluer tout outil personnalisé par rapport aux nouvelles fonctionnalités, dès qu’elles deviennent disponibles. Garder un œil sur la feuille de route de la plateforme et maintenir votre propre feuille de route peut vous aider à rendre cela plus facile. Microsoft
Vous devez établir votre stratégie d’environnement en utilisant les fonctionnalités d’environnement recommandées, adaptées aux besoins uniques de votre organisation. Ne considérez pas la création de votre stratégie environnementale comme une activité ponctuelle. Il devrait évoluer au fil du temps pour intégrer de nouvelles fonctionnalités d’environnement, à mesure qu’elles deviennent disponibles.
Fonctionnalités qui prennent en charge une stratégie environnementale à l’échelle de l’entreprise
Les environnements sont un bloc élémentaire pour Power Platform l’administration, la gouvernance et la sécurité. Un aperçu complet des fonctionnalités sort du cadre de cet article ; cependant, cette section met en évidence les fonctionnalités qui prennent en charge la mise en œuvre d’une stratégie environnementale à l’échelle de l’entreprise.
Types d’environnements décrit les différentes utilisations des environnements dans le cadre de votre stratégie.
promouvoir fournit un ensemble de fonctionnalités premium qui facilitent la gestion des environnements à grande échelle.
La réclamation automatique de licence simplifie l’attribution de licences en permettant aux utilisateurs de réclamer Power Apps des licences par utilisateur lorsqu’ils en ont besoin, au lieu de demander à un administrateur d’identifier à l’avance les utilisateurs qui ont besoin de licences.
environnement groupes et règles explique comment gérer les environnements en tant que groupes et appliquer des règles aux groupes pour automatiser des politiques de gouvernance cohérentes.
Le routage par défaut environnement déplace automatiquement les créateurs de la création de ressources dans le routage par défaut environnement vers leur propre routage personnel environnement.
Microsoft Dataverse offre une sécurité et une gestion des actifs améliorées.
Les solutions préférées aident les créateurs à garantir que tous les actifs qu’ils créent se trouvent dans une Dataverse solution, ce qui facilite leur transfert vers d’autres environnements.
Le catalogue de Power Platform permet aux créateurs de Partager des composants, comme des applications et des flux, et des points de départ plus avancés, tels que des modèles.
Types d’environnements
Le tableau suivant décrit les types d’environnements que vous pouvez créer, leurs caractéristiques et leurs utilisations prévues.
| Type | Caractéristiques et utilisations |
|---|---|
| Default | L’environnement qui accompagne chaque locataire. De nombreuses Microsoft 365 expériences utilisent cet environnement pour les personnalisations et les automatisations. Cet environnement n’est pas destiné à un travail à long terme ou permanent au-delà des Microsoft 365 scénarios de productivité personnelle. |
| Production | Cet environnement est destiné à être utilisé pour un travail permanent dans une organisation. Les environnements de production prennent en charge une conservation des sauvegardes étendue, de sept jours à 28 jours maximum. |
| Bac à sable | Ces environnements hors production prennent en charge des actions d’environnement telles que la copie et la réinitialisation. Les sandbox sont mieux utilisés pour les tests et les environnements de création ALM. |
| Développeur | Ces environnements spéciaux sont conçus comme des espaces de travail de développement personnels des créateurs, qui isolent les ressources low-code des utilisateurs et des autres créateurs. Les créateurs peuvent disposer de trois environnements de développeur au maximum. Ils ne comptent pas dans votre capacité de locataire. Les environnements de développement qui n’ont pas été utilisés depuis 90 jours sont automatiquement désactivés, puis supprimés de votre locataire si le propriétaire ne répond pas aux notifications. Les applications Dynamics 365 ne sont pas disponibles dans les environnements de développeur. |
| Évaluation | Ces environnements sont destinés à prendre en charge les tests à court terme et les preuves de concept. Ils sont limités à un par utilisateur. Les environnements de test sont automatiquement supprimés de votre locataire après une courte période de temps. |
| Microsoft Dataverse for Teams | Ces environnements sont automatiquement créés lorsque vous créez une application dans Teams ou installez une application à partir du catalogue d’applications. Le modèle de sécurité de ces environnements s’aligne sur l’équipe à laquelle ils sont associés. |
| Assistance | Il s’agit d’environnements spéciaux créés par le support pour permettre aux ingénieurs de résoudre les problèmes. Microsoft Ces environnements ne comptent pas dans votre capacité de locataire. |
Lorsque vous élaborez une stratégie globale d’environnement de locataire, les différents types sont pertinents pour prendre en charge les recommandations stratégiques.
Environnements gérés
Les environnements disposent d’un ensemble de fonctionnalités et de caractéristiques de base en fonction du type d’environnement. Les environnements gérés développent les fonctionnalités de base pour fournir une suite de fonctionnalités premium qui permettent aux administrateurs de mieux gérer Power Platform à grande échelle avec plus de contrôle, moins d’efforts et plus d’insights. Ces fonctionnalités sont déverrouillées lorsque vous définissez un environnement comme géré.
Le tableau suivant répertorie les fonctionnalités des environnements gérés disponibles au moment d’écrire ces lignes. De nouvelles fonctionnalités sont souvent ajoutées, alors consultez la documentation pour connaître la liste la plus récente. Bien que toutes les fonctionnalités puissent vous aider à élaborer une stratégie environnementale, les fonctionnalités en italique sont plus pertinentes pour la stratégie décrite dans cet article.
| Plus de visibilité | Plus de contrôle | Moins d’effort |
|---|---|---|
| Informations sur l’utilisation Résumé de l’administrateur Rapports de licence Vue de la politique de données Exporter des données vers Azure Application Insights Descriptions générées par l’IA pour toutes les applications |
Limites de partage Politiques de données pour les flux Bureau Vérificateur de solution Contenu de bienvenue du créateur Pare-feu IP Liaison de cookie IP Clés gérées par le client Coffre-fort client Sauvegardes étendues |
Activation facile Power Platform canalisations Routage environnement Groupes et règles environnement Power Platform conseiller |
Réclamation automatique de licence
Les politiques de réclamation automatique automatisent l’attribution de Power Apps et Power Automate licences aux utilisateurs lorsqu’ils en ont besoin pour utiliser certaines applications ou fonctionnalités. L’automatisation peut contribuer à réduire le nombre de licences consommées et à éviter les frais liés à l’attribution manuelle des licences.
Une fois qu’une stratégie est configurée, tout utilisateur de l’organisation ayant besoin d’un individu Power Apps la licence est automatiquement accordée dans les conditions suivantes :
Si un utilisateur sans licence Power Apps autonome lance une application nécessitant une licence Premium, le système attribuer automatiquement à l’utilisateur une licence Power Apps par utilisateur.
Si un utilisateur sans licence Power Apps autonome lance une application dans un environnement géré, le système attribuer automatiquement à l’utilisateur une licence Power Apps par utilisateur.
De même, une fois qu’une stratégie est configurée, tout utilisateur de l’organisation ayant besoin d’un individu Power Automate la licence est automatiquement accordée dans les conditions suivantes :
L’utilisateur déclenche, enregistre ou active un flux cloud premium avec RPA (automatisation robotisée des processus) assisté.
L’utilisateur demande une licence Premium Power Automate.
Nous vous recommandons de configurer la revendication automatique de licence si votre stratégie d’environnement inclut des environnements gérés. Les utilisateurs d’applications et de flux rencontrent le moins de frictions en matière de licences, et vous consommez uniquement des licences pour les utilisateurs qui exécutent activement des applications ou utilisent Power Automate.
Groupes d’environnements et règles
Comme Power Platform l’adoption dans votre locataire augmente, tout comme le nombre d’environnements nécessitant une administration et une gouvernance. À mesure que le nombre d’environnements augmente, plus il devient difficile de garantir que vous avez appliqué des paramètres et des politiques de gouvernance cohérents sur les environnements. La fonctionnalité de groupes d’environnements facilite cette tâche en vous permettant de créer des groupes nommés et d’y associer des environnements, par exemple en plaçant des documents associés dans un dossier de fichiers.
Gardez les considérations suivantes à l’esprit lorsque vous envisagez d’utiliser des groupes d’environnement :
Un environnement doit être géré pour être inclus dans un groupe.
Un environnement peuvent résider dans un seul groupe à la fois.
Un environnement peut être déplacé d'un groupe à une autre.
Les environnements d’un groupe peuvent provenir de plusieurs régions géographiques.
Les groupes ne peuvent pas contenir d’autres groupes.
Pour vous aider à appliquer des paramètres et une gouvernance cohérents, les groupes d’environnement peuvent avoir une ou plusieurs des règles suivantes configurées et activées :
Partage des contrôles pour les applications canevas en cours
Informations sur l’utilisation
Contenu d’accueil du créateur
Mise en application du vérificateur de solution
Conservation des sauvegardes
Descriptions générées par l’IA
Une règle devient active lorsqu’elle est publiée. Les règles actives sont appliquées à tous les environnements associés au groupe.
Lorsqu’une règle de groupe gère un paramètre, les paramètres d’environnement individuels sont verrouillés. La seule façon de les changer est de modifier la règle. Si l’environnement est supprimé du groupe, il conserve les paramètres du groupe, mais un administrateur de l’environnement peut désormais les modifier. Ceci est important pour une stratégie d’environnement, car cela garantit qu’un administrateur d’environnement ne peut pas remplacer les stratégies que vous avez définies pour le groupe.
L’utilisation de groupes d’environnements vous permet d’organiser vos environnements de manière logique, similaire à votre structure organisationnelle, à votre hiérarchie de services de produits ou à d’autres cadres que nous explorerons plus tard. Le diagramme suivant est un exemple conceptuel de la manière dont l’organisation Contoso pourrait organiser ses groupes d’environnement.
Figure : Conceptualisation d’une stratégie environnement pour un locataire Contoso.
Lorsque vous planifiez les règles à configurer, réfléchissez à ce que vous pourriez appliquer à chaque niveau de la hiérarchie conceptuelle. Bien que vous ne puissiez pas encore configurer la hiérarchie des groupes, vous pouvez utiliser une combinaison de conventions de dénomination et de configuration de règles pour implémenter votre conception conceptuelle. Par exemple, compte tenu de la conceptualisation du client Contoso présentée précédemment, l’illustration suivante représente les groupes d’environnement que l’organisation pourrait utiliser pour mettre en œuvre sa conception.
Figure : Exemple d’implémentation des groupes conceptuels environnement dans le locataire réel
Plus loin dans cet article, nous explorons d’autres façons d’utiliser les groupes d’environnements dans le cadre d’une stratégie d’environnement de locataire.
Routage de l’environnement par défaut
Un élément clé de la stratégie environnementale que nous décrivons dans cet article consiste à éloigner les créateurs de la création de ressources dans l’environnement par défaut. La fonctionnalité de routage d’environnement redirige les créateurs vers leur propre environnement de développement personnel et crée de nouveaux environnements de développement, selon les besoins.
Figure : Un créateur est automatiquement redirigé vers un environnement de développeur personnel au lieu du environnement par défaut lors de la création d’applications.
Les environnements de développement créés par routage sont gérés par défaut. Les utilisateurs disposant de licences Developer Plan sont limités à la création et à la prévisualisation des ressources dans l’environnement. Pour exécuter les ressources en tant qu’utilisateur, ils ont besoin d’une licence appropriée.
Vous pouvez utiliser le routage d’environnement seul, mais la méthode recommandée consiste à l’utiliser avec des groupes d’environnement. Lorsqu’il est utilisé de cette manière, tout environnement créé est associé au groupe que vous désignez pour contenir tous les nouveaux environnements de développement, garantissant ainsi qu’il est immédiatement couvert par vos politiques de gouvernance.
Les créateurs se voient automatiquement attribuer un rôle de sécurité qui en fait un administrateur de leur environnement de développement. Lorsque l’environnement fait partie d’un groupe d’environnements, le créateur (en tant qu’administrateur de l’environnement) ne peut pas modifier les paramètres d’environnement car ils sont gérés par les règles du groupe d’environnements. Seuls les administrateurs, qui peuvent modifier les règles du groupe, peuvent apporter des modifications.
Vous pouvez imposer encore plus de contrôle de deux manières. D'abord, vous pouvez désactiver la création manuelle d’environnements de développeur dans les paramètres de votre client. Lorsque cette option est définie, les créateurs ne peuvent pas créer eux-mêmes d’environnements dans le portail d’administration. Ils n’en obtiendront pas non plus automatiquement créés par la politique de routage. Deuxièmement, vous pouvez spécifier un groupe de sécurité, dans la stratégie de routage, pour limiter les personnes pouvant créer automatiquement un environnement.
Initialement, le routage d’environnement prend en charge l’éloignement des créateurs nouveaux et existants de l’environnement par défaut lorsqu’ils utilisent make.powerapps.com. Au fil du temps, d’autres Power Platform services prendront en charge la fonctionnalité de routage d’environnement.
Microsoft Dataverse
Dataverse stockez et gère en toute sécurité les données utilisées par les applications. Dans le contexte d’une stratégie d’environnement, la Dataverse fonctionnalité de solution est ce que vous utilisez pour transporter des applications et des composants d’un environnement à un autre. Les créateurs créent leurs actifs dans des conteneurs (des solutions) qui suivent ce qu’ils créent. Les solutions peuvent facilement être transportées vers d’autres environnements. Grâce à cette approche, vous pouvez séparer les environnements de développement, dans lesquels les créateurs créent des ressources, des environnements de production dans lesquels elles sont utilisées. Les créateurs et les utilisateurs en bénéficient. Les créateurs peuvent continuer à faire évoluer leurs ressources et les utilisateurs ne sont pas surpris par des changements soudains. Lorsque les créateurs sont prêts à publier leurs modifications, ils peuvent demander à promouvoir la ressource mise à jour dans l’environnement de production.
Dataverse Les solutions sont le mécanisme de mise en œuvre de l’ALM dans produits Power Platform comme Power Apps et Power Automate. Pipelines dans Power Platform utiliser des solutions pour automatiser le CI/CD des actifs créés par les créateurs. Les solutions peuvent être exportées depuis Dataverse et stocké dans un outil de contrôle de source comme Azure DevOps ou GitHub. La solution en matière de contrôle de code source devient la source de vérité si vous devez recréer l’environnement de développement. Par exemple, si un créateur crée une application populaire puis supprime l’environnement de développement, une solution exportée stockée dans le contrôle de source pourrait être utilisée pour recréer un environnement de développement viable.
Une autre considération importante lorsque vous créez un environnement avec Dataverse, indique si des applications Dynamics 365 seront déployées dans l’environnement. Si le potentiel existe, vous devez activer Dynamics 365 lorsque vous créez l’environnement, sinon vous ne pourrez pas installer les applications Dynamics 365 ultérieurement.
Nous vous recommandons de provisionner Dataverse dans n’importe quel environnement où les créateurs créent des actifs qui seront partagés avec d’autres utilisateurs. Cela facilite la préparation des actifs pour ALM.
Solution par défaut
Lorsqu’un créateur crée un Dataverse actif dans un Dataverse environnement et ne démarre pas à partir d’une solution personnalisée l’actif est associé à la solution par défaut et peut-être aussi à la Common Data Service solution par défaut. La solution par défaut est partagée par tous les créateurs qui créent des actifs dans l’environnement. Il n’existe pas de moyen simple d’identifier quel fabricant a créé quels composants ou quels actifs appartiennent à quelles applications. Cela peut rendre difficile la promotion d’une application populaire dans un autre environnement pour la partager avec un audience plus grand. Vous devrez promouvoir tous les actifs dans la solution par défaut, ce qui n’est pas un scénario idéal.
Pour soutenir votre stratégie d’environnement et faciliter son utilisation, les créateurs doivent créer une solution personnalisée dans leur environnement de développement, puis la définir comme solution solution préférée dans l’environnement. Les créateurs définissent la solution préférée dans un environnement pour indiquer à quelle solution un actif qu’ils ont créé doit être associé. Les solutions privilégiées peuvent contribuer à garantir que lorsque les créateurs utilisent des pipelines pour promouvoir leurs ressources vers d’autres environnements, la solution promue contient tous les actifs requis. Considérez cela comme la préparation des actifs à être prêts pour l’ALM.
Pipelines dans Power Platform
Comme nous l’avons vu, l’un des principes clés d’une bonne stratégie environnementale est d’isoler l’endroit où un actif est construit de l’endroit où il est déployé et utilisé. Cette séparation garantit que les utilisateurs qui tentent d’utiliser un actif ne subissent pas de temps d’arrêt parce qu’un fabricant le met à jour. Cependant, cela nécessite que les actifs soient promus dans un environnement de production, idéalement dans le cadre d’un Dataverse solution avant de pouvoir être utilisés.
Dataverse Les solutions peuvent être transportées manuellement entre environnements. Cependant, vous pouvez automatiser le processus et mettre en place des politiques pour garantir une gestion appropriée des changements en utilisant pipelines. En fonction des règles d’environnement que vous avez définies dans le vérificateur de solutions, les pipelines appliquent automatiquement toutes les règles avant le déploiement de la solution, évitant ainsi d’autres erreurs de déploiement. Le diagramme suivant illustre comment les pipelines peuvent automatiser la promotion d’un actif du développement à la production.
Figure : Un pipeline automatise la promotion d’un actif stocké dans le contrôle de source depuis le développement, en passant par les tests, jusqu’à la production.
Vous pouvez configurer le nombre d’environnements et de processus, comme les approbations, qui doivent être inclus dans un pipeline.
Les pipelines travaillent en collaboration avec des groupes environnementaux. Ils peuvent être préconfigurés pour les environnements de développement afin de permettre aux créateurs de démarrer facilement le processus de promotion en répondant à une invite lorsqu’ils tentent de partager leurs actifs avec d’autres utilisateurs. Dans le cadre d’une demande de déploiement utilisant des pipelines, les créateurs peuvent proposer avec qui partager leurs actifs et les rôles de sécurité requis. Un administrateur de pipeline peut approuver ou rejeter la demande avant le déploiement en garantissant le minimum de privilèges au créateur qui l’a émise.
Les pipelines stockent les définitions de chaque pipeline dans un hôte environnement qu’il gère par défaut. Power Platform Microsoft Cependant, vous pouvez définir plusieurs environnements hôtes dans votre locataire que vous gérez, ce qui vous permet de gérer des exigences uniques.
Catalogue dans Power Platform
Les organisations dans lesquelles les développeurs et les créateurs créent et partagent des composants, tels que des applications et des flux, ainsi que des modèles, qui constituent des points de départ plus avancés, ont tendance à tirer davantage de valeur Power Platform. Le Power Platform catalogue permet aux créateurs de Partager leurs composants et modèles dans différents environnements de manière plus efficace.
Le catalogue est installé dans un environnement et peut être installé avec l’hôte du pipeline dans le même environnement. Il est également possible de gérer des exigences uniques en matière de segmentation des ressources en installant plusieurs environnements sur lesquels un catalogue est installé.
Feuille de route des fonctionnalités
À mesure que les fonctionnalités de Microsoft qui prennent en charge la gouvernance et l’administration continuent d’évoluer, vous pouvez suivre le mouvement suivre dans le Power Platform Planificateur de versions . Vous apprenez ce qui est prévu, le contenu de la prochaine vague de versions et ce que vous pouvez essayer maintenant. Vous pouvez même créer votre propre plan de publication en enregistrant les éléments que vous souhaitez suivre.
Fondation d’une stratégie environnementale à l’échelle de l’entreprise
Nous avons discuté de notre vision d’une stratégie d’environnement locataire à l’échelle de l’entreprise et des fonctionnalités clés de l’environnement qui la prennent en charge. Voyons maintenant comment vous pouvez utiliser ces fonctionnalités ensemble dans le cadre d’une stratégie environnementale. Votre stratégie doit être basée sur les exigences uniques de votre organisation. Commençons donc par un exemple de base avant de passer à la manière d’adapter une stratégie pour répondre à vos besoins.
Dans cet exemple, la direction de Contoso souhaite permettre aux employés de tirer parti de Power Platform et a identifié les exigences générales suivantes :
Les employés doivent être capables de créer des processus automatisés d’approbation de documents et d’autres Power Platform personnalisations avec Microsoft 365.
Les employés doivent être capables de créer Power Apps et Power Automate des automatisations pour améliorer leur productivité personnelle.
Les créateurs qui travaillent sur l’application Compliance Tracker de l’entreprise doivent être capables de la développer et de la maintenir.
Pour prendre en charge ces exigences, l’équipe d’administration et de gouvernance de Contoso a proposé la topologie d’environnement suivante :
Figure : Topologie environnement proposée pour le projet à grande échelle de Contoso. Power Platform
Explorons ce diagramme de topologie d’environnement en détail.
L’environnement par défaut est utilisé pour créer des personnalisations de productivité Microsoft 365. Les politiques de prévention de la perte de données et les restrictions de partage limitent les autres types d’activités des créateurs et placent des garde-fous autour de ce que les créateurs peuvent construire dans cet environnement.
Seuls les administrateurs sont en mesure de créer des environnements d’essai, sandbox et de production. Les créateurs utilisent un formulaire personnalisé ou un autre processus pour demander un nouveau environnement. Microsoft Le Microsoft Power Platform Kit de démarrage du Centre d’excellence (CoE) comprend une demande d’environnement qui pourrait être utilisée.
Quatre groupes d’environnement sont créés : Développement, Développement partagé, UAT (test d’acceptation utilisateur) et Production.
Une politique de routage d’environnement définie pour le groupe Développement éloigne les créateurs de l’environnement par défaut vers leurs propres environnements de développement. Au fur et à mesure que de nouveaux environnements de développement sont créés, ils sont automatiquement associés au groupe Développement et ses règles sont appliquées.
Le groupe Développement partagé prend en charge les environnements contenant des projets avec plusieurs créateurs.
Le groupe UAT contient des environnements utilisés pour tester les ressources avant qu’elles ne soient promues en production.
Le groupe Production contient des environnements qui hébergent des applications, des flux et d’autres artefacts destinés à une utilisation en production.
Ce qui manque dans cette topologie proposée, ce sont des pipelines pour automatiser la promotion entre les environnements de développement, de test et de production. Ajoutons-les maintenant.
Figure : La même topologie environnement avec des pipelines connectant un hôte de pipeline environnement aux environnements de développement, de test et de production.
Dans le diagramme de topologie d’environnement révisé, nous avons ajouté un environnement hôte de pipeline et deux pipelines. Un pipeline déplace les ressources du développement vers les environnements de test, puis vers les environnements de production. La règle de pipeline sur le groupe Développement sera modifiée pour utiliser ce pipeline. L’autre pipeline déplace les ressources de l’environnement développement partagé vers les environnements de test, puis vers les environnements de production. La règle de pipeline sur le groupe Développement partagé sera modifiée pour utiliser ce pipeline.
Cette stratégie d’environnement de base fournit une base sur laquelle vous pouvez vous appuyer pour d’autres cas d’utilisation, que nous explorerons ensuite.
Stratégies environnementales pour des scénarios spécifiques
Voici quelques cas d’utilisation courants que vous devrez peut-être intégrer dans la stratégie d’environnement des locataires de base.
Contrôlez quels créateurs peuvent créer des environnements de développement
Par défaut, toute personne possédant un Power Platform Licence Premium, une licence Plan Développeur ou un Power Platform Le rôle d’administrateur de locataire peut créer un environnement de développeur à partir du portail d’administration.
Dans la stratégie d’environnement de base, le routage d’environnement garantit que les créateurs sont dirigés loin de l’environnement par défaut vers un nouvel environnement de développeur créé dans le groupe désigné. Cependant, les créateurs peuvent toujours créer manuellement des environnement de développeur qui ne sont pas placés dans un groupe d’environnements et dont les règles ne sont pas appliquées.
Pour affiner les créateurs éligibles au routage d’environnement, spécifiez un groupe de sécurité dans la configuration de routage. Lorsqu’un groupe de sécurité est configuré, seuls les membres du groupe de sécurité sont routés. Tous les autres reviennent à l’environnement par défaut.
Offrir plus de flexibilité aux créateurs avancés
Dans la stratégie d’environnement de base, tous les nouveaux environnements de création sont acheminés vers un groupe d’environnements de développeur désigné. Généralement, ce groupe d’environnements applique un ensemble de règles de gouvernance assez restrictives.
À mesure que les créateurs deviennent plus avancés, vous pouvez leur permettre de demander l’accès à davantage de fonctionnalités. Au lieu de les supprimer du groupe d’environnement d’origine et de gérer manuellement l’exception, vous pouvez utiliser un autre groupe d’environnement pour suivre ces créateurs avancés.
Figure : Ajoutez davantage de créateurs compétents à un environnement qui a assoupli les règles de gouvernance.
Organiser les environnements de développement par région ou unité commerciale
Dans l’implémentation actuelle du routage d’environnement, tous les nouveaux environnements de développement sont créés dans un seul groupe d’environnements. Que se passe-t-il si vous souhaitez organiser les environnements de développement de vos créateurs par région, par exemple, ou par unité commerciale ?
Utilisez le routage pour diriger les créateurs vers un nouvel environnement de développement créé dans le groupe désigné. Vous pouvez ensuite le déplacer vers un autre groupe basé sur la région, l’unité organisationnelle ou d’autres critères, où vous pouvez appliquer des règles de gouvernance plus granulaires.
Figure : Une fois que le routage environnement a créé les environnements de développement dans le groupe désigné, déplacez-les vers des groupes structurellement plus spécifiques.
Le déplacement d’environnements est aujourd’hui une action manuelle, mais vous pourrez l’automatiser lorsque le Power Platform Le connecteur d’administration prend en charge la fonctionnalité de groupe dans une future mise à jour.
Développer une application à usage professionnel
Une équipe de votre organisation développe peut-être une application destinée à une utilisation à l’échelle de l’entreprise. L’équipe peut être dirigée par l’informatique ou comprendre à la fois des utilisateurs informatiques et professionnels (ce qu’on appelle une équipe de fusion).
Dans la stratégie d’environnement la plus simple, l’équipe de projet crée un environnement partagé qui est soit un bac à sable, soit un type de production. Un type d’environnement de développement n’est pas le meilleur moyen de prendre en charge la collaboration de plusieurs créateurs sur une ressource. Cependant, les créateurs doivent communiquer entre eux pour éviter les collisions et les conflits dans l’environnement partagé.
Des environnements de test et de production dédiés ne sont pas requis. L’application pourrait être testée et déployée dans des environnements de test et de production à l’échelle de l’organisation qui hébergent plusieurs applications.
Figure : Deux applications d’entreprise en cours de développement dans des environnements dédiés, puis testées et déployées dans des environnements partagés avec d’autres applications.
Dans une variante plus avancée, chaque créateur dispose d’un environnement de développement individuel. Cela présente l’avantage d’offrir un plus grand isolement au créateur, mais peut rendre plus compliquée la combinaison du travail individuel dans un environnement d’intégration. Bien que travailler de manière isolée puisse être utile pour des équipes plus grandes et sophistiquées, cela peut ajouter des frais inutiles aux petites équipes qui peuvent mieux collaborer dans un environnement de développement partagé.
Figure : Deux créateurs travaillant sur la même application dans des environnements de développement individuels doivent combiner leur travail dans une intégration partagée environnement avant de passer aux tests et à la production.
Cette variante intègre généralement une stratégie de contrôle de source, chaque environnement de développement étant représenté comme une branche du contrôle de source qui est fusionnée lorsque les modifications sont prêtes à être promues. Il est important de tenir compte de la manière dont l’application sera maintenue après la version initiale.
Par exemple, la version 1.0 de l’application peut être en production pendant que l’équipe passe à la création de la version 2.0. Votre stratégie d’environnement doit prendre en charge la résolution d’un problème dans la version 1.0, alors que le développement de la version 2.0 est en cours.
Figure : La version 1.0 doit être corrigée, testée et déployée pendant que la version 2.0 est en cours de développement, de test et de déploiement.
Les groupes d’environnement proposent plusieurs approches pour gérer ce scénario d’application d’entreprise. Par exemple, il peut s’agir d’un seul groupe d’applications ou impliquer la création de groupes distincts pour chaque étape de développement. Dans la section des meilleures pratiques, nous explorons comment évaluer les options.
Minimiser l’utiliser les environnements de développeur
Les environnements de développeur individuels sont le moyen recommandé pour fournir aux créateurs un espace de travail pour créer des solutions low-code. Ils offrent le plus haut niveau d’isolement des autres fabricants. Mais si votre organisation souhaite minimiser le nombre d’environnements de développeur, il est préférable d’avoir plusieurs environnements partagés plutôt que d’encourager les créateurs à créer des actifs dans l’environnement par défaut.
Dans ce scénario, vous limiteriez la création d’environnements de développeur et créeriez des environnements de développeur partagés de type production. Vous pouvez organiser ces environnements partagés par structure organisationnelle, région ou d’autres critères. Un groupe environnemental pourrait les contenir pour garantir que des règles de gouvernance cohérentes sont appliquées. Accordez aux créateurs la permission de créer des ressources low-code dans l’environnement qui leur est attribué.
La sécurité dans le cadre de votre stratégie environnementale
Les environnements sont un élément clé d’une utilisation Power Platform sécurisée. Ils représentent des limites de sécurité au sein de votre locataire qui contribuent à protéger les applications et les données. Dans le cadre de votre stratégie d’environnement, vous devez considérer la manière dont vos exigences de sécurité influencent le nombre et l’objectif des environnements de votre locataire.
Les environnements vous permettent de créer plusieurs limites de sécurité au sein de votre locataire pour protéger les applications et les données. La protection fournie par l’environnement peut être ajustée pour répondre à la protection de sécurité nécessaire en appliquant un ensemble configurable de fonctionnalités de sécurité sur l’environnement. Une discussion détaillée des fonctionnalités de sécurité de chaque environnement dépasse le cadre de cet article. Cependant, dans cette section, nous proposons des recommandations sur la manière d’envisager la sécurité dans le cadre de votre stratégie d’environnement locataire.
Sécurité au niveau du locataire
La plupart des paramètres de sécurité qui affectent les environnements sont configurés individuellement pour chaque environnement. Toutefois, vous pouvez apporter certaines modifications au niveau du locataire pour vous aider à prendre en charge votre stratégie environnementale.
- Envisager de désactiver la fonction Partager avec tout le monde dans Power Platform. Seuls les administrateurs pourraient partager un actif avec tout le monde.
- Envisager sécuriser l’intégration avec Exchange.
- Appliquez l’isolation entre locataires pour aider à minimiser le risque d’exfiltration de données entre locataires.
- Limitez la création d’environnements de production nouveaux sur le net aux administrateurs. Limiter la création de environnement est bénéfique pour maintenir le contrôle en général : à la fois pour éviter une consommation de capacité non comptabilisée et pour réduire le nombre d’environnements à gérer. Si les utilisateurs doivent demander des environnements à l’informatique centrale, il est plus facile de voir sur quoi les gens travaillent si les administrateurs sont le gardien.
Sécuriser l’environnement par défaut
L’environnement par défaut joue un rôle dans la prise en charge des Microsoft 365 personnalisations de productivité. Cependant, dans le cadre de la stratégie environnementale recommandée, il est préférable de minimiser son utilisation autant que possible. Au lieu de cela, les créateurs devraient construire dans leurs propres environnements isolés. Bien que vous ne puissiez pas bloquer l’accès à l’environnement par défaut, vous pouvez minimiser ce qui peut y être fait.
Tout d’abord, utilisez le routage de l’environnement pour diriger les créateurs vers leur propre espace de travail afin de créer des actifs low-code.
Vérifiez qui dispose d’un accès administrateur à l’environnement par défaut et limitez-le aux rôles qui en ont besoin.
Pensez à renommer l’environnement par défaut en quelque chose de plus descriptif, comme "Productivité personnelle".
Établissez une politique de prévention contre la perte de données (DLP) pour l’environnement par défaut qui bloque les nouveaux connecteurs et restreint les fabricants à utiliser uniquement des connecteurs de base non bloquables. Déplacez tous les connecteurs qui ne peuvent pas être bloqués vers le groupe de données commerciales. Déplacez tous les connecteurs blocables vers le groupe de données bloquées.
Créez une règle pour bloquer tous les modèles d’URL utilisés par les connecteurs personnalisés.
Sécuriser l’environnement par défaut devrait être une priorité. Faites-le avec la sécurité au niveau du locataire dans le cadre de la première étape de la mise en œuvre de votre stratégie d’environnement. Sans leur mise en œuvre, les créateurs ont davantage de possibilités d’ajouter des actifs en défaut. Une fois ces éléments en place ainsi que le routage de l’environnement, les créateurs sont encouragés à utiliser leur propre environnement.
Sécuriser autres environnements
Si votre organisation est comme la plupart, vous disposez de plusieurs environnements en plus de l’environnement par défaut. Le niveau de sécurité requis par chacun peut varier en fonction des applications et des données qu’il contient. Les environnements de développement ont généralement des règles plus souples que les environnements de production. Certains environnements de production nécessitent la plus grande protection possible.
Dans le cadre de l’établissement de votre stratégie d’environnement, identifiez les niveaux de sécurité communs à vos environnements et les fonctionnalités qui protègent chaque niveau, comme dans l’exemple suivant.
Figure : Un exemple de trois niveaux de sécurité environnement et des fonctionnalités de sécurité qui s’appliquent aux environnements de chaque niveau.
Intégrez les niveaux de sécurité que vous identifiez dans votre stratégie de groupe et, si possible, utilisez des règles pour activer les fonctionnalités de sécurité dans vos environnements. Dans cet exemple, une règle limite le partage dans tous les environnements désignés comme sécurité normale ou moyenne.
Alignez les environnements sur votre stratégie de prévention des pertes de données
Les politiques de données constituent un autre élément important d’un effort de gouvernance global visant à contrôler les services utilisés par les ressources low-code dans un environnement. Les groupes d’environnement n’ont pas de règle pour appliquer une stratégie DLP à un environnement. Cependant, vous pouvez aligner votre stratégie DLP sur vos groupes d’environnement. Par exemple, vous pouvez créer une stratégie DLP portant le même nom ou un nom similaire à celui d’un groupe d’environnements et l’appliquer aux environnements de ce groupe.
Apprenez-en davantage sur la manière d’établir une stratégie DLP.
Figure : Dans cet exemple, les environnements du groupe Personal Dev suivre utilisent une stratégie DLP qui bloque tous les connecteurs non-Microsoft .
Personnaliser une stratégie d’environnement de votre organisation
Dans les sections précédentes, nous avons décrit notre vision de la manière dont les organisations peuvent gérer les environnements à grande échelle. Nous avons exploré les fonctionnalités essentielles, comment elles contribuent à une stratégie d’environnement et à quoi pourrait ressembler une topologie d’environnement de base qui les utilise. Nous avons donné des exemples de la manière de s’appuyer sur cette base pour s’adapter à des scénarios courants. Parce que chaque organisation est unique, l’étape suivante consiste à adapter une stratégie environnementale qui répond aux besoins de votre organisation.
Commencer où vous trouvez-vous
Que votre organisation soit nouvelle Power Platform ou que vous l’utilisez depuis des années, la première étape consiste à évaluer votre situation. Évaluez, à un niveau élevé, le contenu de votre environnement par défaut, les autres environnements dont vous disposez et à quoi ils sont utilisés. Souvent, une stratégie environnementale est élaborée dans le cadre d’un effort global visant à établir une gouvernance de Power Platform dans une organisation. Si tel est le cas, vous avez peut-être déjà établi une partie de la vision de gouvernance nécessaire pour adapter une stratégie à votre organisation.
Les informations sur l’organisation que vous devez connaître comprennent :
Quelle est la vision de la façon dont Power Platform sera-t-il utilisé dans l’organisation ?
Qui dans l’organisation créera des actifs low-code ?
Vous devez prendre quelques décisions clés :
Comment les créateurs obtiendront-ils de nouveaux environnements ?
Allez-vous regrouper vos environnements, et si oui, comment ?
Quels niveaux de sécurité sont requis pour les différents environnements et comment les environnements sont-ils classés ?
Comment déciderez-vous si une application, une automatisation ou un Copilot utilisera un environnement existant ou un nouveau ?
Existe-t-il des écarts entre les fonctionnalités de base de la plateforme et vos exigences qui nécessitent un processus de gouvernance personnalisé ?
Comment allez-vous gérer les actifs existants dans l’environnement par défaut ?
Avez-vous une stratégie de politique DLP en matière de locataires et d’environnement, et si oui, comment s’aligne-t-elle sur la stratégie environnementale que vous créez ?
Vous pourriez également trouver de l’inspiration dans les modèles d’exploitation cloud qui font partie du Cloud Adoption Framework for Azure.
Comblez les lacunes en utilisant la plateforme
Vous rencontrerez presque toujours des exigences auxquelles les capacités intégrées de la plate-forme ne satisfont pas. Lorsque vous évaluez ces lacunes, considérez les résultats possibles suivants de votre évaluation :
L’écart est acceptable.
Cette lacune peut être comblée à l’aide du Power Platform kit de démarrage du Centre d’excellence.
Cette lacune peut être comblée grâce aux fonctionnalités de la plateforme, telles que les API, les connecteurs et les applications personnalisées, ou les automatisations.
Cette lacune peut être comblée à l’aide d’un outil ou d’une application tiers.
Kit de démarrage CoE
Le Power Platform Kit de démarrage du Centre d’excellence est un ensemble de composants et d’outils conçus pour aider votre organisation à adopter et à prendre en charge l’utilisation de Power Platform. Un aspect clé du kit de démarrage est sa capacité à collecter des données sur l’utilisation de la plateforme dans vos environnements, ce qui peut être utile lorsque vous développez et faites évoluer votre stratégie d’environnement.
Par exemple, le tableau de bord Environnements Power BI offre une présentation qui vous aide à comprendre quels environnements existent dans votre locataire, qui les a créés et quels actifs ils contiennent.
Figure : Le tableau de bord Environnements dans Power BI.
Le kit comprend des points de départ ou des sources d’inspiration, comme un processus que les créateurs peuvent utiliser pour demander de nouveaux environnements et des modifications des politiques DLP pour leurs environnements.
Figure : Diagramme de flux illustrant un processus de gestion environnement dans le kit de démarrage CoE.
Programmabilité et extensibilité plateforme
L’un des avantages d’une plate-forme low-code est que vous pouvez l’utiliser pour créer des applications, des automatisations, des portails et des copilotes pour vous aider à la gérer. Vous avez également accès à des outils de niveau inférieur qui peuvent être utilisés pour combler les lacunes de votre stratégie environnementale.
Vous pouvez utiliser les connecteurs suivants pour créer des applications et des flux :
Vous pouvez utiliser l’ Power Platform interface de ligne de commande (CLI) pour développer des automatisations afin de vous aider à gérer le cycle de vie de l’environnement et d’autres tâches liées aux pratiques DevOps.
Avec les applets de commande PowerShell Power Platform pour les créateurs et les administrateurs, vous pouvez automatiser de nombreuses tâches de surveillance et de gestion.
Le Power Platform Kit de développement logiciel (SDK) DLP gérer des vos stratégies de prévention des pertes de données du client et de l’environnement.
Meilleure pratique et recommandations
Dans cette section de l’article, nous nous appuyons sur les recommandations des sections fondamentales et spécifiques aux scénarios.
Nouveaux environnements
Dans le cadre de l’élaboration de votre stratégie, réfléchissez au moment où vous créez des environnements pour prendre en charge une charge de travail. Votre évaluation doit équilibrer les avantages de l’isolement qu’offre un environnement (par exemple, être capable de verrouiller des environnements particuliers plus que d’autres est utile du point de vue de la sécurité) avec les inconvénients, tels que le fait que l’isolement crée des frictions pour les utilisateurs qui tentent de partager des données. à travers les applications.
Lorsque vous évaluez si une application ou une automatisation appartient à son propre environnement, évaluez séparément les différentes étapes du cycle de vie de l’application. Pendant le développement, l’isolement des autres applications est important. Lorsque plusieurs applications sont développées dans un seul environnement, vous risquez de créer des dépendances entre applications.
En règle générale, lorsque cela est possible, les environnements de développement doivent être à usage unique, jetables et faciles à recréer.
Il est logique de tester plusieurs applications dans le même environnement si elles s’exécutent ensemble en production. En fait, si vous ne testez pas avec les applications qui fonctionneront en production, vous risquez de ne pas découvrir de problèmes de compatibilité.
Lorsque vous évaluez l’environnement de production d’une application, gardez les considérations suivantes à l’esprit :
L’application est-elle compatible avec les applications existantes dans l’environnement ? Par exemple, deux applications qui utilisent toutes deux la table Dataverse Contact à des fins différentes peuvent ne pas être compatibles. Les applications sont-elles compatibles du point de vue de la politique DLP ?
Existe-t-il des exigences de conformité ou réglementaires particulières pour la séparation des données ? Par exemple, le Sensibilité des données nécessite-t-il qu’elles soient isolées ? Existe-t-il une exigence selon laquelle les données ne peuvent pas être incluses avec d’autres données ?
Les données sont-elles hautement confidentielles ou sensibles ? L’exfiltration causerait-elle des dommages financiers ou à la réputation de l’organisation ? L’isolement dans un environnement séparé peut permettre un meilleur contrôle de la sécurité.
L’application a-t-elle besoin de données provenant d’autres applications et doit-elle être colocalisée avec elles ? Par exemple, deux applications qui utilisent toutes deux votre table client doivent être hébergées ensemble. Les séparer créerait des copies de données redondantes et créerait des problèmes de maintenance des données.
Les données nécessitent-elles une résidence régionale des données ? Dans certains scénarios, la même application ou automatisation peut être déployée dans des environnements régionaux pour garantir une isolation et une résidence appropriées des données.
La plupart des utilisateurs se trouvent-ils dans la même région que l’environnement ? Si l’environnement se trouve dans la zone EMEA, mais que la plupart des utilisateurs de l’application sont basés aux États-Unis, le partage d’un environnement peut ne pas offrir les meilleures performances.
De nouveaux administrateurs seront-ils nécessaires ou les administrateurs existants suffiront-ils ? Si la nouvelle application nécessite plus d’administrateurs, sont-ils compatibles avec les administrateurs existants, car tous disposeront d’autorisations d’administrateur sur toutes les applications de l’environnement ?
Quelle est la durée de vie de l’application ? Si l’application ou l’automatisation est temporaire ou de courte durée, ce n’est peut-être pas une bonne idée de l’installer dans un environnement avec des applications plus permanentes.
Les utilisateurs auront-ils des difficultés à devoir utiliser plusieurs environnements pour différentes applications ? Cela peut affecter tout, depuis la recherche d’une application sur leur appareil mobile jusqu’aux rapports en libre-service qui doivent extraire des données de plusieurs environnements.
Capacité
Chaque environnement (en plus des environnements d’essai et de développement) consomme 1 Go pour la mise en service initiale. La capacité est partagée entre les locataires et doit donc être allouée à ceux qui en ont besoin.
Conservez la capacité en :
- Gérant les environnements de test et de production partagés. Contrairement aux environnements de développement partagés, les autorisations dans les environnements de test et de production doivent être limitées à l’accès de l’utilisateur pour les tests.
- Automatisez le nettoyage des environnements de développement temporaires et encouragez l’utilisation d’environnements d’essai pour les tests ou le travail de validation de principe.
Groupes d’environnements
Les groupes d’environnement sont flexibles et vous permettent de s’adapter à divers cas d’utilisation propres à vos organisations. Voici quelques façons dont vous pouvez envisager de regrouper les environnements dans le cadre de votre stratégie environnementale :
Par service ou composant ; par exemple, un ServiceNow arbre de services
Développement, test et Production
Départements, groupes professionnels ou centres de coûts
Par projets
Par emplacement, si la plupart des environnements d’un emplacement ont des besoins de gouvernance similaires ; cela peut également aider à respecter une conformité réglementaire et juridique régionale similaire
Figure : les groupes idée de deux départements différents ont des règles différentes.
Nommer les environnements et les groupes
Dans le cadre de votre stratégie, réfléchissez à la façon dont les environnements et les groupes sont nommés.
Les noms d’environnement sont visibles par les administrateurs, les créateurs et les utilisateurs. Seuls les administrateurs utilisent généralement des groupes d’environnements, mais les créateurs peuvent en rencontrer s’ils disposent des privilèges nécessaires pour créer des environnements.
Les environnements de développement créés automatiquement suivent le modèle <nom d’utilisateur>L’environnement ; par exemple, "L’environnement d’Avery Howard". Les groupes d’environnement ne sont pas nommés automatiquement.
Il n’est pas nécessaire que les noms d’environnement et de groupe d’environnement soient uniques. Toutefois, pour éviter toute confusion, il est préférable d’éviter les noms en double.
Les noms êtes limité à 100 caractères. Les noms plus courts sont plus faciles à utiliser.
Établissez une convention de dénomination cohérente.
Des noms cohérents aident les administrateurs à connaître l’objectif du groupe et les environnements qu’il gère, et peuvent faciliter l’automatisation et la création de rapports.
Une pratique courante consiste à inclure l’étape du cycle de vie dans le nom d’un environnement ; par exemple, Contoso Dev, Contoso Test, Contoso Prod. L’objectif est de séparer clairement les environnements ayant le même contenu, mais des objectifs différents.
Une autre pratique courante consiste à inclure le service ou l’unité commerciale dans le nom lorsque l’environnement est dédié à ce groupe d’utilisateurs.
Par exemple, vous pouvez décider que tous les noms d’environnement ou de groupe d’environnements doivent suivre le modèle <Etape du cyle de vie>–<région>–<unité commerciale>–<but> (Prod-US-Finance-Paie).
Gardez les noms courts, significatifs et descriptifs.
Réfléchissez à la façon dont vos groupes évolueront et se développeront au fil du temps, et assurez-vous que votre convention de dénomination peut répondre à ces besoins évolutifs.
Évitez d’inclure des informations confidentielles dans les noms. Ils peuvent être visibles par toute personne ayant accès au centre d’administration.
Les actifs s’ouvre dans l’environnement par défaut
Votre stratégie d’environnement doit encourager (ou imposer) l’utilisation d’environnements de développement personnels afin de réduire ce qui est créé dans l’environnement par défaut. Cependant, vous devez examiner ce que les créateurs ont déjà créé dans l’environnement par défaut et évaluer comment gérer chaque cas d’utilisation. Est-il approprié de le laisser dans l’environnement par défaut ou doit-il être migré vers un autre environnement ?
Un élément clé de cet effort d’hygiène consiste à identifier les applications largement utilisées dans votre organisation et qui doivent disposer de leur propre environnement de développement protégé, distinct de l’environnement de production.
Le tableau suivant répertorie des exemples de cas d’utilisation et d’actions de migration. En fin de compte, votre organisation doit identifier ses propres cas d’utilisation et les facteurs de risque associés au maintien des actifs dans l’environnement par défaut. En savoir plus sur le moment où déplacer des ressources à partir de la valeur par défaut environnement.
| Par défaut environnement | Action migratoire |
|---|---|
| Microsoft 365 productivité personnelle | Rester dans l’environnement par défaut. |
| Éléments avec un seul créateur qui ont été utilisés récemment mais qui ne sont pas partagés | Accédez à l’environnement de développement individuel du propriétaire. |
| Éléments avec un seul créateur qui ont été utilisés récemment et sont partagés | Passez à l’environnement de développement individuel du propriétaire et exécutez à partir d’un environnement de production partagé. |
| Éléments avec plusieurs créateur qui ont été utilisés récemment et sont partagés | Passez à l’environnement de développement partagé et exécutez à partir d’un environnement de production partagé. |
| Actifs qui n’ont pas été utilisés récemment | Avertissez le propriétaire et passez en quarantaine si aucune réponse. |
Actifs dans Dataverse for Teams d’environnement
Microsoft Dataverse for Teams permet aux utilisateurs de créer des applications, des robots et des flux personnalisés en Microsoft Teams utilisant Power Apps, Microsoft Copilot Studio et Power Automate. Lorsqu’un propriétaire d’équipe ajoute cette capacité à son équipe, un environnement Microsoft Power Platform avec une base de données Dataverse for Teams est créée et liée à leur équipe. Découvrez comment établir des politiques de gouvernance pour gérer les environnements. Microsoft Dataverse for Teams
Environnement stratégie en interne chez Microsoft
Microsoft se considère comme un "Client Zéro" car elle adopte en interne des mesures visant à favoriser l’automatisation et l’efficacité parmi ses employés. Power Platform Les chiffres suivants vous donnent une idée de l’échelle d’utilisation sur les locataires internes. Microsoft
50 000-60 000 créateurs actifs chaque mois
Plus de 250 000 candidatures et plus de 300 000 flux
Plus de 20 000 environnement
Microsoft passe de sa stratégie environnement précédente à une stratégie utilisant les dernières fonctionnalités de gouvernance, notamment les groupes environnement, environnement et les règles. Power Platform
Dans le cadre de la stratégie améliorée, Microsoft il est prévu de regrouper les scénarios en fonction du type de développement, de la propriété organisationnelle et du niveau de risque. Étant donné que l’entreprise construit énormément de choses, il est trop difficile de se concentrer sur tous les scénarios possibles et de les personnaliser pour chaque cas d’utilisation. Il se passe trop de choses et cela doit être automatisé et utiliser autant de contrôles prêts à l’emploi que possible.
Microsoft structure ses environnements en trois catégories plus larges qui couvrent sept cas d’utilisation, reflétant différents degrés de risque et de contrôle : productivité personnelle, collaboration en équipe et développement d’entreprise. Power Platform
Productivité personnelle – Ceci est destiné à quelqu’un qui souhaite simplement créer une application ou un flux pour lui-même. Par exemple, ils ne collaborent pas avec les autres. Ces utilisateurs sont dirigés vers des environnements de développement personnel, qui sont verrouillés. Ces environnements utilisent les fonctionnalités de l’environnement géré, notamment la restriction du partage et contrôlent également d’autres choses que vous pouvez faire dans les environnements. Les connecteurs et les actions disponibles sont fortement restreints dans ce groupe d’environnements. Ces environnements sont les moins risqués. L’utilisation d’environnements personnels verrouillés permet aux utilisateurs d’éviter le processus de conformité plus rigoureux simplement pour créer des applications et des flux de productivité personnels.
Collaboration d’équipe – Ceci est destiné aux utilisateurs qui créent des outils, des automatisations et des processus pour leur équipe. Pour ce scénario, Microsoft encourage l’utilisation d’ Dataverse for Teams environnements. Le cycle de vie, la gestion des accès et l’étiquetage des données sont contrôlés au niveau du groupe Microsoft 365 afin que nous n’ayons pas à passer du temps à gérer ces utilisateurs du point de vue de la gouvernance Power Platform. Ce niveau d’utilisation constitue la prochaine étape dans le spectre des risques.
Niveau de développement/production de l’entreprise utilisé par tous les employés – Il s’agit de personnes qui créent des outils ou des solutions utilisés plus largement dans l’entreprise. Ces environnements peuvent stocker les données les plus sensibles, utiliser des connecteurs plus puissants et nécessiter davantage de gouvernance. Ceci est considéré comme le risque le plus élevé et la plupart des efforts sont consacrés à la gouvernance. ALM est requis, le travail de préproduction étant effectué dans des environnements sandbox et seules les solutions gérées sont autorisées dans les environnements de production. Ces environnements doivent être liés à ServiceTree, qui applique des contrôles récurrents de sécurité et de confidentialité. Les règles du groupe d’environnement sont personnalisées en fonction des métadonnées et des signaux ServiceTree. De nombreux groupes d’environnements et règles sont utilisés pour gérer et contrôler ces environnements.
MicrosoftLa stratégie de gouvernance n’est pas statique. Il est fluide et évolue pour s’adapter aux nouveaux défis et intégrer de nouvelles Power Platform fonctionnalités.
Evoluer votre stratégie d’environnement client
Dans cet article, nous avons décrit comment établir une stratégie d’environnement de locataire à l’échelle de l’entreprise. La stratégie peut évoluer avec votre entreprise, quel que soit votre point de départ. Les organisations de toute taille peuvent bénéficier de la stratégie que nous présentons ; cependant, pour les organisations déjà à plus grande échelle, les avantages sont plus importants.
L’élaboration d’une stratégie d’environnement pour les locataires n’est pas une activité ponctuelle. C'est un parcours. Vous devez faire évoluer votre stratégie au fil du temps à mesure que vos besoins évoluent. Votre stratégie doit également s’adapter pour adopter les nouvelles fonctionnalités de la plateforme et relever de nouveaux défis.
Comme pour tout parcours, différentes organisations se rejoignent à différents moments du parcours, mais toutes ont la même destination en tête. Ce qui suit sont des rampes d’accès possibles qui représentent la situation actuelle de votre organisation.
Démarrer
Votre organisation est au début de son parcours pour adopter Power Platform. C'est ce que l'on appelle souvent nouveau. Vous commencez votre voyage au meilleur endroit car vous n’avez pas à vous soucier des environnements existants ni de l’impact que les nouvelles politiques pourraient avoir sur la façon dont les membres de votre organisation utilisent Power Platform. C’est le meilleur moment pour mettre en œuvre une stratégie environnementale à l’échelle de l’entreprise, alignée sur les fonctionnalités et les meilleures pratiques du produit.
Explorez les principales fonctionnalités et stratégies de l’environnement décrites dans cet article. Prenez le temps de comprendre les thèmes clés ainsi que les considérations et décisions dont vous avez besoin pour concevoir et mettre en œuvre une stratégie d’environnement locataire qui correspond le mieux à vos besoins.
Établir dès maintenant une base solide est essentiel pour éviter d’avoir à faire face à une situation incontrôlable qui peut survenir plus tard si vous démarrez sans stratégie définie. Planifiez une accélération rapide de votre utilisation de Power Platform, mais évitez la tentation de sur-concevoir votre stratégie d’environnement en ajoutant une complexité qui n’est pas nécessaire. N’oubliez pas qu’il s’agit d’un voyage et que vous pouvez continuer à faire évoluer votre stratégie à mesure que vos besoins évoluent.
Align
Votre organisation a et exécute une stratégie environnementale qui doit être modifiée pour s’aligner sur les nouvelles Power Platform fonctionnalités et bonnes pratiques. C'est ce que l'on appelle souvent friche. Contrairement aux organisations qui débutent, vous devez considérer l’impact sur votre organisation d’un changement de stratégie environnementale.
Explorez les principales fonctionnalités et stratégies de l’environnement décrites dans cet article et évaluez ce qui est nécessaire pour faire évoluer votre stratégie afin qu’elle soit plus conforme. Habituellement, tout ce qui est nécessaire, ce sont des ajustements progressifs. Lorsque cela est possible, planifiez le déploiement des modifications pour minimiser l’impact sur vos utilisateurs.
Les suggestions suivants sont des modifications incrémentiel courants que vous pourriez implémenter :
Pour démarrer votre alignement sans affecter les environnements existants, créez un groupe d’environnements contenant de nouveaux environnements de développement et établissez des règles sur la manière dont vous souhaitez les régir. Activez le routage des environnements pour garantir que tous les nouveaux environnements de développement sont créés dans le groupe désigné.
Évaluez votre stratégie de regroupement et, si nécessaire, créez des groupes pour prendre en charge vos environnements existants. Établissez des règles pour ces groupes qui s’alignent sur les restrictions et exceptions existantes. Déplacez les environnements existants vers ces groupes.
Identifiez les applications largement populaires créées et utilisées dans l’environnement par défaut. Utilisez des pipelines pour les publier dans un environnement de production où les utilisateurs de votre organisation peuvent les exécuter. Travaillez ensuite à la migration du développement de ces applications vers un environnement de développeur individuel ou un environnement de développement dédié.
Créez un plan pour identifier, mettre en quarantaine et supprimer les actifs de l’environnement par défaut qui ne sont pas utilisés.
Améliorer
La stratégie d’environnement que vous exécutez est déjà conforme aux dernières fonctionnalités et aux meilleures pratiques, mais votre organisation souhaite ajouter davantage de contrôles ou de fonctionnalités.
Communiquez la stratégie environnementale de votre organisation
Vous mettez en œuvre votre stratégie d’environnement locataire avec plus de succès si votre Power Platform les utilisateurs comprennent et sont alignés sur ce que vous essayez d’accomplir. Si vous activez simplement votre stratégie sans aucune communication, les utilisateurs voient les changements comme des restrictions et cherchent des moyens de les contourner.
Dans le cadre du développement ou de l’évolution de votre stratégie, décidez de la manière dont vous informez les utilisateurs des éléments clés de la stratégie qui affectent leur utilisation de Power Platform. Ils n’ont pas besoin de tous les détails techniques de votre stratégie, mais uniquement des éléments essentiels qui les aident à rester productifs, tels que :
Objet de l'environnement par défaut
Où ils devraient créer de nouveaux actifs low-code
Comment ils doivent utiliser leur environnement de développement personnel
Processus de demande d’environnements personnalisés pour des division ou projet spécifiques
Politiques générales d’utilisation des connecteurs et comment demander davantage de privilèges de connecteur pour leurs environnements
Comment partager ce qu’ils construisent avec les autres
Les responsabilités d’un créateur, par ex. :
Gardez le client propre. Supprimer vos environnements, applications et flux s’ils ne sont plus nécessaires. Utilisez des environnements de test si vous expérimentez.
Partagez judicieusement. Faites attention au partage excessif de vos environnements, applications, flux et connexions partagées.
Protégez de données d’organisation. Éviter de déplacer des données de sources de données hautement confidentielles ou confidentielles vers un stockage non protégé ou externe.
Lorsque votre stratégie change, partagez comment les changements affectent vos utilisateurs afin qu’ils sachent quoi faire différemment
Un bon début consiste à activer le contenu de bienvenue des créateurs dans le groupe d’environnement où de nouveaux créateurs sont ajoutés.
Figure : Utilisez le contenu de bienvenue pour aider les nouveaux créateurs à réussir.
Une autre approche efficace pour communiquer avec vos utilisateurs consiste à établir un Power Platform hub interne. Le hub peut être un lieu où les gens peuvent collaborer aux projets, partager des idées et découvrir de nouvelles façons d’appliquer la technologie pour en faire plus. Le hub pourrait être l’endroit où vous partagez des informations plus détaillées sur votre stratégie d’environnement qui sont pertinentes pour vos utilisateurs. Découvrez comment créer un hub interne. Power Platform
Conclusion
Dans cet article, nous avons exploré les fonctionnalités conçues pour aider votre organisation à gérer Power Platform les environnements à l’échelle de l’entreprise et à les intégrer dans votre stratégie d’environnement de locataire.
À mesure que votre organisation adopte Power Platform et que l’utilisation s’accélère, les besoins en environnements peuvent évoluer rapidement. Vous avez besoin d’une approche agile qui aide votre stratégie environnementale à suivre les changements et à continuer de répondre aux exigences changeantes de gouvernance de votre organisation.
Un facteur clé de réussite d’une stratégie d’environnement locataire est de communiquer avec vos créateurs et utilisateurs et d’obtenir leur soutien. Assurez-vous que les personnes qui créent des applications et des automatisations low-code savent comment suivre la stratégie environnementale de votre organisation et où elles doivent créer leurs actifs low-code.
Le parcours d’adoption de chaque organisation Power Platform est unique. Nous avons présenté quelques idées pour vous aider à démarrer du bon pied. Votre Microsoft équipe de compte ou Power Platform partenaire peut vous aider à créer une stratégie de locataire environnement plus personnalisée pour votre organisation.