rapportpfe YOSRAADDALI .pdf



Nom original: rapportpfe_YOSRAADDALI.pdf

Ce document au format PDF 1.5 a été généré par TeX / pdfTeX-1.40.17, et a été envoyé sur fichier-pdf.fr le 14/03/2018 à 14:58, depuis l'adresse IP 196.203.x.x. La présente page de téléchargement du fichier a été vue 249 fois.
Taille du document: 6.7 Mo (109 pages).
Confidentialité: fichier public




Télécharger le fichier (PDF)










Aperçu du document


République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
Université de Tunis El Manar
Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du
Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques
Spécialité : Génie Logiciel et Systèmes d’Information
Par

Yosra ADDALI

Mise en place d’une solution de tracking et
monitoring d’une plateforme SaaS

Encadrant professionnel :
Encadrant académique :

M.Malek TAZEROUT
Ingénieur R&D
et Mlle Mayssa MESSAOUDI
Maître Assistante
Madame Hela LIMAM

Réalisé au sein de Devsricker

Année Universitaire :2016/2017

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.

Encadrant professionnel, M. Malek TAZEROUT
Signature et cachet

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.

Encadrant académique, Madame Hela LIMAM
Signature

i

Dédicaces
Je dédie ce modeste travail à :
Mes chers parents, Je mets entre vos mains le fruit de votre amour, de votre tendresse, de vos sacrifices,
et vos encouragements, tout au long de mes études.
Mon cher père , Amor, aucune dédicace ne peut exprimer l’amour, l’estime et le respect que j’ai
toujours pour vous. Vous m’avez donné la vie et vous étiez toujours là pour m’encourager, me motiver,
me pousser à devenir ce que je suis aujourd’hui. Veuillez trouvez dans ce modeste travail la conclusion
de vos efforts, mon amour et ma gratitude. Puisse ce jour vous apporter toute la joie et la fierté que
vous avez tant attendu. Puisse dieu vous accorder la bonne santé et vous garde comme toujours à nos
côtés.
Ma chère mère, Najet, toutes les expressions ne peuvent exprimer mes sentiments d’amour et de
respect vers vous. Vous êtes pour moi la meilleure des mères, qui a consacré sa vie aux bonheur et
réussite de ses enfants. Vous m’avez donné la vie et vous avez guidé tous mes pas, vous êtes toujours
à mes côtés pour me motiver, me pousser à devenir ce que je suis aujourd’hui. En témoignage de vos
fatigues, vos efforts et vos sacrifices, je vous dédie ce travail pour avouer ma reconnaissance et ma
profonde estime. Espérant être votre source de bonheur et de fierté pour ce jour attendu. Puisse Dieu
vous accorder santé et longue vie.
À ma soeur Kaouther et mon frère Adem, je ne peux exprimer à travers ces lignes tous mes
sentiments d’amour envers vous. Que l’amour et la fraternité nous unissent à jamais.
À tous mes amis qui ont toujours fait confiance en moi et en mes capacités à faire mieux. Je ne
pourrais être que reconnaissante envers tout ce que vous avez fait pour moi.

Yosra ADDALI

ii

Remerciements
Au terme de mon projet de fin d’études, j’aimerais exprimer mes sentiments de
gratitude envers toutes les personnes qui par leur présence, leur soutien, leur
disponibilité et leurs conseils, j’ai pu accomplir ce projet.
Je tiens tout d’abord à remercier Monsieur Malek TAZEROUT pour avoir
accepté de m’accueillir au sein de son organisme et m’assurer toutes les
conditions de travail appropriées.
J’adresse aussi mes profonds et sincères remerciements à mon enseigante et
encadrante Madame Hela LIMEM qui a accepté de diriger ce travail, pour ses
conseils précieux, son encouragement continu, sa haute disponibilité, sa patience
énorme et le temps précieux qu’elle m’a réservé tout au long de la réalisation de
mon projet.
Je tiens à remercier et témoigner toute ma reconnaissance à mes encadrants
professionnels au sein de l’entreprise DevStriker, Madame Mayssa
MESSAOUDI pour m’avoir bien encadrée et orientée durant mon PFE et pour
l’aide précieuse qu’elle m’a accordée, ainsi que Monsieur Emmanuel ZEPPA
pour ses conseils et sa disponibilité tout au long de cette période.
Je tiens à remercier également toute l’équipe de DevStriker pour leur chaleureux
accueil, leur collaboration, leur aide et leur soutien continu.
Finalement, je remercie mes proches, mes chers amis, toute ma famille et mes
chers parents pour leur inlassable soutien et pour la confiance qu’ils m’ont
accordés.

iii

Table des matières
Introduction générale

1

1 Contexte général

3

1.1

Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.1.1

SimplyCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.1.2

Devstriker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.2

Étude de l’existant : Plateforme SimplyCE . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.3

Problématique

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.4

Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.5

Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2 ÉTUDE PRÉALABLE

10

2.1

Définition quelque concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.2

Big Data et marketing : les opportunités pour l’entreprise . . . . . . . . . . . . . . . .

12

2.2.1

Un marketing prédictif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.2.2

Les bénéfices du Big data sur le marketing . . . . . . . . . . . . . . . . . . . . .

12

Les logiciels de Web Analytique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.3.1

Histoire et évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.3.2

Logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.3

3 Initiation au projet
3.1

3.2

16

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

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
4.1

24

Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv

25

4.2

4.3

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

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

Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

5.2.1
5.2.2
5.3

5.4

Proof of Concept G.A

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

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

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
6.1

6.2

6.3

47

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

Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.2.1

Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.2.2

Diagrammes de séquence système . . . . . . . . . . . . . . . . . . . . . . . . . .

50

Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

6.3.1

Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

6.3.2

Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

v

6.4

6.5

6.3.3

Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

6.3.4

Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

6.4.1

Coté backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

6.4.2

Coté frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

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
7.1

7.2

7.3

7.4

7.5

7.6

68

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

Spécification fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

7.2.1

Diagrammes de séquence système . . . . . . . . . . . . . . . . . . . . . . . . . .

72

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

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

Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

7.5.1

Test d’unitaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

7.5.2

Test intégration côté Front . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

Évaluation des besoins non-fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . .

89

Conclusion générale

91

Bibliographie

92

Annexes

94

Annexe 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94

vi

Table des figures
1.1

Logo de SimplyCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.2

Modules de SimplyCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.3

Les étapes de la méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.1

L’évolution du Digital Analytics depuis 1993 jusqu’aujourd’hui [4] . . . . . . . . . . . .

14

3.1

Hiérarchie des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.2

Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.3

Exemples de maquettes réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.1

Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.2

Modèle d’exécution de NodeJs [6]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.3

Comparaison entre PHP et NodeJs en terme de temps de réponse [7] . . . . . . . . . .

27

4.4

Comparaison en termes de scalabilité entre les bases de données relationnelles et non
relationnelles [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.5

Courbe de performance React VS Angular VS AngularJS VS Blaze . . . . . . . . . . .

31

4.6

ArchitectureMVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.1

Backlog du sprint 1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.2

prototype GA

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.3

APIs GA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.4

Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.5

Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.6

Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.7

Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.8

Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.9

Backlog des sprints 3 et 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5.10 schéma de construction les indicateurs clés de performance . . . . . . . . . . . . . . . .

45

5.11 schéma les indicateurs clés de performance en l’entreprise simply CE . . . . . . . . . .

45

6.1

Backlog du sprint 5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.2

Backlog du sprint 6

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.3

Backlog du sprint 7

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

vii

Table des figures
6.4

Backlog du sprint 8

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.5

Diagramme de cas d’utilisation de Release 2

. . . . . . . . . . . . . . . . . . . . . . .

50

6.6

Diagramme de séquence système « S’authentifier » . . . . . . . . . . . . . . . . . . . .

51

6.7

Diagramme de séquence système « Créer un compte utilisateur » . . . . . . . . . . . .

52

6.8

Diagramme d’activité de release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

6.9

Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

6.10 Diagramme de classe de release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

6.11 Diagramme de séquence d’authentification . . . . . . . . . . . . . . . . . . . . . . . . .

57

6.12 Diagramme de séquence récupérer les sources . . . . . . . . . . . . . . . . . . . . . . .

58

6.13 Exemple de permission

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

6.14 Exemple d’API réalisés

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

6.15 Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

6.16 Interfaces d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

6.17 vérification de l’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

6.18 Interfaces de réinitialisation du mot de passe . . . . . . . . . . . . . . . . . . . . . . . .

62

6.19 reset du mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

6.20 Interfaces de consultation et modification du profil . . . . . . . . . . . . . . . . . . . .

62

6.21 Interfaces d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

6.22 Interfaces de consultation des sources . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

6.23 Interfaces de choisir type de source récupérée . . . . . . . . . . . . . . . . . . . . . . .

64

6.24 Interfaces de récupération a partir google analytique . . . . . . . . . . . . . . . . . . .

64

6.25 Interfaces de récupération à partir API REST SimplyCE . . . . . . . . . . . . . . . . .

65

6.26 Rapport de quelques tests d’intégration du deuxième Release . . . . . . . . . . . . . .

65

6.27 Release 2 : Rapport de test d’intégration : Modèle utilisateur . . . . . . . . . . . . . .

66

6.28 Release 2 : Rapport de quelques tests unitaires . . . . . . . . . . . . . . . . . . . . . .

66

6.29 Release 2 test fonctionnel : authentification réussi

. . . . . . . . . . . . . . . . . . . .

67

7.1

Backlog du sprint 9

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

7.2

Backlog du sprint 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

7.3

Backlog du sprint 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

7.4

Backlog du sprint 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

7.5

Diagramme de cas d’utilisation relatif aux décideurs . . . . . . . . . . . . . . . . . . .

71

7.6

Diagramme de cas d’utilisation relatif aux analystes

. . . . . . . . . . . . . . . . . . .

72

7.7

Diagramme de classe pour troisième release . . . . . . . . . . . . . . . . . . . . . . . .

75

viii

7.8

Diagramme de séquence relatif au cas d’utilisation " Créer une structure " . . . . . . .

76

7.9

Diagramme de séquence relatif au cas d’utilisation " Consulter les statistiques " . . . .

77

7.10 Diagramme de séquence relatif au cas d’utilisation " créer un tableau de bord personnalisé
" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

7.11 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

7.12 APIs de gestion des tableaux de bord

. . . . . . . . . . . . . . . . . . . . . . . . . . .

79

7.13 Interface de consultation des structures . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

7.14 Interface d’ajouter une structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

7.15 Interface l’agrégation des sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

7.16 Interface tableau de bord de l’agrégation des sources . . . . . . . . . . . . . . . . . . .

81

7.17 Interface de consultation des tableaux de bord . . . . . . . . . . . . . . . . . . . . . . .

82

7.18 Interface d’analyse du parcours d’utilisateurs . . . . . . . . . . . . . . . . . . . . . . .

83

7.19 Interface d’analyse performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

7.20 Interface d’analyse e-commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

7.21 Interface de création tableau du bord . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

7.22 Interface de première étape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

7.23 Interface de deuxième étape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

7.24 Interface de troisième étape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

7.25 Interface l’étape finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

7.26 Interface l’étape finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

7.27 Classification de navigation des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . .

87

7.28 Release 3 : Rapport de test d’unitaire : Modèle dadhboard

. . . . . . . . . . . . . . .

88

. . . . . . . . . . . . . . . .

89

. . . . . . . . . . . . . . . . . . . . . . . . . . .

89

8.1

Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94

8.2

Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94

8.3

Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94

8.4

Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95

8.5

Bouts de code injectés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95

7.29 Release 3 : Rapport de test d’unitaire : Modèle structure
7.30 Release 3 : Test intégration coté front

ix

Liste des tableaux
2.1

Comparaison entre les différents logiciels de Web Analytique . . . . . . . . . . . . . . .

15

3.1

Acteurs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

x

Liste des abréviations
— CE

=

— CRUD =

Comité d’Entreprise
Create Read Update Delete

— GLSI

=

Génie Logiciel et Systèmes d’Information

— KPI

=

Key Performance Indicator

— SaaS

=

Software-as-a-Service

— UML

=

UnifiedModeling Language

xi

Introduction générale
En faveur de l’amélioration continue de la performance des entreprises, les propriétaires d’entreprises,
les parties prenantes (actionneurs) et les décideurs se trouvent dans la nécessité d’examiner régulièrement
la situation globale de l’activité et du processus métier (Business). En visualisant l’ensemble de
données collectées au sein d’une entreprise, il devient possible de mettre en évidence les principales
questions, les risques et les tendances pour identifier de nouvelles opportunités dans l’industrie en
question. Les données dont nous parlons sont en effet créées par différentes sources, telles que les
individus, les dispositifs et les applications au sein de l’organisation ; et elles ne cessent de croître de
jour en jour. Cherchant à stimuler et à améliorer leur activité, les organisations se servent le plus
de telles données pour constituer leurs propres indicateurs de performance. Toutefois, les données
obtenues n’offrent généralement pas de précieux aperçus à leurs lecteurs car elles souffrent de lacunes
et d’un manque de pertinence, ce qui nous empêche d’analyser et d’identifier les problèmes radicaux
en fouillant inutilement dans des documents et des rapports exhaustifs. Sachant que, la capacité de
suivre, de collecter, de décoder et d’agir sur de telles données traitées en temps réel est devenue une
tâche extrêmement dure et délicate en même temps. Parmi les solutions finales les plus couramment
utilisées, nous distinguons la visualisation de données telles que la création de tableaux de bord. Ceux-ci
contiennent généralement plusieurs graphiques donnant un aperçu de l’activité de l’entreprise tout en
se concentrant sur les métriques principales, en apportant de la valeur ajoutée et en projetant des
informations clés et critiques.
À cette fin, DevStriker, l’entreprise hôte de notre stage, a décidé de lancer un outil Web d’analyse
et de visualisation de données toute plate-forme pour toute la suite Web Simply CE. En effet, les
principaux objectifs de notre stage de six mois ont été répartis sur deux parties fondamentales, en
commençant par la collecte des informations pertinentes jusqu’à la mise en œuvre d’un outil permettant
à l’utilisateur final de consulter des tableaux de bord et de les personnaliser selon plusieurs critères et
vues.
Le présent rapport englobe et synthétise tout le travail réalisé. Il s’articule autour de sept chapitres.
Le premier chapitre « Contexte général » présente l’organisme d’accueil, le projet et la méthodologie de
travail adoptée. Le deuxième chapitre « Étude préalable » présente une étude préliminaire du projet.
Le troisième chapitre « Initiation au projet » introduit les grandes lignes du projet tout en détaillant
ses spécificités et son déroulement. Le quatrième chapitre « Lancement du projet » constitue la phase
de « pré-jeu » au cours de laquelle nous précisons l’architecture générale de notre solution ainsi que nos
choix technologiques et les outils que nous avons utilisé tout au long du projet. Le cinquième, le sixième

1

Introduction générale
et le septième chapitre présentent les « releases » de notre projet, dans lesquelles nous retournons avec
plus de détails à la conception soulignant les fonctionnalités offertes par notre solution, ainsi qu’une
présentation de l’étape de réalisation et de l’implémentation de notre solution.

2

Chapitre 1

Contexte général

Plan
1

Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2

Étude de l’existant : Plateforme SimplyCE . . . . . . . . . . . . . . . . . . .

5

3

Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

4

Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

5

Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

Chapitre 1. Contexte général

Introduction
Ce chapitre est consacré à la présentation du cadre général de notre projet. Nous allons
commencer par l’organisme d’accueil : son activité et ses services. Par la suite nous allons procéder à
une description de l’existant. La dernière section présente les grands traits de la solution ainsi que la
démarche à suivre pour la concrétiser.

1.1

Organisme d’accueil

Nous procédons à présent à la présentation de l’entreprise au sein de laquelle s’est déroulé notre
projet de fin d’études.

1.1.1

SimplyCE

Fondée en juin 2014, SimplyCE est une start-up de la région Nantaise en France en plein
développement. Elle évolue sur le marché de la publicité, des loisirs et de la réduction, et met à
disposition de ses clients des produits et des services innovants. SimplyCE édite et distribue une
gamme de produits répondant aux besoins des comités d’Entreprises (institutions représentatives du
personnel au sein d’une entreprise) en termes de gestion, de communication et de satisfaction des
salariés. Ces produits permettent de simplifier la vie des élus des CE dans l’exercice de leur mandat en
garantissant une facilité de gestion et une satisfaction des salariés. Pour son activité, l’entreprise a créé
une plate-forme hébergée en mode SAAS (Software as a Service), qui comprend un site internet, des
modules de gestion et une interface e-commerce pour la vente de billetterie à tarif réduit. A ce jour,
SimplyCE collabore avec 400 enseignes sur Nantes et sa métropole, elle propose également environ 15
000 offres sur le plan national. [1]
La figure 3.2 introduit le logo de SimplyCE.

Figure 1.1: Logo de SimplyCE

4

Chapitre 1. Contexte général

1.1.2

Devstriker

Devstriker est la filiale off-shore de SimplyCE en Tunisie, créée en novembre 2016. Sa mission
consiste principalement à étendre des activités de développement informatique et de design graphique.
Les équipes à ce moment sont composées de :
— Développeurs Full-Stack, Web et Mobile
— Web designers / Intégrateurs Web
— Social Media Manager / Community Manager
— Designers Graphiques

1.2

Étude de l’existant : Plateforme SimplyCE

SimplyCE a développé une solution de type Saas (Software a as service), une solution multiservice
en ligne à la destination des comités d’entreprises. La solution inclut les fonctionnalités suivantes :
— Un micro-réseau social privé d’entreprise : Permet aux comités d’entreprise de communiquer en
interne avec leurs salariés en leur partageant des newsletters, des PV de réunions, des albums
photos et en leur diffusant des sondages et des enquêtes.
— Un espace e-commerce privé de billetterie : Permet aux salariés de l’entreprise d’acheter directement
en ligne tout en bénéficiant de tarifs préférentiels sur un catalogue d’offres à dimension locale et
nationale.
— Un module de gestion : Permet aux comités d’entreprise d’administrer la liste de leurs salariés,
de leur attribuer des subventions selon leurs politiques sociales et d’effectuer le suivi.
La figure ci-dessous illustre les trois modules mentionnés.

5

Chapitre 1. Contexte général

Figure 1.2: Modules de SimplyCE

1.3

Problématique

La plateforme SimplyCE ayant plusieurs modules web, nous citons ceux qui sont en relation
avec les salariés des comités des entreprises :Wigo Vacances, L’irrésistible, Simply Club. Ainsi
les données fournis par ces modules constituent une mine générant des volumes de données de plus
en plus vertigineux. La solution SimplyCE édite et distribue une gamme de produits engendrant une
masse de données produites chaque jour. À ce stade-là, il parait si difficile d’identifier précisément le
profil de chaque client tout en proposant voire infligeant un produit en adéquation avec les intérêts des
acheteurs et leurs désirs personnels. En effet, l’entreprise n’aurait presque aucune idée sur l’évolution
des comportements d’achat, les insatisfactions des salariées avec tout ce qui circule dans les tuyaux
informatiques de leurs entreprises et notamment les données capturée auprès de ces clients, etc.
Aujourd’hui, les décideurs au sein de SimplyCE posent des questions comme les suivantes :
— Quelle est la performance des pages les plus vues ?
— Que recherchent les visiteurs sur notre plate-forme ?
6

Chapitre 1. Contexte général
— Y a-t-il des maillons faibles dans les entonnoirs ?
— Quels produits déclenchent le plus de mise au panier ?
— Quels produits dans les paniers sont les plus abandonnés au moment de l’achat ?
— Où-est ce que les visiteurs cliquent-ils sur nos pages Web et où ne cliquent-ils pas ?
Cette connaissance servira davantage pour améliorer et accélérer la prise de décision. Un autre problème
se manifeste ici : Il faut trouver un moyen de prévoir à long terme les comportements des clients et des
prospects aussi. Il ne s’agit plus seulement de se demander « qui a acheté, quand et par quel canal ?
», mais aussi « qui achètera quoi, quand et par quel canal ? ». Ce raisonnement est né afin d’enrichir
l’expérience-utilisateur et d’obtenir un aperçu concis de la production de l’entreprise. En outre, la
fixation et la distinction des axes d’analyse les plus importants et de ceux qui peuvent être ignorés
s’avère de plus en plus complexe. C’est l’une des principales raisons pour lesquelles nous avons besoin
d’un outil de « Tracking » pour le suivi et le traitement des données collectées et de cette manière là,
l’entreprise peut avoir une vision globale de ses multiples actions Marketing, savoir ce qui fonctionne
en temps réel et ce qui ne fonctionne pas dans son tunnel de conversion et dans ses actions Marketing.

1.4

Solution proposée

La solution proposée consiste à la mise en place d’un outil d’analyse et de suivi des parcours
des utilisateurs de la plate-forme de type SaaS de SimplyCE. Cet outil permettra d’analyser les
comportements des visiteurs, de définir leurs intérêts à travers la recherche avancée effectuée (selon
des mots-clés à priorité) et de fixer des mesures de performance de la plateforme. En outre, cet outil
permettra de déterminer et délimiter nos stratégies en fournissant des statistiques sur les utilisateurs
en temps réel et sur leurs parcours d’achat complets. Ainsi, l’outil d’Analytique sert principalement à
décortiquer les données liées aux ventes et au marketing pour en conclure les mesures adéquates.

1.5

Méthodologie de travail

Méthodologie agile :
Depuis des années, la majorité des projets de développement logiciel s’appuie sur des méthodologies
appelées agiles. Cette bannière combine plusieurs méthodes basées sur le développement itératif et
incrémental, dans lequel la recherche des solutions aux problèmes repose sur la collaboration, impliquant
le client du début jusqu’à la fin du projet. Elle considère que le besoin ne peut être figé et propose de
s’adapter aux changements de ce dernier.[2]
La méthodologie agile vise à avoir :

7

Chapitre 1. Contexte général
— Une meilleure qualité de communication : Le client a la possibilité de clarifier ou modifier ses
besoins au fur et à mesure.
— Une meilleure visibilité : Le client a une meilleure visibilité sur l’avancement de son projet.
— Une meilleure qualité du produit : Les tests sont effectués continuellement.
— Un meilleur contrôle des coûts : Le projet peut être arrêté à défaut de budget.
Méthodologie agile : Scrum

Scrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est constitué
d’une définition de rôles, de réunions et d’artefacts.
Scrum définit 3 rôles :
— Le Product Owner : C’est le client et le représentant de l’utilisateur ; il définit les besoins, les
spécifications du produit et l’ordre dans lequel les fonctions seront développées.
— Le Scrum Master : C’est l’intermédiaire entre le Product Owner et l’équipe de développement.
Il assure la bonne application de la méthodologie Scrum.
— L’équipe de développement : C’est l’équipe qui réalise le produit tout en respectant les délais
fixés à l’avance. Il s’agit d’une équipe auto-organisée. Elle regroupe en général une panoplie de
profils : Architecte, concepteur, développeur, spécialiste IHM, testeur, etc.
Notre projet suit ainsi le processus de développement agile SCRUM (processus de mêlée) afin
d’identifier les besoins systématiques, spécifier et planifier dans les délais et en appliquant les bonnes
pratiques du Génie Logiciel l’intégralité du projet.
La figure 1.3 présente les étapes de la méthodologie SCRUM.

8

Chapitre 1. Contexte général

Figure 1.3: Les étapes de la méthodologie SCRUM
[3]

Conclusion
Ce chapitre est une partie introductive de notre projet, au cours de laquelle nous avons présenté
le cadre général de notre travail. Nous avons introduit en premier lieu l’organisme d’accueil ensuite,
notre solution et la méthodologie de travail adoptée.
Nous entamons ainsi la prochaine partie qui consiste à établir une première étude explorant les différents
concepts qui touchent à ce projet.

9

Chapitre 2

ÉTUDE PRÉALABLE

Plan
1

Définition quelque concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2

Big Data et marketing : les opportunités pour l’entreprise

3

Les logiciels de Web Analytique . . . . . . . . . . . . . . . . . . . . . . . . . . 13

. . . . . . . . . 12

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.
Toutes les sources de données sont

Moins de 10 des données sont disponibles
exploitées.
Données

en

temps

réel,

corrélées,

Données en lots, incomplètes, disjointes
gouvernées.
Supervision de l’activité
Optimisation de l’activité.
Comparaison entre la prise décision aujourd’hui et avec le Big Data
Les décisions humaines sont difficiles à interpréter ou à prévoir. Le Big data donne l’opportunité
11

Chapitre 2. ÉTUDE PRÉALABLE
de ne pas avoir à comprendre le processus de décision. Plus besoin de savoir quels sont les facteurs
de performance, le pourquoi est mis de côté. Ce qui importe, ce sont les conséquences, les résultats
plus que la causalité.
Il en est pratiquement de même pour le Big data qui reconstitue un simili grossier du contexte,
en croisant des données qui à priori n’ont pas de relations entre elles, ce qui n’est pas le cas du
décisionnel classique.

2.2

Big Data et marketing : les opportunités pour l’entreprise

La donnée, et le Big data, vont impacter le marketing, en lui amenant toujours plus d’informations
pour qu’il puisse accéder à une connaissance plus riche et plus juste du client. Le marketing va
indubitablement évoluer. Dès lors, si le Big data se met au service du marketing, quels en sont les
objectifs et quels bénéfices en tirent-ils ?

2.2.1

Un marketing prédictif

Le marketing s’oriente vers un marketing prédictif qui se nourrit d’importants volumes de
données remontés en continu et en temps réel. Cela entraîne deux nouveautés : La modélisation
numérique du réel pour manipuler virtuellement le monde ; et des ajustements instantanés et continus
des politiques commerciales. Le marketing prédictif est l’aboutissement du « Big data marketing ». Il
fait l’objet d’énormément de fantasmes. L’Homme a toujours désiré connaître son avenir. La prédiction
certaine conférerait au marketing et au Big data marketing un caractère scientifique. Toutefois nous
n’en sommes encore qu’aux balbutiements. Le passage du Data mining à l’analyse prédictive n’est
pas encore intégralement franchi. Des obstacles restent à surmonter pour que les promesses de la
science soient tenues : tout d’abord, il faudra être capable de gérer la complexification croissante des
algorithmes destinés à appréhender toujours plus de dimensions et toujours plus de données. Cela
suppose avant tout de remettre en cause les schémas classiques de calculs et de stockages de données
afin de permettre au système de résoudre les requêtes avec le moins d’utilisation possible des actions
pénalisantes comme les accès disques.

2.2.2

Les bénéfices du Big data sur le marketing

Le Big data explore déjà de nouveaux usages dans plusieurs spécialités mercatiques comme
le marketing relationnel avec des scénarios « cross-canal », le web analytics avec l’optimisation des
parcours en ligne et le marketing prédictif avec l’anticipation des besoins et des évolutions. Le Big data
va contribuer à transformer le marketing en améliorant ses capacités d’exécution depuis la collecte des

12

Chapitre 2. ÉTUDE PRÉALABLE
informations clients jusqu’à l’implémentation de promotions ou d’offres ciblées. Cette conjugaison du
Big data avec le marketing doit amener vers un marketing augmenté, le Big data marketing, pour :
— Accroître la réputation de la marque ;
— Anticiper les comportements plutôt que de réagir aux situations ;
— Comprendre chaque client dans son unicité ;
— Délivrer un contenu en lien avec la cible ;
— Développer les produits de demain ;
— Explorer toutes les informations clients disponibles ;
— Maximiser la valeur délivrée à chaque interaction.

2.3

Les logiciels de Web Analytique

Il est très important lors de la création ou de la gestion d’un site Web d’être en mesure de
connaître la performance de celui-ci.

2.3.1

Histoire et évolution

L’évolution de la notion du Digital Analytics est étroitement liée aux évolutions du Web.
Trois évolutions majeures du Web ont ainsi bouleversé ce concept : deux évolutions technologiques :
l’arrivée du langage JavaScript et des nouvelles technologies de stockage, et une évolution légale : la
directive européenne sur les Cookies.
L’arrivée du langage JavaScript a révolutionné la discipline en permettant de collecter de
nouvelles données de façon plus précise La démocratisation des nouvelles technologies de stockage
a rendu possible de nouveaux usages comme l’accès et l’utilisation des données en temps réel à
des fins d’optimisation des performances digitales tant au niveau de l’acquisition de trafic que de
la personnalisation.
L’application de la directive européenne sur les Cookies dans les pays de l’Union Européenne
a obligé les annonceurs à demander le consentement de leur visiteur avant l’utilisation de solutions de
suivi de leur comportement. Les annonceurs doivent maintenant trouver un juste milieu entre le fait
d’être en accord avec la loi et le fait de toujours collecter plus de données.[4]
La figure 2.1 justifie l’évolution du Digital Analytics depuis 1993 jusqu’aujourd’hui.

13

Chapitre 2. ÉTUDE PRÉALABLE

Figure 2.1: L’évolution du Digital Analytics depuis 1993 jusqu’aujourd’hui [4]

2.3.2

Logiciels

Dans cette section nous présentons un petit portrait des différents logiciels existants de Web
Analytique.
Nous distinguons différents facteurs qui se présentent pour faire le comparatif entre les solutions
existantes.
Nous essayons à travers le tableau 2.1 de dégager les fonctionnalités principales.

14

Chapitre 2. ÉTUDE PRÉALABLE
Kiss Metrics

Fonctionnalités

Langues
Prix de base

suivre
les
comportements
des visiteurs sur un
site Web.
Anglais
120 $ à 600$ par
mois

Piwik
analyser
les
informations
sur
les
visiteurs
du
site Web, tracker
les
mots-clés
intéressants
Anglais

Moz pro

120$ à 600$ par mois

99$ à 599$ par mois

suivre
comportements
e-commerce

les

Anglais

Tableau 2.1: Comparaison entre les différents logiciels de Web Analytique
Nous constatons par conséquent que l’offre de logiciels est bien variée et axée sur un domaine
et pour une certaine cible. Par contre ceci nous conduit à conclure qu’il y a manque d’analyse sur les
trois axes en même temps. D’autre part, ces solutions ne permettent pas d’importer des données à
partir de sources externes.

conclusion
Dans ce chapitre, nous avons présenté une étude théorique concernant le domaine du Web
Analytique ainsi que des critiques des solutions existantes sur le marché. Une analyse des besoins fera
l’objet du chapitre suivant afin d’avoir une idée plus claire sur le déroulement de notre projet.

15

Chapitre 3

Initiation au projet

Plan
1

Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2

Pilotage du projet avec Scrum

. . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapitre 3. Initiation au projet

Introduction
L’analyse des besoins est une étape primordiale dans la réalisation de tout projet informatique.
De ce fait, ce chapitre sera consacré à la présentation des besoins de notre projet.
Nous commençons par l’identification des acteurs (rôles des utilisateurs) et leurs fonctionnalités principales,
ensuite nous entamons la spécification fonctionnelle et non fonctionnelle afin de produire le backlog du
produit ainsi qu’une première planification des sprints.

3.1

Capture des besoins

Dans cette partie, nous définissons les acteurs, leurs rôles et leurs privilèges dans notre application.

3.1.1

Identification des acteurs

Nous pouvons distinguer dans notre système 3 acteurs différents :

— Décideur : C’est l’utilisateur de notre application, celui qui consulte tout ce qui concerne les
analyses à travers la visualisation des statistiques et des rapports générés( parcours, performances,
e-commerce, etc.). Son rôle consiste en la possibilité de décider des orientations d’entreprise à
travers les résultats de l’application visualisés.
— Analyste : Son rôle est de contrôler l’activité des parcours d’utilisateurs dans la plate-forme
SimplyCE. Il capture dans un premier temps toutes les informations nécessaires et les stocke.
Ensuite il les traite pour pouvoir récupérer des mesures analytiques.
— L’administrateur : Il s’agit de l’administrateur de toute la plate-forme. Ses autorisations étendent
celles de tous les autres acteurs.
Nous introduisons dans la figure une hiérarchie de tous les acteurs.

Figure 3.1: Hiérarchie des acteurs

17

Chapitre 3. Initiation au projet

3.1.2

Recueil des besoins fonctionnels (Product Backlog)

Les principales fonctionnalités de notre application sont divisées en 2 catégories : La première est
spécifique à la collecte de données et l’injection des scripts à la plate-forme Simply Club, la deuxième
partagée entre le décideur et l’analyste.
Le Backlog du produit
L’approche de Scrum propose de commencer par énumérer les exigences du client pour produire le
backlog du produit en tant qu’une liste de « user Stories » ; cette liste contient tout ce qui pourrait
être exigé dans le produit et est la seule source de besoins pour toutes les modifications à apporter au
produit.
Chaque élément du backlog ( « backlog item ») est estimé en terme d’effort de développement par
l’équipe Scrum.
Dans note projet, nous avons estimé l’effort de chaque « backlog item » par un nombre issu de la suite
de Fibonacci.
Le tableau 3.1.2 introduit le backlog du produit désigné pour notre projet avec l’ordre de priorité qui
a été fixé par le « Product Owner ».

18

Chapitre 3. Initiation au projet
ID

User Story

Sprint

1

En tant qu’analyste, je veux collecter de données.

1

5

En tant qu’analyste, je veux reconstituer le parcours utilisateur.

2

En tant qu’analyste, je veux mesurer la performance de la
6

2
plate-forme.
En tant qu’analyste, je veux récupérer de données à partir d’une

2

8
API REST.
En tant qu’analyste, je veux récupérer de données de tracking de

3

8
notre plate-forme à partir du serveur Google Analytics.

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

En tant que décideur, je veux consulter l’analyse et les statistiques
9

10
e-commerce.

10

En tant que décideur, je veux consulter le parcours utilisateur.

10

En tant que décideur, je veux consulter et évaluer la performance
11

10
de la plate-forme simplyCE.

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

En tant qu’administrateur, je veux créer un compte google
15

1
analytique.

16

En tant qu’administrateur, je veux gérer des comptes d’utilisateurs
Backlog du produit

3.1.3

3

Les besoins non fonctionnels

L’utilité d’un système logiciel est déterminée par ses exigences fonctionnelles et ses caractéristiques
non fonctionnelles à la fois. Les exigences non fonctionnelles sont en effet des exigences implicites que
le système doit respecter. Dans notre cas, nous avons identifié :
L’ergonomie de l’interface :
Afin de satisfaire les utilisateurs, cette contrainte est inévitable. Ainsi, l’interface de l’application doit
être simple, conviviale et facile à utiliser. Pour le design de l’application, nous devons suivre les grandes
lignes directrices (guidelines).
19

Chapitre 3. Initiation au projet
La sécurité :
Notre système devrait être sécurisé : au moment de l’authentification des utilisateurs de l’application,
il faut tenir compte des droits d’accès pour protéger les données. Ainsi, il faut s’assurer des données
d’authentification (notamment les jetons de sécurité pour les sessions des utilisateurs) mais aussi du
cryptage des données au niveau de la base de données (principalement les mots de passe des comptes
des utilisateurs).
La maintenabilité et l’évolutivité :
Notre projet doit être aligné avec les normes architecturales pour une maintenance facile et pour assurer
l’évolution du système en cas d’ajout ou de modification de besoins.
La synchronisation de données :
L’application doit gérer une mise à jour de données en temps réel pour garantir la fiabilité et la
cohérence des données au niveau des résultats d’analytique obtenus.

3.1.4

Modélisation des besoins

Dans cette section, nous présentons le diagramme de cas d’utilisation global afin de mieux
organiser les besoins de notre système. Nous retournons avec plus de détails sur ces diagrammes dans
les phases de réalisation de nos sprints. Dans un diagramme de cas d’utilisation, à chaque acteur est
attribué un rôle bien déterminé et chaque cas d’utilisation représente une fonctionnalité réalisée par le
système.
La figure 3.2 représente le diagramme de cas d’utilisation général

20

Chapitre 3. Initiation au projet

Figure 3.2: Diagramme de cas d’utilisation global

3.1.5

Prototypage des interfaces

Le prototypage (appelé aussi le maquettage) est une technique qui consiste à préparer les
interfaces graphiques de l’application. Elle a pour but de simuler l’interface d’un produit.
Le prototypage permet ainsi de détecter les problèmes d’utilisabilité et de mesurer la satisfaction du
client par rapport à la compréhension du projet avant de se lancer dans le codage.
Dans notre projet, nous avons fait le prototypage des interfaces avec l’outil "Balsamiq".
3.1.5.1

Outil de prototypage : Balsamiq

Balsamiq est un outil qui permet de faire des maquettes d’interfaces de manière simple et rapide.
Grâce à une bibliothèque riche de gadgets qui sont utilisés par la technique de "drag-and-drop" pour
faciliter la génération des maquettes sans aucune connaissance particulière de code.
3.1.5.2

Exemples de maquettes réalisées

La figure 5.2 présente une maquette de la navigation principale d’un utilisateur.
Ces prototypes décrivent les grandes lignes des interfaces. La solution finale ne sera pas totalement

21

Chapitre 3. Initiation au projet
conforme à ces maquettes.

Figure 3.3: Exemples de maquettes réalisées

3.2

Pilotage du projet avec Scrum

Dans ce paragraphe nous décrivons le déroulement de notre projet tout au long de la période
du stage.

3.2.1

Les outils Scrum : VersionOne

Il existe des différents outils pour la gestion d’un projet Scrum qui offrent la possibilité de suivre
la priorité, la traçabilité et la gestion de tout le travail associé. Parmi ces outils nous avons choisi
d’utiliser « VersionOne ».
C’est une solution complète de gestion de projet agile qui permet à l’équipe d’utiliser Scrum en leur
fournissant un espace de travail collaboratif. Il permet aux équipes d’avoir une meilleure vision de
l’avancement de leur projet ce qui leur permet d’avoir une idée sur les risques à venir et d’améliorer
leur productivité [5].

3.2.2

Équipes et rôles

Nous illustrons dans le tableau 3.1 les différents acteurs participant au déroulement de notre
projet et leurs rôles respectifs.

22

Chapitre 3. Initiation au projet
Acteur

Rôle

Malek
TAZEROUT

Product
Owner

Mission
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
Veiller au bon déroulement du projet et
à l’application correcte de la méthodologie
(Planification des sprints et évènements Scrum)

Mayssa
MESSAOUDI

Scrum
Master

S’assurer de l’implication de l’équipe et l’aider à
franchir les différents obstacles
Assister l’équipe dans
l’identification de solutions

Yosra
ADDALI

L’équipe

la

recherche

et

Suivi des tâches réalisées et des idées proposées
Proposition de solutions
Recherche Et Développement
Conception
Réalisation des tests

Tableau 3.1: Acteurs du projet

Conclusion
Dans ce chapitre, nous avons défini en premier lieu les acteurs de notre application avec leurs
rôles et leurs cas d’utilisation.
En deuxième lieu nous avons présenté les spécifications fonctionnelles et non fonctionnelles de la
solution.
Enfin nous avons décrit le déroulement de notre projet suivant la méthodologie Scrum.
Dans ce qui suit nous allons introduire le premier sprint qui consiste à présenter les choix architecturaux
et techniques.

23

Chapitre 4

Lancement du projet

Plan
1

Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2

Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3

Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapitre 4. Lancement du projet

Introduction
Au cours de ce chapitre, nous définissons notre architecture globale du projet, puis nous
définissons nos choix technologiques et nos outils utilisés.

4.1

Architecture de la solution

Dans cette partie nous illustrons l’architecture globale de notre solution.
L’architecture utilisée dans notre système est l’architecture 3-tiers illustrée par la figure 4.1

Figure 4.1: Architecture globale

Cette architecture se base en effet sur une séparation de 3 niveaux au sein d’une même application :
— Un client léger :
Celui-ci prend en charge la présentation de l’application, les traitements locaux qui permettent la
vérification de la saisie et la mise en forme des données. Dans notre cas, il s’agit d’une application
Web.

— Un serveur d’application :
Il prend en charge les traitements applicatifs. Il communique avec le client à travers des requêtes
HTTP .
— Un serveur de base de données :
C’est là où se situent les données. Il doit avoir une importante capacité de stockage, il doit être
disponible afin qu’on puisse y accéder à tout moment, et il doit enfin avoir une puissante capacité
de traitement dans le cas où plusieurs requêtes s’y exécute en même temps.

25

Chapitre 4. Lancement du projet

4.2

Choix technologiques

Cette section sera consacrée à justifier nos choix technologiques et à montrer leurs avantages.

4.2.1

Le développement web

4.2.1.1

La plateforme du serveur

Le temps de réponse élevé du serveur dans la solution existante de SimplyCE nous a poussé à
chercher une autre plateforme que Symfony (PHP) qui remédie à ce problème. La solution que nous
avons trouvée est d’utiliser NodeJs. Basé sur JavaScript, NodeJs gère efficacement les requêtes HTTP
et contient également un serveur HTTP intégré ce qui rend possible de faire tourner un serveur web en
interne, sans avoir besoin d’un serveur externe comme Apache. Cette solution nous permet de gagner
en performance par rapport à la première puisque le modèle d’exécution NodeJs est basé sur la boucle
d’événements JavaScript qui utilise les callbacks sur un seul processus. Cette boucle d’événements
facilite la gestion des demandes simultanées sur le serveur.
La figure 4.2 explique bien comment NodeJs fonctionne.

Figure 4.2: Modèle d’exécution de NodeJs [6]

Une fois que les clients ont envoyé leurs demandes au serveur NodeJs, ce dernier les place dans
une file d’attente de traitement « Event Queue ». Par la suite, NodeJs utilise la boucle d’événements
de Javascript « Event Loop » qui vérifie les demandes placées dans la file d’attente pour les traiter. Si
les demandes du client sont simples : c’est à dire elles ne nécessitent pas des entrées/sorties bloquantes,
alors elles seront traitées directement. Sinon, la boucle d’événement utilise le « C++ Thread Pool »
pour les traiter. Lorsque le traitement d’un Thread est terminé, un Callback est envoyé à l’« Event
Loop » qui par la suite retourne la réponse au client.
La figure 4.3 montre la performance de NodeJs en le comparant avec PHP en terme de temps de
réponse.

26

Chapitre 4. Lancement du projet

Figure 4.3: Comparaison entre PHP et NodeJs en terme de temps de réponse [7]

4.2.1.2

La base de données

Le choix du système de gestion de la base de données (SGBD) est une étape primordiale pour
tout projet informatique. En effet, les données sont les éléments vitaux des entreprises, c’est pour
cette raison qu’il faut bien choisir le SGBD qui permet de les gérer et les mettre à disposition des
utilisateurs. Il existe deux groupes de famille de SGBD dont chacune dispose de ses avantages et de
ses inconvénients. Dans le cadre de notre projet nous avons fait le choix entre la famille des SGBD
relationnels tels que MYSQL qu’utilise SimplyCE actuellement, et la famille des SGBD non relationnels
représentée par la technologie NOSQL (Not Only SQL).
Vu le grand nombre de données diffusées par SimplyCE et le nombre important des utilisateurs qui ne
cesse d’augmenter, la solution MYSQL de SimplyCE déjà existante devient de plus en plus difficile à
gérer, notre intérêt alors se tourne vers les techniques NOSQL. En effet, pour un flux de données très
important lors du suivi des données des utilisateurs nous nous trouvons face à des modèles de données
sans schéma fixe et qui s’enrichissent et prennent du volume au cours du temps ; et notons ici que le
temps de réponse d’une base de données relationnelle augmente proportionnellement ce qui cause une
chute claire de performance. La figure 4.4 explique encore notre choix.

Figure 4.4: Comparaison en termes de scalabilité entre les bases de données relationnelles et non
relationnelles [8]

27

Chapitre 4. Lancement du projet
Il existe de multiples bases de données de type NOSQL, dans notre projet nous avons utilisé
la base NOSQL Orientée-Document « MongoDB ». MongoDB est une base de données NOSQL Open
Source qui utilise des documents de type JSON pour stocker les données ; ce qui signifie que les champs
peuvent varier d’un document à l’autre et la structure des données (qui n’a pas de schéma fixe) peut être
modifiée au fil du temps. Ce mécanisme lui confère une grande souplesse d’utilisation et une véritable
évolutivité. MongoDB peut également être mise à l’échelle à travers de multiples centres de données
distribués pour répondre et faire face à une montée en charge ou une intolérance aux pannes, offrant
une disponibilité et évolutivité précédemment inaccessibles avec les bases de données relationnelles. [9].
4.2.1.3

Les Services Web

Les services web sont des programmes informatiques permettant la communication et l’échange
de données entre applications et systèmes hétérogènes dans des environnements distribués. Ils fournissent
un moyen d’intégrer différents systèmes et d’exposer des fonctions métiers réutilisables. Les applications
logicielles écrites dans divers langages de programmation et exécutées sur différentes plateformes
peuvent utiliser les services Web pour échanger des informations sur Internet en utilisant le protocole
HTTP. Dans notre projet il est évident de créer des web services et de les exposer en tant que méthode
Web au client mobile [10].

Services web RESTful
REST, l’acronyme de "Representational State Transfer", est un style d’architecture pour les systèmes
distribués, basé sur le protocole HTTP. Il est basé sur les principes suivants :
— Tout est ressource : chaque ressource est identifiable par un seul identifiant (URI).
— L’utilisation des méthodes/standards HTTP (GET -POST -PUT – DELETE).
— Architecture Client/Serveur : Le client pour accéder et modifier la ressource et le serveur pour
fournir la ressource.
— Stateless (sans état) : Toutes les modifications d’une ressource doivent être effectuées à travers
une requête HTTP isolée et indépendante.

Avantages du REST
Parmi les différents avantages du REST nous pouvons citer :
— La simplicité d’implémentation.
— La séparation entre le client et le serveur.
— L’indépendance vis à vis du langage de programmation et de la plateforme de déploiement [11].

28

Chapitre 4. Lancement du projet
Les bonnes pratiques pour la conception d’une APIS REST
La création des APIS REST constitue une étape inévitable et primordiale dans notre projet. La réussite
de cette mission passe par l’étape de conception qui représente un enjeu majeur, dans la mesure où une
API mal conçue ne sera vraisemblablement pas ou peu utilisée. Pour cette raison, nous devons suivre
les bonnes pratique telles que :
— Une URL doit être simple et intuitive.
— L’utilisation des noms dans un URI au lieu des verbes.
— Les noms doivent être explicites et au pluriel.
— L’utilisation des verbes HTTP pour décrire les actions réalisées sur les ressources : "POST" pour
la création d’une ressource, "PUT" pour la modification d’une ressource, "DELETE" pour la
suppression d’une ressource et "GET" pour la demande d’une ressource.
— L’utilisation des codes de statuts HTTP (Exemples : 401 : utilisateur non authentifié, 404 :
ressource non trouvée, 202 : succès de la requête) [12] [13].
4.2.1.4

Approches de création d’une APIS REST

Grâce à la communauté NodeJs très active, la quantité de résultats pour une recherche de
REST sur NPM est très importante mais chacun a sa propre implémentation et sa propre approche.
Nous avons comparé dans un premier temps des différentes approches qui permettent de créer une
application exposant une APIS REST.

— EXPRESS : EXPRESS est le framework standard pour le développement des applications Web
basé sur Node JS. L’approche la plus courante est de simplement créer des routes avec Express.
Sa caractéristique la plus avantageuse est sa large communauté très active et son inconvénient
majeur c’est le fait qu’il n’a rien de standard, toutes les routes doivent être créées manuellement :
nous devons toujours implémenter notre propre approche.

— HAPI : Hapi est un framework NodeJs moins connu qui prend de l’ampleur grâce au support
à plein temps de l’équipe de Wal-Mart Labs. Il prend une approche un peu différente de celle
d’Express en fournissant beaucoup plus de fonctionnalités hors du commun pour la construction
des services Web.

— LOOPBACK : LoopBack de « StrongLoop » est un framework de backend Node.js complet
pour connecter les applications aux données via des APIs REST.
29

Chapitre 4. Lancement du projet
C’est un framework hautement évolutif pour créer des APIs et les relier à des sources de données. Il
est construit au dessus d’Express et est livré avec un ensemble de modules NodeJs pour construire
des APIs REST pour des applications clientes. Parmi ses caractéristiques les plus avantageuses
nous pouvons citer :
Sa documentation très riche et complète, son explorateur API intégré que nous pouvons utiliser
pour parcourir facilement l’API que nous avons créée ainsi que ses modèles intégrés et prêts à
l’emploi.
La plus puissante fonctionnalité de Loopback, c’est en fait la génération d’une API REST
complète et bien documentée à partir d’un modèle défini, avec un ensemble d’opérations « CRUD
» de création ( POST), de lecture ( GET ), de mise à jour( UPDATE ) et de suppression (
DELETE ).[14] [15]
Choix
Après une comparaison de ces frameworks très connus et utilisés nous optons pour Loopback. C’est
le framework qui regroupe toutes les fonctionnalités dont nous avons besoin pour l’implémentation de
notre API REST ; et en plus nous pouvons utiliser EXPRESS en cas de besoin puisque Loopback est
construit au dessus de lui.

4.2.2

Le développement front-end

4.2.2.1

Angular 2

Angular 2.+ est l’un des frameworks le plus avancé pour le web crée par Google. Angular 2 est
le résultat de reconstruction d’AngularJS,développé avec TypeScript,et sa versions table était lancée
en 14 Septembre 2016.Angular 2 a apporté plusieurs améliorations par rapport à son prédécesseur
AngularJS avec des performances améliorées,une modularité accrue,du code plus expressif et un respect
des nouveaux standards du web.[16]
4.2.2.2

React

React est l’une des bibliothèques JavaScript les plus populaires développées par Facebook pour
construire des interfaces utilisateurs.React permet de créer des composants réutilisables pour construire
des interfaces graphiques.[17]
Comme nous avons déjà mentionné les deux critères choisis pour la comparaison sont la performance
et la modularité du code.En ce qui concerne la performance, la figure 4.5 montre une analyse du temps
nécessaire pour afficher un certain nombre d’articles.
L’analyse est faite pour comparer 4 framworks Angular2, AngularJS, ReactJS et Blaze, mais nous

30

Chapitre 4. Lancement du projet

Figure 4.5: Courbe de performance React VS Angular VS AngularJS VS Blaze
[18]
intéressons seulement aux résultats d’Angular 2 et ReactJS.
Selon la courbe, Angular est le plus performant, avec l’affichage de 50000 articles dans moins
de 1000 milli secondes.En outre, en ce qui concerne la modularité du code et la lisibilité, Angular
utilise TypeScript qui permet une meilleure organisation du code avec les interfaces et un typage
statique.Angular et React sont à base de composants ce qui permet d’avoir un code modulaire et
réutilisable.Après l’évaluation de ces deux critères,nous avons choisi Angular 2.
4.2.2.3

Librairies utilisés

Chart.js et 3D.js
Pour afficher les statistiques obtenues, nous avons besoin de dessiner plusieurs graphiques graphiques
qui forment les tableaux de bord. Une des bibliothèques les plus riches et stables pour faire cette tâche
est D3.JS et Chart.js.

4.2.3

Test et qualité de code

Dans cette partie, nous détaillons les choix des framework de tests.
4.2.3.1

Mocha

Mocha est un framework de test JavaScript exécuté sur Node JS. Nous l’avons utilisé pour
réaliser des tests d’intégration côté serveur de nos APIs REST [19].

31

Chapitre 4. Lancement du projet
4.2.3.2

Jasmine

Jasmine est un framework de test JavaScript exécuté sur Angular 2+. Nous l’avons utilisé pour
effectuer des tests fonctionnels côté client [20].
4.2.3.3

protractor

Protractor est un framework de test de bout en bout pour les applications angulaires. Protractor
exécute des tests contre votre application fonctionnant dans un vrai navigateur, en interagissant avec
elle comme un utilisateur.[21]

4.2.4

Les patrons de conception (Design Patterns)

La conception d’un projet est une préoccupation primordiale. Une des premières choses que
nous devrions considérer est l’architecture que nous envisageons d’adopter ; c’est le moyen de définir
comment les différents éléments de notre application se rapportent les uns aux autres et pour établir
les règles de base pour nous guider pendant le développement. Dans notre projet nous avons utilisé des
différents patrons de conception. Pour l’architecture de notre application Front-End, nous avons fait le
choix entre les deux patrons architecturaux les plus connus et les plus utilisés dans le développement
Web : MVVM [22].

4.2.4.1

MVVM : ( Model-View-View-Model )

MVVM est un design pattern très souvent utilisé ces derniers temps par des bibliothèques
JavaScript.
— Model : Le modèle inclut tout le code qui implémente la logique de l’application principale et
définit les types requis pour modéliser le domaine de l’application. Ce layer est complètement
indépendant des layer de modèle Vue et Vue.
— ViewModel : La couche ViewModel fournit des cibles de liaison de données pour la vue. Dans
de nombreux cas, le Modèle View expose directement le modèle ou fournit des membres qui
encapsulent des membres de modèle spécifiques. Le Modèle d’affichage peut également définir
des membres pour garder une trace des données pertinentes pour l’interface utilisateur, mais pas
pour le modèle, tel que l’ordre d’affichage d’une liste d’éléments.
— View : Le calque de vue définit l’interface utilisateur à l’aide du balisage déclaratif. Le balisage
de liaison de données définit la connexion entre des composants d’interface utilisateur spécifiques
et divers membres modèle Vue (et parfois modèles).

32

Chapitre 4. Lancement du projet

Figure 4.6: ArchitectureMVVM
[23]
La figure 4.6 résume donc l’architecture de design pattern MVVM.
4.2.4.2

Singleton

Le Design Pattern Singleton garantit qu’une classe ne possède qu’une seule instance, et fournit
un seul point d’accès à celle-ci. Nous l’avons utilisé dans la partie Front-End parce que nous avons
besoin d’une seule instance responsable de la consommation des Web Services.

4.3

Environnement de travail

Dans cette partie, nous présentons l’environnement matériel mis à la disposition du présent
projet ainsi que l’environnement logiciel qui a permis l’implémentation de notre application.

4.3.1

Environnement matériel

Notre projet n’exige pas un environnement matériel spécifique. Pendant la phase d’implémentation
on a utilisé un ordinateur portable avec les caractéristiques suivantes :
— Marque : Sony VAIO (Serie E, 15 pouces).
— Processeur : Intel Core i5 330M / 2.13 GHz - Mémoire Volatile : 4 giga octets.
— Mémoire de stockage : 500 Go 1600 MHZ DDR3.
— Graphisme : Intel iris 1536 Mo.
— Système d’exploitation : Windows version 10.

4.3.2

Environnement logiciel

Dans cette section, nous présentons les outils logiciels que nous avons utilisés tout au long de
notre projet.

33

Chapitre 4. Lancement du projet
4.3.2.1

Enterprise Architect

Enterprise Architect est un logiciel spécialisé dans la modélisation et la conception UML, édité
par la société australienne Sparx Systems. Il dispose d’une riche documentation et est destiné aux
analystes et aux développeurs pour les aider à concevoir des logiciels faciles à mettre à jour.
4.3.2.2

WebStorm

WebStorm est un IDE rapide et puissant pour le développement basé sur Node js.
Il offre de nombreuses fonctionnalités parmi lesquelles nous présentons :
— Une assistance intelligente du code.
— Un système de contrôle de versions avec une interface utilisateur dynamique.
— Des fonctionnalités de débogage et de test.
4.3.2.3

Bitbucket

Bitbucket est un système de contrôle de versions réparti, utilisé pour suivre notre projet et le
partager facilement avec toute l’équipe SCRUM.

34

Chapitre 4. Lancement du projet
4.3.2.4

MongoDB Compass

MongoDB Compass est conçu pour permettre aux utilisateurs d’analyser et de comprendre
facilement le contenu de leurs collections de données dans MongoDB et d’effectuer des requêtes, sans
nécessiter de connaissance de MongoDB.
4.3.2.5

Postman

Postman est une application qui permet avec un navigateur Web de lancer des appels d’API
et de les tester. Il dispose d’un environnement graphique complet et clair pour gérer l’ensemble des
interactions avec les API.
4.3.2.6

NPM : Node Package Manager

C’est le gestionnaire des paquets de NodeJs que nous avons utilisé pour installer nos dépendances
côté serveur. NPM dispose d’un fichier de configuration important nommé ’package.json’ qui décrit la
configuration du projet et contient la liste des dépendances avec leurs versions précises.

Conclusion
Durant ce chapitre, nous avons préparé le terrain pour la réalisation de notre projet. Nous avons
défini l’architecture de notre solution et présenté l’environnement de travail. Nous entamons dans le
chapitre suivant la phase de réalisation en se lançant dans le premier sprint.

35

Chapitre 5

Release 1

Plan
1

Présentation des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2

Sprint 1 : Proof of Concept G.A . . . . . . . . . . . . . . . . . . . . . . . . . 37

3

Sprint 2 : Méthode de collecte de données . . . . . . . . . . . . . . . . . . . 38

4

Sprints 3 et 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43



Documents similaires


examen
examen
examen 1
rapport pfa final
description d
outil de supervision de reseaux


Sur le même sujet..