Académique Documents
Professionnel Documents
Culture Documents
Par
Yosra ADDALI
M.Malek TAZEROUT
Encadrant professionnel : Ingénieur R&D
et Mlle Mayssa MESSAOUDI
Encadrant académique : Maître Assistante
Madame Hela LIMAM
Signature et cachet
J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
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
gratitude envers toutes les personnes qui par leur présence, leur soutien, leur
disponibilité et leurs conseils, j’ai pu accomplir ce projet.
encadrante Madame Hela LIMEM qui a accepté de diriger ce travail, pour ses
conseils précieux, son encouragement continu, sa haute disponibilité, sa patience
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
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
vii
Table des figures
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
x
Liste des abréviations
— CE = Comité d’Entreprise
— SaaS = Software-as-a-Service
xi
Introduction générale
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
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.
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.
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 :
— Designers Graphiques
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 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.
5
Chapitre 1. Contexte général
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 :
6
Chapitre 1. Contexte général
— 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.
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.
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 visibilité : Le client a une meilleure visibilité sur l’avancement de son projet.
— Un meilleur contrôle des coûts : Le projet peut être arrêté à défaut de budget.
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.
— 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
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
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.
— 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.
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.
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 ?
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
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.
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
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
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
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.
Dans cette partie, nous définissons les acteurs, leurs rôles et leurs privilèges dans notre application.
— 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.
17
Chapitre 3. Initiation au projet
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
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.
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
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".
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.
21
Chapitre 3. Initiation au projet
Dans ce paragraphe nous décrivons le déroulement de notre projet tout au long de la période
du stage.
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].
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
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.
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 .
25
Chapitre 4. Lancement du projet
Cette section sera consacrée à justifier nos choix technologiques et à montrer leurs avantages.
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.
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]
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].
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].
— Tout est ressource : chaque ressource est identifiable par un seul identifiant (URI).
— 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.
28
Chapitre 4. Lancement du projet
— 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].
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.
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.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
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.
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]
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].
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
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.
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.
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 :
— Processeur : Intel Core i5 330M / 2.13 GHz - Mémoire Volatile : 4 giga octets.
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
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 :
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
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.
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
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.
Objectifs fonctionnels :
— Proof of concept Google Analytique : trouver et pratiquer un exemple simple (Prototype) démontrant
l’utilisation de G.A.
— Tracking implémentée.
Dans cette partie nous allons présenter le premier sprint de cette Release et ce que nous avons
fait durant ce tout premier sprint.
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
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.
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
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.
39
Chapitre 5. Release 1
40
Chapitre 5. Release 1
• S’abonner»
Nous illustrons par la figure 8.1 le script injecté permettant de mesurer le nombre de clics.
41
Chapitre 5. Release 1
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
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
43
Chapitre 5. Release 1
Objectifs fonctionnels :
— Choix KPIs.
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.
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
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.
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.
Les objectifs définis dans ces deux sprints sont des objectifs fonctionnels :
— Inscription.
— Authentification.
— Déconnexion.
— Édition profile.
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
La spécification fonctionnelle dans notre cas se traduit par les diagrammes UML de cas d’utilisation
et de séquence système.
49
Chapitre 6. Release 2
50
Chapitre 6. Release 2
51
Chapitre 6. Release 2
Nous décrivons le cas d’utilisation « Réinitialiser le mot de passe » par la description textuelle
ci dessous.
52
Chapitre 6. Release 2
Scénario
Si l’email fourni est inexistant, l’utilisateur sera alerté.
d’excéption
Description textuelle du cas d’utilisation « Réinitialiser le mot de passe »
Nous décrivons le cas d’utilisation «Gérer des sources » par la description textuelle ci dessous.
53
Chapitre 6. Release 2
Acteur L’analyste.
Scénario
Si le configuration saisie est inexistant, l’utilisateur sera alerté.
d’excéption
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.
L’objectif de ce diagramme est de montrer comment l’utilisateur peut naviguer entre les pages
dans l’application.
54
Chapitre 6. Release 2
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.
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é.
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
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
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.
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é.
Nous illustrons dans la figure 8.2 quelques API réalisés aux cours de ces sprints.
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
6.4.2.2 Inscription
60
Chapitre 6. Release 2
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
Un utilisateur connecté peut accéder à son profil et modifier ses informations personnelles.
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 :
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
63
Chapitre 6. Release 2
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.
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
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.
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.
65
Chapitre 6. Release 2
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 .
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
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
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é .
Les objectifs définis dans les sprints 9,10,11 et 12 sont des objectifs fonctionnels :
— Documentation jasmin.
— Documentation chart.js.
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
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
Nous illustrons par les diagrammes ci dessus les cas d’utilisations pour ces sprints.
71
Chapitre 7. Release 3
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é.
Nous décrivons le cas d’utilisation «Gérer des tableaux de bord» par la description textuelle ci
dessous.
72
Chapitre 7. Release 3
Acteur Le décideur.
Scénario
Si le configuration saisie est invalide, l’utilisateur sera alerté.
d’excéption
Description textuelle du cas d’utilisation « Gérer les tableaux de bord »
Nous décrivons le cas d’utilisation «Consulter les statistiques» par la description textuelle ci
dessous.
73
Chapitre 7. Release 3
Acteur Le décideur.
7.3 Conception
Nous présentons dans cette section notre conception pour ces sprints du troisième Release.
À 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
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
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.
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.
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
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.
Dans cette partie nous illustrons et expliquons les captures d’écran des interfaces réalisés.
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
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.
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
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
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 :
82
Chapitre 7. Release 3
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.
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
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.
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
La figure 7.23 montre le décideur aura la chance de donner son avis concernant l’objectif de
l’entreprise.
85
Chapitre 7. Release 3
— 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
— 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.
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
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.
La figure 7.29 montre le résultat de quelques test réalisé sur le modèle structure.
88
Chapitre 7. Release 3
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
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/.
[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].
[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].
[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
[22] A. Dhwaj, « Design Pattern : MVC vs. MVP vs. MVVM », 2015, [En ligne ; consulté le 10-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.
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.
Nous illustrons par la figure 8.3 quelques bouts de codes que nous avons détecté l’exception sur
la plate-forme.
94
Annexes
Nous illustrons par la figure 8.4 quelques bouts de codes que nous avons détecté l’ajout des
produits au panier.
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.
95
PÌl
CÃrtF TrK , ÅSaR Cf-ta nu' ÃCti niÁr ituF nu' a siM Å wn`m , ¤rKm @¡ @f d¤
wwm dtsm wlF ylt ms ¨t AAyb m w¡ ¤rKm @¡ dh ¤ . rhJ ¢tF ©d ¨l
, C ¤z wls yl wF £ ¯ £@¡ .¨FAF± A\n @h yl £ d «r TyA ¤ ¨ky TOnm ¨l
¨¤rtk CAt rOn yl¤ hAO d§d¤
liA,niraM ati ,nisFC Áta ,ÃCtiM\niÁC Áta,ata i ,uqitylana
¤ ,ityla : yAf Aml
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 : ¨¤rtk¯ d§rb 23 719 302 : HAf 71 111 111 : Ah Hw - ryb AfR - C® ry h
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 : ¨¤rtk¯ d§rb 71 706 698 : HAf 71 706 164 : Ah TA§C 2080 ¨¤CAb A§r w h 2
2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@isim.rnu.tn