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 client jette les bases pour accélérer l’utilisation de manière gérable et sécurisée.

Cet article vous montre comment aligner votre stratégie d’environnement client Power Platform 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.

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 environnements Power Platform 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 de 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 nombreuses perspectives soient disponibles pour la gestion des environnements Power Platform, l’approche présentée dans cet article s’aligne sur la dernière orientation produit de Microsoft et utilise les fonctionnalités actuelles et les améliorations prévues à court terme. Ces conseils mis à jour peuvent vous aider à garantir que vous utilisez uniquement les fonctionnalités et options d’environnement qui sont stratégiques pour la façon dont Microsoft prévoit que vous gérez les environnements à grande échelle.

Vision stratégique de l’environnement des locataires de Microsoft

De nombreuses organisations commencent leur parcours Power Platform 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 fournit aux organisations une rampe d’accès à une stratégie d’environnement pour l’adoption à l’échelle de l’entreprise de toutes fonctionnalités Power Platform. 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 modèle de maturité pour l’adoption de Power Platform fournit plus 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.

Les fonctionnalités d’administration, de gouvernance et de sécurité Power Platform 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éveloppeur 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 dossier OneDrive pour tous leurs documents. Utilisez plutôt les fonctionnalités d’environnement pour guider les créateurs vers leur propre environnement personnel où ils peuvent créer leurs applications en toute sécurité, à l’abri des créateurs travaillant sur des ressources sans lien entre elles, 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.

Illustration : Illustration d’un environnement central partagé (à gauche) et d’une stratégie de routage d’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éveloppeur pour la promouvoir dans un environnement de production. Les utilisateurs peuvent ensuite exécuter la ressource, isolés de toute activité de créateur en cours.

Donnez 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, utilisez 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. Surveiller la feuille de route de la plateforme Microsoft et l’aligner sur votre propre feuille de route facilite ce processus.

Établissez votre stratégie d’environnement à l’aide des fonctionnalités d’environnement recommandées et 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 de l’administration, de la gouvernance et de la sécurité Power Platform. Un aperçu complet des fonctionnalités n’entre pas dans le cadre de cet article. Toutefois, cette section met en évidence les fonctionnalités qui prennent en charge la mise en œuvre d’une stratégie d’environnement à l’échelle de l’entreprise.

• Types d’environnements décrit les différentes utilisations des environnements dans le cadre de votre stratégie.
• Les environnements gérés fournissent un ensemble de fonctionnalités premium qui facilitent la gestion des environnements à grande échelle.
• Revendication automatique de licence simplifie l’attribution des licences en permettant aux utilisateurs de réclamer des licences Power Apps par utilisateur quand ils en ont besoin au lieu de demander à l’administrateur d’identifier à l’avance les utilisateurs qui auront besoin de licences.
• Groupes et règles d’environnement 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 de l’environnement par défaut éloigne automatiquement les créateurs de la création de ressources dans l’environnement par défaut vers leur propre environnement personnel.
• Microsoft Dataverse fournit une sécurité accrue et ALM.
• Les solutions préférées aident les créateurs à s’assurer que tous les actifs qu’ils créent se trouvent dans une solution Dataverse, ce qui facilite leur promotion dans d’autres environnements.
• Pipelines dans Power Platform fournit un processus simplifié pour promouvoir les actifs depuis les environnements de développeur jusqu’aux environnements de test et de production, rendant l’intégration et le déploiement continus (CI/CD) accessibles à tous les fabricants.
• Catalogue dans Power Platform permet aux créateurs de partager des composants, tels que des applications et des flux, ainsi que 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 expériences Microsoft 365 utilisent cet environnement pour les personnalisations et les automatisations. Cet environnement n’est pas destiné à un travail à long terme ou permanent au-delà des scénarios de productivité personnelle Microsoft 365.
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éveloppeur 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 Microsoft pour permettre aux ingénieurs de résoudre les problèmes. Ces environnements ne comptent pas dans votre capacité de locataire.

Lors de la création d’une stratégie globale d’environnement de client, tenez compte des différents types pour étayer vos recommandations.

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 license Vue stratégie données Exporter données vers Azure Application Insights Descriptions générées par l’IA pour toutes les applications	Limites de partage Stratégies de données pour les flux de bureau Vérificateur de solution Contenu d’accueil du créateur Pare-feu IP Liaison des cookies IP Clés gérées par le client Customer Lockbox Sauvegardes étendues	Activation facile Pipelines Power Platform Acheminement d’environnement Groupes d’environnements et règles Page Actions

Demande automatique de licences

Les stratégies de revendication automatique automatisent l’attribution de licences Power Apps et Power Automate 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’une licence individuelle Power Apps en reçoit automatiquement une, dans les conditions suivantes :

• Si un utilisateur sans licence Power Apps autonome lance une application nécessitant une licence Premium, le système attribue 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 attribue 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’une licence individuelle Power Automate en reçoit automatiquement une dans les conditions suivantes :

• L’utilisateur déclenche, enregistre ou active un flux de cloud premium avec RPA (automatisation robotisée des processus) attended.

• L’utilisateur demande une licence Power Automate Premium.

Nous vous recommandons de configurer la revendication automatique de licence si votre stratégie d’environnement inclut 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

À mesure que l’adoption de Power Platform dans votre locataire augmente, le nombre d’environnements nécessitant une administration et une gouvernance peut augmenter également. À 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 d’environnement peut les modifier. Cette approche est importante pour une stratégie d’environnement, car elle garantit qu’un administrateur d’environnement ne peut pas remplacer les stratégies 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.

Illustration : Conceptualisation d’une stratégie d’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.

Illustration : Exemple d’implémentation des groupes d’environnement conceptuel dans le client 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 environnement de développeur personnel et crée de nouveaux environnements de développeur, si nécessaire.

Illustration : Schéma d’un créateur automatiquement redirigé vers un environnement de développeur personnel au lieu de l’environnement par défaut lors de la création d’applications.

Les environnements de développeur 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éveloppeur, 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éveloppeur. 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 services Power Platform prendront en charge la fonctionnalité de routage d’environnement.

Contenu d’accueil du créateur

Fournissez du contenu de bienvenue personnalisé pour aider les créateurs à prendre en main Power Apps et Copilot Studio. Lorsque vous ajoutez votre propre contenu d’aide, il remplace l’expérience d’aide par défaut de première utilisation de Power Apps pour les créateurs. Le message d’accueil personnalisé peut informer les décideurs sur les règles de l’entreprise et ce qu’ils peuvent faire dans chaque environnement ou groupe d’environnements.

Voici quelques suggestions pour savoir comment votre organisation peut utiliser le message de bienvenue dans chaque type d’environnement. Incluez une image qui identifie le type d’environnement ou les propriétaires pour faciliter l’adoption de l’utilisateur et la prévention des erreurs.

Environnement par défaut

L’environnement par défaut est souvent le plus restreint, avec des stratégies de données et des contrôles de partage. Créez un message de bienvenue qui avertit vos décideurs des restrictions et des limitations possibles, et incluez un lien vers le site web ou le document de stratégie de votre organisation.

Par exemple, vous souhaiterez peut-être informer les créateurs d’utiliser l’environnement par défaut uniquement pour les solutions liées aux applications Microsoft 365, éviter d’utiliser des applications de production dans l’environnement par défaut et de partager leurs applications canevas uniquement avec un nombre limité de personnes. L’exemple suivant montre comment créer un tel message dans les paramètres des environnements managés :

Exemple d’entrée Markdown :

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to Contoso Personal Productivity Environment

### Before you start, here are some considerations

Use this environment if you plan to build apps that integrate with Office 365.

Before you start, be aware of these limitations:

1. You can't share your apps with more than five users.
1. The data in Dataverse is shared with everyone in the organization.
1. You can only use Office 365 connectors.

If you're not sure you're in the right place, follow **[this guidance](#)**.

Voici le message d’accueil rendu :

Environnements de production

Les environnements de production sont généralement utilisés pour déployer des solutions qui prennent en charge la productivité de l’entreprise et de l’équipe. Il est important que les applications et les données soient conformes aux stratégies organisationnelles. Étant donné que vous devez contrôler quels utilisateurs ont accès à l’environnement de production, il est judicieux d’informer les utilisateurs si vous avez une stratégie d’actualisation de l’accès. Vous pouvez autoriser davantage de connecteurs et augmenter les limites de partage dans un environnement de production. Vous pouvez également utiliser le message de bienvenue pour informer les décideurs de l’équipe appropriée pour contacter le support technique. L’exemple suivant montre comment créer un tel message :

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to HR Europe Environment

### Before you start, here are some considerations

Use this environment if you're on the HR team and your data is located in Europe.

Before you start, be aware of these limitations:

1. You can only share apps with security groups. [Follow this process](#) to share your apps.
1. The data in Dataverse is stored in Europe.
1. You can only use social media connectors with read actions.
1. If you need more connectors, [submit a request](#).

If you're not sure you're in the right place, follow **[this guidance](#)**.

Voici un exemple de sortie :

Environnements de développement

Les environnements de développement sont le plus souvent là où les développeurs créent leurs solutions. Étant donné que les développeurs travaillent sur les applications, ils ne sont pas en production et la scalabilité est limitée. Normalement, les environnements de développement ont des stratégies de données plus souples en raison de la nature des créateurs. Pour éviter que les développeurs utilisent des ressources de production dans leurs environnements de développement, limitez les fonctionnalités de partage et utilisez une stratégie de données spécifique pour ce type d’environnement. Voici un exemple de message d’accueil pour un environnement de développement :

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to a Developer Environment

### Before you start, here are some considerations

Use this environment if you're a developer and you're building solutions.

Before you start, be aware of these limitations:

1. You can only share resources with up to two members of your team. If you need to share with more people, [submit a change request](#).
1. Use resources only while you're developing a solution.
1. Be mindful of the connectors and data you're using.
1. If you need more connectors, [submit a request](#).

If you're not sure you're in the right place, follow **[this guidance](#)**.

Voici un exemple de sortie pour un environnement de développement :

Environnements de bac à sable

En règle générale, les environnements de bac à sable sont utilisés pour tester des solutions. Étant donné que certains tests impliquent un nombre important d'utilisateurs, ces environnements peuvent évoluer jusqu'à atteindre une certaine limite et ont une capacité disponible supérieure à celle d'un environnement de développement. Les environnements de bac à sable sont également couramment utilisés comme environnements de développement et sont généralement partagés par plusieurs développeurs. Voici un exemple de message d’accueil pour un tel environnement :

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to a Test Environment

### Before you start, here are some considerations

Use this environment only if you're testing solutions.

Before you start, be aware of these limitations:

1. You can only share resources with your team. If you need to share with more people, [submit a change request](#).
1. You're not allowed to edit or import solutions directly in this environment.
1. Be mindful of the test data and compliance.
1. If you need help from a security export or IT support, [submit a request](#).

If you're not sure you're in the right place, follow **[this guidance](#)**.

Voici un exemple de sortie pour un environnement de bac à sable ou de test :

Limiter le partage

Les administrateurs peuvent limiter la façon dont les utilisateurs peuvent partager des applications de canevas, des flux et des agents. Toutefois, la limite s’applique uniquement au partage futur. Si vous appliquez une limite de partage de 20 à un environnement avec des ressources déjà partagées avec plus de 20 utilisateurs, ces ressources continuent de fonctionner pour tous les utilisateurs avec utilisant ces ressources. Créez un processus permettant d’informer les créateurs d’applications, de flux et d’agents qui sont partagés avec plus d’utilisateurs que la nouvelle limite, afin qu’ils puissent réduire le nombre d’utilisateurs avec lesquels leurs ressources sont partagées. Dans certains cas, vous pouvez décider de déplacer la solution vers un autre environnement. Les limites de partage s’appliquent aux applications de canevas, aux flux et aux agents.

Les administrateurs doivent généralement contrôler la façon dont les créateurs partagent leurs applications, flux et agents quand :

• Les ressources sont partagées dans un environnement de productivité personnel. Si vous disposez d’un environnement dans lequel les utilisateurs peuvent créer des ressources pour leur propre travail, les ressources sans valeur métier globale ou les ressources sans prise en charge du service informatique, il est important que vous ne puissiez pas les partager au sein de l’organisation. Si les ressources commencent en tant que productivité personnelle, mais plus tard deviennent populaires et sont largement utilisées, gardez à l’esprit la limite que vous définissez sur le partage. Une limite courante est comprise entre 5 et 50 utilisateurs.

• Les ressources sont partagées avec des groupes de sécurité ou tout le monde. Les ressources partagées avec un groupe de sécurité peuvent être exécutées par tous les membres du groupe. Dans un environnement de développement, vous souhaiterez peut-être que le développeur contrôle la façon dont les ressources sont partagées au lieu de s’appuyer sur l’appartenance au groupe. Dans d’autres scénarios, vous pouvez autoriser le partage avec tout le monde. Si la stratégie de votre organisation est que les ressources sont partagées avec un groupe de sécurité qui inclut tous les utilisateurs autorisés à exécuter la ressource et qui sont gérés par le service informatique, vous souhaiterez peut-être empêcher les créateurs de partager avec d’autres groupes de sécurité.

Voici les limites de partage courantes pour chaque type d’environnement :

• Par défaut : sélectionnez Exclure le partage avec des groupes de sécurité, sélectionnez Limiter le nombre total de personnes pouvant partager, puis sélectionnez 20 pour la valeur.

• Développeur : sélectionnez Exclure le partage avec des groupes de sécurité, sélectionnez Limiter le nombre total de personnes pouvant partager, puis sélectionnez 5 pour la valeur.

• Bac à sable : sélectionnez Exclure le partage avec des groupes de sécurité et laissez limiter le nombre total de personnes pouvant partager à des personnes non sélectionnées. Utilisez cette option si les applications sont partagées avec un groupe de sécurité géré par le service informatique qui inclut les utilisateurs autorisés à exécuter l’application. Si le créateur, l’utilisateur ou l’équipe peut gérer les utilisateurs autorisés à tester une solution, sélectionnez Ne pas définir de limites (par défaut).

• Production : sélectionnez Ne pas définir de limites (par défaut). Pour contrôler le partage en fonction d’un groupe de sécurité spécifique, sélectionnez Exclure le partage avec des groupes de sécurité et laissez limiter le nombre total de personnes pouvant partager à des personnes non sélectionnées.

Microsoft Dataverse

Dataverse stocke et gère en toute sécurité les données utilisées par les applications. Dans le cadre d’une stratégie d’environnement, la fonctionnalité de la solution Dataverse vous permet de transporter des actifs 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éveloppeur, 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.

Les solutions Dataverse sont le mécanisme de mise en œuvre d’ALM dans des produits Power Platform comme Power Apps et Power Automate. Pipelines dans Power Platform utilisent 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éveloppeur. Par exemple, si un créateur crée une application populaire puis supprime l’environnement de développeur, une solution exportée stockée dans le contrôle de source pourrait être utilisée pour recréer un environnement de développeur 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. Cette stratégie permet de préparer plus facilement les actifs pour l’ALM.

Solution par défaut

Lorsqu’un créateur crée un actif Dataverse dans un environnement Dataverse et ne part pas d’une solution personnalisée, l’actif est associé à la solution par défaut et peut également être associé à la solution par défaut Common Data Service. La solution par défaut est partagée par tous les créateurs qui créent des actifs dans l’environnement. Il est difficile d’identifier quel créateur a créé des composants spécifiques ou quels actifs appartiennent à des applications spécifiques, ce qui rend plus difficile la promotion d’une application populaire dans un autre environnement pour partager avec un public plus large. Pour ce faire, vous devez promouvoir tous les actifs de la solution par défaut, ce qui n’est pas 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éveloppeur, puis la définir comme 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’une solution Dataverse avant de pouvoir être utilisés.

Les solutions Dataverse 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.

Illustration : un pipeline automatiser la promotion d’un actif stocké dans le contrôle de code source, du développement à la production en passant par les tests.

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éveloppeur 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 dans Power Platform stockent les définitions de chaque pipeline dans un environnement hôte que Microsoft gère par défaut. 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.

Mise en application du vérificateur de solution

Il est courant pour une équipe de centre d’excellence (CoE) de configurer des garde-fous afin de réduire le risque que les utilisateurs importent des solutions non conformes dans un environnement. Les administrateurs peuvent facilement appliquer des vérifications complètes d’analyse statique des solutions à un ensemble de règles de bonnes pratiques pour identifier les modèles problématiques. Les organisations disposant de centres d'excellence décentralisés trouvent souvent nécessaire d’activer le vérificateur de solutions, ainsi que de contacter de manière proactive les décideurs par e-mail pour offrir de l'assistance.

L’application du vérificateur de solutions offre trois niveaux de contrôle : Aucun, Avertir et Bloquer. Les administrateurs configurent l’effet de la vérification, qu’il fournisse un avertissement mais autorise l’importation, ou bloque complètement l’importation, tout en fournissant le résultat de l’importation au créateur.

Les organisations qui utilisent cette fonctionnalité le configurent différemment en fonction du type d’environnement. Il est normal d’avoir des exceptions, et ces conseils doivent toujours être alignés sur vos besoins. Toutefois, voici les paramètres les plus courants pour l’application du vérificateur de solution dans chaque type d’environnement :

• Valeur par défaut : sélectionnez Bloquer et envoyer des e-mails.
• Développeur : sélectionnez Avertir et laissez Envoyer des e-mails non sélectionné.
• Bac à sable : sélectionnez Avertir et laissez Envoyer des e-mails non sélectionné.
• Production : sélectionnez Bloquer et envoyer des e-mails.
• Environnement Teams : sélectionnez Bloquer et envoyer des e-mails.

Catalogue dans Power Platform

Les organisations où les développeurs et les créateurs créent et partagent des composants tels que des applications, des flux et des modèles, qui servent de points de départ avancés, ont tendance à tirer plus de valeur de Power Platform. Le catalogue Power Platform permet aux créateurs de partager facilement leurs composants et modèles entre les environnements.

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 de segmentation des ressources en ayant plusieurs environnements avec un catalogue installé.

Les organisations qui encouragent les développeurs et les créateurs à créer et partager des composants et des modèles dans le catalogue dérivent davantage de valeur de leur investissement dans Power Platform. Construire simplement ne suffit pas. Le partage des artefacts, à grande échelle, favorise les communautés et soutient les groupes qui peuvent valoriser un personnel diversifié dans l’organisation. En fait, les organisations qui réussissent le mieux avec Power Platform adoptent un modèle d’équipe de fusion, où les développeurs, les créateurs et les administrateurs professionnels travaillent ensemble pour aider leurs collègues à tirer la valeur la plus élevée possible de la plateforme en réutilisant des solutions, des modèles et des composants.

Feuille de route des fonctionnalités

Alors que Microsoft continue de faire évoluer les fonctionnalités de Power Platform qui prennent en charge la gouvernance et l’administration, vous pouvez suivre le processus dans le planificateur de versions. Vous apprenez ce qui est prévu, le contenu de la prochaine vague de lancement 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 d’adapter une stratégie pour répondre à vos besoins.

Dans cet exemple, la direction de Contoso souhaite donner aux employés les moyens de tirer parti de Power Platform et a identifié les exigences de haut niveau suivantes :

• Les employés doivent être capables de créer des processus automatisés d’approbation de documents et d’autres personnalisations Power Platform avec Microsoft 365.
• Les employés doivent être capables de créer des automatisations Power Apps et Power Automate 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 répondre à ces exigences, l’équipe d’administration et de gouvernance de Contoso a développé la topologie d’environnement suivante :

Illustration : Topologie d’environnement proposée pour le projet Power Platform à grande échelle de Contoso..

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 stratégies et restrictions de données sur le partage limitent d’autres types d’activités de créateur et placent des garde-fous autour de ce que les créateurs peuvent créer dans cet environnement.

Seuls les administrateurs sont en mesure de créer des environnements de test, sandbox et de production. Les créateurs utilisent un formulaire Microsoft personnalisé ou un autre processus pour demander un nouvel environnement. Le Le Kit de démarrage du Centre d’excellence (CoE) Microsoft Power Platform 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éveloppeur. Au fur et à mesure que de nouveaux environnements de développeur 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.

Cette topologie proposée manque de pipelines pour automatiser la promotion entre les environnements de développeur, de test et de production. Ajoutons-les maintenant.

Figure : La même topologie d’environnement avec des pipelines connectant un environnement hôte de pipeline aux environnements de développeur, 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éveloppeur

Par défaut, toute personne possédant une licence Premium, une licence Plan Développeur ou un rôle d’administrateur de locataire Power Platform 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.

Illustration : Ajoutez des décideurs plus compétents à un environnement où les règles de gouvernance sont assouplies.

Organiser les environnements de développeur par région ou unité commerciale

Dans l’implémentation actuelle du routage d’environnement, tous les nouveaux environnements de développeur sont créés dans un seul groupe d’environnements. Que se passe-t-il si vous souhaitez organiser les environnements de développeur 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éveloppeur 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.

Illustration : le routage des environnements créant des environnements de développeur dans le groupe désigné les déplacés vers des groupes plus structurellement spécifiques.

Le déplacement d’environnements est aujourd’hui une action manuelle, mais vous pourrez l’automatiser lorsque le connecteur d’administration Power Platform 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éveloppeur n’est pas le meilleur moyen de prendre en charge la collaboration de plusieurs créateurs sur une ressource. 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.

Illustration : Schéma illustrant 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éveloppeur individuel. Cette stratégie a l’avantage d’offrir une plus grande isolation 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éveloppeur partagé.

Illustration : Deux créateurs travaillant sur la même application dans des environnements de développeur individuels doivent combiner leur travail dans un environnement d’intégration partagé 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éveloppeur é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.

Illustration : La version 1.0 doit être corrigée, testée et déployée tandis 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. Si votre organisation souhaite réduire le nombre d’environnements de développeur, il est préférable d’utiliser 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 sécurisée de Power Platform. 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 fonctionnalité 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 une isolation du client pour minimiser le risque d’exfiltration de données entre clients.
• Limitez la création d’environnements de production nouveaux sur le net aux administrateurs. Limiter la création d’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 personnalisations de productivité Microsoft 365. 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 stratégie de données pour l’environnement par défaut qui bloque les nouveaux connecteurs et restreint les fabricants à utiliser uniquement des connecteurs de base et déblocables. 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éer 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 est une priorité. Implémentez-la avec une sécurité au niveau du client dans le cadre de la première étape de votre stratégie d’environnement. Sans ces mesures, les créateurs peuvent ajouter plus d’actifs à l’environnement par défaut. Une fois ces mesures et le routage d’environnement en place, les créateurs sont encouragés à utiliser leur propre environnement.

En savoir plus : Sécuriser l’environnement par défaut

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éveloppeur 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.

Illustration : Un exemple de trois niveaux de sécurité d’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.

Aligner les environnements sur votre stratégie de stratégie 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 de données à un environnement. Toutefois, vous pouvez aligner votre stratégie de stratégie de données avec vos groupes d’environnement. Par exemple, vous pouvez créer une stratégie de données portant le même nom ou un nom similaire qu’un groupe d’environnement et l’appliquer à des environnements de ce groupe.

En savoir plus sur l’implémentation d’une stratégie de stratégie de données.

Figure : Dans cet exemple, les environnements du groupe Développement personnel suivent une stratégie de protection contre la perte de données (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 débute avec Power Platform ou que vous l’utilisiez 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 :

• Comment envisagez-vous d'utiliser Power Platform 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 de données pour le locataire et l'environnement, et si oui, comment cette stratégie s'aligne-t-elle sur la stratégie environnementale que vous êtes en train de créer ?

Vous trouverez peut-être l’inspiration dans les modèles d’exploitation du cloud qui font partie du Cloud Adoption Framework pour 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 kit de démarrage du Centre d’excellence Power Platform.
• 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 Kit de démarrage du Centre d’excellence Power Platform 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.

Illustration : Le tableau de bord Environnements dans Power BI.

Le kit comprend des points de départ ou une inspiration, tels qu’un processus que les créateurs peuvent utiliser pour demander de nouveaux environnements et des modifications apportées aux stratégies de données pour leurs environnements.

Illustration : Diagramme de flux illustrant un processus de gestion de l’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 :

• Power Platform for Admins et Power Platform for Admins V2
• Power Apps for Admins et Power Apps pour les créateurs
• Gestion de Power Automate

Vous pouvez utiliser l'interface de ligne de commande (CLI) Power Platform 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 pour les créateurs et les administrateurs Power Platform, vous pouvez automatiser de nombreuses tâches de surveillance et de gestion.

Le Kit de développement logiciel (SDK) DLP Power Platform permet de gérer 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 de créer des environnements pour prendre en charge une charge de travail. Votre évaluation doit trouver un équilibre entre les avantages de l’isolation qu’offre un environnement, tels que le verrouillage d’environnements particuliers pour une meilleure sécurité, et les inconvénients, tels que les frictions auxquelles les utilisateurs sont confrontés lors du partage de données entre 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éveloppeur 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 Contact de Dataverse à des fins différentes peuvent ne pas être compatibles. Les applications sont-elles compatibles du point de vue de la stratégie de données ?

• 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 (puisque tous auront des 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 de test 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éveloppeur 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éveloppeur temporaires et encouragez l’utilisation d’environnements de test 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 arbre de services ServiceNow
• 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

Illustration : Groupes d’environnements pour deux services différents avec des règles différentes.

Nommer des environnements et des 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éveloppeur créés automatiquement suivent le modèle Environnement <du nom d'utilisateur> ; 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.

Conventions de dénomination

Établissez des conventions d’affectation de noms cohérentes.

• Les noms cohérents aident les administrateurs à savoir quel est l’objectif du groupe et quels environnements il gère. Des noms cohérents facilitent également 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 <phase du cycle de vie>-<région>-<division>-<but> (Prod-US-Finance-Paie).

• Gardez les noms courts, significatifs et descriptifs.

• Évitez d’inclure des informations confidentielles dans les noms. Ils peuvent être visibles par toute personne ayant accès au centre d’administration.

• 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.

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éveloppeur 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 qui nécessitent un environnement de développeur 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 opportun pour déplacer des actifs de l’environnement par défaut.

Environnement par défaut	Action migratoire
Productivité personnelle Microsoft 365	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éveloppeur 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éveloppeur 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éveloppeur 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.

Ressources dans les environnements Dataverse for Teams

Microsoft Dataverse for Teams permet aux utilisateurs de créer des applications, des bots et des flux personnalisés dans Microsoft Teams avec 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. En savoir plus sur la manière d’établir des stratégies de gouvernance pour gérer les environnements Microsoft Dataverse for Teams.

Stratégie environnementale interne Microsoft

Microsoft se considère comme le « client zéro » parce qu’il adopte Power Platform en interne pour favoriser l’automatisation et l’efficacité de ses employés. Les chiffres suivants montrent l’ampleur de l’utilisation dans le client interne de 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 d’environnement précédente à une stratégie utilisant les dernières fonctionnalités de gouvernance Power Platform, notamment les environnements gérés, les groupes d’environnement et les règles.

Dans le cadre de la stratégie améliorée, Microsoft prévoit 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 tant de choses sont créées dans la société, il est difficile de se concentrer sur tous les scénarios possibles et de les personnaliser pour chaque cas d’utilisation. Compte tenu de l’ampleur de l’innovation et du changement, l’automatisation est nécessaire, ainsi que le plus grand nombre possible de contrôles prêts à l’emploi.

Microsoft structure ses environnements Power Platform en trois grandes catégories qui couvrent sept cas d’utilisation, reflétant différents degrés de risque et de contrôle : la productivité personnelle, la collaboration d’équipe et le développement de l’entreprise.

• Productivité personnelle : pour les utilisateurs qui souhaitent simplement créer une application ou un flux pour eux-mêmes, sans collaborer avec d’autres utilisateurs. Ces utilisateurs sont dirigés vers des environnements de développeur personnel. Ces environnements verrouillés utilisent les fonctionnalités Environnement géré, notamment la restriction du partage et le contrôle d’autres actions. Les connecteurs et les actions dans ces environnements sont fortement restreints. 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 requis pour créer des applications et des flux de productivité personnelle.

• Collaboration d’équipe : pour les utilisateurs qui créent des outils, une automatisation et des processus pour leur équipe. Pour ce scénario, Microsoft recommande d’utiliser des environnements Dataverse for Teams. 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, ce qui élimine le besoin de consacrer du temps à la gestion de 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 : pour les utilisateurs qui créent des outils ou des solutions utilisés plus largement dans la société. Ces environnements peuvent stocker les données les plus sensibles, utiliser des connecteurs plus puissants et nécessiter davantage de gouvernance. C’est à ce niveau que le risque est le plus élevé et, par conséquent, des efforts considérables sont consacrés à la gouvernance. L’ALM est requis, le travail de préproduction se déroulant dans des environnements de bac à sable 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.

La stratégie de gouvernance de Microsoft n’est pas statique. Il est fluide et évolue pour s’adapter aux nouveaux défis et intégrer de nouvelles fonctionnalités Power Platform.

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 évolue avec votre entreprise, quel que soit le point de départ de votre parcours. 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. Faites évoluer votre stratégie au fil du temps en fonction de l’évolution de vos besoins. 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. Cette phase est ce qu’on appelle souvent un nouveau site. 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 les décisions que vous devez prendre pour concevoir et mettre en œuvre une stratégie d’environnement client qui répond 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 fonctionnalités Power Platform et les bonnes pratiques. Cette phase est ce qu’on appelle souvent un site désaffecté. 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éveloppeur 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éveloppeur 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éveloppeur 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 vos utilisateurs Power Platform 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 seulement de l’essentiel qui les aide à rester productifs. Par exemple, communiquez :

• 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éveloppeur 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.

Illustration : 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 hub Power Platform 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 est l’endroit où vous pouvez également partager des informations détaillées sur votre stratégie d’environnement qui sont pertinentes pour vos utilisateurs. En savoir plus sur la manière de créer un hub Power Platform interne.

Conclusion

Dans cet article, nous avons exploré les fonctionnalités conçues pour aider votre organisation à gérer les environnements Power Platform à 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 vous avons présenté quelques idées pour vous aider à démarrer. Votre équipe de compte Microsoft ou partenaire Power Platform peut vous aider à créer une stratégie d’environnement de locataire plus personnalisée pour votre organisation.

Informations associées

• Groupes d’environnements
• Acheminement d’environnement
• Sécurité d’entreprise avec Power Platform (livre blanc)
• Sécurité et gouvernance low-code
• Concepts de solution dans ALM