Gouvernance Power Automate avec FlowStudio MCP

Classifiez, étiquetez et gouvernez les flux Power Automate à l'échelle via le magasin en cache de FlowStudio MCP — sans Dataverse, sans CoE Starter Kit, et sans le portail Power Automate.

Cette compétence utilise la même famille d'outils store_* que power-automate-monitoring, mais avec une intention différente : la gouvernance écrit des métadonnées (update_store_flow) et lit pour les résultats d'audit et de classification. La surveillance lit les mêmes outils pour les résultats d'intégrité opérationnelle. Ne cherchez pas à mémoriser quel outil « appartient » à quelle compétence — choisissez selon ce que fait l'utilisateur. Pour les contrôles d'intégrité et les tableaux de bord des taux d'échec, chargez plutôt power-automate-monitoring.

⚠️ Abonnement Pro+ requis. Cette compétence appelle des outils store_* qui ne fonctionnent que pour les abonnés FlowStudio for Teams ou MCP Pro+.

Si l'utilisateur n'a pas accès à Pro+ : le premier appel d'outil store_* retournera une erreur 403/404. Quand cela se produit :

1. CESSEZ d'appeler les outils store
2. Dites à l'utilisateur que les fonctionnalités de gouvernance nécessitent un abonnement Pro+
3. Redirigez-le vers https://mcp.flowstudio.app/pricing

Découverte : chargez les schémas d'outils via les outils méta plutôt que tools/list — appelez tool_search avec query: "skill:governance" pour le groupe canonique, ou query: "select:update_store_flow" pour un outil unique. Cette compétence couvre les motifs de flux et la sémantique des champs — des choses que tool_search ne peut pas vous dire. Si ce document contredit une réponse API réelle, l'API a raison.

Critique : Comment extraire les ID de flux

list_store_flows retourne id au format <environmentId>.<flowId>. Vous devez diviser sur le premier . pour obtenir environmentName et flowName pour tous les autres outils :

id = "Default-<envGuid>.<flowGuid>"
environmentName = "Default-<envGuid>"    (tout avant le premier ".")
flowName = "<flowGuid>"                  (tout après le premier ".")

Aussi : ignorez les entrées sans displayName ou avec state=Deleted — ce sont des enregistrements épars ou des flux qui n'existent plus dans Power Automate. Si un flux supprimé a monitor=true, suggérez de désactiver la surveillance (update_store_flow avec monitor=false) pour libérer un créneau de surveillance (le plan standard en inclut 20).

L'outil d'écriture : update_store_flow

update_store_flow écrit les métadonnées de gouvernance uniquement dans le cache de Flow Studio — il ne modifie PAS le flux dans Power Automate. Ces champs ne sont pas visibles via get_live_flow ou le portail PA. Ils existent uniquement dans le magasin Flow Studio et sont utilisés par le pipeline de balayage et les règles de notification de Flow Studio.

Cela signifie :

• ownerTeam / supportEmail — définit qui Flow Studio considère comme le contact de gouvernance. Ne change PAS le propriétaire réel du flux PA.
• rule_notify_email — définit qui reçoit les notifications d'échec/absence d'exécution de Flow Studio. Ne change PAS les alertes d'échec intégrées de Microsoft.
• monitor / critical / businessImpact — Classification Flow Studio uniquement. Power Automate n'a pas de champs équivalents.

Sémantique de fusion — seuls les champs que vous fournissez sont mis à jour. Retourne l'enregistrement complet mis à jour (même forme que get_store_flow).

Paramètres requis : environmentName, flowName. Tous les autres champs optionnels.

Champs modifiables

Prudence avec security : Le champ security sur get_store_flow contient du JSON structuré (ex. {"triggerRequestAuthenticationType":"All"}). Écrire une simple chaîne comme "reviewed" le remplacera. Pour marquer un flux comme examiné en sécurité, utilisez plutôt tags.

Flux de travail de gouvernance

1. Examen détaillé de la conformité

Identifiez les flux manquant les métadonnées de gouvernance requises — l'équivalent du Centre de conformité des développeurs du CoE Starter Kit.

1. Demandez à l'utilisateur quels champs de conformité il exige
   (ou utilisez la politique de gouvernance existante de son organisation)
2. list_store_flows
3. Pour chaque flux (ignorez les entrées sans displayName ou state=Deleted) :
   - Divisez id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Vérifiez quels champs requis manquent ou sont vides
4. Signalez les flux non conformes avec les champs manquants énumérés
5. Pour chaque flux non conforme :
   - Demandez les valeurs à l'utilisateur
   - update_store_flow(environmentName, flowName, ...champs fournis)

Champs disponibles pour les contrôles de conformité :

Chaque organisation définit ses propres règles de conformité. Les champs ci-dessus sont des suggestions basées sur les motifs courants de gouvernance Power Platform (CoE Starter Kit). Demandez à l'utilisateur quelles sont ses exigences avant de signaler les flux comme non conformes.

Conseil : Les flux créés ou mis à jour via MCP ont déjà description (auto-ajouté par update_live_flow). Les flux créés manuellement dans le portail Power Automate sont ceux qui manquent le plus souvent de métadonnées de gouvernance.

2. Détection de ressources orphelines

Trouvez les flux appartenant à des comptes Azure AD supprimés ou désactivés.

1. list_store_makers
2. Filtrez où deleted=true ET ownerFlowCount > 0
   Note : les créateurs supprimés n'ont PAS displayName/mail — enregistrez leur id (OID AAD)
3. list_store_flows → collectez tous les flux
4. Pour chaque flux (ignorez les entrées sans displayName ou state=Deleted) :
   - Divisez id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Analysez les propriétaires : json.loads(record["owners"])
   - Vérifiez si un principalId de propriétaire correspond à un id de créateur orphelin
5. Signalez les flux orphelins : id du créateur, nom du flux, état du flux
6. Pour chaque flux orphelin :
   - Réaffectez la gouvernance : update_store_flow(environmentName, flowName,
       ownerTeam="NewTeam", supportEmail="new-owner@contoso.com")
   - Ou décommissionnez : set_store_flow_state(environmentName, flowName,
       state="Stopped")

update_store_flow met à jour les métadonnées de gouvernance dans le cache uniquement. Pour transférer la propriété réelle de PA, un administrateur doit utiliser le centre d'administration Power Platform ou PowerShell.

Note : Beaucoup de flux orphelins sont générés par le système (créés par des comptes DataverseSystemUser pour la surveillance SLA, les articles de connaissance, etc.). Ils n'ont jamais été construits par une personne — envisagez de les étiqueter plutôt que de les réaffecter.

Couverture : Ce flux de travail ne recherche que le magasin en cache, pas l'API PA en direct. Les flux créés après le dernier balayage n'apparaîtront pas.

3. Calcul du score d'archivage

Calculez un score d'inactivité (0-7) par flux pour identifier les candidats de nettoyage sûrs. S'aligne avec le scoring d'archivage du CoE Starter Kit.

1. list_store_flows
2. Pour chaque flux (ignorez les entrées sans displayName ou state=Deleted) :
   - Divisez id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
3. Calculez le score d'archivage (0-7), ajoutez 1 point pour chaque :
   +1  lastModifiedTime à moins de 24 heures de createdTime
   +1  displayName contient "test", "demo", "copy", "temp", ou "backup"
       (insensible à la casse)
   +1  createdTime remonte à plus de 12 mois
   +1  state est "Stopped" ou "Suspended"
   +1  json.loads(owners) est un tableau vide []
   +1  runPeriodTotal = 0 (jamais exécuté ou pas d'exécutions récentes)
   +1  parsez json.loads(complexity) → actions < 5
4. Classifiez :
   Score 5-7 : Recommandez l'archivage — signalez à l'utilisateur pour confirmation
   Score 3-4 : Marquez pour examen →
     Lisez les étiquettes existantes de la réponse get_store_flow, ajoutez #archive-review
     update_store_flow(environmentName, flowName, tags="<existing> #archive-review")
   Score 0-2 : Actif, aucune action
5. Pour les archives confirmées par l'utilisateur :
   set_store_flow_state(environmentName, flowName, state="Stopped")
   Lisez les étiquettes existantes, ajoutez #archived
   update_store_flow(environmentName, flowName, tags="<existing> #archived")

Ce qu'« archivage » signifie : Power Automate n'a pas de fonctionnalité d'archivage native. L'archivage via MCP signifie : (1) arrêter le flux pour qu'il ne puisse pas s'exécuter, et (2) l'étiqueter #archived pour qu'il soit découvrable pour un nettoyage futur. La suppression réelle nécessite le portail Power Automate ou PowerShell admin — elle ne peut pas être effectuée via les outils MCP.

4. Audit des connecteurs

Auditez quels connecteurs sont utilisés dans les flux monitorés. Utile pour l'analyse d'impact DLP et la planification des licences premium.

1. list_store_flows(monitor=true)
   (limitez aux flux monitorés — auditer tous les 1000+ flux est coûteux)
2. Pour chaque flux (ignorez les entrées sans displayName ou state=Deleted) :
   - Divisez id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Analysez les connexions : json.loads(record["connections"])
     Retourne un tableau d'objets avec apiName, apiId, connectionName
   - Notez le champ tier au niveau du flux ("Standard" ou "Premium")
3. Construisez l'inventaire des connecteurs :
   - Quels apiNames sont utilisés et par combien de flux
   - Quels flux ont tier="Premium" (connecteur premium détecté)
   - Quels flux utilisent des connecteurs HTTP (apiName contient "http")
   - Quels flux utilisent des connecteurs personnalisés (apiNames sans préfixe shared_)
4. Signalez l'inventaire à l'utilisateur
   - Pour l'analyse DLP : l'utilisateur fournit ses groupes de connecteurs de politique DLP,
     l'agent référence croisée avec l'inventaire

Limitez aux flux monitorés. Chaque flux nécessite un appel get_store_flow pour lire le JSON connections. Les plans standard ont environ 20 flux monitorés — gérables. Auditer tous les flux dans un grand tenant (1000+) serait très coûteux en appels API.

list_store_connections retourne les instances de connexion (qui a créé quelle connexion) mais PAS les types de connecteurs par flux. Utilisez-le pour les comptages de connexions par environnement, pas pour l'audit des connecteurs.

Les définitions des politiques DLP ne sont pas disponibles via MCP. L'agent construit l'inventaire des connecteurs ; l'utilisateur fournit la classification DLP pour référence croisée.

5. Gestion des règles de notification

Configurez la surveillance et les alertes pour les flux à l'échelle.

Activez les alertes d'échec sur tous les flux critiques :
1. list_store_flows(monitor=true)
2. Pour chaque flux (ignorez les entrées sans displayName ou state=Deleted) :
   - Divisez id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Si critical=true ET rule_notify_onfail n'est pas true :
     update_store_flow(environmentName, flowName,
       rule_notify_onfail=true,
       rule_notify_email="oncall@contoso.com")
   - Si AUCUN flux n'a critical=true : c'est un constat de gouvernance.
     Recommandez à l'utilisateur de désigner ses flux les plus importants comme critiques
     en utilisant update_store_flow(critical=true) avant de configurer les alertes.

Activez la détection d'absence d'exécution pour les flux planifiés :
1. list_store_flows(monitor=true)
2. Pour chaque flux où triggerType="Recurrence" (disponible sur la réponse de liste) :
   - Ignorez les flux avec state="Stopped" ou "Suspended" (ne sont pas censés s'exécuter)
   - Divisez id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Si rule_notify_onmissingdays est 0 ou non défini :
     update_store_flow(environmentName, flowName,
       rule_notify_onmissingdays=2)

critical, rule_notify_onfail, et rule_notify_onmissingdays sont disponibles uniquement depuis get_store_flow, pas depuis list_store_flows. L'appel de liste pré-filtre vers les flux monitorés ; l'appel de détail vérifie les champs de notification.

Limite de surveillance : Le plan standard (FlowStudio for Teams / MCP Pro+) inclut 20 flux monitorés. Avant d'activer en masse monitor=true, vérifiez combien de flux sont déjà monitorés : len(list_store_flows(monitor=true))

6. Classification et étiquetage

Classifiez en masse les flux par type de connecteur, fonction métier ou niveau de risque.

Auto-étiquetez par connecteur :
1. list_store_flows
2. Pour chaque flux (ignorez les entrées sans displayName ou state=Deleted) :
   - Divisez id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Analysez les connexions : json.loads(record["connections"])
   - Construisez les étiquettes à partir des valeurs apiName :
     shared_sharepointonline → #sharepoint
     shared_teams → #teams
     shared_office365 → #email
     Connecteurs personnalisés → #custom-connector
     Connecteurs liés à HTTP → #http-external
   - Lisez les étiquettes existantes de la réponse get_store_flow, ajoutez les nouvelles
   - update_store_flow(environmentName, flowName,
       tags="<existing tags> #sharepoint #teams")

Deux systèmes d'étiquettes : Les étiquettes affichées dans list_store_flows sont extraites automatiquement du champ description du flux (ex. un créateur écrit #operations dans la description du portail PA). Les étiquettes définies via update_store_flow(tags=...) écrivent dans un champ distinct du cache Azure Table. Elles sont indépendantes — écrire des étiquettes de magasin ne touche pas à la description, et éditer la description dans le portail n'affecte pas les étiquettes de magasin.

Fusion d'étiquettes : update_store_flow(tags=...) remplace le champ des étiquettes de magasin. Pour éviter de perdre les étiquettes d'autres flux de travail, lisez d'abord les étiquettes de magasin actuelles depuis get_store_flow, ajoutez les nouvelles, puis réécrire.

get_store_flow a déjà un champ tier (Standard/Premium) calculé par le pipeline de balayage. N'utilisez update_store_flow(tier=...) que si vous devez le remplacer.

7. Offboarding des créateurs

Quand un employé quitte l'entreprise, identifiez ses flux et applications, et réaffectez les contacts de gouvernance et les destinataires de notification de Flow Studio.

1. get_store_maker(makerKey="<departing-user-aad-oid>")
   → vérifiez ownerFlowCount, ownerAppCount, deleted status
2. list_store_flows → collectez tous les flux
3. Pour chaque flux (ignorez les entrées sans displayName ou state=Deleted) :
   - Divisez id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Analysez les propriétaires : json.loads(record["owners"])
   - Si un principalId correspond à l'OID de l'utilisateur qui part → signalez
4. list_store_power_apps → filtrez où ownerId correspond à l'OID
5. Pour chaque flux signalé :
   - Vérifiez runPeriodTotal et runLast — est-il encore actif ?
   - Si conservation :
     update_store_flow(environmentName, flowName,
       ownerTeam="NewTeam", supportEmail="new-owner@contoso.com")
   - Si décommissionnement :
     set_store_flow_state(environmentName, flowName, state="Stopped")
     Lisez les étiquettes existantes, ajoutez #decommissioned
     update_store_flow(environmentName, flowName, tags="<existing> #decommissioned")
6. Signalez : flux réaffectés, flux arrêtés, applications nécessitant réaffectation manuelle

Ce que « réaffecter » signifie ici : update_store_flow change qui Flow Studio considère comme le contact de gouvernance et qui reçoit les notifications de Flow Studio. Cela ne transfère PAS la propriété réelle du flux Power Automate — cela nécessite le centre d'administration Power Platform ou PowerShell. Mettez aussi à jour rule_notify_email pour que les notifications d'échec aillent à la nouvelle équipe au lieu de l'email de l'employé qui part.

La propriété Power Apps ne peut pas être modifiée via les outils MCP. Signalez-les pour réaffectation manuelle dans le centre d'administration Power Apps.

8. Examen de sécurité

Révisez les flux pour des préoccupations de sécurité potentielles en utilisant les données du magasin en cache.

1. list_store_flows(monitor=true)
2. Pour chaque flux (ignorez les entrées sans displayName ou state=Deleted) :
   - Divisez id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Analysez la sécurité : json.loads(record["security"])
   - Analysez les connexions : json.loads(record["connections"])
   - Lisez sharingType directement (champ de niveau supérieur, PAS à l'intérieur du JSON security)
3. Signalez les résultats à l'utilisateur pour examen
4. Pour les flux examinés :
   Lisez les étiquettes existantes, ajoutez #security-reviewed
   update_store_flow(environmentName, flowName, tags="<existing> #security-reviewed")
   Ne remplacez PAS le champ security — il contient des données d'authentification structurées

Champs disponibles pour l'examen de sécurité :

Chaque organisation décide de ce qui constitue une préoccupation de sécurité. Par exemple, un déclencheur HTTP non authentifié est attendu pour les récepteurs webhook (Stripe, GitHub) mais peut être un risque pour les flux internes. Examinez les résultats dans le contexte avant de signaler.

9. Gouvernance d'environnement

Auditez les environnements pour la conformité et l'éparpillement.

1. list_store_environments
   Ignorez les entrées sans displayName (lignes de métadonnées au niveau du tenant)
2. Signalez :
   - Environnements de développement (sku="Developer") — devraient être limités
   - Environnements non gérés (isManagedEnvironment=false) — moins de gouvernance
   - Note : isAdmin=false signifie que le compte de service actuel n'a pas d'accès admin
     à cet environnement, pas que l'environnement n'a pas d'admin
3. list_store_flows → groupez par environmentName
   - Comptage des flux par environnement
   - Analyse des taux d'échec : runPeriodFailRate est sur la réponse de liste —
     pas besoin d'appels get_store_flow par flux
4. list_store_connections → groupez par environmentName
   - Comptage des connexions par environnement

10. Tableau de bord de gouvernance

Générez un résumé de gouvernance au niveau du tenant.

Métriques efficaces (appels de liste uniquement) :
1. total_flows = len(list_store_flows())
2. monitored = len(list_store_flows(monitor=true))
3. with_onfail = len(list_store_flows(rule_notify_onfail=true))
4. makers = list_store_makers()
   → active = comptage où deleted=false
   → orphan_count = comptage où deleted=true ET ownerFlowCount > 0
5. apps = list_store_power_apps()
   → widely_shared = comptage où sharedUsersCount > 3
6. envs = list_store_environments() → comptage, groupez par sku
7. conns = list_store_connections() → comptage

Calculez à partir des données de liste :
- % de surveillance : monitored / total_flows
- % de notification : with_onfail / monitored
- Comptage des orphelins : de l'étape 4
- Comptage à haut risque : flux avec runPeriodFailRate > 0,2 (sur réponse de liste)

Métriques détaillées (nécessitent get_store_flow par flux — coûteux pour les grands tenants) :
- % de conformité : flux avec businessImpact défini / total des flux actifs
- Comptage non documenté : flux sans description
- Répartition par tier : groupez par champ tier

Pour les métriques détaillées, itérez tous les flux en un seul passage :
  Pour chaque flux de list_store_flows (ignorez les entrées éparses) :
    Divisez id → environmentName, flowName
    get_store_flow(environmentName, flowName)
    → accumulez businessImpact, description, tier

Référence des champs : champs get_store_flow utilisés dans la gouvernance

Tous les champs ci-dessous sont confirmés présents sur la réponse get_store_flow. Les champs marqués avec * sont aussi disponibles sur list_store_flows (moins cher).

Compétences liées

• power-automate-monitoring — Contrôles de santé, taux d'échec, inventaire (lecture seule)
• power-automate-mcp — Compétence fondationnelle : configuration de connexion, assistance MCP, découverte d'outils
• power-automate-debug — Diagnostic approfondi avec entrées/sorties au niveau des actions
• power-automate-build — Construire et déployer des définitions de flux