La promesse de Microsoft est belle ! Les outils de la Power Platform (Power BI, Power Automate et Power Apps) sont utilisables directement par des représentants des équipes, dites “métiers”. Ce sont des utilisateurs du système d’information.
Certains ont un appétit particulier pour la gestion des processus et l’informatique, sans non plus être des geeks ni disposer de compétences de développeur. Ce profil s’appelle le “Citizen Developer” ou le “Power User” (à la sauce Microsoft).
Est-ce la fin du métier de développeur ?
Avant d’être consultant Microsoft 365, j’ai été développeur durant plusieurs années. Et comme tout développeur qui se respecte, j’ai certains réflexes qui sont bien ancrés. Ces réflexes vont parfois à l’inverse de la simplicité, en apparence au moins. Ils nécessitent de l’expérience du développement pour s’acquérir.
Chez mes clients, je reprends régulièrement des applications Power Apps réalisées par des Power Users. La plupart du temps, ces applications sont globalement fonctionnelles. La promesse de Microsoft du “Citizen Developer” paraît donc tenue ! Cependant, certaines subtilités sont souvent mal maîtrisées… Ce qui peut poser des problèmes, plus ou moins handicapants pour l’évolution et la maintenance des applications Power Platform. Cela crée ce que l’on appelle communément une “dette technique”.
Voici mon top 5 de ces “subtilités”, pourquoi cela pose un problème et comment y remédier.
1. Renommer les composants
La première subtilité (et je la rencontre systématiquement) est l’absence de convention de nommage des différents composants. À chaque composant créé, Power Apps génère automatiquement un nom qui permet de le réutiliser dans différentes actions de l’application.
Par exemple : je crée une TextBox. Celle-ci va s’appeler TextBox1. Si j’en crée une deuxième, elle va s’appeler TextBox2, et ainsi de suite.
Si votre application n’a que 5 composants, ce n’est pas un drame de garder les noms par défaut. En revanche, quand vous multipliez les écrans et les composants, cela devient plus complexe pour s’y retrouver et ne pas mélanger tous les composants. Et si vous implémentez des calculs à partir de valeurs de composants, cela devient inévitablement un véritable casse-tête et une usine à bugs.
Un développeur a l’habitude de définir des conventions de nommage* pour avoir un code compréhensible et par conséquent, facilement maintenable.
*NB : la définition d’une convention de nommage s’étend aussi aux différentes variables créées dans les applications.
Ce que je recommande comme règles de nommage sur Power Apps
Nom du composant = un trigramme permettant d’identifier le type de composant (Txt pour TextBox par exemple) + le nom de l’écran (en effet, les composants sont globaux à une application et pas spécifiques à un écran, ce qui peut être assez perturbant) + une description de ce que fait le composant.
Par exemple : j’ai un composant Label (libellé) affichant un titre sur la page d’accueil. Je vais l’appeler : LblHomeTitle.
Ce travail peut paraître fastidieux, notamment quand le but de l’utilisation de Power Apps est d’optimiser le « Time to Market » à l’extrême (développer Jour J et utiliser J+1, ce qui est possible avec la Power Platform). Cependant, ce temps est vite amorti dès que l’on met à jour l’application après plusieurs semaines / mois. D’autant plus quand c’est quelqu’un d’autre qui fait cette mise à jour.
Les conventions ne sont pas un caprice de développeur. Elles sont la promesse d’une évolutivité et maintenabilité à moyen et long terme. Comme les applications de la Power Platform sont amenées à évoluer rapidement, cette bonne pratique est essentielle.
2. Gérer les erreurs de code
La deuxième subtilité concerne la gestion des erreurs. Pour une fonctionnalité donnée, un Citizen Developer va penser à gérer le scénario passant. S’il est un peu aguerri, il va peut-être penser à gérer certains cas d’erreurs fonctionnelles évidentes. En revanche, un développeur aura l’habitude de couvrir certains cas d’erreurs techniques habituelles.
Par exemple, un écran doit afficher le résultat d’une division. Le Citizen Developer saura afficher le résultat de la division sans problème. En revanche, il n’aura pas forcément le réflexe de couvrir certaines erreurs basiques. Tel que par exemple, la division par 0 ou des opérandes qui ne sont pas numériques.
En outre, un développeur saura toujours tracer les erreurs correctement. Que ce soit pour l’utilisateur (message d’erreur clair) et/ou pour l’administrateur (log d’erreurs détaillé).
La bonne gestion des erreurs est une règle d’or du développeur qui concerne absolument le Citizen Developer. Elle va permettre d’éviter des bugs (tests en amonts intégré au code) et de réparer très rapidement une application buggée (grâce au journal d’erreur qui indiquera rapidement le composant en défaut, facile à isoler pour la correction).
3. Commenter le code
Ici, on s’intéresse toujours à la maintenabilité du code (sujet clé). Cette problématique rejoint en partie la première recommandation (règle de nommage), mais elle est plus globale.
D’une manière générale, les développeurs parlent un langage commun utilisant des règles communes appris à l’école et également durant leur expérience professionnelle (règle de syntaxe, d’algorithmique ou de découpage, commentaires du code etc.). Pendant des années, les développeurs ont été jugés et élevés par leurs pairs. Ce qui leur a permis de comprendre et d’adopter des pratiques communes dans leurs réalisations. Idéalement, un programme réalisé par un développeur A doit pouvoir être modifié par un développeur B, sans explication, grâce à cette culture commune vis-à-vis du code.
Pour un Power User X, c’est quelque chose qui n’est pas du tout intuitif. Celui-ci va créer son application de la façon la plus claire et compréhensible pour lui-même, ce qui n’est pas forcément la même que celle de son voisin Power User Y.
On ne va pas résoudre des années de pratiques et d’apprentissage par “Power magie” avec la Power Platform. Mais autant la bonne compréhension de règles de syntaxe, d’algorithmique, de découpage ne s’apprend pas en 5 minutes, autant il est assez simple de bien commenter le code. Un code bien commenté (je sais que ce sujet est controversé entre développeurs) améliore la lisibilité et la compréhension de ce qui est codé entre deux Power Users X/Y…. Et même pour celui qui doit reprendre son propre code des mois (ou des années) plus tard et comprendre ce qu’il a voulu faire et comment…
Commenter son code pour un Citizen Developer est un levier facilement actionnable pour améliorer grandement la maintenabilité de ses applications et le ROI (Retour Sur Investissement) de la Power Platform.
4. Créer des environnements distincts
Toujours dans le but d’optimiser le Time-to-Market, Microsoft a créé un concept d’environnements.
La solution par défaut est un peu extrême : on a un environnement unique qui héberge toutes les applications. Pour un Citizen Developer, cette notion d’environnement semble abstraite et n’est pas du tout intuitive. Pour un développeur, elle est fondamentale. De même que l’on ne fait pas des réglages de freins de sa voiture en roulant, on ne peut pas faire des mises à jour d’applications en les utilisant.
D’où le découpage a minima en 2 environnements séparés par les équipes informatiques : développement et production. Souvent, on en ajoute quelques autres si c’est utile pour des applications plus sensibles : maintenance (séparée du développement), recette, voire formation…
Par défaut, le Citizen Developer code directement dans l’environnement de production de la Power Platform ! Or, il doit faire évoluer une application déjà en production sans impacter les autres utilisateurs de son application sauf s’il veut déclencher une tempête chez l’équipe support ! Dans ce cas-là, il est donc intéressant de créer d’autres environnements pour gérer ce processus de livraison et bien distinguer les phases de développement, recette et production. Cela permet aussi de segmenter les accès aux différents environnements.
Techniquement, un environnement » est un espace de stockage cloud dans Microsoft 365, où les accès sont segmentés, sur lequel on héberge des applications Power Apps et/ou des flux Power Automate.
NB 1 : La même application dans 2 environnements différents aura par défaut les mêmes sources de données. Il faut donc faire attention à mettre à jour les sources de données quand on passe d’un environnement à un autre (sources de données de production VS source de données de développement ou de maintenance par exemple).
NB 2 : La création d’environnements nécessite une licence Power Apps Premium.
5. Optimisation des performances
Là encore, le concept de performances peut sembler un peu flou pour le Citizen Developer… C’est habituellement le “problème” des informaticiens de fournir des applications performantes.
Mais le Citizen Developer ne peut pas s’en désintéresser dès lors qu’il devient concepteur – développeur d’applications. Il doit avoir un peu d’attention sur les dimensions des données manipulées notamment, et sur manière de le faire.
La performance est un sujet est assez subtil avec Power Apps car il intervient à plusieurs niveaux :
- Le premier c’est le bon choix de la source de données. Je vois souvent des utilisateurs vouloir basculer un fichier Excel vers Power Apps en gardant comme source de données… le fichier Excel d’origine. En règle générale, je recommande plutôt d’utiliser par défaut SharePoint comme source de données sur des modèles simples ou encore le Dataverse si l’entreprise dispose de licences Dynamics, qui est la source la plus optimale pour Power Apps.
- Le deuxième est directement lié à la qualité du code. Il y a souvent plusieurs moyens de récupérer des collections des données. Et généralement un Citizen Developer va utiliser une boucle pour reconstruire une collection, ce qui peut paraitre plus intuitif, alors même qu’il existe des mécanismes de requêtes qui permettent d’obtenir directement ce que l’on veut.
- Le troisième c’est ce que j’appelle l’effet de seuil. Par défaut, Power Apps définit un seuil de requête à 500 lignes. Dans les faits, on n’a quasiment jamais besoin de requêter plus de 500 lignes. Personne n’est capable de lire 500 lignes à la fois (ou même d’afficher 500 lignes différentes visibles sur un écran). Il est donc très souvent pertinent de réduire le volume de ses requêtes en ajoutant des filtres et donc d’optimiser les performances de l’application.
Au-delà de ce top 5, j’aurais pu citer d’autres subtilités comme la gestion de la sécurité. Ou encore la capacité à déterminer si un cas d’usage doit ou ne doit pas être implémenté en « low code ». Ou encore la maitrise du cycle de livraison d’une application, etc… Mais la prise en compte de ce top 5 va déjà grandement faciliter la qualité, la maintenabilité et la performance du code pour le Citizen Developer.
Pour répondre à la question du début de cet article : « Est-ce la fin du métier de développeur ? »
Selon moi, la réponse est non… le métier de développeur doit se réinventer pour s’adapter au low code – no code. Et le Citizen Developer doit adopter quelques-unes des pratiques du développeur pour produire une application de meilleure facture.
Un profil est en train d’émerger dans cette mouvance du low code, c’est le No Code Ops.
C’est lui qui a la charge d’animer des ateliers de création d’applications avec des utilisateurs du métier. Il a aussi la charge de les conseiller sur les bonnes pratiques à adopter pour avoir des applications robustes. Un tel profil permet également à la DSI d’avoir un contrôle sur les applications créées notamment pour appliquer les bonnes pratiques vues ci-avant, en termes de sécurité et pour éviter le « Shadow IT » , qui peut très vite prendre de l’ampleur avec Power Apps ou d’autres outils de low code – no code du marché.
