Modernisation des applications avec Power Platform

Dans le paysage numérique actuel en évolution rapide, les entreprises sont confrontées au défi constant de moderniser leurs applications héritées pour suivre le rythme de l’évolution des besoins commerciaux. La modernisation des applications est cruciale pour améliorer l’efficacité opérationnelle, améliorer l’expérience client et garder une longueur d’avance sur la concurrence. Microsoft Power Platform offre une suite complète d’outils et de technologies qui permettent aux entreprises de transformer et de moderniser leurs applications de manière rapide et efficace.

Ce livre blanc explore les avantages, les stratégies et les pratiques recommandées de modernisation des applications avec Microsoft Power Platform. Il fournit des informations et des conseils sur la façon dont la plateforme low-code Microsoft peut vous aider à garantir le succès de vos efforts de modernisation des applications dans le cadre de la transformation numérique de votre organisation.

Astuce

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

Introduction

Les applications héritées présentent de nombreux défis pour les organisations. Ces applications reposent souvent sur des piles et des cadres technologiques obsolètes, ce qui les rend difficiles à intégrer aux systèmes et outils modernes. Elles présentent souvent des limitations en termes d’évolutivité et de performances qui entravent la capacité d’une organisation à gérer les charges de travail croissantes et les demandes des clients. Les applications héritées manquent de flexibilité et d’agilité, ce qui limite leur capacité à s’adapter rapidement à l’évolution des besoins de l’entreprise et à la dynamique du marché. Les failles de sécurité, les coûts de maintenance élevés, les capacités d’intégration limitées et le risque de dépendance vis-à-vis des fournisseurs aggravent encore les défis des applications héritées. Pour les surmonter, les entreprises doivent moderniser leur infrastructure applicative afin de tirer parti des nouvelles technologies.

Les capacités de développement low-code de Microsoft Power Platform permettent de créer et de déployer des applications modernes de manière plus rapide et rentable qu’auparavant. Intégrez facilement vos systèmes et sources de données existants pour un échange de données et une collaboration transparents. Ajoutez l’intelligence artificielle pour améliorer les expériences utilisateur, automatiser les processus et obtenir des informations précieuses à partir de vos données. Que vous soyez un développeur citoyen qui bricole sur les bords ou un développeur professionnel travaillant sur une personnalisation complexe, vous pouvez conduire la transformation numérique de manière intuitive, rapide et à moindre coût qu’avec les approches traditionnelles.

Pourquoi Power Platform ?

Les outils et technologies complets qui composent Power Platform réduisent considérablement la durée, le coût et les exigences de développement des projets de modernisation et de transformation numérique. Son approche low-code réduit, voire élimine, le besoin de ressources coûteuses en matière de codage, de science des données et d’ingénierie de l’IA. Les développeurs citoyens et les développeurs professionnels en bénéficient. Les développeurs citoyens peuvent jouer un rôle actif dans le processus de modernisation, en créant des applications directement basées sur leur expertise du domaine et en réduisant leur dépendance vis-à-vis des équipes informatiques. Les développeurs professionnels peuvent fournir des solutions même complexes en beaucoup moins de temps, ce qui leur permet de passer plus rapidement au projet suivant.

Produits et concepts Power Platform

Chaque produit de la famille Power Platform a un domaine d’intérêt unique. Les organisations peuvent mettre en œuvre les produits individuellement ou en combinaison pour répondre à leurs besoins spécifiques. Les produits sont interconnectés, formant un tout homogène, quelle que soit la manière dont ils sont combinés.

Le tableau suivant offre un aperçu général de chaque produit Power Platform.

Product	Description
Power Apps	Créez des applications personnalisées dans un canevas intuitif par glisser-déposer. Avec plus d’un millier de connecteurs, les sources de données et les services internes et externes ne sont qu’à quelques clics. Vos applications peuvent s’exécuter dans un navigateur, sur le bureau ou sur des appareils mobiles.
Power Automate	Créez des flux de travail pour automatiser même les processus complexes. Incorporez des sources de données et des services internes et externes à l’aide de connecteurs intégrés et personnalisés. Utilisez l’automatisation des processus numériques (DPA) lorsque les applications disposent d’une interface de programmation d’application (API). Utilisez l'automatisation robotisée des processus (RPA) pour automatiser les tâches répétitives effectuées dans un navigateur ou une application de bureau. Déclenchez les flux de travail pour s’exécuter lorsque des événements se produisent dans d’autres systèmes et services, ou planifiez-les pour s’exécuter à une heure spécifique.
Copilot Studio	Création d’agents conversationnels en utilisant une interface graphique sans code. Vous pouvez déployer des agents sur plusieurs canaux, y compris des sites web, des applications mobiles et des plateformes de messagerie comme Microsoft Teams. La création assistée par l’IA peut accélérer la création de rubriques. Les réponses génératives peuvent trouver et présenter des informations provenant de sources multiples sans nécessiter la création de rubriques.
Power BI	Faites glisser des graphiques, des tableaux et d’autres éléments visuels vers un canevas pour créer facilement des rapports sophistiqués qui révèlent des informations contenues dans vos données. Incluez le Machine Learning automatisé pour la modélisation prédictive et les visualisations d’IA avec des arborescences hiérarchiques pour des explorations détaillées de l’analyse des causes profondes. Explorez vos données en posant des questions en langage naturel dans un format simple de questions-réponses.
Power Pages	Créez rapidement des sites web attrayants et axés sur les données sur une plateforme Software as a service (SaaS) sécurisée, de qualité professionnelle et low-code. Grâce à des modèles riches et personnalisables et à une expérience visuelle fluide, la création, l’hébergement et l’administration de sites web d’entreprise modernes orientés vers l’extérieur sont plus faciles.

La famille de produits Power Platform se base sur quelques capacités et concepts de support. Le tableau suivant décrit les éléments les plus importants à comprendre.

Concept	Description
Power Fx	Power Fx est un langage low-code open source inspiré des formules Excel. Fortement typé, déclaratif et fonctionnel, avec une logique impérative et une gestion des états, le tout exprimé dans un texte convivial, Power Fx facilite les tâches de programmation courantes pour les développeurs citoyens et les développeurs professionnels. Il prend en charge le spectre complet du développement, depuis le sans code pour ceux qui n’ont jamais fait de programmation auparavant au « pro-code » pour les professionnels expérimentés, ce qui permet aux diverses équipes de collaborer et d’économiser du temps et des dépenses.
Connecteurs	Les connecteurs sont essentiels pour permettre au codage low-code et traditionnel de fonctionner ensemble pour fournir des applications modernes. Les connecteurs sont un wrapper autour d’une API qui permet à Power Apps et Power Automate d’utiliser des sources de données et des services internes et externes. Plus d’un millier de connecteurs prédéfinis sont disponibles, et vous pouvez créer les vôtres pour n’importe quelle API RESTful. La définition du connecteur inclut les métadonnées nécessaires pour faciliter l’utilisation de l’API par les applications low-code.
Dataverse	Dataverse est un magasin de données hybride à l’échelle du cloud basé sur des services de gestion des données Azure, mais c’est plus qu’une base de données. Il s’agit de la plateforme de données sous-jacente à la fois pour Dynamics 365 et Power Platform, avec une logique côté serveur sous la forme de flux de travail et de plug-ins, des règles métier et des flux de processus, un modèle de sécurité hautement sophistiqué et une plateforme de développement extensible avec prise en charge intégrée des applications multilingues et multidevises. Les applications peuvent être rapidement construites à partir du modèle de données, ce qui en fait l’un des moyens les plus rapides de déployer une solution de formulaire sur les données.
AI Builder	AI Builder facilite l’utilisation de l’intelligence artificielle dans Power Apps et Power Automate pour rechercher des informations dans vos données, automatiser des processus et rendre vos applications plus productives. Avec AI Builder, vous n’avez besoin de compétences en codage ou en science des données pour accéder à la puissance de l’IA. Les modèles prédéfinis et personnalisables sont prêts à l’emploi pour de nombreux scénarios métier courants, et vous pouvez créer vos propres modèles pour répondre à un besoin métier spécifique.
Copilot	L'assistance de l’IA de Copilot rend les utilisateurs et les développeurs Power Platform, citoyens ou professionnels, plus productifs, ce qui leur permet de consacrer plus de temps aux meilleures parties de leur travail et moins de temps aux tâches simples. Décrivez votre scénario d’entreprise à Copilot dans Power Automate et il peut convertir votre description en un flux de travail automatisé. Dites à Copilot dans Power Apps ce que vous voulez faire ou quelles informations vous voulez voir et il peut créer une application correspondante. Copilot configure les connexions, crée et remplit des tables, génère des écrans et propose même des suggestions pour améliorer votre flux ou votre application. Vos applications intégreront des expériences optimisées par copilote dès le premier écran, afin que vos utilisateurs puissent découvrir des insights lors d’une conversation.
Environnements et solutions	Les environnements sont des limites qui contiennent et facilitent la gestion et la sécurisation des ressources Power Platform. Ils sont également utilisés dans la gestion du cycle de vie des applications (ALM), dans laquelle les solutions sont développées et testées dans des environnements distincts avant d’être déployées dans un environnement de production. Les solutions sont des personnalisations et des extensions Power Platform mises en package. Une solution peut inclure des applications, des flux, des tables, des graphiques, des tableaux de bord, des connecteurs et d’autres composants dont la personnalisation ou l’extension a besoin. Les solutions peuvent être développées, testées et déployées en production dans des environnements distincts dans le cadre de la politique ALM d’une organisation. Vous pouvez exporter des solutions pour les partager avec d’autres utilisateurs ou organisations et importer des solutions à partir d’autres utilisateurs. Les solutions sont gérées ou non gérées. Les solutions non gérées sont utilisées pour le développement et les tests. Les solutions gérées sont utilisées pour la production, le déploiement et la distribution.

Principaux avantages de Power Platform pour la modernisation des applications

Les avantages de la modernisation des applications à l’aide de Microsoft Power Platform s’étendent au-delà de la valeur commerciale initiale d’une solution qui utilise des technologies modernes.

• Réduction des coûts. Les organisations peuvent économiser de l’argent sur le développement et la maintenance d’applications. Une étude réalisée par Forrester Consulting a révélé que les entreprises qui utilisent Power Platform peuvent voir une réduction de 45 % des coûts de développement d’applications et obtenir un retour sur investissement de 140 %.

• Développez le pool de ressources et éliminez les goulots d’étranglement. Les développeurs professionnels, les scientifiques des données et les ingénieurs en IA sont très bien payés et très demandés. Les petites et moyennes entreprises n’ont souvent pas le luxe d’une expertise interne en matière de codage et l’externalisation est coûteuse. Le low-code Power Platform est plus accessible par un plus grand groupes de ressources. Les experts en la matière et les employés ayant une expertise des processus métier peuvent aider à accélérer les efforts de modernisation, même s’ils n’ont jamais écrit une ligne de code.

• Construisez le chariot, ne réinventez pas la roue. Le développement de logiciels traditionnels repart à zéro à chaque fois, réinventant la roue à chaque nouveau projet. Avec des produits Power Platform low-code, intuitifs et conviviaux comme vos roues, vous pouvez vous concentrer sur la création d’un meilleur chariot, en améliorant vos processus métier, et profiter plus rapidement des avantages de vos efforts de modernisation.

• Réduisez la dette technique. Le coût, à la fois financier et en opportunités perdues, de la mise à niveau de solutions logicielles « rapides et sales » et de la maintenance de l’infrastructure existante est élevé. Power Platform réduit cette dette technique en rendant plus facile et moins coûteux de créer des solutions dès la première fois, en simplifiant l’intégration et la gouvernance des données avec un Common Data Model et des connecteurs, en fournissant une plateforme centralisée pour la gestion des solutions et en soutenant l’amélioration continue grâce à l’analyse et à l’IA.

• Améliorez la sécurité et garantissez la conformité. Tous les produits Power Platform incluent la sécurité, la conformité et la gouvernance de niveau entreprise entièrement intégrées et prêtes à l’emploi, en commençant par les environnements dans lesquels ils s’exécutent. Les environnements gérés sont une suite d’outils qui permettent aux administrateurs de gérer Power Platform à grande échelle avec plus de contrôle et moins d’efforts. Entre autres fonctionnalités, vous pouvez limiter qui peut partager quels flux et applications et avec qui, et utiliser des stratégies pour restreindre les connecteurs que les créateurs peuvent utiliser. Avec les modèles de sécurité des données natifs et flexibles, chaque application n’a pas besoin de construire son propre modèle de sécurité.

• Modernisez selon l’utilisation. Plus les applications que vous souhaitez moderniser sont importantes, moins il est probable que vous souhaitiez toutes les remplacer en même temps. Une approche low-code se prête bien à la création de solutions par incréments gérables.

• Intégrez des applications héritées. Les applications plus anciennes n’ont souvent pas d’API. Les fonctionnalités RPA de Power Platform peuvent automatiser les applications classiques et les inclure dans vos nouveaux processus métier modernes. La RPA peut également être utile pour moderniser progressivement des applications volumineuses et complexes.

• Innovez sans dépenser plus. Les fonctionnalités Power Platform continuent de s’améliorer. Les applications construites sur la plateforme bénéficient des innovations Microsoft sans plus de coûts pour vous.

• Augmentez la productivité des travailleurs dans un lieu de travail moderne. Power Platform fait partie du lieu de travail moderne de Microsoft. Les applications modernisées sur la plateforme peuvent tirer parti des fonctionnalités de Microsoft 365, notamment des expériences mobiles attrayantes et une collaboration simple et intuitive. L’IA de pointe comme Copilot, AI Builder et les fonctionnalités qui seront bientôt annoncées rendent les utilisateurs et les développeurs plus productifs avec moins de frustration et des courbes d’apprentissage moins profondes.

Innovation pour l’employé de première ligne

Les travailleurs de première ligne ont besoin d’applications modernes qu’ils peuvent utiliser sur n’importe quel appareil, où qu’ils travaillent. Ils ont besoin d’accéder à des informations en temps réel pour prendre de meilleures décisions plus rapidement. Ils doivent collaborer avec leurs collègues et la direction pour que tout fonctionne bien. Lorsqu’American Airlines a décidé de moderniser certains aspects de ses opérations, elle a obtenu tout cela et plus encore.

En partenariat avec Microsoft, American Airlines a créé ConnectMe, une application Microsoft Teams basée sur Power Apps et Azure. En utilisant l’application sur n’importe quel appareil mobile, les équipes de première ligne ont à portée de main des informations clés sur l’arrivée, l’embarquement, les bagages et les portes d’embarquement en temps réel, ce qui rationalise les opérations au sol, accélère les temps de rotation des avions et rend les voyages plus agréables pour les clients. En savoir plus sur la transformation de la compagnie aérienne.

Autonomisation de l’IA pour les travailleurs du savoir

Les travailleurs du savoir nagent dans un océan de données et, trop souvent, ils ont l’impression de se noyer. Presque toutes les applications collectent des données. Peu d’entre elles aident les utilisateurs à donner un sens aux données qu’ils collectent, et encore moins à obtenir des informations susceptibles d’aider les travailleurs à mieux faire leur travail. Des fonctionnalités d’IA peuvent être ajoutées aux applications dans le cadre de la modernisation, non seulement pour automatiser la collecte et l’analyse des données, mais aussi pour permettre aux travailleurs du savoir de repérer plus facilement les modèles et les tendances. L’analyse prédictive peut utiliser des modèles d’IA pour prévoir les résultats futurs sur la base de données historiques avec une grande précision, ce qui permet aux dirigeants de planifier en toute confiance. Les applications modernisées peuvent inclure l’IA de copilote, agissant en tant que partenaire pour générer du contenu en contexte, en résumant des entretiens, en rédigeant des messages marketing et commerciaux ciblés, et même en offrant des informations utiles en temps réel pendant qu’un représentant du service client ou un vendeur est au téléphone avec un client.

Un parcours progressif vers la modernisation des applications héritées

Si votre organisation est comme la plupart des autres, vous avez un arriéré croissant d’applications obsolètes qui bénéficieraient d’une modernisation. Les applications héritées utilisent généralement une technologie obsolète et reposent sur une infrastructure (matérielle et logicielle) qui n’est plus prise en charge. Souvent, seuls quelques employés, généralement ceux qui approchent de la retraite, savent comment elles fonctionnent. Les nouveaux employés ne veulent rien avoir à faire avec elles parce qu’ils ne peuvent pas utiliser les outils modernes auxquels ils sont habitués ou avec lesquels ils veulent travailler. Leur maintenance, sans parler de leur mise à jour, nécessite de gravir une montagne de dette technique qui augmente au fur et à mesure que vous grimpez. Des années, voire des décennies, de maintenance disparate aboutissent à une base de code à laquelle personne n’ose toucher, surtout lorsque la majeure partie de l’entreprise en dépend.

Souvent, les entreprises ne peuvent pas facilement remplacer toutes ces applications en même temps. Au lieu de cela, elles se lancent dans un parcours de modernisation progressive. Une approche progressive maximise les avantages de la modernisation tout en atténuant certains des risques liés à un effort de modernisation ponctuel.

Options de modernisation des applications

La modernisation ne signifie pas toujours la reconstruction d’une application héritée à partir de zéro. D’autres options sont de la retirer, de la remplacer, de la réhéberger, de la refactoriser et de la restructurer.

Le tableau suivant décrit chaque option, l’étape ALM au moment où elle est la plus appropriée et les facteurs qui peuvent influencer sa sélection.

Fin du cycle de vie

Migration

Modernisation

Mettre hors service

Replace

Réhéberger

Refactoriser

Réarchitecte

Reconstruire

Description

Supprimer l’application

Remplacer l’application par SaaS ou une autre application

Redéployer en l’état dans le cloud

Optimiser le code existant

Déplacer le code vers une nouvelle architecture d’application ou le décomposer en microservices

Réécrire l’application à partir de zéro avec l’étendue et les spécifications d’origine

Facteurs

N’est plus nécessaire

Réduire les dépenses

Réduire les dépenses d’investissement

Tirer parti des nouvelles technologies

Réduire les dépenses d’investissement

Récupérer le stockage des données

Retour sur investissement rapide du cloud

Mises à jour plus rapides et plus courtes

Code plus portable

Une plus grande efficacité du cloud en termes de ressources, de vitesse et de coûts

Améliorer les performances

Réduire la dette technique

Améliorer l’évolutivité, la fiabilité et la maintenabilité

Faciliter l’adoption de nouvelles fonctionnalités cloud

Combiner les piles technologiques

Accélérer l’innovation

Accélérer le développement

Réduire les dépenses opérationnelles

Technologies Microsoft

Power Apps

Dynamics 365

Azure IaaS

Azure VMWare

Power Platform

Conteneurs

Azure PaaS

Power Platform

Azure PaaS

Microservices sans serveur

Power Platform

Azure PaaS

Microservices sans serveur

Le tableau suivant suggère comment une approche low-code peut s’appliquer à chacune des options de modernisation des applications.

Option	Description
Réhéberger	Le réhébergement déplace une application telle quelle d’un environnement plus ancien vers un environnement plus récent. Une approche low-code ne s’applique pas directement, mais le réhébergement peut être la première étape avant d’appliquer d’autres stratégies qui incluraient des solutions low-code.
Refactoriser ou réorganiser	La refactorisation modifie le code afin que les applications puissent tirer le meilleur parti d’un environnement axé sur le cloud. La refonte de l’architecture modifie considérablement le code. Cela peut inclure l’encapsulation de la logique existante en la déplaçant vers une API qui peut être exposée à des solutions low-code via un connecteur.
Remplacer ou recréer	Le remplacement remplace une application par une autre. La reconstruction recrée une application à partir de zéro. Il s’agit généralement de cette option lorsqu’une approche low-code permet d’obtenir les meilleurs résultats commerciaux. Commencer par une application de Dynamics 365 ou Microsoft AppSource peut aider à accélérer la modernisation lorsque le cas d’utilisation correspond à une fonctionnalité prédéfinie. Les organisations peuvent ensuite utiliser des composants Power Platform pour personnaliser l’application en fonction de leurs besoins uniques.

L’approche low-code de Power Platform a le potentiel d’offrir bien plus qu’un autre outil de développement. L’intégration du low-code dans votre stratégie d’applications modernes peut également jeter les bases pour permettre aux non-développeurs, comme les experts en la matière, de participer à votre effort de modernisation. Les organisations ont constaté que l’établissement d’un centre d’excellence (CoE) autour de Power Platform et l’utilisation d’outils tels que le Starter Kit CoE pour créer des directives et une gouvernance aident les utilisateurs à créer des applications et des automatisations low-code avec succès et garantissent que les actifs tels que les API et les composants peuvent être réutilisés. Le low-code peut accélérer le développement d’applications et aider les organisations à extraire plus rapidement de la valeur de leurs données, quel que soit l’endroit où elles se trouvent. En fait, de nombreuses organisations décident d’intégrer un état d’esprit low-code dans leur culture.

Un guide pour votre parcours de modernisation

Il est facile de se sentir dépassé lorsque vous commencez à penser à moderniser les applications héritées. Un guide peut vous aider à planifier votre parcours et à vous maintenir sur le bon chemin tout au long du parcours. Un bon point de départ est ces trois étapes, en considérant chacune d’entre elles avec un état d’esprit low-code.

1. Planification. Réfléchissez bien à vos objectifs de modernisation d’une application héritée et définissez votre stratégie pour les atteindre. Énoncez clairement le problème que vous souhaitez que la modernisation résolve. C’est le moment d’évaluer vos applications et vos environnements en gardant un œil sur ce qui ne fonctionne pas, ce qui fonctionne mais pourrait être amélioré et, surtout, quelle valeur, pour l’entreprise ou pour les utilisateurs, résulte de tout changement. Évaluez chaque opportunité de modernisation pour déterminer son potentiel à tirer parti d’une approche low-code. Priorisez les opportunités qui intègrent des solutions low-code. Utilisez l’Évaluateur de stratégies d’adoption du cloud pour créer une analyse de rentabilité pour la modernisation des applications.

2. Mise en œuvre. Modernisez vos applications non seulement de manière incrémentielle, mais aussi de manière itérative. Une approche itérative donne aux organisations la flexibilité nécessaire pour modifier la portée ou la stratégie de leur projet selon leurs besoins. Les solutions low-code Power Platform peuvent être développées et testées plus rapidement que les applications développées traditionnellement, et le déploiement dans les environnements gérés ne nécessite que quelques étapes. Bien que le low-code nécessite moins de perfectionnement que le codage traditionnel, assurez-vous que vos employés sont correctement formés à la façon de travailler en tant qu’équipes de fusion, qui mélangent des ressources low-code et traditionnelles.

3. Opérations. La modernisation des applications ne s’arrête pas à la mise en œuvre. Avec une approche low-code axée sur le cloud, vous pouvez utiliser des services et des outils de plateforme cloud pour sécuriser, régir, gérer et optimiser vos applications.

Évaluer les opportunités de solutions low-code

Les organisations utilisent diverses méthodes, de l’examen informel aux arbres de décision détaillés, pour déterminer si une approche low-code est la bonne façon de moderniser une application héritée. La chose la plus importante à prendre en compte est que le low-code n’est pas une décision du tout ou rien. Il est courant de créer une partie d’une application à partir de composants Power Platform et une partie à partir de composants développés à l’aide de techniques de codage traditionnelles.

Pour évaluer une application, nous vous recommandons de déterminer d’abord si elle est toujours nécessaire et utile ou si elle doit être retirée. Si vous décidez qu’elle est toujours nécessaire, évaluez si une solution low-code peut remplacer l’application dans son ensemble. Si l’application entière n’est pas adaptée à un remplacement low-code, évaluez si une ou plusieurs charges de travail ou composants de l’application pourraient l’être. Vous constaterez peut-être qu’une solution low-code étendue à un code développé de manière traditionnelle offre le meilleur des deux mondes.

Par exemple, si vous déterminez qu’une application n’est pas adaptée parce qu’un contrôle obligatoire est manquant dans Power Apps, vous pouvez utiliser Power Apps component framework (PCF) et le code traditionnel pour créer un contrôle personnalisé. Un autre exemple est une application qui a une logique complexe. Vous pouvez centraliser la logique dans une API à laquelle Power Apps peut accéder à l’aide d’un connecteur personnalisé. Dans ces deux exemples, l’extensibilité de Power Platform a permis de créer la majeure partie de l’application avec des composants low-code, comblant ainsi les lacunes avec le code développé traditionnellement.

NSure.com, une plateforme propriétaire d’achat d’assurance en ligne, offre un exemple concret. Le lancement initial de la société s’appuyait sur les services traditionnels Angular, Xamarin et Azure. En ajoutant Power Platform et Dynamics 365, NSure.com a créé une solution de nouvelle génération en utilisant à la fois des techniques de codage low-code et traditionnelles, comme l’illustre le diagramme suivant. En savoir plus sur le parcours de la société.

Il est tout aussi important d’identifier les opportunités low-code que de reconnaître quand une approche low-code n’est pas la bonne. Les tableaux suivants décrivent des cas d’utilisation qui ne conviennent généralement pas aux solutions low-code. Les organisations sont confrontées à des défis différents au niveau du front-end et du back-end, nous allons donc les considérer séparément.

Scénarios front-end qui ne correspondent pas à une approche low-code

Scénario	Défi
L’appareil de l’utilisateur n’est pas compatible	Power Platform reconnaît les appareils mobiles et les appareils spécialisés tels que les lecteurs de codes-barres. Les périphériques qui dépendent d’API ou de pilotes spécifiques peuvent ne pas être pris en charge et nécessiter une approche plus traditionnelle.
Gros volume de données côté client	L’expérience utilisateur dans certaines applications nécessite de grandes quantités de données, un défi pour toute technologie, et pas seulement pour le low-code. Le téléchargement et le traitement d’une telle quantité de données peuvent mettre à rude épreuve les systèmes back-end et dégrader les performances de l’application et de l’appareil sur lequel elle s’exécute. Les utilisateurs ne sont pas aussi productifs lorsqu’ils sont contraints de naviguer dans un océan de données. Avant de vous tourner vers les méthodes de codage traditionnelles pour gérer la charge, déterminez si un filtrage et une navigation appropriés peuvent offrir une meilleure expérience utilisateur.
Exigences hors ligne complexes	Les applications qui doivent fonctionner dans des endroits où la connectivité est médiocre ou inexistante peuvent être difficiles à mettre en œuvre et à prendre en charge, qu’elles utilisent du code low-code ou traditionnel. Power Apps offre une fonctionnalité de base pour des scénarios hors ligne simples. Par exemple, une application qui capture des prospects lors d’un événement et les télécharge dans une base de données marketing après l’événement fonctionnerait correctement. Pour les applications qui nécessitent des fichiers et des images, des connecteurs autres que Dataverse ou une résolution de conflits complexes, vous devez vous tourner vers les techniques de code traditionnelles.

Scénarios back-end qui ne correspondent pas à une approche low-code

Scénario	Défi
Données à grande vitesse	L’importation de millions de lignes de données dans le cadre de migrations et d’événements similaires est généralement prise en charge. Toutefois, les charges de travail qui impliquent le traitement de millions de lignes de données toutes les heures ou tous les jours doivent faire l’objet d’une évaluation plus approfondie. Par exemple, la collecte de gros volumes de données de télémétrie de l’Internet des objets (IoT) dans Dataverse n’aurait pas de sens. Au lieu de cela, les services cloud Azure peuvent être utilisés pour collecter et analyser les données et les signaux pertinents ajoutés à Dataverse pour déclencher des actions dans l’application. Les applications qui impliquent un gros volume de mises à jour régulières des données Dataverse peuvent nécessiter l’aide du code traditionnel pour mettre à l’échelle les mises à jour.
Charges de travail en arrière-plan avec une logique complexe	Les charges de travail en arrière-plan qui impliquent une logique complexe ou un volume élevé d’appels d’API peuvent ne pas convenir à une solution low-code. Au lieu de cela, la logique peut être centralisée dans une API qu’une solution low-code peut appeler.
API qui utilisent des protocoles autres que RESTful	Les connecteurs Power Platform ne prennent en charge que les API REST. Si vous avez besoin de vous connecter à une autre API de style comme SOAP ou gRPC, fournissez votre propre API REST qui communique avec celle incompatible.

Nous vous recommandons de suivre les vagues de lancement Power Platform, car elles continuent de combler les lacunes dans ce que vous pouvez faire avec les solutions low-code. La création d’une preuve de concept low-code est un bon moyen de déterminer si votre scénario est adapté.

Donner la priorité aux opportunités low-code

Lorsque vous évaluez votre portefeuille d’applications, il ne suffit pas d’identifier les bons candidats pour une transformation low-code. Votre équipe doit les hiérarchiser pour maximiser le succès de vos efforts de modernisation.

La définition des priorités doit tenir compte des facteurs suivants :

• La maturité low-code de votre organisation
• La complexité de l’opportunité
• Retour sur investissement pour l’organisation, les utilisateurs et le service informatique
• Délai de rentabilisation

Être réaliste quant aux capacités low-code de votre organisation peut vous aider à choisir une opportunité qui met votre équipe au défi de se développer, mais qui ne la pousse pas à échouer. Vous n’avez pas à choisir l’application la plus simple sans aucun défi. Une application idéale offrirait des opportunités d’explorer comment combiner le code traditionnel avec des solutions low-code.

Les applications avec une intégration complexe avec d’autres systèmes ne sont souvent pas le meilleur point de départ. Essayer de s’attaquer à des applications trop volumineuses ou trop complexes peut entraîner de la frustration et des échecs. Évitez ceux qui sont des candidats low-code douteux. Conservez-les pour une fois que votre équipe aura effectué quelques modernisations réussies.

Lors de la modernisation d’une application monolithique volumineuse, demandez-vous si vous pouvez moderniser de petites parties de celle-ci de manière incrémentielle. Les applications monolithiques étaient autrefois courantes. Désormais, les applications plus petites axées sur les rôles ou les tâches sont plus courantes. Elles permettent un développement incrémentiel, des améliorations et une mise à l’échelle des équipes qui les construisent.

Les premières modernisations sont importantes, car elles permettent à l’organisation de voir l’impact des solutions low-code. Il est important d’évaluer les avantages et les risques pour les parties prenantes d’une application lorsque vous hiérarchisez les opportunités. Choisir une application dont personne ne se soucie ou qui a un faible impact sur l’organisation ne sera pas la meilleure démonstration des avantages d’une solution low-code.

L’adoption de l’application modernisée par les utilisateurs est importante. Les utilisateurs ont besoin de sentir que leur nouvelle application low-code s’intègre au reste des applications qu’ils utilisent. Un autre risque pour l’adoption est le degré de personnalisation auquel ils sont habitués. S’ils s’attendent à une expérience hautement personnalisée, ils seront peut-être moins enclins à adopter une solution low-code moins personnelle.

Organiser et perfectionner vos équipes

Les organisations qui réussissent à moderniser leurs applications héritées ne se contentent pas d’attribuer un projet de modernisation à une équipe de développeurs de code traditionnels en espérant qu’ils réussissent. Il est important de donner à votre équipe les connaissances et la confiance nécessaires au développement low-code pour mener à bien un effort de modernisation.

Une équipe de ressources low-code travaillant aux côtés de ressources de code traditionnelles est appelée équipe de fusion. Les équipes de fusion sont conçues pour encourager la collaboration en formant les deux types de ressources à l’intégration de solutions low-code au code traditionnel. Un architecte de solution établit comment la solution est architecturée entre le code low-code et le code traditionnel.

Bien qu’il soit facile d’attribuer par défaut tout le travail aux développeurs traditionnels, les efforts de modernisation low-code sont de bonnes opportunités pour élargir l’équipe de projet. De nombreux utilisateurs professionnels constituent d’excellentes ressources low-code. Ils peuvent accélérer le travail de l’équipe car ils comprennent déjà le problème de l’entreprise. Il leur suffit d’apprendre à effectuer les types de travail low-code pris en charge par l’équipe et de se familiariser avec les procédures de test et d’ALM. Cela peut impliquer d’apprendre à créer des applications dans Power Apps ou des flux de travail dans Power Automate. Ils doivent également comprendre ce que les codeurs traditionnels peuvent développer pour faciliter leurs efforts low-code. Cela ne signifie pas qu’ils doivent savoir écrire du code traditionnel.

Les ressources de code traditionnelles doivent avoir une connaissance de base des approches low-code et de la façon dont celles-ci diffèrent du code qu’elles écrivent généralement. Plus important encore, ils doivent apprendre les options d’extensibilité des solutions low-code. Ils doivent être à l’aise avec la création d’une application ou d’un flux de test qui utilise le code qu’ils écrivent pour s’assurer qu’il fonctionne et être prêts à prendre en charge des ressources low-code dans l’utilisation de leurs ressources d’extensibilité.

Les ressources low-code et code traditionnel doivent comprendre où commencent et se terminent les solutions low-code et les solutions de code traditionnel, et où elles se croisent.

Collecter les exigences

Vous constaterez peut-être que vous avez des applications qui datent d’une décennie ou plus et qui ne sont pas documentées. Elles peuvent nécessiter de l’ingénierie inverse ou des connaissances sur les utilisateurs métier pour les recréer. Il est important de se rappeler que même si une approche low-code est efficace, elle n’accélère pas la collecte des exigences et des connaissances sur les processus métier ni ne rend pas les exigences complexes moins complexes. Souvent, on s’attend de manière irréaliste à ce qu’une équipe qui modernise une application accomplisse autant qu’une équipe qui crée une nouvelle application avec le low-code. Établissez les attentes de votre organisation en tenant compte de ces défis.

Deux approches peuvent permettre d’accélérer l’acquisition de connaissances sur une application héritée. Tout d’abord, élargissez l’équipe pour inclure des utilisateurs métier ayant des connaissances du domaine. Deuxièmement, concentrez-vous sur la compréhension du processus métier et de ses résultats souhaités plutôt que de documenter la façon dont il est mis en œuvre dans le système existant. L’exception à cette règle est si l’application héritée nécessite une logique spécialisée qui exécute des règles métier que vous devez suivre.

Éviter de travailler contre les approches low-code

Les organisations qui débutent dans la modernisation d’applications avec des solutions low-code commettent souvent l’erreur de développer low-code de la même manière qu’elles développent du code traditionnel. Par exemple, une organisation pourrait appliquer les normes UX écrites pour les applications Angular à sa première mise en œuvre de Power Apps. L’équipe du projet passerait un temps inutile à essayer de répondre à des normes qui étaient conçues pour les capacités du cadre Angular et non pour les besoins de l’entreprise.

Les équipes qui ont l’habitude de travailler avec du code traditionnel peuvent tenter de minimiser le low-code. Par exemple, au lieu d’utiliser les contrôles Power Apps, l’équipe peut créer une application à partir des contrôles de Power Apps component framework afin d’éviter autant que possible d’utiliser le low-code. Il est préférable pour les équipes d’aller aussi loin que possible avec le low-code jusqu’à ce qu’elles rencontrent des bloqueurs qui ne peuvent pas être contournés. Les équipes qui apprennent à tirer parti des fonctionnalités de la plateforme réussissent mieux à tirer le meilleur parti du low-code. Le low-code devient de plus en plus capable de prendre en charge ce qui n’était auparavant possible qu’avec le code traditionnel. Dans le passé, un défi courant était de rester bloqué parce que le low-code ne pouvait pas reproduire certaines fonctionnalités nécessaires. Power Platform répond à ce défi avec des options d’extensibilité qui permettent aux applications low-code d’incorporer des composants spécialisés écrits dans le code traditionnel si nécessaire.

Les approches low-code peuvent jouer un rôle important dans vos stratégies de modernisation. Pour obtenir les meilleurs résultats, il faut un énoncé clair du problème que l’effort de modernisation est censé résoudre, une planification, une dotation en personnel qui va au-delà des rôles par défaut, de la formation et de l’établissement des priorités. Apporter les ajustements appropriés à leurs normes et processus si nécessaire aide également les organisations à réaliser tout le potentiel du low-code. Une modernisation réussie devrait améliorer la valeur commerciale globale des applications modernisées.

Les plateformes low-code ont évolué rapidement ces dernières années. Bien qu’elles aient toujours été douées pour prendre en charge des scénarios de productivité individuels, l’accent a récemment été mis sur les capacités de l’entreprise. Les organisations créent des applications low-code qui prennent en charge le lieu de travail moderne, y compris le travail hybride (à distance et sur site) et le besoin connexe de trouver des moyens d’encourager la collaboration. Les plateformes low-code comme Power Platform peuvent désormais évoluer pour gérer des applications sur lesquelles tous les utilisateurs d’une organisation peuvent se baser et qui peuvent s’intégrer dans les modèles de sécurité d’entreprise. En connectant les fonctionnalités low-code à l’infrastructure de l’entreprise, vous pouvez utiliser des techniques low-code côte à côte avec les méthodes traditionnelles. Le low-code fait abstraction d’une grande partie de la complexité et permet à un plus grand nombre de personnes de participer à l’élaboration de solutions.

Comprendre la structure de coûts d’une approche low-code

Une question que les organisations se posent souvent lorsqu’elles envisagent un effort de modernisation est de savoir combien cela coûtera. Bien qu’une discussion complète sur l’octroi de licences et l’analyse des coûts dépasse le cadre du présent document, nous pouvons explorer ces sujets à un niveau élevé.

Les produits Power Platform sont des produits sous licence. Vous pouvez les utiliser sous licence individuellement pour répondre à vos besoins. Vous pouvez configurer la facturation Azure pour le paiement à l’utilisation, qui permet une utilisation sans engagement ni achat de licence préalable et inclut une partie de l’utilisation dans l’application Power Automate. Power Automate dispose également de licences par utilisateur et par flux pour le travail autonome. La gestion des licences par flux fonctionne bien lorsque l’automatisation profite à l’ensemble de l’organisation. Les licences Power Apps peuvent être par utilisateur ou par application. Les sites Power Pages sont utilisés sous licence par utilisateur, site ou mois. Une licence supplémentaire est nécessaire pour les sites authentifiés. Toutes les licences incluent l’utilisation de connecteurs et de Dataverse, avec la possibilité d’utiliser sous licence plus de stockage et de requêtes d’API pour les scénarios à gros volume.

Tous les produits Power Platform ont une tarification par volume qui s’applique généralement aux efforts de modernisation des applications et qui doit être évaluée en fonction de la stratégie unique de chaque organisation.

Lorsque vous évaluez le coût du low-code par rapport au code traditionnel, il est essentiel de réaliser que la comparaison n’est pas de comparer des pommes avec des pommes. Avec le low-code, vous payez la main-d’œuvre nécessaire à l’implémentation d’un processus métier unique dans le produit low-code et la licence de produit pour l’utiliser. En général, la licence inclut plusieurs applications et automatisations sans que chacune d’entre elles ne nécessite plus de coûts.

Avec les approches de codage traditionnelles, vous payez pour la main-d’œuvre nécessaire à la mise en œuvre d’un processus métier unique dans le code, la main-d’œuvre nécessaire à la construction de l’infrastructure de l’application et les services cloud nécessaires pour prendre en charge l’application.

Toutes les solutions, qu’elles soient low-code ou code traditionnel, nécessitent une maintenance et un entretien continus. Cependant, les solutions low-code nécessitent moins de ressources pour le faire. Elles encourent également moins de dette technique car l’infrastructure de l’application est fournie par la plateforme.

Par rapport à une application entièrement personnalisée qui n’est pas construite sur une plateforme low-code, une solution low-code a un coût plus prévisible. Évitez de tomber dans le piège de comparer les licences low-code au coût initial du déploiement de code traditionnel.

Un coup d’œil dans Power Platform

Les composants Power Platform sont basés sur les mêmes services cloud Microsoft Azure que ceux disponibles si vous utilisez des méthodes de codage traditionnelles. L’intégration de ces composants entre eux et avec des fonctionnalités de sécurité, d’évolutivité et de reprise après sinistre a été réalisée pour vous.

Au sein de Dataverse

Dataverse est optimisé par plus de 25 services Azure entièrement gérés tels que Functions, Load Balancer, Cognitive Services, Synapse, DevOps, Active Directory et Microsoft Purview. Les fonctionnalités intégrées incluent une sécurité complète, des analyses puissantes, l’IA, une logique métier avancée et la gestion des événements, la modélisation des données et l’intégration à Dynamics 365, Microsoft 365, Azure, etc. Toutes ces fonctionnalités sont basées sur une couche de stockage Dataverse polyglotte, qui est basée sur Azure SQL DB (pour les données relationnelles), Azure Cosmos DB (pour NoSQL), le stockage blob Azure (pour les fichiers) et Azure Data Lake Storage Gen 2 (pour l’analyse à grande échelle et la conservation des données à long terme). Elles sont disponibles pour une utilisation transparente dans les composants low-code de Power Platform et via l’API REST Dataverse.

La haute disponibilité et la continuité d’activité et reprise d’activité (BCDR) sont importantes pour les applications stratégiques. Dataverse maximise la disponibilité avec les services de fiabilité Azure. La réplication des serveurs primaires et secondaires est synchrone, avec une structure en dessous qui peut détecter les défaillances et choisir un nouveau serveur principal en suivant les protocoles d’exactitude. Les basculements à haute disponibilité, qui se produisent dans une région Azure, sont transparents et rarement notés par les utilisateurs, et se produisent généralement en quelques secondes. Ils sont garantis de n’avoir aucune perte de données, que la panne soit planifiée ou non.

Les basculements de récupération d’urgence se produisent entre deux régions Azure. Pour garantir un basculement plus rapide avec une perte de données minimale, une copie continue de récupération d’urgence est conservée à l’aide de la réplication asynchrone. Les basculements planifiés n’entraînent aucune perte de données et, pour les environnements de production, peuvent généralement être effectués en quelques secondes ou quelques minutes.

En plus de la mise en œuvre technique de la haute disponibilité et du BCDR, l’équipe d’exploitation teste régulièrement son état de préparation à répondre à différents types d’événements.

Au sein de Power Automate

Les flux de cloud Power Automate sont basés sur Azure Logic Apps. Power Automate fournit des abstractions et l’intégration à d’autres composants low-code comme Power Apps et utilise le moteur d’exécution Logic Apps. Les développeurs qui connaissent Logic Apps trouveront que Power Automate utilise des concepts similaires, y compris le langage d’expression.

Au sein de Power Apps

Le moteur d’exécution Power Apps est basé sur le cadre React. Les applications sont intégrées dans le concepteur Power Apps, qui utilise une interface par glisser-déplacer pour créer des écrans. Les formules Power Fx implémentent la logique. Les connecteurs étendent l’accès des applications à d’autres services, logiques et composants qui permettent des extensions visuelles réutilisables. Les développeurs peuvent utiliser Power Apps Component framework (PCF) pour créer des contrôles personnalisés. Bien que de nombreux cadres d’interface utilisateur puissent être utilisés avec PCF, les fonctionnalités Power Apps intègrent la prise en charge de React.

Au sein des connecteurs

Les connecteurs utilisent Azure API Management pour gérer les informations d’identification et les connexions de chaque utilisateur.

La même architecture est utilisée pour tous les connecteurs, y compris les connecteurs personnalisés que vous créez pour vos propres API. L’utilisation d’Azure API Management garantit une interface cohérente pour les produits Power Platform comme Power Apps et Power Automate avec tous les connecteurs.

Une exception est le connecteur Dataverse. Il apparaît dans la liste des connecteurs pour les applications et les flux, mais il est implémenté différemment. Lorsqu’une application ou un flux utilise des données ou des actions Dataverse, l’interaction est directe via l’API OData de Dataverse.

Options d’extensibilité de Power Platform

L’extensibilité est une fonctionnalité clé qui différencie Microsoft Power Platform des autres plateformes low-code. L’un des principes directeurs de la plateforme est « pas de falaises » : vous ne devriez pas être empêché d’accomplir quelque chose en utilisant du low-code, même si cela nécessite un code traditionnel. Vous pouvez créer une charge de travail entière dans le cadre d’une application plus grande à l’aide de code traditionnel si nécessaire. Cependant, la plateforme offre de nombreuses options d’extensibilité qui permettent d’utiliser ensemble du code low-code et du code traditionnel dans la même charge de travail.

Le tableau suivant fournit une vue d’ensemble de certaines des options d’extensibilité courantes. Nous y reviendrons plus tard, lorsque nous discuterons de la façon d’aborder la modernisation et des modèles que vous pouvez appliquer.

Option	Description
API et connecteurs personnalisés	Les connecteurs personnalisés pour vos API REST centralisent la logique de l’application et lui permettent d’être exposée à des composants low-code de manière sécurisée et gouvernée. Vous pouvez utiliser cette approche dans une stratégie axée sur les API pour la modernisation des applications. Le connecteur personnalisé utilise un document OpenAPI pour définir comment un composant low-code peut interagir avec l’API REST. Par exemple, vous pouvez créer une API à l’aide de Azure Functions et la publier dans Azure Gestion des API. Azure API Management peut exporter une définition OpenAPI pour créer automatiquement le connecteur personnalisé à utiliser dans une solution low-code. Cette approche dissocie les applications clientes des API, ce qui leur permet d’évoluer indépendamment. Les API sont gérées de manière centralisée, ce qui ajoute une couche de sécurité en n’exposant pas directement l’API et en utilisant des techniques d’authentification telles que des clés d’abonnement, des jetons, des certificats client et des en-têtes personnalisés.
Power Apps Component framework	Power Apps Component framework est un cadre d’extensibilité permettant de créer des visuels personnalisés pour Power Apps et Power Pages. Les composants de code sont créés en utilisant HTML, Javascript ou TypeScript. Considérez les composants de code comme des blocs de construction d’interface utilisateur qui peuvent être réutilisés pour créer une ou plusieurs applications. Les composants incluent un manifeste qui définit comment un composant low-code peut interagir avec le composant de code. L’interface du composant permet au moteur d’exécution d’hébergement de communiquer les événements du cycle de vie du conteneur d’hébergement. Cela permet au composant de code de restituer ses visuels à l’aide des informations contextuelles fournies par le conteneur d’hébergement. Pour obtenir des idées, parcourez la galerie de la communauté, à l’adresse https://pcf.gallery.
Tables virtuelles	Les tables virtuelles facilitent l’intégration des données qui résident dans des systèmes externes. Elles représentent parfaitement les données externes sous forme de tables dans Microsoft Dataverse, sans répliquer les données et souvent sans avoir besoin de codage personnalisé. Dataverse est fourni avec des fournisseurs de données pour OData v4 et Azure Cosmos DB. Un fournisseur de connecteurs virtuels, actuellement en version préliminaire, étend les fournisseurs de données disponibles pour inclure un sous-ensemble des connecteurs Power Platform, y compris SharePoint et SQL Server. Pour des scénarios plus avancés, les développeurs peuvent créer des fournisseurs de données personnalisés. La création de fournisseurs de données personnalisés nécessite des connaissances approfondies des données externes et de Dataverse. La possibilité de créer des plug-ins Dataverse en utilisant Power Fx pour la logique est en version préliminaire.
Plug-ins Dataverse	Un plug-in Dataverse est un gestionnaire d’événements personnalisé qui s’exécute en réponse à un événement spécifique. Considérez les plug-ins comme des procédures stockées dans un moteur de base de données, mais écrites en .NET. Par exemple, des événements sont déclenchés lors du traitement d’une opération de données Microsoft Dataverse ou à la demande pour des événements d’API personnalisés. Le plug-in est implémenté en tant que classe personnalisée compilée dans un assembly .NET Framework qui peut être chargé et enregistré dans Dataverse. À l’aide d’une interface définie, le plug-in peut obtenir des informations contextuelles sur l’événement en cours de traitement. Les plug-ins peuvent s’exécuter dans le cadre de la transaction Dataverse et peuvent effectuer d’autres opérations de données qui font partie de la transaction actuelle. Les plug-ins sont destinés aux petites unités de travail. Leurs performances doivent être optimisées afin qu’elles n’affectent pas négativement les performances globales. Les plug-ins sont toujours exécutés, quelles que soient les opérations de l’interface utilisateur ou de l’API, ce qui en fait un moyen puissant d’appliquer de manière cohérente la logique métier.

Exploration des scénarios d’architecture de modernisation low-code

Comme avec la plupart des plateformes, vous pouvez composer un nombre infini de scénarios d’architecture à l’aide de composants Power Platform et d’autres services cloud Microsoft. Dans cette section de l’article, nous explorons certains des scénarios les plus courants et discutons de certaines considérations que vous devez garder à l’esprit lorsque vous les utilisez.

Expériences des applications

La modernisation de l’expérience utilisateur peut faire une grande différence pour les utilisateurs. Power Apps est le principal moyen de créer des expériences d’applications internes avec Power Platform. Vous pouvez utiliser Power Pages pour les applications web internes, mais il est plus courant pour les applications externes.

Power Apps

Les charges de travail doivent être conçues de manière à ce que les utilisateurs puissent effectuer une grande partie de leur travail sans changer d’application. Lorsque vous modernisez une application monolithique volumineuse, vous pouvez diviser ses fonctionnalités en plusieurs applications. En revanche, si les utilisateurs doivent travailler avec plusieurs applications, vous pouvez les consolider dans une seule application qui présente une vue unifiée de leurs multiples sources de données.

Le tableau suivant décrit les deux types d’applications que vous pouvez créer avec Power Apps : les applications canevas et les applications pilotées par modèle.

Type d’application	Description
applications canevas	Les applications canevas sont hautement personnalisables. Elles se composent d’un ou plusieurs écrans avec lesquels les utilisateurs interagissent. Vous contrôlez la disposition de chaque écran et la navigation entre les écrans. Les applications canevas fonctionnent avec les données utilisant des connecteurs. Une seule application peut fonctionner avec plusieurs connecteurs, ce qui la rend idéale pour l’intégration dans plusieurs sources de données en tant qu’application composite.
Applications pilotées par modèle	Les applications pilotées par modèle utilisent Dataverse comme source de données principale. Elles se composent d’une ou plusieurs pages, qui peuvent être des tables Dataverse ou des pages personnalisées. Une page de table Dataverse peut être explorée jusqu’à une page de détails pour l’afficher et la modifier. Les pages personnalisées peuvent intégrer un écran d’application canevas et des données provenant des connecteurs. Les applications pilotées par modèle ont une structure de navigation intégrée personnalisable. Il est cohérent dans toutes les applications pilotées par modèle, ce qui facilite l’adoption par les utilisateurs.

Le diagramme suivant illustre une architecture de base pour une application canevas ou une application pilotée par modèle, dans laquelle l’application se connecte directement aux sources de données.

Pour minimiser les connexions directes à une source de données, vous pouvez demander à l’application d’utiliser un connecteur personnalisé à l’API, qui effectue tout le travail nécessaire dans la source de données. Cette approche vous permet de contrôler quelles opérations sont exposées à des composants low-code et peut faire abstraction de la complexité de la logique sous-jacente. Le diagramme suivant illustre cette approche axée sur les API.

Power Apps peut également exécuter directement des flux de cloud Power Automate qui peuvent renvoyer des résultats à l’application ou s’exécuter de manière asynchrone.

L’utilisation de Power Apps avec vos référentiels de données ou vos API vous permet de moderniser l’expérience utilisateur tout en minimisant les interruptions d’autres parties d’une solution héritée. Cette approche peut également vous permettre de connecter plusieurs systèmes hérités dans une seule application, offrant ainsi aux utilisateurs un emplacement unique pour effectuer leur travail.

Power Pages

La source de données principale pour Power Pages est Dataverse. Lorsque vous ajoutez des pages à un site web, vous stockez les définitions de page dans Dataverse. Les pages peuvent à la fois présenter des données Dataverse et collecter des données des utilisateurs pour les stocker dans une table Dataverse.

Vous pouvez configurer des pages pour l’accès anonyme ou pour l’accès authentifié à l’aide de Microsoft Entra ID pour les utilisateurs internes ou de fournisseurs d’identité pour les utilisateurs externes. Lorsque des utilisateurs authentifiés accèdent aux données, seules les données auxquelles ils sont autorisés à accéder sont disponibles.

Une application courante d’un site Power Pages fournit aux utilisateurs externes un accès en libre-service à un processus d’entreprise organisationnel. Les utilisateurs internes peuvent utiliser une application Power Apps. Le schéma suivant illustre une telle architecture.

Gestion des données

La modernisation des applications nécessite d’évaluer les données utilisées dans la solution globale. Les applications modernisées disposent de plusieurs options pour le traitement des données. Dans de nombreux cas, plusieurs applications utilisent le même référentiel de données. Il devient difficile de migrer les données vers un nouveau référentiel dans le cadre de la modernisation d’une des applications. Un principe de base de Power Platform est que les données peuvent être utilisées là où elles se trouvent ou incorporées à la plateforme dans Dataverse ou un lac de données.

Vous disposez des options suivantes pour l’architecture de données de l’application modernisée :

• Laisser les données en place : utilisez des connecteurs ou des API avec des connecteurs personnalisés pour accéder aux données là où elles se trouvent. Lorsque les données sont locales, la passerelle de données peut faciliter la connectivité sécurisée. Utilisez des tables virtuelles pour intégrer des données externes compatibles en tant que table Dataverse.

• Migrer vers Dataverse : Dataverse est une bonne option pour les données transactionnelles et pour consolider plusieurs sources en un système unique d’enregistrement. Les données peuvent être mappées et migrées à partir de nombreuses sources à l’aide de Power Query et de flux automatisés. Dataverse prend également en charge les tables élastiques, conçues pour ingérer de gros volumes de données stockées dans des formats non structurés ou semi-structurés.

• Migrer vers le lac de données : pour les données historiques, analytiques ou de télémétrie, utilisez un lac de données. Les données du lac peuvent être utilisées pour générer des analyses Power BI ou traitées pour générer des informations basées sur l’IA.

Lorsque vous évaluez les options pour l’architecture de données d’une application modernisée, gardez à l’esprit les considérations suivantes :

• Impact sur d’autres applications : bien que la migration vers un magasin de données plus efficace puisse être idéale pour une application, l’impact initial sur les autres applications qui utilisent les données peut être trop élevé. Certaines organisations envisagent de laisser les données dans les anciens magasins de données et de créer de nouvelles données dans Dataverse, en migrant à partir de l’ancien magasin à mesure que d’autres applications sont modernisées.

• Impact sur les nouvelles applications : laisser les données dans un ancien magasin de données, bien que facile, peut avoir un impact négatif sur la facilité avec laquelle les applications modernisées peuvent les utiliser. Les magasins de données plus anciens peuvent ne pas avoir une bonne intégration avec d’autres services cloud, ce qui rend plus difficile l’intégration des données dans la nouvelle architecture globale.

• Consolidation des données : il est courant dans le cadre de la modernisation des applications d’identifier les données qui n’ont pas de propriété ou de responsabilité claire pour garantir leur bonne utilisation. En consolidant leurs données dans Dataverse, les entreprises peuvent améliorer leur gouvernance et garantir qu’elles sont utilisées correctement.

• Confidentialité et sécurité des données : vous devez évaluer la confidentialité et la sécurité en fonction de vos besoins actuels et de l’architecture de modernisation cible, et pas seulement en fonction de la façon dont l’application héritée les a gérées. Les solutions cloud offrent plus d’options pour mettre en œuvre des contrôles de confidentialité et de sécurité. Souvent, un seul magasin de données peut les simplifier. Vous devez également réfléchir à la manière de mettre en œuvre une sécurité des données unifiée dans les applications hybrides qui répartissent les données sur plusieurs référentiels.

• Problèmes d’intégration. Les magasins de données plus anciens peuvent ne pas disposer des API nécessaires pour autoriser l’accès sans migrer les données ni créer une API que les applications peuvent utiliser avec un connecteur personnalisé. La connectivité entre l’ancien magasin de données et les applications qui l’utilisent doit être évaluée pour déterminer si les performances sont acceptables.

Vous devez déterminer une architecture de données pour chaque application qui sera modernisée. Une première étape consiste à établir une vision globale de la façon dont vos architectures de données incorporent Dataverse. Si l’objectif est de maximiser la valeur du low-code, vous devez utiliser Dataverse dans la mesure du possible. Avoir une vision dès le départ peut vous aider à éviter de propager davantage de silos de données.

Données externes et Dataverse

Les applications héritées se basent souvent sur des données qui résident en dehors de l’organisation et qui existaient bien avant Dataverse. La modernisation de ces applications n’implique pas nécessairement la duplication des données dans Dataverse. À la place, vous pouvez représenter les données sous forme de tables virtuelles Dataverse. Les tables virtuelles peuvent participer à des relations avec d’autres tables virtuelles et avec des tables locales. Les applications modernisées voient un ensemble unifié de tables qui semble exister entièrement dans Dataverse.

Les tables virtuelles sont mises en œuvre à l’aide d’une architecture de fournisseur de données. Dataverse comprend un fournisseur OData qui peut être utilisé avec les services web OData V4. Un fournisseur de données de connecteur virtuel, actuellement en version préliminaire, permet d’utiliser des connecteurs Power Platform tabulaires comme tables virtuelles.

Le schéma suivant illustre l’utilisation du connecteur virtuel.

Les développeurs peuvent également créer des fournisseurs personnalisés pour d’autres sources de données externes. Cependant, ils doivent comprendre et mettre en œuvre tous les mappages Dataverse et le support opérationnel.

Les considérations suivantes peuvent vous aider à évaluer l’utilisation des tables virtuelles dans vos projets de modernisation :

• Toutes les sources de données externes doivent avoir une clé primaire et le fournisseur de données doit la présenter en tant que GUID à Dataverse. Vous pouvez prendre en charge des clés autres que GUID avec le remplissage si la valeur remplie est stable et unique.
• La sécurité des données est configurée au niveau de la table virtuelle. La sécurité au niveau des lignes et des colonnes n’est pas disponible.
• Les performances des tables virtuelles dépendent du fournisseur de données, de l’API de la source de données externe et de la connectivité à la source de données. Dans la plupart des cas, l’accès aux tables virtuelles est plus lent qu’avec les tables Dataverse locales.
• Certaines fonctionnalités Dataverse telles que la recherche, l’audit, les graphiques et tableaux de bord, ainsi que l’accès hors connexion ne sont pas disponibles pour les tables virtuelles.
• L’utilisation de tables virtuelles comme données de référence peut entraîner une réduction de la synchronisation.

Fichier et Images

Lors de la modernisation d’applications qui utilisent des fichiers et des images, il est important de tenir compte de l’emplacement de stockage de la nouvelle solution. Dataverse dispose de fonctionnalités spécialisées pour le stockage de fichiers et d’images. Les deux peuvent être ajoutés aux tables en tant que colonne et sont stockés dans le stockage blob Azure géré par Dataverse. Les applications peuvent les utiliser à l’aide du connecteur Dataverse, sans nécessiter aucune authentification distincte ou API.

L’utilisation de Dataverse pour les fichiers et les images est appropriée lorsqu’ils ont une connexion directe aux données et que plusieurs utilisateurs n’ont pas besoin de collaborer dessus ; par exemple, une photo d’un produit ou d’un emplacement ou la copie finale d’un contrat juridique. Toutefois, si plusieurs utilisateurs doivent modifier le contrat juridique simultanément, l’utilisation de SharePoint offre de meilleures fonctionnalités de collaboration. Envisagez d’utiliser directement le stockage blob Azure si la sécurité doit être gérée séparément de Dataverse ou si vous avez besoin d’utiliser certaines fonctionnalités spécifiques aux fichiers.

Intégrations

La modernisation des applications passe souvent par des intégrations avec des systèmes internes ou externes. Les intégrations peuvent être classées en trois catégories : données, applications ou processus.

• Intégration de données : combine des données de différentes sources pour fournir à l’utilisateur une vue unifiée. Il propose une approche découplée mais ne permet pas la construction de logique ou de processus en temps réel. Les performances peuvent être meilleures car toutes les données sont locales.

• Intégration d’applications : se connecte à la couche d’application et s’effectue généralement via des API ou, dans le cas des solutions low-code, via des connecteurs. L’intégration au niveau de l’application fournit une frontière définie entre deux solutions, mais crée également une dépendance en temps réel dans de nombreux cas. Ce type d’intégration crée également une frontière de sécurité, où l’accès peut être contrôlé par le système qui fournit l’API.

• Intégration de processus : connecte plusieurs systèmes disparates, chacun faisant partie d’un processus métier global. Ce type d’intégration est le plus découplé, ce qui permet aux systèmes participants de gérer chaque partie du processus d’entreprise. Dans les scénarios de modernisation, il peut être utile de partitionner une partie d’un processus de modernisation avec du low-code, intégré à d’autres parties encore gérées par un système hérité.

Lorsque vous évaluez la façon dont vous implémentez les intégrations, il est important de ne pas supposer que l’ancienne approche est la meilleure pour l’application que vous modernisez. Par exemple, si un processus est en temps réel et synchrone, demandez-vous si vous pouvez le faire de manière asynchrone. L’intégration synchrone peut être plus fragile dans une solution cloud. Par exemple, un flux Power Automate low-code avec une gestion appropriée des erreurs pourrait orchestrer l’intégration. Non seulement cette approche améliorerait la fiabilité, mais elle améliorerait également la productivité des utilisateurs, car ils n’auraient plus à attendre la fin de l’intégration.

Les considérations suivantes peuvent vous aider à évaluer comment proposer des intégrations existantes :

• L’intégration est-elle toujours nécessaire ? Il n’est pas rare de constater que plus personne n’utilise les résultats de l’intégration et qu’elle peut être retirée.

• Y a-t-il des problèmes de connectivité si l’application modernisée se trouve dans le cloud ? Les défis peuvent inclure la latence et l’accès à une API locale ou à un magasin de données. Dans certains cas, la passerelle de données locale peut faciliter l’accès au service ou aux données à partir du cloud. Lorsque l’accès aux données ou au service est trop lent, déterminez si vous pouvez rendre les données locales pour l’application modernisée ou effectuer l’intégration en arrière-plan.

L’intégration peut également aider à dimensionner correctement une application modernisée. Vous pouvez partitionner une ou plusieurs parties de l’application héritée pour les laisser derrière vous ou les implémenter dans une application distincte. Cette approche fonctionne bien lorsque des utilisateurs de rôles différents utilisent différentes parties de l’application héritée. Vous pouvez implémenter un ou plusieurs des rôles en utilisant le low-code et utiliser l’intégration de processus pour laisser l’application existante gérer les parties restantes du processus. En utilisant cette approche, vous pouvez moderniser progressivement les pièces restantes au fil du temps. Le fait d’avoir des parties indépendantes du processus implémentées séparément peut également faciliter une manière plus agile de déployer des améliorations indépendamment des autres parties du processus.

Avant d’effectuer des intégrations personnalisées, vous devez évaluer les capacités d’intégration intégrées dans Power Apps.

• Microsoft Teams : les applications canevas Power Apps et les agents Copilot Studio peuvent être intégrés dans les canaux Teams. À l’aide du connecteur Teams, les applications et les flux peuvent facilement publier et utiliser des messages Teams. Les cartes Power Apps peuvent être utilisées comme des micro-applications pour partager des informations exploitables dans un canal Teams.

• SharePoint : les applications pilotées par modèle Power Apps peuvent être configurées pour se connecter aux documents stockés dans une bibliothèque SharePoint afin de les rendre disponibles dans une ligne Dataverse. Avec les listes Microsoft ou une liste SharePoint, les utilisateurs peuvent exécuter des flux Power Automate dans le contexte d’un élément de liste.

• Power BI : les informations Power BI peuvent être affichées dans le contexte d’une application canevas Power Apps. Vous pouvez intégrer un application pilotée par modèle dans un rapport Power BI pour permettre aux utilisateurs d’agir sur les informations sans quitter Power BI.

L’utilisation de Dataverse en tant que référentiel de données principal pour l’application modernisée fournit quelques fonctionnalités intégrées qui peuvent être utiles pour l’intégration.

• Les API personnalisées Dataverse peuvent être utilisées pour l’intégration entrante au niveau de l’application. Les API personnalisées fournissent une opération unique associée à une petite quantité de logique de code personnalisée. Par exemple, un système d’envoi pourrait utiliser l’API personnalisée RequestNewProject et la logique associée saurait comment placer les données reçues dans les tables Dataverse appropriées. Le système d’envoi serait extrait de la structure de table Dataverse.

• L’intégration sortante peut être effectuée à l’aide des fonctionnalités de publication d’événements de Dataverse. Dataverse peut être configuré pour publier sur Azure Service Bus, Azure Event Hubs ou n’importe quel récepteur Webhook. Par exemple, lorsqu’une ligne de table de projet Dataverse est créée, elle peut être publiée dans une file d’attente Azure Service Bus. Vous pouvez également publier des événements plus conceptuels qui correspondent à un événement de processus d’entreprise. Par exemple, vous pouvez définir et publier des événements lorsqu’un projet est terminé.

Le diagramme suivant illustre un exemple d’événements entrants et sortants dans un environnement Dataverse.

Les organisations doivent également envisager des options d’intégration prédéfinies disponibles auprès de tiers sur Microsoft AppSource. Par exemple, Microsoft dispose d’une solution prédéfinie pour les organisations qui doivent intégrer SAP à Power Platform. Cette solution prédéfinie incorpore des applications, des flux et ajoute de nouvelles fonctionnalités qui facilitent la communication entre le système SAP de votre organisation et Power Platform.

Par exemple, Ernst et Young a utilisé l’intégration SAP prédéfinie pour développer rapidement une solution permettant d’optimiser un processus financier mondial à haute fréquence. Le diagramme suivant de la solution PowerPost de l’entreprise montre comment les utilisateurs financiers valident des documents dans son système SAP ERP de comptabilité générale à l’aide de Power Platform.

Options de connectivité d’intégration

Au fur et à mesure que les solutions migrent vers le cloud, la connectivité aux ressources locales peut s’avérer essentielle pour garantir que les intégrations fonctionnent toujours avec l’application modernisée. Ces applications doivent également être en mesure de s’intégrer à d’autres ressources cloud traditionnelles qui peuvent résider dans différents environnements réseau. Power Platform prend en charge les quatre principales options pour une connectivité sécurisée : les passerelles de données, les passerelles de données de réseau virtuel, les liens privés et ExpressRoute.

• Les Passerelles de données permettent aux composants low-code de Power Apps, Power Automate et Power BI d’accéder aux ressources locales pour prendre en charge les scénarios d’intégration hybride. Les passerelles offrent un moyen rapide aux applications low-code modernisées d’accéder à des sources de données qui sont encore locales. Avec une passerelle, vous pouvez vous connecter à des données locales à partir de sources telles qu’un système de fichiers local, DB2, Oracle, SAP ERP, SQL Server et SharePoint. Une passerelle peut prendre en charge plusieurs utilisateurs et l'accès à plusieurs sources. Vous pouvez également configurer des passerelles de données en tant que clusters pour assurer une haute disponibilité.

  La prise en charge de la passerelle est intégrée dans le processus de connexion pour les connecteurs, ce qui permet d’indiquer quand une passerelle est requise et de sélectionner la passerelle configurée. Une fois la connexion configurée, les applications et les flux peuvent utiliser le connecteur comme s’ils n’avaient pas de passerelle.

  

• Les Passerelles de données de réseau virtuel permettent aux flux de données Power BI et Power Platform de se connecter aux services de données dans un réseau virtuel Azure sans nécessiter une passerelle de données locale sur une machine virtuelle à l’intérieur du réseau virtuel.

• Les points de terminaison privés Azure Private Link et Azure Networking permettent aux applications et aux flux d’accéder à Power BI en toute sécurité. Les points de terminaison privés sont utilisés pour envoyer du trafic de données en privé en utilisant l’infrastructure réseau de base de Microsoft au lieu de passer par Internet. Les points de terminaison privés garantissent que le trafic à destination des ressources Power BI de votre organisation, comme les rapports ou les espaces de travail, suit toujours le chemin du réseau de lien privé configuré par votre organisation.

• Azure ExpressRoute fournit un moyen avancé de connecter votre réseau local aux services de cloud Microsoft en utilisant une connectivité privée. Une seule connexion ExpressRoute peut accéder à plusieurs services en ligne tels que Power Platform, Dynamics 365, Microsoft 365 et les services cloud Azure sans passer par l’Internet public. ExpressRoute nécessite une planification et une configuration importantes et implique des coûts plus élevés pour le service ExpressRoute et le fournisseur de connectivité.

Quelles que soient les approches que vous utilisez pour la connectivité d’intégration, vous devez évaluer votre connectivité pour vous assurer qu’elle a une latence suffisamment faible et une bande passante suffisante pour prendre en charge à la fois vos intégrations et l’application modernisée.

Logique métier

Lors de la création d’applications modernes, vous pouvez choisir avec quoi implémenter la logique métier et où l’implémenter dans votre architecture d’application. Sans conseils, la plupart des organisations se retrouveraient dans un chaos de logique métier. Disposer d’une logique réutilisable qui garantit la cohérence de la mise en œuvre peut aider à accélérer les efforts de modernisation.

Dans le cas présent, nous définissons la logique métier comme étant différente de la logique de l’expérience utilisateur. Par exemple, la logique qui consiste à naviguer d’un écran à l’autre en fonction des valeurs des données d’inspection est la logique de l’expérience utilisateur. La logique que vous mettez en œuvre pour déterminer si une inspection est terminée peut inclure plusieurs évaluations de condition et est considérée comme une logique métier.

Lors de la conception d’une solution qui inclut du low-code, les considérations suivantes peuvent vous aider à décider où placer la logique métier.

• Dans l’application Power Apps : placer une logique métier dans l’application low-code est l’approche la plus simple, mais elle offre des options limitées pour la réutilisation ou pour appliquer la cohérence entre les applications et les automatisations. En règle générale, vous devez limiter cette approche à une logique simple et non critique que d’autres applications ou automatisations n’ont pas besoin d’utiliser. Les outils low-code ne fournissent pas une expérience de débogage ligne par ligne. Si la logique s’étend sur plusieurs écrans ou est difficile à lire, vous devriez envisager d’autres approches qui seraient plus faciles à maintenir. Il n’est pas rare qu’une certaine logique métier soit dupliquée localement dans l’application et dans le cloud. Par exemple, si un utilisateur saisit une réservation d’hôtel, la règle métier est que la date de départ ne peut pas être antérieure à la date d’arrivée. Si l’application ne validait pas cela, l’utilisateur allait jusqu’à la fin et soumettait la réservation pour constater que le connecteur personnalisé l’avait rejetée. La gestion de la validation localement dans l’application et dans le cloud offre une bien meilleure expérience utilisateur.

• Dans un flux de cloud Power Automate : vous pouvez exprimer une logique métier dans les actions d’un flux, et le flux peut se déclencher en réponse à un événement ou à une demande d’exécution à la demande d’autres applications et flux. Le flux peut fournir une approche low-code de la logique de centralisation. Les étapes du flux sont indépendantes et ne font pas partie d’une transaction. Toutefois, les flux peuvent implémenter une compensation pour gérer la restauration si des erreurs se produisent. Les flux peuvent exécuter des étapes à l’aide de connexions disposant d’autorisations allant au-delà de ce que l’utilisateur de l’application peut faire, ce qui permet d’élever les autorisations. Cette approche permet également de réduire les autorisations dont l’utilisateur de l’application peut avoir besoin.

• Dans un plug-in Dataverse : les plug-ins s’exécutent en réponse à un événement de ligne de données, par exemple la création, la mise à jour ou la suppression. Cette logique s’exécute chaque fois que l’événement se produit, quelle que soit l’application ou le flux qui a effectué l’action ou si elle a été effectuée directement à partir de l’API Dataverse. L’avantage de ce comportement est qu’il garantit la cohérence entre toutes les utilisations. De plus, toutes les modifications de données Dataverse à partir de la logique de plug-in sont transactionnelles et sont toutes terminées ou toutes restaurées. La logique de plug-in doit être courte et efficace et ne pas essayer d’implémenter un travail de longue haleine. Parfois, les plug-ins sur les événements ne sont pas la meilleure approche si vous devez écouter des événements sur plusieurs tables pour terminer un seul événement professionnel comme Close Inspection. Par exemple, vous pouvez envisager une API personnalisée Dataverse au lieu d’avoir des plug-ins sur plusieurs tables. Les plug-ins peuvent exécuter une logique avec des autorisations élevées que l’utilisateur n’aurait peut-être pas normalement. Cette approche permet également de réduire les autorisations dont l’utilisateur de l’application peut avoir besoin. Les plug-ins peuvent être déployés dans une solution Dataverse avec des applications et des flux.

• Dans les API personnalisées Dataverse : les API personnalisées Dataverse vous permettent d’implémenter votre propre message d’API personnalisé qui peut exécuter la logique. Par exemple, vous pouvez créer une API personnalisée Fermer l’inspection qui est appelée pour faire tout le travail de vérification et de fermeture d’une inspection. Il ne serait pas piloté par les événements, mais utilisé à la demande par les applications et les flux qui en ont besoin. Comme les plug-ins pilotés par les événements, les modifications de données effectuées dans le plug-in d’API personnalisé sont transactionnelles. Une API personnalisée convient mieux lorsque le seul service qu’elle utilise est l’API Dataverse pour d’autres tâches de données. Les plug-ins pour les API personnalisées peuvent être déployés dans une solution Dataverse avec des applications et des flux.

Implémenter une API de code

Vous pouvez implémenter des API dans votre runtime d’hébergement d’API préféré, tel que Azure Functions, Azure Container Apps ou tout autre service capable d’héberger une API REST. Ces API personnalisées peuvent implémenter n’importe quelle logique, et les applications low-code et les applications à code traditionnel peuvent les utiliser. Les API personnalisées ne fournissent pas de support de transaction autre que ce qui pourrait être fourni par une API qu’elles utilisent. Par exemple, une API personnalisée pourrait utiliser les constructions de transaction SQL Server si elle utilisait SQL Server. Le déploiement d’une API de code serait indépendant des ressources low-code qui pourraient l’utiliser. Vous pouvez utiliser la gestion des API Azure pour régir l’utilisation de ces API et les rendre plus détectables.

Sécurité

La sécurité, y compris l’authentification et l’autorisation, est un élément essentiel de l’architecture d’une application modernisée. Les applications modernes sont souvent plus difficiles à sécuriser que les applications héritées. Elles incluent plusieurs services de cloud, et les utilisateurs travaillent avec eux à partir d’emplacements plus divers. Conceptuellement, la sécurité dans la plateforme garantit que les utilisateurs peuvent effectuer le travail qu’ils doivent faire avec le moins de friction possible, tout en protégeant les données et les services.

Power Platform adopte une approche multicouche de la sécurité que vous pouvez utiliser pour créer votre architecture de sécurité. L’un des principes fondamentaux de ces fonctionnalités est que les solutions low-code doivent s’intégrer à votre appareil de sécurité existant afin de minimiser l’impact de leur introduction.

Examinons en détail les multiples couches de sécurité qui composent le modèle de sécurité de Power Platform.

• Les utilisateurs sont authentifiés par Microsoft Entra ID et l’utilisation peut être limitée à l’aide de stratégies d’accès conditionnel.
• La gestion des licences est le premier contrôle à permettre l’accès aux composants Power Platform.
• La capacité de créer des applications et des flux de travail est contrôlée par des rôles de sécurité dans le contexte des environnements.
• La capacité d’un utilisateur à voir et à utiliser les ressources Power Platform est contrôlée par le partage de l’application avec lui. Les ressources sont partagées directement avec l’utilisateur ou le groupe Entra ID.
• Les environnements agissent comme des limites de sécurité qui permettent de mettre en œuvre différents besoins de sécurité dans chacun.
• Les flux et les applications canevas Power Automate utilisent des connecteurs. Les identifiants de connexion spécifiques et les droits de service associés déterminent les autorisations lorsque les applications utilisent les connecteurs.
• Les environnements avec une instance Dataverse prennent en charge des modèles de sécurité plus avancés spécifiques au contrôle de l’accès aux données et aux services dans cette instance Dataverse.
• L’utilisation de connecteurs peut être encore plus limitée avec les règles de protection contre la perte de données (DLP). Des restrictions entrantes et sortantes entre clients peuvent être également appliquées aux connecteurs.

Il est important de noter que lors de l’accès aux sources de données à l’aide de connecteurs, toute la sécurité sous-jacente offerte par la source de données s’ajoute aux couches de sécurité décrites. Power Apps et Power Automate ne fournissent pas par défaut aux utilisateurs un accès à la source de données du connecteur dont ils ne disposent pas déjà. Les utilisateurs doivent uniquement avoir accès aux données auxquelles ils ont réellement besoin d’accéder.

Lorsque vous utilisez Dataverse dans le cadre d’une solution, il inclut un modèle de sécurité basé sur les rôles qui peut être adapté à de nombreux scénarios métier. Les données peuvent être sécurisées jusqu’à une colonne individuelle sur une ligne de données. Les utilisateurs se voient attribuer un ou plusieurs rôles de sécurité qui, ensemble, déterminent leurs privilèges globaux. Dataverse fournit des composants de modélisation de la sécurité, comme les divisions et les équipes. Par exemple, les divisions peuvent être utilisées pour définir des limites de sécurité afin d’isoler les données entre deux groupes différents d’utilisateurs de l’organisation. Vous pouvez utiliser des équipes pour regrouper les utilisateurs qui ont besoin d’un accès similaire aux données. Vous pouvez même attribuer à un groupe la propriété des lignes de données. Le diagramme suivant illustre l’utilisation de divisions pour isoler des données pour les divisions d’une organisation.

Concevoir votre modèle de sécurité

Adaptez le modèle de sécurité de l’application modernisée à l’architecture globale de l’application. Les applications qui utilisent un référentiel de données unique et sans connecteurs nécessitent un travail de conception de sécurité minimal. À mesure que les applications utilisent davantage de connecteurs et de référentiels de données, votre modélisation de la sécurité doit inclure d’autres considérations.

• Identité de l’utilisateur : comment les utilisateurs s’authentifient-ils et le mappage a-t-il déjà été effectué dans Microsoft Entra ID dans les scénarios provenant de l’environnement local ? Cela inclut le mappage des groupes nécessaires pour prendre en charge l’affectation de groupes d’applications ou d’équipes dans les magasins de données de cloud comme Dataverse.

• Identité de connexion du connecteur : lorsque les applications utilisent un ou plusieurs connecteurs, quel type d’authentification est effectué pour la connexion et fournit-il le niveau de contrôle nécessaire pour mettre en œuvre les contrôles de sécurité requis ? Par exemple, les applications qui utilisent un principal de service pour se connecter n’ont pas besoin que l’utilisateur de l’application dispose d’un accès direct au connecteur, ce qui peut être avantageux dans certains scénarios. Les connexions utilisateur individuelles peuvent convenir aux applications qui ont besoin de savoir quel utilisateur a effectué une opération ou d’étendre les réponses à des utilisateurs spécifiques.

• Portabilité de la construction de sécurité : à mesure que vos applications utilisent davantage de connecteurs et de référentiels de données, il est important de rappeler que toutes les constructions de sécurité de l’une ne sont pas directement mappées à une autre. Par exemple, dans Dataverse, il existe plusieurs façons pour un utilisateur d’accéder à une ligne de données, notamment en partageant la ligne avec l’utilisateur. Si une application associe une bibliothèque de documents SharePoint à la ligne, la sécurité qui donne accès à la bibliothèque de documents est distincte de la sécurité qui contrôle l’accès à Dataverse. Ils ne sont pas mappés directement. Les applications modernisées doivent s’adapter à ces types d’incompatibilités entre les connecteurs et les référentiels de données qu’elles utilisent.

Intelligence artificielle

Au cours des dernières années, l’IA a trouvé sa place dans les efforts de modernisation des applications. Lors de la modernisation des applications, les organisations doivent envisager d’utiliser l’intelligence artificielle pour rendre les utilisateurs plus productifs et mieux à même de prendre des décisions éclairées. Les résultats de l’intégration de l’IA peuvent également se traduire par de meilleures expériences client qui ont un impact positif sur les résultats commerciaux.

L’inclusion de l’IA impliquait auparavant un travail lourd dans l’intégration de la logique d’application et la création de modèles formés personnalisés. Grâce à la disponibilité et à la puissance de grands modèles de langage, les applications peuvent désormais introduire de nouvelles façons d’utiliser l’IA pour aider les utilisateurs à obtenir des réponses et à effectuer des tâches. Les utilisateurs peuvent utiliser des invites en langage naturel pour interagir avec les fonctionnalités de l’IA dans un large éventail de scénarios d’entreprise d’assistance.

Microsoft a introduit des copilotes dans ses principaux produits et services pour faciliter l’accès aux technologies d’IA avancées. Un Copilot utilise des techniques d’IA modernes et de grands modèles de langage et les utilisateurs peuvent interagir avec lui dans les applications qu’ils utilisent tous les jours, comme Microsoft 365, Windows, Dynamics 365 et Power Platform.

Étendre avec les plug-ins

Les utilisateurs d’applications alimentées par Copilot peuvent demander au Copilot de l’aide pour les tâches courantes dans l’application. Vous pouvez étendre les copilotes pour inclure des données et des tâches qu’il ne connaît pas encore et qui dépassent le cadre de l’application avec laquelle l’utilisateur travaille. Microsoft 365 Copilot peut incorporer des données Power Platform stockées dans Dataverse afin que les utilisateurs n’aient pas à passer d’une application à l’autre. Par exemple, à partir d’Outlook, un utilisateur peut demander à Copilot de générer une mise à jour de statut pour toutes les inspections ayant échoué effectuées aujourd’hui. Microsoft 365 Copilot hérite automatiquement de l’infrastructure de sécurité et de gouvernance native et Dataverse applique la sécurité et les autorisations de l’utilisateur au moment de l’exécution.

Connecteurs sous forme de plug-ins

Les connecteurs Power Platform sont également importants pour l’expérience Copilot. Les connecteurs peuvent se connecter sous forme de plug-ins pour étendre les capacités de Copilot. Par exemple, Microsoft 365 Copilot avec le connecteur Power Platform pour Jira Software peut permettre à un chef de projet de demander le statut d’un ticket de support Jira et d’agir en fonction de la réponse, par exemple en l’acheminant pour une approbation supplémentaire ou en démarrant un bon de commande pour un nouveau matériel. À l’aide de plug-ins, vous pouvez intégrer vos processus métier et vos données avec Copilot pour permettre aux utilisateurs d’interagir à partir des applications qu’ils utilisent.

Créer votre propre copilote

Au fur et à mesure que les utilisateurs s’habituent à avoir l’assistance de l’IA du copilote dans leurs applications, ils l’attendent dans toutes les applications. Vous pouvez rendre vos applications modernes plus attrayantes en incluant des copilotes que vous créez avec la pile Copilot, un cadre de développement de l’IA.

Vous pouvez utiliser le contrôle Copilot prédéfini dans Power Apps pour ajouter des copilotes à vos applications canevas et vos applications pilotées par modèle. En configurant une vue d’une source de données et quelques informations d’invite de base, vous pouvez rapidement fournir votre propre expérience copilote dans l’application.

Gestion du cycle de vie des applications

Une partie importante de tout effort de modernisation consiste à établir un processus approprié de gestion du cycle de vie des applications. Les organisations souhaitent souvent que leurs efforts low-code correspondent à la façon dont elles travaillent avec l’ALM du code traditionnel. Power Platform fournit des outils ALM afin que vous puissiez inclure des artefacts low-code dans ou avec les processus que vous utilisez habituellement.

ALM dans Power Platform commence par la façon dont vous créez vos ressources low-code. Les ressources que vous générez sont dans le contexte d’un environnement Power Platform. Un environnement peut avoir un magasin de données Dataverse. Vous pouvez utiliser plusieurs environnements, généralement de développement, de test et de production, pour implémenter des zones d’atterrissage dans un processus ALM qui inclut le low-code. Le nombre et l’objectif des environnements sont flexibles, et les organisations peuvent les ajuster pour répondre aux besoins de chaque projet. Une solution Dataverse est un conteneur pour les ressources low-code associées, ce qui facilite le contrôle de version et le transport d’un environnement à un autre.

Les pipelines Power Platform offrent une approche low-code pour automatiser les déploiements et mettre en œuvre l’intégration continue et la livraison continue (CI/CD). Power Platform gère le processus lorsque les pipelines sont configurés. Les administrateurs peuvent gérer et gouverner les pipelines de manière centralisée.

Les organisations peuvent également utiliser les outils CI/CD de leur choix. Power Platform CLI est un outil de ligne de commande que vous pouvez utiliser avec la plupart des outils d’automatisation CI/CD. Power Platform Build Tools fournit des actions pour GitHub et des tâches pour Azure DevOps qui fournissent toutes les actions courantes requises pour créer des automatisations CI/CD incluant des artefacts low-code.

Le diagramme suivant illustre un exemple d’une équipe créant une application Inspection. Dans leur boucle interne, ils travaillent dans un environnement de développement et stockent leur travail dans un référentiel Git. La boucle externe se compose d’un environnement de test et d’un environnement de production. Un pipeline de build prend la solution contrôlée par version, effectue les vérifications nécessaires et produit un artefact de solution d’inspection. Un pipeline de mise en production déploie ensuite la solution pour la tester, où les testeurs peuvent vérifier qu’elle est prête pour la production. Une fois approuvée, le pipeline de mise en production déploie la solution en production.

Lorsque vous exportez une solution à partir de Dataverse, celle-ci est exportée sous la forme d’un fichier compressé unique. Pour stocker les ressources low-code dans le contrôle de version, vous pouvez utiliser les outils de génération pour décompresser le fichier de solution en fichiers de composants individuels. Pendant l’automatisation de la build, les outils de build combinent des fichiers individuels du contrôle de version en un seul fichier compressé.

Le déploiement d’une solution dans un environnement contenant une version précédente de la solution utilise un processus de mise à niveau intelligent qui applique uniquement les modifications. Ce processus de mise à niveau évite d’avoir recours à des scripts de différenciation ou à d’autres moyens de déterminer ce qui doit être déployé.

Lorsque votre application modernisée inclut des ressources low-code et de code traditionnel, vous pouvez les combiner dans un seul processus CI/CD ou les gérer indépendamment. Grâce à une gestion indépendante, les ressources peuvent être déployées individuellement et les équipes de projet peuvent gagner en agilité. Par exemple, l’API utilisée par une application low-code peut se déployer indépendamment si l’équipe n’introduit pas de modifications avec rupture.

Surveillance et informations

Les applications modernisées doivent s’intégrer dans des environnements opérationnels qui permettent de diagnostiquer les problèmes dans différents environnements, du développement à la production. Application Insights, une extension Azure Monitor, collecte la télémétrie à partir de Power Apps et Dataverse. Ces informations aident non seulement à identifier et à résoudre les problèmes, mais fournissent également des informations sur ce que les utilisateurs font dans une application. Vous pouvez utiliser ces informations pour améliorer les applications et les processus de votre application modernisée.

Lorsqu’une application Power Apps est en cours de développement, les développeurs peuvent inclure une logique pour consigner les événements personnalisés. Une fois que vous avez connecté l’application déployée dans Application Insights, l’extension collecte automatiquement la télémétrie de base, y compris plus de contexte des événements consignés, à mesure que les utilisateurs interagissent avec l’application.

Les administrateurs peuvent également configurer des environnements Dataverse pour exporter la télémétrie dans Application Insights. Les données consignées peuvent inclure des appels d’API Dataverse, l’exécution de plug-ins, les opérations SDK et les exceptions. Les développeurs qui créent une logique de plug-in personnalisée peuvent consigner des données de télémétrie plus personnalisées directement dans Application Insights.

L’utilisation Application Insights dans vos applications peut faciliter la corrélation des problèmes avec plusieurs ressources. Le personnel des opérations peut créer des alertes dans Azure Monitor qui se déclenchent lorsqu’un grand nombre d’exceptions sont détectées. Une analyse régulière de vos applications modernisées permet d’identifier les tendances qui nécessitent une enquête plus approfondie.

Conclusion

Dans ce livre blanc, nous avons exploré les avantages, les stratégies et les meilleures pratiques de modernisation de vos applications héritées avec Microsoft Power Platform. Vous avez obtenu des informations et des conseils sur l’utilisation des fonctionnalités low-code de Power Platform pour garantir le succès de vos efforts de modernisation dans le cadre de la transformation numérique de votre organisation.

Les applications héritées présentent de nombreux défis pour les organisations. Pour les surmonter, les organisations doivent se lancer dans des initiatives de modernisation des applications afin de revitaliser leur infrastructure et de tirer parti des technologies modernes. Dans ce livre blanc, vous avez vu comment adopter une approche low-code pour vos efforts de modernisation, en particulier comment les fonctionnalités de développement low-code de Microsoft Power Platform vous permettent de créer et de déployer rapidement des applications modernes.

Le low-code ouvre la porte à un plus grand nombre de personnes que les codeurs traditionnels. Un facteur clé pour les organisations qui réussissent avec une approche low-code est de s’assurer que les personnes impliquées dans la modernisation des applications ont une formation au développement low-code, qu’il s’agisse de développeurs professionnels ou d’utilisateurs métier. Les utilisateurs métier sont plus proches du problème métier à résoudre et peuvent apporter une expertise qui leur fait gagner du temps. Les développeurs de code traditionnels peuvent appliquer les techniques et les compétences dont ils disposent déjà pour créer des extensions afin de combler les lacunes du low-code. Les organisations peuvent être plus efficaces en combinant des ressources commerciales et techniques au sein de ce que nous aimons appeler des « équipes de fusion ».

Ce livre blanc pose les bases pour vous. Les prochaines étapes vous appartiennent. Voici quelques suggestions :

• Prenez quelques minutes pour découvrir ce que votre organisation fait déjà avec le low-code. Cela pourrait vous surprendre !
• Évaluez les opportunités de modernisation de vos applications.
• Identifiez et priorisez un bon premier candidat.
• Dotez en personnel une équipe qui modernise l’application. Pour de meilleurs résultats, assurez-vous qu’il s’agit d’une équipe de fusion.
• Assurez-vous que l’équipe dispose de la formation nécessaire pour réussir.
• Permettez à l’équipe de moderniser l’application.
• Réfléchissez à l’effort de modernisation. Affinez-le et adaptez-le à d’autres applications héritées.

Le parcours de chaque organisation vers la modernisation des applications est unique. Votre équipe de compte Microsoft ou votre partenaire Power Platform peut vous aider à planifier votre parcours et à vous maintenir sur le bon chemin tout au long du parcours.

Resources

• Impact économique total™ des fonctionnalités de Microsoft Power Platform Premium
• L’application ConnectMe d’American Airlines offre une expérience de voyage plus fluide pour les clients et de meilleurs outils technologiques pour les membres de l’équipe
• Référentiel open-source Power Fx sur GitHub
• Kit de démarrage CoE
• Évaluation de l’adoption de Power Platform
• Une compagnie d’assurance numérique automatise un processus d’achat complexe à l’aide de Power Platform
• Galerie PCF
• EY facilite l’entrée à la source pour un processus financier global avec Power Platform, réduisant les délais de 95 %
• Azure Private Link
• Microsoft Azure ExpressRoute
• Planificateur de versions Power Platform
• Guide des licences Microsoft Power Platform
• Microsoft décrit le cadre pour créer des applications d’IA et des copilotes ; développe l’écosystème de plug-ins d’IA