Sécurité & ALM

Principaux de service dans la Power Platform : pourquoi, comment, déploiement et surveillance

Par Nicolas Boulet-Lavoie · 8 août 2026 · 16 min de lecture

Trop d'automatisations reposent encore sur le compte personnel de la personne qui les a créées. Le jour où ce compte change de mot de passe, quitte l'entreprise ou se voit imposer une authentification multifacteur, le flux s'arrête — souvent sans prévenir. Le principal de service est la réponse propre à ce problème : une identité applicative, non humaine, qui fait tourner vos automatisations de façon stable, sécurisée et traçable. Voici pourquoi l'adopter, comment le mettre en place, le déployer avec l'ALM et le surveiller.

Plan de match — PDF gratuitLa procédure de migration complète, en 7 phases, à cocher et à imprimer. Télécharger ↓

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

Dans Microsoft Entra ID (anciennement Azure AD), une inscription d'application définit une application. Le principal de service (service principal) est l'instance locale de cette application dans votre tenant : c'est l'identité qui obtient des jetons et exécute des actions. En pratique, on parle souvent d'un compte de service applicatif — une identité qui s'authentifie avec un secret ou un certificat, jamais avec un humain derrière le clavier.

Le point clé

Un utilisateur normal se connecte avec un mot de passe et, souvent, une double authentification. Un principal de service se connecte avec des identifiants d'application (client ID + secret ou certificat). Il n'a pas de boîte courriel, ne subit pas de MFA interactive et ne « part » pas quand un employé quitte l'entreprise. C'est exactement ce qu'il faut pour faire tourner une automatisation de façon durable.

Pourquoi l'utiliser ?

Rattacher une automatisation critique à un compte personnel est une dette technique qui finit toujours par se payer. Le principal de service règle six problèmes d'un coup.

Stabilité

Plus de flux qui casse à cause d'un mot de passe changé, d'une MFA ou d'un départ.

Sécurité

Droits limités au strict nécessaire (moindre privilège), sans partager un compte humain.

Zéro compte orphelin

L'automatisation ne dépend plus d'une personne : rien à réattribuer lors d'un départ.

ALM propre

Les connexions appartiennent à une identité de service, pas à un développeur — le déploiement se rejoue.

Traçabilité

Chaque action est journalisée sous une identité dédiée, distincte des actions humaines.

Gouvernance

Identités de service inventoriées, secrets à durée limitée, accès révocables en un clic.

Compte personnel ou principal de service ?

Le contraste est net dès qu'on met les deux approches côte à côte.

Critère	Compte utilisateur personnel	Principal de service
Authentification	Mot de passe + MFA (interactive)	Client ID + secret / certificat (non interactive)
Changement de mot de passe	Casse les connexions	Sans effet ; on gère l'expiration du secret
Départ d'un employé	Flux orphelins à réattribuer en urgence	Aucun impact
Droits	Ceux de la personne (souvent trop larges)	Rôle dédié, au strict nécessaire
Déploiement (ALM)	Connexions à recréer manuellement	Rejouable via références de connexion
Audit	Mêlé aux actions humaines	Identité isolée et surveillable

L'anatomie d'un principal de service

Mettre en place un principal de service, c'est assembler quatre pièces. Comprendre leur rôle évite bien des erreurs de configuration.

L'inscription d'application (Entra ID) : la définition de l'application et son client ID.
Le secret ou le certificat : l'identifiant qui prouve l'identité. Préférez un certificat pour la production ; à défaut, un secret à durée de vie courte.
L'utilisateur d'application (Dataverse) : le principal de service doit être ajouté comme utilisateur d'application dans l'environnement pour y agir.
Le rôle de sécurité : les permissions accordées à cet utilisateur d'application — au plus juste, jamais « Administrateur système » par confort.

Comment le créer et l'utiliser

La démarche tient en cinq étapes. Elle se fait entièrement au clavier, ou en une commande avec la CLI Power Platform.

Inscrire l'application

Dans Entra ID, créez une inscription d'application. Notez le client ID et le tenant ID.

Générer les identifiants

Ajoutez un certificat (recommandé) ou un secret client à échéance courte. Stockez-le hors de l'application.

Créer l'utilisateur d'application

Dans le centre d'administration Power Platform, ajoutez le principal comme utilisateur d'application de l'environnement.

Attribuer un rôle

Donnez-lui un rôle de sécurité minimal (idéalement un rôle sur mesure), limité aux tables réellement utilisées.

Connecter & exécuter

Créez une connexion « avec principal de service » et faites tourner vos flux et applications dessus.

Le raccourci CLI

La commande pac admin create-service-principal --environment <id> automatise l'essentiel : elle inscrit l'application, l'ajoute comme utilisateur d'application dans l'environnement et retourne le client ID, le tenant ID et le secret. Pratique pour amorcer un environnement — pensez ensuite à restreindre le rôle attribué et à sécuriser le secret.

Côté usage, tous les connecteurs ne supportent pas encore le principal de service, mais les plus importants oui — à commencer par Microsoft Dataverse, mais aussi SQL Server, Azure et plusieurs autres. Lorsqu'on crée la connexion, on choisit « Se connecter avec un principal de service » et l'on saisit le trio tenant ID / client ID / secret.

Le déployer avec l'ALM

C'est là que le principal de service prend toute sa valeur. Dans une démarche de gestion du cycle de vie applicatif (ALM), on ne recrée pas les connexions à la main dans chaque environnement — on les paramètre.

Élément	Rôle dans le déploiement
Références de connexion	Dans la solution, les flux pointent vers une référence ; à l'import, on la lie à la connexion « principal de service » de l'environnement cible.
Variables d'environnement	Client ID et tenant ID sont passés en variables, différentes par environnement (dev, test, prod).
Azure Key Vault	Le secret n'est jamais dans la solution : il est référencé depuis Key Vault, avec rotation et accès contrôlés.
Pipelines Power Platform	Le déploiement dev → test → prod se rejoue automatiquement, les connexions se rebranchant sur l'identité de service de chaque environnement.

Résultat : une solution qui se déploie de façon reproductible, sans dépendre d'un développeur ni d'un secret copié-collé dans un flux. C'est le socle d'une automatisation d'entreprise que l'on peut auditer et maintenir dans le temps.

Le surveiller

Une identité qui agit sans humain derrière doit être surveillée de près. Voici où regarder.

Quoi surveiller	Où
Connexions du principal de service (succès / échecs)	Entra ID → Journaux de connexion → onglet « Connexions de principaux de service »
Expiration des secrets et certificats	Entra ID → inscription d'application → Certificats & secrets (à alerter avant échéance)
Actions dans les données	Dataverse → journal d'audit ; centre d'administration Power Platform
Exécutions des flux	Historique d'exécution du flux ; analytique Power Automate
Inventaire des identités de service	CoE Starter Kit ; revue périodique des utilisateurs d'application par environnement

Bonnes pratiques

Un principal par usage : évitez le compte de service « fourre-tout » partagé entre tous les projets.
Moindre privilège : un rôle de sécurité sur mesure, limité aux tables et actions réellement nécessaires.
Certificat plutôt que secret en production ; si secret, durée de vie courte et rotation planifiée.
Secrets dans Key Vault, jamais en dur dans un flux, une variable ou un dépôt de code.
Alerter avant l'expiration du secret ou du certificat pour éviter l'interruption.
Documenter et inventorier chaque principal de service : à quoi il sert, qui en est responsable, quels droits.
Réviser périodiquement les accès et retirer les identités qui ne servent plus.

Et pour envoyer des courriels ?

C'est la question piège la plus fréquente. Le connecteur Office 365 Outlook (« Envoyer un courriel V2 »), celui qu'on utilise presque partout dans Power Automate, ne supporte pas le principal de service : il exige une connexion utilisateur rattachée à une boîte aux lettres. Or un principal de service n'a pas de boîte.

La bonne méthode

On passe par Microsoft Graph avec la permission d'application Mail.Send (consentement administrateur), en envoyant depuis une boîte partagée dédiée et en restreignant le principal à cette seule boîte via une stratégie d'accès d'application (Application Access Policy). Sans cette restriction, Mail.Send autorise l'envoi au nom de n'importe quelle boîte du tenant — beaucoup trop large. Pour des courriels transactionnels à volume, Azure Communication Services – Email est une alternative, sans boîte Exchange.

Tutoriel pas à pas : créer un principal de service et l'utiliser dans Power Automate

Voici la démarche complète, illustrée par le cas concret de l'envoi de courriels. Comptez une trentaine de minutes. Prérequis : un rôle d'administrateur d'application (ou global) dans Entra ID, un rôle d'administrateur Exchange, et un plan Power Automate Premium (l'action HTTP utilisée est une action premium).

Partie 1 — Créer l'inscription d'application (Entra ID)

Dans le portail Microsoft Entra, allez dans Applications → Inscriptions d'applications → Nouvelle inscription. Nommez-la clairement, par exemple svc-power-automate-courriel, et laissez « Comptes dans cet annuaire d'organisation uniquement ».
Sur la page Vue d'ensemble, notez l'ID d'application (client) et l'ID de l'annuaire (locataire / tenant). Vous en aurez besoin dans le flux.
Allez dans Certificats et secrets → Nouveau secret client. Choisissez une échéance courte (6 mois par exemple) et copiez immédiatement la valeur du secret : elle devient invisible dès que vous quittez la page. En production, préférez un certificat à un secret.

Partie 2 — Autoriser l'envoi de courriels (Microsoft Graph)

Dans l'inscription, ouvrez API autorisées → Ajouter une autorisation → Microsoft Graph → Autorisations d'application, cherchez Mail.Send et ajoutez-la.
Cliquez sur Accorder le consentement administrateur. Le statut de l'autorisation doit passer au vert (« Accordé »).
Créez une boîte aux lettres partagée dédiée (ex. [email protected]), puis limitez le principal à cette seule boîte avec une stratégie d'accès d'application, en PowerShell Exchange Online :

PowerShell — Exchange Online

New-ApplicationAccessPolicy `  -AppId <ID-client> `  -PolicyScopeGroupId [email protected] `  -AccessRight RestrictAccess `  -Description "Limiter svc-power-automate a la boite d'automatisation" # Verifier que la politique s'applique bienTest-ApplicationAccessPolicy `  -Identity [email protected] `  -AppId <ID-client>

Partie 3 — L'utiliser dans un flux Power Automate

(Recommandé) Stockez le secret dans Azure Key Vault et lisez-le dans le flux avec le connecteur Azure Key Vault, plutôt que de le coller en clair dans l'action.
Ajoutez une action HTTP (premium) et configurez-la ainsi :

Méthode : POST
URI : https://graph.microsoft.com/v1.0/users/[email protected]/sendMail
Authentification : Active Directory OAuth
— Autorité : https://login.microsoftonline.com
— Locataire : votre tenant ID
— Audience : https://graph.microsoft.com
— ID client : votre client ID
— Type d'identifiant : Secret → le secret (idéalement depuis Key Vault)

Corps de la requête (JSON) :

JSON — corps de la requête

{  "message": {    "subject": "Rapport quotidien",    "body": {      "contentType": "HTML",      "content": "<p>Bonjour,</p><p>Voici le rapport du jour.</p>"    },    "toRecipients": [      { "emailAddress": { "address": "[email protected]" } }    ]  },  "saveToSentItems": true}

Enregistrez et testez le flux. Une réponse 202 Accepted confirme l'envoi : le courriel part de la boîte partagée, exécuté par le principal de service — sans licence utilisateur ni boîte personnelle.

Et pour agir sur des données Dataverse ?

Si votre flux ne fait pas qu'envoyer des courriels mais lit ou écrit dans Dataverse, la logique est la même côté Entra ID, mais au lieu de Graph vous ajoutez le principal comme utilisateur d'application dans l'environnement (centre d'administration Power Platform), lui attribuez un rôle de sécurité minimal, puis créez une connexion Dataverse « avec principal de service » — sans passer par une action HTTP.

Faut-il retirer les licences ?

Question naturelle : puisque le principal de service ne consomme aucune licence — et qu'une boîte partagée non plus (sous 50 Go, sans archive ni conservation légale) — peut-on économiser en retirant la licence du compte qui envoie aujourd'hui les courriels ? Ça dépend entièrement du rôle de ce compte.

Compte dédié à une seule tâche (créé juste pour envoyer des courriels) : oui. Convertissez sa boîte en boîte partagée, validez le flux avec le principal de service, puis seulement retirez la licence. Jamais l'inverse, sinon les envois s'arrêtent.
Compte de service transversal (utilisé un peu partout pour automatiser, souvent avec Power Automate Premium) : non. Le convertir casserait tous les flux qui s'y connectent, et retirer la licence supprimerait le droit d'exécuter les connecteurs premium de ces flux. L'économie deviendrait une panne.

La bonne approche pour un compte transversal

Ne faites pas un « grand remplacement ». Gardez le compte et sa licence comme filet de sécurité, puis migrez flux par flux vers des principaux de service dédiés par usage (un pour l'envoi de courriels, un ou plusieurs pour Dataverse, etc.). À mesure que les flux basculent, le compte se vide de ses responsabilités. Le jour où plus rien n'en dépend, là vous évaluez la récupération de la licence. L'économie arrive à la fin — le vrai gain immédiat, c'est la robustesse et la gouvernance.

Ressources vidéo

Quelques tutoriels vidéo (chaînes tierces, en anglais) qui montrent ces étapes à l'écran.

Créer le principal de service

L'utiliser dans Power Automate (dont l'envoi de courriels)

Le principal de service n'est pas qu'un détail technique : c'est un pilier d'une automatisation gouvernée. Il s'inscrit naturellement dans une démarche plus large de gouvernance et de sécurisation de vos automatisations.

Vos automatisations reposent encore sur des comptes personnels ? Mettons en place des identités de service propres et gouvernées.

Discutons de votre projet