Modéliser ses données dans Dataverse

Pourquoi aller au-delà de SharePoint ?

Depuis le début de notre parcours, nous avons choisi SharePoint comme point d’ancrage pour stocker les données de notre application de gestion des demandes internes. Ce choix était volontaire car SharePoint est familier à beaucoup d’organisations, facile à configurer, et il ne nécessite pas de licences supplémentaires. En effet, l’utilisation de Power Apps avec SharePoint est déjà incluse dans les licences O365 et n’entraîne donc pas de surcoût. Il offre une excellente porte d’entrée pour se lancer dans Power Apps sans devoir bouleverser l’écosystème existant.

Mais en avançant dans notre fil rouge, certaines limites commencent à apparaître. Vous avez sans doute déjà remarqué que SharePoint ne permet pas de gérer simplement des relations complexes entre données, que la gestion des volumes reste contrainte, et que les règles de sécurité s’appliquent parfois de manière trop large ou trop limitée. En bref, SharePoint est pratique pour démarrer, mais il montre vite ses limites dès que l’on cherche à construire une application métier robuste, destinée à durer. Il est possible de faire beaucoup de choses avec SharePoint et Power Apps, mais cela nécessitera...

Structuration des données : listes contre tables relationnelles

L’une des différences majeures entre SharePoint et Dataverse réside dans la structuration des données. Dans SharePoint, nous avons des listes, chacune pouvant contenir des colonnes de différents types. C’est suffisant pour gérer un besoin simple, mais dès que l’on veut représenter des relations plus complexes, comme les relations de plusieurs à plusieurs, les choses se compliquent. Les colonnes de type « recherche » existent, mais elles restent limitées et deviennent difficiles à manipuler dans Power Apps.

Par exemple, dans des galeries, si l’on veut récupérer un champ d’une table liée avec SharePoint, nous devons forcément utiliser des formules de type LookUp ou avoir récupéré le champ en question dans la table. Avec Dataverse, c’est plus simple.

Dataverse, au contraire, repose sur un modèle relationnel complet. Chaque table peut avoir des relations un-à-plusieurs ou plusieurs-à-plusieurs avec d’autres tables. Cela ouvre la porte à des scénarios beaucoup plus riches. Par exemple, dans notre application de gestion des demandes, nous pourrions imaginer créer une table « Commentaires » liée à la table « Demandes internes »....

Sécurité et gouvernance : deux philosophies opposées

La sécurité est un autre terrain où les deux approches divergent. Dans SharePoint, les droits sont hérités des sites, des bibliothèques et des listes. On peut bien sûr gérer des autorisations au niveau des éléments, mais cela reste lourd et difficile à administrer à grande échelle. De plus, SharePoint ne permet pas de gérer finement l’accès aux colonnes : un utilisateur qui a accès à un élément voit toutes ses colonnes.

Dataverse adopte une approche radicalement différente, plus proche d’une base de données professionnelle. La sécurité peut être définie au niveau des tables, des enregistrements, voire des colonnes. Il est possible, par exemple, d’autoriser un utilisateur à voir uniquement les demandes qu’il a lui-même créées, ou à accéder en lecture seule à certaines colonnes sensibles comme le budget. Cette granularité change complètement la donne pour les applications métier.

Attention : qui dit granularité accrue dit aussi besoin d’organisation. Mettre en place une bonne gouvernance dans Dataverse est indispensable, mais une fois ce cadre posé, vous bénéficiez d’une sécurité...

Intégration avec la Power Platform : un avantage décisif

Avec SharePoint, chaque fois que nous connectons notre application, nous devons nous assurer que les colonnes sont bien configurées, que la délégation est respectée et que les formules Power Fx ne sortent pas des limites de ce connecteur. Avec Dataverse, ces contraintes disparaissent presque complètement. Les filtres, tris et recherches sont exécutés côté serveur, ce qui garantit des performances stables, même avec de gros volumes de données. Les fonctions sont également plus délégables.

De plus, Dataverse intègre des fonctionnalités supplémentaires que SharePoint n’offre pas, comme les Business Rules (règles d’entreprise appliquées côté serveur), les Business Process Flows (processus guidés pour les utilisateurs), ou encore la possibilité d’ajouter du code côté serveur avec des plugins. Même si nous ne plongerons pas dans ces aspects avancés tout de suite, il est important de comprendre que Dataverse est conçu comme une plateforme d’applications professionnelles, et pas seulement comme un stockage de données.

À retenir

SharePoint est idéal pour démarrer rapidement une application, tester une idée ou répondre à un besoin ponctuel. Dataverse...

Restaurer un environnement : la résilience de Dataverse

Un aspect souvent sous-estimé, pourtant crucial dans les projets, est la résilience. Que se passe-t-il si une grave erreur survient en production ? Avec SharePoint, la restauration est compliquée. Certes, il existe des corbeilles, des versions d’éléments et même des sauvegardes de site, mais rien qui ne permette de restaurer un environnement applicatif complet, avec sa liste, ses données et son application Power Apps associée, à un instant donné.

Dataverse, en revanche, offre une véritable gestion des environnements. Chaque environnement peut être sauvegardé et restauré, ce qui permet de revenir à une version stable en cas de problème. Cette restauration n’affecte pas seulement les données : elle préserve aussi la structure des tables, les relations, les règles métier et les applications associées. Pour une organisation, c’est une garantie de continuité de service inestimable.

Conseil : lorsque vous développez des applications stratégiques pour votre entreprise, appuyez-vous sur Dataverse. En cas d’incident, vous serez heureux de pouvoir restaurer un environnement complet, plutôt que de courir après des morceaux de données éparpillées dans SharePoint.

Création d’une solution

Lorsque l’on travaille dans Dataverse, il est essentiel de comprendre la notion de solution. Une solution n’est pas seulement un dossier technique où l’on regroupe ses tables, ses applications et ses flux. C’est en réalité un contenant logique qui permet d’organiser, de transporter et de versionner les composants d’un projet Power Platform.

Sans solution, tout ce que vous créez (tables, colonnes, applications, règles métier, processus, etc.) est placé dans la solution par défaut. Cela peut sembler pratique au début, mais devient rapidement un cauchemar à maintenir. La solution par défaut est partagée par tous les makers de votre environnement, et mélanger plusieurs projets ou expérimentations dans ce même espace conduit à une perte de visibilité, à des erreurs et surtout à l’impossibilité de gérer correctement les cycles de vie (développement, test, production).

Créer une solution spécifique à votre projet est donc une meilleure pratique incontournable. Cela permet de travailler de manière cohérente et surtout d’anticiper la future mise en production. Cela vous permettra aussi de retrouver facilement les différents éléments présents dans votre projet : application, table, flux, variable d’environnement, etc.

Créer une première table

Dans cette section, nous allons créer notre toute première table Dataverse, qui constituera le cœur de notre application fil rouge. Cette table s’appellera Demande. Elle servira à stocker l’ensemble des demandes effectuées par les collaborateurs : incidents informatiques, besoins RH, requêtes logistiques, etc.

Imaginez-la comme une grande armoire numérique dans laquelle chaque demande correspond à un dossier. Chaque dossier contient des informations clés : le titre, la description, le service concerné, le demandeur, la date, le statut, et éventuellement des fichiers. Cette table sera la colonne vertébrale de notre application.

Une fenêtre latérale s’ouvre : c’est ici que vous allez définir les propriétés de base de votre table.

Ce nom sera utilisé dans toute la plateforme, y compris dans les applications, les flux et les vues. Choisissez-le soigneusement, car il représente la nature des données stockées.

Ajouter des colonnes

Notre table Demande est en place, mais pour l’instant, elle est vide. Elle ne contient qu’une colonne principale, le Titre de la demande.

Or, une table vide n’a que peu d’intérêt. Pour qu’elle devienne réellement utile, il faut lui ajouter des colonnes métiers, c’est-à-dire des champs qui vont permettre de stocker les informations spécifiques à chaque demande.

Ces colonnes sont essentielles : ce sont elles qui donneront de la richesse et de la structure à notre modèle de données. Chaque colonne que nous allons créer correspond à une information précise que nous souhaitons recueillir dans notre application fil rouge.

Pour bien comprendre, imaginez que chaque enregistrement dans la table est une fiche de demande. Pour l’instant, cette fiche ne contient qu’un titre. Nous allons maintenant y ajouter des sections à remplir : une description détaillée, le service concerné, le demandeur, la date, le statut, etc.

1. Colonne Description

Commençons par une colonne très simple, mais fondamentale : la Description.

 Dans l’interface Dataverse, ouvrez votre Solution, puis sélectionnez votre table.

 Cliquez sur + Nouveau, puis, dans le menu déroulant, choisissez Colonne.

Une fenêtre de configuration s’ouvre sur la droite.

• Nom de la colonne : Description

• Type de données : Plusieurs lignes de texte

• Longueur maximale : laissez la valeur par défaut, 2 000 caractères, ce qui est largement suffisant pour une première version.

Cette colonne servira aux utilisateurs à expliquer précisément leur demande. C’est ici qu’ils pourront décrire le problème rencontré ou le besoin exprimé, de manière libre et détaillée.

Prenons un exemple concret :

Titre de la demande : « Problème de connexion VPN »

Description : « Depuis ce matin, je n’arrive plus à me connecter au VPN de l’entreprise. Le message d’erreur indique une authentification impossible. J’ai déjà redémarré mon ordinateur et testé sur un autre réseau. »

Ce niveau de détail est essentiel pour que la personne...

Créer un formulaire principal

Une fois les colonnes et les vues bien structurées, l’étape suivante consiste à façonner l’interface de saisie et de consultation des données. Dans les applications Model-driven, cette interface repose sur un élément central : le formulaire.

Un formulaire dans Dataverse est une vue structurée d’un enregistrement. C’est à travers lui que les utilisateurs créent, modifient et consultent les données d’une table. Contrairement aux Canvas Apps, où chaque champ doit être ajouté et mis en forme manuellement, les formulaires Model-driven offrent une structure prête à l’emploi, très largement configurable en no-code.