[R3dKap]

Salut Geoffroy WAGNER, ne te ronges pas trop quand même… 😅

La question de la documentation des applications Power Apps revient souvent… Et moi-même je me suis déjà challengé sur le sujet…

J’ai récemment trouvé un outil que quelqu’un a développé pour générer automatiquement la documentation d’une application Power Apps. Mais, comme on peut s’en douter, tout système automatique qu’il est il ne fait que générer des pages et des pages de documents Word qui ne font que mettre à plat sur le papier ce qui existe dans l’application : liste des écrans et leurs contrôles, les bouts de codes associés, etc. Mais ce genre d’outil automatique n’est pas capable d’expliquer les subtilités et la logique d’une application comme le peut faire un être humain.

Je considère donc que c’est le rôle du développeur de décrire de lui-même comment son application est architecturée et surtout d’en décrire ses subtilités. Reste à voir sous quelle forme et de quelle manière…

Je vais décrire ici 2 techniques que j’ai personnellement utilisées pour documenter mes applications Power Apps…

Le composant de documentation directement intégré à l’application

L’idée consiste à stocker la documentation dans une liste SharePoint (ou une table du Dataverse selon l’application). Côté application, un composant ajouté à chaque écran permet de créer/éditer la documentation associée à l’écran en question.

Gros avantage : le développeur peut documenter son application directement depuis le Studio au fur et à mesure qu’il la construit. Mais faut être assidu.

Inconvénient : impossible d’incruster des images au milieu du texte car le composant d’édition HTML de Power Apps ne le permet pas.

Je viens de faire un p’tit article ici pour expliquer comment utiliser ce composant :

Le document PowerPoint

Il s’agit ici simplement de documenter l’application dans un document PowerPoint en décrivant ses caractéristiques et ses différents écrans.

Gros avantage : on peut formaliser la documentation comme on le veut (avec des flèches, des graphiques, etc.) + on peut y adjoindre d’autres éléments comme l’architecture de l’application.

Inconvénient : le document est “séparé” de l’application à contrario du composant décrit précédemment qui est directement intégré à l’application.

Par exemple, pour une application qui permet de gérer des demandes je l’ai documentée ainsi :

• Une slide pour décrire l’architecture de l’application : indication de la source de données, présence de flux Power Automate,

• Une slide pour décrire le contenu du App.OnStart : les variables globales, les préchargement de données en collections locales, …

• Une slide pour expliquer à quoi sert chacun des écrans de l’application

• Plusieurs slides pour chaque écran. Par exemple pour l’écran d’accueil qui affiche la liste des demandes, permet de filtrer les demandes, permet de trier les demandes :

  • Une slide pour expliquer comment je construis la liste des demandes (en gros, le Items de la galerie)

  • Une slide pour expliquer le fonctionnement du tri des colonnes

  • Une slide pour expliquer comment les boutons de la barre d’actions sont visibles ou pas en fonction de certains critères liés à la demande sélectionnée

  • etc.

• etc.

Comme tu le vois, l’idée c’est vraiment d’aborder ce document Power Point comme si tu faisais un cours à une personne pour lui expliquer l’application. Il y a très souvent plusieurs slides pour chacun des écrans de l’application afin de bien détailler les différentes fonctionnalités ou caractéristiques qui leur sont propres.

Voilou…

CommentID=64evX2ZnFVy4ys7, PostID=dmMRgV3ikUdjXI6

[Geoffroy]

Merci beaucoup pour ta réponse complète et instructive. C’est vrai aussi qu’en se donnant la peine de décrire précisément ce qu’on fait, on arrive à l’améliorer.

Je vais donc m’y mettre 🙂

CommentID=dbek8SuoK5wYC57, PostID=dmMRgV3ikUdjXI6

[DavidZed]

Bonjour Geoffroy WAGNER ,

Pour ma part je documente en pdf / ppt, pour ce qui est du code j’essaie de commenter au maximum. Pour moi, un bon commentaire décrit les étapes importantes du code, mais surtout le pourquoi tel ou tel formule ex :

// On retire de la collection des items qui n'ont pas été modifiés pour raccourcir le temps de patchnRemoveIf(Collection;Modified=false)

Dans la doc technique, j’essaie, autant que possible d’indiquer si une fonction importante est “cachée” dans un objet : bouton hors champ, fin d’un timer ou d’un média. On est parfois amené à placer des formules sur des évènements d’objets dont l’emplacement n’est pas forcément intuitif à retrouver.

Pour ceux qui se demandent comment quelles sont les balises pour les commentaires dans le code : // Met toute la ligne en commentaire /* Met en commentaire tout le texte entre ces deux balises */

CommentID=rCstzzVtQgVMNB2, PostID=dmMRgV3ikUdjXI6