Découvrir les Model-driven Apps

1. Canvas Apps : tout est à construire

Un Canvas App, c’est un peu comme partir d’une feuille blanche. Vous devez dessiner vos écrans, placer vos boutons, configurer vos galeries, définir vos formulaires. Rien n’est imposé.

Cela donne un sentiment de liberté incroyable : vous pouvez imaginer une application qui ressemble exactement à vos besoins, même avec un design très éloigné de ce que propose Microsoft.

Mais cette liberté a un coût. Chaque action doit être programmée...

1. Avec Canvas

2. Avec Model-driven

3. Quand utiliser l’un ou l’autre ?

La question du choix est centrale.

Dans une entreprise, il est fréquent de combiner les deux. On utilise une Model-drivenApp pour gérer les données et une Canvas...

1. Comprendre les briques d’une Model-driven App

Avant de créer notre première application, il est important de bien comprendre le vocabulaire.

Ces quatre concepts (zones, groupes, pages et paramètres) forment l’ossature de toute application model-driven....

1. Comprendre ce qu’est une vue

Dans une application model-driven, une vue est une fenêtre prête à l’emploi sur une table Dataverse. Elle affiche une liste d’enregistrements selon les colonnes choisies, un ordre de tri et, surtout, des filtres. Une vue est donc à la fois un modèle d’affichage et une requête. L’utilisateur n’a rien à construire : il ouvre la page, et la liste s’affiche avec les bons champs, les bons filtres et les bons tris.

Dans notre fil rouge, la table Demande contient toutes les demandes internes. Une vue Demandes en cours montrera uniquement les enregistrements dont le statut est En cours, avec, par exemple, les colonnes Titre, Service, Priorité, Date et Demandeur. Une autre vue Mes demandes filtrera sur Propriétaire = utilisateur courant. Vous voyez l’idée : chaque besoin d’analyse ou d’action peut devenir une vue dédiée, stable et partageable.

2. Les types de vues

Toutes les vues ne jouent pas le même rôle. Il existe trois grandes familles que vous croiserez au quotidien.

Les vues système sont créées dans les solutions, par les makers ou les administrateurs, et sont visibles par tous selon les rôles de sécurité. Ce sont celles que vous ajoutez à l’application dans le concepteur d’app. Elles structurent l’expérience de tous les utilisateurs.

Quelques vues système « spécialisées » méritent une mention :

1. Pourquoi les formulaires sont centraux

Dans une application model-driven, le formulaire est la porte d’entrée sur la donnée. C’est l’écran où l’on consulte, saisit et met à jour un enregistrement. Il se génère à partir de la table Dataverse, puis on le structure pour qu’il épouse le métier : on choisit les champs, on organise l’espace, on décide quand un champ est visible, obligatoire ou verrouillé.

Contrairement à une Canvas App, où tout est à construire en low-code - chaque bouton, chaque étiquette, chaque logique -, la structure de base existe déjà. On paramètre plutôt qu’on ne code. Résultat : un temps de mise en œuvre réduit, une UX cohérente et des formulaires naturellement responsives.

Dans notre fil rouge, ouvrir une Demande affiche un formulaire avec le Titre, la Description, le Service, le Demandeur, la Date de la demande, le Statut, la Priorité et le Commentaire du gestionnaire. À partir de ce socle, nous allons affiner, clarifier et guider l’utilisateur, sans écrire une ligne de JavaScript.

2. Les types de formulaires et quand les utiliser

Tous les formulaires ne servent pas le même objectif. Dataverse en propose plusieurs, que l’on combine selon les scénarios.

Le formulaire principal (Main) est l’écran complet. On y place les champs clés, des sections, des onglets, des sous-grilles, des graphiques, voire des composants PCF. C’est le plan de travail du gestionnaire : il y passe du temps, il a besoin de contexte, de listes liées, d’un historique.

Le formulaire de création rapide (Quick Create) ouvre un panneau latéral. On y saisit l’essentiel sans quitter son écran. Il est idéal pour une création ponctuelle : j’ajoute une demande au fil de l’eau depuis la page d’un service.

Le formulaire de consultation rapide (Quick View) n’est pas ouvert directement par l’utilisateur. Il injecte des informations d’une table liée dans le formulaire courant.

Exemple : afficher le Responsable et l’Email du Service sélectionné, sans dupliquer les colonnes. On gagne en lisibilité et on évite les recopies....

1. Comprendre l’intérêt des graphiques

Dans une application model-driven, les données sont structurées et centralisées dans Dataverse. Mais les afficher sous forme de listes ou de formulaires ne suffit pas toujours. Très vite, un gestionnaire, un responsable ou même un collaborateur veut comprendre les tendances : combien de demandes sont encore ouvertes ? Quel service est le plus sollicité ? Quelle est la répartition des statuts ?

Les graphiques répondent à ces questions en un clin d’œil. Ils transforment une liste d’enregistrements en représentation visuelle et complètent les vues et les formulaires. Là où la vue sert à lire et à filtrer, et le formulaire à détailler, le graphique aide à décider rapidement.

Contrairement à Power BI, destiné à l’analyse approfondie, les graphiques model-driven sont conçus pour être rapides à mettre en place et directement utilisables par les utilisateurs. Quelques clics suffisent, sans écrire de code.

2. Les types de graphiques disponibles

Par défaut, Dataverse propose plusieurs représentations simples, mais efficaces :