Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
Université de Tunis El Manar
In...
J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
Encadrant professionnel, M. Malek ...
Dédicaces
Je dédie ce modeste travail à :
Mes chers parents, Je mets entre vos mains le fruit de votre amour, de votre ten...
Remerciements
Au terme de mon projet de fin d’études, j’aimerais exprimer mes sentiments de
gratitude envers toutes les per...
Table des matières
Introduction générale 1
1 Contexte général 3
1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . ...
4.2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Le développeme...
6.3.3 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3.4 Diagramme de séquence...
Table des figures
1.1 Logo de SimplyCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Mo...
Table des figures
6.4 Backlog du sprint 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.5 ...
7.8 Diagramme de séquence relatif au cas d’utilisation " Créer une structure " . . . . . . . 76
7.9 Diagramme de séquence ...
Liste des tableaux
2.1 Comparaison entre les différents logiciels de Web Analytique . . . . . . . . . . . . . . . 15
3.1 Ac...
Liste des abréviations
— CE = Comité d’Entreprise
— CRUD = Create Read Update Delete
— GLSI = Génie Logiciel et Systèmes d...
Introduction générale
En faveur de l’amélioration continue de la performance des entreprises, les propriétaires d’entrepri...
Introduction générale
et le septième chapitre présentent les « releases » de notre projet, dans lesquelles nous retournons...
Chapitre 1
Contexte général
Plan
1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4...
Chapitre 1. Contexte général
Introduction
Ce chapitre est consacré à la présentation du cadre général de notre projet. Nou...
Chapitre 1. Contexte général
1.1.2 Devstriker
Devstriker est la filiale off-shore de SimplyCE en Tunisie, créée en novembre ...
Chapitre 1. Contexte général
Figure 1.2: Modules de SimplyCE
1.3 Problématique
La plateforme SimplyCE ayant plusieurs modu...
Chapitre 1. Contexte général
— Y a-t-il des maillons faibles dans les entonnoirs ?
— Quels produits déclenchent le plus de...
Chapitre 1. Contexte général
— Une meilleure qualité de communication : Le client a la possibilité de clarifier ou modifier ...
Chapitre 1. Contexte général
Figure 1.3: Les étapes de la méthodologie SCRUM
[3]
Conclusion
Ce chapitre est une partie int...
Chapitre 2
ÉTUDE PRÉALABLE
Plan
1 Définition quelque concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 ...
Chapitre 2. ÉTUDE PRÉALABLE
Introduction
Dans ce deuxième chapitre nous faisons l’objet d’une étude préliminaire à travers...
Chapitre 2. ÉTUDE PRÉALABLE
de ne pas avoir à comprendre le processus de décision. Plus besoin de savoir quels sont les fa...
Chapitre 2. ÉTUDE PRÉALABLE
informations clients jusqu’à l’implémentation de promotions ou d’offres ciblées. Cette conjugai...
Chapitre 2. ÉTUDE PRÉALABLE
Figure 2.1: L’évolution du Digital Analytics depuis 1993 jusqu’aujourd’hui [4]
2.3.2 Logiciels...
Chapitre 2. ÉTUDE PRÉALABLE
Kiss Metrics Piwik Moz pro
Fonctionnalités
suivre les
comportements
des visiteurs sur un
site ...
Chapitre 3
Initiation au projet
Plan
1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....
Chapitre 3. Initiation au projet
Introduction
L’analyse des besoins est une étape primordiale dans la réalisation de tout ...
Chapitre 3. Initiation au projet
3.1.2 Recueil des besoins fonctionnels (Product Backlog)
Les principales fonctionnalités ...
Chapitre 3. Initiation au projet
ID User Story Sprint
1 En tant qu’analyste, je veux collecter de données. 1
5 En tant qu’...
Chapitre 3. Initiation au projet
La sécurité :
Notre système devrait être sécurisé : au moment de l’authentification des ut...
Chapitre 3. Initiation au projet
Figure 3.2: Diagramme de cas d’utilisation global
3.1.5 Prototypage des interfaces
Le pro...
Chapitre 3. Initiation au projet
conforme à ces maquettes.
Figure 3.3: Exemples de maquettes réalisées
3.2 Pilotage du pro...
Chapitre 3. Initiation au projet
Acteur Rôle Mission
Malek
TAZEROUT
Product
Owner
Définition des besoins
Définition de l’ord...
Chapitre 4
Lancement du projet
Plan
1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...
Chapitre 4. Lancement du projet
Introduction
Au cours de ce chapitre, nous définissons notre architecture globale du projet...
Chapitre 4. Lancement du projet
4.2 Choix technologiques
Cette section sera consacrée à justifier nos choix technologiques ...
Chapitre 4. Lancement du projet
Figure 4.3: Comparaison entre PHP et NodeJs en terme de temps de réponse [7]
4.2.1.2 La ba...
Chapitre 4. Lancement du projet
Il existe de multiples bases de données de type NOSQL, dans notre projet nous avons utilis...
Chapitre 4. Lancement du projet
Les bonnes pratiques pour la conception d’une APIS REST
La création des APIS REST constitu...
Chapitre 4. Lancement du projet
C’est un framework hautement évolutif pour créer des APIs et les relier à des sources de d...
Chapitre 4. Lancement du projet
Figure 4.5: Courbe de performance React VS Angular VS AngularJS VS Blaze
[18]
intéressons ...
Chapitre 4. Lancement du projet
4.2.3.2 Jasmine
Jasmine est un framework de test JavaScript exécuté sur Angular 2+. Nous l...
Chapitre 4. Lancement du projet
Figure 4.6: ArchitectureMVVM
[23]
La figure 4.6 résume donc l’architecture de design patter...
Chapitre 4. Lancement du projet
4.3.2.1 Enterprise Architect
Enterprise Architect est un logiciel spécialisé dans la modél...
Chapitre 4. Lancement du projet
4.3.2.4 MongoDB Compass
MongoDB Compass est conçu pour permettre aux utilisateurs d’analys...
Chapitre 5
Release 1
Plan
1 Présentation des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2 Spri...
Chapitre 5. Release 1
Introduction
Dans ce chapitre nous allons concentrer sur la première « Release » du projet. Nous all...
Chapitre 5. Release 1
Figure 5.1: Backlog du sprint 1
5.2.2 Proof of Concept G.A
Pour s’assurer de la bonne compréhension ...
Chapitre 5. Release 1
5.3.1 Tracking Simply CE
Le tracking consiste à organiser la collecte et le stockage de données de n...
Chapitre 5. Release 1
5.3.3 Backlog sprint 2
Nous introduisons à travers la figure 5.4 le backlog du sprint2.
Figure 5.4: B...
Chapitre 5. Release 1
Nous prenons l’exemple d’une Event Tracking :
• A cliqué sur le lien Télécharger »
• A consulté une ...
Chapitre 5. Release 1
Figure 5.6: Bouts de code injectés
• Comportement d’achat sur la plate-forme Simply-Club
Nous nous p...
Chapitre 5. Release 1
Figure 5.7: Bouts de code injectés
Nous illustrons par la figure 8.4 quelques bouts de code que nous ...
Chapitre 5. Release 1
Objectifs fonctionnels :
— Étude détaillée des indicateurs clés de performance.
— Choix KPIs.
— Choi...
Chapitre 5. Release 1
Figure 5.10: schéma de construction les indicateurs clés de performance
Le schéma 5.11 ci-dessus rés...
Chapitre 5. Release 1
utilisé à la phase suivante"étude technique de la collecte". Nous entamons dans ce qui suit la deuxi...
Chapitre 6
Release 2
Plan
1 Présentation des sprints du release 2 . . . . . . . . . . . . . . . . . . . . . . . 48
2 Spéci...
Chapitre 6. Release 2
Introduction
Dans ce chapitre, nous allons concentrer sur la deuxième release du projet. Nous allons...
Chapitre 6. Release 2
Figure 6.1: Backlog du sprint 5
La figure 6.2 présente le backlog du sprint 6.
Figure 6.2: Backlog du...
Chapitre 6. Release 2
Figure 6.5: Diagramme de cas d’utilisation de Release 2
6.2.2 Diagrammes de séquence système
Pour mi...
Chapitre 6. Release 2
6.2.2.1 Authentification d’un utilisateur
Figure 6.6: Diagramme de séquence système « S’authentifier »...
Chapitre 6. Release 2
6.2.2.2 Création d’un compte utilisateur
Figure 6.7: Diagramme de séquence système « Créer un compte...
Chapitre 6. Release 2
Titre Réinitialisation du mot de passe
Acteur Utilisateur non authentifié.
Résumé
Ce cas d’utilisatio...
Chapitre 6. Release 2
Titre Gérer des sources
Acteur L’analyste.
Résumé
Ce cas d’utilisation permet à l’analyste de récupé...
Chapitre 6. Release 2
Figure 6.8: Diagramme d’activité de release 2
6.3.2 Diagramme de paquetage
Le diagramme de paquetage...
Chapitre 6. Release 2
Pour release 2, nous n’avons besoin que des modèles illustrés par la figure 6.10.
Figure 6.10: Diagra...
Chapitre 6. Release 2
Figure 6.11: Diagramme de séquence d’authentification
Nous illustrons par la figure 6.12 comment se dé...
Chapitre 6. Release 2
Figure 6.12: Diagramme de séquence récupérer les sources
6.4 Réalisation
Durant la réalisation de ch...
Chapitre 6. Release 2
un second temps, la partie de la REST Api correspondante qui sera consommée par la suite par le
fron...
Chapitre 6. Release 2
6.4.2.1 Connexion
A la première utilisation de l’application passe obligatoirement par l’interface d...
Chapitre 6. Release 2
Figure 6.16: Interfaces d’inscription
La figure 6.17 illustre un email contenant un lien de vérificati...
Chapitre 6. Release 2
Figure 6.18: Interfaces de réinitialisation du mot de passe
La figure 6.19 illustre un email contenan...
Chapitre 6. Release 2
6.4.2.5 Accueil
Un utilisateur connecté peut accéder l’interface d’accueil. La figure 6.21 résume les...
Chapitre 6. Release 2
Figure 6.23: Interfaces de choisir type de source récupérée
6.4.2.7 Récupération de données
L’analys...
Chapitre 6. Release 2
Figure 6.25: Interfaces de récupération à partir API REST SimplyCE
6.5 Test
L’une des caractéristiqu...
Chapitre 6. Release 2
Figure 6.27: Release 2 : Rapport de test d’intégration : Modèle utilisateur
6.5.2 Test unitaire côté...
Chapitre 6. Release 2
Figure 6.29: Release 2 test fonctionnel : authentification réussi
Conclusion
Dans ce deuxième release...
Chapitre 7
Release 3
Plan
1 Présentation des sprints du release 3 . . . . . . . . . . . . . . . . . . . . . . 69
2 Spécific...
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Prochain SlideShare
Chargement dans…5
×

5

Partager

Télécharger pour lire hors ligne

Rapport pfe isi_Big data Analytique

Télécharger pour lire hors ligne

Rapport PFE ISI

Livres associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir

Rapport pfe isi_Big data Analytique

  1. 1. République Tunisienne Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Université de Tunis El Manar Institut Supérieur d’Informatique d’El Manar Rapport de Projet de Fin d’Études Présenté en vue de l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques Spécialité : Génie Logiciel et Systèmes d’Information Par Yosra ADDALI Mise en place d’une solution de tracking et monitoring d’une plateforme SaaS Encadrant professionnel : Encadrant académique : M.Malek TAZEROUT et Mlle Mayssa MESSAOUDI Madame Hela LIMAM Ingénieur R&D Maître Assistante Réalisé au sein de Devsricker Année Universitaire :2016/2017
  2. 2. J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance. Encadrant professionnel, M. Malek TAZEROUT Signature et cachet J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance. Encadrant académique, Madame Hela LIMAM Signature i
  3. 3. Dédicaces Je dédie ce modeste travail à : Mes chers parents, Je mets entre vos mains le fruit de votre amour, de votre tendresse, de vos sacrifices, et vos encouragements, tout au long de mes études. Mon cher père , Amor, aucune dédicace ne peut exprimer l’amour, l’estime et le respect que j’ai toujours pour vous. Vous m’avez donné la vie et vous étiez toujours là pour m’encourager, me motiver, me pousser à devenir ce que je suis aujourd’hui. Veuillez trouvez dans ce modeste travail la conclusion de vos efforts, mon amour et ma gratitude. Puisse ce jour vous apporter toute la joie et la fierté que vous avez tant attendu. Puisse dieu vous accorder la bonne santé et vous garde comme toujours à nos côtés. Ma chère mère, Najet, toutes les expressions ne peuvent exprimer mes sentiments d’amour et de respect vers vous. Vous êtes pour moi la meilleure des mères, qui a consacré sa vie aux bonheur et réussite de ses enfants. Vous m’avez donné la vie et vous avez guidé tous mes pas, vous êtes toujours à mes côtés pour me motiver, me pousser à devenir ce que je suis aujourd’hui. En témoignage de vos fatigues, vos efforts et vos sacrifices, je vous dédie ce travail pour avouer ma reconnaissance et ma profonde estime. Espérant être votre source de bonheur et de fierté pour ce jour attendu. Puisse Dieu vous accorder santé et longue vie. À ma soeur Kaouther et mon frère Adem, je ne peux exprimer à travers ces lignes tous mes sentiments d’amour envers vous. Que l’amour et la fraternité nous unissent à jamais. À tous mes amis qui ont toujours fait confiance en moi et en mes capacités à faire mieux. Je ne pourrais être que reconnaissante envers tout ce que vous avez fait pour moi. Yosra ADDALI ii
  4. 4. Remerciements Au terme de mon projet de fin d’études, j’aimerais exprimer mes sentiments de gratitude envers toutes les personnes qui par leur présence, leur soutien, leur disponibilité et leurs conseils, j’ai pu accomplir ce projet. Je tiens tout d’abord à remercier Monsieur Malek TAZEROUT pour avoir accepté de m’accueillir au sein de son organisme et m’assurer toutes les conditions de travail appropriées. J’adresse aussi mes profonds et sincères remerciements à mon enseigante et encadrante Madame Hela LIMEM qui a accepté de diriger ce travail, pour ses conseils précieux, son encouragement continu, sa haute disponibilité, sa patience énorme et le temps précieux qu’elle m’a réservé tout au long de la réalisation de mon projet. Je tiens à remercier et témoigner toute ma reconnaissance à mes encadrants professionnels au sein de l’entreprise DevStriker, Madame Mayssa MESSAOUDI pour m’avoir bien encadrée et orientée durant mon PFE et pour l’aide précieuse qu’elle m’a accordée, ainsi que Monsieur Emmanuel ZEPPA pour ses conseils et sa disponibilité tout au long de cette période. Je tiens à remercier également toute l’équipe de DevStriker pour leur chaleureux accueil, leur collaboration, leur aide et leur soutien continu. Finalement, je remercie mes proches, mes chers amis, toute ma famille et mes chers parents pour leur inlassable soutien et pour la confiance qu’ils m’ont accordés. iii
  5. 5. Table des matières Introduction générale 1 1 Contexte général 3 1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1 SimplyCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.2 Devstriker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Étude de l’existant : Plateforme SimplyCE . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 ÉTUDE PRÉALABLE 10 2.1 Définition quelque concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Big Data et marketing : les opportunités pour l’entreprise . . . . . . . . . . . . . . . . 12 2.2.1 Un marketing prédictif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2 Les bénéfices du Big data sur le marketing . . . . . . . . . . . . . . . . . . . . . 12 2.3 Les logiciels de Web Analytique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 Histoire et évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2 Logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3 Initiation au projet 16 3.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.2 Recueil des besoins fonctionnels (Product Backlog) . . . . . . . . . . . . . . . . 18 3.1.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.4 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.5 Prototypage des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.1 Les outils Scrum : VersionOne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.2 Équipes et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4 Lancement du projet 24 4.1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 iv
  6. 6. 4.2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.1 Le développement web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.2 Le développement front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.3 Test et qualité de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2.4 Les patrons de conception (Design Patterns) . . . . . . . . . . . . . . . . . . . . 32 4.3 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5 Release 1 36 5.1 Présentation des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2 Sprint 1 : Proof of Concept G.A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.2 Proof of Concept G.A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.3 Sprint 2 : Méthode de collecte de données . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.1 Tracking Simply CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.2 Les différentes API Google Analytics . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.3 Backlog sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3.4 Planifier la collecte et l’analyse de données . . . . . . . . . . . . . . . . . . . . . 40 5.3.5 Les informations pertinentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.4 Sprints 3 et 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.4.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.4.2 Le planning du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4.3 Les indicateurs clés de performance . . . . . . . . . . . . . . . . . . . . . . . . . 44 6 Release 2 47 6.1 Présentation des sprints du release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.1.1 Objectifs des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.1.2 Le planning des sprints du release 2 . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2.2 Diagrammes de séquence système . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.3.1 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.3.2 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 v
  7. 7. 6.3.3 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.3.4 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.4.1 Coté backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.4.2 Coté frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.5.1 Test d’intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.5.2 Test unitaire côté front . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.5.3 Test fonctionnel côté front . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7 Release 3 68 7.1 Présentation des sprints du release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.1.1 Objectifs des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.1.2 Le planning des sprints du release 3 . . . . . . . . . . . . . . . . . . . . . . . . 69 7.2 Spécification fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.2.1 Diagrammes de séquence système . . . . . . . . . . . . . . . . . . . . . . . . . . 72 7.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.3.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.3.2 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.3.3 diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.4.1 côté backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.4.2 Côté frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.4.3 Impact du modèle d’apprentissage sur la mesure du parcours utilisateurs . . . . 86 7.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.5.1 Test d’unitaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.5.2 Test intégration côté Front . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 7.6 Évaluation des besoins non-fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Conclusion générale 91 Bibliographie 92 Annexes 94 Annexe 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 vi
  8. 8. Table des figures 1.1 Logo de SimplyCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Modules de SimplyCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Les étapes de la méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 L’évolution du Digital Analytics depuis 1993 jusqu’aujourd’hui [4] . . . . . . . . . . . . 14 3.1 Hiérarchie des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Exemples de maquettes réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2 Modèle d’exécution de NodeJs [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3 Comparaison entre PHP et NodeJs en terme de temps de réponse [7] . . . . . . . . . . 27 4.4 Comparaison en termes de scalabilité entre les bases de données relationnelles et non relationnelles [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.5 Courbe de performance React VS Angular VS AngularJS VS Blaze . . . . . . . . . . . 31 4.6 ArchitectureMVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2 prototype GA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.3 APIs GA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.4 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.5 Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.6 Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.7 Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.8 Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.9 Backlog des sprints 3 et 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.10 schéma de construction les indicateurs clés de performance . . . . . . . . . . . . . . . . 45 5.11 schéma les indicateurs clés de performance en l’entreprise simply CE . . . . . . . . . . 45 6.1 Backlog du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2 Backlog du sprint 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.3 Backlog du sprint 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 vii
  9. 9. Table des figures 6.4 Backlog du sprint 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.5 Diagramme de cas d’utilisation de Release 2 . . . . . . . . . . . . . . . . . . . . . . . 50 6.6 Diagramme de séquence système « S’authentifier » . . . . . . . . . . . . . . . . . . . . 51 6.7 Diagramme de séquence système « Créer un compte utilisateur » . . . . . . . . . . . . 52 6.8 Diagramme d’activité de release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.9 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.10 Diagramme de classe de release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.11 Diagramme de séquence d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.12 Diagramme de séquence récupérer les sources . . . . . . . . . . . . . . . . . . . . . . . 58 6.13 Exemple de permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.14 Exemple d’API réalisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.15 Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.16 Interfaces d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.17 vérification de l’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.18 Interfaces de réinitialisation du mot de passe . . . . . . . . . . . . . . . . . . . . . . . . 62 6.19 reset du mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.20 Interfaces de consultation et modification du profil . . . . . . . . . . . . . . . . . . . . 62 6.21 Interfaces d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.22 Interfaces de consultation des sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.23 Interfaces de choisir type de source récupérée . . . . . . . . . . . . . . . . . . . . . . . 64 6.24 Interfaces de récupération a partir google analytique . . . . . . . . . . . . . . . . . . . 64 6.25 Interfaces de récupération à partir API REST SimplyCE . . . . . . . . . . . . . . . . . 65 6.26 Rapport de quelques tests d’intégration du deuxième Release . . . . . . . . . . . . . . 65 6.27 Release 2 : Rapport de test d’intégration : Modèle utilisateur . . . . . . . . . . . . . . 66 6.28 Release 2 : Rapport de quelques tests unitaires . . . . . . . . . . . . . . . . . . . . . . 66 6.29 Release 2 test fonctionnel : authentification réussi . . . . . . . . . . . . . . . . . . . . 67 7.1 Backlog du sprint 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.2 Backlog du sprint 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.3 Backlog du sprint 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.4 Backlog du sprint 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.5 Diagramme de cas d’utilisation relatif aux décideurs . . . . . . . . . . . . . . . . . . . 71 7.6 Diagramme de cas d’utilisation relatif aux analystes . . . . . . . . . . . . . . . . . . . 72 7.7 Diagramme de classe pour troisième release . . . . . . . . . . . . . . . . . . . . . . . . 75 viii
  10. 10. 7.8 Diagramme de séquence relatif au cas d’utilisation " Créer une structure " . . . . . . . 76 7.9 Diagramme de séquence relatif au cas d’utilisation " Consulter les statistiques " . . . . 77 7.10 Diagramme de séquence relatif au cas d’utilisation " créer un tableau de bord personnalisé " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.11 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.12 APIs de gestion des tableaux de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.13 Interface de consultation des structures . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.14 Interface d’ajouter une structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.15 Interface l’agrégation des sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.16 Interface tableau de bord de l’agrégation des sources . . . . . . . . . . . . . . . . . . . 81 7.17 Interface de consultation des tableaux de bord . . . . . . . . . . . . . . . . . . . . . . . 82 7.18 Interface d’analyse du parcours d’utilisateurs . . . . . . . . . . . . . . . . . . . . . . . 83 7.19 Interface d’analyse performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 7.20 Interface d’analyse e-commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 7.21 Interface de création tableau du bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 7.22 Interface de première étape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7.23 Interface de deuxième étape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7.24 Interface de troisième étape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 7.25 Interface l’étape finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 7.26 Interface l’étape finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.27 Classification de navigation des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . 87 7.28 Release 3 : Rapport de test d’unitaire : Modèle dadhboard . . . . . . . . . . . . . . . 88 7.29 Release 3 : Rapport de test d’unitaire : Modèle structure . . . . . . . . . . . . . . . . 89 7.30 Release 3 : Test intégration coté front . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 8.1 Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.2 Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.3 Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.4 Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 8.5 Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 ix
  11. 11. Liste des tableaux 2.1 Comparaison entre les différents logiciels de Web Analytique . . . . . . . . . . . . . . . 15 3.1 Acteurs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 x
  12. 12. Liste des abréviations — CE = Comité d’Entreprise — CRUD = Create Read Update Delete — GLSI = Génie Logiciel et Systèmes d’Information — KPI = Key Performance Indicator — SaaS = Software-as-a-Service — UML = UnifiedModeling Language xi
  13. 13. Introduction générale En faveur de l’amélioration continue de la performance des entreprises, les propriétaires d’entreprises, les parties prenantes (actionneurs) et les décideurs se trouvent dans la nécessité d’examiner régulièrement la situation globale de l’activité et du processus métier (Business). En visualisant l’ensemble de données collectées au sein d’une entreprise, il devient possible de mettre en évidence les principales questions, les risques et les tendances pour identifier de nouvelles opportunités dans l’industrie en question. Les données dont nous parlons sont en effet créées par différentes sources, telles que les individus, les dispositifs et les applications au sein de l’organisation ; et elles ne cessent de croître de jour en jour. Cherchant à stimuler et à améliorer leur activité, les organisations se servent le plus de telles données pour constituer leurs propres indicateurs de performance. Toutefois, les données obtenues n’offrent généralement pas de précieux aperçus à leurs lecteurs car elles souffrent de lacunes et d’un manque de pertinence, ce qui nous empêche d’analyser et d’identifier les problèmes radicaux en fouillant inutilement dans des documents et des rapports exhaustifs. Sachant que, la capacité de suivre, de collecter, de décoder et d’agir sur de telles données traitées en temps réel est devenue une tâche extrêmement dure et délicate en même temps. Parmi les solutions finales les plus couramment utilisées, nous distinguons la visualisation de données telles que la création de tableaux de bord. Ceux-ci contiennent généralement plusieurs graphiques donnant un aperçu de l’activité de l’entreprise tout en se concentrant sur les métriques principales, en apportant de la valeur ajoutée et en projetant des informations clés et critiques. À cette fin, DevStriker, l’entreprise hôte de notre stage, a décidé de lancer un outil Web d’analyse et de visualisation de données toute plate-forme pour toute la suite Web Simply CE. En effet, les principaux objectifs de notre stage de six mois ont été répartis sur deux parties fondamentales, en commençant par la collecte des informations pertinentes jusqu’à la mise en œuvre d’un outil permettant à l’utilisateur final de consulter des tableaux de bord et de les personnaliser selon plusieurs critères et vues. Le présent rapport englobe et synthétise tout le travail réalisé. Il s’articule autour de sept chapitres. Le premier chapitre « Contexte général » présente l’organisme d’accueil, le projet et la méthodologie de travail adoptée. Le deuxième chapitre « Étude préalable » présente une étude préliminaire du projet. Le troisième chapitre « Initiation au projet » introduit les grandes lignes du projet tout en détaillant ses spécificités et son déroulement. Le quatrième chapitre « Lancement du projet » constitue la phase de « pré-jeu » au cours de laquelle nous précisons l’architecture générale de notre solution ainsi que nos choix technologiques et les outils que nous avons utilisé tout au long du projet. Le cinquième, le sixième 1
  14. 14. Introduction générale et le septième chapitre présentent les « releases » de notre projet, dans lesquelles nous retournons avec plus de détails à la conception soulignant les fonctionnalités offertes par notre solution, ainsi qu’une présentation de l’étape de réalisation et de l’implémentation de notre solution. 2
  15. 15. Chapitre 1 Contexte général Plan 1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Étude de l’existant : Plateforme SimplyCE . . . . . . . . . . . . . . . . . . . 5 3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  16. 16. Chapitre 1. Contexte général Introduction Ce chapitre est consacré à la présentation du cadre général de notre projet. Nous allons commencer par l’organisme d’accueil : son activité et ses services. Par la suite nous allons procéder à une description de l’existant. La dernière section présente les grands traits de la solution ainsi que la démarche à suivre pour la concrétiser. 1.1 Organisme d’accueil Nous procédons à présent à la présentation de l’entreprise au sein de laquelle s’est déroulé notre projet de fin d’études. 1.1.1 SimplyCE Fondée en juin 2014, SimplyCE est une start-up de la région Nantaise en France en plein développement. Elle évolue sur le marché de la publicité, des loisirs et de la réduction, et met à disposition de ses clients des produits et des services innovants. SimplyCE édite et distribue une gamme de produits répondant aux besoins des comités d’Entreprises (institutions représentatives du personnel au sein d’une entreprise) en termes de gestion, de communication et de satisfaction des salariés. Ces produits permettent de simplifier la vie des élus des CE dans l’exercice de leur mandat en garantissant une facilité de gestion et une satisfaction des salariés. Pour son activité, l’entreprise a créé une plate-forme hébergée en mode SAAS (Software as a Service), qui comprend un site internet, des modules de gestion et une interface e-commerce pour la vente de billetterie à tarif réduit. A ce jour, SimplyCE collabore avec 400 enseignes sur Nantes et sa métropole, elle propose également environ 15 000 offres sur le plan national. [1] La figure 3.2 introduit le logo de SimplyCE. Figure 1.1: Logo de SimplyCE 4
  17. 17. Chapitre 1. Contexte général 1.1.2 Devstriker Devstriker est la filiale off-shore de SimplyCE en Tunisie, créée en novembre 2016. Sa mission consiste principalement à étendre des activités de développement informatique et de design graphique. Les équipes à ce moment sont composées de : — Développeurs Full-Stack, Web et Mobile — Web designers / Intégrateurs Web — Social Media Manager / Community Manager — Designers Graphiques 1.2 Étude de l’existant : Plateforme SimplyCE SimplyCE a développé une solution de type Saas (Software a as service), une solution multiservice en ligne à la destination des comités d’entreprises. La solution inclut les fonctionnalités suivantes : — Un micro-réseau social privé d’entreprise : Permet aux comités d’entreprise de communiquer en interne avec leurs salariés en leur partageant des newsletters, des PV de réunions, des albums photos et en leur diffusant des sondages et des enquêtes. — Un espace e-commerce privé de billetterie : Permet aux salariés de l’entreprise d’acheter directement en ligne tout en bénéficiant de tarifs préférentiels sur un catalogue d’offres à dimension locale et nationale. — Un module de gestion : Permet aux comités d’entreprise d’administrer la liste de leurs salariés, de leur attribuer des subventions selon leurs politiques sociales et d’effectuer le suivi. La figure ci-dessous illustre les trois modules mentionnés. 5
  18. 18. Chapitre 1. Contexte général Figure 1.2: Modules de SimplyCE 1.3 Problématique La plateforme SimplyCE ayant plusieurs modules web, nous citons ceux qui sont en relation avec les salariés des comités des entreprises :Wigo Vacances, L’irrésistible, Simply Club. Ainsi les données fournis par ces modules constituent une mine générant des volumes de données de plus en plus vertigineux. La solution SimplyCE édite et distribue une gamme de produits engendrant une masse de données produites chaque jour. À ce stade-là, il parait si difficile d’identifier précisément le profil de chaque client tout en proposant voire infligeant un produit en adéquation avec les intérêts des acheteurs et leurs désirs personnels. En effet, l’entreprise n’aurait presque aucune idée sur l’évolution des comportements d’achat, les insatisfactions des salariées avec tout ce qui circule dans les tuyaux informatiques de leurs entreprises et notamment les données capturée auprès de ces clients, etc. Aujourd’hui, les décideurs au sein de SimplyCE posent des questions comme les suivantes : — Quelle est la performance des pages les plus vues ? — Que recherchent les visiteurs sur notre plate-forme ? 6
  19. 19. Chapitre 1. Contexte général — Y a-t-il des maillons faibles dans les entonnoirs ? — Quels produits déclenchent le plus de mise au panier ? — Quels produits dans les paniers sont les plus abandonnés au moment de l’achat ? — Où-est ce que les visiteurs cliquent-ils sur nos pages Web et où ne cliquent-ils pas ? Cette connaissance servira davantage pour améliorer et accélérer la prise de décision. Un autre problème se manifeste ici : Il faut trouver un moyen de prévoir à long terme les comportements des clients et des prospects aussi. Il ne s’agit plus seulement de se demander « qui a acheté, quand et par quel canal ? », mais aussi « qui achètera quoi, quand et par quel canal ? ». Ce raisonnement est né afin d’enrichir l’expérience-utilisateur et d’obtenir un aperçu concis de la production de l’entreprise. En outre, la fixation et la distinction des axes d’analyse les plus importants et de ceux qui peuvent être ignorés s’avère de plus en plus complexe. C’est l’une des principales raisons pour lesquelles nous avons besoin d’un outil de « Tracking » pour le suivi et le traitement des données collectées et de cette manière là, l’entreprise peut avoir une vision globale de ses multiples actions Marketing, savoir ce qui fonctionne en temps réel et ce qui ne fonctionne pas dans son tunnel de conversion et dans ses actions Marketing. 1.4 Solution proposée La solution proposée consiste à la mise en place d’un outil d’analyse et de suivi des parcours des utilisateurs de la plate-forme de type SaaS de SimplyCE. Cet outil permettra d’analyser les comportements des visiteurs, de définir leurs intérêts à travers la recherche avancée effectuée (selon des mots-clés à priorité) et de fixer des mesures de performance de la plateforme. En outre, cet outil permettra de déterminer et délimiter nos stratégies en fournissant des statistiques sur les utilisateurs en temps réel et sur leurs parcours d’achat complets. Ainsi, l’outil d’Analytique sert principalement à décortiquer les données liées aux ventes et au marketing pour en conclure les mesures adéquates. 1.5 Méthodologie de travail Méthodologie agile : Depuis des années, la majorité des projets de développement logiciel s’appuie sur des méthodologies appelées agiles. Cette bannière combine plusieurs méthodes basées sur le développement itératif et incrémental, dans lequel la recherche des solutions aux problèmes repose sur la collaboration, impliquant le client du début jusqu’à la fin du projet. Elle considère que le besoin ne peut être figé et propose de s’adapter aux changements de ce dernier.[2] La méthodologie agile vise à avoir : 7
  20. 20. Chapitre 1. Contexte général — Une meilleure qualité de communication : Le client a la possibilité de clarifier ou modifier ses besoins au fur et à mesure. — Une meilleure visibilité : Le client a une meilleure visibilité sur l’avancement de son projet. — Une meilleure qualité du produit : Les tests sont effectués continuellement. — Un meilleur contrôle des coûts : Le projet peut être arrêté à défaut de budget. Méthodologie agile : Scrum Scrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est constitué d’une définition de rôles, de réunions et d’artefacts. Scrum définit 3 rôles : — Le Product Owner : C’est le client et le représentant de l’utilisateur ; il définit les besoins, les spécifications du produit et l’ordre dans lequel les fonctions seront développées. — Le Scrum Master : C’est l’intermédiaire entre le Product Owner et l’équipe de développement. Il assure la bonne application de la méthodologie Scrum. — L’équipe de développement : C’est l’équipe qui réalise le produit tout en respectant les délais fixés à l’avance. Il s’agit d’une équipe auto-organisée. Elle regroupe en général une panoplie de profils : Architecte, concepteur, développeur, spécialiste IHM, testeur, etc. Notre projet suit ainsi le processus de développement agile SCRUM (processus de mêlée) afin d’identifier les besoins systématiques, spécifier et planifier dans les délais et en appliquant les bonnes pratiques du Génie Logiciel l’intégralité du projet. La figure 1.3 présente les étapes de la méthodologie SCRUM. 8
  21. 21. Chapitre 1. Contexte général Figure 1.3: Les étapes de la méthodologie SCRUM [3] Conclusion Ce chapitre est une partie introductive de notre projet, au cours de laquelle nous avons présenté le cadre général de notre travail. Nous avons introduit en premier lieu l’organisme d’accueil ensuite, notre solution et la méthodologie de travail adoptée. Nous entamons ainsi la prochaine partie qui consiste à établir une première étude explorant les différents concepts qui touchent à ce projet. 9
  22. 22. Chapitre 2 ÉTUDE PRÉALABLE Plan 1 Définition quelque concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2 Big Data et marketing : les opportunités pour l’entreprise . . . . . . . . . 12 3 Les logiciels de Web Analytique . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  23. 23. Chapitre 2. ÉTUDE PRÉALABLE Introduction Dans ce deuxième chapitre nous faisons l’objet d’une étude préliminaire à travers laquelle nous dévoilons les notions sur lesquelles nous allons nous appuyer et nous menons notre propre recherche et observation vis-à-vis du domaine d’activité concernant notre projet. Nous examinerons par la suite l’existant : cette analyse nous facilitera le développement des modules métiers pour aboutir finalement à une solution concevable, adéquate et qui répond efficacement aux exigences. 2.1 Définition quelque concepts — Web Analytique : Le Web Analytics regroupe la mesure, la collecte, l’analyse et la présentation de données provenant d’Internet et utilisées pour optimiser un site web. C’est un ensemble d’analyses permettant d’étudier précisément les comportements et les habitudes des visiteurs sur les sites web. Le Web Analytics (appelé également Digital Analytics) est aujourd’hui l’un des éléments clés du marketing digital et de l’optimisation des sites, de l’e-commerce notamment. — Big Data : Ce concept est défini principalement par la volumétrie des données dans le monde entier et leur variété qui suivent une croissance exponentielle. Cela se justifie notamment par l’omniprésence d’Internet, la numérisation croissante des interactions de tout type, l’Open Data, l’émergence des objets connectés génèrent des volumes de données de plus en plus vertigineux, la variété des données accrue ; avec notamment le développement des réseaux sociaux : images, sons et textes (et tout autre format de donnée) sont désormais également des données à analyser. Le Big data désigne ainsi une nouvelle génération de solutions de collecte, de stockage, de traitement en temps réel et d’analyse des données. — Big Data Analytique : Le Big Data en entreprise doit aider à la prise de décision. Il est en effet intéressant de voir quelles sont les différences entre le décisionnel classique et le big data. La prise de décision aujourd’hui La prise de décision avec le Big data Vision rétrospective, en « rétroviseur » Vision prospective, recommandations. Moins de 10 des données sont disponibles Toutes les sources de données sont exploitées. Données en lots, incomplètes, disjointes Données en temps réel, corrélées, gouvernées. Supervision de l’activité Optimisation de l’activité. Comparaison entre la prise décision aujourd’hui et avec le Big Data Les décisions humaines sont difficiles à interpréter ou à prévoir. Le Big data donne l’opportunité 11
  24. 24. Chapitre 2. ÉTUDE PRÉALABLE de ne pas avoir à comprendre le processus de décision. Plus besoin de savoir quels sont les facteurs de performance, le pourquoi est mis de côté. Ce qui importe, ce sont les conséquences, les résultats plus que la causalité. Il en est pratiquement de même pour le Big data qui reconstitue un simili grossier du contexte, en croisant des données qui à priori n’ont pas de relations entre elles, ce qui n’est pas le cas du décisionnel classique. 2.2 Big Data et marketing : les opportunités pour l’entreprise La donnée, et le Big data, vont impacter le marketing, en lui amenant toujours plus d’informations pour qu’il puisse accéder à une connaissance plus riche et plus juste du client. Le marketing va indubitablement évoluer. Dès lors, si le Big data se met au service du marketing, quels en sont les objectifs et quels bénéfices en tirent-ils ? 2.2.1 Un marketing prédictif Le marketing s’oriente vers un marketing prédictif qui se nourrit d’importants volumes de données remontés en continu et en temps réel. Cela entraîne deux nouveautés : La modélisation numérique du réel pour manipuler virtuellement le monde ; et des ajustements instantanés et continus des politiques commerciales. Le marketing prédictif est l’aboutissement du « Big data marketing ». Il fait l’objet d’énormément de fantasmes. L’Homme a toujours désiré connaître son avenir. La prédiction certaine conférerait au marketing et au Big data marketing un caractère scientifique. Toutefois nous n’en sommes encore qu’aux balbutiements. Le passage du Data mining à l’analyse prédictive n’est pas encore intégralement franchi. Des obstacles restent à surmonter pour que les promesses de la science soient tenues : tout d’abord, il faudra être capable de gérer la complexification croissante des algorithmes destinés à appréhender toujours plus de dimensions et toujours plus de données. Cela suppose avant tout de remettre en cause les schémas classiques de calculs et de stockages de données afin de permettre au système de résoudre les requêtes avec le moins d’utilisation possible des actions pénalisantes comme les accès disques. 2.2.2 Les bénéfices du Big data sur le marketing Le Big data explore déjà de nouveaux usages dans plusieurs spécialités mercatiques comme le marketing relationnel avec des scénarios « cross-canal », le web analytics avec l’optimisation des parcours en ligne et le marketing prédictif avec l’anticipation des besoins et des évolutions. Le Big data va contribuer à transformer le marketing en améliorant ses capacités d’exécution depuis la collecte des 12
  25. 25. Chapitre 2. ÉTUDE PRÉALABLE informations clients jusqu’à l’implémentation de promotions ou d’offres ciblées. Cette conjugaison du Big data avec le marketing doit amener vers un marketing augmenté, le Big data marketing, pour : — Accroître la réputation de la marque ; — Anticiper les comportements plutôt que de réagir aux situations ; — Comprendre chaque client dans son unicité ; — Délivrer un contenu en lien avec la cible ; — Développer les produits de demain ; — Explorer toutes les informations clients disponibles ; — Maximiser la valeur délivrée à chaque interaction. 2.3 Les logiciels de Web Analytique Il est très important lors de la création ou de la gestion d’un site Web d’être en mesure de connaître la performance de celui-ci. 2.3.1 Histoire et évolution L’évolution de la notion du Digital Analytics est étroitement liée aux évolutions du Web. Trois évolutions majeures du Web ont ainsi bouleversé ce concept : deux évolutions technologiques : l’arrivée du langage JavaScript et des nouvelles technologies de stockage, et une évolution légale : la directive européenne sur les Cookies. L’arrivée du langage JavaScript a révolutionné la discipline en permettant de collecter de nouvelles données de façon plus précise La démocratisation des nouvelles technologies de stockage a rendu possible de nouveaux usages comme l’accès et l’utilisation des données en temps réel à des fins d’optimisation des performances digitales tant au niveau de l’acquisition de trafic que de la personnalisation. L’application de la directive européenne sur les Cookies dans les pays de l’Union Européenne a obligé les annonceurs à demander le consentement de leur visiteur avant l’utilisation de solutions de suivi de leur comportement. Les annonceurs doivent maintenant trouver un juste milieu entre le fait d’être en accord avec la loi et le fait de toujours collecter plus de données.[4] La figure 2.1 justifie l’évolution du Digital Analytics depuis 1993 jusqu’aujourd’hui. 13
  26. 26. Chapitre 2. ÉTUDE PRÉALABLE Figure 2.1: L’évolution du Digital Analytics depuis 1993 jusqu’aujourd’hui [4] 2.3.2 Logiciels Dans cette section nous présentons un petit portrait des différents logiciels existants de Web Analytique. Nous distinguons différents facteurs qui se présentent pour faire le comparatif entre les solutions existantes. Nous essayons à travers le tableau 2.1 de dégager les fonctionnalités principales. 14
  27. 27. Chapitre 2. ÉTUDE PRÉALABLE Kiss Metrics Piwik Moz pro Fonctionnalités suivre les comportements des visiteurs sur un site Web. analyser les informations sur les visiteurs du site Web, tracker les mots-clés intéressants suivre les comportements e-commerce Langues Anglais Anglais Anglais Prix de base 120 $ à 600$ par mois 120$ à 600$ par mois 99$ à 599$ par mois Tableau 2.1: Comparaison entre les différents logiciels de Web Analytique Nous constatons par conséquent que l’offre de logiciels est bien variée et axée sur un domaine et pour une certaine cible. Par contre ceci nous conduit à conclure qu’il y a manque d’analyse sur les trois axes en même temps. D’autre part, ces solutions ne permettent pas d’importer des données à partir de sources externes. conclusion Dans ce chapitre, nous avons présenté une étude théorique concernant le domaine du Web Analytique ainsi que des critiques des solutions existantes sur le marché. Une analyse des besoins fera l’objet du chapitre suivant afin d’avoir une idée plus claire sur le déroulement de notre projet. 15
  28. 28. Chapitre 3 Initiation au projet Plan 1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 22
  29. 29. Chapitre 3. Initiation au projet Introduction L’analyse des besoins est une étape primordiale dans la réalisation de tout projet informatique. De ce fait, ce chapitre sera consacré à la présentation des besoins de notre projet. Nous commençons par l’identification des acteurs (rôles des utilisateurs) et leurs fonctionnalités principales, ensuite nous entamons la spécification fonctionnelle et non fonctionnelle afin de produire le backlog du produit ainsi qu’une première planification des sprints. 3.1 Capture des besoins Dans cette partie, nous définissons les acteurs, leurs rôles et leurs privilèges dans notre application. 3.1.1 Identification des acteurs Nous pouvons distinguer dans notre système 3 acteurs différents : — Décideur : C’est l’utilisateur de notre application, celui qui consulte tout ce qui concerne les analyses à travers la visualisation des statistiques et des rapports générés( parcours, performances, e-commerce, etc.). Son rôle consiste en la possibilité de décider des orientations d’entreprise à travers les résultats de l’application visualisés. — Analyste : Son rôle est de contrôler l’activité des parcours d’utilisateurs dans la plate-forme SimplyCE. Il capture dans un premier temps toutes les informations nécessaires et les stocke. Ensuite il les traite pour pouvoir récupérer des mesures analytiques. — L’administrateur : Il s’agit de l’administrateur de toute la plate-forme. Ses autorisations étendent celles de tous les autres acteurs. Nous introduisons dans la figure une hiérarchie de tous les acteurs. Figure 3.1: Hiérarchie des acteurs 17
  30. 30. Chapitre 3. Initiation au projet 3.1.2 Recueil des besoins fonctionnels (Product Backlog) Les principales fonctionnalités de notre application sont divisées en 2 catégories : La première est spécifique à la collecte de données et l’injection des scripts à la plate-forme Simply Club, la deuxième partagée entre le décideur et l’analyste. Le Backlog du produit L’approche de Scrum propose de commencer par énumérer les exigences du client pour produire le backlog du produit en tant qu’une liste de « user Stories » ; cette liste contient tout ce qui pourrait être exigé dans le produit et est la seule source de besoins pour toutes les modifications à apporter au produit. Chaque élément du backlog ( « backlog item ») est estimé en terme d’effort de développement par l’équipe Scrum. Dans note projet, nous avons estimé l’effort de chaque « backlog item » par un nombre issu de la suite de Fibonacci. Le tableau 3.1.2 introduit le backlog du produit désigné pour notre projet avec l’ordre de priorité qui a été fixé par le « Product Owner ». 18
  31. 31. Chapitre 3. Initiation au projet ID User Story Sprint 1 En tant qu’analyste, je veux collecter de données. 1 5 En tant qu’analyste, je veux reconstituer le parcours utilisateur. 2 6 En tant qu’analyste, je veux mesurer la performance de la plate-forme. 2 2 En tant qu’analyste, je veux récupérer de données à partir d’une API REST. 8 3 En tant qu’analyste, je veux récupérer de données de tracking de notre plate-forme à partir du serveur Google Analytics. 8 4 En tant qu’analyste, je veux créer une structure. 9 7 En tant que décideur, je veux gérer des tableaux de bord. 10 8 En tant que décideur, je veux consulter des statistiques. 11 9 En tant que décideur, je veux consulter l’analyse et les statistiques e-commerce. 10 10 En tant que décideur, je veux consulter le parcours utilisateur. 10 11 En tant que décideur, je veux consulter et évaluer la performance de la plate-forme simplyCE. 10 12 En tant que utilisateur, je veux gérer mon profil. 7 13 En tant que décideur, je veux exporter des rapports. 12 14 En tant que décideur, je veux suivre mes objectifs. 10 15 En tant qu’administrateur, je veux créer un compte google analytique. 1 16 En tant qu’administrateur, je veux gérer des comptes d’utilisateurs 3 Backlog du produit 3.1.3 Les besoins non fonctionnels L’utilité d’un système logiciel est déterminée par ses exigences fonctionnelles et ses caractéristiques non fonctionnelles à la fois. Les exigences non fonctionnelles sont en effet des exigences implicites que le système doit respecter. Dans notre cas, nous avons identifié : L’ergonomie de l’interface : Afin de satisfaire les utilisateurs, cette contrainte est inévitable. Ainsi, l’interface de l’application doit être simple, conviviale et facile à utiliser. Pour le design de l’application, nous devons suivre les grandes lignes directrices (guidelines). 19
  32. 32. Chapitre 3. Initiation au projet La sécurité : Notre système devrait être sécurisé : au moment de l’authentification des utilisateurs de l’application, il faut tenir compte des droits d’accès pour protéger les données. Ainsi, il faut s’assurer des données d’authentification (notamment les jetons de sécurité pour les sessions des utilisateurs) mais aussi du cryptage des données au niveau de la base de données (principalement les mots de passe des comptes des utilisateurs). La maintenabilité et l’évolutivité : Notre projet doit être aligné avec les normes architecturales pour une maintenance facile et pour assurer l’évolution du système en cas d’ajout ou de modification de besoins. La synchronisation de données : L’application doit gérer une mise à jour de données en temps réel pour garantir la fiabilité et la cohérence des données au niveau des résultats d’analytique obtenus. 3.1.4 Modélisation des besoins Dans cette section, nous présentons le diagramme de cas d’utilisation global afin de mieux organiser les besoins de notre système. Nous retournons avec plus de détails sur ces diagrammes dans les phases de réalisation de nos sprints. Dans un diagramme de cas d’utilisation, à chaque acteur est attribué un rôle bien déterminé et chaque cas d’utilisation représente une fonctionnalité réalisée par le système. La figure 3.2 représente le diagramme de cas d’utilisation général 20
  33. 33. Chapitre 3. Initiation au projet Figure 3.2: Diagramme de cas d’utilisation global 3.1.5 Prototypage des interfaces Le prototypage (appelé aussi le maquettage) est une technique qui consiste à préparer les interfaces graphiques de l’application. Elle a pour but de simuler l’interface d’un produit. Le prototypage permet ainsi de détecter les problèmes d’utilisabilité et de mesurer la satisfaction du client par rapport à la compréhension du projet avant de se lancer dans le codage. Dans notre projet, nous avons fait le prototypage des interfaces avec l’outil "Balsamiq". 3.1.5.1 Outil de prototypage : Balsamiq Balsamiq est un outil qui permet de faire des maquettes d’interfaces de manière simple et rapide. Grâce à une bibliothèque riche de gadgets qui sont utilisés par la technique de "drag-and-drop" pour faciliter la génération des maquettes sans aucune connaissance particulière de code. 3.1.5.2 Exemples de maquettes réalisées La figure 5.2 présente une maquette de la navigation principale d’un utilisateur. Ces prototypes décrivent les grandes lignes des interfaces. La solution finale ne sera pas totalement 21
  34. 34. Chapitre 3. Initiation au projet conforme à ces maquettes. Figure 3.3: Exemples de maquettes réalisées 3.2 Pilotage du projet avec Scrum Dans ce paragraphe nous décrivons le déroulement de notre projet tout au long de la période du stage. 3.2.1 Les outils Scrum : VersionOne Il existe des différents outils pour la gestion d’un projet Scrum qui offrent la possibilité de suivre la priorité, la traçabilité et la gestion de tout le travail associé. Parmi ces outils nous avons choisi d’utiliser « VersionOne ». C’est une solution complète de gestion de projet agile qui permet à l’équipe d’utiliser Scrum en leur fournissant un espace de travail collaboratif. Il permet aux équipes d’avoir une meilleure vision de l’avancement de leur projet ce qui leur permet d’avoir une idée sur les risques à venir et d’améliorer leur productivité [5]. 3.2.2 Équipes et rôles Nous illustrons dans le tableau 3.1 les différents acteurs participant au déroulement de notre projet et leurs rôles respectifs. 22
  35. 35. Chapitre 3. Initiation au projet Acteur Rôle Mission Malek TAZEROUT Product Owner Définition des besoins Définition de l’ordre de priorité dans lequel les fonctionnalités seront développées Validation des tâches réalisées et des idées proposées Mayssa MESSAOUDI Scrum Master Veiller au bon déroulement du projet et à l’application correcte de la méthodologie (Planification des sprints et évènements Scrum) S’assurer de l’implication de l’équipe et l’aider à franchir les différents obstacles Assister l’équipe dans la recherche et l’identification de solutions Suivi des tâches réalisées et des idées proposées Yosra ADDALI L’équipe Proposition de solutions Recherche Et Développement Conception Réalisation des tests Tableau 3.1: Acteurs du projet Conclusion Dans ce chapitre, nous avons défini en premier lieu les acteurs de notre application avec leurs rôles et leurs cas d’utilisation. En deuxième lieu nous avons présenté les spécifications fonctionnelles et non fonctionnelles de la solution. Enfin nous avons décrit le déroulement de notre projet suivant la méthodologie Scrum. Dans ce qui suit nous allons introduire le premier sprint qui consiste à présenter les choix architecturaux et techniques. 23
  36. 36. Chapitre 4 Lancement du projet Plan 1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
  37. 37. Chapitre 4. Lancement du projet Introduction Au cours de ce chapitre, nous définissons notre architecture globale du projet, puis nous définissons nos choix technologiques et nos outils utilisés. 4.1 Architecture de la solution Dans cette partie nous illustrons l’architecture globale de notre solution. L’architecture utilisée dans notre système est l’architecture 3-tiers illustrée par la figure 4.1 Figure 4.1: Architecture globale Cette architecture se base en effet sur une séparation de 3 niveaux au sein d’une même application : — Un client léger : Celui-ci prend en charge la présentation de l’application, les traitements locaux qui permettent la vérification de la saisie et la mise en forme des données. Dans notre cas, il s’agit d’une application Web. — Un serveur d’application : Il prend en charge les traitements applicatifs. Il communique avec le client à travers des requêtes HTTP . — Un serveur de base de données : C’est là où se situent les données. Il doit avoir une importante capacité de stockage, il doit être disponible afin qu’on puisse y accéder à tout moment, et il doit enfin avoir une puissante capacité de traitement dans le cas où plusieurs requêtes s’y exécute en même temps. 25
  38. 38. Chapitre 4. Lancement du projet 4.2 Choix technologiques Cette section sera consacrée à justifier nos choix technologiques et à montrer leurs avantages. 4.2.1 Le développement web 4.2.1.1 La plateforme du serveur Le temps de réponse élevé du serveur dans la solution existante de SimplyCE nous a poussé à chercher une autre plateforme que Symfony (PHP) qui remédie à ce problème. La solution que nous avons trouvée est d’utiliser NodeJs. Basé sur JavaScript, NodeJs gère efficacement les requêtes HTTP et contient également un serveur HTTP intégré ce qui rend possible de faire tourner un serveur web en interne, sans avoir besoin d’un serveur externe comme Apache. Cette solution nous permet de gagner en performance par rapport à la première puisque le modèle d’exécution NodeJs est basé sur la boucle d’événements JavaScript qui utilise les callbacks sur un seul processus. Cette boucle d’événements facilite la gestion des demandes simultanées sur le serveur. La figure 4.2 explique bien comment NodeJs fonctionne. Figure 4.2: Modèle d’exécution de NodeJs [6] Une fois que les clients ont envoyé leurs demandes au serveur NodeJs, ce dernier les place dans une file d’attente de traitement « Event Queue ». Par la suite, NodeJs utilise la boucle d’événements de Javascript « Event Loop » qui vérifie les demandes placées dans la file d’attente pour les traiter. Si les demandes du client sont simples : c’est à dire elles ne nécessitent pas des entrées/sorties bloquantes, alors elles seront traitées directement. Sinon, la boucle d’événement utilise le « C++ Thread Pool » pour les traiter. Lorsque le traitement d’un Thread est terminé, un Callback est envoyé à l’« Event Loop » qui par la suite retourne la réponse au client. La figure 4.3 montre la performance de NodeJs en le comparant avec PHP en terme de temps de réponse. 26
  39. 39. Chapitre 4. Lancement du projet Figure 4.3: Comparaison entre PHP et NodeJs en terme de temps de réponse [7] 4.2.1.2 La base de données Le choix du système de gestion de la base de données (SGBD) est une étape primordiale pour tout projet informatique. En effet, les données sont les éléments vitaux des entreprises, c’est pour cette raison qu’il faut bien choisir le SGBD qui permet de les gérer et les mettre à disposition des utilisateurs. Il existe deux groupes de famille de SGBD dont chacune dispose de ses avantages et de ses inconvénients. Dans le cadre de notre projet nous avons fait le choix entre la famille des SGBD relationnels tels que MYSQL qu’utilise SimplyCE actuellement, et la famille des SGBD non relationnels représentée par la technologie NOSQL (Not Only SQL). Vu le grand nombre de données diffusées par SimplyCE et le nombre important des utilisateurs qui ne cesse d’augmenter, la solution MYSQL de SimplyCE déjà existante devient de plus en plus difficile à gérer, notre intérêt alors se tourne vers les techniques NOSQL. En effet, pour un flux de données très important lors du suivi des données des utilisateurs nous nous trouvons face à des modèles de données sans schéma fixe et qui s’enrichissent et prennent du volume au cours du temps ; et notons ici que le temps de réponse d’une base de données relationnelle augmente proportionnellement ce qui cause une chute claire de performance. La figure 4.4 explique encore notre choix. Figure 4.4: Comparaison en termes de scalabilité entre les bases de données relationnelles et non relationnelles [8] 27
  40. 40. Chapitre 4. Lancement du projet Il existe de multiples bases de données de type NOSQL, dans notre projet nous avons utilisé la base NOSQL Orientée-Document « MongoDB ». MongoDB est une base de données NOSQL Open Source qui utilise des documents de type JSON pour stocker les données ; ce qui signifie que les champs peuvent varier d’un document à l’autre et la structure des données (qui n’a pas de schéma fixe) peut être modifiée au fil du temps. Ce mécanisme lui confère une grande souplesse d’utilisation et une véritable évolutivité. MongoDB peut également être mise à l’échelle à travers de multiples centres de données distribués pour répondre et faire face à une montée en charge ou une intolérance aux pannes, offrant une disponibilité et évolutivité précédemment inaccessibles avec les bases de données relationnelles. [9]. 4.2.1.3 Les Services Web Les services web sont des programmes informatiques permettant la communication et l’échange de données entre applications et systèmes hétérogènes dans des environnements distribués. Ils fournissent un moyen d’intégrer différents systèmes et d’exposer des fonctions métiers réutilisables. Les applications logicielles écrites dans divers langages de programmation et exécutées sur différentes plateformes peuvent utiliser les services Web pour échanger des informations sur Internet en utilisant le protocole HTTP. Dans notre projet il est évident de créer des web services et de les exposer en tant que méthode Web au client mobile [10]. Services web RESTful REST, l’acronyme de "Representational State Transfer", est un style d’architecture pour les systèmes distribués, basé sur le protocole HTTP. Il est basé sur les principes suivants : — Tout est ressource : chaque ressource est identifiable par un seul identifiant (URI). — L’utilisation des méthodes/standards HTTP (GET -POST -PUT – DELETE). — Architecture Client/Serveur : Le client pour accéder et modifier la ressource et le serveur pour fournir la ressource. — Stateless (sans état) : Toutes les modifications d’une ressource doivent être effectuées à travers une requête HTTP isolée et indépendante. Avantages du REST Parmi les différents avantages du REST nous pouvons citer : — La simplicité d’implémentation. — La séparation entre le client et le serveur. — L’indépendance vis à vis du langage de programmation et de la plateforme de déploiement [11]. 28
  41. 41. Chapitre 4. Lancement du projet Les bonnes pratiques pour la conception d’une APIS REST La création des APIS REST constitue une étape inévitable et primordiale dans notre projet. La réussite de cette mission passe par l’étape de conception qui représente un enjeu majeur, dans la mesure où une API mal conçue ne sera vraisemblablement pas ou peu utilisée. Pour cette raison, nous devons suivre les bonnes pratique telles que : — Une URL doit être simple et intuitive. — L’utilisation des noms dans un URI au lieu des verbes. — Les noms doivent être explicites et au pluriel. — L’utilisation des verbes HTTP pour décrire les actions réalisées sur les ressources : "POST" pour la création d’une ressource, "PUT" pour la modification d’une ressource, "DELETE" pour la suppression d’une ressource et "GET" pour la demande d’une ressource. — L’utilisation des codes de statuts HTTP (Exemples : 401 : utilisateur non authentifié, 404 : ressource non trouvée, 202 : succès de la requête) [12] [13]. 4.2.1.4 Approches de création d’une APIS REST Grâce à la communauté NodeJs très active, la quantité de résultats pour une recherche de REST sur NPM est très importante mais chacun a sa propre implémentation et sa propre approche. Nous avons comparé dans un premier temps des différentes approches qui permettent de créer une application exposant une APIS REST. — EXPRESS : EXPRESS est le framework standard pour le développement des applications Web basé sur Node JS. L’approche la plus courante est de simplement créer des routes avec Express. Sa caractéristique la plus avantageuse est sa large communauté très active et son inconvénient majeur c’est le fait qu’il n’a rien de standard, toutes les routes doivent être créées manuellement : nous devons toujours implémenter notre propre approche. — HAPI : Hapi est un framework NodeJs moins connu qui prend de l’ampleur grâce au support à plein temps de l’équipe de Wal-Mart Labs. Il prend une approche un peu différente de celle d’Express en fournissant beaucoup plus de fonctionnalités hors du commun pour la construction des services Web. — LOOPBACK : LoopBack de « StrongLoop » est un framework de backend Node.js complet pour connecter les applications aux données via des APIs REST. 29
  42. 42. Chapitre 4. Lancement du projet C’est un framework hautement évolutif pour créer des APIs et les relier à des sources de données. Il est construit au dessus d’Express et est livré avec un ensemble de modules NodeJs pour construire des APIs REST pour des applications clientes. Parmi ses caractéristiques les plus avantageuses nous pouvons citer : Sa documentation très riche et complète, son explorateur API intégré que nous pouvons utiliser pour parcourir facilement l’API que nous avons créée ainsi que ses modèles intégrés et prêts à l’emploi. La plus puissante fonctionnalité de Loopback, c’est en fait la génération d’une API REST complète et bien documentée à partir d’un modèle défini, avec un ensemble d’opérations « CRUD » de création ( POST), de lecture ( GET ), de mise à jour( UPDATE ) et de suppression ( DELETE ).[14] [15] Choix Après une comparaison de ces frameworks très connus et utilisés nous optons pour Loopback. C’est le framework qui regroupe toutes les fonctionnalités dont nous avons besoin pour l’implémentation de notre API REST ; et en plus nous pouvons utiliser EXPRESS en cas de besoin puisque Loopback est construit au dessus de lui. 4.2.2 Le développement front-end 4.2.2.1 Angular 2 Angular 2.+ est l’un des frameworks le plus avancé pour le web crée par Google. Angular 2 est le résultat de reconstruction d’AngularJS,développé avec TypeScript,et sa versions table était lancée en 14 Septembre 2016.Angular 2 a apporté plusieurs améliorations par rapport à son prédécesseur AngularJS avec des performances améliorées,une modularité accrue,du code plus expressif et un respect des nouveaux standards du web.[16] 4.2.2.2 React React est l’une des bibliothèques JavaScript les plus populaires développées par Facebook pour construire des interfaces utilisateurs.React permet de créer des composants réutilisables pour construire des interfaces graphiques.[17] Comme nous avons déjà mentionné les deux critères choisis pour la comparaison sont la performance et la modularité du code.En ce qui concerne la performance, la figure 4.5 montre une analyse du temps nécessaire pour afficher un certain nombre d’articles. L’analyse est faite pour comparer 4 framworks Angular2, AngularJS, ReactJS et Blaze, mais nous 30
  43. 43. Chapitre 4. Lancement du projet Figure 4.5: Courbe de performance React VS Angular VS AngularJS VS Blaze [18] intéressons seulement aux résultats d’Angular 2 et ReactJS. Selon la courbe, Angular est le plus performant, avec l’affichage de 50000 articles dans moins de 1000 milli secondes.En outre, en ce qui concerne la modularité du code et la lisibilité, Angular utilise TypeScript qui permet une meilleure organisation du code avec les interfaces et un typage statique.Angular et React sont à base de composants ce qui permet d’avoir un code modulaire et réutilisable.Après l’évaluation de ces deux critères,nous avons choisi Angular 2. 4.2.2.3 Librairies utilisés Chart.js et 3D.js Pour afficher les statistiques obtenues, nous avons besoin de dessiner plusieurs graphiques graphiques qui forment les tableaux de bord. Une des bibliothèques les plus riches et stables pour faire cette tâche est D3.JS et Chart.js. 4.2.3 Test et qualité de code Dans cette partie, nous détaillons les choix des framework de tests. 4.2.3.1 Mocha Mocha est un framework de test JavaScript exécuté sur Node JS. Nous l’avons utilisé pour réaliser des tests d’intégration côté serveur de nos APIs REST [19]. 31
  44. 44. Chapitre 4. Lancement du projet 4.2.3.2 Jasmine Jasmine est un framework de test JavaScript exécuté sur Angular 2+. Nous l’avons utilisé pour effectuer des tests fonctionnels côté client [20]. 4.2.3.3 protractor Protractor est un framework de test de bout en bout pour les applications angulaires. Protractor exécute des tests contre votre application fonctionnant dans un vrai navigateur, en interagissant avec elle comme un utilisateur.[21] 4.2.4 Les patrons de conception (Design Patterns) La conception d’un projet est une préoccupation primordiale. Une des premières choses que nous devrions considérer est l’architecture que nous envisageons d’adopter ; c’est le moyen de définir comment les différents éléments de notre application se rapportent les uns aux autres et pour établir les règles de base pour nous guider pendant le développement. Dans notre projet nous avons utilisé des différents patrons de conception. Pour l’architecture de notre application Front-End, nous avons fait le choix entre les deux patrons architecturaux les plus connus et les plus utilisés dans le développement Web : MVVM [22]. 4.2.4.1 MVVM : ( Model-View-View-Model ) MVVM est un design pattern très souvent utilisé ces derniers temps par des bibliothèques JavaScript. — Model : Le modèle inclut tout le code qui implémente la logique de l’application principale et définit les types requis pour modéliser le domaine de l’application. Ce layer est complètement indépendant des layer de modèle Vue et Vue. — ViewModel : La couche ViewModel fournit des cibles de liaison de données pour la vue. Dans de nombreux cas, le Modèle View expose directement le modèle ou fournit des membres qui encapsulent des membres de modèle spécifiques. Le Modèle d’affichage peut également définir des membres pour garder une trace des données pertinentes pour l’interface utilisateur, mais pas pour le modèle, tel que l’ordre d’affichage d’une liste d’éléments. — View : Le calque de vue définit l’interface utilisateur à l’aide du balisage déclaratif. Le balisage de liaison de données définit la connexion entre des composants d’interface utilisateur spécifiques et divers membres modèle Vue (et parfois modèles). 32
  45. 45. Chapitre 4. Lancement du projet Figure 4.6: ArchitectureMVVM [23] La figure 4.6 résume donc l’architecture de design pattern MVVM. 4.2.4.2 Singleton Le Design Pattern Singleton garantit qu’une classe ne possède qu’une seule instance, et fournit un seul point d’accès à celle-ci. Nous l’avons utilisé dans la partie Front-End parce que nous avons besoin d’une seule instance responsable de la consommation des Web Services. 4.3 Environnement de travail Dans cette partie, nous présentons l’environnement matériel mis à la disposition du présent projet ainsi que l’environnement logiciel qui a permis l’implémentation de notre application. 4.3.1 Environnement matériel Notre projet n’exige pas un environnement matériel spécifique. Pendant la phase d’implémentation on a utilisé un ordinateur portable avec les caractéristiques suivantes : — Marque : Sony VAIO (Serie E, 15 pouces). — Processeur : Intel Core i5 330M / 2.13 GHz - Mémoire Volatile : 4 giga octets. — Mémoire de stockage : 500 Go 1600 MHZ DDR3. — Graphisme : Intel iris 1536 Mo. — Système d’exploitation : Windows version 10. 4.3.2 Environnement logiciel Dans cette section, nous présentons les outils logiciels que nous avons utilisés tout au long de notre projet. 33
  46. 46. Chapitre 4. Lancement du projet 4.3.2.1 Enterprise Architect Enterprise Architect est un logiciel spécialisé dans la modélisation et la conception UML, édité par la société australienne Sparx Systems. Il dispose d’une riche documentation et est destiné aux analystes et aux développeurs pour les aider à concevoir des logiciels faciles à mettre à jour. 4.3.2.2 WebStorm WebStorm est un IDE rapide et puissant pour le développement basé sur Node js. Il offre de nombreuses fonctionnalités parmi lesquelles nous présentons : — Une assistance intelligente du code. — Un système de contrôle de versions avec une interface utilisateur dynamique. — Des fonctionnalités de débogage et de test. 4.3.2.3 Bitbucket Bitbucket est un système de contrôle de versions réparti, utilisé pour suivre notre projet et le partager facilement avec toute l’équipe SCRUM. 34
  47. 47. Chapitre 4. Lancement du projet 4.3.2.4 MongoDB Compass MongoDB Compass est conçu pour permettre aux utilisateurs d’analyser et de comprendre facilement le contenu de leurs collections de données dans MongoDB et d’effectuer des requêtes, sans nécessiter de connaissance de MongoDB. 4.3.2.5 Postman Postman est une application qui permet avec un navigateur Web de lancer des appels d’API et de les tester. Il dispose d’un environnement graphique complet et clair pour gérer l’ensemble des interactions avec les API. 4.3.2.6 NPM : Node Package Manager C’est le gestionnaire des paquets de NodeJs que nous avons utilisé pour installer nos dépendances côté serveur. NPM dispose d’un fichier de configuration important nommé ’package.json’ qui décrit la configuration du projet et contient la liste des dépendances avec leurs versions précises. Conclusion Durant ce chapitre, nous avons préparé le terrain pour la réalisation de notre projet. Nous avons défini l’architecture de notre solution et présenté l’environnement de travail. Nous entamons dans le chapitre suivant la phase de réalisation en se lançant dans le premier sprint. 35
  48. 48. Chapitre 5 Release 1 Plan 1 Présentation des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2 Sprint 1 : Proof of Concept G.A . . . . . . . . . . . . . . . . . . . . . . . . . 37 3 Sprint 2 : Méthode de collecte de données . . . . . . . . . . . . . . . . . . . 38 4 Sprints 3 et 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
  49. 49. Chapitre 5. Release 1 Introduction Dans ce chapitre nous allons concentrer sur la première « Release » du projet. Nous allons présenter le travail réalisé durant chaque Sprint de cette Release. En se basant sur l’avis du Product Owner, nous avons défini le but de la Release : C’est d’étudier et de collecter les informations dédiée aux parcours utilisateurs. 5.1 Présentation des sprints Les objectifs définis dans ces sprints sont : Objectifs techniques : — Étude détaillée de l’API Google Analytique. Objectifs fonctionnels : — Étude détaillée de la plate-forme Simply CE. — Détermination des informations pertinentes dédiées au parcours utilisateur. — Détermination des données métiers requises par G.A. — Création d’un compte Google Analytique qui nous est spécifique. — Proof of concept Google Analytique : trouver et pratiquer un exemple simple (Prototype) démontrant l’utilisation de G.A. — Tracking implémentée. 5.2 Sprint 1 : Proof of Concept G.A Dans cette partie nous allons présenter le premier sprint de cette Release et ce que nous avons fait durant ce tout premier sprint. 5.2.1 Backlog du Sprint 1 Le backlog du sprint contient les « Technical Stories » et les « User Stories ». Ces derniers servent à préciser les attentes du Product Owner dans ce Sprint en matière de fonctionnalités. La figure 5.1 résume donc le backlog de premiers Sprints. 37
  50. 50. Chapitre 5. Release 1 Figure 5.1: Backlog du sprint 1 5.2.2 Proof of Concept G.A Pour s’assurer de la bonne compréhension et de la fiabilité de l’étude que nous avons menée, le PO nous a demandé de réaliser un petit prototype pour monter l’utilisation concrète de Google Analytique. La figure 5.2 montre un prototype d’utilisation des APIs Google Analytics qui permet de récupérer les informations de la plate-forme Simply CE. Figure 5.2: prototype GA 5.3 Sprint 2 : Méthode de collecte de données Quelque soit le type d’évaluation menée, il est essentiel de bien choisir les méthodes de collecte et d’analyse des données et de les appliquer correctement. 38
  51. 51. Chapitre 5. Release 1 5.3.1 Tracking Simply CE Le tracking consiste à organiser la collecte et le stockage de données de navigation de l’ensemble des visites réalisées par les visiteurs de la plate-forme Simply CE. Donc pour s’assurer cet objectif nous avons utilisé les APIs Google Analytique. Vu que la solution Simply CE en mode production et aussi ayant plusieurs module web donc notre tracking a été effectue tout d’abord sur une plate-forme de test en mode sandbox pour le moment "Simply Club". 5.3.2 Les différentes API Google Analytics Google Analytique est un service gratuit de « Web Analytique » proposé par Google. [24] Pour mettre en place la fonctionnalité de tracking, nous avons besoin de recourir aux API G.A qui sont organisées en 4 catégories principales : Collection, Configuration, Traitement et Reporting. — La catégorie collection recueille les données d’interaction utilisateur. — La catégorie configuration permet de gérer la façon dont les données sont traitées. — La catégorie traitement traite les données d’interaction utilisateur, avec les données de configuration. — La catégorie rapports permet d’accéder à toutes les données traitées. Nous illustrons par la figure 5.4 les APIs google analytique. Figure 5.3: APIs GA [25] 39
  52. 52. Chapitre 5. Release 1 5.3.3 Backlog sprint 2 Nous introduisons à travers la figure 5.4 le backlog du sprint2. Figure 5.4: Backlog du sprint 2 5.3.4 Planifier la collecte et l’analyse de données Avant de décider de la nature et du contenu de données à recueillir et de la façon de les analyser, il faut déterminer et étudier les actions que les salaries de comités d’entreprise font sur la plate-forme Simply CE. Dans ce cas, nous nous intéressons seulement par le module. web intitule "Simply Club". Vu que ce but de récupérer les données pertinentes est clairement défini, il est nécessaire de commencer d’injecter les codes de suivi là où il le faut dans la plate-forme, donc en allant sur les pages de la plate-forme Simply CE, nous devons injecter les marqueurs de suivi dans les balises HTML <HEAD>. 5.3.5 Les informations pertinentes La configuration Google Analytique par défaut permet de collecter ces informations : • Le comportement des utilisateurs Dans cette partie, nous allons définir les données dédiées à l’analyse le comportement de l’utilisateur : le parcours utilisateur est utilisé pour représenter l’expérience du client donc c’est les différentes étapes du service. Dans un contexte de collecte, nous devons être basé sur des observations. Pour cela, il faut aller sur le site Simply Club pour comprendre les actions réalisé par les utilisateurs dans leur contexte. Ces observations permettent de capter ce qu’il se passe réellement et ne se base pas sur des hypothèses. Il faut prendre en compte toutes les parties prenantes du service et penser à toute la chaîne de valeur : les actions c’est à dire les interactions des utilisateurs,les intérêts et la navigation sur le site,processus d’achat. 40
  53. 53. Chapitre 5. Release 1 Nous prenons l’exemple d’une Event Tracking : • A cliqué sur le lien Télécharger » • A consulté une image de produit » • A effectué une recherche sur le site » • A cliqué sur la bannière d’un partenaire » • A cliqué sur un lien sortant » • A accédé à la page d’actualités » • S’abonner» • A complété son profil » Nous illustrons par la figure 8.1 le script injecté permettant de mesurer le nombre de clics. Figure 5.5: Bouts de code injectés Pour plus de détails des scripts injectées voir l’annexe 1. • L’analyse de la performance Simply-Club Les données relatives à la performance présente par une visite est en effet le passage d’un visiteur sur la plate-forme Simply Club au bout d’une unité de temps durant laquelle une ou plusieurs pages sont vues. Nous nous proposons ainsi d’enregistrer ces vues de pages car à ce stade nous aidons à récolter des donnés de performance le cas il y a des exceptions, pour une session le nombre de visiteurs, les transaction qu’elle peut les supporter. Nous illustrons par la figure 8.2 quelques bouts de codes que nous avons injectées sur la plate-forme Simly Club. 41
  54. 54. Chapitre 5. Release 1 Figure 5.6: Bouts de code injectés • Comportement d’achat sur la plate-forme Simply-Club Nous nous proposons en effet de récupérer à cette phase les données relatives au commerce électronique. Pour collecter ces données, il faut au préalable de préparer des scripts afin de les injecter au niveau d’une page de confirmation d’achat, ou de validation de paiement, de même il est possible de récupérer d’autres données que celles relatives au panier d’utilisateurs, telles que les produits intéressés. Une fois l’implémentation réalisée, nous allons pouvoir récupérer et voir les données orientées E-commerce. Pour mesurer l’interaction de salariés avec les produits revient à tracker ces évènements : • suivre parcours d’achat d’un salarie • Les clics de produits • L’affichage des détails de produits • L’ajout des produits au panier • La suppression des produits au panier • Suivre le panier d’achat • Au niveau du transaction Nous illustrons par la figure 5.7 quelques bouts de code que nous avons injectés sur la plate-forme. 42
  55. 55. Chapitre 5. Release 1 Figure 5.7: Bouts de code injectés Nous illustrons par la figure 8.4 quelques bouts de code que nous avons injectés sur la plate-forme. Figure 5.8: Bouts de code injectés 5.4 Sprints 3 et 4 5.4.1 Objectifs Les objectifs définis dans ces deux sprints sont : Objectifs techniques : — Documentation technique sur NodeJS — Documentation technique sur ExpressJS — Installation et configuration de l’environnement de développement. — Installation et configuration de l’environnement de test. — Configuration du projet sur bitbucket. 43
  56. 56. Chapitre 5. Release 1 Objectifs fonctionnels : — Étude détaillée des indicateurs clés de performance. — Choix KPIs. — Choix technologique Front Back — Création projet (structuration : Prototype back end + Prototype front end) 5.4.2 Le planning du sprint Nous présentons le planning du sprint 3 et 4 par son backlog de sprint. La figure 6.1 résume donc le backlog de nos deux Sprints. Figure 5.9: Backlog des sprints 3 et 4 5.4.3 Les indicateurs clés de performance Définition : Key Performance Indicator, en français : Indicateur Clé de Performance : Métrique essentielle, et dans l’idéal, objective et actionnable Un ensemble de mesures quantifiables qu’une entreprise utilise pour mesurer ou comparer les performances en termes de satisfaction de leurs objectifs stratégiques et rendre le processus décisionnel plus facile. Vu que dans notre projet nous avons la parties aide la décision, Les indicateurs clés (KPI) aident les décideurs à comprendre comment elles sont performantes par rapport à leurs buts et objectifs stratégiques. [26] Le schéma 5.10 ci-dessus résume donc la construction des KPIs en relation les objectifs de l’entreprise. 44
  57. 57. Chapitre 5. Release 1 Figure 5.10: schéma de construction les indicateurs clés de performance Le schéma 5.11 ci-dessus résume donc les différents KPI que nous avons besoins lors la dernière phase reconstitution des tableaux de bord. Figure 5.11: schéma les indicateurs clés de performance en l’entreprise simply CE Conclusion Dans cette premier release, nous avons configuré notre environnement de travail, acquis les connaissances de base pour le développement de notre projet et nous avons consacré à l’étude théorique du projet qui explique bien le type donnée collectée et nous permet de les sélectionner que nous avons 45
  58. 58. Chapitre 5. Release 1 utilisé à la phase suivante"étude technique de la collecte". Nous entamons dans ce qui suit la deuxième release de notre application. 46
  59. 59. Chapitre 6 Release 2 Plan 1 Présentation des sprints du release 2 . . . . . . . . . . . . . . . . . . . . . . . 48 2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
  60. 60. Chapitre 6. Release 2 Introduction Dans ce chapitre, nous allons concentrer sur la deuxième release du projet. Nous allons présenter le travail réalisé durant chaque Sprint de ce Release. En se basant sur l’avis du product Owner, nous avons défini le but de ce Release : C’ est de livrer la deuxième version du projet qui permet à l’analyste authentifié de récupérer et consulter les sources. 6.1 Présentation des sprints du release 2 Dans cette partie nous présentons les sprints du deuxième release. 6.1.1 Objectifs des sprints Les objectifs définis dans ces deux sprints sont des objectifs fonctionnels : — Inscription. — Authentification. — Déconnexion. — Initialisation du mot de passe. — Édition profile. — Récupération de données à partir de la API SimplyCE. — Récupération de données à partir de Google Analytique. — Étude détaillée les indicateurs de clé performance. — Documentation technique sur Loopback. — Documentation technique sur Angular 4. 6.1.2 Le planning des sprints du release 2 Nous présentons le planning des sprints par leurs backlog des sprints. La figure 6.1 présente le backlog du sprint 5. 48
  61. 61. Chapitre 6. Release 2 Figure 6.1: Backlog du sprint 5 La figure 6.2 présente le backlog du sprint 6. Figure 6.2: Backlog du sprint 6 La figure 6.3 présente le backlog du sprint 7. Figure 6.3: Backlog du sprint 7 La figure 6.4 présente le backlog du sprint 8. Figure 6.4: Backlog du sprint 8 6.2 Spécification fonctionnelle La spécification fonctionnelle dans notre cas se traduit par les diagrammes UML de cas d’utilisation et de séquence système. 6.2.1 Diagramme de cas d’utilisation Dans la figure suivante nous illustrons le diagramme de cas d’utilisation de Release 2. 49
  62. 62. Chapitre 6. Release 2 Figure 6.5: Diagramme de cas d’utilisation de Release 2 6.2.2 Diagrammes de séquence système Pour mieux comprendre le fonctionnement de l’authentification et de l’inscription d’un utilisateur, nous illustrons les diagrammes de séquence système de ces deux fonctionnalités. 50
  63. 63. Chapitre 6. Release 2 6.2.2.1 Authentification d’un utilisateur Figure 6.6: Diagramme de séquence système « S’authentifier » 51
  64. 64. Chapitre 6. Release 2 6.2.2.2 Création d’un compte utilisateur Figure 6.7: Diagramme de séquence système « Créer un compte utilisateur » 6.2.2.3 Réinitialisation du mot de passe Nous décrivons le cas d’utilisation « Réinitialiser le mot de passe » par la description textuelle ci dessous. 52
  65. 65. Chapitre 6. Release 2 Titre Réinitialisation du mot de passe Acteur Utilisateur non authentifié. Résumé Ce cas d’utilisation permet à l’utilisateur qui a oublié son mot de passe de le réinitialiser. Précondition L’utilisateur demande de réinitialiser son mot de passe. Postcondition Mot de passe réinitialisé. Scénario nominal 1. L’utilisateur demande la réinitialisation de son mot de passe. 2. L’utilisateur introduit son email. 3. Un email contenant un lien de réinitialisation est lui est envoyé. 4. L’utilisateur clique sur le lien et arrive sur un formulaire où il saisit son nouveau mot de passe. 5. Une fois le mot de passe modifié l’utilisateur peut se connecter avec son nouveau mot de passe. Scénario d’excéption Si l’email fourni est inexistant, l’utilisateur sera alerté. Description textuelle du cas d’utilisation « Réinitialiser le mot de passe » 6.2.2.4 Gérer les sources Nous décrivons le cas d’utilisation «Gérer des sources » par la description textuelle ci dessous. 53
  66. 66. Chapitre 6. Release 2 Titre Gérer des sources Acteur L’analyste. Résumé Ce cas d’utilisation permet à l’analyste de récupérer le source de données . Précondition L’utilisateur choisit le type de source. Postcondition Récuperation un source. Scénario nominal 1. L’analyste sélectionne l’affichage des sources. 2. Une liste des sources est affichée. 3. L’analyste choisit type de source : à partir de google analytique ou bien API REST du simply CE. 4. Si le choix est égal google analytique, l’analyste introduit ses configurations nécessaires pour récupérer les données. 5. si choix est égal API REST l’analyste introduit url de l’API Simply CE. 6. Dans les deux cas l’analyste clique sur le buttons récupérer les données . 7. Une fois l’ajout de donnée a été effectué, une source sera ajouté. 8.Une liste des sources est affichée. Scénario d’excéption Si le configuration saisie est inexistant, l’utilisateur sera alerté. Description textuelle du cas d’utilisation « Gérer les sources » 6.3 Conception Dans cette section, nous présentons d’abord le diagramme d’activité pour mieux comprendre la navigation entre les différentes pages de notre application, puis nous illustrons le diagramme du classe(nos entités métiers) et les diagrammes de séquences. 6.3.1 Diagramme d’activité L’objectif de ce diagramme est de montrer comment l’utilisateur peut naviguer entre les pages dans l’application. 54
  67. 67. Chapitre 6. Release 2 Figure 6.8: Diagramme d’activité de release 2 6.3.2 Diagramme de paquetage Le diagramme de paquetage représente l’arrangement et l’organisation des différents éléments d’un projet. chaque paquetage permet de regrouper un ensemble d’éléments une même appellation (namespace) . La figure 6.9 présente le diagramme de paquetage de notre solution. Figure 6.9: Diagramme de paquetage 6.3.3 Diagramme de classe L’objectif du diagramme de classe dans notre projet est de concevoir nos collections MongoDB. Ce diagramme sera progressivement mis à jour dans chaque sprint de notre projet. 55
  68. 68. Chapitre 6. Release 2 Pour release 2, nous n’avons besoin que des modèles illustrés par la figure 6.10. Figure 6.10: Diagramme de classe de release 2 Le modèle « User » est l’un des modèles intégrés fournis par Loopback. Ce modèle offre plusieurs fonctionnalités que nous pouvons utiliser telles que le système d’authentification. Le modèle « AccessToken » aussi est fourni par Loopback. Une fois qu’un utilisateur est connecté, LoopBack lui crée un nouveau « AccessToken ». Il est requis lors de l’invocation des méthodes REST pour valider que le client a bien le droit d’invoquer des méthodes sur un modèle donné. 6.3.4 Diagramme de séquence Nous illustrons par la figure 6.12 comment se déroule l’authentification dans notre système à travers le diagramme de séquence. 56
  69. 69. Chapitre 6. Release 2 Figure 6.11: Diagramme de séquence d’authentification Nous illustrons par la figure 6.12 comment se déroule la récupération de données dans notre système à travers le diagramme de séquence. 57
  70. 70. Chapitre 6. Release 2 Figure 6.12: Diagramme de séquence récupérer les sources 6.4 Réalisation Durant la réalisation de chaque sprint dans notre projet, nous passons par deux phases : développement de la partie backend et ensuite, la partie frontend. Nous créons dans un premier temps notre base de données, nous implémentons la logique métier de notre application afin d’exposer, dans 58
  71. 71. Chapitre 6. Release 2 un second temps, la partie de la REST Api correspondante qui sera consommée par la suite par le frontend. 6.4.1 Coté backend Pour réaliser les fonctionnalités requises pour ce release, nous avons développé une liste des rôles et des ACL ( Access Control List) afin de vérifier si l’utilisateur est autorisé à effectuer des actions et si les données fournies sont correctes. Nous illustrons dans la figure 6.13 un exemple de permission réalisé : une source ne peut être crée que par un analyste authentifié. Figure 6.13: Exemple de permission Nous illustrons dans la figure 8.2 quelques API réalisés aux cours de ces sprints. Figure 6.14: Exemple d’API réalisés 6.4.2 Coté frontend Dans cette partie nous expliquons et illustrons les captures d’écran des interfaces concernés. 59
  72. 72. Chapitre 6. Release 2 6.4.2.1 Connexion A la première utilisation de l’application passe obligatoirement par l’interface d’authentification. Une fois il est authentifié, et tant qu’il n’a pas fait la déconnexion, la session sera toujours active, cela lui donne l’accès direct à l’application pour les prochaines utilisations. Figure 6.15: Interface de connexion 6.4.2.2 Inscription Si un utilisateur(l’analyste ou le décideur) ne possède pas un compte, il doit le créer. Pour ce fait, il doit entrer l’email et ses informations personnelles. 60
  73. 73. Chapitre 6. Release 2 Figure 6.16: Interfaces d’inscription La figure 6.17 illustre un email contenant un lien de vérification l’inscription. Figure 6.17: vérification de l’inscription 6.4.2.3 Réinitialisation du mot de passe En cas d’oubli de son mot de passe, l’utilisateur peut le réinitialiser via le bouton "mot de passe oublié". Dans ce cas, l’utilisateur est appelé à introduire son adresse e-mail pour recevoir le lien de redirection contenant un AccessToken lui permettant de réinitialiser son mot de passe. 61
  74. 74. Chapitre 6. Release 2 Figure 6.18: Interfaces de réinitialisation du mot de passe La figure 6.19 illustre un email contenant un lien de réinitialisation. Figure 6.19: reset du mot de passe 6.4.2.4 Consultation et modification du profile Un utilisateur connecté peut accéder à son profil et modifier ses informations personnelles. Figure 6.20: Interfaces de consultation et modification du profil 62
  75. 75. Chapitre 6. Release 2 6.4.2.5 Accueil Un utilisateur connecté peut accéder l’interface d’accueil. La figure 6.21 résume les trois fonctionnalités principales : — Récupération les données — Transformation les données — Visualisation les données Figure 6.21: Interfaces d’accueil 6.4.2.6 Liste de sources L’analyste connecté peut accéder l’interface gestion des sources afin d’avoir la possibilité de les consulter. En outre, la même figure 6.22 présente un bouton au coin supérieur droit qui donne la possibilité de créer une nouvelle source comme dans la figure 6.23 Figure 6.22: Interfaces de consultation des sources 63
  76. 76. Chapitre 6. Release 2 Figure 6.23: Interfaces de choisir type de source récupérée 6.4.2.7 Récupération de données L’analyste s’authentifie à son espace et se propose de créer une nouvelle source.Il se rend à l’onglet google analytique connecteur comme le montre 6.24 Après avoir choisir type de source qu’il souhaite de récupérer , il sera ajouté automatiquement à la liste. Figure 6.24: Interfaces de récupération a partir google analytique La figure 6.25 illustre un analyste connecté peut accéder l’interface d’ajoute source à partr REST API Simply CE.Il remplit les informations nécessaire puis valide 64
  77. 77. Chapitre 6. Release 2 Figure 6.25: Interfaces de récupération à partir API REST SimplyCE 6.5 Test L’une des caractéristiques de Scrum qu’à la fin de chaque itération, notre travail doit être intégré, testé et validé afin d’obtenir un incrément du produit final potentiellement livrable. Il existe plusieurs types de Test. Afin de tester notre solution nous avons réalisé des tests d’intégrations coté serveur et des tests unitaires et fonctionnels coté mobile. 6.5.1 Test d’intégration Dans cette partie nous avons testé le bon fonctionnement des API Rest qu’on a implémente aux cours de ce Release. La figure 6.26 présente le résultat de quelques API testés. Figure 6.26: Rapport de quelques tests d’intégration du deuxième Release La figure 6.27 présente le résultat de quelques API testés. 65
  78. 78. Chapitre 6. Release 2 Figure 6.27: Release 2 : Rapport de test d’intégration : Modèle utilisateur 6.5.2 Test unitaire côté front Pour vérifier la logique de nos méthodes développées au cours de ce Release, nous avons réalisé des tests unitaires. La figure 6.28 illustre le résultat de quelques tests réalisés . Figure 6.28: Release 2 : Rapport de quelques tests unitaires 6.5.3 Test fonctionnel côté front Le test fonctionnel est un scénario utilisateur appliqué sur un écran de l’application. Il simule des interactions utilisateurs et fait des vérifications sur les données affichées sur les composants graphiques qui constitue l’interface après le test. Les figures présentent le résultat d’un test fonctionnel réalisé avec protractor dans un scénario d’authentification réussi et dans un scénario d’authentification échoué. 66
  79. 79. Chapitre 6. Release 2 Figure 6.29: Release 2 test fonctionnel : authentification réussi Conclusion Dans ce deuxième release,nous avons livré la deuxième version de notre application qui permet aux analystes de récupérer et de consulter les sources. Nous entamons dans ce qui suit la 3ème release de notre application qui porte sur la gestion des tableau de bord et d’analyse du parcours utilisateurs. 67
  80. 80. Chapitre 7 Release 3 Plan 1 Présentation des sprints du release 3 . . . . . . . . . . . . . . . . . . . . . . 69 2 Spécification fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6 Évaluation des besoins non-fonctionnels . . . . . . . . . . . . . . . . . . . . . 89
  • RihabMechergui

    Nov. 15, 2020
  • MarvelEKOUERE

    May. 11, 2020
  • ayoub_neo

    Jan. 25, 2020
  • aminaAddali

    May. 1, 2019
  • AnisMesrati

    Mar. 30, 2018

Rapport PFE ISI

Vues

Nombre de vues

7 390

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

24

Actions

Téléchargements

484

Partages

0

Commentaires

0

Mentions J'aime

5

×