Transférer proprement les flux, les Power Apps et les connexions lors du départ d'un collaborateur : la checklist Power Platform pour avant et après.
Quand une collaboratrice ou un collaborateur démissionne, la plupart des processus d'offboarding pour le portable, la boîte mail et le badge d'accès se déroulent sans accroc. Ce qui passe presque toujours à travers les mailles du filet : les flux, les Power Apps et les connexions que cette personne a construits dans la Power Platform. Un flux qui classe chaque matin des factures d'une boîte mail vers SharePoint ne remarque pas immédiatement que son propriétaire n'existe plus. Il continue simplement de fonctionner jusqu'à ce qu'une connexion expire ou qu'une licence soit retirée, et alors toute l'équipe se retrouve soudain face à un processus à l'arrêt, sans aucune explication.
Cette checklist est pensée comme un lead asset : un document que tu parcours simplement lors du prochain départ, au lieu de devoir réfléchir à chaque fois à l'endroit où se trouvent les traces d'une personne dans la Power Platform. Elle complète notre article sur Solutions in Power Automate, qui explique pourquoi seuls les flux d'une solution peuvent réellement être transférés proprement. Ici, il s'agit de l'angle prévention : ce que tu vérifies concrètement avant, pendant et après le dernier jour de travail pour que tes collaborateurs numériques continuent de fonctionner, peu importe qui quitte l'entreprise.
Dans la plupart des entreprises, les flux et les Power Apps ne sont recensés dans aucun inventaire central. Ils naissent de façon décentralisée, souvent créés par une seule personne qui voulait automatiser une tâche récurrente. C'est exactement ce qui les rend invisibles lors de l'offboarding : personne à l'IT ne sait qu'un flux existe, jusqu'à ce qu'il tombe soudain en échec après le départ de la personne qui l'a créé.
Selon la documentation officielle sur le Changement de propriétaire d'un flux cloud, lors de la création d'un flux, la personne qui le crée devient automatiquement propriétaire. Ce rôle détermine les droits de modification, les partages, l'historique d'exécution et parfois même la licence utilisée. Si cette personne quitte l'entreprise sans transfert préalable, le flux devient ce que Microsoft appelle un flux orphelin : une automatisation sans propriétaire valide, dont les connexions peuvent défaillir à tout moment.
Le principe le plus important d'abord : tout ce qui peut être réglé avant le départ est plus simple que tout ce qui doit être rattrapé après. Tant que la personne a encore accès, tu peux travailler avec elle au lieu de devoir reconstituer, en tant qu'administrateur, ce qui existe réellement après coup.
Tous les départs ne laissent pas assez de délai pour tout régler à l'avance. Si la personne est déjà partie, tu as besoin du point de vue de l'administrateur.
Get-AdminFlow et Set-AdminFlowOwnerRole, au lieu de cliquer sur chaque flux individuellement.Une idée reçue fréquente est qu'un flux s'arrête immédiatement lorsque la personne propriétaire quitte l'entreprise. En réalité, selon la documentation sur les flux d'équipe, un flux partagé continue simplement de fonctionner pour l'instant, tant qu'il a encore un propriétaire actif, par exemple un copropriétaire. Ce n'est que lorsqu'il n'existe plus aucun propriétaire actif qu'un transfert devient impératif.
La situation devient plus critique du côté de la licence. Selon la FAQ sur les licences Power Automate, un flux premium dont le propriétaire n'a plus de licence premium valide est d'abord rétrogradé à une capacité inférieure. Tous les propriétaires sont notifiés, et si la situation reste non résolue, Power Automate désactive complètement le flux après 14 jours. Dans la pratique, ces deux semaines sont la véritable fenêtre de temps dont tu disposes pour un transfert ordonné, avant qu'une automatisation en production ne tombe en panne sans avertissement.
La prévention la plus fiable n'est pas du tout une action d'offboarding, mais une règle qui s'applique déjà dès la construction d'un flux : chaque flux et chaque appli utilisés en production reçoivent dès le départ au moins une deuxième personne comme copropriétaire. Ainsi, lors d'un départ réel, il ne reste plus qu'à retirer le propriétaire d'origine, au lieu de devoir en chercher un nouveau dans l'urgence. Combiner cette règle avec une structure de gouvernance légère, comme le décrit notre article sur CoE light pour 30 collaborateurs et limiter en plus l'accès aux groupes de connecteurs sensibles via les Politiques DLP pour débutants, réduit nettement le risque d'un flux orphelin dès le départ.
Si tu ne veux pas entretenir cette checklist manuellement, mais l'ancrer durablement comme un élément fixe de ton propre processus d'offboarding, tu trouveras auprès du conseil Power Automate de NordFlux un accompagnement pour mettre en place proprement, dès le départ, la gouvernance et la prévention. Tu gardes ainsi le contrôle sur tes automatisations, même quand les équipes changent.
Un flux sans copropriétaire a encore un propriétaire valide et actif et continue de fonctionner normalement. Ce n'est que lorsque cet unique propriétaire quitte l'organisation et que personne ne reprend le rôle que le flux est considéré comme orphelin, c'est-à-dire sans propriétaire valide. C'est exactement pour cela qu'un copropriétaire est la prévention la plus simple : il empêche un flux de tomber, tout simplement, dans l'état orphelin.
Non, pas directement. Selon la documentation, un administrateur doit d'abord s'ajouter lui-même comme propriétaire ou copropriétaire avant de pouvoir apporter des modifications à un flux qui ne lui appartient pas. Dans le Power Platform Admin Center, cela se fait via la fonction Partager sur la page de détail du flux concerné : tu y saisis ton propre nom comme nouveau propriétaire et enregistres la modification.
Contrairement aux flux autonomes, les flux compatibles avec les solutions peuvent être transférés directement à une nouvelle personne depuis la vue d'édition, sans export ni import. Une fois le transfert terminé, l'ancien et le nouveau propriétaire deviennent automatiquement copropriétaires communs, de sorte que tous deux conservent l'accès à l'historique d'exécution et aux références de connexion. Tu trouveras plus de détails à ce sujet dans l'article lié sur Solutions in Power Automate.
Après la suppression dans le centre d'administration Microsoft 365, cela peut prendre, selon la documentation officielle, entre 30 minutes et 6 heures avant que le statut ne bascule sur désactivé dans les environnements Power Platform concernés. Si tu ne veux pas accepter ce délai d'attente, tu peux vérifier et accélérer le statut manuellement via le diagnostic utilisateur dans le centre d'administration.
Non, cela ne suffit pas et crée plutôt de nouveaux problèmes. Si tu supprimes seulement la connexion, le flux reste malgré tout lié à la personne partie en tant que propriétaire et tourne dans le vide sans connexion fonctionnelle. Le bon ordre est l'inverse : d'abord transférer le propriétaire à une personne active, puis mettre à jour les connexions concernées avec les identifiants de cette nouvelle personne.
Fondateur de NordFlux. Sept ans d'expérience, du web et du SEO jusqu'à l'automatisation à l'échelle d'un groupe, aujourd'hui pragmatique pour les PME et avec une souveraineté des données allemande.
Certifications
Chaque utilisateur M365 atterrit automatiquement dans l'environnement par défaut de la Power Platform, souvent avec une protection DLP minimale. Voici comment combler cette lacune.
Power Automate ou Power Apps ? Voici comment décider, à l'aide de critères officiels de Microsoft, si ton processus a besoin d'un flow ou d'une application.
Lorsqu'un propriétaire de flow quitte l'entreprise, un offboarding oublié met en danger les processus automatisés et l'accès aux connexions sensibles. Nous mettons en place des structures de copropriété et un processus d'offboarding fiable pour votre Power Platform, avant que le prochain départ ne devienne un problème. Vos flows et Power Apps restent ainsi sous contrôle, même en cas de changement de personnel.