Gérer Power Apps

Si vous êtes administrateur d’environnement, administrateur global ou administrateur Microsoft Power Platform, vous pouvez gérer les applications créées dans votre organisation.

Les administrateurs peuvent effectuer les tâches suivantes depuis le centre d’administration Power Platform :

• Ajout ou modification des utilisateurs avec lesquels une application est partagée
• Suppression des applications qui ne sont actuellement pas en cours de utilisation

Conditions préalables

• Un plan Power Apps ou un plan Power Automate. Sinon, vous pouvez vous inscrire à une version d’évaluation Power Apps.
• Administrateur d’environnement Power Apps, administrateur général ou autorisations d’administrateur Power Platform. Pour plus d’informations, voir Administration d’environnement dans Power Apps.

Gérer Power Apps

1. Connectez-vous au centre d’administration Power Platform.

2. Dans le volet de navigation, sélectionnez Environnements, puis un environnement avec des ressources, et enfin cliquez sur la ressource Power Apps.

   

3. Sélectionnez une application à gérer.

   

4. Sélectionnez l’action souhaitée.

   

Gérer qui peut partager des applications canevas

Power Apps respecte le privilège "Partager" de l’application canevas dans Dataverse. Un utilisateur ne pourra pas partager des applications canevas dans un environnement s’il n’a pas de rôle de sécurité avec le privilège de partage d’applications canevas défini sur une valeur autre que "Aucune sélectionnée". Ce privilège de partage de l’application canevas Dataverse est également respecté dans l’environnement par défaut. Cet article explique comment modifier les privilèges dans un rôle de sécurité : Modifier un rôle de sécurité.

Note

La possibilité de contrôler de manière granulaire le privilège de partage d’application canevas dans un rôle de sécurité nécessite Dataverse dans l’environnement où le privilège doit être modifié. Power Apps ne reconnaît pas discrètement les autres privilèges d’entité d’application canevas Dataverse définis pour l’environnement.

Les mises à jour du système peuvent supprimer les personnalisations des rôles de sécurité prédéfinis, y compris le créateur d’environnement. Cela signifie que la suppression du privilège de partage d’application canevas peut être réintroduite lors d’une mise à jour du système. Jusqu’à ce que la personnalisation du privilège de partage de l’application canevas soit préservée lors des mises à jour du système, la personnalisation du privilège de partage peut devoir être réappliquée.

Afficher le contenu d’erreur de gouvernance de votre organisation

Si vous spécifiez que le contenu du message d’erreur de gouvernance doit apparaître dans les messages d’erreur, il sera inclus dans le message d’erreur affiché lorsque les utilisateurs constatent qu’ils ne sont pas autorisés à partager des applications dans un environnement. Voir : Commandes de contenu des messages d’erreur de gouvernance PowerShell.

Distinguer les créateurs de formulaires personnalisés Microsoft SharePoint des fabricants d’environnement généraux

En plus de la possibilité d’économiser des ressources de formulaire personnalisées SharePoint dans un environnement autre que celui par défaut, il est également possible de limiter les privilèges du fabricant pour ne pouvoir créer et modifier que les formulaires personnalisés SharePoint dans un environnement autre que celui par défaut. En dehors de l’environnement par défaut, un administrateur peut désaffecter le rôle de sécurité de créateur d’environnement des utilisateurs et affecter le rôle de sécurité de créateur de formulaires personnalisés SharePoint.

Note

La capacité de distinguer les fabricants de formulaires SharePoint personnalisés des fabricants d’environnement généraux nécessite Dataverse dans l’environnement où le privilège doit être modifié.

Un utilisateur avec seulement le rôle de créateur de formulaire SharePoint personnalisé dans un environnement ne verra pas l’environnement dans la liste des environnements dans https://make.powerapps.com ou alors https://flow.microsoft.com.

Procédez comme suit pour limiter les privilèges du fabricant afin de ne pouvoir créer et modifier que des formulaires SharePoint personnalisés dans un environnement autre que celui par défaut.

1. Faites en sorte qu’un administrateur désigne un environnement pour les formulaires personnalisés SharePoint différent de l’environnement par défaut.

2. Faites en sorte qu’un administrateur installe la solution de création de formulaires personnalisés SharePoint à partir de AppSource vers votre environnement désigné pour les formulaires personnalisés SharePoint.

3. Dans le centre d’administration Power Platform, sélectionnez l’environnement que vous avez désigné pour les formulaires SharePoint personnalisés à la première étape et attribuez le rôle de sécurité de créateur de formulaires SharePoint personnalisés aux utilisateurs censés créer des formulaires SharePoint personnalisés. Voir Attribuez des rôles de sécurité aux utilisateurs dans un environnement doté d’une base de données Dataverse.

Questions fréquentes

Puis-je modifier les privilèges dans le rôle de sécurité du créateur de formulaires SharePoint personnalisés ?

Non, le rôle de sécurité du créateur de formulaires SharePoint personnalisés est ajouté à un environnement en important une solution non personnalisable. Remarque, la création de formulaire SharePoint personnalisé nécessite qu’un utilisateur dispose d’autorisations dans SharePoint et Power Platform. La plate-forme vérifie qu’un utilisateur dispose des autorisations d’écriture pour la liste ciblée créée avec Microsoft Listes et qu’il a la permission dans Power Platform pour créer ou mettre à jour le formulaire SharePoint personnalisé. Pour un fabricant de formulaires SharePoint personnalisés pour répondre au contrôle Power Platform, l’utilisateur doit avoir le rôle de sécurité du formulaire SharePoint personnalisé ou le rôle de sécurité Créateur d’environnement.

Est-ce qu’un utilisateur avec seulement le rôle de créateur de formulaire SharePoint personnalisé verra un environnement dans le sélecteur d’environnement make.powerapps.com ?

Non, un fabricant qui n’a pas de rôle de sécurité indiqué dans Choisir la documentation des environnements ne verra pas l’environnement dans le sélecteur d’environnement dans https://make.powerapps.com. Un utilisateur avec le rôle de créateur de formulaire SharePoint personnalisé peut tenter de naviguer vers l’environnement en manipulant l’URI. Si l’utilisateur tente de créer une application autonome, une erreur d’autorisation s’affichera.

Gérer l’état de mise en quarantaine de l’application

En complément des stratégies de prévention contre la perte des données de Power Platform, Power Platform permet aux administrateurs de « mettre en quarantaine » une ressource, en définissant des barrières de sécurité pour le développement à faible code. L’état de mise en quarantaine d’une ressource est géré par les administrateurs et contrôle si une ressource est accessible aux utilisateurs finaux. Dans Power Apps, cette fonctionnalité permet aux administrateurs de limiter directement la disponibilité des applications qui peuvent nécessiter une attention particulière pour répondre aux exigences de conformité d’une organisation.

Note

Une application mise en quarantaine n’est pas accessible aux utilisateurs qui n’ont jamais lancé l’application auparavant.

Une application mise en quarantaine peut être accessible, momentanément, aux utilisateurs qui ont lancé l’application avant qu’elle ne soit mise en quarantaine. Ces utilisateurs peuvent utiliser l’application mise en quarantaine pendant quelques secondes s’ils l’ont déjà utilisée. Mais après cela, ils reçoivent un message les informant que l’application est mise en quarantaine s’ils essaient de l’ouvrir à nouveau.

Le tableau suivant décrit l’impact de l’état de mise en quarantaine sur les expériences des administrateurs, des décideurs et des utilisateurs finaux.

Personnage	Expérience
Administrateur	Quel que soit l’état de mise en quarantaine d’une application, une application est consultable par les administrateurs dans les applets de commande PowerShell et le centre d’administration Power Platform.
Créateur	Quel que soit l’état de mise en quarantaine d’une application, une application est visible dans https://make.powerapps.com et peut être ouverte pour modification dans Power Apps Studio.
Utilisateur final	Une application mise en quarantaine présente aux utilisateurs finaux qui lancent l’application un message indiquant qu’ils ne peuvent pas accéder à l’application.

Les utilisateurs finaux voient le message suivant lorsqu’ils lancent une application qui a été mise en quarantaine.

Le tableau suivant reflète le support de la mise en quarantaine :

Type de Power Apps	Support de mise en quarantaine
Application canevas	Généralement disponible
Application pilotée par modèle	Non pris en charge à ce jour

Mettre une application en quarantaine

Set-AppAsQuarantined -EnvironmentName <EnvironmentName> -AppName <AppName>

Annuler la quarantaine d’une application

Set-AppAsUnquarantined -EnvironmentName <EnvironmentName> -AppName <AppName>

Obtenir l’état de mise en quarantaine d’une application

Get-AppQuarantineState -EnvironmentName <EnvironmentName> -AppName <AppName>

Accès conditionnel sur des applications individuelles (préversion)

En plus de respecter les stratégies d’accès conditionnel appliquées au service Power Apps, il est possible d’appliquer des stratégies d’accès conditionnel Microsoft Entra à des applications individuelles créées avec Power Apps. Par exemple, un administrateur peut appliquer une stratégies d’accès conditionnel nécessitant une authentification multifacteur uniquement sur les applications contenant des données sensibles. Power Apps tire parti d’un contexte d’authentification d’accès conditionnel comme mécanisme pour cibler les stratégies d’accès conditionnel sur les applications granulaires. Les administrateurs sont la personne autorisée à ajouter et à supprimer des contextes d’authentification sur une application. Les créateurs ne peuvent pas modifier les contextes d’authentification sur une application.

Note

1. Les contextes d’authentification définis sur une application ne sont pas déplacés avec les applications dans les solutions et déplacés entre les environnements. Cela permet d’appliquer différents contextes d’authentification aux applications dans différents environnements. De plus, lorsqu’une application se déplace d’un environnement à l’autre via des solutions, le contexte d’authentification défini dans un environnement est préservé. Par exemple, si un contexte d’authentification est défini sur une application dans un environnement UAT, ce contexte d’authentification est conservé.
2. Plusieurs contextes d’authentification peuvent être définis sur une application. Un utilisateur final doit réussir l’union des stratégies d’accès conditionnel appliquées par plusieurs contextes d’authentification.

Le tableau suivant décrit l’impact de l’application de l’accès conditionnel sur une application spécifique sur les expériences des administrateurs, des décideurs et des utilisateurs finaux.

Personnage	Expérience
Administrateur	Quelles que soient les stratégies d’accès conditionnel associées à une application, une application est visible pour les administrateurs dans le Centre d’administration Power Platform et les applets de commande PowerShell.
Fabricant	Quelles que soient les stratégies d’accès conditionnel associées à une application, une application est visible dans https://make.powerapps.com et peut être ouverte pour modification dans Power Apps Studio.
Utilisateur final	Les stratégies d’accès conditionnel appliquées à une application sont appliquées lorsque les utilisateurs finaux lancent l’application. Un utilisateur qui ne réussit pas les contrôles d’accès conditionnel se voit présenter une boîte de dialogue dans l’expérience d’authentification indiquant qu’il n’est pas autorisé à accéder à la ressource.

Une fois que les administrateurs ont associé les contextes d’authentification aux stratégies d’accès conditionnel dans https://portal.azure.com, ils peuvent définir l’ID de contexte d’authentification sur une application. L’image suivante montre où obtenir l’ID de contexte d’authentification.

Les utilisateurs finaux qui ne répondent pas aux exigences de la stratégie d’accès conditionnel observeront la boîte de dialogue suivante après s’être connectés pour accéder à une application.

Le tableau suivant reflète l’accès conditionnel à la prise en charge granulaire des applications :

Type de Power Apps	Accès conditionnel sur le support des applications individuelles
Application canevas	Disponibilité en version préliminaire
Application pilotée par modèle	Non pris en charge

Ajouter des ID de contexte d’authentification d’accès conditionnel à une application

Set-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName> -AuthenticationContextIds <id1, id2, etc...>

Obtenir des ID de contexte d’authentification d’accès conditionnel définis dans une application

Get-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName>

Supprimer des ID de contexte d’authentification d’accès conditionnel dans une application

Remove-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName>

Voir aussi

Prise en charge de PowerShell pour l’administrateur de Power Apps