Concevoir une navigation fluide entre écrans

La navigation dans Power Apps, c’est la façon dont une personne passe d’un écran à l’autre : ouvrir une demande, revenir à la liste, atteindre le bon menu. Elle repose sur quelques fonctions simples, Navigate et Back en tête. Dans une entreprise, elle décide souvent si une application est adoptée sans formation ou si elle reste de côté après quelques jours.

Ce qu’une navigation claire change pour vos équipes

Prenons une situation type : une application de demandes de congés dans une PME. Le salarié dépose sa demande, le manager la valide, le service RH suit l’ensemble. Si le manager doit traverser quatre écrans pour trouver les demandes en attente, il finira par répondre par e-mail, et l’application perdra son intérêt.

Une navigation bien pensée donne à chacun un chemin court vers sa tâche, un bouton de retour toujours au même endroit et un écran d’accueil qui dit quoi faire. Les utilisateurs posent moins de questions, abandonnent moins de saisies et n’ont pas besoin d’un mode d’emploi. Pour un responsable de service, c’est souvent la différence entre un outil utilisé et un outil contourné.

Ces règles valent pour les applications dites Canvas, où vous dessinez chaque écran. Si vous partez de zéro, commencez par créer une première application Canvas, puis revenez structurer ses déplacements.

Les trois fonctions à connaître

Navigate et Back ne s’utilisent que dans une formule de comportement, comme la propriété OnSelect d’un bouton. Elles changent seulement l’écran affiché : les autres écrans continuent d’exister, et un curseur déplacé garde sa valeur quand on y revient.

Les formules de cet article utilisent la virgule. Dans une interface en français, selon la langue ou les réglages régionaux, le séparateur d’arguments devient le point-virgule (;) et l’enchaînement de deux formules s’écrit ;;.

Une correction par rapport à ce qu’on lit souvent : Back n’accepte pas de nombre d’écrans. Back(2) n’existe pas. Son seul argument, facultatif, est la transition, comme dans Back(ScreenTransition.Cover). Pour remonter plus haut, appelez Navigate vers l’écran voulu. La référence Microsoft des fonctions Back et Navigate détaille la syntaxe.

Créer des boutons et choisir la transition

Un bouton de navigation tient en une ligne, dans sa propriété OnSelect :

Navigate(EcranDemande, ScreenTransition.Fade)

Pour l’essayer pendant la création, maintenez Alt et cliquez sur le bouton, ou lancez l’aperçu avec F5. Le deuxième argument décide de l’animation :

• ScreenTransition.None : remplacement immédiat, c’est la valeur par défaut.
• ScreenTransition.Fade : l’écran actuel s’efface.
• ScreenTransition.Cover et CoverRight : le nouvel écran glisse par-dessus, vers la gauche ou vers la droite.
• ScreenTransition.UnCover et UnCoverRight : l’écran actuel glisse et découvre le nouveau.

Back applique d’office la transition inverse de celle de l’aller : vous n’avez rien à régler dans la plupart des cas. Restez sobre : une même transition pour un même type de déplacement suffit, et un outil de travail n’a pas besoin de spectacle.

Placez les boutons principaux toujours au même endroit, par exemple le retour en haut à gauche et l’action principale en bas. Les utilisateurs prennent ainsi des automatismes. Une icône ne suffit pas toujours : ajoutez un mot quand le sens n’est pas évident.

Construire un menu quand l’application grandit

Au-delà de cinq ou six écrans, les boutons isolés encombrent l’interface. Un repère simple : si vous ajoutez un écran et ne savez plus où poser son bouton, il faut un menu. Une galerie, le contrôle qui répète un modèle pour chaque ligne d’une liste, fait très bien l’affaire. Dans sa propriété Items :

Table(
    {Libelle: "Accueil", Ecran: EcranAccueil},
    {Libelle: "Demandes", Ecran: EcranDemandes},
    {Libelle: "Validation", Ecran: EcranValidation}
)

Dans la propriété OnSelect de la galerie, un seul appel sert à toutes les lignes :

Navigate(ThisItem.Ecran, ScreenTransition.None)

Pour montrer la page active, comparez l’écran de la ligne à l’écran affiché, dans la propriété TemplateFill :

If(ThisItem.Ecran.Name = App.ActiveScreen.Name, RGBA(0, 120, 212, 0.15), RGBA(0, 0, 0, 0))

Un menu efficace comporte :

• des icônes reconnaissables pour chaque section ;
• des libellés courts, de deux ou trois mots au plus ;
• un repère visuel de la page active ;
• un ordre qui suit le parcours habituel de l’utilisateur.

Pour ne pas recopier ce menu sur chaque écran, transformez-le en composant réutilisable, modifié une seule fois pour toute l’application.

Transmettre des informations d’un écran à l’autre

Le troisième argument de Navigate transmet des données à l’écran d’arrivée. C’est un enregistrement, entre accolades, dont chaque colonne devient une variable de contexte, c’est-à-dire une variable propre à cet écran. Depuis une liste de demandes :

Navigate(EcranDetail, ScreenTransition.Cover, {varDemande: ThisItem})

Sur EcranDetail, une étiquette affiche alors varDemande.Titre, et un bouton peut modifier la ligne avec la fonction Patch, qui écrit dans vos données sans formulaire. Vous pouvez passer plusieurs valeurs :

Navigate(EcranDetail, ScreenTransition.Fade, {ID: 12, Teinte: Color.Red})

C’est la seule façon de définir une variable de contexte depuis un autre écran, et ces variables sont conservées quand on change d’écran. Pensez donc à les remplacer lors du passage suivant.

Une formule peut aussi lire directement un contrôle d’un autre écran, comme GalerieDemandes.Selected. C’est pratique, mais Microsoft conseille de limiter ces dépendances entre écrans, car elles obligent à charger l’écran référencé. Sur une application importante, préférez le passage par Navigate. Pour une saisie sur plusieurs écrans, voyez aussi comment concevoir des formulaires simples à remplir.

Écran de départ, retour et droits d’accès

Choisir l’écran de départ

La propriété App.StartScreen indique le premier écran affiché. Elle peut dépendre d’un paramètre reçu dans l’adresse, par exemple depuis le lien d’un e-mail de validation :

If(IsBlank(Param("demande")), EcranAccueil, EcranDetail)

Microsoft signale que le premier écran de la liste est toujours initialisé avec l’application. Si vous utilisez App.StartScreen, gardez en tête de liste un écran vide ou très léger.

Gérer l’historique

Chaque appel à Navigate est mémorisé, et des appels successifs à Back remontent jusqu’au premier écran. Back renvoie false si l’utilisateur n’a encore navigué nulle part, ce qui arrive quand il entre directement par un lien. Prévoyez donc un bouton vers l’accueil, qui appelle Navigate. Il évite aussi les parcours en boucle où il faudrait appuyer cinq fois sur retour : au-delà de trois appuis pour revenir à l’accueil, revoyez le parcours.

Adapter le menu aux droits de chacun

Certains écrans ne concernent que certains rôles. Au démarrage du premier écran, vérifiez la présence de l’utilisateur dans une table de rôles :

Set(varEstAdmin, Not(IsBlank(LookUp(Administrateurs, Email = User().Email))))

Mettez ensuite varEstAdmin dans la propriété Visible du bouton concerné. Attention : masquer un bouton n’est pas une protection. La vraie sécurité se règle sur la source de données, avec les rôles de Dataverse ou les autorisations de SharePoint.

Garder des écrans rapides sur tous les appareils

Une navigation fluide dépend aussi du temps d’ouverture de chaque écran. Les pages de Microsoft sur les performances donnent des pistes concrètes :

• Un premier écran léger. Évitez d’y charger une galerie ou une table. L’utilisateur voit l’application plus vite.
• Peu de calculs au démarrage. Déplacez ce que vous pouvez de App.OnStart vers App.Formulas, qui laisse Power Apps décider du bon moment.
• Prudence avec les collections. Un ClearCollect sur beaucoup de lignes dans OnVisible ralentit chaque passage sur l’écran. Pour des données en lecture seule, branchez la galerie directement sur la source.
• Des images adaptées. Compressez les images avant de les importer et supprimez les médias inutilisés. Un fichier .svg pèse souvent moins qu’un .png.
• Découper si besoin. Si des parties de l’application sont vraiment séparées, faites-en des applications distinctes, reliées par Launch et des paramètres.

Nous n’avons pas trouvé de plafond officiel de contrôles par écran dans ces pages. Le chiffre de 30 souvent conseillé reste un signal d’alerte utile : au-delà, demandez-vous si l’écran ne fait pas deux métiers à la fois.

Les propriétés OnVisible du nouvel écran et OnHidden de l’ancien servent à lancer une action au moment de la transition, par exemple réinitialiser une variable. Gardez-y des traitements courts.

Une navigation réussie sur ordinateur peut être pénible au doigt. Essayez l’application sur un vrai téléphone, et pas seulement dans l’aperçu de Studio. Un repère courant pour les zones tactiles est de 48 pixels de côté au minimum : ce n’est pas une règle de Microsoft, mais un bouton trop petit provoque vite des appuis ratés. Gardez aussi le même en-tête sur tous les écrans, pour que chacun sache où il se trouve.

Quand faire appel à un expert pour structurer l’application

Sur une application de cinq écrans utilisée par un seul service, ces règles suffisent, et vous pouvez avancer sans aide. Un regard extérieur devient utile quand l’application dépasse plusieurs dizaines d’écrans, quand plusieurs métiers y ont des parcours différents, ou quand les écrans deviennent lents sans cause évidente. Dans ces cas, le découpage décidé au départ pèse plus que chaque formule, et il coûte cher à reprendre une fois l’outil en service. Notre page sur les applications métier avec Power Apps décrit ce type de projet et quand il se justifie.

Questions fréquentes

Quelle est la différence entre Navigate et Back dans Power Apps ?

Navigate ouvre un écran précis, avec une transition et éventuellement des variables de contexte, et l’ajoute au parcours mémorisé. Back revient à l’écran affiché juste avant, comme le bouton retour d’un navigateur. Il applique par défaut la transition inverse de celle de l’aller.

Comment revenir deux écrans en arrière ?

Back(2) n’existe pas : l’argument de Back est une transition, pas un nombre. Le plus simple est d’appeler Navigate vers l’écran voulu. Cette méthode garde le parcours lisible pour la personne qui reprendra l’application.

Combien de contrôles peut contenir un écran Power Apps ?

Nous n’avons pas trouvé de plafond officiel par écran dans les pages de Microsoft sur les performances. Prenez 30 contrôles comme signal d’alerte plutôt que comme limite. Si un écran ralentit, répartissez son contenu ou regroupez ce qui se répète dans un composant.

Comment transmettre des données entre deux écrans avec Navigate ?

Passez un enregistrement en troisième argument : Navigate(Ecran2, ScreenTransition.None, {Nom: "Dupont", Age: 35}). Sur l’écran d’arrivée, Nom et Age sont des variables de contexte, utilisables directement. Elles restent en mémoire après le changement d’écran.

Comment masquer un menu selon les autorisations de l’utilisateur ?

Comparez User().Email à une table de rôles, gardez le résultat dans une variable, puis utilisez-la dans la propriété Visible. Masquer un bouton n’empêche pas l’accès aux données. Réglez donc aussi les droits sur la source, car c’est là que se trouve la vraie protection.

À partir de combien d’écrans faut-il créer un menu ?

Il n’existe pas de seuil officiel : cinq ou six écrans sont un bon repère. Le vrai signal est l’encombrement, quand les boutons se multiplient ou que les utilisateurs ne trouvent plus une section. Un menu construit avec une galerie reste alors simple à faire évoluer.