Compte de service vs principal de service dans Power Automate

Lorsqu'un flux tourne en production, le choix de l'identité sous-jacente détermine s'il continue de fonctionner même si une collègue est malade, qu'un mot de passe expire ou que quelqu'un quitte l'entreprise. C'est exactement là que la même question revient sans cesse dans Power Automate : un flux doit-il s'exécuter sous un compte de service classique, c'est-à-dire un compte utilisateur partagé, ou sous un principal de service, c'est-à-dire une identité autonome et non humaine dans Microsoft Entra ID ?

La réponse courte de la documentation officielle est claire : Microsoft recommande le principal de service pour les flux de production critiques pour l'activité et ne considère explicitement pas le compte de service classique comme une bonne pratique. Il vaut néanmoins la peine d'examiner de près les deux modèles, car ils fonctionnent techniquement de manière différente et impliquent des prérequis différents.

Qu'est-ce qu'un compte de service dans Power Automate ?

Selon la documentation Microsoft sur la licence de Power Automate un compte de service est un compte utilisateur Microsoft Entra tout à fait normal, détourné de son usage pour représenter une entité non humaine telle qu'une application ou un service. En pratique, cela signifie qu'une équipe crée un compte du type flow-production@entreprise.fr, partage le mot de passe avec plusieurs collègues, et ce compte devient alors propriétaire des flux de production.

Microsoft nomme directement le problème : si plusieurs personnes ont accès au même compte, il devient presque impossible de savoir qui a apporté quelle modification à un flux. S'y ajoute la gestion des mots de passe, un sujet permanent, par exemple lors de changements de mot de passe imposés ou d'authentifications multifacteur. Microsoft conseille donc explicitement de vérifier régulièrement les autorisations des comptes de service existants, de limiter autant que possible le cercle des personnes ayant accès et d'utiliser des comptes distincts pour des scénarios différents afin de réduire la surface d'attaque. Dans certains cas, un compte de service est utilisé pour rendre un flux indépendant de son créateur d'origine. Mais c'est précisément pour cet usage que Microsoft recommande explicitement de passer à un principal de service.

Qu'est-ce qu'un principal de service ?

Selon la documentation Microsoft sur la prise en charge des flux appartenant à un principal de service un principal de service est une identité de sécurité non humaine qui représente une application ou un service et peut posséder et gérer de manière autonome des ressources dans Azure et la Power Platform. Techniquement, il repose sur une inscription d'application Microsoft Entra. Pour qu'un principal de service puisse posséder des flux dans la Power Platform, un utilisateur d'application doit d'abord être créé, soit via le centre d'administration Power Platform, soit via l'API.

Une fois cet utilisateur d'application configuré, la propriété d'un flux cloud peut lui être transférée : dans le flux, vous ouvrez la section Détails, choisissez Modifier et remplacez le propriétaire par le nom de l'utilisateur d'application. Important : selon la documentation, un principal de service ne peut pas devenir copropriétaire d'un flux, mais uniquement propriétaire exclusif. Pour un flux en dehors d'une solution, toutes les connexions utilisées doivent en outre être partagées explicitement avec l'utilisateur d'application ; pour un flux de solution, cette étape n'est pas nécessaire.

Compte de service ou principal de service : l'aide à la décision

Pour la pratique quotidienne, la décision peut se fonder sur des critères clairs, comme le décrit également la documentation Microsoft sur l'accès aux flux Power Automate :

• Flux critiques pour l'activité ou à l'échelle de l'entreprise : Microsoft recommande ici explicitement le principal de service, car la propriété du flux est ainsi totalement découplée du cycle de vie d'une seule personne. Si quelqu'un quitte l'entreprise ou change de rôle, le flux reste intact.
• Pipelines DevOps sur plusieurs environnements : quiconque déploie des flux automatiquement du développement au test puis à la production devrait, selon la documentation, également s'appuyer sur le principal de service, car il se gère proprement via l'API.
• Traçabilité : un principal de service laisse une piste d'audit claire, indépendante des personnes. Avec un compte de service partagé, on ne sait souvent plus qui a modifié quoi et quand.
• Flux interactifs ou spécifiques à un utilisateur : si un flux a besoin du contexte personnel d'un humain, par exemple pour des approbations ou des autorisations personnalisées, un compte utilisateur classique reste le bon choix, ni un compte de service ni un principal de service.
• Comptes de service existants : si vous souhaitez faire passer un flux en cours d'exécution d'un compte de service à un principal de service, vous devriez également vérifier les limites de licence et de requêtes, nous y reviendrons juste après.

Licences et limites de requêtes : ne pas les sous-estimer

Un principal de service propriétaire d'un flux est considéré dans Power Automate comme un utilisateur d'application non interactif et ne peut donc pas recevoir de licence utilisateur classique. Ses propres limites de requêtes non soumises à licence s'appliquent à la place, et dès que le flux utilise des connecteurs premium, il a besoin d'une licence de processus Power Automate ou d'une licence par flux, ou à défaut de l'appartenance à un groupe de flux disposant de la licence correspondante.

Pour un compte de service classique, en revanche, c'est la logique de licence habituelle des comptes utilisateur qui s'applique, complétée par une règle spéciale contre ce que l'on appelle le multiplexage : si plusieurs personnes partagent les identifiants d'un compte de service et que le flux utilise des fonctionnalités premium, la documentation recommande une licence de processus pour le flux dès que de nombreuses personnes différentes utilisent le compte, afin que les nouveaux utilisateurs restent automatiquement conformes en matière de licence. Il ne faut pas confondre le compte de service avec les comptes utilisateur non interactifs que Dataverse prévoit pour les processus en arrière-plan tels que les migrations de données : un maximum de sept est autorisé par locataire, et Power Automate lui-même ne prend pas encore en charge ce type de compte particulier comme propriétaire de flux, selon la documentation.

Et qu'en est-il de l'identité managée ?

Quiconque vient du monde Azure pense rapidement, pour les identités non humaines, aux identités managées, c'est-à-dire des identités attribuées par le système ou par l'utilisateur, qui rendent les identifiants totalement superflus. Pour les flux cloud de Power Automate, ce concept n'est toutefois pas une option directe pour l'instant : les identités managées sont avant tout ancrées dans Azure Logic Apps, où certains connecteurs intégrés et gérés, comme Azure Key Vault, Azure Blob Storage ou Azure SQL, peuvent s'authentifier via elles. Dans Power Automate même, c'est le principal de service qui assume la tâche comparable de donner à un flux une identité stable, indépendante de personnes individuelles. Ceux qui exploitent en parallèle des flux et des Logic Apps devraient garder cette différence à l'esprit plutôt que d'assimiler mentalement les deux concepts.

La transition en pratique : du compte de service au principal de service

Le changement se déroule en trois étapes : vous créez d'abord une inscription d'application dans Microsoft Entra ID, puis vous en créez un utilisateur d'application dans la Power Platform. Ensuite, vous partagez explicitement avec cet utilisateur d'application toutes les connexions utilisées par le flux, sauf s'il s'agit d'un flux de solution. Enfin, vous changez dans le flux le propriétaire pour le nouvel utilisateur d'application et vous réactivez le flux. Prévoyez pour cette dernière étape un court test avant de désactiver l'ancien compte de service, afin que les processus de production ne tournent pas dans le vide.

Si vous ne souhaitez pas mener seul la migration de plusieurs flux de production, des comptes de service vers des principaux de service, vous trouverez de l'aide dans l'offre Power Automate de NordFlux, depuis la mise en place de l'inscription d'application jusqu'à la sécurisation de la structure de licences et d'autorisations. Vous gardez ainsi le contrôle sur qui possède et exploite quelle automatisation, même à mesure que votre paysage de flux s'agrandit.

Questions fréquentes

Un compte de service est-il interdit pour les flux de production ?

Pas interdit, mais Microsoft ne le considère explicitement pas comme une bonne pratique. Pour les flux critiques pour l'entreprise ou de longue durée, la documentation recommande clairement à la place le principal de service, car celui-ci ne dépend pas de personnes individuelles ni de mots de passe partagés.

Un principal de service peut-il être copropriétaire d'un flux ?

Non. Selon la documentation, un utilisateur d'application principal de service ne peut être que le propriétaire exclusif d'un flux, jamais copropriétaire. Il n'apparaît donc même pas dans la boîte de dialogue de modification des copropriétaires.

Un principal de service a-t-il besoin de sa propre licence Power Automate ?

Un principal de service est un utilisateur d'application non interactif et ne peut donc pas recevoir de licence utilisateur classique. Dès que le flux utilise des connecteurs premium, il a besoin à la place d'une licence de processus Power Automate ou d'une licence par flux, ou de l'appartenance à un groupe de flux disposant de la licence adaptée.

L'identité managée peut-elle aussi être utilisée dans Power Automate ?

Pas directement pour posséder un flux cloud. Les identités managées sont avant tout un concept d'Azure Logic Apps pour l'authentification auprès de certaines ressources Azure. Dans Power Automate, le principal de service assume le rôle comparable d'une identité de flux stable et non humaine.

Que deviennent les connexions existantes lorsque je change de propriétaire ?

Les connexions ne sont pas automatiquement transférées au nouveau propriétaire. S'il s'agit d'un flux en dehors d'une solution, vous devez en plus partager explicitement toutes les connexions utilisées avec le nouvel utilisateur d'application principal de service, sinon l'exécution échoue. Pour un flux de solution, cette étape n'est pas nécessaire, selon la documentation.