Qui est propriétaire de vos applications Power Apps ?

La question paraît administrative jusqu'au jour où elle devient urgente : un flux automatisé s'arrête un vendredi soir, et l'on découvre qu'il s'exécutait sous le compte d'un collaborateur parti huit mois plus tôt. Rien n'avait cassé à son départ, parce que le compte était resté actif jusqu'à ce qu'un nettoyage de routine le supprime.

Ce n'est pas un défaut de Power Platform ; c'est la conséquence normale d'une plateforme conçue pour que chacun puisse construire. Le coût n'apparaît sur aucune facture — il apparaît le jour où il vous faut une réponse rapide et où vous ne l'avez pas.

Pourquoi la propriété se perd

Chaque application et chaque flux a un propriétaire, par défaut la personne qui l'a créé. C'est cohérent le premier jour, puis cela s'érode :

• Le collaborateur change de service et reste propriétaire d'une application dont il ne sait plus rien.
• Le collaborateur part, son compte est désactivé puis supprimé, comme le décrit la documentation sur la révocation des accès.
• L'application est partagée avec un groupe : tout le monde s'en sert, plus personne n'en est réellement responsable.
• Le flux s'exécute via une connexion rattachée à un compte nominatif plutôt qu'à une identité de service.

Ce dernier point est le plus dangereux. Le flux ne tombe pas au départ de son auteur — il tombe à la révocation des informations d'identification de la connexion, ce qui peut survenir des mois plus tard. Cause et effet sont séparés par assez de temps pour que le lien entre les deux se perde.

Les environnements démultiplient le problème

Un environnement se crée en quelques clics, et c'est l'unité à laquelle s'appliquent la sécurité, la capacité et les stratégies de prévention des pertes de données, comme l'explique la vue d'ensemble des environnements. Un tenant comptant vingt environnements n'a pas vingt dossiers : il a vingt frontières de sécurité distinctes.

Une application sensible hébergée dans un environnement d'essai créé il y a deux ans pour un test rapide n'est pas un cas rare ; c'est le cas courant.

Ce que l'inventaire doit contenir

1. Chaque environnement : son type, son administrateur, la présence ou non d'une base Dataverse.
2. Chaque application : propriétaire, date de dernière exécution, nombre d'utilisateurs. Une application non ouverte depuis un an relève de l'archivage, pas de la maintenance.
3. Chaque flux : propriétaire et état de ses connexions. Les flux désactivés comptent plus que les actifs — l'un d'eux s'est arrêté sans que personne ne le remarque.
4. Les propriétaires qui ne font plus partie de l'organisation : c'est la liste qui répond à la question urgente.

Les modules PowerShell pour administrateurs Power Platform permettent d'extraire tout cela, et une connexion par principal de service rend l'opération planifiable plutôt que dépendante du compte de quelqu'un. Mais le travail long reste le rapprochement des résultats entre eux — et avec l'annuaire des collaborateurs présents.

Que faire une fois l'inventaire établi

La tentation est de réattribuer l'ensemble à un unique compte d'administration. Cela règle une panne et en prépare une autre : une boîte de réception qui reçoit toutes les alertes de la plateforme, et une propriété nominale qui n'emporte aucune responsabilité réelle.

Préférez : ajouter un copropriétaire issu de l'équipe métier pour ce qui est réellement utilisé, basculer les flux critiques sur des connexions à identité de service, archiver ce qui n'a pas servi depuis un an, et laisser une trace écrite de ce que vous avez décidé de conserver.

Obtenir l'inventaire

Power Insights recense environnements, applications, flux, connexions et propriétaires en une seule analyse, signale ceux qui ne font plus partie de l'organisation, et met en avant les flux désactivés, les applications dormantes et les environnements sans administrateur — dans un rapport directement transmissible.

L'outil fonctionne en lecture seule : il lit les métadonnées, jamais les données contenues dans les applications.

À lire également : ce qui est codé en dur dans vos cinquante applications et les dépendances qu'une migration inter-tenant révèle.