Environnements Power Platform : dev, test et prod

1Étape 1 : Créer les trois environnements

Ouvrez le Centre d'administration Power Platform, puis Manage > Environments > New. Créez un environnement par étape du cycle de vie : par exemple App-Dev et App-Test en type Sandbox, App-Prod en type Production.

Pour chacun, répondez Yes à Add a Dataverse data store : les solutions, les variables d'environnement et Pipelines en ont besoin. Ce choix ne peut pas être annulé. Choisissez la même région pour les trois et associez un groupe de sécurité.

Un environnement de type Developer reste possible pour développer. À partir du 15 novembre 2026, seul le développeur géré pourra être créé, à raison d'un par utilisateur, et il faut une licence premium pour y exécuter apps et flux.

Vérification : La page Environments liste les trois environnements avec leur type, leur région et une URL Dataverse.

2Étape 2 : Créer l'éditeur et la solution dans l'environnement de dev

Dans Power Apps, sélectionnez l'environnement de dev, puis Solutions > New solution. Sous Publisher, choisissez New publisher et renseignez Display Name, Name et Prefix (par exemple nmr). Le préfixe précède le nom de chaque table et colonne créée.

Fixez le préfixe avant de créer le moindre composant : le nom d'un élément de métadonnées ne change plus après sa création. Utilisez un seul éditeur pour toutes vos solutions.

Cochez Set as your preferred solution. Les composants créés hors contexte de solution y atterriront au lieu de la solution par défaut.

Vérification : Dans Solutions, la nouvelle solution apparaît en type non géré avec votre éditeur, et une table créée dedans porte votre préfixe.

3Étape 3 : Isoler la configuration : références de connexion et variables

Créez apps et flux depuis la solution. Un flux de solution se lie à une référence de connexion, pas directement à une connexion. Pour en ajouter une à la main : New > More > Connection Reference.

Pour toute valeur qui change d'un environnement à l'autre (URL de site SharePoint, liste, adresse e-mail), créez une variable d'environnement : New > More > Environment variable. Types disponibles : Decimal number, Text, JSON, Two options, Data source, Secret.

Avant l'export, retirez la valeur actuelle de la solution : Current Value > ... > Remove from this solution. La valeur reste en dev, mais une nouvelle valeur sera demandée à l'import.

Vérification : Le volet des composants de la solution liste vos références de connexion et vos définitions de variables, sans valeur actuelle exportée.

4Étape 4 : Exporter la solution

Dans l'interface : sélectionnez la solution, Export, cochez Publish all changes, puis choisissez Managed dans Export as. Seuls les composants publiés sont exportés.

Exportez aussi une version non gérée : c'est votre source, à conserver dans un système de contrôle de version. On ne peut pas exporter une solution gérée.

En ligne de commande, connectez-vous à l'environnement de dev puis exportez les deux variantes. --managed est un commutateur sans valeur.

pac auth create --name Dev --environment "App-Dev"
pac solution export --name MaSolution --path .\out\MaSolution.zip --overwrite
pac solution export --name MaSolution --path .\out\MaSolution_managed.zip --managed --overwrite

Vérification : Le dossier out contient deux fichiers .zip, et pac solution list affiche la version exportée.

5Étape 5 : Préparer le fichier de paramètres de déploiement

Générez un fichier JSON à partir du .zip géré. Il liste les variables d'environnement et les références de connexion à renseigner.

Créez un fichier par environnement cible. Remplissez Value pour chaque variable et ConnectionId pour chaque référence. L'identifiant de connexion se lit dans l'URL de la connexion, sous Connections, dans l'environnement cible.

pac solution create-settings --solution-zip .\out\MaSolution_managed.zip --settings-file .\settings.test.json

# Contenu attendu (valeurs à compléter)
# {
#   "EnvironmentVariables": [
#     { "SchemaName": "nmr_SiteUrl", "Value": "" }
#   ],
#   "ConnectionReferences": [
#     { "LogicalName": "nmr_sharepoint", "ConnectionId": "",
#       "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_sharepointonline" }
#   ]
# }

Vérification : Chaque entrée de settings.test.json a une valeur ou un ConnectionId non vide.

6Étape 6 : Importer en test, puis en production

Une solution gérée ne s'importe pas dans l'environnement qui contient la solution non gérée d'origine : il faut bien un environnement de test séparé.

Dans l'interface, l'import demande une connexion pour chaque référence et une valeur pour chaque variable sans valeur. En ligne de commande, passez le fichier de paramètres.

La personne qui active un flux doit posséder les connexions utilisées, ou y avoir accès par partage. Validez en test, puis répétez l'import en production avec settings.prod.json.

pac auth create --name Test --environment "App-Test"
pac solution import --path .\out\MaSolution_managed.zip --settings-file .\settings.test.json --publish-changes --activate-plugins

Vérification : Dans l'environnement de test, la solution apparaît comme gérée, avec la bonne version, et ses flux sont activés.

7Étape 7 : Automatiser le déploiement avec Pipelines

Pipelines déploie des solutions gérées, avec connexions et variables, depuis l'environnement de dev. Ouvrez la solution non gérée, puis la page Pipelines, et sélectionnez Create pipeline.

Prérequis : tous les environnements ont Dataverse, et chaque environnement cible est un environnement géré. Les environnements par défaut et sans Dataverse ne peuvent pas être cibles d'un pipeline personnel.

Un pipeline personnel relie au plus trois environnements : un de dev et deux cibles. Pour davantage d'étapes, des approbations ou le partage, un administrateur configure un hôte dédié dans l'app Deployment Pipeline Configuration.

Vérification : Depuis la solution en dev, le bouton de déploiement propose l'étape de test, et l'historique des exécutions affiche un déploiement réussi.

8Étape 8 : Poser une stratégie de données (DLP) de base

Dans le Centre d'administration : Security > Data and privacy > Data policy > New Policy. Classez les connecteurs en trois groupes : Business, Non-business, Blocked.

Un même app ou flux ne peut pas combiner des connecteurs de groupes différents. Placez les connecteurs de données d'entreprise (SharePoint, Dataverse, Office 365 Outlook) dans Business. Bloquez ceux qui n'ont rien à faire chez vous.

Laissez Non-business comme groupe par défaut pour les nouveaux connecteurs, comme le recommande Microsoft. Appliquez la stratégie à la production, puis vérifiez que vos apps et flux restent conformes en test.

Vérification : La stratégie apparaît dans la liste Data policy avec la bonne portée, et un flux mêlant un connecteur Business et un Non-business ne peut plus être enregistré.