Gérer des flux partagés avec des utilisateurs en dehors d’un environnement

À partir de juin 2025, tout flux partagé avec un utilisateur qui n’est pas membre de l’environnement devient inaccessible à cet utilisateur. Ce changement important dans Power Automate nécessite que les utilisateurs soient membres d’un environnement pour accéder aux flux dans cet environnement. Cette modification renforce la sécurité en appliquant les limites de l’environnement. Cependant, cela a un impact sur les organisations qui ont des flux partagés entre différents environnements, par exemple, un propriétaire de flux qui ajoute une personne extérieure à l’environnement en tant que copropriétaire ou utilisateur d’exécution uniquement.

Pour se conformer à la nouvelle stratégie, les administrateurs Power Platform doivent identifier les flux partagés avec des utilisateurs externes à leur environnement et ajuster les paramètres de partage de ces flux. Cet article propose une approche structurée pour y parvenir.

Cet article vous aide à effectuer les opérations suivantes :

• Identifiez les flux partagés avec des utilisateurs externes (utilisateurs ne faisant pas partie de l’environnement du flux).
• Ajustez le partage et l’accès à ces flux pour assurer la continuité (par exemple, ajoutez les utilisateurs appropriés aux environnements et utilisez un accès en exécution seule).

Cet article permet aux administrateurs Power Platform de résoudre de manière préventive les problèmes de partage avant la mise en application en juin 2025. Cela peut également aider à établir une gouvernance pour gérer le partage de flux en toute sécurité à l’avenir. Pour illustrer les points clés, cet article comprend des exemples réels et des instructions étape par étape.

Pour connaître les pratiques recommandées pour gérer les flux partagés, consultez Partager un flux de cloud.

Identifier les flux partagés avec des utilisateurs en dehors de leur environnement

La première étape consiste à inventorier tous les flux de cloud et leurs utilisateurs partagés dans chaque environnement, puis à identifier les flux qui ont des partages avec des personnes externes, c’est-à-dire des utilisateurs qui ne sont pas membres de cet environnement. Les flux Power Automate peuvent être créés de deux manières : en tant que flux normaux (hors solution) ou en tant que flux basés sur une solution (faisant partie d’une solution Dataverse). Les deux résident dans un environnement et doivent tous deux être examinés. Les sections suivantes décrivent les méthodes permettant d’identifier les flux partagés en externe.

Centre d’administration Power Platform - Méthode GUI

Les administrateurs d’environnement peuvent utiliser le centre d’administration Power Platform pour un audit visuel.

1. Dans le centre d’administration Power Platform, sélectionnez Gérer>Environnements > (votre environnement) >Ressources>Flux.

   Une liste de tous les flux de l’environnement, ainsi qu’une colonne Propriétaires s’affiche.

2. Pour chaque flux, inspectez les propriétaires. Si un flux a plusieurs propriétaires (créateur et copropriétaires), il est partagé. Comparez ces propriétaires aux membres connus de l’environnement. Par exemple, comparez le groupe de sécurité ou la liste d’utilisateurs pour cet environnement.

3. Signalez les flux où un propriétaire ou un copropriétaire n’est pas un membre attendu de l’environnement. Par exemple, si l’environnement du département A ne contient que des utilisateurs du département A, mais que vous voyez un copropriétaire du département B, ce flux est partagé avec une personne extérieure. Vous devrez peut-être sélectionner le nom d’un propriétaire pour afficher les détails ou effectuer des références croisées avec l’annuaire des utilisateurs de votre environnement.

Avantages du centre d’administration Power Platform - Méthode GUI

Le centre d’administration Power Platform fournit une interface conviviale et permet le filtrage et le tri des flux par nom ou propriétaire. Vous pouvez rapidement repérer les incohérences évidentes si vous savez quelles équipes et quels utilisateurs appartiennent à l’environnement.

Inconvénients du centre d’administration Power Platform - Méthode GUI

Cette méthode est manuelle et ne s’adapte pas correctement à de nombreux flux. Vous devez vérifier individuellement les propriétaires, ce qui peut prendre beaucoup de temps pour les environnements de grande taille. Il peut être difficile de vérifier l’appartenance à un environnement directement à partir de l’interface utilisateur.

Script PowerShell : méthode automatisée

Pour un audit systématique et reproductible, Power Automate offre des applets de commande PowerShell administratives pour répertorier les flux et leurs propriétaires. Cette approche est puissante pour l’analyse en bloc dans de grands environnements ou des locataires entiers. Vous pouvez écrire un script pour le processus afin qu’il génère tous les flux et mette en évidence les partages externes.

Par exemple, ce script utilise Get-AdminFlow pour récupérer tous les flux, puis Get-AdminFlowOwnerRole pour chaque flux pour répertorier ses propriétaires et leurs rôles. La sortie répertorie chaque nom de flux et une puce de Owner: [User], Role: [Owner/Co-owner]. Vous pouvez rediriger cette sortie vers un fichier ou la traiter ultérieurement.

Ensuite, déterminez les partages externes : Comparez le nom d’utilisateur principal (UPN) de chaque propriétaire à l’ensemble des utilisateurs membres de l’environnement. Un partage externe est indiqué par tout propriétaire dont l’UPN ne figure pas dans la liste d’utilisateurs ou le groupe de sécurité de l’environnement. En pratique, vous pouvez :

• Exportez la liste des propriétaires de flux à partir du script précédent et de la liste des utilisateurs de l’environnement, puis utilisez Excel ou un script pour rechercher les différences, ou
• Améliorez le script PowerShell pour effectuer une vérification croisée avec les utilisateurs de l’environnement via Get-AdminEnvironmentUser.

Avantages du script PowerShell - méthode automatisée

Cette méthode est automatisée et complète. Il peut énumérer rapidement des centaines ou des milliers de flux et peut être créé par script pour la création de rapports. Vous pouvez l’exécuter selon une planification, par exemple mensuelle, pour repérer de nouveaux partages externes.

Inconvénients du script PowerShell – méthode automatisée

Nécessite une familiarité avec PowerShell et les privilèges d’administrateur. De plus, la sortie brute affiche les UPN et les ID d’objet. Vous devez interpréter ceux qui sont externes à l’environnement et nécessitent une analyse. Cependant, cela est simple si vous connaissez le domaine utilisateur de votre environnement ou si vous disposez d’une liste de membres de l’environnement.

Boîte à outils du Center of Excellence (CoE) – Méthode du tableau de bord

Si votre organisation utilise le Starter Kit du Center of Excellence Power Platform, il fournit des tableaux de bord et des rapports Power BI qui comprennent des mesures de partage. L’inventaire des flux du CoE peut mettre en évidence les flux qui ont des propriétaires invités ou des propriétaires en dehors du groupe de sécurité normal de l’environnement. Par exemple, le tableau de bord CoE peut contenir un rapport de Flux avec plusieurs propriétaires ou de Flux partagés avec des utilisateurs invités. Vous pouvez exploiter ces informations pour rechercher les flux présentant un partage anormal.

Avantages de la boîte à outils du Center of Excellence (CoE) - Méthode du tableau de bord

Rapports visuels centralisés qui agrègent peut-être déjà les données de l’environnement. Pas de script supplémentaire si le CoE est en place. Il peut signaler automatiquement les modèles non conformes.

Inconvénients de la boîte à outils du Center of Excellence (CoE) – méthode du tableau de bord

Nécessite que le kit de démarrage CoE soit déployé et maintenu à jour. Les données peuvent ne pas être en temps réel (elles sont généralement actualisées selon un calendrier). En outre, la configuration de filtres personnalisés, tels que l’identification des utilisateurs de domaine externes, peut nécessiter de modifier les composants CoE.

Comparaison des méthodes d’identification

À l’aide d’une ou d’une combinaison des méthodes du tableau précédent, compilez une liste des flux qui ont des utilisateurs partagés externes. Il s’agit des flux concernés qui nécessitent une attention particulière avant le changement de stratégie. Dans de nombreuses organisations, il peut s’agir d’un sous-ensemble de flux gérable, par exemple, seulement quelques flux inter-services ou des flux partagés avec le compte invité d’un partenaire. Dans d’autres, en particulier les locataires ayant des pratiques de partage ouvertes, il peut y avoir un nombre important de flux à gérer, donc plus tôt vous les identifiez, mieux c’est.

Ajuster le partage et l’accès pour les flux concernés

Une fois que vous avez identifié les flux qui sont partagés avec des utilisateurs en dehors de leur environnement, l’étape suivante consiste à corriger la configuration de partage de chaque flux. L’objectif est de s’assurer que chaque utilisateur qui a besoin d’accéder à un flux est correctement ajouté à l’environnement (ou que l’accès au flux est modifié d’une autre manière). Effectuez cette opération afin que personne ne perde de fonctionnalités lorsque la nouvelle application entre en vigueur. Les sections suivantes décrivent comment gérer les ajustements.

Évaluer la nécessité de chaque partage externe

Pour chaque flux signalé, discutez avec le propriétaire du flux ou l’équipe commerciale concernée de la raison pour laquelle il a été partagé en externe. Ce contexte est important pour décider du correctif. La liste suivante décrit des scénarios et des actions courants.

• Scénario 1 : l’utilisateur a été ajouté en tant que copropriétaire simplement pour exécuter le flux ou voir les sorties : dans de nombreux cas, les propriétaires ont ajouté un utilisateur externe en tant que propriétaire alors que cette personne n’avait besoin que de déclencher ou d’utiliser le flux (pas de le modifier). Par exemple, le propriétaire peut ajouter un agent du support technique en tant que copropriétaire d’un flux afin de pouvoir le déclencher manuellement. Dans ce cas, l’utilisateur n’a probablement pas besoin de droits de propriétaire complets.
• Action : supprimez-les de la liste Propriétaires et partagez à la place le flux avec eux en tant qu’utilisateur en exécution seule (le cas échéant), après vous être assuré qu’ils ont accès à l’environnement. Cela fournit la capacité nécessaire pour exécuter le flux sans en faire un propriétaire. Pour en savoir plus, consultez la section Ajouter les utilisateurs nécessaires à l’environnement de cet article.
• Scénario 2 : l’utilisateur collabore réellement à la création ou à la maintenance du flux : par exemple, deux départements développent conjointement un flux, un utilisateur du département B est donc devenu copropriétaire dans l’environnement du département A.
• Action : intégrez correctement cet utilisateur dans l’environnement en tant que propriétaire avec le rôle approprié, ou envisagez de déplacer le flux vers un environnement neutre si plusieurs unités organisationnelles doivent en être copropriétaires. À court terme, ajouter l’utilisateur à la liste des utilisateurs autorisés de l’environnement et lui attribuer un rôle approprié (créateur d’environnement s’il a besoin de droits de modification) résout les problèmes d’accès.
• Scénario 3 : le partage n’est plus nécessaire : parfois, des utilisateurs ont été ajoutés temporairement ou ont quitté le projet.
• Action : supprimez l’utilisateur externe du partage du flux. Il s’agit de la solution la plus simple, le cas échéant. Si personne en dehors de l’environnement n’a besoin du flux, annulez le partage avec eux. Le flux est alors conforme et il ne reste que les propriétaires internes.
• Scénario 4 : partages entre clients ou d’utilisateurs invités : par exemple, un flux a été partagé avec un compte invité (client externe). Ceci est bloqué après l’application.
• Action : déterminez si cet invité a absolument besoin d’un accès. Si oui, une option consiste à ajouter officiellement cet invité en tant qu’invité Azure AD dans votre client et dans le groupe de sécurité de l’environnement. Cela en fait un membre de l’environnement. Ceci est rare. Vous pouvez également travailler au transfert de la propriété à un utilisateur interne qui peut agir au nom de l’invité, ou utiliser un mécanisme différent, comme exposer le flux via un déclencheur HTTP sécurisé plutôt que le partage direct. Nous vous recommandons de supprimer les partages d’invités directs, car même s’ils sont ajoutés en tant que membre de l’environnement, des problèmes entre locataires peuvent survenir.

Ajouter les utilisateurs nécessaires à l’environnement

Pour chaque utilisateur qui doit continuer à avoir accès au flux, assurez-vous qu’il est membre de l’environnement à l’avenir. Cela signifie généralement que :

• Si l’environnement utilise un groupe de sécurité : ajoutez le compte de l’utilisateur à ce groupe de sécurité Azure AD. Cela leur confère le rôle d’utilisateur de base par défaut dans l’environnement, sauf configuration contraire. Le rôle d’utilisateur de base est généralement suffisant pour une personne qui n’a besoin que d’exécuter des flux et non de créer et de modifier. Après l’avoir ajouté, vérifiez que l’utilisateur apparaît désormais dans la liste des utilisateurs de l’environnement dans le centre d’administration Power Platform.

• S’il s’agit de l’environnement par défaut du client, qui est ouvert à tous les utilisateurs : la plupart des utilisateurs sous licence s’y trouvent déjà. Assurez-vous que l’utilisateur dispose d’une licence Power Automate. L’application affecte principalement les environnements autres que ceux par défaut avec une appartenance restreinte.

• Créateur d’environnement et utilisateur de base  n’accordez pas le rôle de créateur d’environnement à moins que la personne n’ait vraiment besoin de créer et de modifier des flux dans cet environnement. Dans nos correctifs, nous préférons attribuer uniquement l’utilisateur de base, ou un rôle minimal personnalisé, qui permet d’exécuter des flux partagés. Pour l’accès en exécution seule, l’utilisateur de base est suffisant ; l’utilisateur n’a pas besoin d’être un créateur. La limitation des rôles de créateur est une bonne pratique de gouvernance, qui est abordée plus en détail dans la section suivante.

Ajuster les paramètres de partage du flux

L’utilisateur étant désormais membre de l’environnement, ajustez la façon dont le flux est partagé avec lui.

• Si l’utilisateur n’a besoin que d’exécuter le flux : utilisez le partage en exécution seule. Dans Power Automate, ouvrez les paramètres de partage du flux. Supprimez l’utilisateur de la liste Propriétaires et, dans la section Utilisateurs en exécution seule, ajoutez son nom. Pour les flux déclenchés manuellement, comme les flux de bouton et les flux instantanés, ou les flux déclenchés avec des liens partageables, cela garantit que la personne peut déclencher le flux sans en être propriétaire. Ils ne peuvent pas modifier ou afficher les composants internes du flux et peuvent uniquement l’exécuter. Le résultat est que l’utilisateur reste en dehors de la liste des propriétaires, il n’y a donc pas de conflit d’environnement, mais peut utiliser la fonctionnalité du flux comme prévu.

  Exemple : Bob du marketing était copropriétaire du flux Processeur de prospects des ventes juste pour le déclencher régulièrement. Nous supprimons Bob en tant que copropriétaire et l’ajoutons en tant qu’utilisateur en exécution seule. Bob est également ajouté à l’environnement Sales en tant qu’utilisateur de base. Maintenant Bob peut sélectionner le bouton du flux ou recevoir son lien pour l’exécuter, mais il n’est plus un propriétaire externe, il est un utilisateur de base autorisé de cet environnement.

• Si l’utilisateur a besoin d’autorisations complètes du propriétaire (co-création) : après l’avoir ajouté à l’environnement, assurez-vous qu’il reste répertorié comme propriétaire du flux. Techniquement, vous pouvez les supprimer et les rajouter pour actualiser les autorisations. Mais une fois qu’ils sont dans l’environnement, le partage est légitime. Vous pouvez également envisager de déplacer le flux vers une solution si deux propriétaires de zones différentes le maintiennent à long terme. Les flux de solution sont plus faciles à transporter vers un environnement dédié si nécessaire. Dans tous les cas, vérifiez qu’ils apparaissent sous Propriétaires et que leur rôle est Peut modifier (propriétaire) dans les détails du flux.

• Supprimez tous les partages redondants ou non autorisés : pendant ce processus, profitez-en pour faire le ménage. Si une personne a été ajoutée juste au cas où, mais n’utilise jamais le flux, supprimez-la. Le principe du moindre privilège contribue à réduire la supervision. Assurez-vous que la liste Propriétaires de chaque flux est limitée à ceux qui ont vraiment besoin d’un accès à la conception et aux modifications.

Communiquer les changements aux utilisateurs concernés

Si vous supprimez l’accès d’une personne ou modifiez la façon dont elle appelle un flux, informez-la. Du point de vue de l’utilisateur, l’exécution d’un flux via un accès en exécution seule peut être légèrement différente. Ils peuvent obtenir un lien de partage ou voir le flux dans Flux d’équipe plutôt que dans Mes flux. Expliquez que « pour nous conformer aux nouvelles stratégies Power Automate, nous avons mis à jour la méthode de partage pour le flux X. Vous pouvez continuer à l’exécuter avec la méthode Y, mais il ne s’affiche plus sous votre propriété directe. Cela permet d’éviter toute confusion.

Vérifier l’état post-ajustement

Après avoir apporté des modifications, utilisez le centre d’administration PowerShell ou Power Platform pour vérifier qu’aucun flux ne reste avec des propriétaires externes. Par exemple, exécutez à nouveau le script d’identification et vérifiez qu’il ne signale plus ces flux. Résolvez chaque instance signalée par la suppression ou l’appartenance appropriée à l’environnement.

En effectuant ces ajustements, vous vous assurez que lorsque Microsoft bascule le commutateur, ces flux continuent de s’exécuter pour les utilisateurs prévus. Au lieu d’une erreur indiquant you do not have access to this flow, l’utilisateur reste autorisé, car il est désormais membre de l’environnement dans une capacité appropriée. Essentiellement, vous alignez vos pratiques de partage sur le modèle de gouvernance de la plateforme.

Informations associées

• Guide sur le partage de flux de cloud et les autorisations
• Partager un flux de cloud