REX – Retour d’expérience projets PowerApps

Suite à une longue période d’inactivité je me décide à publier ce nouvel article pour vous faire part de mon retour d’expérience de projets PowerApps menés depuis maintenant 1 an. L’idée ici est de balayer les points à noter ou importants qui vous concerneront si vous décidez de débuter un projet PowerApps. En effet, j’ai eu l’occasion de développer/mettre en production un certain nombre d’applications depuis la fin de l’année 2017 ce qui me permet de vous restituer une partie de ce que j’ai pu vivre ou découvrir durant cette période.

Contexte: Sans rentrer dans plus de détails, mon retour d’expérience est entre autre basé sur l’implémentation de:

  • Une PowerApps de service desk (standalone app + form app) utilisée à grande échelle
  • Une PowerApps d’OSD Request (standalone app)
  • Une PowerApps d’Onboarding Requests (standalone app – user management)
  • Une PowerApps de Leave Requests (standalone app)

Le dénominateur commun de ces différents projets est leur back-end. Je m’attache en effet à rester le plus possible dans l’écosystème Office 365. Dès lors, les données résident dans des listes SharePoint. Ce qui a plusieurs avantages mais aussi inconvénients, évidemment. Malgré tout, cela reste selon moi la meilleure solution en terme de rapport « qualité/efficacité/prix/user experience ».

Rentrons donc sans plus tarder dans l’énumération des points et recommandations de ce REX.

Maitrisez le sujet PowerApps

Cette technologie est jeune mais déjà très capable. Malgré tout, vous serez inévitablement confronté à ses limitations. Qu’on parle ici de sources de données « délégables », de fonctionnalité hors ligne, de licence, de passerelle etc… Tâchez d’investiguer les sujets qui vous semblent critiques et ce afin de ne pas vous retrouver bloqués lors du développement et devoir faire machine arrière.

Les temps de développement sont courts

C’est un fait. PowerApps (et Flow) vous simplifient la vie sur bien des aspects.Cela signifie donc que vous pouvez obtenir une application fonctionnelle à 80% en un très court laps de temps. Mais attention aux faux amis. Les 20% restants seront soient du fine tuning, soit de la « plomberie » pour faire fonctionner l’app exactement comme vous le souhaitez. Ces derniers pourcentages sont chronophages, ne sous estimez pas ce délai d’implémentation. En début de projet, vous progresserez énormément en peu de temps, mais votre progression stagnera passés quelques jours.

OUI, il est possible de faire du déconnecté

C’est une question qui revient sans cesse. Oui, vous pouvez créer une application fonctionnant en mode déconnectée. Mais il faut en comprendre le mécanisme (cela rejoint mon point 1). Le mode déconnecté ne fonctionne qu’au travers des applications PowerApps (donc pas de browser, pas de réelle universalité) via un cache de l’application. Votre périphérique doit donc avoir de l’espace mémoire disponible (c’est rarement un problème, PowerApps ne peut allouer que 200Mo de cache par application) et l’utilisation peut être inconstante si le point d’entrée se fait via un navigateur. Car oui, votre application ne peut pas créer de cache au travers d’un navigateur, mais elle peut malgré tout s’y exécuter en mode connecté. Quid d’un utilisateur ayant des données dans un cache local sur son smartphone, et qui lance finalement l’app sur Edge ? Cela nécessite une bonne dose de formation, d’analyse et de réflexion en amont sur la manière dont l’application doit fonctionner.

Gestion des erreurs et retours utilisateurs sont importants

Ça parait simple à dire mais c’est la réalité. PowerApps vous facilite tellement la vie qu’on en oublie rapidement que des fonctionnalités peuvent échouer (je pense notamment à un submit de liste ou une query GET, car oui tout n’est que webservices derrière la façade et les API Microsoft ne sont pas infaillibles). Ces mécaniques sont parfois directement implémentées dans l’app, selon la manière dont vous avez abordé la conception (je pense notamment à l’usage d’un Form et de la fonction SubmitForm versus des champs en pagailles utilisant une fonction Patch() pour le submit). L’utilisation de loader et de fonctions Notify sont des must have.

La gateway n’est disponible que sur votre environnement par défaut

Cela rejoint une nouvelle fois le premier point mais c’est important de le savoir. La gateway fonctionne parfaitement bien. Mais elle n’est (à l’heure actuelle) disponible que via votre environnement par défaut. Résultat, si vous décidez d’utiliser les environnements PowerApps/Flow afin de développer en DEV/UAT/PROD … Vous devrez vous passer des interactions On-Prem sur les environnements DEV et UAT (si on admet que PROD est votre environnement par défaut). C’est dommage, cette situation devrait changer à l’avenir mais elle est toujours d’actualité lors de la rédaction de cet article.

Les runs de flows sont dans un pool commun

Tout aussi important à savoir. Les niveaux de licences viennent avec un nombre de runs de flows par utilisateur par mois (exemple 2000). Avec 20 utilisateurs standards, vous obtenez donc 2000 * 20 runs de flows par utilisateurs par mois. C’est énorme, même pour un tenant ayant peu d’utilisateurs. Vous avez donc de la marge pour implémenter les flows qui vous seront utiles. Je n’ai à l’heure actuelle jamais épuisé le pool chez aucun de mes clients.

Les outils sont fiables

En 1 an, seule la dernière MAJ de l’interface de Flow a eu un effet indésirable sur les flows en production : le scheduler (trigger d’un de mes flows) avait changé de fréquence, passant d’un run par jour à un run toutes les 2 heures. C’est ennuyeux, oui, mais dans mon cas l’impact a été assez faible. En dehors de ce problème, je n’ai pas observé de régression suite à des updates.

Les cmdlets ne sont pas encore au point

Oui, Flow et PowerApps viennent avec des cmdlets d’administration. Au delà du fait qu’ils nécessitent d’importants droits pour pouvoir être exécutés, ces cmdlets sont pour l’heure trop limités. Impossible de créer par scripts des connexions chez vos utilisateurs par exemple. Ne comptez donc pas vraiment dessus pour scripter d’éventuels déploiement etc.

Les utilisateurs apprécient PowerApps

C’est simple, 100% des clients chez qui j’ai pu développer des applications ont un retour positif de la part de leurs utilisateurs.

Vous allez vous prendre la tête avec les types de données SharePoint

Si vous envisagez de créer une standalone app (avec comme source SPO) ou une form app, alors vous serez tôt ou tard embêtés par les types spécifiques à SPO : choice, multi-choice, people-picker, bool, lookup. Renseignez-vous sur ce blog post précieux  et faites un PoC des scénarios pour les valider

Documentez, commentez vos formules et actions !

Difficile d’introduire de bonnes pratiques de documentation d’une application sans que ce soit fastidieux. Faites votre possible pour documenter vos formules (vous pouvez ajouter un commentaire via « // » dans PowerApps) et vos actions dans Flow. Et oui, en cliquant sur « … » vous pourrez insérer un commentaire visible en haut de la brique de l’action : très pratique pour la relecture

Il n’y a pas de versioning Flow

Et c’est vraiment regrettable, mais à l’heure actuelle, rien d’autre à faire que d’exporter régulièrement les releases majeures de vos Flows pour les backuper à l’ancienne.

Les form app SPO sont difficiles à tester

Impossible de faire remonter les données dans votre formulaire SPO PowerApps. De fait, vous ne travaillez pas vraiment sur un item lorsque vous développez, mais surtout avec les propriétés de l’item au travers du composant « SharePointIntegration ». Rien d’insurmontable, mais ça rallonge le testing et le rend plus pénible

Parallélisez dans PowerApps et faites des Refresh()

Utilisez sans restriction la fonction Concurrent() et pensez à rafraîchir vos sources de données régulièrement (les timers sont géniaux pour faire cela automatiquement)

Les autorisations de Flows remontent dans votre PowerApps

Si votre PowerApps démarre un flow (trigger Powerapps) et que ce dernier utilise plusieurs connexions vers des sources de données variées, alors l’utilisateur de l’application devra également avoir une connexion valide à ces sources : c’est son identité qui sera utilisée de A à Z. Autrement dit, n’utilisez pas ce trigger et préférez des triggers « détournés » si vous pouvez abstraire le compte qui doit exécuter les flows

Les pages d’accueil PowerApps et Flow ne sont pas efficaces

Les pages d’accueil PowerApps et Flow ne vous permettent pas de retrouver rapidement une application particulière ou bien l’ensemble des Flows liés à une application. L’interface ne permet pas de réellement catégoriser les apps ou flux et c’est dommage. Résultat : pensez à utiliser une convention de nommage très pertinente de vos Flows + y ajouter une description. Cela sera rapidement précieux.

Les ressources web et les livres périment vite

Privilégiez la documentation des sites officiels Powerapps ou Flow, ainsi que leur blog d’actualités pour vous documenter. Si vous trouvez des tutoriels ou astuces sur le web qui datent de plus de 6 mois, vous pouvez considérer qu’ils sont déjà obsolètes pour la plupart. Les joies du cloud et des updates très rapides.

 

En espérant que les divers points abordés dans cet article vous aideront, n’hésitez pas à me contacter si vous avez la moindre question.

Cet article a été rédigé en collaboration avec Benoît Jester (pour les fans de SharePoint, son blog est accessible ici )

Laisser un commentaire