Power Platform ou un p’tit dev ?

Posted by
English version available here

Depuis plusieurs années maintenant, Microsoft a mis en avant les outils satellites tels que Flow, Power BI et Power Apps pour concevoir des solutions métiers autour de l’ERP sans développement, les fameux outils « lowcode ».

En 2019, ces 3 outils se sont regroupés autour d’une plateforme intégrée appelée Power Plaform. C’est dans cette logique que Flow a été renommé en Power Automate. On y retrouve également Power Virtual Agents qui est utilisé pour créer des chatbox.

Développer des solutions d’entreprise, de A à Z, sans avoir à écrire la moindre ligne de code : c’est vraiment cet enjeu qui est à challenger avec la Power Platform.

Alors Madame Michu peut-elle se débrouiller toute seule ? Ces outils sont-ils vraiment autosuffisants ? Plus besoin de développement dans l’ERP ?

La situation actuelle

Dynamics 365 se repose désormais sur la Power Platform : c’est un fait, Microsoft investit un paquet sur ces outils, bien plus que sur les outils de développement classiques de l’ERP.

Depuis quelques temps déjà, il n’est plus possible de surcharger le code de l’éditeur, mais il faut venir travailler par extension. Comprendre par là que le noyau exécute le code standard, puis on vient greffer sa modification en bout de chaîne. C’est sans doute contraignant pour les développeurs, qui doivent adapter leur travail à ces nouvelles règles, mais plus facile pour passer les mises à jour qui sont fréquentes (10 par an), et qui impactent le standard.

La philosophie de l’éditeur pour répondre à 100% des besoins client, au sein de l’ERP est la suivante : le standard couvre 80% de vos besoins, les ISV de nos partenaires 15% et les 5% seront couverts par des apps ou des flux avancés via la Power Platform.

Peut-on penser que dans un futur proche, Microsoft interdira complètement les développements hors ISV car contraire à l’approche Power Platfom ? On peut l’imaginer (et encore…), mais qu’en est-il côté terrain ?

Quelques exemples modélisables par la Power Platform

Voici un besoin classique : J’ai besoin de notifier par mail automatiquement tous les soirs une assistante en interne pour tous les clients qui ont des impayés, qu’elle fasse une proposition d’action puis en fonction du niveau d’impayé notifier tel ou tel manager pour approbation de l’action à mener.  Cela a du sens de concevoir ces flux avec la Power Platform, dont 100% des actions sont hors ERP ou manuelles dans l’ERP et dont le déclencheur est un point de l’ERP.

Typiquement ici, on peut imaginer créer un business event sur les alertes et paramétrer un flow sur Power Automate, ou bien passer par un report électronique qui se déclenche une fois par jour….

Autre exemple. Il n’existe pas à ce jour de workflow de création des produits. On peut alors imaginer une Power Apps qui viendrait initier une fiche article au sein du CDS, puis un flow Power Automate pour gérer l’approbation et la création d’un article dans l’ERP. Lorsque la donnée n’est pas déjà présente dans l’ERP, pas de soucis non plus.

En résumé, un flux de sortie ou d’entrée peut se modéliser de la sorte.

Attention toutefois à ne pas sous-estimer la charge de travail. On ne fait pas de code certes, mais il faut des compétences sur plusieurs outils, réaliser des tests de bouts en bouts. Au final, ce n’est pas certain (même pas du tout) que la charge en jours/homme soit inférieure à si le sujet avait été traité uniquement dans l’ERP par du développement.

Quid de la sécurité en production, en cas de plantage ? A qui s’adresser en cas de soucis de production qui brasse des milliers de données ? Au support Power Automate ou au support ERP ? Après quelques recherches, voici la réponse : si le client dispose d’un « contrat services Premier »   et si le problème est reproductible facilement, Microsoft répond sous 1h à  24h-48h maximum pour un problème en PROD. Dans tous les cas, il faut créer un ticket depuis le centre d’administration de Power Apps.

 

Des cas plus complexes à concevoir sans développement

Voyons à présent des cas un peu plus délicats pour une conception 100% Power Platform.

J’ai besoin d’un nouveau champ dans la fiche client : ouvrir une Power Apps avec ce champ, ce n’est pas très ergonomique pour l’utilisateur final. Là il s’agit d’un champ, mais s’il y en plusieurs qui ne sont pas forcément pour les mêmes utilisateurs ça vient compliquer les choses. Qui plus est, cela nécessite un réel travail de conception pour le modèle de données : il faut dupliquer beaucoup de choses dans la Power Apps.

Finalement, en l’état, cela parait moins ergonomique, plus compliqué et plus cher à mettre en œuvre. Madame Michu peut elle y arriver toute seule ? Pour manier Power Apps, il faut quand même quelques compétences techniques ou de débrouillardise ! Tout le monde n’y arrive pas en 30 secondes. C’est d’ailleurs pour cela qu’il existe des experts Power Apps sur le marché.

Autre exemple : je souhaite disposer d’un workflow de validation lors de la mise à jour d’un RIB fournisseur. Ici on peut penser que Power Automate est la solution. Certes, mais il y a néanmoins du travail de développement « ERP » à réaliser. Pour avoir un workflow sur un objet qui n’a pas de statut de contrôle disponible, il faudra venir le rajouter en développement. De plus, des développements de rôles ou au minimum privilèges sont aussi à envisager (même si pas obligatoire de passer par un développement pour cela). La charge de travail est probablement plus conséquente sur la Power Platform, d’autant plus qu’il faut avoir une licence Premium pour tous les connecteurs avec l’ERP dans Power Automate.

Enfin, une réflexion plus globale sur le déclencheur de Power Automate : cela peut être soit un timer (toutes les x minutes), soit un évènement de l’ERP. Attention, Power Automate est plus proche d’un processus synchrone – même si ce n’est pas en temps réel puisqu’il y a un délai minime d’une minute – qu’asynchrone. Sans développement additionnel, le changement du RIB du fournisseur est immédiat et est en attente de validation du flux Power Automate qui va venir bloquer le RIB pour son utilisation en premier lieu, avant d’attendre l’approbation et la libération du RIB. Mais il existe bien un laps de temps pendant lequel l’utilisateur a fait sa modification et avant que le flow s’exécute puisse faire des actions non souhaitées avec.

Le futur

On peut clairement penser que ces outils vont aller en s’améliorant, aussi bien dans leur utilisation que dans leur application. La wave plan 1 nous met déjà l’eau à la bouche. Rendez-vous le 2 Avril pour une présentation webinar pour les intéressés.

Un utilisateur qui renseigne son champ spécifique sans se rendre compte qu’il est en fait dans une Power Apps, pourquoi pas !

Attendons voir. Ne négligeons jamais dans nos conceptions ces merveilleux outils dans notre besace de boîte à outils pour concevoir des solutions. Combinés à des rapports électroniques, nous avons des possibilités quasi infinies. Face à des ERP concurrentiels, Microsoft possède de solides arguments technologiques à faire valoir et mettre en avant. Pour autant, ne nous interdisons pas de désigner un bon vieux développement qui économiquement est plus facile à accepter pour un client et également correspond mieux à son besoin métier de l’instant.

Yohann

One comment

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.