La dépendance à une seule personne dans Power Automate — pour que les flux ne s'arrêtent pas quand leur créateur quitte l'entreprise

« Nous avions un employé qui connaissait bien Power Automate et qui avait automatisé toutes sortes de tâches dans l’entreprise. Mais il va démissionner le mois prochain, et personne ne sait quel flux fait quoi » — ce type de consultation a nettement augmenté ces derniers temps. Il arrive aussi qu’on nous contacte alors que la personne est déjà partie, au stade où « depuis le mois dernier, les e-mails de notification de commande n’arrivent plus, et personne ne sait comment les réparer ».

Nous avions déjà traité, dans l’article « Reprendre un système sans code source ni documentation — la procédure pratique pour l’exploiter et le maintenir sans l’arrêter », la passation d’un système dont le créateur est parti. Les flux Power Automate, précisément parce qu’ils peuvent être créés sans code, sont encore plus sujets à la même situation, et n’ont en plus aucune garantie de « rester en place » comme le ferait un exécutable. C’est parce qu’un flux est fortement lié au compte de son créateur et à ses connexions, et que la façon dont il se casse change au moment même où ce compte est désactivé ou supprimé. Cet article vérifie, en s’appuyant sur la documentation officielle de Microsoft, ce qui arrive concrètement à un flux quand son propriétaire disparaît, puis met en ordre, dans l’ordre pratique d’une petite ou moyenne entreprise : ce qu’il faut faire avant le départ, ce que l’on peut faire après le départ, et comment concevoir l’inventaire et le compte d’exécution pour éviter dès le départ la dépendance à une seule personne.

1. La conclusion, d’abord

• Un flux a pour propriétaire son créateur, et les connexions utilisées à l’exécution (authentification vers SharePoint, Outlook, etc.) sont liées au compte de la personne qui les a créées. Une connexion partagée ne peut être utilisée qu’à l’intérieur de ce flux, et même un copropriétaire ne peut pas modifier les identifiants d’une connexion créée par quelqu’un d’autre.¹
• Même si le propriétaire quitte l’entreprise, le flux lui-même continue de fonctionner tant qu’il reste un copropriétaire. Les actions utilisant la connexion de la personne partie finissent toutefois par échouer, d’où la nécessité de remplacer ces connexions.¹²
• Un flux sans aucun propriétaire valide devient un « flux orphelin » (orphaned flow). Un administrateur peut le repérer sur la page d’environnement du centre d’administration Power Platform (Ressources → Flux) et ajouter un nouveau propriétaire depuis « Partager ». Un traitement en masse via PowerShell (Get-AdminFlow, Set-AdminFlowOwnerRole) est également possible.²
• Avant le départ, la démarche se fait en deux temps : « ajout d’un copropriétaire » puis « changement de propriétaire ». Le transfert de propriété (la passation pendant que la personne est encore en poste) n’est possible que pour les flux compatibles avec les solutions ; les flux hors solution doivent être ajoutés à une solution ou reconstruits par export/import.³⁴
• Le problème des e-mails de notification qui continuent d’être envoyés au nom de la personne, on peut s’en affranchir de l’impact du départ en les faisant partir d’une boîte aux lettres partagée (action « Envoyer un e-mail depuis une boîte aux lettres partagée (V2) »). Les recommandations de Microsoft vont aussi dans ce sens : pour les notifications formalisées, utiliser un expéditeur partagé plutôt qu’un nom personnel.⁵⁶
• Un compte de service reposant sur le partage d’un compte utilisateur n’est pas recommandé comme bonne pratique, et pour les flux critiques pour l’activité, Microsoft recommande officiellement la propriété par principal de service. Comme les PME se heurtent toutefois à des obstacles de configuration et de licence, le chapitre 5 de cet article propose une répartition réaliste des usages.⁴⁷⁸
• La première étape n’est pas technique : c’est l’inventaire. Commencez par lister, via le centre d’administration et Get-AdminFlow, les flux existants dans l’entreprise, et par constituer un registre minimal des flux (nom, objectif, propriétaire, connexions, activité concernée).⁹

2. Comment naît la dépendance à une seule personne pour un flux

La dépendance à une seule personne dans Power Automate ne vient ni de mauvaise volonté ni de négligence : elle naît de l’accumulation de bonnes intentions. Voici le déroulement typique.

1. Une personne du terrain qui s’y connaît crée un flux pour se faciliter la tâche. Quelque chose de modeste, comme « transcrire les réponses d’un formulaire Forms dans Excel ».
2. Comme c’est pratique, l’entourage s’y met aussi. Des demandes affluent — « envoyez aussi cette notification à notre service », « pourriez-vous aussi enregistrer les bons de commande ? » — et les flux se multiplient et grandissent.
3. Sans qu’on s’en rende vraiment compte, cela s’infiltre dans le cœur de l’activité. Des traitements comme la première prise en charge des commandes, l’enregistrement des factures ou la circulation des approbations — le genre de tâche qui bloque l’activité si elle s’arrête — finissent par tourner sur des flux liés au compte personnel de cette personne.
4. Le tout fonctionne de façon stable sans que personne n’en connaisse le contenu. Comme il n’y a aucune raison de toucher à quelque chose qui fonctionne, ni passation ni documentation ne sont créées. « On n’y touche pas parce que ça marche » se transforme directement en « personne ne peut y toucher ».

Ce schéma est le même que celui d’un système sans code source ni spécifications qui reste après le départ de son développeur. Power Automate présente cependant deux points plus délicats qu’un système hérité classique. Premièrement, le flux est créé dans « Mes flux », un espace personnel dont l’existence même n’est visible que par son créateur. Contrairement à un système dont l’exécutable reste sur un serveur, un flux n’apparaît même pas dans une liste tant qu’on ne l’a pas inventorié. Deuxièmement, l’exécution du flux dépend du compte de son créateur et de ses connexions. L’impact se manifeste dès l’instant où le compte est désactivé ou supprimé dans le cadre du départ. Le chapitre suivant vérifie précisément ce comportement.

D’abord, un terme à poser — qu’est-ce qu’un « flux compatible avec les solutions » ?

Ce terme revient souvent dans les chapitres suivants, autant le clarifier dès maintenant. Une solution est un contenant permettant de transporter ensemble un flux et ses composants (références de connexion, tables Dataverse, applications, etc.). Son utilisation nécessite un environnement disposant de Dataverse, et un flux créé (ou ajouté a posteriori) dans une solution s’appelle un flux compatible avec les solutions (solution-aware flow).¹⁰

Dans le contexte de la passation, la différence suivante entre en jeu.

La première ligne de ce tableau répond à la question « pourquoi peut-on changer le propriétaire d’un flux compatible avec les solutions ? ». Pour un flux ordinaire, le propriétaire est intégré à l’identité même du flux, donc il ne peut pas être remplacé après coup. Pour un flux compatible avec les solutions, ce lien est détaché, ce qui permet de remplacer le propriétaire.³ Autrement dit, la mesure la plus efficace contre la dépendance à une seule personne consiste à placer dès le départ les flux importants dans une solution. La décision d’adoption est traitée au chapitre 7.

3. Que devient un flux quand le compte disparaît ?

Le flux lui-même ne disparaît pas, mais devient un « flux orphelin »

Tout d’abord, un préalable : même si le compte de la personne partie est supprimé de Microsoft Entra ID, les flux qu’elle a créés ne sont pas supprimés automatiquement. Les flux et les connexions sont classés comme des éléments « que l’administrateur doit vérifier et supprimer manuellement » : ils ne disparaissent donc jamais tout seuls. En revanche, l’historique d’exécution est, lui, supprimé automatiquement avec la suppression du compte. Soyez vigilant si vous comptez sur les anciens enregistrements d’exécution comme trace.¹¹

Même si le flux subsiste, un flux qui n’a plus aucun propriétaire valide se retrouve dans l’état appelé flux orphelin (orphaned flow). La documentation de support de Microsoft définit un flux orphelin comme « un flux sans propriétaire valide », et précise explicitement que si le flux utilise une connexion liée au compte d’un utilisateur qui a quitté l’entreprise, il peut échouer.²

Les connexions sont liées au compte de la personne

C’est le point le plus critique. Les connexions utilisées par chaque action du flux (authentification vers SharePoint, Outlook, Teams, etc.) fonctionnent avec les identifiants de l’utilisateur qui les a créées. La FAQ officielle sur le cas où le créateur d’un flux partagé quitte l’entreprise résume la situation ainsi :¹

• S’il reste un propriétaire valide, tel qu’un copropriétaire, le flux lui-même continue de fonctionner
• Cependant, les actions utilisant une connexion au nom de la personne partie peuvent échouer, il faut donc mettre à jour les identifiants de la connexion (concrètement, remplacer, dans l’écran d’édition du flux, la connexion de chaque action par une connexion d’un autre compte)

De plus, une connexion partagée ne peut être utilisée qu’à l’intérieur de ce flux, et même un copropriétaire ne peut pas modifier les identifiants d’une connexion créée par un autre propriétaire.¹ Autrement dit, « on a ajouté un copropriétaire, donc tout va bien » n’est vrai qu’à moitié : la passation n’est réellement terminée qu’une fois le travail de « chasser » la connexion de la personne partie hors du flux (remplacer, dans chaque action, par sa propre connexion, puis enregistrer) effectué.

Les dommages collatéraux de licence — le cas de la désactivation au bout de 14 jours

Un flux qui utilise des connecteurs premium fonctionne grâce à la licence de son propriétaire. Selon la FAQ officielle sur les licences, un flux premium qui perd son support de licence — par exemple parce que le propriétaire quitte l’entreprise — est rétrogradé dans un état de performance dégradée, tous les propriétaires sont notifiés, et le flux est désactivé au bout de 14 jours sans intervention.⁴ C’est un comportement à retardement : « ça a un peu ralenti » se transforme en arrêt deux semaines plus tard. Ce problème se pose rarement pour un flux n’utilisant que des connecteurs standard, mais savoir quels flux utilisent des fonctionnalités premium est une information à connaître grâce à l’inventaire (la frontière entre standard et premium est détaillée dans « Les licences Power Automate et la frontière entre connecteurs standard et premium »).

Le problème des e-mails qui continuent d’être envoyés au nom de la personne

Un aspect souvent négligé est le « nom » sous lequel partent les notifications. L’action « Envoyer un e-mail (V2) » envoie depuis la boîte aux lettres de l’utilisateur connecté, donc tant que le flux fonctionne, les e-mails de notification continuent de partir au nom personnel de son créateur. Tant que la personne est en poste, cela se limite à « pourquoi reçoit-on un e-mail de cette personne chaque matin ? », mais après son départ, l’envoi lui-même échoue avec la désactivation du compte. À l’inverse, si un copropriétaire ne remplace que la connexion par la sienne, c’est désormais en son propre nom que partent toutes les notifications.

Les recommandations de Microsoft préconisent d’éviter d’envoyer des notifications formalisées comme relevant du travail sous un nom personnel, et d’utiliser un expéditeur partagé. Avec Outlook, l’action « Envoyer un e-mail depuis une boîte aux lettres partagée (V2) » permet d’envoyer depuis une boîte aux lettres partagée (par exemple noreply-flow@exemple.fr), et l’historique d’envoi reste dans le dossier Éléments envoyés de cette boîte partagée (l’envoi nécessite une autorisation d’accès à la boîte aux lettres). Pour les notifications Teams, les actions du type « Publier en tant que bot de flux » remplissent le même rôle. En complément, ajouter une signature du type « Cet e-mail est envoyé automatiquement par Power Automate. Pour toute question, contactez XX » évite toute confusion côté destinataire, même si la personne en charge change.⁵⁶

4. Ce qu’il faut faire avant le départ, ce que l’on peut faire après le départ

Avant le départ — deux semaines suffisent

Une fois le départ ou la mutation décidé, procédez selon les six étapes suivantes. Voici la vue d’ensemble (les numéros correspondent aux étapes détaillées ci-dessous).

flowchart TD
    Start["Départ ou mutation décidé"] --> S1["① Lister et trier les flux"]
    S1 --> S2["② Ajouter un copropriétaire"]
    S2 --> Q{"Flux compatible<br/>avec les solutions ?"}
    Q -- Oui --> S3a["③ Changer le propriétaire depuis l'écran de détails"]
    Q -- Non --> S3b["③ Ajouter à une solution puis changer<br/>ou reconstruire"]
    S3a --> S4["④ Remplacer les connexions de chaque action"]
    S3b --> S4
    S4 --> S5["⑤ Faire partir les notifications depuis une boîte partagée"]
    S5 --> S6["⑥ Tester le fonctionnement avec le compte de la personne partie désactivé"]

1. Lister et trier les flux. Ouvrez l’écran « Mes flux » avec la personne concernée, et triez-les en « utilisés pour l’activité », « efficacité personnelle » et « résidus d’expérimentation ». C’est le moment le plus efficace pour créer la première version du registre des flux présenté au chapitre 6.
2. Ajouter un copropriétaire. Ajoutez le successeur et la personne responsable du système d’information (ou, à défaut, une personne disposant de droits d’administrateur) comme propriétaires du flux. Un copropriétaire peut consulter l’historique d’exécution, modifier, arrêter ou supprimer le flux, et même ajouter des propriétaires.¹ Notez que l’ajout d’un copropriétaire n’est qu’une mesure minimale d’urgence : la recommandation officielle est de limiter au maximum le partage courant à l’exécution seule (run-only).⁷
3. Transférer la propriété. Pour un flux compatible avec les solutions, vous pouvez changer le propriétaire depuis l’écran de détails du flux, en le remplaçant par le successeur (ou un compte de service). Après le changement, l’ancien et le nouveau propriétaire deviennent tous deux copropriétaires, et les flux à exécution planifiée ou automatique s’exécutent désormais avec la licence du nouveau propriétaire (jusqu’à sept jours pour la prise en compte ; ouvrir puis enregistrer le flux l’applique immédiatement).³ Comme vu au chapitre 2, un flux hors solution ne permet pas de transférer le propriétaire : si l’environnement dispose de Dataverse, ajoutez-le d’abord à une solution avant de changer le propriétaire ; sinon, reconstruisez-le sous le nouveau propriétaire par export/import ou par « Enregistrer sous ».³⁴
4. Remplacer les connexions. Comme vu au chapitre précédent, sauter cette étape signifie que la passation n’est pas terminée. Dans l’écran d’édition du flux, basculez la connexion de chaque action vers une connexion du nouveau compte, puis enregistrez. Retirer la personne partie de la liste des propriétaires nécessite aussi de mettre à jour les connexions qui utilisaient ses identifiants.¹
5. Déplacer l’expéditeur des notifications. Pour les flux utilisant « Envoyer un e-mail (V2) » sous un nom personnel, basculez-les, comme vu au chapitre 3, vers un envoi depuis une boîte aux lettres partagée. Sans cette correction, toutes les notifications partiront au nom du successeur une fois la passation faite.⁵⁶
6. Tester. Si possible, exécutez un cycle complet avec le compte de la personne partie désactivé (ou pendant une période où elle n’intervient pas, comme un congé), pour vérifier que tout fonctionne dans les mêmes conditions qu’après son départ.

Après le départ — ce que l’administrateur peut faire

Même si la personne est déjà partie et qu’il n’y a plus de propriétaire, il existe des solutions.

• Repérer les flux orphelins dans le centre d’administration. La navigation à suivre est la suivante.²

  1. Connectez-vous au centre d’administration Power Platform
  2. Dans le menu de gauche, sous « Environnements » (Environments), sélectionnez l’environnement concerné
  3. Sur la page de détails de l’environnement, ouvrez « Ressources » (Resources) → « Flux » (Flows)
  4. Regardez la colonne « Propriétaires » (Owners) de la liste. Les flux pour lesquels cette colonne est vide sont les flux orphelins

  Autrement dit, le seul objectif sur cet écran est de « chercher les lignes dont la colonne propriétaire est vide ». Dans un environnement comptant beaucoup de flux, il est plus fiable de trier sur cette colonne ou de les extraire de façon systématique avec PowerShell, comme décrit plus loin.

• Ajouter un nouveau propriétaire depuis « Partager ». Sélectionnez le flux concerné dans la liste, ajoutez le compte du nouveau propriétaire depuis « Partager » (Share), puis enregistrez.² Notez que si l’administrateur souhaite aussi modifier le contenu du flux, il doit d’abord s’ajouter lui-même comme propriétaire ou copropriétaire.³
• Traiter en masse avec PowerShell si le nombre est élevé. Le module d’administration (Microsoft.PowerApps.Administration.PowerShell) permet d’énumérer, avec Get-AdminFlow -CreatedBy <ID d'objet de la personne partie>, les flux qu’elle a créés, puis d’accorder le rôle de copropriétaire avec Set-AdminFlowOwnerRole -RoleName CanEdit. Les droits actuels se vérifient avec Get-AdminFlowOwnerRole.²
• Reconstruire les connexions. Après la reprise de la propriété, remplacez les connexions au nom de la personne partie par des connexions du nouveau compte. Si le compte de la personne partie a déjà été supprimé, la connexion d’origine ne peut pas être restaurée : il faut alors créer de nouvelles connexions et les réattribuer à chaque action.¹

À noter, en complément : pour les flux d’approbation en particulier, il existe un autre type de blocage — « une demande en attente d’approbation reste assignée à la personne partie ». La réaffectation côté approbateur et la conception de l’escalade sont traitées aux chapitres 5 et 6 de « Créer un flux d’approbation avec Power Automate », que vous pouvez consulter pour ce sujet.

5. Concevoir le compte d’exécution — compte personnel, compte de service, principal de service

Pour ne pas revivre ce genre de crise de passation, la mesure de fond consiste à décider dès le départ « au nom de qui les flux métier doivent tourner ».

Expliquons d’abord seule la « licence Process » qui apparaît dans le tableau comparatif. Il existe globalement deux grands types de licences Power Automate : la licence utilisateur, attribuée à une « personne », et la licence Process, une licence de capacité attribuée au « flux » lui-même (ou à la machine d’exécution).¹² Attribuée à un flux cloud, elle permet d’utiliser des connecteurs premium et personnalisés indépendamment de la licence dont dispose l’utilisateur propriétaire ou exécutant ce flux (l’attribution suppose que le flux se trouve dans une solution).¹²

Un principal de service n’étant pas une personne, il ne peut pas détenir de licence utilisateur. D’où l’idée que « pour qu’un flux utilisant des fonctionnalités premium soit détenu par un principal de service, il faut attribuer une licence Process côté flux ». À l’inverse, ce n’est pas nécessaire pour un flux qui n’utilise que des connecteurs standard.⁸ La frontière elle-même entre standard et premium est détaillée dans « Les licences Power Automate et la frontière entre connecteurs standard et premium ».

Cela posé, comparons les options.

Voici des repères pratiques pour choisir.

• Pour un outil d’efficacité personnelle, un compte personnel suffit. Vouloir tout gérer avec rigueur finirait par étouffer l’automatisation sur le terrain elle-même.
• Pour un flux métier dont dépend un service, faites au moins partir les notifications depuis une boîte aux lettres partagée⁵, et prévoyez au moins deux copropriétaires. Si vous créez un compte de service pour l’exécution, limitez les autorisations au strict minimum et restreignez l’accès aux identifiants à quelques personnes. Microsoft lui-même recommande le principal de service plutôt qu’un compte de service⁴, mais pour une exploitation de petite ou moyenne échelle centrée sur des connecteurs standard, « un compte dédié avec une gestion rigoureuse du mot de passe » reste souvent la solution réaliste.
• Pour un flux au cœur de l’activité de toute l’entreprise (directement lié aux commandes, à la facturation ou aux paiements), la propriété par principal de service mérite d’être envisagée. Le propriétaire n’étant plus une personne, aucun impact lié à un départ, et l’on évite aussi l’incident où le flux s’arrête suite à la perte de licence d’un propriétaire.⁸ Un principal de service ne peut toutefois pas devenir copropriétaire (seul l’usage comme propriétaire est possible), et une licence Process reste nécessaire pour les fonctionnalités premium : à ce stade, il vaut mieux impliquer le service IT ou un expert externe dans la conception.⁸

Notez que, même en créant un compte de service, il vaut mieux éviter d’y faire passer toute la création de flux et les petites modifications : en gardant la règle « celui qui crée le fait avec son propre compte, et seuls la propriété et l’exécution sont confiées au compte de service », on préserve la traçabilité de « qui a modifié quoi et quand ».

6. Inventaire et documentation — savoir d’abord « ce qui existe »

Le point de départ de toute mesure contre la dépendance à une seule personne consiste, pour l’organisation, à savoir quels flux existent en interne. Comme pour la passation d’un système devenu une boîte noire — où la première étape est l’inventaire des exécutables et des tâches —, il existe une méthode éprouvée pour inventorier les flux.

Obtenir la liste des flux

• Depuis le centre d’administration : en ouvrant « Ressources » → « Flux » sur la page d’environnement du centre d’administration Power Platform, vous obtenez la liste des flux de l’environnement avec leurs propriétaires. C’est aussi ici que l’on repère les flux orphelins.²
• Depuis PowerShell : la cmdlet d’administration Get-AdminFlow renvoie tous les flux des environnements gérés pour un administrateur d’environnement, et tous les flux du locataire pour un administrateur général. Get-AdminFlow | Export-Csv -Path '.\FlowExport.csv' fournit directement une base pour un registre au format CSV, et Get-AdminFlowWithHttpAction permet de ne cibler que les flux utilisant une action HTTP (probablement liés à une intégration externe).⁹ Si vous n’êtes pas à l’aise avec PowerShell, vous pouvez aussi consulter « Les bases des commandes PowerShell — les opérations à connaître d’abord et une utilisation sûre ».

Un registre minimal des flux

Le secret pour que ce registre dure dans le temps, c’est de ne pas trop le sophistiquer. Utilisez une liste SharePoint ou Excel, une ligne par flux, avec uniquement les colonnes suivantes.

Le point important est la colonne « au nom de qui sont les connexions ». Le propriétaire se voit dans l’écran d’administration, mais le nom associé aux connexions ne se découvre qu’en ouvrant le flux : c’est l’information dont la valeur, une fois notée dans le registre, est la plus élevée.

Conventions de nommage et le champ « description »

Les directives de codage de Microsoft recommandent de donner aux composants d’un flux des noms descriptifs et cohérents, de documenter et partager les conventions de nommage, et d’ajouter aux actions des notes équivalentes à des commentaires de code.¹³ En pratique, le simple fait d’harmoniser les noms de flux selon un schéma du type « [Service] Nom de l’activité - Contenu du traitement » (par exemple « [Ventes] Commande par fax - Enregistrement PDF et notification du responsable ») change considérablement la lisibilité de la liste. Par ailleurs, l’écran de détails du flux comporte un champ Description, dont Copilot peut générer une ébauche¹⁴ ; y placer le même contenu que la colonne « Objectif » du registre constitue une assurance pour le jour où le registre deviendra obsolète.

Une fois le registre créé, un problème suivant apparaît : qui remarquera un arrêt dû à une erreur ? La conception des notifications d’échec et des nouvelles tentatives est traitée en détail dans « La gestion des erreurs et la conception des tentatives dans Power Automate ».

7. Environnements et solutions — sortir de la logique « tout dans l’environnement par défaut »

Power Platform dispose d’une notion de cloisonnement appelée « environnement », et tout flux créé sans rien préciser atterrit dans l’environnement par défaut (default environment). Cet environnement par défaut est accessible à tous les utilisateurs du locataire : c’est un endroit où n’importe quel employé disposant d’une licence Microsoft 365 peut créer des applications ou des flux. Cela convient très bien comme terrain de jeu pour la productivité individuelle, mais les recommandations de Microsoft elles-mêmes soulignent que l’environnement par défaut accumule facilement des ressources sans propriétaire suite au départ de leurs créateurs, et que les flux largement partagés ou devenus importants pour l’activité devraient être déplacés vers un environnement dédié.¹⁵

Une PME n’a pas besoin de mettre en place d’emblée une séparation d’environnements complète (développement, test, production). Mais les deux points suivants méritent d’être gardés à l’esprit dès que l’échelle est encore réduite.

• Placer dans une solution les flux entrés dans le cœur de l’activité. Une solution est un contenant permettant de transporter ensemble un flux et ses composants ; un flux placé dedans (flux compatible avec les solutions) permet de changer de propriétaire directement, de gérer les connexions sous forme de « références de connexion » faciles à remplacer, et d’utiliser l’historique de versions.³¹⁰ Comme vu au chapitre 4, la facilité de passation lors d’un départ n’a rien à voir. Son utilisation nécessite un environnement disposant de Dataverse.¹⁰
• Vérifier au moins une fois la politique DLP. Une politique de prévention de la perte de données (DLP), qui classe les connecteurs en usage professionnel / non professionnel et limite leurs combinaisons, constitue un filet de sécurité contre l’accident où un flux sauvage ferait fuiter des données internes vers un service externe.¹⁶ L’approche globale de la gouvernance est abordée au chapitre 9 de « Automatiser les processus métier avec Power Automate ».

La séparation des environnements, l’ALM (le pipeline développement → test → production) et la gouvernance à l’échelle de l’entreprise via le CoE Starter Kit sont des sujets qui viennent ensuite ; il est amplement suffisant de les envisager une fois que les flux se comptent par dizaines. D’abord le registre et la mise en solution, ensuite les environnements.

8. Tableau de décision — à qui appartient ce flux ?

Pour finir, une ligne de partage sur le niveau de gestion à appliquer à chaque flux. Gérer strictement tous les flux n’étant pas réaliste, on les répartit en trois niveaux selon « qui est gêné si le flux s’arrête ».

La façon d’aborder un flux tombé dans ce dernier état est la même que pour la passation d’un système sans code source ni spécifications évoquée en introduction. Plutôt que de le reconstruire d’emblée, on commence par observer le déclencheur, les connexions et les destinations de sortie, pour consigner « ce qu’il fait » dans le registre. Heureusement, contrairement à un EXE sans code source, un flux laisse tout son contenu visible. Il suffit de devenir copropriétaire pour que déchiffrer sa définition ne soit pas particulièrement difficile.

Il y a aussi la question de savoir si ce traitement devrait, en premier lieu, continuer à reposer sur Power Automate. Un flux complexe, qui devient facilement un terreau de dépendance à une seule personne, peut être plus facile à transmettre en le déplaçant vers un script PowerShell, le Planificateur de tâches, ou une fonctionnalité du système métier lui-même, car cela permet de le faire passer par une gestion Git et une revue de code. Ce choix est détaillé dans « Choisir entre Power Automate, PowerShell et le Planificateur de tâches ».

9. Conclusion

• Un flux est lié au compte de son créateur et à ses connexions. Même si le compte disparaît avec le départ, le flux lui-même subsiste, mais l’historique d’exécution est supprimé automatiquement, les actions utilisant une connexion au nom de la personne partie échouent, et un flux premium se désactive après un délai de grâce de 14 jours.¹¹²⁴
• Avant le départ, deux semaines suffisent pour effectuer la passation, dans l’ordre suivant : ajout d’un copropriétaire → (si compatible avec les solutions) changement de propriétaire → remplacement des connexions → passage à une boîte aux lettres partagée pour les notifications.³¹
• Même après le départ, on peut repérer les flux orphelins via « Ressources → Flux » dans le centre d’administration ou via PowerShell (Get-AdminFlow/Set-AdminFlowOwnerRole), et réattribuer un propriétaire. La reconstruction des connexions reste cependant incontournable.²
• La mesure de fond consiste en l’inventaire via un registre des flux, des conventions de nommage et un champ description, le passage des notifications à un expéditeur partagé, et une conception qui détache l’exécution des flux importants d’une personne (compte de service avec prudence, principal de service pour les flux centraux).¹³⁶⁷
• Décider, pour chaque flux, s’il s’agit d’un « outil personnel », d’un « actif d’équipe » ou d’une « infrastructure d’entreprise », et ajuster le niveau de gestion en conséquence : c’est, selon nous, la ligne réaliste pour éviter la dépendance à une seule personne sans pour autant étouffer l’automatisation sur le terrain.

Même si le créateur n’a aucun projet de mutation ou de départ, nous recommandons de suivre une fois, à titre d’« exercice de prévention », les quatre premiers chapitres de cet article. Si vous hésitez sur l’inventaire des flux, la conception de la passation, ou sur la pertinence de continuer à porter un traitement sur Power Automate, n’hésitez pas à nous consulter.

Articles connexes

• Automatiser les processus métier avec Power Automate — Flux cloud, flux de bureau et gestion robuste des erreurs
• Créer un flux d’approbation avec Power Automate — numériser les circuits de validation et de demande sur papier et par e-mail
• Reprendre un système sans code source ni documentation — la procédure pratique pour l’exploiter et le maintenir sans l’arrêter
• La gestion des erreurs et la conception des tentatives dans Power Automate
• Les licences Power Automate et la frontière entre connecteurs standard et premium

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge tout, depuis l’enquête de passation pour une automatisation ou un système métier devenu inaccessible suite au départ ou à la mutation de son responsable, jusqu’à la revue de conception opérationnelle de Power Automate et la systématisation des traitements qui ont dépassé ce qu’un flux peut gérer.

• Conseil technique et revue de conception
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Que devient un flux Power Automate lorsque la personne qui l'a créé quitte l'entreprise ?

Le flux lui-même n'est pas supprimé automatiquement même si le compte de la personne partie est supprimé, et il continue de fonctionner tant qu'il reste un copropriétaire. Cependant, les connexions du flux (l'authentification vers SharePoint, Outlook, etc.) sont liées au compte de la personne qui les a créées, si bien que les actions utilisant la connexion de la personne partie échouent dès que son compte est désactivé ou supprimé. De plus, un flux qui n'a plus aucun propriétaire valide devient un « flux orphelin » ; les flux utilisant des fonctionnalités premium voient leurs performances se dégrader si le propriétaire perd sa licence, et sont désactivés au bout de 14 jours si rien n'est fait. Il est donc essentiel d'ajouter un copropriétaire et de remplacer les connexions avant le départ.

Un administrateur peut-il reprendre un flux créé par une personne déjà partie ?

Oui, c'est possible. Dans le centre d'administration Power Platform, sélectionnez l'environnement puis ouvrez « Ressources » → « Flux » : vous pouvez y repérer les flux orphelins sans propriétaire et ajouter un nouveau propriétaire depuis « Partager ». S'il y a beaucoup de flux, vous pouvez aussi récupérer la liste avec la cmdlet PowerShell d'administration Get-AdminFlow, puis ajouter des copropriétaires en masse avec Set-AdminFlowOwnerRole. Cependant, même après avoir repris la propriété, les connexions au nom de la personne partie ne fonctionnent pas telles quelles : il faut, dans une étape séparée, remplacer la connexion de chaque action du flux par une connexion du nouveau compte.

Ajouter un copropriétaire suffit-il comme mesure contre un départ ?

Ce n'est pas suffisant. Un copropriétaire peut modifier, arrêter le flux et même ajouter des propriétaires, mais il ne peut pas changer les identifiants d'une connexion créée par quelqu'un d'autre, et une connexion partagée ne peut être utilisée qu'à l'intérieur de ce flux. Les actions utilisant la connexion de la personne partie ne continueront de fonctionner que lorsque le copropriétaire les aura remplacées par sa propre connexion. Le problème des e-mails de notification qui continuent d'être envoyés au nom de la personne partie subsiste également, il faut donc penser cela en parallèle d'une conception plus large : faire partir les envois depuis une boîte aux lettres partagée, et orienter les flux critiques pour l'activité vers un compte d'exécution dédié ou une propriété par principal de service.

Faut-il créer un compte de service partagé pour l'exécution des flux ?

C'est une option possible, mais Microsoft ne recommande pas, en tant que bonne pratique, un compte de service consistant à partager un compte utilisateur. Le mot de passe étant partagé entre plusieurs personnes, il devient difficile de savoir qui l'a modifié, et la gestion du mot de passe elle-même devient un risque. Si vous en utilisez un, limitez les autorisations au strict minimum et restreignez le nombre de personnes y ayant accès. Pour les flux critiques pour l'activité, la propriété par principal de service, qui ne dépend d'aucun compte humain, est officiellement recommandée, mais sa configuration nécessite des compétences côté IT, et une licence Process est nécessaire si des fonctionnalités premium sont utilisées.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.