Yosra ADDALI, profile picture
Téléchargé parYosra ADDALI
22,838 vues

Rapport pfe isi_Big data Analytique

Ce document est un rapport de projet de fin d'études présenté par Yosra Addali pour l'obtention d'un diplôme en génie logiciel et systèmes d'information, axé sur la mise en place d'une solution de tracking et monitoring d'une plateforme SaaS. Il comprend des sections sur le contexte général, l'étude préalable, l'initiation au projet, le lancement, et les différentes phases de développement. L'étudiante remercie ses encadrants et présente les méthodologies agiles utilisées, telles que Scrum, durant son projet réalisé au sein de l'entreprise Devstriker.

Intégrer la présentation

Téléchargé 544 fois
1 / 109
2 / 109
3 / 109
4 / 109
5 / 109
6 / 109
Plus lue
7 / 109
8 / 109
9 / 109
10 / 109
11 / 109
12 / 109
13 / 109
14 / 109
15 / 109
16 / 109
17 / 109
18 / 109
19 / 109
20 / 109
21 / 109
22 / 109
23 / 109
24 / 109
25 / 109
26 / 109
27 / 109
28 / 109
29 / 109
30 / 109
31 / 109
32 / 109
33 / 109
34 / 109
35 / 109
Plus lue
36 / 109
37 / 109
38 / 109
39 / 109
40 / 109
41 / 109
42 / 109
43 / 109
44 / 109
45 / 109
46 / 109
47 / 109
48 / 109
49 / 109
50 / 109
51 / 109
52 / 109
53 / 109
54 / 109
55 / 109
56 / 109
57 / 109
58 / 109
59 / 109
60 / 109
61 / 109
62 / 109
63 / 109
64 / 109
65 / 109
66 / 109
67 / 109
68 / 109
69 / 109
70 / 109
71 / 109
72 / 109
73 / 109
74 / 109
75 / 109
76 / 109
Plus lue
77 / 109
78 / 109
79 / 109
80 / 109
81 / 109
82 / 109
83 / 109
84 / 109
85 / 109
86 / 109
87 / 109
88 / 109
89 / 109
90 / 109
91 / 109
92 / 109
93 / 109
94 / 109
95 / 109
96 / 109
97 / 109
98 / 109
99 / 109
100 / 109
101 / 109
102 / 109
103 / 109
104 / 109
105 / 109
106 / 109
107 / 109
108 / 109
109 / 109
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
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
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
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
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
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
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
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
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
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
Liste des tableaux 2.1 Comparaison entre les différents logiciels de Web Analytique . . . . . . . . . . . . . . . 15 3.1 Acteurs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 x
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Chapitre 3 Initiation au projet Plan 1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 22
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
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
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
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
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
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
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
Chapitre 4 Lancement du projet Plan 1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Chapitre 6. Release 2 6.2.2.1 Authentification d’un utilisateur Figure 6.6: Diagramme de séquence système « S’authentifier » 51
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Chapitre 7. Release 3 Introduction Après avoir présente la release 2, dans ce chapitre nous allons concentrer sur la troisiè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 troisième version du projet qui permet à un décideur authentifié de consulter les statistiques et de créer un tableau du bord personnalisé . 7.1 Présentation des sprints du release 3 Dans cette partie nous présentons les sprints du troisième release. 7.1.1 Objectifs des sprints Les objectifs définis dans les sprints 9,10,11 et 12 sont des objectifs fonctionnels : — La gestion des rôles. — Création une structure. — L’agrégation deux sources. — Création un tableau de bord statique :Parcours utilisateurs — Création un tableau de bord statique :Analyse performance — Création un tableau de bord statique :Analyse e-commerce — Gestion des tableaux de bord. — Création un tableau de bord personnalisée. — Documentation ng2 dnd. — Documentation jasmin. — Documentation chart.js. — R & D algorithme analytique. — Documentation sur les types de tests à réaliser et leurs frameworks. 7.1.2 Le planning des sprints du release 3 Nous présentons le planning des sprints par leurs backlog des sprints. La figure 7.1 présente le backlog du sprint 9. 69
Chapitre 7. Release 3 Figure 7.1: Backlog du sprint 9 La figure 7.2 présente le backlog du sprint 10. Figure 7.2: Backlog du sprint 10 La figure 7.3 présente le backlog du sprint 11. Figure 7.3: Backlog du sprint 11 La figure 7.4 présente le backlog du sprint 12. Figure 7.4: Backlog du sprint 12 7.2 Spécification fonctionnelles La spécification fonctionnelle dans notre cas se traduit par le diagramme des cas d’utilisation d’UML et les diagrammes de séquences système. 70
Chapitre 7. Release 3 7.2.0.1 Diagramme de cas d’utilisation Nous illustrons par les diagrammes ci dessus les cas d’utilisations pour ces sprints. Figure 7.5: Diagramme de cas d’utilisation relatif aux décideurs 71
Chapitre 7. Release 3 Figure 7.6: Diagramme de cas d’utilisation relatif aux analystes 7.2.1 Diagrammes de séquence système Pour mieux comprendre le fonctionnement de gestion des tableaux de bord d’un décideur, nous illustrons les diagrammes de séquence système de ce fonctionnalité. 7.2.1.1 Gérer les tableaux de bord Nous décrivons le cas d’utilisation «Gérer des tableaux de bord» par la description textuelle ci dessous. 72
Chapitre 7. Release 3 Titre Gérer des tableaux de bord Acteur Le décideur. Résumé Ce cas d’utilisation permet au décideur de gérer les tableaux de bord . Précondition Le décideur choisit le tableau de bord consulté. Postcondition Un tableau de bord personnalisé a été crée. Scénario nominal 1. Le décideur sélectionne l’affichage des tableaux de bord. 2. Une liste des tableaux de bord est affichée(personnalisé et prédéfinie). 3.Le décideur clique sur le button créer un nouveau tableau de bord. 4.Le décideur doit saisir les configurations nécessaire pour continuer le flux de création. 5.Le tableau de bord choisi sera ajouté à la liste personnalisée. 6. Dans le cas de suppression, le décideur clique sur le button supprimer. 7.Le système affiche une message de vérifier le choix. 8. Dans le cas consultation, il faut que de cliquer sur le nom de tableau de bord. Scénario d’excéption Si le configuration saisie est invalide, l’utilisateur sera alerté. Description textuelle du cas d’utilisation « Gérer les tableaux de bord » 7.2.1.2 Consulter les statistiques Nous décrivons le cas d’utilisation «Consulter les statistiques» par la description textuelle ci dessous. 73
Chapitre 7. Release 3 Titre Consulter les statistiques Acteur Le décideur. Résumé Ce cas d’utilisation permet au décideur de consulter les statistiques . Précondition Le décideur choisit le tableau de bord consulté. Postcondition Un tableau de bord prédéfinie a été consulté. Scénario nominal 1. Le décideur sélectionne l’affichage des tableaux de bord. 2. Une liste des tableaux de bord est affichée(personnalisé et prédéfinie). 3.Le décideur choisit la statistique qu’il en veut à consulter. 4.Une liste des statistique est affichée. 5.Le décideur avait le droit d’inviter autre décideur via l’email. 6.Le système affiche boite de dialogue. 7.Le décideur saisit l’email. 8. Dans le cas d’exporter les rapport, le décideur clique sur le button télécharger. 9. Le système télécharge le rapport de statistique choisi. Scénario d’excéption Dans le cas ou le décideur ne veut choisir aucune tableau de bord , il peut créer un nouveau tableau de bord. Description textuelle du cas d’utilisation « Consulter les statistiques » 7.3 Conception Nous présentons dans cette section notre conception pour ces sprints du troisième Release. 7.3.1 Diagramme de classe À ce niveau, notre diagramme de classe présenté dans le chapitre précèdent par la figure 7.7 a peu changé. Nous illustrons ce changement par la figure 7.7 74
Chapitre 7. Release 3 Figure 7.7: Diagramme de classe pour troisième release 7.3.2 Diagramme de séquence Nous illustrons par la figure 7.8 le diagramme de séquence du cas d’utilisation "Créer une structure". 75
Chapitre 7. Release 3 Figure 7.8: Diagramme de séquence relatif au cas d’utilisation " Créer une structure " Nous illustrons par la figure 7.9 le diagramme de séquence du cas d’utilisation "Consulter les statistiques ". 76
Chapitre 7. Release 3 Figure 7.9: Diagramme de séquence relatif au cas d’utilisation " Consulter les statistiques " Nous présentons par la figure 7.10 le diagramme de séquence du cas d’utilisation "créer un tableau de bord personnalisé ". Figure 7.10: Diagramme de séquence relatif au cas d’utilisation " créer un tableau de bord personnalisé " 77
Chapitre 7. Release 3 7.3.3 diagramme de déploiement Le diagramme de déploiement est une vue statique qui sert à représenter l’utilisation de l’infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que les relations entre eux. Notre projet n’est pas encore en production mais notre idée se résume par la figure 7.11 qui présente le diagramme de déploiement de notre projet. Figure 7.11: Diagramme de déploiement 7.4 Réalisation Comme nous l’avons fait au cours des précédents sprints, la réalisation de notre projet se déroule en deux étapes : Le développement de la partie backend et ensuite, la partie frontend. Dans cette section, nous présentons notre réalisation aux cours de ces deux parties. 7.4.1 côté backend Pour la réalisation des fonctions requises pour ce Release, nous avons eu besoin de créer un modèle « Dashboard » qui représente le tableau de bord qui permet un décideur de consulter les statistiques. Pour ce fait, nous avons utilisé les relations « hasOne » et « belongsTo » de Loopback. hasOne : Une relation hasOne établit une connexion « un à un » avec un autre modèle, de sorte que chaque instance du modèle déclaré a une instance de l’autre modèle. 78
Chapitre 7. Release 3 belongsTo : Une relation BelongsTo établit une connexion « plusieurs à un » ou « un à un » avec un autre modèle. Chaque instance du modèle déclarant appartient à l’instance de l’autre modèle, alors que le modèle cible peut posséder beaucoup de modèles déclarant. Dans notre cas, un dashboard et son utilisateur sont reliés par les deux relations « hasOne » et « belongsTo » . Après avoir définis tous les modèles et les relations requises, nous avons implémenté nos APIs REST nécessaires. La figure illustre quelques API crées pendant ces deux sprints. Figure 7.12: APIs de gestion des tableaux de bord 7.4.2 Côté frontend Dans cette partie nous illustrons et expliquons les captures d’écran des interfaces réalisés. 7.4.2.1 Création une structure de données L’analyste s’authentifie à son espace et se propose de créer une nouvelle structure afin de consulter la liste.Il se rend à l’onglet "structure". La figure 7.13 illustre la consultation une structure. 79
Chapitre 7. Release 3 Figure 7.13: Interface de consultation des structures Pour la remplir, il faut que de saisir le nom et la date au fur et à mesure puis il doit cliquer sur le bouton ok. La figure 7.14 illustre l’ajout une structure. Figure 7.14: Interface d’ajouter une structure Après avoir créé une structure, il sera ajouté automatiquement à la liste.Puis, il se propose maintenant de consulter les sources pour continuer le flux de la création.Il va choisir l’une des sources parmi la liste afin de glisser dans les zone 1 ou 2. Comme nous pouvons le voir, il dispose ainsi des détails de la source en chaque zone puis, il valide. La figure 7.15 illustre l’agrégation des sources. 80
Chapitre 7. Release 3 Figure 7.15: Interface l’agrégation des sources La figure 7.16 illustre la résultat final de l’agrégation des sources. Figure 7.16: Interface tableau de bord de l’agrégation des sources 7.4.2.2 Consultation des tableau de bord Après l’authentification, le décideur sera rediriger vers le l’interface de base où il sera capable de voir toutes les tableaux de bord qu’il a le droit de consulter. Le décideur peut à tout moment de consulter son tableau de bord pour valider les statistiques ajoutés, les modifier ou les supprimer. La figure 7.17 illustre le tableau de bord de base 81
Chapitre 7. Release 3 Figure 7.17: Interface de consultation des tableaux de bord 7.4.2.3 les tableau de bord prédéfinie Après avoir consulter les tableaux de bord, le décideur peut choisir ce qu’il veut d’analyser. Dés que le décideur choisit tableau de bord d’analyse du comportement utilisateurs, il aura la chance de vérifier l’expérience utilisateurs dans le site Simply club. En fait au lieu de réfléchir et vérifier, il peut consulter les résultats statistiques qui permet de répondre quelque questions analytiques : — Où les visiteurs cliquent-ils ? — Navigation des utlisateurs — Que font les utilisateurs sur le site ? — Y’a-t-il des zones qui canalisent les comportement ? La figure 7.18 illustre cette fonctionnalité. 82
Chapitre 7. Release 3 Figure 7.18: Interface d’analyse du parcours d’utilisateurs C’est une étape très important où le décideur doit suivre les différentes fails,l’ergonomie de site. La figure 7.19 montre des statistiques sur la performance de site Simply Club. Figure 7.19: Interface d’analyse performance La figure 7.20 présente des statistiques sur commerce électronique de site Simply Club. il nous permet de répondre des questions analytiques : — 83
Chapitre 7. Release 3 Figure 7.20: Interface d’analyse e-commerce 7.4.2.4 créer un tableau de bord Le décideur peut à tout moment créer son tableau de bord personnalisée pour valider ses KPI et l’objectif de l’entreprise. En outre, la même figure 7.21 présente un bouton au coin supérieur droit qui donne la possibilité de créer un nouveau tableau de bord comme dans la figure 7.21 Pour continuer le flux de la création, nous allons définir le nom du tableau de bord et son description. La deuxième étape est alors chargé demandant au décideur de définir l’objectif puis, il choisit les métriques et les dimensions. La figure 7.24 contient un exemple de ces paramètres. Figure 7.21: Interface de création tableau du bord De plus, dans la figure 7.22 nous montrons comment le décideur peut d’interagir directement avec l’interface du configuration tableau de bord. 84
Chapitre 7. Release 3 Figure 7.22: Interface de première étape La figure 7.23 montre le décideur aura la chance de donner son avis concernant l’objectif de l’entreprise. Figure 7.23: Interface de deuxième étape À partir de la figure 7.24 exposeront le scénario suivant : • Sélectionnez une période de temps • Sélectionnez les métriques et les dimensions 85
Chapitre 7. Release 3 Figure 7.24: Interface de troisième étape La figure 7.25 montre la validation de création tableau de bord Figure 7.25: Interface l’étape finale 7.4.3 Impact du modèle d’apprentissage sur la mesure du parcours utilisateurs Un projet d’ "analyse l’expérience utilisateurs" commence toujours avec un jeu de données et un problème à résoudre. Une fois le type du problème identifié, la première étape à faire est de découvrir nos données, leur prévenance, leur type, le nombre de variables qu’elles incluent, le nombre d’observation, et bien évidement identifier les variables connues ainsi que les variables à prédire afin de trouver la corrélation entre elles. Dans ce cadre, et pour déterminer l’expérience utilisateurs nous présentons les différents algorithmes d’apprentissage automatique adaptées aux données collectes qui sont : — Map Reduce : Comme nous l’avons mentionné auparavant, nous cherchons à prédire les mots clés touchant les prospects et réussir ;cela permet d’aider le décideur à connaître l’intérêt des utilisateurs. La figure 7.26 illustre que pour une plate-forme Simply Club, les utilisateurs font des recherches sur le produit intitulé A. 86
Chapitre 7. Release 3 Figure 7.26: Interface l’étape finale — K-means : Afin de détecter la navigation fréquente des utilisateurs, il faut classer les pages selon le nombre du vue d’utilisateurs donc l’algorithme K-means permet de déterminer les groupements de pages et cela aidera le décideur à prendre des décisions concernant la position, l’organisation et la priorité des pages. La figure 7.27 illustre la navigation des utilisateurs de la plate-forme Simply Club. Figure 7.27: Classification de navigation des utilisateurs 87
Chapitre 7. Release 3 — algo apriori : pour évaluer ce que les utilisateurs souhaitent acheter, l’algorithme apriori nous permet de fournir un aperçu des produits qui ont tendance à être achetés ensemble et qui sont les plus propices à la promotion. Et dans notre cadre, ça facilitera la prise décision pour l’acteur décideur quand il consulte les statistiques liées aux produits et aux ventes. Nous adaptons ces algorithmes de telle sorte que chacun d’entre eux nous donne la proposition la plus proche selon sa méthode. Nous avons constaté en effet qu’en augmentant la taille de données du modèle d’apprentissage, les propositions de traitement diffèrent et ceci exprime bien que le volume de données a un grand impact sur la prédiction et la précision du résultat(la décision à prendre). 7.5 Test 7.5.1 Test d’unitaire Les tests unitaires permettant de vérifier le fonctionnement de chaque composant logiciel modifié ou nouveau dans des cas de fonctionnement normal, aux limites ou dégradé. Ils s’appuient sur la structure interne du composant (tests "boîte blanche"). Les vérifications portent sur l’initialisation des rubriques, les contrôles de saisie, les règles de gestion, et les messages d’erreur Nous avons effectué quelques tests avec Jasmine Js et Mocka.La figure 7.28 montre le résultat de test réalisé sur le modèle dashboard. Figure 7.28: Release 3 : Rapport de test d’unitaire : Modèle dadhboard La figure 7.29 montre le résultat de quelques test réalisé sur le modèle structure. 88
Chapitre 7. Release 3 Figure 7.29: Release 3 : Rapport de test d’unitaire : Modèle structure 7.5.2 Test intégration côté Front La figure 7.30 montre les résultats de nos tests intégrations. Figure 7.30: Release 3 : Test intégration coté front 7.6 Évaluation des besoins non-fonctionnels Nous montrons dans cette partie, après la réalisation de trois Releases, comment nous avons assuré chacun des besoins non-fonctionnels dans notre application. 1. Sécurité : Dans notre application, les mots de passe sont chiffrés avec la fonction de hashage « bcrypt » avant qu’ils ne soient persisté dans la base de données. Nous avons égalements créer des différents rôles pour notre application avec des différentes permissions. 2. Maintenance : L’utilisation de l’architecture MVVM facilite la maintenance et assure l‘évolutivité de notre application. Notre application est structurée en modules séparés de telle sorte qu’on peut facilement les maintenir ou les réutiliser. 3. Ergonomie de l’interface : Notre application, comme la montrent les captures d’écrans illustrés précédemment, est simple et facile 89
Chapitre 7. Release 3 à utiliser. Conclusion Dans ce troisième release, nous avons développé, testé et validé les fonctionnalités de base requises pour la gestion des tableau de bord et du prédire du comportement utilisateurs. Notre produit est maintenant livrable avec trois modules complets. 90
Conclusion générale La plateforme «SimplyCE» présente un enjeu stratégique pour l’entreprise Devstriker. En effet, cette solution est en pleine expansion et collabore avec plusieurs grandes compagnies à l’échelle internationale. Notre projet de fin d’études, effectué au sein de Devstriker, a comme finalité de faire le suivi de cette plateforme et de concevoir et mettre en place un outil d’analyse. Ce projet répond à un besoin réel de Devstriker qui vise à visualiser la grande image les données générées par les ressources de l’entreprise et de fournir à ses décideurs un aperçu approfondi valeurs traitées et même de les aider dans la phase de prise de décision. Le présent manuscrit détaille toutes les étapes par lesquelles nous sommes passés pour arriver au résultat obtenu. Nous avons commencé dans un premier lieu par la collecte de données de notre application, puis l’identification les différentes exigences de notre futur système. Nous avons préparé aussi notre planning de travail en respectant les priorités de nos besoins suite à une profonde analyse. Sur le plan technique, nous avons mis en place dés le début une architecture basée sur des couches faiblement couplées. Et bien évidement, nous étions responsables dans nos choix technologiques et architecturaux tout au long du projet grace à une etude comparative approfondie. Par la suite, nous avons appliqué la méthodologie SCRUM qui nous a permis de contrôler le cycle de vie du développement de la solution tout en respectant les bonnes pratiques. Finalement, notre travail ne s’arrête pas à ce niveau, nous allons continuer à travailler sur la prédiction. 91
Bibliographie [1] M. Shell. (Jan. 2014). simplyce. [Accès le 5-Février-2017], adresse : http://http://www. simplyce.fr/. [2] L. Florent.m, Guide de d emarrage scrmu, http://www.agiliste.fr/, [En ligne ; consulté le 15-mars-2017]. [3] Résumé de Scrum, http://www.n-axis.in/methodologies-agile.php, [En ligne ; consulté le 15-février-2017]. [4] L’évolution du Digital Analytics depuis 1993 jusqu’aujourd’hui, http://www.web-alliance.fr/, [En ligne ; consulté le 05-Février-2017]. [5] Présentation de l’outil VersionOne, https://www.versionone.com/, [En ligne ; consulté le 20-mars-2017]. [6] NodeJS architecture, http://www.dotnettricks.com/learn/nodejs/exploring- nodejs- code-execution-process, [En ligne ; consulté le 01-mars-2017]. [7] R. Sanchez, Comparing Node.js vs PHP Performance, http://www.hostingadvice.com/blog/ comparing-node-js-vs-php-performance/, [En ligne ; consulté le 01-mars-2017]. [8] S. M. S. Primer, « SQL vs NoSQL », [En ligne ; consulté le 15-mars-2017]. [9] MongoDB and MySQL Compared, https://www.mongodb.com/compare/mongodb-mysql, [En ligne ; consulté le 05-mars-2017]. [10] openclassrooms, « Les services web », 2017, [En ligne ; consulté le 20-avril-2017]. [11] REST API : What is it, and what are its advantages in project development ?, https : / / bbvaopen4u.com/en/actualidad/rest- api- what- it- and- what- are- its- advantages- project-development, [En ligne ; consulté le 20-avril-2017]. [12] Designer une API REST, http://blog.octo.com/designer- une- api- rest/, [En ligne ; consulté le 20-avril-2017]. [13] The Fundamentals of REST API Design, https://stormpath.com/blog/fundamentals-rest- api-design, [En ligne ; consulté le 20-avril-2017]. [14] Why LoopBack Is Better Than Express.js ?, https://da-14.com/blog/why-loopback-better- expressjs, [En ligne ; consulté le 05-avril-2017]. [15] Comparing Express, Restify, hapi and LoopBack for building RESTful API, https://strongloop. com/strongblog/compare-express-restify-hapi-loopback/, [En ligne ; consulté le 05-avril-2017]. 92
Bibliographie [16] Angular 4, https://http://angular.io/, [En ligne ; consulté le 05-avril-2017]. [17] React.js, https://reactjs.net/, [En ligne ; consulté le 05-avril-2017]. [18] Courbe deperformanceReactVSAngular, https://fr.vuejs.org/v2/guide/comparison.html, [En ligne ; consulté le 05-avril-2017]. [19] Mocha Js, https://mochajs.org/, [En ligne ; consulté le 20-avril-2017]. [20] Jasmine, https://jasmine.github.io/, [En ligne ; consulté le 20-avril-2017]. [21] protractor, http://www.protractortest.org/#/, [En ligne ; consulté le 20-avril-2017]. [22] A. Dhwaj, « Design Pattern : MVC vs. MVP vs. MVVM », 2015, [En ligne ; consulté le 10-avril-2017]. [23] ArchitectureMVVM, https://fr.vuejs.org/v2/guide/comparison.html, [En ligne ; consulté le 05-avril-2017]. [24] API Google Analytique, https://developers.google.com/analytics/, [En ligne ; consulté le 05-Février-2017]. [25] API Google Analytique, https://developers.google.com/analytics/, [En ligne ; consulté le 05-Février-2017]. [26] KPI, http://www.web-alliance.fr/, [En ligne ; consulté le 15-Avril-2017]. 93
Annexes Annexe 1. Nous illustrons par la figure 8.1 le code injecté qui permet de capturer le nombre d’échec connexion ainsi le nombre de réussite. Figure 8.1: Bouts de code injectés Nous illustrons par la figure 8.2 quelques bouts de codes que nous avons injectés sur la plate-forme simply club qui permet de mesurer le temps resté à chaque page. Figure 8.2: Bouts de code injectés Nous illustrons par la figure 8.3 quelques bouts de codes que nous avons détecté l’exception sur la plate-forme. Figure 8.3: Bouts de code injectés 94
Annexes Nous illustrons par la figure 8.4 quelques bouts de codes que nous avons détecté l’ajout des produits au panier. Figure 8.4: Bouts de code injectés Nous illustrons par la figure 8.5 quelques bouts de codes que nous avons collecte dédiée les actions utilisateurs sur la plate-forme simply club. Figure 8.5: Bouts de code injectés 95
' ' . . : Résumé Ce projet intitulé "Mise en place d’une solution de tracking et monitoring d’une plate-forme SaaS", a été réalise au sein de l’entreprise Devstriker sur une période de six mois. L’objectif de ce projet est d’une part de collecter les données qui permettent d’analyser le com- portement utilisateurs existant sur la plate-forme SimplyCE et d’une autre part la mise en place d’un outil d’analyse de cette plate-forme. Cet outil permettra d’analyser les comportements des visiteurs, de définir leurs intérêts et d’analyser le volet de commerce électronique. Mots clés : Google Analytics, Web analytique, Big Data,Data Tracking/Monitoring, Digital Marke- ting,Agile Abstract This project, entitled "Setting up a tracking/monitoring solution of a SaaS platefome", was carried out within the company Devstriker over a period of six months. The objective of this project is to collect the data that allows to analyze the user behavior existing on the platform SimplyCE and on the other hand the setting up of an analysis tool of this platform. This tool will analyze visitor behaviours, define their interests and analyze the e-commerce component. Keywords : Google Analytics, Web analytique, Big Data,Data Tracking/Monitoring, Digital Market- ing,AgileLoopback direction@devstriker.com : 23 719 302 : 71 111 111 : Rue du Lac Malaren, Les Berges du Lac 1053 Tunis Tél : 71 111 111 Fax : 23 719 302 Email : direction@devstriker.com isi@isim.rnu.tn : 71 706 698 : 71 706 164 : 2080 2 2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@isim.rnu.tn

Contenu connexe

PDF
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
parYasmine Lachheb
 
PDF
Rapport PFE Ilef Ben Slima
parIlef Ben Slima
 
PDF
RapportPFE_IngenieurInformatique_ESPRIT
parLina Meddeb
 
PDF
iRecruite
parDonia Hammami
 
PDF
rapport PFE ingénieur génie logiciel INSAT
parSiwar GUEMRI
 
PDF
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
parSalma Gouia
 
PDF
Rapport de stage de fin d'études ISI 2015
parAnouar Kacem
 
PDF
Plateforme de gestion des projets de fin d'études
parMajdi SAIBI
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
parYasmine Lachheb
 
Rapport PFE Ilef Ben Slima
parIlef Ben Slima
 
RapportPFE_IngenieurInformatique_ESPRIT
parLina Meddeb
 
iRecruite
parDonia Hammami
 
rapport PFE ingénieur génie logiciel INSAT
parSiwar GUEMRI
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
parSalma Gouia
 
Rapport de stage de fin d'études ISI 2015
parAnouar Kacem
 
Plateforme de gestion des projets de fin d'études
parMajdi SAIBI
 

Tendances

PDF
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
parSofien Benrhouma
 
PDF
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
parMohamed Amine Mahmoudi
 
PDF
Rapport de projet de fin d"études
parMohamed Boubaya
 
PDF
Rapport de projet de conception et de développement
parDonia Hammami
 
PDF
Rapport de projet de fin d'étude licence informatique et multimédia
parNazih Heni
 
PDF
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
parNawres Farhat
 
PDF
rapport de projet de fin d'étude_PFE
parDonia Hammami
 
PDF
Rapport pfe talan_2018_donia_hammami
parDonia Hammami
 
PDF
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
parRaoua Bennasr
 
PDF
Rapport stage pfe
parrimeh moussi
 
PDF
Pfe conception et développement d'une application web GMAO JEE
parOussama Djerba
 
PDF
Pfe conception et réalisation d'une application de gestion des processus d'ac...
parAhmed Makni
 
PDF
Rapport- Conception et réalisation d'une plateforme social learning
parRouâa Ben Hammouda
 
PDF
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
parHajer Dahech
 
PDF
Rapport de stage PFE - Mémoire master: Développement d'une application Android
parBadrElattaoui
 
DOCX
Rapport de PFE
parGhizlane ALOZADE
 
PPTX
Ma présentation PFE : Application Android & Site Web
parHarrathi Mohamed
 
PDF
La spécification des besoins
parIsmahen Traya
 
PPT
présentation soutenance PFE.ppt
parMohamed Ben Bouzid
 
PPTX
Conception et Réalisation d’une Plateforme Web de Gestion des achats
parAyed CHOKRI
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
parSofien Benrhouma
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
parMohamed Amine Mahmoudi
 
Rapport de projet de fin d"études
parMohamed Boubaya
 
Rapport de projet de conception et de développement
parDonia Hammami
 
Rapport de projet de fin d'étude licence informatique et multimédia
parNazih Heni
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
parNawres Farhat
 
rapport de projet de fin d'étude_PFE
parDonia Hammami
 
Rapport pfe talan_2018_donia_hammami
parDonia Hammami
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
parRaoua Bennasr
 
Rapport stage pfe
parrimeh moussi
 
Pfe conception et développement d'une application web GMAO JEE
parOussama Djerba
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
parAhmed Makni
 
Rapport- Conception et réalisation d'une plateforme social learning
parRouâa Ben Hammouda
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
parHajer Dahech
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
parBadrElattaoui
 
Rapport de PFE
parGhizlane ALOZADE
 
Ma présentation PFE : Application Android & Site Web
parHarrathi Mohamed
 
La spécification des besoins
parIsmahen Traya
 
présentation soutenance PFE.ppt
parMohamed Ben Bouzid
 
Conception et Réalisation d’une Plateforme Web de Gestion des achats
parAyed CHOKRI
 

Similaire à Rapport pfe isi_Big data Analytique

PDF
Conception et développement d'une marketplace basée sur l'architecture micros...
parAdem Amen Allah Thabti
 
PDF
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
parmouafekmazia
 
PDF
Rapport Projet de Fin d'Etudes
parHosni Mansour
 
PDF
Masters, Rapport de projet de fin d'étude de Conception et développement d’un...
parmouafekmazia
 
PDF
Outpatient Department System (OPD)
parBen Ahmed Zohra
 
PDF
Conception et développement d'une application de gestion de production et de ...
parMohamed Aziz Chetoui
 
PDF
Gestion des actifs applicatifs
parSafaAballagh
 
PDF
Conception et réalisation d’un Système d’information des étudiants du départe...
parIlyas CHAOUA
 
PDF
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
paryounes elmorabit
 
PDF
pfe_rapport_poste_licence_LFIG.pdf
parnesrine haloui
 
PDF
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
parMohammed JAITI
 
PDF
Belwafi bilel
parBelwafi Bilel
 
PDF
Belwafi bilel
parBelwafi Bilel
 
PDF
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
parHoussem Eddine Jebri
 
PDF
Fourth year internship report
parSlimane Akaliâ , سليمان أقليع
 
PDF
Rapport_PFE_Seifeddine_ABIDI_ESPRIT_24/25
parSeifeddine ABIDI
 
PDF
rapport pfe: Solution de réservation une table dans un restaurants
parbarbourafedia1
 
PDF
Rapport du pfe (application Web de gestion des annonces scolaires)
parAbderahman Ouzzani chahdie
 
DOCX
PFE :: Application de gestion des dus d'enseignement
parNassim Bahri
 
PPTX
rapport-pfa-2020-s1-gshshsgbfhsdgsbhshbss.pptx
parHelmiBabay
 
Conception et développement d'une marketplace basée sur l'architecture micros...
parAdem Amen Allah Thabti
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
parmouafekmazia
 
Rapport Projet de Fin d'Etudes
parHosni Mansour
 
Masters, Rapport de projet de fin d'étude de Conception et développement d’un...
parmouafekmazia
 
Outpatient Department System (OPD)
parBen Ahmed Zohra
 
Conception et développement d'une application de gestion de production et de ...
parMohamed Aziz Chetoui
 
Gestion des actifs applicatifs
parSafaAballagh
 
Conception et réalisation d’un Système d’information des étudiants du départe...
parIlyas CHAOUA
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
paryounes elmorabit
 
pfe_rapport_poste_licence_LFIG.pdf
parnesrine haloui
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
parMohammed JAITI
 
Belwafi bilel
parBelwafi Bilel
 
Belwafi bilel
parBelwafi Bilel
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
parHoussem Eddine Jebri
 
Fourth year internship report
parSlimane Akaliâ , سليمان أقليع
 
Rapport_PFE_Seifeddine_ABIDI_ESPRIT_24/25
parSeifeddine ABIDI
 
rapport pfe: Solution de réservation une table dans un restaurants
parbarbourafedia1
 
Rapport du pfe (application Web de gestion des annonces scolaires)
parAbderahman Ouzzani chahdie
 
PFE :: Application de gestion des dus d'enseignement
parNassim Bahri
 
rapport-pfa-2020-s1-gshshsgbfhsdgsbhshbss.pptx
parHelmiBabay
 

Dernier

PDF
Optimisation de la gestion de stocks et de la planification des approvisionne...
parYounes Nokri
 
PPTX
Support de cours systèmes embarqués.pptx
parbensaidyosr898
 
PPTX
Le cours est inspirée du livre ‘clean agile’ de Robert C. Martin, un des fond...
parbatanga1
 
PPTX
Présentation du comité technique ITB Somme/Oise 2026 implantation.pptx
parInstitut Technique de la Betterave
 
PPTX
Présentation du comité technique ITB Somme/Oise 2026 Azote.pptx
parInstitut Technique de la Betterave
 
PPTX
Présentation du comité technique ITB Somme/OIie 2026 protection fongicide.pptx
parInstitut Technique de la Betterave
 
PPTX
Présentation du comité technique ITB Somme/Oise 2026 désherbage dicots.pptx
parInstitut Technique de la Betterave
 
PDF
cours EIE 2020.pdf presentation environement
parhafssabenmachi
 
PDF
1-Définition des structures de chaussées.pdf
parELOUAFYABDERRAHIM
 
Optimisation de la gestion de stocks et de la planification des approvisionne...
parYounes Nokri
 
Support de cours systèmes embarqués.pptx
parbensaidyosr898
 
Le cours est inspirée du livre ‘clean agile’ de Robert C. Martin, un des fond...
parbatanga1
 
Présentation du comité technique ITB Somme/Oise 2026 implantation.pptx
parInstitut Technique de la Betterave
 
Présentation du comité technique ITB Somme/Oise 2026 Azote.pptx
parInstitut Technique de la Betterave
 
Présentation du comité technique ITB Somme/OIie 2026 protection fongicide.pptx
parInstitut Technique de la Betterave
 
Présentation du comité technique ITB Somme/Oise 2026 désherbage dicots.pptx
parInstitut Technique de la Betterave
 
cours EIE 2020.pdf presentation environement
parhafssabenmachi
 
1-Définition des structures de chaussées.pdf
parELOUAFYABDERRAHIM
 

Rapport pfe isi_Big data Analytique

  • 1.
    République Tunisienne Ministère del’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
  • 3.
    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
  • 4.
    Dédicaces Je dédie cemodeste 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
  • 5.
    Remerciements Au terme demon 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
  • 6.
    Table des matières Introductiongé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
  • 7.
    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
  • 8.
    6.3.3 Diagramme declasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
  • 9.
    Table des figures 1.1Logo 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
  • 10.
    Table des figures 6.4Backlog 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
  • 11.
    7.8 Diagramme desé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
  • 12.
    Liste des tableaux 2.1Comparaison entre les différents logiciels de Web Analytique . . . . . . . . . . . . . . . 15 3.1 Acteurs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 x
  • 13.
    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
  • 14.
    Introduction générale En faveurde 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
  • 15.
    Introduction générale et leseptiè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
  • 16.
    Chapitre 1 Contexte général Plan 1Organisme 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
  • 17.
    Chapitre 1. Contextegé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
  • 18.
    Chapitre 1. Contextegé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
  • 19.
    Chapitre 1. Contextegé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
  • 20.
    Chapitre 1. Contextegé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
  • 21.
    Chapitre 1. Contextegé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
  • 22.
    Chapitre 1. Contextegé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
  • 23.
    Chapitre 2 ÉTUDE PRÉALABLE Plan 1Définition quelque concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2 Big Data et marketing : les opportunités pour l’entreprise . . . . . . . . . 12 3 Les logiciels de Web Analytique . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  • 24.
    Chapitre 2. ÉTUDEPRÉ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
  • 25.
    Chapitre 2. ÉTUDEPRÉ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
  • 26.
    Chapitre 2. ÉTUDEPRÉ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
  • 27.
    Chapitre 2. ÉTUDEPRÉ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
  • 28.
    Chapitre 2. ÉTUDEPRÉ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
  • 29.
    Chapitre 3 Initiation auprojet Plan 1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 22
  • 30.
    Chapitre 3. Initiationau 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
  • 31.
    Chapitre 3. Initiationau 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
  • 32.
    Chapitre 3. Initiationau 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
  • 33.
    Chapitre 3. Initiationau 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
  • 34.
    Chapitre 3. Initiationau 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
  • 35.
    Chapitre 3. Initiationau 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
  • 36.
    Chapitre 3. Initiationau 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
  • 37.
    Chapitre 4 Lancement duprojet Plan 1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
  • 38.
    Chapitre 4. Lancementdu 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
  • 39.
    Chapitre 4. Lancementdu 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
  • 40.
    Chapitre 4. Lancementdu 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
  • 41.
    Chapitre 4. Lancementdu 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
  • 42.
    Chapitre 4. Lancementdu 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
  • 43.
    Chapitre 4. Lancementdu 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
  • 44.
    Chapitre 4. Lancementdu 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
  • 45.
    Chapitre 4. Lancementdu 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
  • 46.
    Chapitre 4. Lancementdu 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
  • 47.
    Chapitre 4. Lancementdu 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
  • 48.
    Chapitre 4. Lancementdu 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
  • 49.
    Chapitre 5 Release 1 Plan 1Pré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
  • 50.
    Chapitre 5. Release1 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
  • 51.
    Chapitre 5. Release1 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
  • 52.
    Chapitre 5. Release1 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
  • 53.
    Chapitre 5. Release1 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
  • 54.
    Chapitre 5. Release1 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
  • 55.
    Chapitre 5. Release1 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
  • 56.
    Chapitre 5. Release1 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
  • 57.
    Chapitre 5. Release1 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
  • 58.
    Chapitre 5. Release1 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
  • 59.
    Chapitre 5. Release1 utilisé à la phase suivante"étude technique de la collecte". Nous entamons dans ce qui suit la deuxième release de notre application. 46
  • 60.
    Chapitre 6 Release 2 Plan 1Présentation des sprints du release 2 . . . . . . . . . . . . . . . . . . . . . . . 48 2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
  • 61.
    Chapitre 6. Release2 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
  • 62.
    Chapitre 6. Release2 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
  • 63.
    Chapitre 6. Release2 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
  • 64.
    Chapitre 6. Release2 6.2.2.1 Authentification d’un utilisateur Figure 6.6: Diagramme de séquence système « S’authentifier » 51
  • 65.
    Chapitre 6. Release2 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
  • 66.
    Chapitre 6. Release2 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
  • 67.
    Chapitre 6. Release2 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
  • 68.
    Chapitre 6. Release2 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
  • 69.
    Chapitre 6. Release2 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
  • 70.
    Chapitre 6. Release2 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
  • 71.
    Chapitre 6. Release2 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
  • 72.
    Chapitre 6. Release2 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
  • 73.
    Chapitre 6. Release2 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
  • 74.
    Chapitre 6. Release2 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
  • 75.
    Chapitre 6. Release2 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
  • 76.
    Chapitre 6. Release2 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
  • 77.
    Chapitre 6. Release2 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
  • 78.
    Chapitre 6. Release2 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
  • 79.
    Chapitre 6. Release2 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
  • 80.
    Chapitre 6. Release2 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
  • 81.
    Chapitre 7 Release 3 Plan 1Pré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
  • 82.
    Chapitre 7. Release3 Introduction Après avoir présente la release 2, dans ce chapitre nous allons concentrer sur la troisiè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 troisième version du projet qui permet à un décideur authentifié de consulter les statistiques et de créer un tableau du bord personnalisé . 7.1 Présentation des sprints du release 3 Dans cette partie nous présentons les sprints du troisième release. 7.1.1 Objectifs des sprints Les objectifs définis dans les sprints 9,10,11 et 12 sont des objectifs fonctionnels : — La gestion des rôles. — Création une structure. — L’agrégation deux sources. — Création un tableau de bord statique :Parcours utilisateurs — Création un tableau de bord statique :Analyse performance — Création un tableau de bord statique :Analyse e-commerce — Gestion des tableaux de bord. — Création un tableau de bord personnalisée. — Documentation ng2 dnd. — Documentation jasmin. — Documentation chart.js. — R & D algorithme analytique. — Documentation sur les types de tests à réaliser et leurs frameworks. 7.1.2 Le planning des sprints du release 3 Nous présentons le planning des sprints par leurs backlog des sprints. La figure 7.1 présente le backlog du sprint 9. 69
  • 83.
    Chapitre 7. Release3 Figure 7.1: Backlog du sprint 9 La figure 7.2 présente le backlog du sprint 10. Figure 7.2: Backlog du sprint 10 La figure 7.3 présente le backlog du sprint 11. Figure 7.3: Backlog du sprint 11 La figure 7.4 présente le backlog du sprint 12. Figure 7.4: Backlog du sprint 12 7.2 Spécification fonctionnelles La spécification fonctionnelle dans notre cas se traduit par le diagramme des cas d’utilisation d’UML et les diagrammes de séquences système. 70
  • 84.
    Chapitre 7. Release3 7.2.0.1 Diagramme de cas d’utilisation Nous illustrons par les diagrammes ci dessus les cas d’utilisations pour ces sprints. Figure 7.5: Diagramme de cas d’utilisation relatif aux décideurs 71
  • 85.
    Chapitre 7. Release3 Figure 7.6: Diagramme de cas d’utilisation relatif aux analystes 7.2.1 Diagrammes de séquence système Pour mieux comprendre le fonctionnement de gestion des tableaux de bord d’un décideur, nous illustrons les diagrammes de séquence système de ce fonctionnalité. 7.2.1.1 Gérer les tableaux de bord Nous décrivons le cas d’utilisation «Gérer des tableaux de bord» par la description textuelle ci dessous. 72
  • 86.
    Chapitre 7. Release3 Titre Gérer des tableaux de bord Acteur Le décideur. Résumé Ce cas d’utilisation permet au décideur de gérer les tableaux de bord . Précondition Le décideur choisit le tableau de bord consulté. Postcondition Un tableau de bord personnalisé a été crée. Scénario nominal 1. Le décideur sélectionne l’affichage des tableaux de bord. 2. Une liste des tableaux de bord est affichée(personnalisé et prédéfinie). 3.Le décideur clique sur le button créer un nouveau tableau de bord. 4.Le décideur doit saisir les configurations nécessaire pour continuer le flux de création. 5.Le tableau de bord choisi sera ajouté à la liste personnalisée. 6. Dans le cas de suppression, le décideur clique sur le button supprimer. 7.Le système affiche une message de vérifier le choix. 8. Dans le cas consultation, il faut que de cliquer sur le nom de tableau de bord. Scénario d’excéption Si le configuration saisie est invalide, l’utilisateur sera alerté. Description textuelle du cas d’utilisation « Gérer les tableaux de bord » 7.2.1.2 Consulter les statistiques Nous décrivons le cas d’utilisation «Consulter les statistiques» par la description textuelle ci dessous. 73
  • 87.
    Chapitre 7. Release3 Titre Consulter les statistiques Acteur Le décideur. Résumé Ce cas d’utilisation permet au décideur de consulter les statistiques . Précondition Le décideur choisit le tableau de bord consulté. Postcondition Un tableau de bord prédéfinie a été consulté. Scénario nominal 1. Le décideur sélectionne l’affichage des tableaux de bord. 2. Une liste des tableaux de bord est affichée(personnalisé et prédéfinie). 3.Le décideur choisit la statistique qu’il en veut à consulter. 4.Une liste des statistique est affichée. 5.Le décideur avait le droit d’inviter autre décideur via l’email. 6.Le système affiche boite de dialogue. 7.Le décideur saisit l’email. 8. Dans le cas d’exporter les rapport, le décideur clique sur le button télécharger. 9. Le système télécharge le rapport de statistique choisi. Scénario d’excéption Dans le cas ou le décideur ne veut choisir aucune tableau de bord , il peut créer un nouveau tableau de bord. Description textuelle du cas d’utilisation « Consulter les statistiques » 7.3 Conception Nous présentons dans cette section notre conception pour ces sprints du troisième Release. 7.3.1 Diagramme de classe À ce niveau, notre diagramme de classe présenté dans le chapitre précèdent par la figure 7.7 a peu changé. Nous illustrons ce changement par la figure 7.7 74
  • 88.
    Chapitre 7. Release3 Figure 7.7: Diagramme de classe pour troisième release 7.3.2 Diagramme de séquence Nous illustrons par la figure 7.8 le diagramme de séquence du cas d’utilisation "Créer une structure". 75
  • 89.
    Chapitre 7. Release3 Figure 7.8: Diagramme de séquence relatif au cas d’utilisation " Créer une structure " Nous illustrons par la figure 7.9 le diagramme de séquence du cas d’utilisation "Consulter les statistiques ". 76
  • 90.
    Chapitre 7. Release3 Figure 7.9: Diagramme de séquence relatif au cas d’utilisation " Consulter les statistiques " Nous présentons par la figure 7.10 le diagramme de séquence du cas d’utilisation "créer un tableau de bord personnalisé ". Figure 7.10: Diagramme de séquence relatif au cas d’utilisation " créer un tableau de bord personnalisé " 77
  • 91.
    Chapitre 7. Release3 7.3.3 diagramme de déploiement Le diagramme de déploiement est une vue statique qui sert à représenter l’utilisation de l’infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que les relations entre eux. Notre projet n’est pas encore en production mais notre idée se résume par la figure 7.11 qui présente le diagramme de déploiement de notre projet. Figure 7.11: Diagramme de déploiement 7.4 Réalisation Comme nous l’avons fait au cours des précédents sprints, la réalisation de notre projet se déroule en deux étapes : Le développement de la partie backend et ensuite, la partie frontend. Dans cette section, nous présentons notre réalisation aux cours de ces deux parties. 7.4.1 côté backend Pour la réalisation des fonctions requises pour ce Release, nous avons eu besoin de créer un modèle « Dashboard » qui représente le tableau de bord qui permet un décideur de consulter les statistiques. Pour ce fait, nous avons utilisé les relations « hasOne » et « belongsTo » de Loopback. hasOne : Une relation hasOne établit une connexion « un à un » avec un autre modèle, de sorte que chaque instance du modèle déclaré a une instance de l’autre modèle. 78
  • 92.
    Chapitre 7. Release3 belongsTo : Une relation BelongsTo établit une connexion « plusieurs à un » ou « un à un » avec un autre modèle. Chaque instance du modèle déclarant appartient à l’instance de l’autre modèle, alors que le modèle cible peut posséder beaucoup de modèles déclarant. Dans notre cas, un dashboard et son utilisateur sont reliés par les deux relations « hasOne » et « belongsTo » . Après avoir définis tous les modèles et les relations requises, nous avons implémenté nos APIs REST nécessaires. La figure illustre quelques API crées pendant ces deux sprints. Figure 7.12: APIs de gestion des tableaux de bord 7.4.2 Côté frontend Dans cette partie nous illustrons et expliquons les captures d’écran des interfaces réalisés. 7.4.2.1 Création une structure de données L’analyste s’authentifie à son espace et se propose de créer une nouvelle structure afin de consulter la liste.Il se rend à l’onglet "structure". La figure 7.13 illustre la consultation une structure. 79
  • 93.
    Chapitre 7. Release3 Figure 7.13: Interface de consultation des structures Pour la remplir, il faut que de saisir le nom et la date au fur et à mesure puis il doit cliquer sur le bouton ok. La figure 7.14 illustre l’ajout une structure. Figure 7.14: Interface d’ajouter une structure Après avoir créé une structure, il sera ajouté automatiquement à la liste.Puis, il se propose maintenant de consulter les sources pour continuer le flux de la création.Il va choisir l’une des sources parmi la liste afin de glisser dans les zone 1 ou 2. Comme nous pouvons le voir, il dispose ainsi des détails de la source en chaque zone puis, il valide. La figure 7.15 illustre l’agrégation des sources. 80
  • 94.
    Chapitre 7. Release3 Figure 7.15: Interface l’agrégation des sources La figure 7.16 illustre la résultat final de l’agrégation des sources. Figure 7.16: Interface tableau de bord de l’agrégation des sources 7.4.2.2 Consultation des tableau de bord Après l’authentification, le décideur sera rediriger vers le l’interface de base où il sera capable de voir toutes les tableaux de bord qu’il a le droit de consulter. Le décideur peut à tout moment de consulter son tableau de bord pour valider les statistiques ajoutés, les modifier ou les supprimer. La figure 7.17 illustre le tableau de bord de base 81
  • 95.
    Chapitre 7. Release3 Figure 7.17: Interface de consultation des tableaux de bord 7.4.2.3 les tableau de bord prédéfinie Après avoir consulter les tableaux de bord, le décideur peut choisir ce qu’il veut d’analyser. Dés que le décideur choisit tableau de bord d’analyse du comportement utilisateurs, il aura la chance de vérifier l’expérience utilisateurs dans le site Simply club. En fait au lieu de réfléchir et vérifier, il peut consulter les résultats statistiques qui permet de répondre quelque questions analytiques : — Où les visiteurs cliquent-ils ? — Navigation des utlisateurs — Que font les utilisateurs sur le site ? — Y’a-t-il des zones qui canalisent les comportement ? La figure 7.18 illustre cette fonctionnalité. 82
  • 96.
    Chapitre 7. Release3 Figure 7.18: Interface d’analyse du parcours d’utilisateurs C’est une étape très important où le décideur doit suivre les différentes fails,l’ergonomie de site. La figure 7.19 montre des statistiques sur la performance de site Simply Club. Figure 7.19: Interface d’analyse performance La figure 7.20 présente des statistiques sur commerce électronique de site Simply Club. il nous permet de répondre des questions analytiques : — 83
  • 97.
    Chapitre 7. Release3 Figure 7.20: Interface d’analyse e-commerce 7.4.2.4 créer un tableau de bord Le décideur peut à tout moment créer son tableau de bord personnalisée pour valider ses KPI et l’objectif de l’entreprise. En outre, la même figure 7.21 présente un bouton au coin supérieur droit qui donne la possibilité de créer un nouveau tableau de bord comme dans la figure 7.21 Pour continuer le flux de la création, nous allons définir le nom du tableau de bord et son description. La deuxième étape est alors chargé demandant au décideur de définir l’objectif puis, il choisit les métriques et les dimensions. La figure 7.24 contient un exemple de ces paramètres. Figure 7.21: Interface de création tableau du bord De plus, dans la figure 7.22 nous montrons comment le décideur peut d’interagir directement avec l’interface du configuration tableau de bord. 84
  • 98.
    Chapitre 7. Release3 Figure 7.22: Interface de première étape La figure 7.23 montre le décideur aura la chance de donner son avis concernant l’objectif de l’entreprise. Figure 7.23: Interface de deuxième étape À partir de la figure 7.24 exposeront le scénario suivant : • Sélectionnez une période de temps • Sélectionnez les métriques et les dimensions 85
  • 99.
    Chapitre 7. Release3 Figure 7.24: Interface de troisième étape La figure 7.25 montre la validation de création tableau de bord Figure 7.25: Interface l’étape finale 7.4.3 Impact du modèle d’apprentissage sur la mesure du parcours utilisateurs Un projet d’ "analyse l’expérience utilisateurs" commence toujours avec un jeu de données et un problème à résoudre. Une fois le type du problème identifié, la première étape à faire est de découvrir nos données, leur prévenance, leur type, le nombre de variables qu’elles incluent, le nombre d’observation, et bien évidement identifier les variables connues ainsi que les variables à prédire afin de trouver la corrélation entre elles. Dans ce cadre, et pour déterminer l’expérience utilisateurs nous présentons les différents algorithmes d’apprentissage automatique adaptées aux données collectes qui sont : — Map Reduce : Comme nous l’avons mentionné auparavant, nous cherchons à prédire les mots clés touchant les prospects et réussir ;cela permet d’aider le décideur à connaître l’intérêt des utilisateurs. La figure 7.26 illustre que pour une plate-forme Simply Club, les utilisateurs font des recherches sur le produit intitulé A. 86
  • 100.
    Chapitre 7. Release3 Figure 7.26: Interface l’étape finale — K-means : Afin de détecter la navigation fréquente des utilisateurs, il faut classer les pages selon le nombre du vue d’utilisateurs donc l’algorithme K-means permet de déterminer les groupements de pages et cela aidera le décideur à prendre des décisions concernant la position, l’organisation et la priorité des pages. La figure 7.27 illustre la navigation des utilisateurs de la plate-forme Simply Club. Figure 7.27: Classification de navigation des utilisateurs 87
  • 101.
    Chapitre 7. Release3 — algo apriori : pour évaluer ce que les utilisateurs souhaitent acheter, l’algorithme apriori nous permet de fournir un aperçu des produits qui ont tendance à être achetés ensemble et qui sont les plus propices à la promotion. Et dans notre cadre, ça facilitera la prise décision pour l’acteur décideur quand il consulte les statistiques liées aux produits et aux ventes. Nous adaptons ces algorithmes de telle sorte que chacun d’entre eux nous donne la proposition la plus proche selon sa méthode. Nous avons constaté en effet qu’en augmentant la taille de données du modèle d’apprentissage, les propositions de traitement diffèrent et ceci exprime bien que le volume de données a un grand impact sur la prédiction et la précision du résultat(la décision à prendre). 7.5 Test 7.5.1 Test d’unitaire Les tests unitaires permettant de vérifier le fonctionnement de chaque composant logiciel modifié ou nouveau dans des cas de fonctionnement normal, aux limites ou dégradé. Ils s’appuient sur la structure interne du composant (tests "boîte blanche"). Les vérifications portent sur l’initialisation des rubriques, les contrôles de saisie, les règles de gestion, et les messages d’erreur Nous avons effectué quelques tests avec Jasmine Js et Mocka.La figure 7.28 montre le résultat de test réalisé sur le modèle dashboard. Figure 7.28: Release 3 : Rapport de test d’unitaire : Modèle dadhboard La figure 7.29 montre le résultat de quelques test réalisé sur le modèle structure. 88
  • 102.
    Chapitre 7. Release3 Figure 7.29: Release 3 : Rapport de test d’unitaire : Modèle structure 7.5.2 Test intégration côté Front La figure 7.30 montre les résultats de nos tests intégrations. Figure 7.30: Release 3 : Test intégration coté front 7.6 Évaluation des besoins non-fonctionnels Nous montrons dans cette partie, après la réalisation de trois Releases, comment nous avons assuré chacun des besoins non-fonctionnels dans notre application. 1. Sécurité : Dans notre application, les mots de passe sont chiffrés avec la fonction de hashage « bcrypt » avant qu’ils ne soient persisté dans la base de données. Nous avons égalements créer des différents rôles pour notre application avec des différentes permissions. 2. Maintenance : L’utilisation de l’architecture MVVM facilite la maintenance et assure l‘évolutivité de notre application. Notre application est structurée en modules séparés de telle sorte qu’on peut facilement les maintenir ou les réutiliser. 3. Ergonomie de l’interface : Notre application, comme la montrent les captures d’écrans illustrés précédemment, est simple et facile 89
  • 103.
    Chapitre 7. Release3 à utiliser. Conclusion Dans ce troisième release, nous avons développé, testé et validé les fonctionnalités de base requises pour la gestion des tableau de bord et du prédire du comportement utilisateurs. Notre produit est maintenant livrable avec trois modules complets. 90
  • 104.
    Conclusion générale La plateforme«SimplyCE» présente un enjeu stratégique pour l’entreprise Devstriker. En effet, cette solution est en pleine expansion et collabore avec plusieurs grandes compagnies à l’échelle internationale. Notre projet de fin d’études, effectué au sein de Devstriker, a comme finalité de faire le suivi de cette plateforme et de concevoir et mettre en place un outil d’analyse. Ce projet répond à un besoin réel de Devstriker qui vise à visualiser la grande image les données générées par les ressources de l’entreprise et de fournir à ses décideurs un aperçu approfondi valeurs traitées et même de les aider dans la phase de prise de décision. Le présent manuscrit détaille toutes les étapes par lesquelles nous sommes passés pour arriver au résultat obtenu. Nous avons commencé dans un premier lieu par la collecte de données de notre application, puis l’identification les différentes exigences de notre futur système. Nous avons préparé aussi notre planning de travail en respectant les priorités de nos besoins suite à une profonde analyse. Sur le plan technique, nous avons mis en place dés le début une architecture basée sur des couches faiblement couplées. Et bien évidement, nous étions responsables dans nos choix technologiques et architecturaux tout au long du projet grace à une etude comparative approfondie. Par la suite, nous avons appliqué la méthodologie SCRUM qui nous a permis de contrôler le cycle de vie du développement de la solution tout en respectant les bonnes pratiques. Finalement, notre travail ne s’arrête pas à ce niveau, nous allons continuer à travailler sur la prédiction. 91
  • 105.
    Bibliographie [1] M. Shell.(Jan. 2014). simplyce. [Accès le 5-Février-2017], adresse : http://http://www. simplyce.fr/. [2] L. Florent.m, Guide de d emarrage scrmu, http://www.agiliste.fr/, [En ligne ; consulté le 15-mars-2017]. [3] Résumé de Scrum, http://www.n-axis.in/methodologies-agile.php, [En ligne ; consulté le 15-février-2017]. [4] L’évolution du Digital Analytics depuis 1993 jusqu’aujourd’hui, http://www.web-alliance.fr/, [En ligne ; consulté le 05-Février-2017]. [5] Présentation de l’outil VersionOne, https://www.versionone.com/, [En ligne ; consulté le 20-mars-2017]. [6] NodeJS architecture, http://www.dotnettricks.com/learn/nodejs/exploring- nodejs- code-execution-process, [En ligne ; consulté le 01-mars-2017]. [7] R. Sanchez, Comparing Node.js vs PHP Performance, http://www.hostingadvice.com/blog/ comparing-node-js-vs-php-performance/, [En ligne ; consulté le 01-mars-2017]. [8] S. M. S. Primer, « SQL vs NoSQL », [En ligne ; consulté le 15-mars-2017]. [9] MongoDB and MySQL Compared, https://www.mongodb.com/compare/mongodb-mysql, [En ligne ; consulté le 05-mars-2017]. [10] openclassrooms, « Les services web », 2017, [En ligne ; consulté le 20-avril-2017]. [11] REST API : What is it, and what are its advantages in project development ?, https : / / bbvaopen4u.com/en/actualidad/rest- api- what- it- and- what- are- its- advantages- project-development, [En ligne ; consulté le 20-avril-2017]. [12] Designer une API REST, http://blog.octo.com/designer- une- api- rest/, [En ligne ; consulté le 20-avril-2017]. [13] The Fundamentals of REST API Design, https://stormpath.com/blog/fundamentals-rest- api-design, [En ligne ; consulté le 20-avril-2017]. [14] Why LoopBack Is Better Than Express.js ?, https://da-14.com/blog/why-loopback-better- expressjs, [En ligne ; consulté le 05-avril-2017]. [15] Comparing Express, Restify, hapi and LoopBack for building RESTful API, https://strongloop. com/strongblog/compare-express-restify-hapi-loopback/, [En ligne ; consulté le 05-avril-2017]. 92
  • 106.
    Bibliographie [16] Angular 4,https://http://angular.io/, [En ligne ; consulté le 05-avril-2017]. [17] React.js, https://reactjs.net/, [En ligne ; consulté le 05-avril-2017]. [18] Courbe deperformanceReactVSAngular, https://fr.vuejs.org/v2/guide/comparison.html, [En ligne ; consulté le 05-avril-2017]. [19] Mocha Js, https://mochajs.org/, [En ligne ; consulté le 20-avril-2017]. [20] Jasmine, https://jasmine.github.io/, [En ligne ; consulté le 20-avril-2017]. [21] protractor, http://www.protractortest.org/#/, [En ligne ; consulté le 20-avril-2017]. [22] A. Dhwaj, « Design Pattern : MVC vs. MVP vs. MVVM », 2015, [En ligne ; consulté le 10-avril-2017]. [23] ArchitectureMVVM, https://fr.vuejs.org/v2/guide/comparison.html, [En ligne ; consulté le 05-avril-2017]. [24] API Google Analytique, https://developers.google.com/analytics/, [En ligne ; consulté le 05-Février-2017]. [25] API Google Analytique, https://developers.google.com/analytics/, [En ligne ; consulté le 05-Février-2017]. [26] KPI, http://www.web-alliance.fr/, [En ligne ; consulté le 15-Avril-2017]. 93
  • 107.
    Annexes Annexe 1. Nous illustronspar la figure 8.1 le code injecté qui permet de capturer le nombre d’échec connexion ainsi le nombre de réussite. Figure 8.1: Bouts de code injectés Nous illustrons par la figure 8.2 quelques bouts de codes que nous avons injectés sur la plate-forme simply club qui permet de mesurer le temps resté à chaque page. Figure 8.2: Bouts de code injectés Nous illustrons par la figure 8.3 quelques bouts de codes que nous avons détecté l’exception sur la plate-forme. Figure 8.3: Bouts de code injectés 94
  • 108.
    Annexes Nous illustrons parla figure 8.4 quelques bouts de codes que nous avons détecté l’ajout des produits au panier. Figure 8.4: Bouts de code injectés Nous illustrons par la figure 8.5 quelques bouts de codes que nous avons collecte dédiée les actions utilisateurs sur la plate-forme simply club. Figure 8.5: Bouts de code injectés 95
  • 109.
    ' ' . . : Résumé Ceprojet intitulé "Mise en place d’une solution de tracking et monitoring d’une plate-forme SaaS", a été réalise au sein de l’entreprise Devstriker sur une période de six mois. L’objectif de ce projet est d’une part de collecter les données qui permettent d’analyser le com- portement utilisateurs existant sur la plate-forme SimplyCE et d’une autre part la mise en place d’un outil d’analyse de cette plate-forme. Cet outil permettra d’analyser les comportements des visiteurs, de définir leurs intérêts et d’analyser le volet de commerce électronique. Mots clés : Google Analytics, Web analytique, Big Data,Data Tracking/Monitoring, Digital Marke- ting,Agile Abstract This project, entitled "Setting up a tracking/monitoring solution of a SaaS platefome", was carried out within the company Devstriker over a period of six months. The objective of this project is to collect the data that allows to analyze the user behavior existing on the platform SimplyCE and on the other hand the setting up of an analysis tool of this platform. This tool will analyze visitor behaviours, define their interests and analyze the e-commerce component. Keywords : Google Analytics, Web analytique, Big Data,Data Tracking/Monitoring, Digital Market- ing,AgileLoopback direction@devstriker.com : 23 719 302 : 71 111 111 : Rue du Lac Malaren, Les Berges du Lac 1053 Tunis Tél : 71 111 111 Fax : 23 719 302 Email : direction@devstriker.com isi@isim.rnu.tn : 71 706 698 : 71 706 164 : 2080 2 2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@isim.rnu.tn