Solutions gérées et non gérées dans Power Platform : le guide complet

By Mirko Peters · 2026-10-21

Découvrez les différences essentielles entre les solutions Power Platform gérées et non gérées, les règles de déploiement et les bonnes pratiques ALM pour vos applications.

Automatically translated with AI from the original post. Read the English original

Comprendre la différence entre les solutions Power Platform gérées et non gérées est indispensable pour éviter la suppression catastrophique d'applications et les échecs de déploiement. Ce guide explique comment les couches non gérées servent d'espace de travail modifiable, tandis que les solutions gérées constituent des packages figés et déployables dans les environnements de développement, de test et de production.

Points clés

• Les solutions non gérées sont votre copie de travail dans les environnements de développement, là où vous concevez, modifiez et expérimentez activement.
• Les solutions gérées sont des copies figées et déployables, destinées strictement aux environnements de test et de production afin de préserver la stabilité.
• La suppression d'une solution non gérée ne retire que le conteneur et laisse les composants intacts, tandis que la désinstallation d'une solution gérée supprime les tables personnalisées et les données associées.
• Vous ne pouvez pas réimporter une solution gérée dans le même environnement de développement que celui où a été créée sa solution non gérée parente.
• Considérer les solutions non gérées comme du code source et les solutions gérées comme des artefacts de build aligne votre ALM Power Platform sur les pratiques standard du développement logiciel.

Les différences fondamentales entre solutions gérées et non gérées

Lorsque vous commencez à créer des applications, des flux et des tables dans Microsoft Power Platform, il est facile de traiter les environnements comme d'immenses brouillons numériques. Vous cliquez, créez des entités personnalisées et configurez des flux cloud directement dans un espace par défaut ou partagé. Toutefois, une fois que votre projet dépasse le stade de la preuve de concept, cette approche désinvolte mène rapidement à un code impossible à maintenir et à des pertes de données accidentelles. Pour bâtir des applications fiables, vous devez maîtriser la distinction fondamentale entre solutions non gérées et solutions gérées.

Au fond, une solution est simplement un conteneur, un bordereau d'expédition qui regroupe vos composants d'application afin qu'ils puissent circuler proprement d'un environnement à l'autre. Mais ce conteneur recouvre une dichotomie stricte : non gérée ou gérée. Retenir cette formule simple permet de bien cerner leurs rôles respectifs : non gérée pour modifier ici, gérée pour déployer là-bas.

Solutions non gérées : votre espace de développement

Une solution non gérée est votre copie de travail active et modifiable. Chaque fois que vous concevez une application canevas, rédigez des règles métier ou modifiez des tables Dataverse, vous travaillez dans une solution non gérée au sein de votre environnement de développement. Chaque ajustement, changement de couleur ou modification de schéma se répercute immédiatement dans l'application sous-jacente.

Que se passe-t-il lorsque vous supprimez une solution non gérée ?

L'une des caractéristiques de sécurité les plus importantes des solutions non gérées concerne leur suppression. Si vous supprimez une solution non gérée de votre environnement de développement, seul le conteneur disparaît. Les personnalisations, applications et tables que vous avez créées ne disparaissent pas : elles retombent discrètement dans la solution par défaut. Si cela évite une destruction totale accidentelle pendant le développement, cela peut encombrer votre espace par défaut si vous n'y prenez pas garde.

Microsoft recommande de stocker vos solutions non gérées directement dans des systèmes de contrôle de source comme GitHub ou Azure DevOps. En considérant la solution non gérée comme votre véritable dépôt de code source, vous conservez une piste d’audit complète et historique de chaque modification apportée par votre équipe de développement.

Solutions gérées : votre package de déploiement en production

Une solution gérée représente la copie finalisée, compilée et figée de votre application. Vous ne modifiez pas directement une solution gérée. Vous exportez plutôt votre solution non gérée en tant que solution gérée, puis vous déployez ce package dans les environnements en aval, comme les tests d’acceptation utilisateur (UAT), les tests d’intégration système (SIT) et, finalement, la production.

La suppression de solutions gérées : un enjeu critique

Contrairement à leurs équivalents non gérés, les solutions gérées sont fortement verrouillées par conception. Vous ne pouvez pas modifier directement les composants d’une solution gérée. Plus important encore, la désinstallation d’une solution gérée produit le comportement exactement inverse de celui d’une solution non gérée : comme tout le contenu du package est lié à ce déploiement précis, la suppression de la solution entraîne la suppression de tous ses composants.

Surtout, cette suppression lors de la désinstallation inclut toutes les données stockées dans les tables personnalisées faisant partie de la solution, ainsi que les données stockées dans les colonnes personnalisées ajoutées aux tables existantes. Une fois une solution gérée désinstallée d’un environnement, les données associées sont définitivement perdues. Il n’existe aucune fonction d’annulation native : bien comprendre l’architecture de vos déploiements est donc une responsabilité d’administration essentielle.

Architecture des environnements et règles de test

Les mécanismes techniques de Power Platform imposent des frontières strictes entre environnements concernant la manière de traiter ces deux types de solutions. Par exemple, vous ne pouvez pas importer une solution gérée dans l’environnement de développement qui contient la solution non gérée à partir de laquelle elle a été créée. Tester un déploiement géré exige un environnement entièrement distinct, c’est pourquoi les bonnes pratiques recommandent de mettre en place dès le départ un pipeline multi-environnements dédié.

Une configuration ALM (gestion du cycle de vie des applications) saine et standard comprend au moins trois environnements distincts :

• Développement : environnement dans lequel les créateurs conçoivent et modifient les solutions non gérées.
• Test (UAT) : environnement dans lequel vous importez la solution gérée afin de vérifier que le processus de déploiement et le fonctionnement de l’application sont corrects.
• Production : environnement dans lequel les utilisateurs réels s’appuient chaque jour sur la solution gérée stable et figée.

Maîtriser votre stratégie de déploiement Power Platform

Adopter une séparation stricte entre les espaces de développement non gérés et les déploiements gérés en production transforme votre stratégie Power Platform, d’un ensemble de solutions de fortune fragiles en une ingénierie logicielle de niveau entreprise. En respectant les frontières des solutions, en protégeant vos environnements de production contre les modifications ad hoc et en conservant de bonnes habitudes de contrôle de source, vous garantissez que vos applications critiques pour l’activité restent stables et résilientes à mesure qu’elles évoluent.

Pour approfondir encore les mécanismes des composants Power Platform, des éditeurs, des préfixes et des couches de solution, écoutez l’épisode complet et abonnez-vous au podcast pour suivre en continu l’actualité de l’écosystème cloud Microsoft.