Migration d’applications et de flux à partir de l’environnement par défaut

Ce livre blanc explique comment les organisations et les administrateurs peuvent planifier la migration de leurs applications et flux à partir de l’environnement par défaut.

Auteurs : Ravi Chada (Microsoft), Rui Santos (Microsoft)

Note

Vous pouvez enregistrer ou imprimer ce livre blanc en sélectionnant Imprimer dans votre navigateur, puis Enregistrer au format PDF.

Environnement par défaut

Un environnement par défaut est créé par locataire et est accessible pour tous les utilisateurs de ce locataire. L’environnement par défaut est créé dans la région la plus proche de la région par défaut du locataire Microsoft Entra et est nommé comme suit : [nom du locataire Microsoft Entra] (par défaut). Lorsqu’un nouvel utilisateur s’inscrit à Power Apps ou Power Automate, il est automatiquement ajouté au rôle Créateur de l’environnement par défaut. Aucun utilisateur n’est ajouté automatiquement au rôle Administrateur d’environnement de l’environnement par défaut.

Vous ne pouvez pas supprimer l’environnement par défaut et vous ne pouvez pas sauvegarder manuellement l’environnement par défaut. Les sauvegardes du système se produisent en continu. L’environnement par défaut est limité à 1 To de capacité de stockage. L’environnement par défaut présente les fonctionnalités suivantes :

• Capacité de base de données Dataverse de 3 Go
• Capacité de fichier Dataverse de 3 Go
• Capacité de journal Dataverse de 1 Go

Le contrôle de capacité effectué avant de créer de nouveaux environnements exclut la capacité de stockage incluse de l’environnement par défaut lorsque vous calculez si vous disposez d’une capacité suffisante pour créer un environnement. Pour stocker plus de données, vous pouvez créer un environnement de production.

Dans l’environnement par défaut, les employés d’une organisation disposant d’une licence Microsoft 365 peuvent créer des applications et des flux de cloud. L’environnement par défaut devient le premier studio pour que ces employés commencent à créer leurs applications et flux. Comme il n’est pas possible de supprimer le rôle de créateur d’environnement de l’environnement par défaut, les créateurs commencent à créer des applications et des flux de productivité personnelle et à les partager au sein de leurs équipes pour que d’autres puissent en bénéficier. La plupart des organisations renomment souvent l’environnement par défaut en Productivité personnelle.

Les administrateurs découvrent de manière réactive que de nombreuses applications et flux sont créés dans l’environnement par défaut. Il peut ne pas être approprié qu’une application ou un flux soit dans l’environnement par défaut dans certains scénarios, notamment :

• Une application est partagée avec de nombreux utilisateurs dans un comportement de type production.
• Une application utilise des classeurs Excel contenant des données sensibles.
• Une application, basée sur des listes SharePoint, reçoit de nombreuses interactions de données, telles que des insertions ou des mises à jour.
• Une application ou un flux utilise des connecteurs qui ne sont pas autorisés dans les nouvelles stratégies de protection contre la perte de données (DLP).
• Les connecteurs personnalisés sont activés et utilisés dans l’environnement par défaut, au lieu d’être sécurisés dans un environnement dédié.

Les scénarios ci-dessus valent la peine d’être pris en considération et indiquent que vous devez commencer à déplacer ces applications et flux de l’environnement par défaut vers leur propre environnement de développeur ou vers un autre environnement partagé. D’autres facteurs qui entrent en jeu sont les limitations associées à l’environnement par défaut.

Les équipes du Centre d’excellence (CoE) qui surveillent Power Platform sont obligés de réagir une fois les limites atteintes, ce qui affecte négativement les applications qui s’exécutent dans l’environnement par défaut. Cette limitation peut également être quelque chose qu’un administrateur ou l’équipe CoE doit effectuer régulièrement. Il existe trois grandes phases :

• Identification des objets Power Platform
• Déplacement des objets Power Platform
• Nettoyage des objets Power Platform

Il existe différentes manières d’exporter vos applications et flux pour les déplacer vers un nouvel environnement. Les solutions sont un fichier unique qui peut inclure presque tout ce que vos créateurs créent dans Power Platform et les déplacer ensemble. Les applications canevas et les flux de cloud peuvent être exportés directement.

Au fil du temps, les objets Power Platform ont évolué pour prendre en charge les solutions. Désormais, les applications et les flux peuvent prendre en charge les solutions par défaut, bien que cela nécessite une activation manuelle. Les créateurs peuvent toujours créer des applications et des flux à partir de make.powerapps.com et make.powerautomate.com, qui peuvent être classés comme ne prenant pas en charge les solutions, et ceux-ci peuvent être exportés individuellement ou les ajouter à une solution. En ajoutant une solution, le créateur peut tirer parti des variables d’environnement et des références de connexion pour configurer et déployer des points de terminaison dans les environnements.

L’objectif est que tous les composants Power Platform soient ajoutés à une seule solution, ce qui permet de déplacer facilement plusieurs composants comme une seule unité entre les environnements.

Identification des objets Power Platform

La première étape consiste à identifier les applications, les flux et les actifs qui doivent être déplacés ou nettoyés. Le Starter Kit CoE fournit un inventaire de toutes les applications et de tous les flux, et les rapports Power BI aident à déterminer l’utilisation. Cette étape vous aide à évaluer l’utilisation des applications et devrait vous aider à les étiqueter. À mesure que vous réalisez l’exercice, veillez à marquer les applications et les flux qui doivent être migrés vers un autre environnement. Un indicateur peut être basé sur les connecteurs utilisés, l’emplacement de l’utilisateur, le département de l’utilisateur, etc. Cet article présente également une méthode permettant de reconnaître les éléments qui doivent être nettoyés ou déplacés en fonction des pratiques de protection contre la perte de données (DLP).

Déplacement des objets Power Platform

Si le composant est marqué pour être déplacé vers un autre environnement, des options sont disponibles pour déplacer l’application. Un déplacement est un processus interactif qui nécessite un certain niveau d’interaction avec le créateur. Le niveau de complexité pour déplacer une application ou un flux augmente avec la combinaison de composants utilisés pour créer l’application ou le flux.

Par exemple, une application avec six écrans a 10 boutons dans plusieurs écrans. Supposons que ces 10 boutons appellent chacun un flux individuel. Quelques flux sont également déclenchés quotidiennement pour corriger les données ou les intégrer à un autre système. Supposons également qu’un modèle de traitement d’images AI Builder est utilisé dans le cadre de l’automatisation. Pour déplacer cette application, tous les composants doivent être ajoutés à une solution et les références de connexion doivent être ajustées et testées correctement avant de confirmer l’exécution.

Dans un autre cas, supposons qu’une application canevas utilise une connexion Office 365. Dans ce cas, le créateur doit ajouter uniquement l’application canevas à la solution.

Nettoyage des objets Power Platform

Si un composant est marqué pour le nettoyage, il existe deux options principales. La première option consiste à le supprimer directement et la deuxième option consiste à le supprimer après avoir effectué une sauvegarde. Dans le cas de la sauvegarde, il peut y avoir un certain chevauchement des étapes coïncidant avec le déplacement d’objets.

À titre d’exemple, les administrateurs de l’équipe CoE constatent que la plupart des créateurs créent des applications et des flux de test à des fins d’apprentissage. Les créateurs abandonnent ensuite les applications et les flux, ce qui peut être confirmé en examinant les mesures d’utilisation. Une autre solution consiste à mettre une application en quarantaine. Si personne ne vous contacte à propos de l’application, celle-ci peut également être supprimée.

Maintenir une stratégie de communication joue un rôle clé. Les administrateurs doivent planifier la communication :

• Établir des connexions que les créateurs doivent autoriser lorsqu’ils lancent l’application dans le nouvel environnement.
• La nouvelle URL de l’application dans l’environnement cible.
• Navigation vers l’environnement correct.

Certaines de ces solutions de déplacement d’objets sont prêtes à l’emploi et peuvent nécessiter une licence Power Apps et Power Automate autonome qui offre aux utilisateurs la possibilité de créer et d’exécuter des applications sur des sources de données qui s’étendent au-delà de Microsoft 365.

Stratégies

L’ensemble du processus d’identification et de déplacement des applications et des flux à partir de l’environnement par défaut a plus de chances de réussir lorsqu’il est basé sur une stratégie. Il existe plusieurs stratégies que vous devez envisager.

Stratégie DLP

Les stratégies de protection contre la perte de données (DLP) fonctionnent comme des barrières de sécurité pour empêcher les utilisateurs d’exposer involontairement des données de l’organisation et pour protéger la sécurité des informations dans le client. Les stratégies DLP appliquent des règles pour lesquelles les connecteurs sont activés pour chaque environnement et les connecteurs qui peuvent être utilisés ensemble. Les connecteurs sont classés comme données commerciales uniquement, aucune donnée commerciale autorisée, ou bloqué. Un connecteur dans le groupe de données métier uniquement, il ne peut être utilisé qu’avec d’autres connecteurs de ce groupe dans la même application ou le même flux. Nous vous recommandons d’avoir, au moins, une stratégie.

Identification des objets à l’aide de la stratégie DLP

L’identification basée sur la stratégie DLP est utile pour définir des environnements cibles pour vos applications et flux. Il est possible que certaines applications ou certains flux utilisent un connecteur bloqué par la stratégie DLP ou une combinaison de connecteurs métier et hors métier qui, lors de l’activation de la stratégie DLP, cessent de fonctionner.

Pour éviter l’interruption des objets critiques potentiels, en raison de la stratégie DLP, qui fait partie du Starter Kit CoE, vous pouvez utiliser l’outil Éditeur DLP (analyse de l’impact). L’objectif de l’éditeur DLP est de permettre aux administrateurs de voir l’impact des stratégies existantes ou l’impact potentiel des changements de stratégie. Il fournit aux administrateurs une vue des applications et flux affectés, ainsi que des ressources qui seraient désactivées si des stratégies nouvelles ou mises à jour devaient être appliquées. L’application peut être utilisée pour examiner les stratégies existantes, modifier les stratégies existantes et atténuer les risques en contactant les créateurs et en les informant de la meilleure marche à suivre pour leur application ou flux.

Mettez à jour les stratégies DLP existantes pour examiner leur impact. Suivez l’article Établir l’hygiène du locataire avec le Starter Kit CoE pour trouver plus d’informations sur l’éditeur DLP.

Avant d’activer la fonctionnalité DLP, vous pouvez identifier les applications et les flux affectés et alerter les créateurs. L’éditeur DLP peut envoyer une liste de toutes les applications et de tous les flux affectés à une adresse e-mail, ce qui génère un fichier .csv pour chaque type d’objet.

À l’aide de l’éditeur DLP version 2.0, dans la zone Analyse de l’impact, choisissez Exporter les applications et les flux affectés au format CSV.

Chaque fichier CSV généré (flow.csv et apps.csv) contient des informations concernant :

1. Nom des applications et des flux.
2. Propriétaire des applications et des flux.
3. E-mail du propriétaire des applications et des flux.
4. Toutes les connexions utilisées par les applications et les flux.
5. ID des applications et des flux pour identifier l’objet.
6. ID d’environnement où se trouvent les applications et les flux.

Notez que les Connexions vous donnent la liste de toutes les connexions utilisées par l’application ou le flux. Si vous devez identifier exactement quel connecteur est affecté par la stratégie DLP en question, une automatisation est nécessaire à ce moment. Nous évaluons de changer cette situation dans l’outil.

Exemple d’implémentation pour identifier la connexion :

1. Créez un flux Power Automate.

2. Utilisez le connecteur Obtenir la stratégie DLP du locataire en spécifiant la stratégie DLP en question.

3. Le résultat est deux tableaux, les données métier et les données hors métier. A titre d’exemple, le connecteur Twitter affiche ce code :

   [
     {
       "id": "/providers/Microsoft.PowerApps/apis/shared_twitter",
       "name": "Twitter",
       "type": "Microsoft.PowerApps/apis"
     }
   ……
   ]
   

4. À partir de cette liste, vous avez accès au nom du connecteur qui correspond à la liste de noms de la colonne Connexion de l’application ou du flux au format csv.

5. En convertissant le csv au format Excel et en le plaçant dans votre OneDrive, vous pouvez lire toutes les applications et tous les flux affectés à partir de Power Automate. Vérifiez quelle connexion est affectée en fonction d’une logique qui compare les connexions avec les noms de connecteur.

6. Une fois que vous avez trouvé la connexion à l’origine de l’impact, générez une nouvelle liste avec l’ID d’application ou de flux et le connecteur affecté par la stratégie DLP.

7. Utilisez les informations précédentes pour informer le créateur de l’impact futur. Vous pouvez utiliser Power Cards pour recueillir les commentaires du créateur si l’application ou le flux peut être supprimé ou doit être migré vers un autre environnement.

Sur la base de votre analyse, si vous déterminez que les flux affectés ne sont pas utilisés, vous pouvez les mettre en quarantaine et envoyer un e-mail au créateur avec des instructions sur la façon de les déplacer vers un autre environnement. Cela encourage une culture du « faire soi-même » et supprime l’informatique fantôme. Dans certaines situations, vous souhaitez peut-être exempter certains objets de la stratégie DLP. Par exemple, vous souhaitez peut-être appliquer une stratégie DLP spécifique uniquement pour les nouvelles ressources créées et exempter les ressources actuelles. Pour plus d’informations sur l’exemption des ressources DLP, consultez Exemption des ressources DLP.

En effet, votre stratégie d’environnement est définie via DLP et cela fournit une destination pour les applications et les flux développés dans l’environnement par défaut.

Stratégie de l’environnement

L’élaboration d’une stratégie d’environnement nécessite de configurer les environnements et d’autres couches de sécurité des données d’une manière capable de prendre en charge le développement productif dans votre organisation, tout en sécurisant et en organisant les ressources. Il est important pour les objectifs suivants d’établir une stratégie visant à gérer l’approvisionnement des environnements et leur accès, et à contrôler les ressources en leur sein :

• Sécuriser les données et les accès.
• Régir l’environnement par défaut de manière conforme.
• Gérer le nombre correct d’environnements pour éviter la prolifération et maintenir la capacité.
• Faciliter et mettre en œuvre une bonne gestion du cycle de vie des applications (ALM).
• Organiser les ressources en partitions logiques.
• Faciliter les opérations (et le travail du service d’assistance) consistant à identifier les applications qui sont en production en les plaçant dans des environnements dédiés.
• Veiller à ce que les données soient stockées et transférées dans des régions géographiques acceptables (pour des raisons de performance et de conformité).
• Assurer l’isolement des applications en cours de développement.
• Activation des services de facturation internes pour les utilisateurs finaux de l’entreprise ou les divisions qui consomment les services.

Vous devez avoir des départements bien établis, autonomes et qui ont des processus ALM existants en place. Dans ces cas, les environnements assurent l’isolement et organisent les ressources en fonction du département. Une stratégie basée sur ces critères peut être réalisée en créant des environnements distincts pour chaque département. Ces environnements deviennent alors la destination des applications et des flux dans l’environnement par défaut.

Stratégie de communication

Une communication efficace est cruciale lors d’un processus de migration. La communication se produit dans toutes les phases du processus de migration. Une communication claire favorise la compréhension et la collaboration entre les parties prenantes. Elle permet une circulation fluide des informations, en garantissant que toutes les personnes impliquées sont bien informées des plans de migration, de la progression et des éventuels défis.

Dans le cadre des efforts de migration et de nettoyage, assurez-vous que le processus est fluide pour les créateurs, les parties prenantes et la direction. Élaborez une stratégie sur la meilleure façon de communiquer et sur les points que vous devez communiquer, pour assurer la cohérence de vos objectifs et faciliter la communication pour toutes les personnes impliquées. Certaines options à prendre en compte sont :

• Utilisez le Starter Kit CoE comme outil de suivi des actifs.
• Ajoutez des flux de cloud personnalisés pour envoyer des notifications à différentes phases.
• Créez des modèles d’e-mail qui sont envoyés pour communiquer avec les créateurs.

Les éléments à retenir sont :

• Changement de l’URL de l’application. Les utilisateurs d’application doivent mettre à jour tous les signets d’une application dans l’environnement par défaut.
• S’il existe un flux de déclenchement HTTP basé sur une URL, celui-ci doit être mis à jour dans les flux dépendants pour garantir qu’il agit toujours comme un webhook.
• Fournissez des étapes détaillées pour établir des connexions une fois le déplacement terminé pour les créateurs et les utilisateurs de l’application. Les utilisateurs ne doivent pas se préoccuper de la création d’une connexion lorsqu’ils lancent l’application pour la première fois à partir du nouvel environnement.

Un bon début pour la configuration des communications nécessite qu’un modèle en libre-service soit évolutif et plus en temps réel pour les utilisateurs au lieu de simplement utiliser l’e-mail d’un seul utilisateur ou une liste de distribution. Si vous envisagez de créer un site SharePoint, il existe un modèle disponible que vous pouvez utiliser pour créer un hub Microsoft Power Platform interne. Le hub devient le lieu commun pour en savoir plus sur la stratégie et l’orientation afin que les décideurs puissent prendre les bonnes décisions sur ce qu’ils ont l’intention de créer et où ils doivent aller pour le faire.

Il existe certains composants de solution existants, par exemple configurer les composants de notifications d’inactivité et configurer les composants de conformité des développeurs dans le Starter Kit CoE dont vous pourriez tirer parti. Ces composants sont fournis avec des modèles d’e-mail et peuvent être dupliqués pour répondre à votre objectif et besoin de les migrer à partir de l’environnement par défaut. Un bon ajout consiste également à capturer quelques témoignages de réussite sur le site de communication.

Audiences

Dans le processus de migration, différentes audiences sont généralement impliquées dans la communication. Voici les principales parties prenantes les plus classiques et leurs rôles :

• Propriétaires d’applications : les propriétaires d’applications sont des personnes ou des équipes responsables du développement, maintenance et de la gestion d’applications spécifiques. Ils ont une connaissance approfondie des fonctionnalités, du flux de travail et de la configuration de leurs applications. La communication avec les propriétaires d’application est cruciale pour comprendre les exigences spécifiques à leur application, recueillir des commentaires, répondre aux préoccupations et garantir une migration fluide de leurs applications vers le nouvel environnement.
• Utilisateurs d’applications : les utilisateurs d’applications sont les personnes qui utilisent régulièrement les applications pour effectuer leurs tâches ou leurs flux de travail. Ils peuvent avoir différents niveaux d’expertise technique et de familiarité avec les applications. La communication avec les utilisateurs d’application est importante pour les informer de la migration, fournir des mises à jour sur les éventuels changements ou interruptions pouvant se produire, offrir une formation ou un support pour garantir une transition fluide et réduire tout impact sur leurs opérations quotidiennes.
• Chefs de service ou gestionnaires : les chefs de service ou gestionnaires jouent un rôle important dans le processus de migration car ils supervisent les opérations et les objectifs stratégiques de leurs services respectifs. Ils doivent être informés de la chronologie de migration, des impacts potentiels et des avantages. La communication avec les chefs de service leur permet de fournir les conseils nécessaires, d’aligner la migration avec les objectifs du département et de garantir une coordination fluide au sein de leurs équipes.
• Équipes informatiques ou techniques : Les équipes informatiques ou techniques sont responsables de l’infrastructure, des systèmes et des aspects techniques globaux de la migration. Elles sont impliquées dans la planification, l’exécution et le support du processus de migration. La communication avec les équipes informatiques est essentielle pour discuter des exigences techniques, des dépendances, des considérations de sécurité et des éventuels changements d’infrastructure ou de configuration nécessaires qui doivent être mis en œuvre pour une migration réussie.
• Équipes de sécurité et de conformité : les équipes de sécurité et de conformité jouent un rôle essentiel pour garantir la sécurité des données, la confidentialité et la conformité réglementaire pendant la migration. Elles fournissent des conseils et veillent à ce que des mesures appropriées soient en place pour protéger les informations sensibles. La communication avec les équipes de sécurité et de conformité implique de discuter des exigences de sécurité, des protocoles de chiffrement, des contrôles d’accès et des éventuelles considérations liées à la conformité tout au long du processus de migration.
• Direction exécutive : la direction exécutive, y compris les cadres dirigeants ou les cadres supérieurs, doit être tenue informée du processus de migration. Elle n’a peut-être pas besoin d’informations techniques détaillées, mais doit connaître les objectifs, la progression et les impacts potentiels du projet sur l’organisation. La communication avec la direction générale permet de garantir son soutien, l’alignement sur les objectifs stratégiques et l’allocation de ressources pour la migration.

Il est important d’adapter les stratégies et les messages de communication à chaque audience, en tenant compte de ses besoins spécifiques, de ses préoccupations et de son niveau de compréhension technique. Une communication claire et opportune avec toutes les parties prenantes favorise la collaboration, garantit une coordination fluide et atténue les défis potentiels pendant le processus de migration.

Cadence

La cadence ou la fréquence de communication avec les parties prenantes au cours d’un processus de migration varie en fonction des besoins spécifiques et de la dynamique du projet. Il est important d’établir une communication régulière et cohérente pour tenir les parties prenantes informées, répondre aux préoccupations et maintenir l’alignement tout au long de la migration. Voici quelques considérations pour déterminer la cadence de communication avec les différentes parties prenantes :

• Propriétaires d’applications : Il est important de maintenir une communication fréquente avec les propriétaires d’applications tout au long du processus de migration. Cela comprend des mises à jour régulières sur la progression de la migration, répondre aux éventuelles préoccupations et impliquer les propriétaires d’application dans la prise de décisions, si nécessaire. La fréquence de communication peut varier en fonction de la complexité et de l’importance de l’application, mais il est recommandé de réaliser des contrôles réguliers et de fournir des réponses aux demandes en temps opportun.
• Utilisateurs de l’application : Interagissez avec les utilisateurs de l’application via des canaux de communication réguliers pour les tenir informés de la migration. Cela doit inclure des annonces, des e-mails, des bulletins d’informations ou même des sessions ou ateliers de formation dédiés. La fréquence de communication avec les utilisateurs d’application peut varier, mais il est crucial de fournir des mises à jour à des étapes clés, de les informer des éventuels changements ou interruptions susceptibles de les affecter, et de leur fournir un support et des conseils tout au long du processus.
• Chefs de service et responsables : La communication avec les chefs de service et les responsables peut avoir lieu à intervalles réguliers ou selon les besoins, en fonction de l’importance de la migration pour leurs services. Fournissez des mises à jour périodiques sur la progression générale, les chronologies et l’impact sur leurs équipes.
• Équipes informatiques ou techniques : Communiquez régulièrement avec les équipes informatiques et techniques impliquées dans la migration. Cela comprend une collaboration continue, le partage de mises à jour sur des questions ou des problèmes techniques et la coordination des éventuelles configurations ou modifications nécessaires. La fréquence de communication est généralement plus élevée pendant la phase de planification et d’analyse. Pendant la phase de mise en œuvre, organisez des réunions ou des points de contact réguliers pour garantir une coordination fluide.

Ressources

La gestion efficace des ressources est cruciale pour une migration réussie. Voici quelques aspects clés à prendre en compte en matière de gestion des ressources au cours d’une migration :

• Identification des ressources : Identifiez les ressources requises pour le projet de migration, y compris les personnes ou les équipes responsables de tâches telles que les préparatifs avant la migration, la migration des données, les tests, le déploiement, la configuration et le support après la migration. Déterminez les compétences, l’expertise et la disponibilité spécifiques nécessaires pour chaque rôle.
• Allocation des ressources : attribuez des ressources à des rôles et des tâches en fonction de la compétences ressource, de sa disponibilité et de sa capacité de charge de travail. Assurez-vous que les ressources sont allouées de manière appropriée pour équilibrer la charge de travail et respecter les délais du projet. Tenez compte de toute dépendance ou contrainte qui peut avoir un impact sur l’allocation de ressources, comme les ressources partagées sur plusieurs projets.
• compétences développement et formation : Évaluer les lacunes en matière de compétences et de connaissances au sein de l’équipe et fournir les opportunités de formation ou de perfectionnement nécessaires pour garantir que les ressources sont correctement équipées pour les tâches qui leur sont assignées. Cela peut impliquer de fournir des sessions de formation, des ateliers, ou d’accéder aux ressources et à la documentation pertinentes.
• Communication et collaboration : Favoriser une communication et une collaboration efficaces entre les ressources impliquées dans la migration. Encouragez les mises à jour régulières de l’état, les réunions de coordination et le partage des connaissances pour garantir que tous les membres de l’équipe sont alignés, informés et travaillent ensemble vers des objectifs communs.
• Planification d’urgence : Anticiper les contraintes ou les risques potentiels en matière de ressources et élaborer des plans d’urgence. Identifiez ou formez des ressources de secours polyvalentes dans des rôles critiques pour atténuer les éventuels défis imprévus, comme des absences inattendues ou des limitations de ressources.
• Engagement des parties prenantes : Tenez les parties prenantes, telles que les propriétaires d’applications, les chefs de service et la direction, informés de l’allocation des ressources et de tout impact potentiel sur les délais ou les livrables. Communiquez régulièrement les mises à jour de ressources, les rapports de progression et des éventuels ajustements des plans de ressources pour gérer les attentes et maintenir la transparence.

Migration individuelle d’objets

La distinction entre application et solution est importante. L’exportation et l’importation d’une application n’affectent que cet objet. Une solution est un conteneur pouvant contenir plusieurs applications, flux et autres objets.

Exporter et importer une application canevas (mode hérité)

Les étapes détaillées sont documentées dans Exportation d’un package d’applications canevas et Importation d’un package d’applications canevas.

Cette méthode d’exportation d’applications est une méthode héritée. Bien qu’elle soit prise en charge, nous vous recommandons d’utiliser des solutions. Les solutions vous permettent de migrer plusieurs composants au lieu d’une seule ressource.

Exporter et importer un flux (méthode héritée)

Les étapes suivantes décrivent comment exporter un flux.

1. Sélectionnez le menu « … », sélectionnez Exporter, puis sélectionnez Package (.zip).
2. Entrez le nom et la description de votre package. Vous pouvez ensuite configurer les paramètres par défaut et ajouter des commentaires accessibles au cours de la phase d’importation.
3. Sélectionnez le bouton Exporter dans le coin inférieur droit de la fenêtre pour télécharger le package. Si votre téléchargement ne démarre pas automatiquement, vous pouvez sélectionner le bouton Télécharger.

Les étapes suivantes décrivent comment importer un flux.

1. Sélectionnez le bouton Importer.
2. Chargez le fichier du package et attendez que l’écran affiche les détails du package.
3. Lors de la configuration des paramètres du flux, vous pouvez choisir de créer un nouveau flux ou de mettre à jour un flux existant avec la définition de flux du package.
4. Sélectionnez les connexions nécessaires pour configurer le flux. Le bouton Importer devrait devenir disponible une fois que vous avez configuré correctement tous les paramètres requis.

Après avoir importé le flux, celui-ci doit être activé. Si le flux a des références de connexion, l’utilisateur qui l’active doit avoir accès à ces connexions. Sinon, le propriétaire de la connexion peut accorder l’accès à l’utilisateur d’activation.

Cette méthode d’exportation de flux de cloud est une méthode héritée. Bien qu’elle soit prise en charge, nous vous recommandons d’utiliser des solutions, qui vous permettent de migrer plusieurs composants au lieu d’une seule ressource.

Exporter et importer une application pilotée par modèle

Une application pilotée par modèle fait toujours partie d’une solution. L’application mise en package, incluse dans le fichier de solution (.zip), peut être partagée avec les utilisateurs en fonction de leurs rôles de sécurité une fois qu’elle a été exportée correctement depuis l’environnement source et importée dans l’environnement cible.

Les processus détaillés étape par étape sont décrits dans Exporter une solution et Importer une solution.

Exporter et importer un bot Microsoft Copilot Studio

Vous pouvez exporter et importer des bots à l’aide de solutions. Une liste détaillée des étapes est décrite dans Exporter et importer des bots à l’aide de solutions.

Exporter et importer un site Power Pages

La migration des pages implique l’exportation de la configuration existante depuis l’environnement Microsoft Dataverse source, puis son importation dans l’environnement Dataverse cible. Certaines étapes préalables doivent être exécutées dans l’environnement cible. Une fois le travail de préparation terminé, les données de configuration du portail peuvent être exportées à l’aide de l’Outil de migration de la configuration.

Application de formulaire SharePoint – cas particulier pour l’environnement par défaut

SharePoint Les applications de formulaire ne peuvent être associées qu’à un seul environnement et, si elles ne sont pas configurées autrement, sont dans le environnement par défaut. Une migration de toutes les applications nécessite de définir la destination sur un environnement différent au lieu de l’environnement par défaut. Les formulaires personnalisés existants ne migrent pas automatiquement vers l’environnement nouvellement désigné. Seuls les environnements de production peuvent être désignés pour les formulaires personnalisés SharePoint. Le processus manuel suit, comme déplacer une application canevas.

Sauvegarde d’objets Microsoft Power Platform

La plupart des objets Microsoft Power Platform sont exportés sous forme de fichiers zip. Sinon, ils ont au moins un format de fichier. Ces fichiers dans leur format d’origine, en tant que fichier zip ou quelle que soit leur extension initiale, peuvent être ajoutés à n’importe quel emplacement de stockage de fichiers ou à un référentiel de votre choix. Quelques options à mentionner sont Azure DevOps, GitHub, SharePoint, One Drive ou toute autre solution prenant en charge tous les formats de fichiers.

Options de migration en masse

La migration d’une application ou d’un flux aboutit si elle fonctionne de la même manière qu’auparavant. Cependant, certains éléments ne peuvent pas être transférés :

• Données d’exécution de flux sur les exécutions passées du flux - Les données sur les exécutions de flux ne sont stockées que pendant 28 jours. Si vous avez besoin des données, celles-ci peuvent être exportées et stockées en utilisant le Starter Kit CoE ou si vous avez configuré l’exportation vers le lac de données. La version la plus récente du Starter Kit CoE contient les données d’exécution de flux si elles sont utilisées avec l’exportation de données.
• Versions de l’application canvas - Au fur et à mesure que les créateurs parcourent le processus de développement, plusieurs versions peuvent être créées. Les versions antérieures ne peuvent pas être migrées. Seule la version la plus récente peut être migrée.
• Données accessibles par l’application ou le flux ou à l’aide de connecteurs - Seules les métadonnées de l’application sont incluses dans le cadre de l’exportation.

Tous les commentaires de collaboration formulés dans l’application ou le flux ne sont pas non plus inclus.

Cet article décrit quelques possibilités. Il est important d’examiner attentivement les implications et les avantages de chaque possibilité avant de prendre une décision.

Migrer tout – option de sauvegarde et de restauration de la base de données

Comme pour la plupart des types d’environnement, l’environnement par défaut est également sauvegardé. Ces sauvegardes du système sont effectuées automatiquement. Il n’existe pas d’option à la demande pour l’environnement par défaut, une demande de support est donc nécessaire. La sauvegarde peut être restaurée dans un nouvel environnement en conservant toutes les données dans Dataverse. Cette option sert uniquement à montrer au lecteur son existence et à l’informer du moment opportun pour l’envisager. Elle ne doit pas être considérée comme un choix principal, car elle ne génère qu’une migration partielle.

• Prise en charge : Dataverse, applications Dynamics
• Non entièrement pris en charge : application Canvas, bibliothèque de composants, pages personnalisées, Power Automate, Microsoft Copilot Studio

Pas entièrement pris en charge indique qu’il peut y avoir une perte potentielle de données pendant la migration et que d’autres étapes sont nécessaires.

Migrer les métadonnées puis les données

Une approche recommandée consiste à utiliser des solutions pour déplacer les métadonnées, puis les flux de données, Azure Data Factory, ou un autre outil de votre choix peuvent être utilisés pour transférer les données. Une automatisation complète du début à la fin n’est peut-être pas réalisable dans tous les cas, en raison de la diversité de connecteurs, mais une approximation proche est possible.

À un niveau supérieur, les étapes sont :

1. Ajouter une application à une solution.
2. Ajouter un flux à une solution.
3. Ajouter des bots existants.
4. Ajuster les références de connexion dans les applications et les flux.
5. Vérifier les dépendances de la solution et ajouter des objets.
6. Exporter la solution.
7. Importer la solution.
8. Transférer les données.

Vérification des dépendances de la solution

Le succès d’une importation de solution dans l’environnement cible ne peut être garanti que lorsque tous les composants associés sont ajoutés à la solution ou qu’ils sont disponibles dans l’environnement cible. Si des composants sont manquants, l’importation de la solution risque d’échouer. Pour garantir que tous les composants requis sont présents, il existe des options qui fonctionnent mieux si elles sont utilisées en combinaison :

• Ajoutez manuellement les composants sélectionnés à la solution. Dans ce cas, on suppose que vous savez que tous les composants dépendants sont déjà disponibles dans l’environnement cible.

• Utilisez le bouton afficher les dépendances au sein de la solution pour permettre au système d’identifier les dépendances pour vous. Vous pouvez ajouter toutes les dépendances ou ajouter de manière sélective uniquement les dépendances qui n’existent pas dans l’environnement cible.

  

Ajout d’un composant à une solution (manuel)

En supposant qu’ une solution soit créée, un créateur doit utiliser l’option de menu Ajouter un composant existant pour ajouter une application, un flux ou un bot existant.

Ajuster les références de connexion

Les flux et les applications de canevas gèrent les connexions différemment. Les flux utilisent des références de connexion pour tous les connecteurs, tandis que les applications canevas les utilisent uniquement pour les connexions implicitement partagées (non OAuth), telles que l’authentification SQL Server.

Mise à jour d’une application pour utiliser des références de connexion au lieu de connexions

Les applications canevas qui ne prennent pas en charge les solutions lorsqu’elles sont ajoutées à une solution ne sont pas automatiquement mises à niveau pour utiliser les références de connexion. Les références de connexion ne sont associées aux applications de canevas qu’au moment où un source de données est ajouté à l’application. Pour mettre à niveau des applications, vous devez :

1. Ajouter une application qui ne prend pas en compte les solutions à une solution.
2. Supprimer la connexion de l’application.
3. Créer une nouvelle référence de connexion dans la solution.
4. Ajouter une connexion contenant une référence de connexion associée.

Mettre à jour un flux pour utiliser des références de connexion au lieu de connexions

Lorsqu’un flux n’est pas dans une solution, il utilise des connexions. Si ce flux est ensuite ajouté à une solution, il continue à utiliser les connexions initialement. Les flux peuvent être mis à jour pour utiliser des références de connexions, au lieu de connexions, de l’une des deux manières suivantes :

• Si le flux est exporté dans une solution non gérée et importé, les connexions sont supprimées avec les références de connexion.

• Lorsqu’un flux de solution est ouvert, le vérificateur de flux sur la page des détails du flux affiche un avertissement pour utiliser les références de connexion. Le message d’avertissement a une action que vous pouvez sélectionner pour Supprimer les connexions afin que des références de connexion puissent être ajoutées. La sélection de cette action supprime les connexions du déclencheur et les actions dans le flux et permet de sélectionner et de créer des références de connexion.

Ajout d’un objet à une solution (automatisation)

Vous pouvez utiliser les commandes PowerShell pour déplacer des applications en bloc vers une solution. L’ajout d’applications canevas et de flux de cloud préexistants aux solutions peut également être effectué via la ligne de commande. Installez les modules PowerShell les plus récents pour essayer cette option. Les deux commandes principales sont Set-PowerAppAsSolutionAware et Set-FlowAsSolutionAware.

Une fois les modules installés, insérez votre propre ID d’environnement, ID d’application, ID de flux et ID de solution.

Pour une application canevas :

Set-PowerAppAsSolutionAware -EnvironmentName {Environment ID} -AppName {App ID} -SolutionId {Solution ID}

Pour un flux :

Set-FlowAsSolutionAware -EnvironmentName {Environment ID} -FlowName {Flow ID} - SolutionId {Solution ID}

Les références de connexion sont des entrées de données dans la table référence de connexion. Pour utiliser la référence de connexion dans le cadre de l’application ou du flux, une modification de la définition de l’application ou du flux est nécessaire. Vous devez remplacer le nœud connectionReferences par la référence de connexion.

Importation et exportation d’une solution

En supposant que les solutions soient prêtes, la prochaine étape de l’automatisation peut être effectuée de plusieurs manières :

• Exportez et importez manuellement les solutions dans l’environnement cible.

• Utilisez des packages pour déplacer plusieurs solutions en une seule fois.

• Utilisez les tâches des outils de création de Power Platform pour effectuer plusieurs opérations, comme compresser une solution, décompresser une solution, exporter une solution et importer une solution. DevOps offre la possibilité d’automatiser la gestion du cycle de vie des applications (ALM) et ces tâches sont toutes conçues pour prendre en charge ALM pour Microsoft Power Platform.

L’interface de ligne de commande (CLI) de Power Platform fournit également des options pour exporter et importer des solutions. Toutes les commandes liées aux solutions peuvent être utilisées pour créer, exporter et importer des solutions. Vous pouvez également utiliser CLI pour transférer des données entrantes et sortantes.

Une option conviviale consiste à utiliser des pipelines destinés à démocratiser ALM pour Power Platform. Le regroupement des fonctionnalités d’automatisation ALM et d’intégration continue/déploiement continu (CI/CD) dans un seul service de fonctionnalités est plus accessible pour tous les créateurs, administrateurs et développeurs.

Création de connexions (manuelle)

Dans l’environnement cible, avant que l’opération d’importation ne soit définie, créez les connexions manquantes requises par l’application ou le flux. Pour plus d’informations sur la façon de créer des connexions, voir Gérer les connexions dans Power Automate.

Migration des données

Il existe plusieurs options disponibles pour la migration de données, allant de l’automatisation manuelle à l’automatisation complète.

• Exportez et importez manuellement les données à l’aide de classeurs Excel.
• Un flux de cloud Power Automate peut être développé pour extraire des données des tables sources et les écrire directement dans la destination. Toutefois, cela nécessite que le créateur utilise Dynamics 365 Connector ou le connecteur Dataverse (hérité). Actuellement, le connecteur Dataverse ne prend pas en charge la connexion entre les environnements. Cette fonctionnalité est prévue dans le futur et, une fois publiée, elle pourra être utilisée pour déplacer des données d’un environnement à l’autre.
• L’outil de migration de configuration (CMT) est un outil utilisé pour la migration de portail, mais peut également être utilisé pour la migration de données régulière. CMT peut également être utilisé avec PowerShell. L’outil PAC CLI offre la possibilité d’appeler CMT.
• Les flux de données peuvent être utilisés pour créer des mappages entre les environnements et pour déplacer des données. Le connecteur Web HTTP peut être utilisé comme alternative à Dataverse.
• Azure Data Factory peut être utilisé avec le connecteur Dataverse pour extraire des données de la source et les insérer dans la destination.

Étant donné que l’environnement par défaut est de taille limitée, l’une des options ci-dessus devrait suffire pour déplacer les données en dehors de l’environnement par défaut.

Considérations relatives au nettoyage

Un nettoyage est une bonne idée pour les applications et les flux qui n’ont pas été utilisés ni mis à jour depuis longtemps. Il existe différents aspects à prendre en compte pour un administrateur en ce qui concerne le nettoyage.

• Décidez de l’ordre d’importation des données. Les tables les moins dépendantes vont en premier et les plus dépendantes viennent à la fin.
• Il n’est pas nécessaire de mapper tous les champs. Il n’est pas nécessaire de mapper des champs tels que Version, Date de modification, Date de création, et certains autres champs du système.
• Si vous souhaitez conserver la Date de création d’origine, mappez le champ source Date de création au champ OverRiddenCreatedOn dans la table de destination.
• Les données d’audit ne peuvent pas être migrées.
• N’activez aucun flux de travail ou flux déclenché en fonction de l’insertion de données, sauf si cela est prévu. Cela augmente le temps de migration des données.

Options de marquage

Le Starter Kit CoE ne dispose pas actuellement d’option de marquage. Cependant, il pourrait être une personnalisation que vous pourriez ajouter au Starter Kit.

Créez une table appelée Balises et configurez une relation plusieurs-à-plusieurs (N:N) avec les applications, les flux et d’autres tables d’inventaire. Vous pouvez ensuite créer une balise et associer ces enregistrements aux articles d’inventaire appropriés. Pour une meilleure expérience de l’utilisateur, vous pouvez intégrer une grille dans le formulaire Principal des applications, des flux et d’autres tables d’inventaire. Cette option est recommandée, car elle présente une cohérence référentielle.

Créez un champ de texte dans chaque table d’inventaire et utilisez-le pour capturer le texte (balise) que vous pouvez utiliser ultérieurement.

Si vous souhaitez une liste plus fixe, créez un groupe d’options global et ajoutez-le également à toutes les tables d’inventaire et à leurs formulaires.

Option de quarantaine

Si vous n’êtes pas sûr de la nécessité de certaines applications, vous pouvez essayer de les isoler pendant un certain temps et de les mettre en quarantaine pendant cet état. L’application ne peut être utilisée que par le propriétaire. Après un intervalle de temps approprié et si aucune réponse du propriétaire n’a été reçue, vous pouvez les supprimer de l’environnement.

Les flux ne prennent pas en charge l’état de quarantaine, mais une approche similaire peut être utilisée en arrêtant le flux et en vérifiant s’il est réactivé par le propriétaire.

Dans les deux cas, il est important d’avoir une bonne communication avec le propriétaire.

Option de suppression uniquement

S’il n’y a vraiment aucune perte de productivité ni réutilisation des objets, cette option est la meilleure. La plupart des flux et applications de test entrent dans cette catégorie.

Dans ce cas, une fois la liste d’objets identifiée, un lot PowerShell peut être développé et une liste csv lui est transmise, ce qui supprime tous ces actifs.

Lorsque vous parcourez les ID d’applications et de flux, la commande suivante peut être utilisée pour les supprimer de l’environnement par défaut.

• Remove-AdminFlow -EnvironmentName Default-[Guid] -FlowName [Guid]
• Remove-AdminPowerApp -AppName [Guid] -EnvironmentName [Guid]

Option de sauvegarde et de suppression des objets

À titre d’exemple, supposons qu’un flux Power Automate soit créé pour répondre à un besoin saisonnier spécifique, mais qu’il n’a pas été utilisé depuis longtemps. Dans ce cas, il est recommandé de faire une sauvegarde du composant avant de le supprimer.

Pour effectuer une sauvegarde du composant, les options de migration individuelle ou de migration de masse peuvent être utilisées pour générer une solution exportée. Celle-ci peut ensuite être ajoutée à un référentiel de fichiers de votre choix ou à un emplacement OneDrive.

Une fois la sauvegarde sécurisée, vous pouvez appliquer l’option Supprimer pour terminer le processus de nettoyage.

Dans de nombreux cas, il s’agit de flux et d’applications de test créés par les créateurs dans le cadre de leur apprentissage et expérimentation de la productivité personnelle.

Conclusion

Power Platform est un outil destiné aux développeurs citoyens et aux développeurs professionnels. L’utilisation de l’environnement par défaut doit principalement se concentrer sur la productivité personnelle en utilisant les produits Microsoft 365. Le développement de toutes les autres applications et de tous les autres flux doit se produire dans des environnements partagés, individuels ou de développeur désignés. Une forte recommandation consiste à développer une stratégie d’environnement indépendante basée sur la stratégie DLP, qui peut aider les créateurs à développer leurs applications et flux dans l’environnement correct. Il est également utile d’établir une stratégie de communication et de fournir aux utilisateurs des modèles en libre-service d’apprentissage de la stratégie, de l’implémentation de solutions et des meilleures pratiques pour développer des applications et des flux. Un bon ajout consiste à capturer quelques témoignages de réussite sur le site de communication. Les témoignages de réussite publiés en interne aident les créateurs à se connecter aux idées et à les rendre ouvertes aux possibilités qui peuvent être réalisées avec Power Platform.

Une stratégie de gouvernance solide est essentielle lors de la migration ou du déplacement d’objets spécifiques. Il existe diverses stratégies disponibles pour la migration d’objets, notamment la migration individuelle et de masse. L’option la mieux adaptée dépend des stratégies de notre organisation. Les solutions sont la méthode la plus recommandée pour organiser les composants de votre application et simplifier les migrations.