RÉPUBLIQUE TUNISIENNE MINISTÈRE DE L’ENSEIGNEMENT

SUPÉRIEUR, ET DE LA RECHERCHE SCIENTIFIQUE

Mémoire de Projet de Fin d’études

Présenté en vue de l’obtention du Diplôme ingénierie informatique
Spécialité : génie logiciel

Gestion de projet et Développement

d’une application web pour gérer les
panneaux publicitaires connectés

Réalisé par : Ghassen BOUATTAY

Encadrant universitaire : Encadrant professionnel :

M.Khalil ben kalboussi M.Gafsaoui Houssem

2021/2022
 Résumé
Ce projet est réalisé au sein de SMARTEO. Il entre dans le cadre de notre ingénierie en génie
logiciel a l’EPI Polytechnique de sousse.. L’objectif principal est de bien gérer le projet avec
tous ses phases de développement ainsi la bonne synchronisation avec l’équipe en choisissons
une méthodologie adéquate .
La méthode du travail adoptée est une méthode agile à savoir le framework Scrum. On a
utilisé le langage de modélisation unifié (UML). Le développement de cette application est
effectué à l’aide des services web et du Framework Angular et nodeJS.
Mots clés : Gestion de projet, Agil, SCRUM, Angular, NodeJS, mongo db, DEVOPS,etc.

Abstract
Remerciements

2
Dédicace

3
Table des matières

Introduction générale 1

1 Cadre général du projet 3

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Les valeurs du SMARTEO . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Mission du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Analyse SWOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Tableau comparatif des méthodes agiles . . . . . . . . . . . . . . . . 9
5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Gestion de projet 10
1 Le framework "Scrum" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1 Les caracteristiques de Scrum . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Scrum Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 Fonctionnement de GitFlow . . . . . . . . . . . . . . . . . . . . . . . 13
2 ProjeQtOr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Discord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4
Table des matières 5

4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Phase de planification 17
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . 19
6 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Release 1 23
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 Le premier Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Spécification des besoins de sprint 1 . . . . . . . . . . . . . . . . . . 25
2.3 Conception de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4 les maquettes sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5 Review du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.6 Rétrospective du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . 36
3.0 Le deuxième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1 Spécification des besoins de sprint 2 . . . . . . . . . . . . . . . . . . 36
3.2 conception sprint2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3 Les maquettes sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4 Review du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5 Rétrospective du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . 54

5 Release 2 55
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.0 le premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.1 Spécification des besoins de sprint . . . . . . . . . . . . . . . . . . . 55
2.2 conception sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.3 Les maquettes sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Table des matières 6

2.4 Review du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.0 le deuxième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1 Spécification des besoins de sprint . . . . . . . . . . . . . . . . . . . 63
3.2 Conception de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.3 Les maquettes sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.4 Réviw du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.5 Rétrospective du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.0 diagramme de collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6 Phase de clôture 78
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.0 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.0 Technologie utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.1 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.2 NodeJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.3 ExpressJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.4 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.5 Service web REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.0 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1 Architecture opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2 Architecture applicative . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3 Architecture Web services . . . . . . . . . . . . . . . . . . . . . . . . 83
5.0 L’approche Devops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1 Approche d’intégration, livraison déploiement continus . . . . . . . . 85
6.0 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Conclusion 87
Table des figures

1.1 logo Smarteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Logo taxiora pub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Logo smartuos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Organigramme de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Liste des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 interface ledaips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 vision global scrum de la méthode Scrum. . . . . . . . . . . . . . . . . . . . 10

2.2 Caractéristique scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 scrum team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 sprint planing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 daily scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 git Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Mon espace Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8 logo ProjeQtor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.9 Fonctionalité de projeQtor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.10 Discord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

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

4.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . . . . . . . . . 25

4.2 Diagramme de cas d’utilisation « gérer les utilisateurs » . . . . . . . . . . . . 25
4.3 Diagramme de cas d’utilisation « gérer les rôles » . . . . . . . . . . . . . . . 27
4.4 diagramme de séquences authentification . . . . . . . . . . . . . . . . . . . . 29
4.5 Diagramme de séquence de "Créer un utilisateur" . . . . . . . . . . . . . . . 30

7
Table des figures 8

4.6 Maquette liste utilisateur avec filtre . . . . . . . . . . . . . . . . . . . . . . 31

4.7 Maquette ajouter utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.8 Maquette liste role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.9 maquette modifier role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.10 maquette Ajouter role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.11 Interface de l’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.12 Interface de la liste des utilisateurs avec filtre . . . . . . . . . . . . . . . . . 34
4.13 Interface d’ajout d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . 35
4.14 Interface Modification rôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.15 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . 36
4.16 Diagramme de cas d’utilisation « gérer groupe » . . . . . . . . . . . . . . . . 37
4.17 suivie écran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.18 Diagramme de cas d’utilisation « Gérer les taxis » . . . . . . . . . . . . . . . 41
4.19 Diagramme de séquence modifier taxi . . . . . . . . . . . . . . . . . . . . . 43
4.20 diagramme de séquence affecter groupe a un écran . . . . . . . . . . . . . . 44
4.21 Diagramme de séquence d’un capture d’écran . . . . . . . . . . . . . . . . . 45
4.22 Afficher message à l’écran . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.23 Maquette suivre écrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.24 Maquette d’ajout message temps réel . . . . . . . . . . . . . . . . . . . . . . 47
4.25 Maquette telecharger écran . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.26 Maquette modifier information écran . . . . . . . . . . . . . . . . . . . . . . 48
4.27 Maquette des informations taxi affecter à un écran . . . . . . . . . . . . . . 49
4.28 Interface réalisation liste des écrans . . . . . . . . . . . . . . . . . . . . . . . 49
4.29 Interface capture d’écran . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.30 interface list Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.31 interafce modifier Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.32 interface Ajouter group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.33 Interface affecter écran à un groupe . . . . . . . . . . . . . . . . . . . . . . 52
4.34 Interface de taxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.35 Interface ajoute taxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.36 Interface modifier taxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . . . . . . . . . 56

Table des figures 9

5.2 Diagramme de cas d’utilisation « consulter trace GPS » . . . . . . . . . . . . 57

5.3 Diagramme de séquences tracage GPS . . . . . . . . . . . . . . . . . . . . . 59
5.4 maquette cas utilisation trace GPS . . . . . . . . . . . . . . . . . . . . . . . 60
5.5 maquette cas utilisation trace GPS 2 . . . . . . . . . . . . . . . . . . . . . . 60
5.6 Interface Historique GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.7 Interface filtrage trace GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.8 Interface exemple résultat trace GPS . . . . . . . . . . . . . . . . . . . . . . 62
5.9 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . 63
5.10 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . 63
5.11 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . 64
5.12 Diagramme de cas d’utilisation « gérer les comptes clients » . . . . . . . . . 66
5.13 Diagramme de cas d’utilisation « gérer les médias » . . . . . . . . . . . . . . 67
5.14 Diagramme de séquences uplode médias . . . . . . . . . . . . . . . . . . . . 69
5.15 Diagramme de séquences Ajout client . . . . . . . . . . . . . . . . . . . . . 70
5.16 Maquette espace medias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.17 Maquette gérer media avec filtre . . . . . . . . . . . . . . . . . . . . . . . . 71
5.18 Maquette telecharger médias . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.19 Maquette choisir médias à telecharger . . . . . . . . . . . . . . . . . . . . . 72
5.20 Choisir list client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.21 Interface ajoute client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.22 Interface modifier client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.23 Interface list média . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.24 interafce telecharger média . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.25 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.26 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . 77

6.1 MEAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2 Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.3 NodeJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.4 ExpresseJs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.5 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.6 Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.7 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Table des figures 10

6.8 Architecture Api . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.9 L’aproche devops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.10 différence entre continuous deployment et continuous dilevery . . . . . . . . 86
Liste des tableaux

1.1 Tableau comparatif entre les méthodes agiles . . . . . . . . . . . . . . . . . . 9

4.1 Description textuelle de "Créer un utilisateur"" . . . . . . . . . . . . . . . . 26

4.2 Description textuelle de "Modifier rôle" . . . . . . . . . . . . . . . . . . . . . 28
4.3 Description textuelle de "désactiver un groupe " . . . . . . . . . . . . . . . . 38
4.4 Description textuelle de "lister les écrans " . . . . . . . . . . . . . . . . . . . 40
4.5 Description textuelle de "Modifier taxi " . . . . . . . . . . . . . . . . . . . . 42

5.1 Description textuelle de "Tracage GPS" . . . . . . . . . . . . . . . . . . . . 58

5.2 Description textuelle de "Consulter le tableau de bord" . . . . . . . . . . . . 65
5.3 Description textuelle de "Uplode média " . . . . . . . . . . . . . . . . . . . . 68

11
Introduction générale

L’amélioration de la qualité de service est un challenge que toute entreprise dans le do-
maine professionnel cherche à atteindre. Afin d’y parvenir, il est primordial d’utiliser de
nouvelles technologies d’informations et de communications afin d’améliorer, d’une part, le
fonctionnement et la visibilité des entreprises, et d’autre part pour garantir la fidélité des
clients. De plus, l’outil informatique gagne de plus en plus de place dans tous les secteurs
d’activité. Chacun déploie l’outil informatique pour optimiser la gestion de toutes les tâches
qui y font partie.
"Attendez-vous au meilleur, planifiez le pire et préparez-vous à être surpris !"
Cette citation de Denis Waitley attire notre attention à l’importance de planification et
adaptation à tout changement qui sont les deux clés pour atteindre l’objectif d’un projet sans
dépasser les dates limite ni le budget dans ce contexte on présente La gestion de projets qui
revient à trouver la réponse à quelques questions cruciales.
D’autre parties, le domaine de publicité avec toutes ses catégories a pleinement profité de
L’informatisation de ses activités et nous ne nous pouvons plus imaginer un tel secteur
démuni des outils logiciels. La publicité digitale désigne initialement la publicité effectuée
sur Internet et ses différents terminaux (ordinateurs, smartphones, tablettes, etc.) et qui se
fait essentiellement sous forme d’affichage publicitaire ou de liens commerciaux. En moins
de 10 ans, la publicité digitale s’est imposée comme le premier levier de communication des
annonceurs.
Pour notre cas, nous avons développé ce dernier type de publicité par le rendre dynamique
et déplaçable et surtout réel « interaction émotionnelle entre la publicité et le client »
L’innovation s’importe au niveau des écrans numériques ou digitaux utilisés pour diffuser
de la publicité en extérieur et qui sont capables d’afficher du texte, des animations, des
images, des vidéos et d’autres informations. Pour la première fois en Tunisie, des panneaux
publicitaires connectés situés sur les taxis
Dans ce cadre se situe notre étude qui concerne à gérer un projet de développement d’une
plateforme pour la gestion des écrans connectés. En effet, ce besoin a été ressenti suite aux
différents problèmes remarqués citons :
— L’estimation le temps de travaille.
— La bonne synchronisation avec l’équipe.
— L’absence de suivie des écrans.
— Le paramétrage des écrans.

1
Introduction 2

Pour résoudre ces problèmes, nous avons fait une étude théorique pour mieux concerner le
contexte de notre travail.

Cette étude fait partie des objectifs du notre rapport qui est subdivisé en cinq chapitres.
Le premier chapitre « Présentation du cadre générale » est consacré à la mise en relief du
cadre de développement de notre application. Au niveau de ce chapitre introductif, nous
allons décrire brièvement notre projet suivi d’une présentation de notre organisme d’accueil.
Nous effectuons par la suite, une étude de la méthode de travail au sein de l’organisation
ainsi afin de l’étudier d’une manière critique et présenter la méthode de travail adéquate, puis
nous étudions l’existant avec une critique de sorte que nous puissions présenter la solution
appropriée et nous présenterons la méthodologie choisie et la modélisation adoptée.
Le second chapitre «Gestion de projet », nous allons commencer par la présentation du
framework scrum avec leur différent évènement et acteur, en deuxième lieu nous présentons
le git flow et finalement notre outil de gestion de projet "Projeqtor".
Le Troisième chapitre «Étude préalable » ce chapitre est basé essentiellement a l’étude
du faisabilité de notre projet en faisons tous les analyses nécessaires. Le quatrième chapitre
«Planification », durent ce chapitre nous allons identifier les acteur de notre platforme ainsi
nos besoins fonctionnelle et non fonctionnelles et le backlog du produit le cinquième chapitre,
constitue le corps de notre application, il est consacré par le développement des releases de
notre système.
Le quatrième chapitre « a phase de clôture », sera notre dernier chapitre où nous allons
détailler tous les outils utilisés pour la conception et le développement de notre projet.

Enfin, nous clôturons ce rapport par une conclusion présentant une récapitulation du tra-
vail et nous exposerons par la suite de nouveaux horizons à ce projet en donnant quelques
perspectives futures.
Chapitre 1

Cadre général du projet

1 Introduction
Afin de bien assimiler les différents aspects de notre projet, d’une part nous allons présen-
ter l’entreprise d’accueil SMARTEO ceci permet ensuite de procéder à l’étude de méthode
de travail adapter par l’entreprise suivie d’une critique qui analyse les points faibles et les
problèmes rencontrés. En deuxième temps, nous exposons la méthode de travail proposée.
D’autre part nous allons étudier l’existions, d’une manière critique et présentation de la
solution proposée avec l’analyse nécessaire Enfin, nous présenterons la méthode de travail
adoptée.

2 Présentation de l’organisme d’accueil

Figure 1.1 – logo Smarteo

SMARTEO (figure1.1) est une entreprise d’électronique en Tunisie spécialisée dans la

conception et la fabrication de cartes électroniques et de systèmes embarqués Fondée en 2019
SMARTEO travail en collaboration avec TAXIORA-PUB et SMARTUOS affin de livrer un
produit fini "clé en main".

3
2. Présentation de l’organisme d’accueil 4

TAXIORA-PUB (figure1.2) est une société de service de marketing innovant basée sur
l’affichage dynamique des écrans connecter.

Figure 1.2 – Logo taxiora pub

SMARTUOS (figure1.3) est une société de développent web et mobile.

Figure 1.3 – Logo smartuos

L’organigramme de la société est le suivant :

Figure 1.4 – Organigramme de la société

3. Étude de l’existant 5

La figure 1.5 montre la liste des clients du TAXIORA-PUB

Figure 1.5 – Liste des clients

2.1 Les valeurs du SMARTEO

Le travail en équipe et toute clé de réussite,ça ce qui SMARTEO croit aussi en effet
chaque membre de notre équipe s’interviennent pour fixer finalement un objectif collectif.
L’esprit d’équipe, transparence, innovation et amélioration continue sont les valeurs de notre
organisme d’accueil.

2.2 Mission du stage

Nous avons rejoint l’équipe de SMARTEO sous la direction de Mr. SAADAOUI Walid
dans le cadre de notre ingénierie en génie logiciel a l’EPI Polytechnique de sousse. Notre
objectif est de gérer et développer le projet “TAXIORA PANNEAUX “.

3 Étude de l’existant
En achetant les panneaux d’affichage, la société de vente a mis à la disposition de notre
société «SMARTEO» une plateforme gratuite appelée « Ledaips » qui est présenter dans
la figure 1.6 pour gérer ces panneaux en proposant des différentes fonctionnalités. L’étude
de l’existant est consacrée pour étudier la plateforme « Ledaips » qui gère les panneaux
publicitaires. C’est une phase importante pour découvrir les mécanismes et les failles de la
plateforme web afin de pouvoir proposer une solution correspondante.
3. Étude de l’existant 6

Figure 1.6 – interface ledaips

3.1 Critique de l’existant

Le grand nombre de fonctionnalités intégrées dans cette plate-forme, dont certaines ne

sont pas nécessaires pour nous ainsi que d’autres fonctionnalités sont manquantes.un pro-
blème de charte graphique , nous avons également constaté que les interfaces de « Ledaips »
ne sont pas "utilisées convivialement" qui n’est pas très facile à utiliser.

On va évaluer la plateforme «Ledaips» à partir de ces critères :

— C1 : Temps réel mise à jour : rafraîchissement automatique et en temps réel des
données.
— C2 : Interface graphique : l’aspect graphique d’un site est un point très important.
Le site doit respecter la norme de qualité IHM (Interface Homme-machine), il doit
apporter une image moderne et attirante.
— C3 : Générale / spécialisée :
— Générale (G) : la plateforme permet de gérer tous les types de publicités.
— Spécialisée (S) : la plateforme est spécifique dans la gestion des panneaux publici-
taires.
— C4 : Qualité technique : accessibilité, efficacité, performance, fiabilité et stabilité.
3. Étude de l’existant 7

Figure 1.7 – évaluation

3.2 Présentation du sujet

La commercialisation est définie comme un ensemble de mesures axées sur un produit et
prend un axe très important pour les entreprises en effet, les entreprises cherchent toujours
à rester dans l’imagination des consommateurs. Ainsi de gérer leur publicité elle-même pour
cela notre société SMARTEO cherche mis en place des écrans publicitaires connectés ainsi à
créer des outils de suivi ces écrans pour répondre et résoudre les problèmes clientèle. L’ap-
plication demandée s’intitule TAXIORA PANNEAUX, elle a pour objectif la Conception et
développement d’une plate-forme de gestion autour panneaux publicitaires connectés .
La mise en place de « TAXIORA PANNEAUX » nécessite le développement de trois axes à
savoir :
— Axe de gestion de projet : Utilisation de la méthode agile Scrum.
— Axe de modélisation conceptuelle : Utilisation du langage de modélisation UML (Uni-
fed Modeling Langages).
— Axe de développement : Utilisation du Framework ANGULAR et node js

3.3 Solution proposée

Suite aux constatations faites à l’issue de l’étude de la situation existante, et pour répondre
à ces défis, SMARTEO a décidé de mettre en œuvre une application web qui doit répondre
le mieux possible à ses besoins et à ses priorités. Notre projet propose une solution simple,
son but est d’aider l’entreprise à utiliser une plateforme plus adéquate en améliorant les
fonctionnalités existantes et en ajoutant des autres fonctionnalités essentielles comme la
gestion des clients, taxis, rôles. pour mettre en place notre solution avec moins de risques,
nous avons essayé d’effectuer les analyses nécessaires.
4. Méthodologie de travail 8

3.4 Analyse SWOT

Premièrement, nous tentons de procéder à une analyse SWOT de la solution proposée

identifier correctement les forces et les faiblesses, c’est garantir leur succès.
Nous représentons représente L’analyse SWOT de "TAXIORA PANNEAU".
Forces :
— capacité d’innovation.
— calcule statistique.
— le premier sur le marché tunisien.
— clarté avec les clients, en effet il est possible de contrôler la zone de diffusion des écrans
afin de les gérer à distance.

Faiblisse
— Certain zone ne retourne pas les cordonner GPS
— On ne peut pas communiquer avec la carte que si elle est connectée.

Opportunité
— développement de nouveau service a forte valeur ajouter
— un marché tunisien libre.

Menaces
— faiblesse des activités économiques
Après la réalisation de cette analyse on indique les points qu’on va l’exploiter pour assurer
la réussite de notre projet ainsi les points qu’on doit travailler plus pour diminuer le risque.

4 Méthodologie de travail

La méthodologie Agile est généralement opposée à la méthodologie en cascade classique

(l’approche Développement logiciel linéaire). Il veut être plus flexible et adapté, et met les
besoins du client au centre des priorités du projet. À l’origine, cette approche a été créée
pour les projets de développement web et informatique. Aujourd’hui, la méthode Agile est de
plus en plus répandue, car elle est adaptable à de nombreux types de projets, tous secteurs
confondus. Le manifeste Agile prône les 4 valeurs fondamentales de la méthodologie :
— L’équipe, soit des individus et des interactions plutôt que des processus et des outils
— L’application, c’est-à-dire des fonctionnalités opérationnelles plutôt que de la docu-
mentation exhaustive
— La collaboration avec le client plutôt que la contractualisions des relations
— L’acceptation du changement plutôt que le suivi d’un plan.
5. Conclusion 9

4.1 Tableau comparatif des méthodes agiles

Pour choisir la méthode agile la plus appropriée pour notre projet, nous avons effectué
une étude comparative des trois méthodes agiles les plus courantes présentées dans le tableau.
1.1 [1].

tableau 1.1 – Tableau comparatif entre les méthodes agiles

5 Conclusion
Dans ce chapitre, nous avons présenté la société d’accueil, avec une étude de la méthode
de travail ainsi l’existons, tout en effectuer un critique pour bien comprendre les besoins
manque au sein de notre organisme d’accueil ainsi sur le marché, en effet chaque innovation
et baser sur un critique pour terminer avec une proposition d’une méthode de gestion de
projets adéquats. Dans le suivant chapitre, nous présenterons le Framework qui s’adaptera à
la concrétisation de notre projet.
Chapitre 2

Gestion de projet

1 Le framework "Scrum"
Afin de répondre aux besoins évolutifs du besoins, notre choix s’est porté sur le framework
« Scrum». Ce framewok permet surtout de faire face aux différents problèmes qui font surface
lors de l’exécution du projet allant d’une mauvaise planification aux changements fréquents
des besoins.
Ainsi, on a choisi le framewok Scrum, car le développement logiciel est une activité complexe,
et Scrum permet de faire face à cette complexité par l’empirisme et elle a une vraie valeur
ajoutée dans le travail de l’équipe. pour bien appliqué le framework adapté j’ai choisi en pre-
mier lieux de faire une formation pour l’équipe de SMARTEO sur le notions de Agile et scrum.

Figure 2.1 – vision global scrum de la méthode Scrum.

10
1. Le framework "Scrum" 11

1.1 Les caracteristiques de Scrum

Figure 2.2 – Caractéristique scrum

1.2 Scrum Team

le point fort de Scrum est une petite équipe, la Scrum Team. La Scrum Team se compose
d’un Scrum Master, d’un Product Owner,un proxy product owner et des Développeurs. on
ne peut pas trouver une équipe dans une autre ou bien une hiérarchie entre eux. Il s’agit
d’une seule et même unité stable, composée de professionnels focalisés sur le même objectif
. le figure 2.3 présente notre scrum team :

Figure 2.3 – scrum team

1. Le framework "Scrum" 12

1.3 Sprint Planning

La planification du Sprint Démarre le Sprint en indiquant ce qui doit être fait pendant
ce Sprint. Le plan qui en résulte est crée par toute l’équipe Scrum en collaboration La mise
en page du sprint couvre les sujets suivants :

Figure 2.4 – sprint planing

La mise en page du sprint couvre les sujets suivants L’objectif de Sprint, les éléments du
Product Backlog sélectionnés pour le Sprint, ainsi que le plan pour les livrer, correspondent
à un ensemble appelé le Sprint Backlog.
il est imortant de noter que Le Sprint Planning est limité dans le temps à un maximum de
huit heures pour un Sprint d’un mois. Pour les Sprints plus courts, l’événement est généra-
lement plus court.

1.4 Daily Scrum

Le but du Daily Scrum est de vérifier la progression vers le Sprint et d’ajuster d’adapter
le Sprint Backlog si nécessaire, ajuster les travaux futurs prévus. Le Daily Scrum est un
événement de 15 minutes, pour les Developers de la Scrum Team.animé par le scrum master
au cour de cette réunion trois principal question le scrum master propose
— qu’est-ce que vous avez fait hier ?
— dont est-ce que vous allez fait Aujourd’hui ?
— qu’est-ce qu’il ya des problèmes
1. Le framework "Scrum" 13

Figure 2.5 – daily scrum .

1.5 Fonctionnement de GitFlow

GitFlow est un ensemble de règles simples qui se basent sur le fonctionnement par branche
de Git. Notre projet sera basé sur deux branches : master et develop. Ces deux branches sont
strictement interdites en écriture aux développeurs.
La branche master est le miroir de notre production. Il est donc logique que l’on ne puisse y
pousser nos modifications directement.
La branche develop centralise toutes les nouvelles fonctionnalités qui seront livrées dans la
prochaine version. Ici il va falloir se forcer à ne pas y faire de modifications directement.
Trois autres types de branches vont ensuite nous permettre de travailler :
— feature
— release
— hotfix
La figure 2.7 présente notre espace git pour créer les différents version de notre projet
2. ProjeQtOr 14

Figure 2.6 – git Flow .

Figure 2.7 – Mon espace Git

2 ProjeQtOr
Aprés une démonstration des fonctionnalités de PROJEQTOR a l’équipe de SMARTEO
nous avons décider de l’utiliser comme outil de gestion des projets pour notre projet.
ProjeQtOr est un Logiciel de gestion de projet open source, qui regroupe dans un outil unique
toutes les fonctionnalités nécessaires à l’organisation de vos projets. Il reste simple, facile à
utiliser au quotidien, tout en couvrant un maximum de fonctionnalités de la gestion de projet.
Sa particularité, outre sa complète, est d’être orienté qualité. Ceci signifie qu’il vous
permet d’enregistrer tous les événements de vos projets, et de simplifier de ce fait la mise en
conformité aux principaux standards de gestion de la qualité
nous utilisons cet outil pour gérée notre product backlog, gérer les rôle et affecter les tache au
développeur, de plus chaque développeur peut tracer chaque jour l’avancement de ces tache
qui nous aidons a suivi l’avancement de tous le projet grâce a des indicateur et le diagramme
de Gant.
3. Discord 15

Figure 2.8 – logo ProjeQtor .

le figure ci dessou explique les différents fonctionnalités de notre outils de gestion de projet
ProjeQtor [2].
La figure 2.9 présente les différents fonctionamlités offert par projeQtor [2].

Figure 2.9 – Fonctionalité de projeQtor.

3 Discord
Au cour de la réalisation de notre projet nous avons choisir discord, qui est un logiciel
propriétaire gratuit de VoIP et de messagerie instantanée. Il fonctionne sur les systèmes
d’exploitation Windows, macOS, Linux, Android, iOS ainsi que sur les navigateurs web. La
plateforme comptabilise le 21 juillet 2019 plus de 250 millions d’utilisateurs [3], comme outil
de communication entre l’équipe comme montre le figure 2.10,pour la gestion des version avec
git de telle sorte que chaque push chaque membre de l’équipe sera notifier comme represente
la figure suivante
4. Conclusion 16

Figure 2.10 – Discord

4 Conclusion
Pendant ce chapitre, nous avons détaillé le cadre de scrum, ainsi que les outils de gestion
de projet que nous utiliserons pour gérer "TAXIORA PANNEAU".Le chapitre suivant sera
dédier pour la spécification des besoins détailler de notre projet qui est la premier activité
du processus unifié.
Chapitre 3

Phase de planification
1 Introduction

La phase de spécification des besoins est une étape primordiale pour realiser une applica-
tion avec succès. Dans ce chapitre, nous identifions d’abord les differents acteurs impliquées
dans notre application ainsi que leurs besoins fonctionnels représente es par les cas d’utilisa-
teur. Ensuite, nous specifions le diagramme de cas d’utilisateur et le Product Backlog. Enfin,
nous presentons les besoins non fonctionnels ‘a prendre en consideration dans la phase de
ddéveloppemen.

2 Identification des acteurs

Un acteur est une personne, un materiel ou un logiciel qui interagit avec le système afin
d’obtenir une valeur ajoutee. Les acteurs interagissant avec notre système sont :

— Administrateur :est le responsable des différents paramétrages de l’application.Il a

un contrôle absolu et l’accès total à toutes les fonctionnalités et les services offerts par
le système. Il a la charge d’administrer tous les aspects de l’application.

— Commercial :Le commercial a le même privilège que le designer, mais il peut gérer
des fonctionnalités supplémentaires par rapport au designer qui sont la gestion des
clients, la gestion des taxis, le suivi des écrans et suivi de traçage GPS de l’écran.

— Designer :Il a l’accès à certaines fonctionnalités de la plateforme qu’il puisse gérer

comme la gestion des médias, car c’est généralement le designer qui est responsable
d’accepter ou de refuser un média ainsi que d’autres fonctionnalités dans le média.
Aussi, il a le droit de consulter le tableau de bord et de voir des statistiques de l’écran.

17
3. Besoins fonctionnels 18

3 Besoins fonctionnels
Les besoins que notre application doivent répondre à trois volets : ceux propres à l’ad-
ministrateur, le commercial et le designer Dans ce qui suit nous allons présenter toutes les
fonctionnalités : Notre application permet ‘a ses utilisateurs d’effectuer les opérations sui-
vantes :
— Gérer les utilisateurs :L’administrateur peut ajouter un contact comme étant un
autre utilisateur, peut aussi modifier, supprimer, chercher ou consulter un/des utili-
sateur.

— Gérer les taxis : L’administrateur ou le commercial peut ajouter un contact comme

étant un taxi , peut aussi modifier, supprimer, chercher ou consulter un/des taxi ainsi
affecter un taxi a une écran .

— Gérer médiats :l’administrateur ,désigner ou commercial peut uploder un nouveau

médias ,tester et télécharger dans pc .

— Suivie des écrans :l’administrateur ou le commercial peut consulter fiche écrans et

effectuent différents actions pour chaque écran capture d’écran ,état de matériel ,live
,Message en temps réel,trace Gps ,information taxi ...

— Gestions des clients : l’administrateur peut gérer les clients (ajout/modifier/activer/désactiver).

— Consulter map :l’administrateur ,désigner et commercial peuvent consulter le map

afin de suivre la circulation des écrans ainsi leur historique.

— Consulter le tableau de bord :l’administrateur ou commercial peut consulter le

tableaux de bord pour voir les informations concernant le nombre des taxis , nombre
des écrans ..

— Consulter statistiques :l’administrateur ou commercial peut consulter les statis-

tique pour voir l’information concernant les statistiques activité écran,statistique zone
de circulation .

4 Besoins non fonctionnels

Outre les fonctionnalités essentielles devant être réalisées dans notre application, celle-ci
doit respecter certaines contraintes et répondre à certains besoins non fonctionnels :

— L’ergonomie des interfaces et la facilité d’utilisation : l’application doit être

simple et présente des interfaces conviviales et ergonomiques et pas trop compliquées.
5. Diagramme de cas d’utilisation global 19

— Probabilité et intégralité : l’application doit impérativement fonctionner sur Les

supports différents(portable,tablette,pc..) et sur les diffèrent systèmes d’exploitation.

— La performance : doit assurer la rapidité des activités et leurs fiabilités et être ca-
pable de manipuler un grand nombre d’enregistrements.

— La maintenabilité : Le code doit être suffisamment clair pour permettre des éven-
tuelles évolutions, améliorations ou corrections.

— La sécurité : L’application doit garantir à l’utilisateur l’intégrité et la confidentialité

de ses données.

— Interface graphique et riche :l’utilisateur doit trouver une interface élegante, bien
structure, moderne d’une part et simple ‘a manipuler d’autre part.

5 Diagramme de cas d’utilisation global

La figure 3.1 expose les différentes fonctionnalités que doit offrir le système
l’administrateur et au utilisateur.
5. Diagramme de cas d’utilisation global 20

Consulter le tableau de
bord (dashboard)

Gérer les médias

«include»

«include»
Designer Gérer les clients

«include»

Suivie des écrans «include» S'authentifier

«include»

Commercial Gérer les taxis

«include»

Suivi de trace GPS

«include»

Gérer les utilisateurs

Administrateur

Gérer les paramètres

«extends» «extends»

Gérer les groupes Gérer les roles

Figure 3.1 – Diagramme de cas d’utilisation global

6. Planification 21

6 Planification
A partir des réunions, nous avons divisé le projet en des releases et des sprints. Chaque
sprint regroupe à son tour un ensemble de tâches. Nous avons élaboré un calendrier de
réalisation comme montré dans le tableau ci-dessous.

ID sprint Fonctionnalités
Release 1
Sprint 1 :
— lister/Ajouter/modifier/(activer/désactiver)
gestion des utilisateurs
utilisateur
gestion des rôles
— lister/Ajouter/modifier/(activer/désactiver)
login
rôle

Sprint 2 :
gérer les groupes — lister/Ajouter/modifier/
gérer les taxis (activer/désactiver) groupe
suivie des écrans — lister/Ajouter/modifier/(activer/désactiver)
taxi
— éteindre l’écran
— capture d’écran
— message en temps réelle
— interrupteur d’avertissement

Release 2
Sprint 3 :
— consulter tracking
Trace GPS
— consulter historique circulation

Sprint 4 :
— lister/Ajouter/modifier/(activer/désactiver)
gestion des clients
client
Gestion des médias de dash-
— uplode médias
board
— tester médias
— Consulter les statistiques
— Consulter le tableau de bord
7. Conclusion 22

7 Conclusion
Nous avons présenté le Backlog du produit qui sera notre référence fondamentale dans le
reste du travail. Dans l’étape suivante, nous présentons les différents sprints. En partant du
Backlog du produit défini, nous précisons la liste des tâches à exécuter à chaque sprint.
C’est le Backlog Sprint qui est une référence de chaque sprint en passant de l’analyse et la
conception vers la réalisation. Le résultat sera alors un produit partiel testé et potentielle-
ment livrable. Les sprints sont présentés dans les chapitres suivants.
Chapitre 4

Release 1
1 Introduction
Le terme release peut être défini comme une période de temps qui permet de produire une
version distribuée d’une application. Un release est constitué d’une suite d’itérations (sprint)
qui se terminent quand les incréments de ces derniers construisent un produit.
Dans ce chapitre, nous allons présenter le travail réalisé lors du premier sprint comportant
une phase de planification et les différentes taches tout en spécifiant à chaque sprint les
différentes parties : Backlog sprint, analyse des besoins, conception , sprint reviw et sprint
rétrospective

2 Le premier Sprint
Selon la planification établie, le premier Sprint porte principalement sur les cas d’utilisa-
tion suivants :
— « Gérer les utilisateurs »
— « Gérer les rôles »

23
2. Le premier Sprint 24

2.1 Backlog du sprint 1

Le tableau présente le Backlog du premier sprint.

IDUS Tâches estimation

US1 5
— Api :get/user +filtre
— Front : Lister les utilisateurs avec filtres

US2 3
— Api : post add user
— Front : Formulaire d’ajout user

US3 5
— Api :envoie lien pour créer un mot de passe
— Formulaire ajout mot de passe /confirma-
tion mot de passe (prototype figma)

US4 3
— Api :Put edit user
— Formulaire edit (remplir)

US5 3
— Api :Put édit user
— Formulaire édit (remplir)

US6 2
— Api :envoie lien pour créer un mot de passe
— Formulaire champ mail

US7 1
— Api :put édit satus

US8 1/2
— Sélect rôle

US10 — 2

US11 1
— API :get/role

US12 1/2
— (activer/ désactiver role )
2. Le premier Sprint 25

2.2 Spécification des besoins de sprint 1

2.2.1 Diagramme du cas d’utilisation du sprint 1

La figure suivante présente de diagramme du cas d’utilisation du premier sprint.

Figure 4.1 – Diagramme de cas d’utilisation du sprint 1

2.1.2 Diagrammes de cas d’utilisation raffinés

• Cas d’utilisation « gérer les utilisateurs »

L’administrateur gère les comptes utilisateurs en créant, modifiant, (activer/désactiver).
comme il montre la figure ce dessous :

Figure 4.2 – Diagramme de cas d’utilisation « gérer les utilisateurs »

2. Le premier Sprint 26

Après son authentification, l’administrateur a l’autorisation de gérer les utilisateurs. Dans

la section suivante nous allons intéresser à la création ,la modification l’état et la modification
les informations d’un compte utilisateur.
Le tableau présente la description textuelle détaillée du cas d’utilisation
«Créer un utilisateur ».

Sommaire
Nom Créer un utilisateur
Objectif La création d’un nouveau utilisateur
Acteur principal L’administrateur
Description des scénarios
Les prés conditions l’administrateur authentifié
Les post conditions Un nouveau utilisateur est ajouté avec
succès
Scénario nominal Scénario alternatif
10.1 L’administrateur n’a pas saisi les
bons identifiant : le système renvoie un
1 Le système affiche la page d’accueil. message d’erreur et signale à le com-
2 L’administrateur choisit la liste des utilisateurs. mercial de recommencer
3 Le système envoie la liste des utilisateurs.
4 L’administrateur choisit l’option
« Ajouter un utilisateur ».
5 Le système retourne le formulaire de
création d’un utilisateur.
6 L’administrateur saisit les informations
des utilisateurs
8 L’administrateur confirme l’ajout.
9 Le système valide les informations saisies.
10 Le système ajoute l’organisation.

tableau 4.1 – Description textuelle de "Créer un utilisateur""

2. Le premier Sprint 27

• Cas d’utilisation « Gérer rôle »

Figure 4.3 – Diagramme de cas d’utilisation « gérer les rôles »

2. Le premier Sprint 28

Sommaire
Nom Modifier rôle
Objectif Modification du rôle
Acteur principal l’administrateur
Description des scénarios
Les prés conditions l’administrateur authentifié
Les post conditions Un rôle est Modifier avec succès
Scénario nominal Scénario alternatif
L’administrateur n’a pas saisi les bons
identifiant :le système renvoie un mes-
1 Le système affiche la page d’accueil. sage d’erreur et signale à le commercial
2 L’administrateur choisit la liste des rôles. de recommencer
3 Le système envoie la liste des rôles .
4 L’administrateur choisit l’option
« Modifier Rôle ».
5 Le système retourne le formulaire de
l’édition avec les champs remplies .
6 L’administrateur saisit nouveaux les informations
du rôle
8 L’administrateur confirme l’édition .
9 Le système valide les informations saisies.
10 Le système ajoute l’organisation.

tableau 4.2 – Description textuelle de "Modifier rôle"

2.3 Conception de sprint 1

Dans cette section, nous visons à détailler le contenu des différents composants de sprint1
et les relations entre eux.
Pour ce faire, plusieurs diagrammes UML, selon l’architecture MVC(voir annexe 1),sont utili-
sés pour mettre en relief l’aspect statique et dynamique présenté par le diagramme de classes
et séquences.

2.3.1 Diagrammes de séquence

Les diagrammes de séquences sont la représentation graphique des interactions entre les
acteurs et le système selon un ordre chronologique dans la formulation UML. Dans ce qui
suit, nous présentons le diagramme de séquence pour chaque cas d’utilisation dans notre
système
2. Le premier Sprint 29

• Diagramme de séquence de « Authentification »

Pour accéder en espace le administrateur passe en premier lieu par un formulaire d’authenti-
fication ou il s’saisie son identifiant et son mot de passe. Ces données sont transférées vers la
classe de contrôle « Security Controller » qui sera chargé de vérifier l’existence de l’utilisateur
vue à le modèle «securityManager ».
Le diagramme de la figure 4.4 est un diagramme de séquence pour le cas s’authentifier

Figure 4.4 – diagramme de séquences authentification

2. Le premier Sprint 30

• Diagramme de séquence de « Créer un utilisateur»

Le diagramme de la figure 4.5 est un diagramme de séquence pour le cas d’utilisation créer
utilisateur.

Figure 4.5 – Diagramme de séquence de "Créer un utilisateur"

2. Le premier Sprint 31

2.4 les maquettes sprint 1

Les maquettes sont incontinents représentations graphiques lequel permet d’illustrer vi-
suellement une jonction web une utilisation portable soit seule production d’autres termes les
maquettes sont incontinent images modifiables lesquelles offrent la capacité pour concevoir
incontinent mises de conjoncture peu proche due dénouement dernier et pour mieux faciliter
le travail on a essai de faire les maquettes pour chaque cas d’utilisation

Figure 4.6 – Maquette liste utilisateur avec filtre

2. Le premier Sprint 32

Figure 4.7 – Maquette ajouter utilisateur

Figure 4.8 – Maquette liste role

2. Le premier Sprint 33

Figure 4.9 – maquette modifier role

Figure 4.10 – maquette Ajouter role

2. Le premier Sprint 34

2.5 Review du sprint 1

Dans cette partie, nous allons présenter quelques interfaces graphiques du sprint 1. Nous
avons réalisé 4 interfaces, qui sont :

•L’interface d’authentification
Chaque utilisateur de notre application doit s’authentifier.

Figure 4.11 – Interface de l’authentification

• L’interface de la liste des utilisateurs

L’administrateur liste tous les utilisateurs, avec leurs informations.

Figure 4.12 – Interface de la liste des utilisateurs avec filtre

2. Le premier Sprint 35

•L’interface liste des rôles

L’administrateur lister les rôles sous forme des widget.

Figure 4.13 – Interface d’ajout d’un utilisateur

•L’interface de modification rôle

L’administrateur modifier des rôles .

Figure 4.14 – Interface Modification rôle

3.0. Le deuxième sprint 36

2.6 Rétrospective du sprint 1

Lors de notre premier sprint ,nous étions fortemment alignés sur notre objectif et notre
maission. Cependant, a cette étape ,nous avons du faire face a quelque limites du travail.Face
a ces limites en tant que équipe nous réalisons que si nous voulions travailler plus efficacement
et livrer rapidement l’incriment , nous devions avoir plus de temps pour le sprint planing pour
assure le bon compréhension du besoin.

3.0 Le deuxième sprint

Selon la planification établie, le premier Sprint porte principalement sur les cas d’utilisa-
tion suivants :
— gérer taxis
— gérer groupe
— suivie écran

3.1 Spécification des besoins de sprint 2

A la fin de ce sprint, tout l’administrateur peuvent gérer les groupes et les taxis et suivre
aussi le écrans . Ainsi ils peuvent faire plusieurs action sur l’écran comme capture d’écran
,message en temps réelle éteindre l’écran.

3.1.1 Diagramme du cas d’utilisation du sprint 2

La figure 4.15 présente de diagramme de cas d’utilisation du deuxième sprint

Figure 4.15 – Diagramme de cas d’utilisation du sprint 2

3.0. Le deuxième sprint 37

3.1.2 Diagramme de cas d’utilisation raffinés

• Gérer groupe
Un commercial peut gérer les groupes pour les écrans (créer, modifier, supprimer, consulter. . .
etc.) comme montre la figure 4.16 :

Figure 4.16 – Diagramme de cas d’utilisation « gérer groupe »

3.0. Le deuxième sprint 38

Après son authentification, l’utilisateur a l’autorisation de gérer groupes . Dans la section

suivante nous allons nous intéresser à l’activation/désactivassions d’un groupe .
Le tableau 5.2 présente la description textuelle détaillée du cas d’utilisation «activer/désactiver
groupe »

Sommaire
Nom désactiver un groupe
Objectif désactiver un groupe
Acteur principal l’administrateur
Description des scénarios
Les prés conditions L’utilisateur authentifié
Les post conditions un groupe est désactiver
Scénario nominal Scénario alternatif
6 L’utilisateur ne peux pas désactiver un
groupe en cas de problème le système renvoie
1 Le système affiche la page d’accueil un message d’erreur et signale au l’adminis-
2 l’administrateur choisi le groupe a désactiver trateur de recommencer
3 Le système envoie un message de confirmation
4 L’utilisateur choisi l’option « valider »
5 Le système retourne un message de succès

tableau 4.3 – Description textuelle de "désactiver un groupe "

3.0. Le deuxième sprint 39

• Cas d’utilisation « lister les écrans »

L’utilisateur permet de consulter la liste des écrans .
Le tableau 4.4 présente la description textuelle détaillée du cas d’utilisation
«lister les écrans »

Figure 4.17 – suivie écran

3.0. Le deuxième sprint 40

Sommaire
Nom lister les écrans
Objectif La création d’un commen-
taire sur une publication a
partir d’une page Facebook
Acteur principal L’utilisateur ou l’adminis-
trateur
Description des scénarios
Les prés conditions L’utilisateur est bien au-
thentifié
Les post conditions la liste des écrans est bien
affiché
Scénario nominal Scénario alternatif

1 Le système affiche la page d’accueil L’utilisateur n’a pas bien insérer le message
2 L’utilisateur choisit le menue suivie écran
3 Le système envoie la liste des écrans

tableau 4.4 – Description textuelle de "lister les écrans "

3.0. Le deuxième sprint 41

• Cas d’utilisation « gérer les taxis » :

l’administrateur peux gérer les taxis comme il est présenté dans la figure ce dessous.

Figure 4.18 – Diagramme de cas d’utilisation « Gérer les taxis »

Le tableau 4.5 présente la description textuelle détaillée du cas d’utilisation

« modifier taxi »
3.0. Le deuxième sprint 42

Sommaire
Nom Modifier taxi
Objectif L’administrateur peux mo-
difier un taxi
Acteur principal administrateur
Description des scénarios
Les prés conditions L’utilisateur est authentifié
Les post conditions un taxi est modifier
Scénario nominal Scénario alternatif
8.1 L’utilisateur n’a pas
bien insérer le message : le
1 Le système affiche la page d’accueil système renvoie un message
2 L’utilisateur choisit la page facebook d’erreur et signale au utilia-
pour gérer sa boite de réception teur de recommencer
3 Le système envoie la boite de réception
4 L’utilisateur consulte les messages et
il ouvre la discussion pour envoyer un message
5 L’utilisateur créer un message
7 L’administrateur confirme l’envoie du message
8 Le système valide le message envoyés

tableau 4.5 – Description textuelle de "Modifier taxi "

3.2 conception sprint2

Dans cette section, nous visons à décrire les différents composants de sprint 2 et les
relations entre eux par le biais de séquences.

3.2.1 Diagrammes de séquence

• Diagramme de séquence de « Modifier Taxi »

l’administrateur ou le commercial peut modifier les informations de taxis,comme montre la
figure suivant
3.0. Le deuxième sprint 43

Figure 4.19 – Diagramme de séquence modifier taxi

• Diagramme de séquence de « cas utilisation affecter écran a un groupe »

l’administrateur ou le commercial peux affecter un écran a un groupe , comme montre la
figure ce dessous qui représente la zone de circulation des taxi par exemple le groupe de
sousse représente les taxis qui circulons a sousse
3.0. Le deuxième sprint 44

Figure 4.20 – diagramme de séquence affecter groupe a un écran

• Diagramme de séquence de « cas utilisation capture d’écran »

l’administrateur ou le commercial peux faire un capture d’écran , comme montre la figure ce
dessous
3.0. Le deuxième sprint 45

Figure 4.21 – Diagramme de séquence d’un capture d’écran

• Diagramme de séquence de « Message temps réelle »

l’administrateur ou le commercial peux envoyer et afficher un message en temps réelle ,
comme montre la figure ce dessous
3.0. Le deuxième sprint 46

Figure 4.22 – Afficher message à l’écran

3.0. Le deuxième sprint 47

3.3 Les maquettes sprint 2

Figure 4.23 – Maquette suivre écrans

Figure 4.24 – Maquette d’ajout message temps réel

3.0. Le deuxième sprint 48

Figure 4.25 – Maquette telecharger écran

Figure 4.26 – Maquette modifier information écran

3.0. Le deuxième sprint 49

Figure 4.27 – Maquette des informations taxi affecter à un écran

3.4 Review du sprint 2

Figure 4.28 – Interface réalisation liste des écrans

3.0. Le deuxième sprint 50

Figure 4.29 – Interface capture d’écran

Figure 4.30 – interface list Group

3.0. Le deuxième sprint 51

Figure 4.31 – interafce modifier Group

Figure 4.32 – interface Ajouter group

3.0. Le deuxième sprint 52

Figure 4.33 – Interface affecter écran à un groupe

Figure 4.34 – Interface de taxi

3.0. Le deuxième sprint 53

Figure 4.35 – Interface ajoute taxi

Figure 4.36 – Interface modifier taxi

3.0. Le deuxième sprint 54

3.5 Rétrospective du sprint 2

Lors de notre deuxième sprint ,nous étions fortemment alignés sur notre objectif et notre
maission. Cependant, a cette étape ,nous avons du faire face a quelque limites du travail.Face
a ces limites en tant que équipe nous réalisons que si nous voulions travailler plus efficacement
et livrer rapidement l’incriment , nous devions avoir plus de temps pour le sprint planing pour
assure le bon compréhension du besoin.
Chapitre 5

Release 2
1.0 Introduction
Dans ce chapitre, nous allons présenter le travail réalisé lors du deuxième release compor-
tant les différentes parties : Backlog sprint, spécification des besoins, conception et réalisation.
Ce Release touche les cas d’utilisation
— « tracking GPS »
— « gestion des clients »
— « gestion des médiats »
— « Gestion de dashboard »

2.0 le premier sprint

2.1 Spécification des besoins de sprint

Ce sprint sera dédié à la suivie du tracking gps par l’administrateur ou le commercial

2.1.1 Diagramme du cas d’utilisation du sprint 1

La figure suivante présente de diagramme de cas d’utilisation du sprint 1

55
2.0. le premier sprint 56

Figure 5.1 – Diagramme de cas d’utilisation du sprint 1

2.0. le premier sprint 57

2.1.2 Diagrammes de cas d’utilisation raffinés

• Cas d’utilisation « consulter traces GPS »

l’administrateur ou le commercial peut consulter le trace GPS de tous les ecrans le derniers
24h ou bien faire obtenir le trace GPS aprés un choix du groupe ,l’écran ,un date début ,un
date de fin comme il montre la figure suivante :

Figure 5.2 – Diagramme de cas d’utilisation « consulter trace GPS »

2.0. le premier sprint 58

Sommaire
Nom Créer une tâche
Objectif Trace GPS
Acteur principal Administrateur ou commer-
cial
Description des scénarios
Les prés conditions l’administrateur ou com-
mercial authentifié
Les post conditions Le tracage GPS est affiché
Scénario nominal Scénario alternatif
7.1 les informations données
pour faire le filtre ne sont
1 Le système affiche la page d’accueil pas correctes : le système
2 Le commercial choisit le menu Carte renvoi un message d’erreur
3 Le commercial choisit le menu tracking et signale à le commercial
4 Le système affiche l’interface tracage GPS de recommencer
6 Le commercial peut faire un filtre selon le groupe, écran et date
7 Le système affiche le tracage selon votre choix.

tableau 5.1 – Description textuelle de "Tracage GPS"

2.0. le premier sprint 59

2.2 conception sprint1

2.2.1 Diagrammes de séquence

Figure 5.3 – Diagramme de séquences tracage GPS

2.0. le premier sprint 60

2.3 Les maquettes sprint 1

Figure 5.4 – maquette cas utilisation trace GPS

Figure 5.5 – maquette cas utilisation trace GPS 2

2.0. le premier sprint 61

2.4 Review du sprint 1

Dans cette partie, nous allons présenter quelques interfaces graphiques du sprint 1. Nous
avons réalisé 3 interfaces, qui sont :

•L’interface historique trace GPS

Cette interface affiche trace GPS du dernier 24h.

Figure 5.6 – Interface Historique GPS

• L’interface du trace GPS

L’administrateur ou le commercial peut choisir une date, groupe et l’ecran pour afficher son
tracage GPS.
2.0. le premier sprint 62

Figure 5.7 – Interface filtrage trace GPS

•L’interface du trace GPS

L’administrateur ou le commercial lister peut voir les écrans connecter et leurs places les plus
visités.

Figure 5.8 – Interface exemple résultat trace GPS

3.0. le deuxième sprint 63

3.0 le deuxième sprint

3.1 Spécification des besoins de sprint

Ce sprint sera dédié à la gestion des clients et les médias par l’administrateur ou le com-
mercial.

Figure 5.9 – Diagramme de cas d’utilisation du sprint 2

A la fin de ce sprint,tous les utilisateurs peuvent consulter le tableau de bord ainsi les sta-
tistiques .

Figure 5.10 – Diagramme de cas d’utilisation du sprint 2

3.0. le deuxième sprint 64

3.1.1 Diagrammes de cas d’utilisation raffinés

• Cas d’utilisation « Consulter statistiques »

Chaque utilisateur peut consulter les statistiques de les ecrans, les taxis , les médias et les
clients comme il montre la figure suivante :

Figure 5.11 – Diagramme de cas d’utilisation du sprint 2

3.0. le deuxième sprint 65

• Cas d’utilisation « Consulter le tableau de bord »

Un administrateur ou un utilisateur peuvent consulter le tableau de bord comme il montre
la figure suivante :

Sommaire
Nom Consulter le tableau
de bord
Objectif La consultation de ta-
bleau de bord
Acteur principal L’utilisateur ou l’ad-
ministrateur
Description des scénarios
Les prés conditions L’utilisateur authenti-
fié
Les post conditions Le tableau de bord est
affiché
Scénario nominal Scénario alternatif

1 Le système affiche la page d’accueil néant

2 L’utilisateur demande de consulter le tableau de bord
3 Le système envoie l’interface du tableau de bord

tableau 5.2 – Description textuelle de "Consulter le tableau de bord"

3.0. le deuxième sprint 66

• Cas d’utilisation « gérer les comptes clients »

l’administrateur peut gérer les comptes clients : (créer, modifier,activer/désactiver)au comme
il montre la figure suivante :

Figure 5.12 – Diagramme de cas d’utilisation « gérer les comptes clients »

• cas d’utilisation « gérer les médias »

l’administrateur peut gérer les médias : (uplode, tester)au comme il montre la figure suivante
Après son authentification,l’administrateur ou le commercial peut gérer uploder média .
Nous allons présenter la description textuelle détaillée des cas d’utilisation «uplode média »
Le tableau présente la description textuelle détaillée du cas d’utilisation «uplode média »
3.0. le deuxième sprint 67

Figure 5.13 – Diagramme de cas d’utilisation « gérer les médias »

3.0. le deuxième sprint 68

Sommaire
Nom Créer une tâche
Objectif Uploder médias
Acteur principal Administrateur ou commer-
cial
Description des scénarios
Les prés conditions l’administrateur ou com-
mercial authentifié
Les post conditions une nouvelle média est ajou-
ter a la platforme
Scénario nominal Scénario alternatif
7.1 le taille du fichier est très
grand : le système renvoie
1 1 Le système affiche la page d’accueil un message d’erreur et si-
2 Le commercial choisit le menue média gnale à le commercial
3 Le système envoie la liste des médias de recommencer
4 Le commercial choisit le bouton uplode nouveau média
5 Le système affiche le ficher pour choisir médias a partir du pc
6 Le commercial choisie le médias
et valide l’action
7 Le système vérifie le type de fichier (taille ,extention )
8 Le système ajoute le média.

tableau 5.3 – Description textuelle de "Uplode média "

3.0. le deuxième sprint 69

3.2 Conception de sprint 2

Dans cette section, nous visons à décrire les différents composants de sprint 4 et les
relations entre eux par le biais de diagramme de classes et de séquences.

3.2.1 Diagramme de séquances

Figure 5.14 – Diagramme de séquences uplode médias

3.0. le deuxième sprint 70

Figure 5.15 – Diagramme de séquences Ajout client

3.0. le deuxième sprint 71

3.3 Les maquettes sprint 2

Figure 5.16 – Maquette espace medias

Figure 5.17 – Maquette gérer media avec filtre

3.0. le deuxième sprint 72

Figure 5.18 – Maquette telecharger médias

Figure 5.19 – Maquette choisir médias à telecharger

3.0. le deuxième sprint 73

3.4 Réviw du sprint 2

Figure 5.20 – Choisir list client

3.0. le deuxième sprint 74

Figure 5.21 – Interface ajoute client

Figure 5.22 – Interface modifier client

3.0. le deuxième sprint 75

Figure 5.23 – Interface list média

Figure 5.24 – interafce telecharger média

3.0. le deuxième sprint 76

Figure 5.25 – Dashboard

3.5 Rétrospective du sprint 1

Lors de notre premiére sprint, nous avons terminé tous les cas d’utilisateurs relatifs ‘a
ce sprint dans les temps, le Backlog du sprint etait bien compris et nous avons travaill e
ensemble en harmonie
4.0. diagramme de collection 77

4.0 diagramme de collection

Figure 5.26 – Diagramme de cas d’utilisation du sprint 2

4.1 Conclusion
Dans ce chapitre, nous avons arrivé à l’objectif désiré qui est le fait de pouvoir gérer les
opportunités convenables pour répondre aux besoins fixés pour ce release.
Chapitre 6

Phase de clôture
1.0 Introduction
La phase de clôture est la dernière phase dans le cycle de développement d’un logiciel
avec Scrum.Ce chapitre est consacré donc pour la présentation de l’environnement de travail
utilisé pour la réalisation de notre application.

2.0 Environnement de travail

Nous allons dans ce qui suit présenter l’environnement matériel et logiciel de notre projet.

2.1 Environnement matériel

Notre application a été réalisée avec un ordinateur ayant les caractéristiques suivantes :
— Ordinateur portable : Toshiba
— Système d’exploitation : Windows11
— Processeur : Intel R core i5
— RAM : 8, 00 Go

2.2 Environnement logiciel

Le développement des applications web nécessite à la fois des logiciels pour la conception
ainsi que des logiciels pour le développement de la partie technique, qui sont :
— Pour le développement de notre application Web, nous avons utilisé PhpStorm
comme un environnement de développement pour développer des applications web.[4]
— pour tester les web services on a utiliser Postman tel que : Création une collection
contient notre web service à tester. Régler le Uri. Choisit la méthode nécessaire (GET,
POST, PUT, DELETE)..

78
3.0. Technologie utilisée 79

— Gitlab : c’est une plateforme permettant d’héberger et de gérer des projets web de A
à Z. Présentée comme la plateforme des développeurs modernes, elle offre la possibilité
de gérer ses dépôts Git et ainsi de mieux appréhender la gestion des versions de vos
codes sources.
— Pour la conception, nous avons utilisé Draw.io est une application gratuite en ligne,
accessible via son navigateur (protocole https) qui permet de dessiner des diagrammes
ou des organigrammes.Cet outil vous propose de concevoir toutes sortes de diagrammes,
de dessins vectoriels, de les enregistrer au format XML puis de les exporter
— pour la réalisationdes prototypes nous avons uitiliser figma qui est un éditeur gra-
phique baser en ligne .
Nous avons utilisé aussi des Frameworks comme :
— Illustrator : Pour les figures explicatives pour notre rapport nous utilisons Adobe
Illustrator qui est un éditeur graphique vectoriel.Il convient donc parfaitement à la
mise en page, la typographie, les logos.

3.0 Technologie utilisée

On va développer l’application avec MEAN qui est une pile logicielle JavaScript gratuite
et à code source libre.L’acronyme « MEAN » signifie MongoDB, Express.js, Angular.js et
Node.js comme represente figure 6.1.L’un de principaux avantages de la pile Mean est l’utili-
sation d’un langage unique, java script, qui s’exécute à tous les niveaux de l’application qui
est une approche efficace et moderne de développement web.

Figure 6.1 – MEAN

[5]
3.0. Technologie utilisée 80

Les environnements technologiques que nous avons appliqués sont :

3.1 Angular
Développé par Google, Angular est un Framework open source écrite en JavaScript qui
permet la création d’applications Web et plus particulièrement de ce qu’on appelle des «
Single Page Applications » : des applications web accessible via une page web unique qui
permet de fluidifier l’expérience utilisateur et d’éviter les chargements de pages à chaque
nouvelle action.Le Framework est basé sur une architecture du type MVC et permet donc de
séparer les données, le visuel et les actions pour une meilleure gestion des responsabilités.[6]

Figure 6.2 – Caption

3.2 NodeJS
C’est une plateforme logicielle libre et événementielle en JavaScript basée sur la machine
virtuelle V8 orientée vers les applications réseaux qui doivent pouvoir monter en charge.
Node.js(figure6.3) ayant une performance optimale puisqu’il fonctionne en mode asynchrone
(mode non bloquant).Il est basé sur des boucles événementielles qui lui permettent de sup-
porter de gros volume de requête en même temps et d’une manière efficace.[7]

Figure 6.3 – NodeJS

3.0. Technologie utilisée 81

3.3 ExpressJS

Express(figure6.4) est une infrastructure d’application (Framework), écrit en Javascript

et hébergée dans l’environnement d’exécution node.js.Cette section explique certains de ses
principaux avantages, comment configurer votre environnement de développement et com-
ment effectuer des tâches courantes de développement et de déploiement.[8]

Figure 6.4 – ExpresseJs

3.4 MongoDB

MongoDB(figure 6.5) est une base de données No-SQL orientée document.Elle se distingue
des bases de données relationnelles par sa flexibilité et ses performances.[9]

Figure 6.5 – MongoDB

3.5 Service web REST

REST (Représentationnel State Transfer) est une architecture logicielle de services web
qui permet de construire des applications pour les systèmes distribués comme le world wide
web et intranet.Les API REST sont basées sur HTTP, qui signifie HyperText Transfert
Protocol.C’est ce qui est au cœur de web. Ces APIs sont des méthodes qui définissent les
requetés que le client peut effectuer, dont GET, PUT, POST, DELETE et encore plus.
4.0. Architecture de la solution 82

4.0 Architecture de la solution

Il est primordial à la conception de tout système informatique de choisir le modèle d’ar-
chitecture qui lui est adéquat et pouvant assurer un bon fonctionnement, de meilleurs per-
formances.L’architecture doit garantir la réutilisation et favoriser l’interconnexion fiable de
ce système avec d’autres.
Nous décrivons cette architecture dans la section suivante.

4.1 Architecture opérationnelle

L’architecture opérationnelle repose sur la distinction entre les différents niveaux phy-
siques de la solution.L’architecture de notre solution est 3-tiers composé d’un client léger, un
serveur d’application et un serveur de base de données :
— Un client léger : Il n’est autre qu’un navigateur web représentant un intermédiaire
entre l’utilisateur et l’application
— Le serveur web : Il englobe toutes les couches de notre application et harmonise le
logique métier avec les données de l’application
— Le serveur de données : Il contient le serveur de base de données.
La figure 6.6 illustre ces trois tiers de notre application :

Figure 6.6 – Caption

4.2 Architecture applicative

L’architecture applicative s’intéresse au découpage logique de l’application à partir de ses

spécifications fonctionnelles tout en garantissant un couplage faible et une optimisation des
échanges afin d’assurer de plus grandes facilités d’évolutivité et de réutilisation.
Dans ce cadre on a opté pour une architecture multicouche illustrée par la figure ci-dessous :
— Un modèle (Model) contient les données à afficher..[?].
— Une vue (View) contient la présentation de l’interface graphique.
— Un contrôleur (Controller) contient la logique concernant les actions effectuées par
l’utilisateur.
La figure 6.7 illustre ces trois tiers de notre application :
5.0. L’approche Devops 83

Figure 6.7 – Architecture MVC

4.3 Architecture Web services

Figure 6.8 – Architecture Api

5.0 L’approche Devops

DevOps figure 6.9 est un ensemble de pratiques qui automatisent les processus entre les
deux équipes : Celle du développement et celle des administrateurs système afin de leur per-
mettre de développer, tester et livrer des logiciels plus rapidement et avec plus de fiabilité.Le
5.0. L’approche Devops 84

concept de DevOps repose sur la mise en place d’une culture de collaboration entre des
équipes qui étaient, historiquement, cloisonnées. L’accent est mis sur le changement de men-
talité, la collaboration accrue et une intégration plus poussée.DevOps associe la méthodologie
Agile, l’automatisation, la livraison continue et bien plus encore pour aider les équipes de
développement et opérationnelles à gagner en efficacité, à innover plus rapidement et à offrir
plus de valeur ajoutée aux business et aux clients.

Figure 6.9 – L’aproche devops

la figure 6.9 montre que le cycle DevOps contiennent :

— Planification : Cette phase permet de définir la valeur commerciale et les exi-

gences.Jira et Git peuvent être utilisés pour le suivi des problèmes connus et la gestion
des projets.

— Code : Cette phase inclut la conception logicielle et la création du code logiciel à

l’aide des logiciels GitHub, GitLab, Bitbucket ou Stash, par exemple.

— Compilation : Cette phase consiste à gérer les versions logicielles et à exploiter des
outils automatisés pour compiler et intégrer le code en vue de sa mise en production.

— Test : Cette phase comprend des tests continus, qu’ils soient manuels ou automatisés,
et vise à assurer une qualité de code optimale à l’aide des logiciels JUnit, Codeception,
Selenium, Vagrant, TestNG ou BlazeMeter, par exemple.

— déploiement : Cette phase peut inclure des outils de gestion, de coordination, de

planification et d’automatisation de la mise en production des produits, avec Pup-
pet, Chef, Ansible, Jenkins, Kubernetes, OpenShift, OpenStack, Docker ou Jira, par
exemple.
5.0. L’approche Devops 85

— Supervision : Cette phase permet d’identifier les problèmes affectant une version
logicielle en production et de collecter les informations correspondantes à l’aide des
logiciels Datadog, Grafana, Nagios ou Slack, par exemple.

5.1 Approche d’intégration, livraison déploiement continus

L’approche CI/CD représente une solution aux problèmes posés par l’intégration de nou-
veaux segments de code pour les équipes de développement et d’exploitation.Elle permet
d’augmenter la fréquence de distribution des applications grâce à l’introduction de l’auto-
matisation au niveau des étapes de développement des applications.Les principaux concepts
liés à l’approche CI/CD sont l’intégration continue, la livraison continue et le déploiement
continu.

5.1.1 Intégration continue (CI)

Les développeurs pratiquant l’intégration continue fusionnent leurs modifications dans la

branche principale aussi souvent que possible.Les modifications du développeur sont validées
en créant une version et en exécutant des tests automatisés sur la version.Ce faisant, on évite
le problème de l’intégration qui survient généralement lorsque les utilisateurs attendent le
jour de publication pour fusionner leurs modifications dans la branche de publication. L’inté-
gration continue insiste beaucoup sur les tests d’automatisation pour vérifier que l’application
n’est pas endommagée à chaque fois que de nouveaux commits sont intégrés dans la branche
principale.

5.1.2 La livraison continue/déploiement continu (CD)

La livraison continue (CD : continuous delivery) est une extension de l’intégration

continue qui permet de publier rapidement de nouvelles modifications pour les clients et de
manière durable.Cela signifie qu’en plus d’avoir automatisé les tests, on pourra aussi auto-
matiser le processus de publication en déployant une application à tout moment en cliquant
sur un bouton. En théorie, avec une livraison continue, on peut décider de publier à tout
moment ou selon les besoins. Toutefois, si on souhaite réellement tirer parti des avantages de
la livraison continue, on doit effectuer la mise en production dès que possible afin d’être sûr
de libérer de petits lots faciles à résoudre en cas de problème.
Le déploiement continu va plus loin que la livraison continue.Avec cette pratique, chaque
modification qui passe par toutes les étapes du pipeline de production est transmise aux
clients.Il n’y aucune intervention humaine, et seul un test ayant échoué empêchera le dé-
ploiement d’un nouveau changement en production. Le déploiement continu est un excellent
moyen d’accélérer la boucle de feed-back avec les clients et de soulager l’équipe, car il n’y
6.0. Conclusion 86

a plus de publication.Les développeurs peuvent se concentrer sur la création de logiciels et

voient leur travail mis en ligne quelques minutes après l’avoir terminé. La figure 6.10 montre
la différence entre l’intégration contenue et la livraison contenue

Figure 6.10 – différence entre continuous deployment et continuous dilevery

6.0 Conclusion
Au niveau de ce chapitre, nous avons présenté l’environnement matériel et logiciel de notre
projet, l’architecture adaptée et le diagramme de déploiement de notre application. En effet,
ce chapitre engendre la fin du cycle de vie du développement de l’application.Nous obtenons
donc le fruit du travail exécutable et prêt à être utilisé.
Conclusion et perspectives

Ce rapport représente le fruit du travail réalisé au sein de la Société SMARTEO C dans le

cadre de notre projet de fin d’études pour l’obtention du master professionnel en Innovation
Et Gestion des Projets au sein de l’isims .

En se basant sur la formation acquise durant notre cursus universitaire et sur les nouvelles
notions que nous avons pu assimiler au sein de l’entreprise dans laquelle nous avons effectué
notre stage, les objectifs que nous aient été fixés au départ sont en grandes parties atteintes.

Ce stage nous a permis non seulement de mettre en pratique les connaissances théoriques
acquises durant cinq années d’études mais également de maîtriser un ensemble de nouvelles
technologies. Nous avons eu quelques difficultés vu que c’était notre première expérience avec
SCRUM, nous avons consacré beaucoup de temps pour apprendre et maîtriser cette métho-
dologie. Mais malgré toutes les difficultés rencontrées et les contraintes de temps, nous avons
réussi à améliorer nos performances et nos connaissances depuis la conception jusqu’à la réa-
lisation d’un projet en pratiquant nos acquis et en dépassant toutes sorte de problèmes.

Notre travail ne s’arrête pas à ce niveau, en effet la solution développée reste extensible
à tout type d’amélioration et d’ajout de nouveaux modules. Pour ouvrir les horizons, nous
pouvons parler brièvement des améliorations qui peuvent être faites :
-Nous pouvons changer le programme automatiquement selon la position GPS.
-Nous pouvons faire un programme qui regroupe tout les médias ce qui aide a automatiser
les taches .
-Nous pouvons donner lacées au client pour uploder leur médias
-Nous pouvons devolopper une aplication pour les chauffeurs taxi pour signaler un probléme
si éxiste

87
Bibliographie 88

Bibliographie

[1] Scrum vs xp vs rup, Février 2022. www.researchpublish.com.

[2] projeqtor, Février 2022. https ://www.projeqtor.org/fr/.
[3] discord, Avril 2022. https ://discord.com/.
[4] Phpstorm, Mai 2022. https ://www.video2brain.com/fr/phpstorm.
[5] Mean stak, Avril 2022. https ://www.thirdrocktechkno.com/blog/what-is-mean-stack-
mean-stack-components-and-benefits/.
[6] Angular, Avril 2022. https ://angular.io/guide/setup-local.
[7] nodejs, Mai 2022. https ://nodejs.org/en/.
[8] Expressjs, Mai 2022. https ://expressjs.com/fr/.
[9] F, Mai 2022. www.helpclic.net/.../tutoriel-163-Introduction-au-logiciel-de-transfert-
FTP-FileZilla.html.
[10] Méthode moscow, Mai 2022. https ://anybox.fr/blog/rediger-un-cahier-des-charges-
avec-la-methode-de-moscow.