Gouvernance Power Platform : le guide pratique pour la DSI

Gouvernance Power Platform : environnements, stratégies de données (DLP), centre d'administration, ALM et rôles. La démarche pour un déploiement maîtrisé.

La gouvernance Power Platform repose sur cinq leviers : une stratégie d’environnements qui sépare expérimentation, développement et production ; des stratégies de données (anciennement DLP) qui encadrent les connecteurs ; le centre d’administration Power Platform pour l’inventaire et la supervision ; une démarche ALM fondée sur les solutions ; et des rôles clairement attribués. L’objectif n’est pas de freiner les créateurs, mais de leur offrir un cadre sûr dans lequel ils peuvent avancer vite.

Pourquoi la DSI doit s’emparer du sujet

La Power Platform (Power Apps, Power Automate, Power BI, Power Pages, Copilot Studio, avec Dataverse comme socle de données) est accessible à la plupart des utilisateurs Microsoft 365. C’est sa force : les métiers construisent eux-mêmes leurs applications et leurs automatisations. C’est aussi un risque, si rien n’est cadré :

  • des flux qui envoient des données d’entreprise vers des services personnels ;
  • des applications critiques qui reposent sur le compte d’un seul salarié ;
  • des centaines de ressources dont personne ne connaît le propriétaire ni l’usage.

Interdire ne fonctionne pas : les besoins se reportent vers des outils non maîtrisés. La bonne posture est celle d’un cadre permissif mais surveillé. Si vous avez besoin de clarifier le périmètre, lisez d’abord Qu’est-ce que la Power Platform ?.

Les environnements : la première brique de la gouvernance

Un environnement est un conteneur qui regroupe des applications, des flux, des agents, des connexions et, éventuellement, une base Dataverse. Il est rattaché à une région géographique, et une application ne peut utiliser que les ressources de son propre environnement.

Les types d’environnements

Type Usage Point d’attention
Par défaut Productivité personnelle, essais Tous les utilisateurs disposant d’une licence y sont créateurs. Il ne peut pas être supprimé.
Production Applications dont l’activité dépend Contrôle complet, sauvegardes
Bac à sable (Sandbox) Développement et tests Copie et réinitialisation possibles
Développeur Espace individuel d’un développeur Réservé à son propriétaire
Évaluation (Trial) Test de courte durée Expire automatiquement
Dataverse for Teams Applications créées dans Teams Paramétrage limité

La stratégie recommandée

  1. Requalifier l’environnement par défaut en espace de productivité personnelle. Microsoft suggère même de le renommer (par exemple « Productivité personnelle ») pour clarifier son rôle. Rien de critique ne doit y vivre.
  2. Créer des environnements dédiés pour les projets importants, avec au minimum un trio développement, test et production.
  3. Restreindre la création d’environnements aux administrateurs, avec une procédure de demande simple.
  4. Regrouper les environnements par service ou par niveau de criticité avec les groupes d’environnements, pour leur appliquer les mêmes règles.

Deux rôles intégrés structurent l’accès à chaque environnement : Administrateur d’environnement (gestion complète) et Créateur d’environnement (création d’applications, de flux et de connexions). Lorsqu’une base Dataverse existe, l’accès aux données passe en plus par des rôles de sécurité Dataverse.

Les stratégies de données (DLP) : encadrer les connecteurs

Les connecteurs sont la porte d’entrée vers les données : SharePoint, Outlook, SQL Server, mais aussi Gmail ou Dropbox. Les stratégies de données (data policies, longtemps appelées stratégies DLP) classent chaque connecteur dans l’un de trois groupes :

  • Professionnel (Business) : les services qui hébergent des données d’entreprise ;
  • Non professionnel (Non-Business) : les services à usage personnel ;
  • Bloqué (Blocked) : les connecteurs interdits.

La règle centrale : une application ou un flux ne peut pas combiner des connecteurs de groupes différents. Si SharePoint est classé « Professionnel » et Gmail « Non professionnel », personne ne pourra créer un flux qui copie une liste SharePoint vers une boîte Gmail.

Quelques points à connaître :

  • À la création d’une stratégie, tous les connecteurs sont placés en Non professionnel, et les nouveaux connecteurs publiés par Microsoft y arrivent aussi. Microsoft recommande de conserver ce groupe par défaut, puis de reclasser chaque connecteur après évaluation.
  • Certains connecteurs essentiels ne peuvent pas être bloqués par une stratégie de données : SharePoint, Teams, Outlook, OneDrive Entreprise, Dataverse ou Approbations, entre autres. Ils peuvent seulement être classés en professionnel ou non professionnel. Les stratégies de connecteurs avancées, fondées sur une liste d’autorisation, permettent d’aller plus loin.
  • Les connecteurs HTTP méritent une attention particulière : ils permettent d’appeler n’importe quel service web.
  • Une modification de stratégie s’applique en général en moins d’une heure, jusqu’à 24 heures sur les très gros tenants. Les applications et flux non conformes sont alors suspendus : prévenez les créateurs avant de durcir une stratégie.

Une approche éprouvée : une stratégie stricte à l’échelle du tenant, qui s’applique notamment à l’environnement par défaut, puis des stratégies plus ouvertes sur les environnements dédiés aux projets validés.

Le centre d’administration Power Platform

Le centre d’administration Power Platform (admin.powerplatform.microsoft.com) est le poste de pilotage de la DSI. Environnements, stratégies de données, capacité de stockage, licences : tout s’y gère.

Le CoE Starter Kit est-il encore d’actualité ?

Pendant des années, le CoE Starter Kit (Center of Excellence) a été l’outil de référence pour inventorier les ressources et outiller la gouvernance. Microsoft indique désormais qu’il n’est plus activement maintenu : il reste disponible, mais ne reçoit plus de nouvelles fonctionnalités, et les anomalies signalées ne sont plus traitées. Ses fonctions principales ont été intégrées au centre d’administration :

  • Inventaire : toutes les applications, flux et agents du tenant, avec leurs propriétaires ;
  • Utilisation : suivi de l’adoption et des ressources les plus utilisées ;
  • Surveillance (Monitor) : santé opérationnelle des ressources critiques ;
  • Actions : recommandations pour repérer les risques et appliquer les bonnes pratiques.

Pour un nouveau déploiement, partez donc des fonctions natives du centre d’administration plutôt que d’installer le kit.

Les environnements gérés

Les environnements gérés (Managed Environments) ajoutent une couche de contrôle : limitation du partage des applications, rapport hebdomadaire d’utilisation, vérificateur de solutions obligatoire, message d’accueil pour les créateurs, pipelines de déploiement, pare-feu IP, etc. Ils sont inclus dans les licences autonomes Power Apps, Power Automate, Copilot Studio, Power Pages et Dynamics 365 : vérifiez que les utilisateurs concernés en disposent.

ALM : passer de l’application bricolée à l’application maîtrisée

L’ALM (Application Lifecycle Management) organise le cycle de vie : développement, test, mise en production, évolutions. Sur la Power Platform, elle repose sur les solutions, des conteneurs qui regroupent applications, flux, tables, agents et autres composants pour les déplacer d’un environnement à l’autre. Tous les environnements concernés doivent disposer d’une base Dataverse.

Les bonnes pratiques :

  1. Développer dans une solution, jamais directement hors solution.
  2. Déployer en version gérée (managed) dans les environnements de test et de production, pour éviter les modifications directes.
  3. Utiliser des variables d’environnement (URL d’un site SharePoint, adresse de notification) et des références de connexion, pour qu’une même solution fonctionne d’un environnement à l’autre sans modification.
  4. Automatiser les déploiements avec les pipelines Power Platform, intégrés au produit, ou avec une chaîne CI/CD comme Azure DevOps.
  5. Versionner les solutions dans un contrôle de code source pour les projets critiques.

Le choix de la source de données pèse aussi dans la gouvernance : voyez SharePoint ou Dataverse : quelle base de données pour vos applications ?.

Qui fait quoi ? Les rôles de la gouvernance

Rôle Responsabilités
Administrateur Power Platform (rôle Microsoft Entra) Environnements, stratégies de données, capacité, supervision globale
Administrateur d’environnement Accès, paramètres et ressources d’un environnement
Équipe CoE / plateforme Règles, accompagnement des créateurs, revue des projets critiques
Créateurs (makers) Conception des applications, flux et agents dans le cadre fixé
Propriétaire métier Validation du besoin, responsabilité de l’application en production

Dans une PME, une même personne cumule souvent plusieurs rôles. L’important est que chacun soit nommé, y compris un suppléant pour chaque application critique.

La démarche pour un déploiement maîtrisé

  1. Faire l’état des lieux avec l’inventaire du centre d’administration : quels environnements, quelles applications, quels propriétaires, quels connecteurs ?
  2. Sécuriser l’environnement par défaut : stratégie de données stricte, renommage, communication aux utilisateurs.
  3. Définir la stratégie d’environnements et la procédure de demande d’un nouvel environnement.
  4. Classer les connecteurs en concertation avec la sécurité et les métiers.
  5. Fixer les règles ALM pour tout ce qui part en production.
  6. Accompagner les créateurs : charte, modèles, communauté interne, formation.
  7. Superviser et ajuster chaque trimestre à partir des données d’utilisation.

Les agents Copilot Studio entrent dans le même cadre : environnements, stratégies de données et canaux de publication s’appliquent aussi à eux. Notre article Copilot Studio : créer un agent pas à pas montre où ces règles interviennent.

Former les équipes qui construisent

Une gouvernance efficace suppose des créateurs qui comprennent les solutions, les environnements et les bonnes pratiques de conception. Notre Parcours — Développeur d’applications Power Platform couvre ces sujets sur des cas concrets. Nos experts l’animent à distance ou en intra dans vos locaux.

Questions fréquentes

Quelle différence entre DLP et stratégie de données ?

Aucune sur le fond : Microsoft appelle désormais data policies (stratégies de données) ce que l’on désignait comme stratégies DLP (Data Loss Prevention). Le principe reste le même : classer les connecteurs pour empêcher certaines combinaisons et bloquer les services non autorisés.

Faut-il bloquer l’environnement par défaut ?

Non, on ne peut d’ailleurs pas le supprimer. Il faut le cantonner à la productivité personnelle : stratégie de données stricte, aucune application critique, et un environnement dédié pour tout projet qui grandit.

Le CoE Starter Kit est-il obsolète ?

Il reste disponible, mais Microsoft ne le fait plus évoluer et ne traite plus les anomalies signalées. Ses fonctions principales (inventaire, utilisation, surveillance, recommandations) sont désormais intégrées au centre d’administration Power Platform, à privilégier pour tout nouveau déploiement.

Faut-il Dataverse pour faire de l’ALM ?

Oui. Les solutions, les pipelines et les outils ALM de la Power Platform s’appuient sur Dataverse : chaque environnement qui participe au cycle de vie doit disposer d’une base Dataverse.