Concevoir des formulaires intuitifs dans Power Apps

Un formulaire Power Apps est l’écran où vos équipes saisissent, consultent ou modifient une fiche : une demande d’achat, un rapport d’intervention, une note de frais. C’est souvent lui qui décide du succès de l’application, car un formulaire clair donne des données propres et un formulaire confus donne des erreurs et des ressaisies. Power Apps fournit un contrôle prêt à l’emploi, qu’il reste à organiser et à valider avec quelques formules.

À quoi sert un bon formulaire dans une entreprise

Prenons un service achats qui reçoit ses demandes par e-mail. Il manque souvent le centre de coût, le fournisseur est écrit de trois façons, et l’acheteur passe du temps à relancer. Avec un formulaire Power Apps, le centre de coût devient une liste à choisir, le montant doit être un nombre, et la demande ne part pas tant que les champs obligatoires sont vides. Si le demandeur choisit le motif « Autre », un champ de précision apparaît, et lui seul.

Ce que cela change : moins de relances, des données directement exploitables dans un tableau de bord, et une saisie qui prend moins de temps à celui qui la fait. Une fois la demande enregistrée, un flux d’approbation peut la transmettre au bon responsable sans intervention manuelle.

Deux contrôles et trois modes de formulaire

On lit souvent que Power Apps propose trois types de formulaires. Plus exactement, il y a deux contrôles : Modifier le formulaire (Edit form), pour saisir, et Formulaire d’affichage (Display form), pour consulter. Le premier fonctionne selon trois modes :

Deux propriétés relient le formulaire aux données. DataSource désigne la table, par exemple Demandes, et Item désigne la fiche à afficher, le plus souvent la ligne choisie dans une galerie qui liste les demandes : Galerie1.Selected. Le formulaire crée alors une carte par champ, c’est-à-dire un petit bloc qui contient l’étiquette, le contrôle de saisie et le message d’erreur.

Le fonctionnement courant tient en quelques formules, placées dans OnSelect des boutons. Elles sont écrites avec la virgule : dans une interface en français, selon la langue ou les réglages régionaux, le séparateur devient le point-virgule (;), et le point-virgule qui enchaîne deux formules devient un double point-virgule (;;).

NewForm(FormulaireDemande); Navigate(EcranSaisie, ScreenTransition.None)
SubmitForm(FormulaireDemande)
ResetForm(FormulaireDemande); Back()

La première ligne, sur le bouton Nouvelle demande, prépare une fiche vide et ouvre l’écran de saisie. La deuxième, sur Enregistrer, vérifie les champs puis envoie les données. La troisième, sur Annuler, remet les valeurs d’origine et revient en arrière. Pour tout le détail, voyez la documentation de Microsoft sur ces fonctions.

La suite se règle sur le formulaire lui-même. Dans OnSuccess, qui s’exécute quand l’enregistrement a réussi :

Notify("Demande enregistrée", NotificationType.Success); Back()

En cas d’échec, OnFailure s’exécute et l’écran reste affiché. Une étiquette dont le texte est FormulaireDemande.Error montre alors le message d’erreur, et l’utilisateur peut corriger sans perdre sa saisie.

Choisir le bon contrôle pour chaque champ

Le type de colonne détermine le contrôle proposé par défaut, mais ce n’est pas toujours le plus pratique. Partez de ce que la personne doit faire :

Pour remplacer un contrôle, sélectionnez la carte, déverrouillez-la (Déverrouiller, dans le volet des propriétés avancées), puis insérez le nouveau contrôle. Adaptez ensuite la propriété Update de la carte, qui indique la valeur envoyée à la source. Pour une liste déroulante nommée ListeMotif, sur une colonne de choix SharePoint, on écrit par exemple ListeMotif.Selected. C’est un oubli fréquent : si Update ne vise pas le bon contrôle, la valeur choisie n’arrive pas dans la source.

Organiser les champs et s’adapter aux écrans

Regroupez ce qui va ensemble : le demandeur, puis la demande, puis les pièces jointes. Placez les champs obligatoires en premier, et posez uniquement les questions dont quelqu’un se servira. Chaque champ retiré est un gain de temps à chaque saisie.

Pour un formulaire long, découpez-le en sections avec un titre, ou répartissez les champs sur plusieurs écrans. Dans ce dernier cas, chaque écran peut porter son propre formulaire, et une seule formule enregistre le tout à la fin :

Patch(Demandes, Defaults(Demandes), Formulaire1.Updates, Formulaire2.Updates)

Updates contient les valeurs saisies dans chaque formulaire, et Defaults prépare une nouvelle ligne dans la table.

Sur téléphone, gardez un seul champ par ligne, réglez la propriété Columns du formulaire en conséquence, et prévoyez des zones de toucher assez grandes. Le repère courant des guides d’accessibilité est de 44 pixels. Testez sur un vrai téléphone : l’aperçu ne montre ni le clavier qui recouvre la moitié de l’écran, ni le pouce qui manque sa cible.

Valider les saisies avant l’envoi

SubmitForm contrôle déjà les champs obligatoires et les contraintes de la source de données : si un champ pose problème, rien n’est envoyé. La propriété Required d’une carte rend un champ obligatoire. Pour aller plus loin, quelques formules suffisent.

Griser le bouton tant que le formulaire est incomplet, dans la propriété DisplayMode du bouton :

If(FormulaireDemande.Valid, DisplayMode.Edit, DisplayMode.Disabled)

La propriété Valid du formulaire vaut « vrai » quand toutes ses cartes sont valides.

Vérifier le format d’une adresse e-mail, dans la propriété Visible d’une étiquette placée sous le champ, qui affiche par exemple « Adresse e-mail non valide » :

And(Not(IsBlank(DataCardValue3.Text)), Not(IsMatch(DataCardValue3.Text, Match.Email)))

L’étiquette apparaît seulement quand le champ est rempli et que son contenu ne ressemble pas à une adresse. Le nom DataCardValue3 est celui que Power Apps a donné au contrôle : remplacez-le par le vôtre, ou mieux, renommez vos contrôles. Avec le contrôle moderne de saisie, .Value remplace .Text.

Contrôler la cohérence de deux dates, dans la propriété Visible d’un message ou dans une condition du bouton :

DateFin.SelectedDate < DateDebut.SelectedDate

Afficher un champ seulement si besoin. Pour le champ de précision de notre exemple, écrivez la même formule dans les propriétés Visible et Required de sa carte :

ListeMotif.Selected.Value = "Autre"

Le champ n’apparaît et n’est obligatoire que lorsque le motif est « Autre ». Si vous réglez seulement Required sur « vrai », une carte masquée peut bloquer l’envoi sans que l’utilisateur comprenne pourquoi.

Affichez les messages d’erreur à côté du champ concerné. Le message prévu dans chaque carte le fait déjà, avec la formule Parent.Error. Un message général en haut de l’écran passe souvent inaperçu, surtout sur téléphone.

Rendre le formulaire rapide et accessible

Rapidité

Un formulaire lent décourage. Trois réglages font l’essentiel de la différence :

• Chargez les listes de référence une seule fois, à l’ouverture de l’écran, dans OnVisible, avec une collection gardée en mémoire. Par exemple : ClearCollect(colMotifs, Motifs). La liste déroulante lit ensuite colMotifs au lieu d’interroger la source.
• Évitez de placer une recherche dans une source à l’intérieur d’une propriété qui se recalcule sans cesse, comme Visible ou Text : réservez ces calculs à un événement, comme OnChange.
• Si vos listes dépassent 500 lignes, vérifiez les avertissements : la délégation détermine si toutes les lignes sont réellement prises en compte.

Pour écrire plusieurs tables à la fois ou modifier une fiche sans formulaire, la fonction Patch prend le relais, mais elle ne fait aucune validation à votre place : à réserver aux cas où le formulaire ne suffit pas.

Accessibilité

Un formulaire accessible est aussi plus facile pour tout le monde. Vérifiez les points suivants :

• renseignez AccessibleLabel sur les contrôles, c’est le texte lu par les lecteurs d’écran ;
• gardez un contraste suffisant entre le texte et le fond ;
• assurez-vous que tout se fait au clavier ;
• donnez des instructions claires pour les champs complexes, sans limite de temps pour remplir le formulaire.

Pour l’ordre de passage au clavier, ne numérotez pas les champs un par un. Microsoft recommande de régler TabIndex sur 0 ou -1 : 0 inclut le contrôle dans la navigation, -1 l’en exclut. Les contrôles modernes utilisent AcceptsFocus, qui joue le même rôle. C’est l’ordre des contrôles dans l’écran qui doit rester logique, car les lecteurs d’écran le suivent. Le vérificateur d’accessibilité du Studio repère une partie des oublis.

Tester avant de déployer

Aucun formulaire n’est bon du premier coup. Le test le plus utile ne coûte rien : donnez-le à deux ou trois vrais utilisateurs, avec un cas réel, sans les aider. Notez où ils hésitent, quel champ ils comprennent mal et combien de temps prend la saisie. Essayez aussi le mauvais chemin : champ vide, date incohérente, perte de réseau au moment d’enregistrer, retour en arrière en plein milieu.

Une fois l’application en service, les statistiques d’usage de Power Apps indiquent combien de personnes s’en servent, mais pas à quel champ elles abandonnent. Pour une mesure aussi fine, il faut relier l’application à Azure Application Insights et enregistrer vous-même les étapes avec la fonction Trace. Pour la plupart des formulaires internes, observer deux utilisateurs suffit largement.

Améliorez ensuite par petites touches : un champ retiré, un libellé plus clair, une liste plus courte.

Formulaire critique : à quel moment déléguer

Un formulaire de quelques champs sur une liste SharePoint se construit très bien seul, en suivant cette page. Il vaut mieux vous faire aider lorsque la validation dépend de règles métier nombreuses, lorsque la fiche écrit dans plusieurs tables liées ou contient des données personnelles, ou lorsque des dizaines de personnes en dépendent chaque jour et qu’une erreur de saisie coûte cher. Un expert regardera d’abord la structure des données, souvent à l’origine des formulaires compliqués, avant de toucher aux écrans. Vous pouvez aussi voir ce que recouvre une application métier sur Power Apps.

Questions fréquentes

Quelle est la différence entre un formulaire d’affichage, d’édition et de création ?

Le formulaire d’affichage sert uniquement à consulter une fiche. Le contrôle de modification sert à deux usages selon son mode : modifier une fiche existante avec FormMode.Edit, ou en créer une avec FormMode.New. Le mode FormMode.View lui fait aussi afficher une fiche sans modification possible.

Comment réduire le temps de chargement d’un formulaire ?

Limitez le nombre de champs et de cartes, chargez les listes de référence une fois dans une collection, et évitez les recherches dans une source au sein des propriétés qui se recalculent en permanence. Sur une application avec beaucoup de données, vérifiez aussi les avertissements de délégation. Mesurez sur le téléphone utilisé par vos équipes, pas seulement sur votre poste.

Peut-on masquer un champ selon la réponse de l’utilisateur ?

Oui, avec la propriété Visible de la carte. Par exemple : ListeMotif.Selected.Value = "Autre". Si ce champ doit aussi être obligatoire, écrivez la même condition dans Required, pour qu’une carte masquée ne bloque pas l’envoi.

Quelle taille prévoir pour les boutons sur mobile ?

Le repère courant des guides d’accessibilité est de 44 pixels de côté, ce qui correspond à une zone confortable sous le doigt. Prévoyez aussi de l’espace entre les boutons, pour éviter de toucher le mauvais. L’essai sur un vrai téléphone reste le meilleur contrôle.

Comment tester efficacement un formulaire avant son déploiement ?

Faites-le remplir par de vrais utilisateurs, sans les aider, et notez leurs hésitations. Essayez aussi les cas d’erreur : champ vide, mauvais format, réseau coupé pendant l’enregistrement. Vérifiez enfin dans la source de données que chaque colonne reçoit bien la valeur attendue.