Rapport pfe isi_Big data Analytique

République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientiﬁque
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 ﬁn 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 conﬁance 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éciﬁcation 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 ﬁgures
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.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
vii

Table des figures
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.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
ix

Liste des tableaux
2.1 Comparaison entre les diﬀé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 = UniﬁedModeling 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 oﬀertes 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

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

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

— 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

— 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

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 diﬀérents
concepts qui touchent à ce projet.
9

Chapitre 2
ÉTUDE PRÉALABLE
Plan
1 Déﬁnition 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

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

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

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 diﬀérents logiciels existants de Web
Analytique.
Nous distinguons diﬀé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

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

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

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

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

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 ﬁgure 5.2 présente une maquette de la navigation principale d’un utilisateur.
Ces prototypes décrivent les grandes lignes des interfaces. La solution ﬁnale ne sera pas totalement
21

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

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

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

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

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

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

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

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’aﬃchage 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 aﬃcher 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

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

Figure 4.6: ArchitectureMVVM
[23]
La ﬁgure 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éciﬁque. 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

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 oﬀre 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

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

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 ﬁabilité 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 ﬁgure 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

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

5.3.3 Backlog sprint 2
Nous introduisons à travers la figure 5.4 le backlog du sprint2.
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

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

• 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

Nous illustrons par la figure 8.4 quelques bouts de code que nous avons injectés sur la plate-forme.
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

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

Figure 5.10: schéma de construction les indicateurs clés de performance
Le schéma 5.11 ci-dessus résume donc les diﬀé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 conﬁguré 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

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éciﬁcation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

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

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

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’authentiﬁcation et de l’inscription d’un utilisateur,
nous illustrons les diagrammes de séquence système de ces deux fonctionnalités.
50

6.2.2.1 Authentiﬁcation d’un utilisateur
Figure 6.6: Diagramme de séquence système « S’authentiﬁer »
51

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

Titre Réinitialisation du mot de passe
Acteur Utilisateur non authentiﬁé.
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 modiﬁé 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

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

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 diﬀérents éléments
d’un projet. chaque paquetage permet de regrouper un ensemble d’éléments une même appellation
(namespace) .
La ﬁgure 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

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

Figure 6.11: Diagramme de séquence d’authentiﬁcation
Nous illustrons par la ﬁgure 6.12 comment se déroule la récupération de données dans notre
système à travers le diagramme de séquence.
57

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 aﬁn d’exposer, dans
58

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

6.4.2.1 Connexion
A la première utilisation de l’application passe obligatoirement par l’interface d’authentiﬁcation.
Une fois il est authentiﬁé, 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

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

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

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

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’authentiﬁe à 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 ﬁgure 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

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

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

Figure 6.29: Release 2 test fonctionnel : authentiﬁcation 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éciﬁcation fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6 Évaluation des besoins non-fonctionnels . . . . . . . . . . . . . . . . . . . . . 89

Rapport pfe isi_Big data Analytique

Rapport pfe isi_Big data Analytique

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Rapport pfe isi_Big data Analytique

Semelhante a Rapport pfe isi_Big data Analytique (20)

Rapport pfe isi_Big data Analytique