Application mobile du projet Synapse/React Native/(Flutter) :

L’objectif est de réaliser un projet informatique industriel aidant les décideurs d’une
chaîne de magasins dans la prise de décision. Ce projet se distingue en deux phases. Une
première partie « data » visant à créer, ingérer, stocker, analyser puis visualiser les
différentes données de la chaîne de magasins. La deuxième partie du projet consiste à créer
une application permettant le suivi des activités passées et futures de la chaîne de magasins
sur un terminal mobile. L’application devra communiquer avec l’infrastructure data mise en
place pour présenter ces informations.
Ce document se compose en trois parties. D’abord, une première partie qui consiste à
expliciter le fonctionnement global de l’application. La deuxième partie détaillera plus
spécifiquement l’infrastructure data et les différentes technologies utilisées. Enfin, la
troisième partie expliquera les différents éléments de l’application ainsi que l’intégration des
dashboards et l’authentification nécessaire dans cette application.

1. Explication globale de l’application mobile :

L’application mobile sert à fournir différentes informations auprès des décisionnaires
d’une chaîne de magasins. Il existe plusieurs catégories de décideurs. Il y a les décideurs
locaux (ils s’occupent d’un seul magasin), les décideurs régionaux (ils s’occupent de
l’ensemble des magasins d’un territoire) et les décideurs nationaux (ils s’occupent des
résultats de l’ensemble des magasins du pays). Les membres des catégories citées ci-dessus
auront accès à cette application mais ils n’auront pas accès aux mêmes informations. Voici
un tableau récapitulatif :
Utilisateurs Fonctionnalités
Prédictions
Dashboards
(Jour suivant)
Décisionnaire Local Locaux Locales
Décisionnaire Régional Locaux, régionaux Régionales ?
Décisionnaire National Locaux, Régionaux, National Nationales ?

Les dashboards sont des indicateurs utiles à l’entreprise pour comprendre les
évènements passés. Un dashboard local est par exemple un graphique des ventes ou
l’affluence quotidienne dans un magasin précis. Un dashboard régional peut être la quantité
de produits vendus sur l’ensemble des magasins d’un territoire. Un dashboard national
recense l’activité du groupe au niveau national (le nombre de ventes en France en 2020). Ces
tableaux de bord concerneront les clients, les ventes et les produits par zones géographiques
sur une période de temps définie.
Les prédictions sont utiles pour prévoir l’activité de l’entreprise dans le futur.
L’application indiquera la prédiction des ventes pour chaque magasin ainsi que la prédiction
du nombre de clients pour la journée (ou les journées) à venir.
 2. Partie Data :

a. Schéma de l’infrastructure data

Voici le schéma de l’architecture du projet :

Explications :
Une fois que les données sont simulées, elles sont envoyées vers le service Azure Synapse.
Elles sont potentiellement transformées puis stockées dans un Azure Data Lake. Les données
sont alors prêtes. Elles sont soit ingérées dans un pool SQL dédié (Azure DataWarehouse)
soit une virtualisation d’un datawarehouse est réalisée (SQL Pool Serverless). Voir la partie
réflexion sur le choix des technologies. Lorsque le datawarehouse est prêt, les services
d’analytiques travaillent avec les données. On a Azure Machine Learning pour les modèles
prédictifs des ventes et Power BI pour la réalisation des rapports et des tableaux de bord.
Ces services sont intégrés à Azure Synapse. Enfin, l’application mobile récupère les résultats
générés par les services d’analytiques pour les rendre disponibles dans l’application mobile.
 b. Schéma du datawarehouse
La modélisation du datawarehouse est primordiale car elle va permettre d’élaborer les
tableaux de bord souhaités à partir de requêtes.
Voici le schéma (type flocon) :

Explications :
On a quatre dimensions différentes. On a d’abord la dimension « temps » permettant
de recenser différents niveaux de granularité. On pourra ainsi avoir des informations
horaires, journalières, mensuelles ou annuelles. On a aussi la dimension
« géographie » permettant d’avoir les informations pour l’ensemble de la chaîne de
magasins. On pourra avoir des informations pour un magasin en particulier, un
ensemble de magasins d’une région ou l’ensemble des magasins au niveau national.
La dimension « produit » possède la marque, le nom et la catégorie du produit. Cela
permettra d’analyser les ventes d’un produit spécifique ou d’une catégorie de
produits. Enfin, la dimension « client » inclut l’âge, le sexe, la catégorie socio-
professionnelle et le code postal. Ces informations permettront d’avoir des
statistiques pour les clients au niveau global (pas un client en particulier). Ces
dimensions sont rattachées à la table des faits « vente». C’est-à-dire que pour un
client, à un instant donné, dans un magasin précis et pour un produit acheté, on aura
la quantité achetée et le prix correspondant. A partir de requêtes, nous pourrons
alors avoir des informations sur les clients d’une région ou les ventes journalières
d’un produit, … Certaines variables (date des vacances, le jour férié, la météo, …)
seront utilisés pour l’algorithme de Machine Learning.
Une évolution future serait d’ajouter les stocks. Il faudrait ajouter pour cela une table
des faits des stocks. Le schéma ci-dessus serait modifié. La nouvelle table des faits
serait rattachée à des dimensions comme le temps, le magasin et le produit.

c. Réflexion sur le choix des technologies

Lors de l’implémentation de l’architecture data, deux choix sont possibles dans Azure
Synapse. Plus précisément, c’est au niveau du datawarehouse que ce choix
intervient. Les données sont transformées et ingérées dans le data lake. Elles sont
ainsi prêtes pour une ingestion dans le data warehouse. Nous utilisons soit un SQL
pool dédié en tant que datawarehouse, soit nous utilisons un pool SQL serverless.

SQL pool dédié :

 Prix : DW100c (configuration minimale) : 1.27 € / h

 Persistance des données dans un datawarehouse
 Inscription des modèles de Machine Learning (format ONNX) dans le
datawarehouse (Fonction PREDICT)
 Intégration avec PowerBI
 Cas d’utilisation : Entrepôt de données dont on connait la taille des
requêtes (pour les grosses requêtes). On peut donc le dimensionner
précisément et connaître le coût.

SQL pool serverless :

 Serverless donc on paye que ce qu’on utilise donc un coût global

sûrement moindre
 Pas besoin de gérer les ressources
 Non persistance des données (création de vue / de tables externes
depuis le data lake), virtualisation d’un entrepôt de données
 Impossibilité d’inscrire des modèles de Machine Learning en ONNX
(Passage par un conteneur AKS avec un point de terminaison ?)
 Intégration de PowerBI
 Cas d’utilisation : Exploration, Transformation des données, Entrepôt
de données
 Les deux cas sont envisageables pour ce projet étant donné que l’on peut stopper le
datawarehouse (le pool SQL dédié) quand on ne n’utilise pas.

L’objectif de la partie data est d’automatiser l’ensemble du processus. Dès que l’on
ajoute un fichier, il est automatiquement ajouté dans le datawarehouse puis les
prédictions (si dans un pool SQL dédié) sont effectuées et les tableaux de bord mis à
jour.

3. Partie Application mobile :

L’application mobile doit intégrer trois éléments. D’abord, il faut une fonctionnalité
d’authentification. Nous utiliserons Azure Active Directory pour cela. Ensuite, il faut
intégrer les différents tableaux de bord de Power BI générés dans la partie précédente.
Enfin, il faut aussi intégrer les résultats du scoring des modèles de machine learning dans
l’application. L’application sera d’abord développée sous React Native.
a. Intégration d’Azure Active Directory
L’objectif est d’intégrer dans l’application une authentification à l’aide d’Azure Active
Directory. Celle-ci permettrait d’accéder aux informations suivant le compte auquel nous
sommes connectés. Ainsi, une entreprise peut avoir plusieurs directeurs et donc
plusieurs comptes permettant d’accéder aux données suivant leur niveau d’habilitation.
L’inconvénient est qu’il y a une redirection vers Microsoft pour se connecter. Cette
redirection rend l’application moins immersive. Malheureusement, éviter une redirection
semble impossible. Log in to Azure AD B2C without redirecting to b2clogin Microsoft page -
Microsoft Q&A. Après avoir inscrit l’application dans Azure AD, on peut utiliser soit la
librairie ajax soit la librairie msal. Ces librairies sont disponibles en javascript. Les
documentations utilisent l’une des deux librairies pour effectuer l’authentification Azure
AD dans leur application react.
Voici des liens utiles pour l’intégration :
Lien 1 : Authentification Azure AD avec ReactJS (anceret-matthieu.fr)
Lien 2 : How to Integrate Azure AD into Your Web Application - One Six Solutions
Lien 3 : React JS Application with Azure AD B2C (c-sharpcorner.com)*
Lien 4 : Tutoriel : Ajouter un bouton de connexion Microsoft à une application
monopage React | Microsoft Docs
Lien 5 : Tutorial Add Azure AD login to a React app - YouTube
 b. Intégration des Dashboards/Reports BI
Le but est d’importer les reports BI dans une application react. Il faut utiliser pour
cela la nouvelle libraire ‘powerbi-client-react’ pour utiliser le composant
‘PowerBIEmbed’. On configure le document à importer (report, dashboard, tile, …). On
précise l’Id, l’URL, le jeton d’accès et le type de jeton dans cette configuration. Ensuite,
on appelle une fonction du package qui va importer (à partir de la configuration) le
rapport dans l’application. Le rapport est maintenant dans un conteneur, on va pouvoir
appliquer du code css sur ce conteneur pour le placer dans la page. Le rapport est
interactif et contient le visuel créé sur power BI , ce n’est pas une simple image du
graphique. Un iFrame interactif est généré par la librairie. Cette méthode semble être la
plus pertinente.
Voici des liens utiles pour l’intégration (surtout le lien 1 et 3):
Lien 1 : https://microsoft.github.io/PowerBI-JavaScript/demo/v2-demo/index.html#
Lien 2 : Embedding Microsoft Power BI in a React application - YouTube
Lien 3 : How to embed a Power BI component in a React app | Microsoft Docs
Lien 4 : microsoft/PowerBI-JavaScript: JavaScript library for embedding Power BI into
your apps. Check out the docs website and wiki for more information. (github.com)
Lien 5 : INSANE AMAZING updates for the Power BI Embedded Playground (2021) -
YouTube
Lien 6 : Report/dashboard rendering (alternative to iframe) - Microsoft Power BI
Community
Lien 7 : How To Embed Microsoft Power BI Charts Into Your React Application | by
Akshay Ram Vignesh | Medium
Lien 8 : akshay5995/powerbi-report-component: Easily embed your Microsoft PowerBI Report,
Dashbord or Tile in your React App (github.com)

Note : Des tests depuis une application vide seront effectués pour pouvoir
découvrir, essayer et mieux comprendre les différentes manières d’intégrer Azure
Active Directory et Power BI dans une application react.

c. Intégration des prédictions des algorithmes de ML

Avec un pool SQL dédié : Requête vers une table SQL qui stocke les résultats ?.
Avec un pool SQL severless : Récupération des données puis requêtage du modèle
dans un conteneur AKS . Possibilité de passer par une Azure Function pour récupérer
les données, appeler le modèle et envoyer les résultats à l’application ?
 d. Ecrans de l’application
Voici le lien d’accès aux différents écrans de l’application via le Figma :
Lien Figma
Explications :
Ecran d’authentification :

Lorsque nous ouvrons l’application, nous arrivons directement sur la partie

Authentification de l’application. Il suffit ensuite de cliquer sur le bouton Azure Active
Directory pour accéder à l’application. Il y aura alors une redirection.
Ecran d’accueil / Prédiction :
Nous arrivons ensuite sur la prédiction du jour suivant notre niveau maximal
d’habilitation (Voir plus bas). Nous pouvons ouvrir le menu latéral lorsque l’on appuie
sur le bouton menu, en haut à gauche. Pour les dashboards, nous avons également
accès par défaut aux dashboards du niveau maximal d’habilitation.

Un menu déroulant apparait et nous pouvons

cliquer sur le bouton « choose Business » pour choisir le niveau hiérarchique des
données que l’on souhaite voir (National, Régional, Local). Le décisionnaire National a
accès à tous les niveaux hiérarchiques. Il peut donc décider de voir des résultats au
niveau national, régional et local. Un décisionnaire régional n’a accès qu’aux niveaux
régional et local. Un décisionnaire local n’a pas ce bouton dans l’application puisqu’il
n’a accès qu’aux résultats de son propre magasin.
Une fois le niveau d’habilité sélectionné (s’ils ont le choix), le décisionnaire aura accès
aux dashboards comme les ventes, les clients et des produits sur différentes timelines
(Heures, Jours, Mois, Années). Pour cela, il suffira de cliquer sur le bouton menu puis
de cliquer sur le type de dashboards souhaités.

Enfin, l’utilisateur aura accès aux données de son compte à l’aide de l’onglet
« Account ». Il pourra alors quitter l’application.