Architecturer Power Platform pour des solutions d'entreprise complexes avec Ian Tweedie [MVP]

Microsoft Power Platform est souvent décrit comme une plateforme low-code. Mais que se passe-t-il lorsque les applications que vous créez deviennent critiques pour l'activité, fortement intégrées et trop complexes pour une approche simplement orientée « maker » ?Dans cet épisode de M365 FM, Mirko Peters s'entretient avec Ian Tweedie, architecte de solutions Power Platform, sur ce qui se passe lorsque Power Platform dépasse les simples applications low-code et devient une partie d'une architecture d'entreprise sérieuse.

LOW-CODE NE SIGNIFIE PAS ARCHITECTURE LÉGÈRE
Power Platform peut apporter rapidement une grande part de la valeur métier, mais les solutions d'entreprise contiennent presque toujours des exigences qui dépassent les capacités low-code standard.Ian explique pourquoi le low-code ne doit jamais être confondu avec le no-code, et pourquoi les principes traditionnels de l'architecture logicielle restent pertinents lorsqu'on construit avec Power Apps, Power Automate, Dataverse, les connecteurs personnalisés, les API et les services Azure.

QUAND POWER PLATFORM DEVIENT UN LOGICIEL D'ENTREPRISE
Il n'existe pas forcément de frontière nette entre « low-code » et « entreprise ».La complexité augmente dès que les applications impliquent plusieurs parcours utilisateurs, plusieurs équipes de développement, des intégrations, des exigences de sécurité, des processus critiques pour l'activité et des services interconnectés.À ce stade, l'architecture devient indispensable.Ian explique pourquoi les solutions doivent être découpées en fonctionnalités et modules clairement définis, dotés d'interfaces propres, plutôt que de devenir une grande application interconnectée.

SORTIR DU PROBLÈME DU « WHACK-A-MOLE » EN DÉVELOPPEMENT
On corrige un bug et un autre apparaît ailleurs.Ce problème de développement familier est souvent le symptôme d'une architecture fortement couplée.Ian examine comment une conception modulaire peut isoler les fonctionnalités et réduire les dépendances non intentionnelles. En prenant l'exemple de l'envoi d'e-mails, il montre comment séparer les processus métier des mécanismes de livraison peut faciliter les tests, la maintenance, le remplacement et la montée en charge des applications.

LOW-CODE + PRO-CODE = ARCHITECTURE HYBRIDE
Power Platform n'a pas besoin de rivaliser avec le développement logiciel traditionnel.Un frontend Power Apps peut ne représenter qu'une petite partie d'une application bien plus vaste utilisant Azure, AWS, GCP, des API ou des services personnalisés.La question architecturale importante n'est pas de savoir si quelque chose est « low-code » ou « pro-code ».Il s'agit de déterminer quelle technologie convient le mieux à chaque fonctionnalité.

CITIZEN DEVELOPERS, MAKERS ET ARCHITECTURE
Les citizen developers apportent quelque chose d'extrêmement précieux : une connaissance approfondie des processus métier qu'ils utilisent chaque jour.Mais l'expertise métier ne se traduit pas automatiquement en une bonne architecture applicative.Ian discute de l'équilibre entre donner du pouvoir aux makers et introduire suffisamment d'architecture, de gouvernance, de normalisation et de revue technique pour éviter que les solutions ne deviennent difficiles à maintenir.

LA GOUVERNANCE SANS TUER L'INNOVATION
Une gouvernance insuffisante crée le chaos.Une gouvernance excessive crée des frictions, et pousse les employés vers des contournements non supportés : tableurs, VBA et shadow IT.Le défi consiste à trouver le juste niveau de gouvernance en fonction du risque pour l'organisation, de la criticité de l'application, des utilisateurs et de l'impact métier.

POWER PLATFORM, API ET AZURE
Où la logique métier doit-elle résider ?Les secrets doivent-ils être stockés dans Power Platform ? Quand Azure Key Vault, Azure Functions ou API Management doivent-ils faire partie de l'architecture ?Ian explique pourquoi l'architecture doit toujours partir du problème à résoudre plutôt que d'ajouter des services Azure simplement parce qu'ils sont disponibles.

GIT, CONTRÔLE DE CODE SOURCE ET CI/CD
À mesure que le développement Power Platform devient plus collaboratif, les pratiques de développement traditionnelles gagnent en pertinence.La discussion aborde Git, les dépôts, les environnements de développement, les pipelines, le contrôle de version, l'isolation des fonctionnalités, les dépendances croisées et le CI/CD.Il n'existe pas toujours d'approche parfaite du contrôle de version dans Power Platform : parfois, l'objectif est de choisir l'option « la moins mauvaise » pour le projet.

LE GUIDE D'ARCHITECTURE POWER PLATFORM D'IAN

Le principe central d'Ian est simple :Découper les solutions en fonctionnalités et modules.Chaque fonctionnalité doit avoir une raison d'exister claire et, idéalement, assurer une responsabilité unique et précise.Ensuite, déterminez comment ces fonctionnalités communiquent, où la logique doit s'exécuter, comment elles doivent être testées et quelle technologie est la mieux adaptée pour les implémenter.

LE TOUR DE QUESTIONS EXPRESS
Mirko soumet Ian à une série de questions rapides :Chaque application d'entreprise doit-elle utiliser Dataverse ?Power Platform peut-il créer des applications critiques ?Power Automate peut-il remplacer Logic Apps ?Le low-code réduit-il automatiquement la dette technique ?Power Platform peut-il remplacer le développement d'applications traditionnel ?Et peut-être la plus importante : que faut-il commander lorsqu'on visite Newcastle ?

L'ESSENTIEL
Low-code ne signifie pas architecture légère.À mesure que les solutions Power Platform deviennent plus grandes, plus connectées et plus importantes pour l'activité, les fondamentaux de l'ingénierie logicielle restent pertinents.L'architecture compte.La modélisation des données compte.La gouvernance compte.La sécurité compte.La conception des API compte.Le DevOps compte.Et un développement Power Platform d'entreprise réussi repose de plus en plus sur la compréhension de la manière dont le low-code, le pro-code, Azure, les API, l'automatisation et les pratiques traditionnelles de l'ingénierie logicielle fonctionnent ensemble.

Devenez un soutien de ce podcast : https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.