Rapport PFE AhmedLehyani-V10

République Tunisienne Cycle de Formation d’Ingénieurs
Ministère de l’Enseignement Supérieur dans la Discipline

et de la Recherche Scientifique Génie informatique
Université de Sfax Projet de Fin d’Etudes

École Nationale d’Ingénieurs de Sfax N° d’ordre : 2020 / Dima-058
MEMOIRE
Présenté à
L’Ecole Nationale d’Ingénieurs de Sfax

(Département de Génie Informatique et de Mathématiques Appliquées)
En vue de l’obtention
Du Diplôme National d’Ingénieur en Génie Informatique
Par
Ahmed LEHYANI
Conception et développement d’une

application de diagnostic, de conseil, et
d’adaptation face aux situations difficiles
« 9AWINY »
Soutenu le 08 Juillet 2020, devant la commission d'examen :
Mme. Fadoua DRIRA Président

Mme. Fatma ELLOUZE Examinatrice
M. Riadh BEN HALIMA Encadrant
Mme Manel ELLEUCHI Encadrante
Dédicace
Pour ceux qui ont cru en moi,
Ceux qui m’ont aimé et supporté,
Pour ceux qui ont fait de moi,
Ce que je suis aujourd’hui,
Maman, Papa,
Ma sœur, Mon frère
Et toute la famille,
Mes très chers amis,
Tous les membres de l’IEEE
Et spécialement ceux de l’ENIS Student branch
Je présente ce modeste travail
Grâce à vous et pour vous.
i
Remerciements
C'est avec un grand plaisir que nous réservons cette page en signe de gratitude et de
reconnaissance à tous ceux qui ont assisté ce travail.
Nous tenons particulièrement à remercier nos encadrants à l’Ecole Nationale d’Ingénieurs
de Sfax, M. Riadh BEN HALIMA et Mme Manel ELEUCHI, pour leurs disponibilités, leurs patiences,
leurs encouragements, leurs encadrements de qualité et pour tous leurs conseils judicieux tout au
long de notre projet.
Nos vifs remerciements accompagnés de toute notre gratitude s’adressent également à toute
les équipes de DK Soft et Digital Click pour leur accueil chaleureux, pour leurs aides et précieux
conseils, pour le temps alloué et les efforts fournis à nous guider et à nous intégrer dans
l’environnement de travail.
Enfin, nous exprimons notre grande reconnaissance à tous nos enseignants pour la formation
de qualité qu’ils nous ont prodiguée tout au long de notre cursus universitaire au sein de l’Ecole
Nationale d’Ingénieurs de Sfax.
ii
Table des matières
Introduction générale ...................................................................................................................... 1
Chapitre 1 : Cadre et méthodologie de travail .............................................................................. 3
1.1. Introduction ...................................................................................................................... 3
1.2. Présentation de l’organisme d’accueil.............................................................................. 3
1.3. Présentation du stage ........................................................................................................ 4
1.4. Présentation du projet ....................................................................................................... 4
1.4.1. Etude de l’existant..................................................................................................... 4
1.4.2. Objectifs .................................................................................................................... 7
1.4.3. Besoins du client ....................................................................................................... 8
1.4.4. Besoins non fonctionnels .......................................................................................... 9
1.5. Méthodologie de travail ................................................................................................... 9
1.5.1. Les méthodes agiles ................................................................................................ 10
1.5.2. Comparatif des principales méthodes agiles ........................................................... 10
1.5.3. Méthodologie de travail adoptée ............................................................................. 11
1.6. Conclusion...................................................................................................................... 13
Chapitre 2 : Architectures et exigences ...................................................................................... 14
2.1. Introduction .................................................................................................................... 14
2.2. Architecture et environnement logiciels ........................................................................ 14
2.2.1. Environnement logiciel ........................................................................................... 14
2.2.2. Technologies utilisées ............................................................................................. 16
2.2.3. Architecture logicielle ............................................................................................. 21
2.3. Architecture physique .................................................................................................... 24
2.4. Conclusion...................................................................................................................... 24
iii
Chapitre 3 : Développement de la version 1 ............................................................................... 25
3.1. Introduction .................................................................................................................... 25
3.2. Sprint 1 : Conception et développement de la partie « citoyen » ................................... 25
3.2.1. Tâches sélectionnées ............................................................................................... 25
3.2.2. Analyse des besoins ................................................................................................ 26
3.2.3. Backlog ................................................................................................................... 28
3.2.4. Conception UML .................................................................................................... 29
3.2.5. Réalisation............................................................................................................... 33
3.3. Sprint 2 : Conception et le développement de la partie « administrateur » ................... 36
3.3.3. Backlog ................................................................................................................... 38
3.3.4. Conception UML .................................................................................................... 38
3.3.5. Réalisation............................................................................................................... 40
3.4. Conclusion...................................................................................................................... 41
Chapitre 4 : Développement de la version 2 ............................................................................... 42
4.1. Introduction .................................................................................................................... 42
4.2. Sprint 3 : Amélioration de la partie « citoyen » ............................................................. 42
4.2.3. Backlog ................................................................................................................... 44
4.2.1. Conception UML .................................................................................................... 45
4.2.2. Réalisation............................................................................................................... 48
4.3. Sprint 4 : Amélioration de la partie « administrateur » .................................................. 52
iv
4.3.1. Backlog ................................................................................................................... 54
4.3.1. Conception UML .................................................................................................... 55
4.3.2. Réalisation............................................................................................................... 55
4.3.3. Déploiement et lancement de l’application............................................................. 57
4.4. Conclusion...................................................................................................................... 58
Conclusion générale ...................................................................................................................... 59
v
Table des figures
Figure 1: Logo Digital Click ........................................................................................................... 3

Figure 2: Logo DK Soft .................................................................................................................. 3
Figure 3: Interface Fabulous[1] ...................................................................................................... 5
Figure 4: Interface Stop-Corona [2] ................................................................................................ 5
Figure 5: Interface Google Forms [3] ............................................................................................. 6
Figure 6: Processus de Scrum ....................................................................................................... 13
Figure 7: Outils utilisés ................................................................................................................. 14
Figure 8: Technologies Web utilisées ........................................................................................... 18
Figure 9: Architecture logicielle ................................................................................................... 22
Figure 10: Diagramme de paquetages........................................................................................... 23
Figure 11: Architecture physique de l'application ........................................................................ 24
Figure 12: Diagramme de cas d'utilisation du sprint 1 ................................................................. 27
Figure 13: Diagramme des classes persistantes ............................................................................ 30
Figure 14: Diagramme d'activités ................................................................................................. 31
Figure 15: Diagramme de séquences ............................................................................................ 32
Figure 16: Interface graphique de la page d'accueil de 9AWINY ................................................ 33
Figure 17: Interface graphique du Formulaire de données ........................................................... 34
Figure 18: Exemple de question d'émotion................................................................................... 34
Figure 19: Interface de fin de la 1ère consultation ....................................................................... 35
Figure 20: Interface d'accès entre les consultations ...................................................................... 35
Figure 21: Aperçu sur la version mobile....................................................................................... 35
Figure 24: Interface d'authentification .......................................................................................... 40
Figure 25: Tableau de bord synthétique........................................................................................ 40
Figure 26: Tableau des scores individuels .................................................................................... 41
Figure 27: Tableau des scores ....................................................................................................... 41
vi
Figure 30: Diagramme d'activités ................................................................................................. 47
Figure 31: Interface graphique de la page d'accueil de 9AWINY ................................................ 48
Figure 32: Pop-up de choix de consultation ................................................................................. 48
Figure 33: Formulaire de données ................................................................................................ 49
Figure 34: Ajout des champs spécifiques pour les étudiants ........................................................ 49
Figure 35: Exemple de question d'émotion................................................................................... 50
Figure 36: Exemple de question de la consultation 1 ................................................................... 50
Figure 37: Interface de fin de la 1ère consultation ....................................................................... 51
Figure 38: Interface d'accès entre les consultations ...................................................................... 51
Figure 39: Aperçu sur la version mobile....................................................................................... 52
Figure 41: Tableau de bord synthétique........................................................................................ 55
Figure 42: Carte de résiliences ...................................................................................................... 56
Figure 43: Diagramme de résilience des universités .................................................................... 56
vii
Liste des tableaux
Tableau 1: Comparaison entre les solutions existantes................................................................... 7
Tableau 2: Comparaison entre les méthodologies agiles [4] ........................................................ 11
Tableau 3: Scénario nominal de la partie citoyen ......................................................................... 27
Tableau 4: Backlog sprint 1 .......................................................................................................... 28
Tableau 5: Scénario nominal de la partie administrateur.............................................................. 37
Tableau 6: Backlog sprint 2 .......................................................................................................... 38
Tableau 7: Scénario nominal de la partie citoyen ......................................................................... 44
Tableau 8: Backlog du sprint 3 ..................................................................................................... 44
Tableau 9: Scénario nominal de la partie administrateur.............................................................. 54
Tableau 10: Backlog sprint 4 ........................................................................................................ 54
Tableau 11: Comparaison entre les solutions existantes et notre application ............................... 57
viii
Acronymes
ENIS Ecole Nationale d'Ingénieurs de Sfax
PDF Portable Document Format
REST REpresentational State Transfer
IDE Integrated Development Environment
HTML HyperText Markup Language
CSS Cascading Style Sheets
MVC Model View Controller
XML Extensible Markup Langage
Java EE Java Entreprise Edition
GPL General Public License
JPA Java Persistence API
ORM Object-Relational Mapping
DTO Data Transfer Object
DAO Data Access Object
JWT JSON Web Token
UML Unified Modeling Language
URL Uniform Resource Locator
WAR Web application Archive
ix
Introduction générale
Les systèmes d’informations jouent un rôle primordial dans la société du fait qu’ils
facilitent la gestion et l’automatisation des tâches gênantes. Ceci est le cas pour les instituts
d'enquêtes et sondage dans le domaine des études psychologiques. L’une des tâches les plus
pénibles pour ces instituts est les sondages qu’il faut faire. Cette fonctionnalité exige en général
beaucoup de ressources humaines et matérielles, et entraîne un énorme gaspillage de temps en
cas de calcul manuel. Par conséquent, elle engendre des retards et/ou des risques indésirables. Et
plus de ça, parfois on a besoin des résultats très rapidement pour interagir en même temps et
revoir les résultats et c’est le cas du projet 9AWINY.
Pour ce faire, nous avons rejoint l’équipe Java de la société DK Soft pour la conception et
le développement d’une application de diagnostic, de conseil, et d’adaptation face aux situations
difficiles. Le but de ce projet est d’automatiser les enquêtes, donner des recommandations aux
citoyens, analyser les résultats etc.
Le mot 9AWINY est un mot du dialecte tunisien qui veut dire « donne-moi la force » ou
« rends-moi plus fort ». Nous avons choisi ce nom en collaboration avec le client, pour que ça
soit près des citoyens. En effet, un tel nom peut les encourager à participer pour bénéficier des
recommandations proposées par les experts.
Cette application était faite à titre bénévole pour le bien de la Tunisie, après une période
très difficile que nous avons pu surmonter avec succès.
Pour présenter ce projet, nous avons réparti notre rapport sur trois chapitres :
• Chapitre 1 : Ce chapitre est consacré à la présentation du cadre et de la méthodologie
de travail de notre projet à savoir Scrum.
• Chapitre 2 : Ce chapitre est dédié à la spécification des différentes architectures
associées à notre application ainsi que les différentes technologies utilisées dans 9AWINY.
• Chapitre 3 : Ce chapitre est consacré à la réalisation des deux premiers sprints relatifs
à la conception et au développement de la première version de l’application en commençant
par la partie citoyen, (enquête), passant par le traitement des données et le calcul des scores et
des indices et terminant par la partie administrateur (présentation des données sous différentes
formes : histogramme, carte, jauge, …).
1
• Chapitre 4 : Ce chapitre est consacré à la réalisation du troisième et quatrième sprints
relatifs à l’amélioration de l’application tels que l’ajout du type étudiant en tant que métier pour
le citoyen et la mise en place de tableaux de bords pour la distribution de la résilience.
Ce rapport sera clôturé par une conclusion qui dresse le bilan des tâches réalisées, et
présente quelques perspectives pour améliorer et étendre ce travail.
2
Chapitre 1 : Cadre et méthodologie de travail
1.1. Introduction
Ce chapitre sert à exposer le cadre général de travail durant ce projet de fin d’études. Nous
entamons cette exposition par une présentation générale de l’entreprise. Puis, nous détaillons l’idée
générale du projet, suivie par le besoin du client, ainsi que les principales fonctions à développer.
Enfin, nous présentons la méthodologie adoptée par l’équipe pour réaliser ce projet.
1.2. Présentation de l’organisme d’accueil

Etant une Société de Service et d’Ingénierie Informatique (SSII), Digital Click est une
structure souple, réactive et qui propose des solutions sur mesure dans le domaine des nouvelles
technologies et du système d'information.
Digital click se caractérise par une équipe pluridisciplinaire, expérimentée (métiers,
techniques) et formée à la norme ITIL, par des solutions robustes, souples et adaptées à chaque
client.
Figure 1: Logo Digital Click
DKSoft est une filiale de Digital Click qui s’intéresse au développement des applications
web. Elle est composée de plusieurs équipes organisées par technologie à savoir PHP, .NET et
JEE.
Figure 2: Logo DK Soft
3
1.3. Présentation du stage
Notre stage intitulé « Conception et développement d'une application de diagnostic, de
conseil, et d'adaptation face aux situations difficiles » est réalisé dans le contexte du projet de fin
d’étude du cycle d’ingénieur en Informatiques à l’ENIS. Ce projet est effectué dans une filiale de
la société Digital Click, à savoir DK Soft, au sein de l’équipe JEE qui s’intéresse au développement
des applications Web.
Dans le cadre de ce stage, nous avons participé aux différentes étapes de réalisation du projet
en commençant par la conception et en terminant par le test de l'application.
1.4. Présentation du projet

Etant Stagiaire à DK Soft, nous avons eu l'occasion de développer l'application 9AWINY
demandée par le professeur en psychologie et psychologue cognitif Prof. Slim MASMOUDI en
collaboration avec le Centre de Recherche en Numérique de Sfax et à l'intérêt du ministère de
l'enseignement supérieur et de la recherche scientifique. 9AWINY est une application qui aide les
citoyens à s'adapter aux situations difficiles, notamment face à la pandémie Covid-19 et à la
circonstance de confinement, hors du quotidien.
Cette application présente un baromètre de résilience aux administrateurs (ensemble de
psychologues) ayant besoin du calcul de certains indices permettant de faire les études nécessaires.
1.4.1. Etude de l’existant

Dans le marché, il existe plusieurs applications de conseils à savoir Fabulous [1] et d’autres
servant à s’enquérir de la santé de ses utilisateurs et permettant à l'administrateur de faire des
études sur les résultats des enquêtes filtrées à savoir Stop Corona [2]. Par ailleurs, il est possible
d’utiliser Google Forms [3] pour faire ces types d’enquêtes. Nous détaillons dans cette partie une
description de chacune de ces solutions.
1.4.1.1. Fabulous
Fabulous [1] est une application qui influe sur les comportements des utilisateurs et les aide
à améliorer leurs habitudes sanitaires dans la vie à l’aide d’un questionnaire et des
recommandations à suivre. C’est une application en anglais qui est ouverte à tout le monde et qui
4
n’a pas de partie administrateur. Cette application dispose une version web et une version mobile.
Figure 3: Interface Fabulous[1]
1.4.1.2. Stop Corona

Stop Corona [2] est une application de diagnostic et de statistique qui consulte l'état sanitaire des
citoyens en se basant sur des questions cliniques. Cette application répond, selon les symptômes
somatiques notés, par des recommandations. En plus, Stop Corona possède une partie pour
l’administrateur qui lui permet de faire les statistiques selon des filtres tels que l’âge, le
gouvernorat, etc. Elle est efficace principalement à la période de la pandémie.
Figure 4: Interface Stop-Corona [2]
1.4.1.3. Google forms

Google Forms [2] est une application d'administration de sondages. Il s’agit d’un outil qui
5
permet de collecter des informations auprès des utilisateurs via une enquête ou un quiz
personnalisé. Les informations sont ensuite collectées et automatiquement connectées à une feuille
de calcul. Google Forms inclut plusieurs fonctionnalités : La validation de réponse intelligente, la
recherche dans les menus, le mélange des questions pour un ordre aléatoire, la limitation des
réponses à une fois par personne, etc.
Figure 5: Interface Google Forms [3]
Le tableau 1 illustre une étude comparative qui résume les points communs et les points de
différence entre les différentes applications trouvées.
D’après le tableau 1, chacune des applications présente quelques critères. Toutes les
solutions trouvées sont anonymes et peuvent présenter des recommandations lisibles. Cependant,
aucune ne présente de recommandations audibles et ne fait le suivi du citoyen après une période
de temps. Toutes les applications possèdent une partie où l’administrateur peut s’authentifier et
consulter les résultats des enquêtes, les filtrer et les classer sur un histogramme, à l’exception de
Fabulous qui ne contient pas de côté administrateur.
Pour le côté administrateur, Stop Corona est confidentielle. Elle peut générer une carte
géographique et posséde une interface graphique, tandis que Google Forms ne possède pas de ces
fonctionnalités.
6
Tableau 1: Comparaison entre les solutions existantes
Application Fabulous Stop Corona Google Forms
Coté citoyen
UI ✔ ✔ ✘
Recommandation lisible ✔ ✔ ✔
Recommandation audible ✘ ✘ ✘
Anonymat ✔ ✔ ✔
Suivi ✘ ✘ ✘
Coté administrateur
Confidentialité ✔ ✘
Jauge ✘ ✘
Histogramme ✔ ✔
Carte géographique ✔ ✘
Filtre sur les réponses ✔ ✔
Filtre sur les indices ✘ ✘
Authentification ✔ ✔
UI ✔ ✘
Convertir les données en ✘ ✔

Excel
1.4.2. Objectifs
L’objectif principal du projet est de concevoir et développer une application web. En effet,
notre application doit être flexible à toutes améliorations et évolutions et doit être à haut niveau en
termes de qualité du code, de sécurité et de performance.
7
1.4.3. Besoins du client
Prof. Slim MASMOUDI a développé une enquête composée par des psycho-questions
destinée à tous les citoyens âgés de plus de 12 ans. Cette enquête répond selon des critères par des
recommandations spécifiques pour chaque cas et calcule quelques indices servant à faire les
statistiques et les études nécessaires.
Les besoins exprimés par Prof. Slim MASMOUDI sont en général :
➢ Coté citoyen
- Automatiser le processus de l’enquête en développant une application web gratuite
et anonyme appelée 9AWINY permettant au citoyen de faire deux consultations décalées d’une
semaine.
- Après avoir répondu aux questions de la première consultation, 9AWINY répond
d’une manière intelligente par des recommandations de soutien moral et des conseils lisibles et
audibles selon l’état du citoyen. Ce dernier sera invité à revenir dans une semaine pour terminer la
deuxième consultation.
- Si le citoyen revient avant que la semaine se termine, il n’aura pas la main pour
finir la deuxième consultation.
- Si le citoyen revient après une semaine, et finit sa deuxième consultation, il aura
d’autres recommandations de soutien moral et conseils selon l’évolution de son état psychologique
entre les deux consultations.
➢ Coté administrateur (expert / psychologue)
- 9AWINY calcule les scores de chaque citoyen après la première consultation et
après la deuxième consultation et les sauvegarde pour l’administrateur.
- L’expert peut s’authentifier pour consulter :
o Un tableau des scores : contenant tous les scores des sources de résilience
et celles de vulnérabilité ;
o Un tableau des scores individuel : contenant les scores des sources de
résilience et celles de vulnérabilité pour un citoyen précisé par son identifiant dans la base de
données ;
o Un tableau de bord synthétique : contenant pour chaque consultation la
moyenne des scores de résilience, la moyenne des indices de résistance à la réponse et la moyenne
8
des indices de désirabilité sociale. Ce tableau de bord contient aussi la valence positive, la valence
négative et la valence globale ;
o Un tableau de bord individuel : contenant pour chaque consultation un score
de résilience, un indice de résistance à la réponse et un indice de désirabilité sociale. Ce tableau de
bord contient aussi la valence positive, la valence négative et la valence globale pour un citoyen
précisé par son identifiant dans la base de données.
1.4.4. Besoins non fonctionnels

Les besoins non fonctionnels représentent les exigences qui ne concernent pas le
comportement du système mais des contraintes qui doivent être respectées. Nous identifions les
besoins non fonctionnels suivants :
• Sécurité : L’application doit garantir la sécurité des données qu’elle gère. Le
mécanisme d’authentification doit permettre d'assurer l'authenticité de l’utilisateur connecté et de
vérifier et valider les autorisations qu’il détient lors de sa manipulation de l’application. De plus,
les échanges entre le back end et le front end doivent être protégés.
• Ergonomie : Notre application doit donc offrir une interface conviviale et qui
facilite l’exploitation des fonctionnalités offertes aux utilisateurs.
• Compatibilité : Dans un contexte d’application web, il est important de s’assurer
du bon fonctionnement de l’application sur différents types d’écran (smartphone, tablette, PC).
• Evolutivité : Le développement des applications informatiques doit se faire en
considérant toujours l’évolutivité du système ultérieurement. Modélisation efficace et correcte,
respect des bonnes pratiques de programmation, proposition d’architectures modulaires et
extensibles.
1.5. Méthodologie de travail

Afin de réussir notre projet en respectant les délais et les ressources, il est nécessaire que
l’équipe soit bien organisée et efficace. Dans ce contexte, nous avons dû fixer l'une des méthodes
de gestion de projet existantes afin de nous aider à organiser notre projet de façon rationalisée et
structurée. Choisir une méthodologie pour conduire un projet permet à tous les membres de
l’équipe de travailler efficacement ensemble, en suivant des règles clairement définies.
9
1.5.1. Les méthodes agiles
Les méthodes agiles impliquent au maximum le demandeur lors du processus du projet et
permettent une grande réactivité à ses demandes. Elles reposent sur un cycle de développement
itératif, incrémental et adaptatif. De plus elles sont basées sur une approche flexible et offrent une
meilleure visibilité dans la gestion du projet, ce qui permet à l'équipe d'être plus réactive aux
attentes du client. Les membres de l’équipe travaillent en petites phases et équipes sur des mises à
jour spécifiques du produit. Ensuite, chaque mise à jour est testée en fonction des besoins du client,
au lieu de se concentrer sur un seul produit final qui n’est publié qu’à la fin du projet. C’est pour
cela que le produit final d’un projet agile pourrait bien être différent de ce qui avait été initialement
prévu. Les méthodologies agiles pour le développement informatique offrent plusieurs avantages
tels que : l’amélioration de la qualité des produits, la satisfaction du client, la grande motivation
des travailleurs et le travail collaboratif [4]. Toutes ces raisons nous ont poussés vers le choix de
la méthode agile. Parmi les méthodes agiles nous pouvons citer « Scrum », « Kanban », « RAD »,
« XP », etc. Pour notre projet, nous allons opter pour la méthodologie Kanban étant donné que
cette méthodologie facilite la collaboration entre les membres de notre équipe agile.
1.5.2. Comparatif des principales méthodes agiles

Scrum et Safe sont les méthodes agiles les plus utilisées. Selon le benchmark VersioOne daté
de 2019, Scrum pèse 54% de parts de marché dans l'agilité mono-équipe, et Safe 30% dans l'agilité
multi-équipes. Côté pilotage mono-équipe, Scrum est challengé par Kanban [4].
Alors que Scrum est adapté à la gestion d'un projet unique, Kanban convient mieux au
management de plusieurs projets ou encore à la TMA (tierce maintenance applicative) et au MCO
(maintien en condition opérationnelle). Associant les deux démarches, le Scrumban répond aux
configurations plus complexes. Exemple : le cas d'une équipe investie dans la migration d'une
application vers le cloud, mais qui devra en parallèle maintenir les anciennes versions du logiciel
le temps du chantier. "Le Scrumbanboard associe sur un même tableau de pilotage une timeline
Scrum pour gérer les sprints d'un projet et une matrice de cartes Kanban pour superviser la
résolution de bugs", indique Denis Delwail1.
1
Coach agile de la practice agilité au sein de l'ESN française Umanis qui a publié un benchmark sur les méthodes
agiles
10
Tableau 2: Comparaison entre les méthodologies agiles [4]
Critères Scrum Kanban Scrumban Extremeprogramming

(XP)
Planification Au début de Kanban board, Kanban Planning game
chaque sprint Flux continu board avec
itérations
Estimation de Au début de Optionnel, Idem Kanban Pratiques XP
l'effort chaque sprint prédictibilité
Boards/Artifacts Product Kanban board, Idem Kanban Priorisation par le
backlog, Diagramme client, pratiques XP
Scrum board, des flux
burndown / cumulés
burnup
Quand choisir ? Equipe MCO, TMA, MCO, TMA, Amélioration de la
dédiée à équipe équipe qualité du logiciel
100% au travaillant sur expérimentée critique, prise en
projet plusieurs en agilité compte immédiate des
projets changements
simultanément
Caractéristiques 1. Méthode 1. Kanban 1. 1. Qualité code,
principales leader, board, Adaptabilité, 2. Craftmanship,
2. Sprints, 2. Pilotage 2. Transition, 3. Outillage.
3. BurnUP / visuel, 3. Centre de
vélocité. 3. Indicateurs / services.
cycle time.
Top 3 bénéfices - - Mise en place - Avantages - Qualité du code plus
Productivité, rapide sans de Scrum + importante,
- Scalabilité, changement Kanban, - Réactivité,
- Engagement des processus - Adapté à - Niveau d'expertise des
des équipes. existants, des équipes.
- Pilotage portefeuilles
visuel CFD, projets
- Gestion des mixtes cycle
files d'attentes en V et
Flux. agiles.
1.5.3. Méthodologie de travail adoptée

Le projet « 9awiny » est classé parmi les projets assez difficiles à réaliser. Ce type de projet
nécessite une bonne expérience dans le domaine informatique, une stratégie de travail adaptative
et un suivi périodique par le client. De ce fait, nous avons décidé d’adopter Scrum comme une
méthodologie de travail.
11
1.5.3.1. La méthode Scrum
Scrum est une méthode de développement agile orientée projet informatique dont les
ressources sont régulièrement actualisées.
La méthode Scrum tire son nom du monde du rugby, Scrum = mêlée. Le principe de base
étant d'être toujours prêt à réorienter le projet au fil de son avancement.
C'est une approche dynamique et participative de la conduite du projet. La mêlée est une
phase de jeu essentielle au rugby. Elle permet au jeu de repartir sur d'autres bases. La réunion dans
la méthode Scrum relaie la métaphore [5].
1.5.3.2. Le processus Scrum

Le cycle de vie Scrum est rythmé par des itérations de quelques semaines, « les sprints » [4].
La durée de ces sprints est fixée à 3 semaines dans le cadre de ce projet.
Avant le démarrage d’un Sprint, le Product Owner doit s’assurer que le Product Backlog
(liste des exigences attendues) est correctement ordonnancé en fonction de la valeur métier et du
coût de chaque exigence.
Le Product Owner et l’équipe de développement se réunissent afin de partager ou repartager
ensemble la vision du projet ainsi que les objectifs associés aux éléments du Product Backlog.
L’équipe de développement sélectionne ensuite les éléments du Product Backlog en commençant
par le haut (exigences prioritaires) en fonction de sa capacité à faire. Enfin, l’équipe de
développement, découpe chaque exigence en tâches et estime le temps nécessaire à la réalisation
de chacune d’entre elles. Ces tâches sont enregistrées dans le Sprint Backlog.
Le sprint englobe les activités d’analyse, de conception, de test et de développement. Au
cours de ce dernier, le Product Owner et l’équipe de développement collaborent étroitement pour
atteindre les objectifs fixés.
L’équipe de développement se réunit chaque jour lors de « la mêlée quotidienne » afin
d’évoquer le travail réalisé et soulever les obstacles rencontrés. Chaque membre de l’équipe
actualise son « Reste A Faire » sur ses tâches en cours de manière à actualiser le graphique
d’avancement du sprint. Ce point est limité à 15 minutes.
A la fin du sprint, l’équipe de développement présente les résultats de son travail « Revue de
Sprint » au Product Owner et aux utilisateurs finaux sous la forme d’une démonstration des
nouvelles fonctionnalités réalisées. Les feedbacks sont recueillis.
12
Après la revue du Sprint, l’équipe de développement ainsi que le Product Owner se
réunissent « Rétrospective de Sprint » afin d’identifier les adaptations susceptibles d’augmenter sa
productivité. Les choses qui fonctionnent, celles qui ne fonctionnent pas ainsi que les améliorations
à apporter, sont identifiées dans cette réunion. Elle s’inscrit dans une démarche d’amélioration
continue. Les idées de chacun sont mises à profit. S’enchaine ensuite la planification du sprint
suivant.
La figure 6 illustre à la fois les différents rôles de Scrum ainsi que le déroulement du
processus.
Figure 6: Processus de Scrum
1.6. Conclusion
Au terme de ce chapitre, nous avons présenté la société à laquelle nous avons effectué notre
projet. Puis, nous avons donné une vue générale sur le besoin du client et les objectifs qu’on doit
atteindre. Enfin, nous avons défini la méthodologie de travail adoptée pour la réalisation de projet
« 9AWINY ». Le chapitre suivant sera consacré à la présentation de l’architecture de travail, et la
définition des exigences fonctionnelles et non fonctionnelles de l’application.
13
Chapitre 2 : Architectures et exigences
2.1. Introduction
Pour répondre au besoin d’automatiser le processus de l’enquête, nous avons recueilli
plusieurs technologies qui nous ont amené à atteindre nos buts.
Dans ce chapitre, nous allons faire la présentation de l’architecture logicielle et des
environnements logiciels. Nous allons, par la suite présenter l’architecture physique de notre
application.
2.2. Architecture et environnement logiciels

Dans cette partie, nous détaillons notre environnement logiciel ainsi que notre architecture
logicielle.
2.2.1. Environnement logiciel

Nous énumérons au cours de cette partie les différents outils et technologies employés tout
au long de la réalisation de notre projet.
2.2.1.1. Outils utilisés

La figure 7 représente les outils utilisés pour le bon déroulement du projet.
IDEs Gestion de projets et communication Autres
Figure 7: Outils utilisés
14
2.2.1.2. IDEs
• Eclipse
Eclipse [6] est un environnement de développement intègre extensible,

libre, polyvalent et universel. Il vise à augmenter la productivité du
développeur en fournissant des outils pour la réalisation des logiciels, englobant les activités de
programmation, modélisation, conception et test. Pour le développement de la partie back-end de
notre projet, nous avons utilisé la version 19.12.
• WebStorm
WebStorm [7] est un IDE pour les langages Web (HTML, CSS et JavaScript),
développé par l'entreprise JetBrains et basé sur la plateforme IntelliJ IDEA.
2.2.1.3. Outils de gestion de projets et de communication

• Bitbucket
Bitbucket Cloud [8] est un outil d'hébergement et de collaboration basé
sur Git, conçu pour les équipes. Les meilleures intégrations Jira et Trello de
Bitbucket sont conçues pour rassembler toute l'équipe logicielle pour exécuter un projet. Bitbucket
fournit un endroit à votre l’équipe pour collaborer, créer du code de qualité grâce à des tests
automatisés et déployer le code en toute confiance.
• Jira
Jira Software [9] est une plate-forme puissante qui combine la collecte des problèmes
et les capacités de gestion de projet agile dans une seule application. L'utilisation du
logiciel Jira aide à planifier et à organiser plus efficacement les tâches, les flux de travail et les
rapports pour l’équipe agile.
• Slack
Slack [10] est une plateforme collaborative qui centralise les
communications et les outils dans une interface agréable et facile
d’utilisation, pour que les membres de l’équipe restent productifs, malgré la distance qui les sépare.
15
2.2.1.4. SGBD
• MySQL
MySQL [11] est un système de gestion de bases de données relationnelles

(SGBDR). Il est distribué sous une double licence GPL et propriétaire. Il fait partie
des logiciels de gestion de base de données les plus utilisés au monde, autant par le grand public
(applications web principalement) que par des professionnels.
2.2.1.5. Autres outils

• Postman
Postman [12] est un outil qui permet de construire et de tester rapidement

des requêtes HTTP. Il permet d’exécuter des appels HTTP à un serveur pour en
interpréter la réponse en dehors de tout contexte métier.
• Xampp
XAMPP [13] est une distribution Apache entièrement gratuite et facile à installer
contenant MySQL, PHP et Perl. C’est un logiciel qui nous servira pour démarrer le
serveur MySQL qu’on utilise pour gérer notre base de données dans ce projet.
2.2.2. Technologies utilisées

Dans ce qui suit, nous détaillons les technologies que nous avons utilisées.
2.2.2.1. Technologies de programmation

• Java
Java [14] est un langage typé et orienté objet. Il est compilé et basé sur une
architecture logicielle très particulière nécessitant une machine virtuelle Java. Il utilise
les notions usuelles de la programmation orientée objet : la notion de classe,
d’encapsulation, d’héritage, d’interface, de virtualité, de généricité. Il est accompagné
d’un ensemble énorme de bibliothèques standard couvrant de très nombreux domaines. Nous
avons utilisé le Java Développement Kit JDK 8.
16
2.2.2.2. Plateforme de développement
• JakartaEE
La plateforme Jakarta Entreprise Edition (Jakarta EE) [15] est un ensemble de

spécifications coordonnées et pratiques qui permettent des solutions pour le
développement, le déploiement, et de la gestion des applications multi-tiers centralisées sur un
serveur. Construite sur la plateforme de Java 2 édition standard (Java SE), la plateforme Jakarta
EE ajoute les possibilités nécessaires pour fournir une plateforme complète, stable, sécurisée, et
rapide de Java au niveau entreprise.
2.2.2.3. Outils et Framework

• Spring Boot
Spring Boot [16] est un framework qui facilite le développement d'applications fondées sur
Spring. Il propose une approche dogmatique de la configuration, qui permet
d’éviter aux développeurs de redéfinir la même configuration à plusieurs endroits
du code.
• Spring data JPA
Spring data JPA [17] est un framework qui fournit un modèle de

programmation cohérent basé sur Spring pour l’accès aux données, des bases de
données relationnelles et non relationnelles, des données basées sur le cloud, etc. Il
offre ainsi les avantages suivants :
- Repository puissant et abstractions de mappage d’objets personnalisés,
- Classes de base des domaines fournissant les requêtes de base (CRUD),
- Possibilité d’enrichir les repositories en intégrant des requêtes personnalisées,
- Intégration avancée avec les contrôleurs Spring MVC.
• Hibernate :
Hibernate [18] est un framework open source de type ORM (Object

/Relational/ Mapping) qui est concerné par la persistance des données, il permet
d’avoir une représentation de la base de données relationnelle en objets Java et vice versa.Il est
également une implémentation de la spécification Java Persistence API (JPA). En tant que tel, il
17
peut être facilement utilisé dans tout environnement prenant en charge JPA, y compris les
applications Java SE, les serveurs d'applications Java EE.
• Spring Security :
Spring Security [19] est un framework qui se concentre sur

l'authentification et l'autorisation des applications Spring. Au niveau de
l’authentification, Spring Security offre des mécanismes divers comme par exemple
l’authentification via un annuaire LDAP, OpenID, formulaires, JWT, etc. Au-dessus des
mécanismes d’authentification, Spring Security ajoute des autorisations sur les requêtes Web, les
méthodes ou même les objets.
• Maven :
Apache Maven [20] est un outil de gestion et d’automatisation de

production des projets logiciels qui est basé sur POM (modèle d’objet du
projet). Il offre entre autres les fonctionnalités suivantes :
- Compilation et déploiement des applications Java (JAR, WAR),
- Gestion des librairies requises par l'application,
- Exécution des tests unitaires,
- Génération des documentations du projet,
- Intégration dans différents IDE.
2.2.2.4. Technologies de Web

La figure 8 résume les technologies web que nous avons utilisées.
Ngx charts
Figure 8: Technologies Web utilisées
18
• HTML 5 :
HTML (Hypertext Markup Language) [21], est un format de données développé

pour concevoir les pages web. C’est un langage de balisage permettant de structurer
systématiquement et de mettre en forme le contenu des pages WEB, d’inclure des
ressources multimédias dont des images, des formulaires de saisie, et des programmes
informatiques.
• CSS 3 :
CSS (Cascading Style Sheets /feuilles de styles en cascade) [22], servent à mettre
en forme des documents web, type page HTML ou XML. Par l’intermédiaire de propriétés
d’apparence (couleurs, bordures, polices, etc.) et de placement (largeur, hauteur, côte à
côte, dessus-dessous, etc.), le rendu d’une page web peut être intégralement modifié sans aucun
code supplémentaire dans la page web. Les feuilles de styles ont d’ailleurs pour objectif principal
de dissocier le contenu de la page de son apparence visuelle.
• Bootstrap :
Bootstrap [23] est un framework développé par l'équipe du réseau social

Twitter. Proposé en open source, il utilise les langages HTML, CSS et JavaScript pour
fournir aux développeurs des outils pour créer un site facilement et rapidement. Il est pensé pour
développer des sites avec un design responsive, qui s'adapte à tout type d'écran, et en priorité pour
les Smartphones. Il fournit des outils avec des styles déjà en place pour des typographies, des
boutons, des interfaces de navigation et bien d'autres encore.
• TypeScript :
TypeScript [24] est un langage de programmation open-source développé par

Microsoft. Le langage se présente comme un sur-ensemble du JavaScript avec notamment
l’apport d’un typage statique optionnel des variables et des fonctions, la création de classes et
d’interfaces, la création d’espaces de nommage et de modules.
19
• Angular 8 :
Angular [25] est un framework qui permet de créer des applications

monopages, web et mobiles. Angular se repose sur les langages HTML5, CSS3 et
typeScript. Il utilise l’architecture MVM (Modèle Vue Modèle), proche du modèle MVC. Cela
permettre de structurer le code et séparer la vue et le modèle. Il est considéré comme un langage «
côté client », ceux-ci permettent de gérer l’interface utilisateur de chaque page (affichage,
interactions…) de façon dynamique. Durant l’élaboration du projet, nous avons eu recours au
Angular CLI qui est un outil en ligne de commande permettant de générer un squelette
d’application Angular, de générer rapidement des bouts de code (composant, module, route…), de
faire tourner un serveur de développement, d’exécuter les tests, de déployer notre application.
• Ngx Charts
Ngx Charts [26] est un framework cartographique pour Angular. Il s'agit de l'un des
frameworks les plus populaires pour le développement d'applications Angular, car il
Ngx charts
facilite tellement le rendu des graphiques.
• Angular Material
Angular Material [27] est une bibliothèque de composants graphiques pour les
développeurs Angular. Les composants Angular Material aident à créer des pages
Web et des applications Web attrayantes, cohérentes et fonctionnelles tout en respectant les
principes de conception Web modernes tels que la portabilité du navigateur et l'indépendance des
appareils.
2.2.2.5. Déploiement
• FileZilla Client
FileZilla Client [28] est une solution FTP gratuite. Le client FileZilla prend en
charge non seulement le FTP, mais également le FTP sur TLS (FTPS) et SFTP. Il s'agit
d'un logiciel open source distribué gratuitement sous les termes de la GNU General
Public License. Ce logiciel nous a servi pour le déploiement de l’application sur le serveur.
20
2.2.2.6. Conception
• UML
Le Langage de Modélisation Unifié (UML) [29], est un langage de modélisation
graphique à base de pictogrammes conçu pour fournir une méthode normalisée pour
visualiser la conception d'un système. Il est couramment utilisé en développement logiciel
et en conception orientée objet.
• Draw.io
Draw.io est un service pour dessiner des diagrammes en ligne. L’outil permet de créer tout
type de diagramme assez facilement et gratuitement.
2.2.3. Architecture logicielle

La figure 9 représente l’architecture logicielle globale de notre projet et la figure 10
représente le diagramme de paquetages.
• Le module Backend : Ce module contient quatre sous modules : module « Common »,

module « Persistance », module « Métier » et module « Application ».
o Module Persistance : Ce module représente la couche d’accès à la base de données, il
contient les entités et les entrepôts de notre application.
o Module Métier : Il contient tous les services métier de l’application. Il est responsable
de chaque traitement métier.
o Module Application : Ce module contient les services web, il est responsable de la
communication entre les clients et le serveur web par exposition des API Rest à utiliser
par le client.
o Module Common : Il contient les classes, les constantes et les fonctions partagées
entres les autres modules (persistance, métier et application).
• Le module Frontend : Ce module représente la partie client de notre application, il gère les
requêtes utilisateurs pour afficher le contenu des pages web.
21
Figure 9: Architecture logicielle
22
Figure 10: Diagramme de paquetages
23
2.3. Architecture physique
La figure 11 présente le schéma de l’architecture physique de l’application. Cette architecture
nous a servis lors du développement. Cependant, pour le déploiement, on élimine le serveur
Angular qui était nécessaire au développement pour compiler Angular en temps-réel.
Navigateur Node Serveur

MySQL
Web Server Tomcat
Clients Serveur Angular Serveur Serveur de base

d’application de données
s
Figure 11: Architecture physique de l'application
2.4. Conclusion
Lors de ce chapitre, nous avons détaillé les différents outils dont nous avons eu besoin. Puis,
nous avons enchaîné par l’architecture logicielle. Enfin, nous avons présenté l’architecture
physique de notre application. Nous passons, dans la suite, au développement.
24
Chapitre 3 : Développement de la version 1
3.1. Introduction
Ce chapitre porte sur la présentation de la première version. Il est composé de deux sprints :
• Sprint 1 : conception et le développement de la partie « citoyen » version 1.
• Sprint 2 : conception et le développement de la partie « Administrateur » version 1.
3.2. Sprint 1 : Conception et développement de

la partie « citoyen »
Ce sprint porte sur la présentation de la première version de la partie « citoyen ». Ce dernier
se concentre sur la conception et le développement de la partie « citoyen » de l'application. Tout
d’abord, nous introduisons les différentes tâches sélectionnées pour ce sprint. Ensuite, nous
détaillons la conception de ce processus. Puis, nous présentons la partie réalisation de notre travail.
Enfin, nous terminons par l’exécution d’une pile de tests pour l’un des paramétrages ainsi que la
validation des tâches réalisées de la part du client.
3.2.1. Tâches sélectionnées

Le premier sprint concerne la réalisation de la première version de la partie citoyen. Après
le développement de cette partie, le citoyen doit être capable de :
1. Choisir la langue (Dialecte Tunisien / Français)
Cette étape contient une description de l’application et permet au citoyen de choisir
la langue préférée.
2. Remplir des données personnelles
Cette étape représente un formulaire qui contient des questions choix uniques et un
champ à compléter (l'âge) qui s’affichent dans un seul coup. Le citoyen ne pourra
passer à l’étape suivante qu’après avoir rempli tous les champs correctement.
3. Passer les six questions d'émotions
Cette étape contient six questions à 10 choix qui s’affichent une par une.
La réponse est obligatoire à toutes ces questions.
25
Des scores seront calculés et enregistrés dans la base de données après avoir
répondu.
4. Passer les dix questions de la première passation
Cette étape continent dix questions à quatre choix qui s’affiche une par une.
La réponse est obligatoire à toutes ces questions.
D’autres scores vont être calculés et enregistrés dans la base de données après avoir
répondu.
5. Afficher les recommandations
Suite aux réponses à ces questions et des indices spécifiques vont être calculé des
recommandations seront affichés.
6. Passer les dix questions de la deuxième passation après au moins une semaine
Cette partie contient dix questions comme la première passation.
Le citoyen ne peut accéder à cette partie qu’après au moins une semaine, et il ne
peut pas refaire le test à nouveau.
7. Afficher les recommandations
Suite aux réponses aux deux passations et aux indices spécifiques qui vont être
calculés, des recommandations seront affichées.
3.2.2. Analyse des besoins

Pour bien comprendre le but de ce sprint, nous détaillons dans cette partie le scénario
d’exécution de chaque fonctionnalité.
La figure 12 représente le diagramme de cas d’utilisation pour le passage d’un citoyen
26
Figure 12: Diagramme de cas d'utilisation du sprint 1
Le tableau 3 représente le scénario nominal de la partie citoyen.
Tableau 3: Scénario nominal de la partie citoyen
Titre du cas d’utilisation Passer le test
Acteur Citoyen
Pré conditions Publique
Scénario nominal • Accéder à l’application via un navigateur

• Choisir la langue
• Compléter les données personnelles
• Répondre aux six questions
• Passer la première passation
27
• Lire les recommandations
• Revisiter l'application après une semaine
• Passer la deuxième passation
• Lire les recommandations
3.2.3. Backlog
Le tableau 4 représente le backlog de la partie citoyen.
Tableau 4: Backlog sprint 1
Durée Ma
Cas d’utilisation Description
(Heure) participation
100 %
Réunion du début de sprint 2
Insertion des choix dans la base de 100%
4
données.
0%
Interface graphique. 16
Remplir le
formulaire 100%
Ajout des délégations. 12
100%
Test et correction de bugs. 8
Ajout des questions à la base de 100%
2
données
Ajout des dix choix à la base de 100%
Répondre aux 6
données.
questions
0%
d’émotions Interface graphique. 16
50%
2
données.
100%
Ajout des choix à la base de données. 8
Passer la première 0%
consultation
Envoi des réponses à la base de 100%
4
données.
Sauvegarder l’uiid et la date dans le 12.5%
32
navigateur (cookies)
28
50%
Ajout des recommandations à la base 0%
6
de données.
Importer les recommandations selon 100%
8
le cas.
100%
Afficher les recommandations. 4
Lire et les
recommandations 0%
Interface graphique 16
Générer un identifiant unique pour 100%
2
chacun.
100%
2
données.
100%
Ajout des choix à la base de données. 8
Passer la deuxième 0%
consultation
Envoi des réponses à la base de 100%
10
données.
50%
100%
Réunion de fin de sprint 2
3.2.4. Conception UML

3.2.4.1. Diagramme de classes persistantes
La figure 13 représente le diagramme de classes persistantes réalisé lors du premier sprint de
notre application. Nous notons que pour chaque classe persistante (qu’on appelle aussi entity) nous
développons un repository pour les actions d’accès à la base de données, un service pour les
traitements métier, et un controller pour l’échanger avec la partie front.
29
Figure 13: Diagramme des classes persistantes
30
3.2.4.1. Diagramme d’activités
La figure 14 représente le diagramme d’activités réalisé lors du premier sprint de notre application.
Figure 14: Diagramme d'activités
3.2.4.1. Diagramme de séquences

La figure 15 représente le diagramme de séquences réalisé lors du premier sprint de notre application.
31
Figure 15: Diagramme de séquences
32
3.2.5. Réalisation
Cette partie porte sur le développement des différentes interfaces de la partie « citoyen »
et « administrateur » de l’application, ainsi que son déploiement sur le serveur.
Quand l’utilisateur accède à l’URL de notre application 9awiny.rnu.tn/ une page
d’accueil s’affiche comme l’indique la figure 16. Cette page contient une présentation brève
de l’application en français et en dialecte tunisien. Cette page donne la main au client pour
choisir la langue préférée avec laquelle il fera sa consultation.
Figure 16: Interface graphique de la page d'accueil de 9AWINY
En choisissant la langue préférée, le citoyen sera invité à remplir un formulaire de

données concernant sa situation actuelle tout en conservant son anonymat. Ceci est illustré par
l’interface présentée par la figure 17.
33
Figure 17: Interface graphique du Formulaire de données
Après avoir soumis le formulaire, le citoyen sera redirigé vers une enquête de 16
questions dont les six premières sont des questions d’émotions (voir figure18) où le citoyen
doit répondre par une valeur de 1 à 10 selon son sentiment de l’émotion citée. Tandis que le
reste des questions concerne la première consultation (voir figure 19) où le citoyen répondra
par son degré d’accord avec ce qui lui a été demandé.
Figure 18: Exemple de question d'émotion
Après avoir fini, le citoyen aura l’interface de la figure 19 contenant une série de
recommandations lisibles qui l’aideront à améliorer ses habitudes au sein de la semaine qui
suit, ainsi qu’un identifiant généré automatiquement enregistré dans un cookie du navigateur,
qui lui permettra de passer la deuxième consultation dans une semaine.
34
Figure 19: Interface de fin de la 1ère consultation
Si le citoyen se connecte avant la fin d’une semaine, il aura le message inscrit sur la figure
20 et ne pourra passer à la deuxième consultation qu’après 7 jours.
Figure 20: Interface d'accès entre les consultations
En accédant après 7 jours, le citoyen aura la main pour faire sa deuxième consultation et
pourra avoir de nouvelles recommandations selon l’évolution de son état psychologique et de
sa résilience.
Pour assurer une meilleure portabilité de l’application, nous avons opté pour une version
responsive qui peut s’afficher correctement sur les navigateurs des différentes dimensions
d’écrans (smartphone, tablette, PC, …). La figure 21 illustre un aperçu sur la version mobile.
Figure 21: Aperçu sur la version mobile
35
3.3. Sprint 2 : Conception et le développement
de la partie « administrateur »
Ce sprint porte sur la présentation de la première version de la partie « administrateur ».
Ce dernier se concentre sur la conception et le développement de la partie « administrateur »
de l'application. Tout d’abord, nous introduisons les différentes tâches sélectionnées pour ce
sprint. Ensuite, nous détaillons la conception de ce processus. Puis, nous présentons la partie
réalisation de notre travail. Enfin, nous terminons par l’exécution d’une pile de tests pour l’un
des paramétrages ainsi que la validation des tâches réalisées de la part du client.

Le deuxième sprint concerne la réalisation de la première version de la partie
Administrateur. Après le développement de cette partie, l’administrateur doit être capable de :
➢ S’authentifier ;
➢ Consulter les tableaux des scores individuel et synthétique ;
➢ Consulter les tableaux de bord individuel et synthétique ;
➢ Filtrer l’ensemble des indices calculés selon les données personnelles de chaque
catégorie

La figure 22 représente le diagramme de cas d’utilisation. La couleur bleue représente le
sprint 1 et la couleur verte représente le sprint 2.
36
Le tableau 5 représente le scénario nominal de la partie administrateur.
Tableau 5: Scénario nominal de la partie administrateur
Titre du cas Visualiser les résultats

d’utilisation
Acteur Administrateur
Pré conditions Authentification

• S’authentifier
• Consulter le tableau des scores synthétique ou individuel
37
• Consulter le tableau de bord synthétique ou individuel
• Filtrer l’ensemble des indices calculés selon les données
personnelles de chaque catégorie
3.3.3. Backlog
Le tableau 6 représente le backlog de la partie administrateur.
Cas d’utilisation Description Durée Ma

Réunion début du sprint 2 100%
S’authentifier Authentification à l’aide de nom 32 50%

d’utilisateur et mot de passe.
Changer mot de passe 24 0%
Interface graphique 16 0%
Test et correction de bugs 4 100%
Consulter les Un tableau de bord synthétique 16 75%

scores contenant les scores de résilience.
Un Tableau de bord similaire au 16 75%
précédent mais individuel
Un tableau de scores synthétique 16 75%
contenant les scores de sources de
résilience et celles de
vulnérabilité.
Un tableau de bord similaire au 16 75%
précédent mais individuel
Interface graphique 24 80%
Filtrer les indices Filtres sous forme de formulaire. 12 100%
Appliquer plusieurs filtres à la 8 100%
fois.
Réunion fin du sprint 2

La figure 23 représente le diagramme de classes persistantes de notre application où les
classes représentées en vert sont les classes de la partie administrateur (sprint 2), celles en bleu
sont les classes de la partie citoyen (sprint 1).
38
39
3.3.5. Réalisation
Cette partie porte sur le développement des différentes interfaces « administrateur » de
l’application, ainsi que le déploiement de la première version sur le serveur.
L’administrateur peut accéder à sa partie via l’URL http://9awiny.rnu.tn/#/admin/ et doit se
connecter en fournissant son nom d’utilisateur et son mot de passe via l’interface de la figure 24.
Figure 24: Interface d'authentification
En se connectant, l’administrateur se trouve sur un tableau de bord synthétique (figure 25)

calculant les indices selon des formules confidentielles et nécessaires aux statistiques, où il peut
filtrer ces indices selon les données du premier formulaire. Ce tableau de bord permet de comparer
les résultats des deux consultations et l’évolution des citoyens au bout d’une semaine.
Figure 25: Tableau de bord synthétique
40
L’administrateur peut consulter d’autres scores (figure 26 et figure 27) concernant les
sources de résilience et celles de vulnérabilité et les filtrer.
Figure 27: Tableau des scores
Figure 26: Tableau des scores individuels
3.4. Conclusion
Au cours de ce chapitre, nous avons présenté les objectifs à atteindre, puis nous avons
enchaîné par une analyse des besoins, suivie par la conception UML et nous avons fini par la
réalisation de la première version.
41
Chapitre 4 : Développement de la version 2
4.1. Introduction
Ce chapitre porte sur la présentation de la deuxième version. Ce dernier est composé de deux
sprints :
• Sprint 3 : Amélioration de la partie « citoyen ».
• Sprint 4 : Amélioration de la partie « Administrateur ».
4.2. Sprint 3 : Amélioration de la partie

« citoyen »
Ce sprint porte sur la présentation de la deuxième version de la partie « citoyen ». Ce dernier
se concentre sur l’amélioration de la partie « citoyen » de l'application. Tout d’abord, nous
introduisons les différentes tâches sélectionnées pour ce sprint. Ensuite, nous détaillons la
conception de ce processus. Puis, nous présentons la partie réalisation de notre travail. Enfin, nous
terminons par l’exécution d’une pile de tests pour l’un des paramétrages ainsi que la validation des
tâches réalisées de la part du client.

Le troisième sprint concerne la réalisation de la deuxième version de la partie citoyen. Dans
ce sprint les points suivants sont améliorés :
➢ L'interface homme machine (IHM).
➢ Ajouter un type de citoyen (étudiant) qui a deux autres champs de plus (université et
établissement)
➢ Afficher les questions et les recommandations un par uns.
➢ Rendre les recommandations audibles.
➢ Le choix de la passation sera manuel avec un identifiant
42
La Figure 28 représente le diagramme de cas d’utilisation pour le passage d’un citoyen. La
couleur bleue représente le sprint 1, la couleur verte représente le sprint 2, la couleur rouge
représente le sprint 3.
Le tableau 7 représente le scénario nominal de la partie citoyen.
43
Tableau 7: Scénario nominal de la partie citoyen
Titre du cas d’utilisation Passer le test
Acteur Citoyen
Pré conditions Publique

• Choisir la consultation (consultation 1)
• Compléter les données personnelles
• Répondre aux six questions
• Passer la première passation
• Lire et/ou écouter les recommandations
• Revisiter l'application après une semaine
• Choisir la consultation (consultation 2)
• Passer la deuxième passation
• Lire et/ou écouter les recommandations
4.2.3. Backlog
Le tableau 8 représente le backlog de la partie citoyen.
Tableau 8: Backlog du sprint 3
Cas d’utilisation Description Durée Ma

Réunion du début de sprint 2 100%
Remplir le formulaire Insertion des universités et des 4 100%

établissements dans la base de
données.
Interface graphique. 32 50%
Ajout des délégations. 12 100%
44
Test et correction de bugs. 8 50%
Répondre aux Modifier l’affichage des questions 16 100%

questions d’émotions (un par un)
Passer la première Modifier l’affichage des questions 16 100%

consultation (un par un)
Lire et/ou écouter les Ajout des recommandations 6 100%

recommandations audibles à la base de données.
Importer les recommandations 4 100%
selon le cas.
Afficher les boutons media pour 8 100%
écouter les recommandations.
Générer un identifiant unique 2 100%
pour chacun et l’afficher.
Passer la deuxième Modifier l’affichage des questions 16 100%

consultation (un par un)
Ajouter les deux champs : 10 0%
université et des établissement
IHM Modifier l’IHM de l’application 48 50%
Réunion de fin de sprint 2 100%

4.2.1.1. Diagramme de classes persistantes
La figure 29 représente le diagramme de classes persistantes réalisé lors du troisième sprint
de notre application.
La couleur bleue représente le sprint 1, la couleur verte représente le sprint 2 et la couleur
rouge représente le sprint 3.
45
46
4.2.1.1. Diagramme d’activités
La figure 30 représente le diagramme d’activités réalisé lors du troisième sprint de notre application.
La couleur bleue représente le sprint 1 et la couleur rouge représente le sprint 3.
Figure 30: Diagramme d'activités
47
4.2.2. Réalisation
Cette partie porte sur l’amélioration des différentes interfaces de la partie « citoyen » de
l’application.
Quand l’utilisateur accède à l’URL de notre application 9awiny.rnu.tn/ une page
d’accueil s’affiche comme l’indique la figure 31. Cette page contient une présentation brève
de l’application en français et en dialecte tunisien. Cette page donne la main au client pour
choisir la langue préférée avec laquelle il fera sa consultation.
Figure 31: Interface graphique de la page d'accueil de 9AWINY
En choisissant la langue préférée, un pop-up s’affiche comme l’indique la figure 32. A
Figure 32: Pop-up de choix de consultation
48
son premier passage par 9AWINY, le citoyen doit choisir l’option oui pour dire que c’est son
premier passage par l’application.
Par la suite, le citoyen sera invité à remplir un formulaire de données concernant sa

situation actuelle tout en conservant son anonymat. Ceci est illustré par l’interface présentée
par la figure 33.
Figure 33: Formulaire de données
Si au niveau du champ « Mon métier » le citoyen choisit « étudiant », deux champs de
Figure 34: Ajout des champs spécifiques pour les étudiants
49
plus seront affichés : « Université » et « Etablissement », affichés dans la figure 34, qu’il doit
remplir. Ceci a été ajouté lors du deuxième sprint sous la demande du ministère l'enseignement
supérieur et de la recherche scientifique pour des raisons statistiques.
Après avoir soumis le formulaire, le citoyen sera redirigé vers une enquête de 16
questions dont les six premières sont des questions d’émotions (voir figure 35) où le citoyen
Figure 35: Exemple de question d'émotion
doit répondre par une valeur de 1 à 10 selon son sentiment de l’émotion citée. Tandis que le
reste des questions concerne la première consultation (voir figure 36) où le citoyen répondra
par son degré d’accord avec ce qui lui a été demandé.
Figure 36: Exemple de question de la consultation 1
50
Après avoir fini, le citoyen aura l’interface de la figure 37 contenant une série de
recommandations lisibles et audibles qui l’aideront à améliorer ses habitudes au sein de la
semaine qui suit, ainsi qu’un identifiant (ID : 8467c413) généré automatiquement qui lui
permettra de passer la deuxième consultation dans une semaine.
Figure 37: Interface de fin de la 1ère consultation
Si le citoyen se connecte avant la fin d’une semaine en utilisant son ID, il aura le message
inscrit sur la figure 38 et ne pourra passer à la deuxième consultation qu’après 7 jours.
En accédant après 7 jours, le citoyen aura la main pour faire sa deuxième consultation et
Figure 38: Interface d'accès entre les consultations
51
pourra avoir de nouvelles recommandations selon l’évolution de son état psychologique et de
sa résilience.
Pour assurer une meilleure portabilité de l’application, nous avons opté pour une version
responsive qui peut s’afficher correctement sur les navigateurs des différentes dimensions
d’écrans (smartphone, tablette, PC, …). La figure 39 illustre un aperçu sur la version mobile.
Figure 39: Aperçu sur la version mobile
4.3. Sprint 4 : Amélioration de la partie

« administrateur »
Ce sprint porte sur la présentation de la deuxième version de la partie « administrateur ».
Ce dernier se concentre sur l’amélioration de la partie « administrateur » de l'application. Tout
d’abord, nous introduisons les différentes tâches sélectionnées pour ce sprint. Ensuite, nous
détaillons la conception de ce processus. Puis, nous présentons la partie réalisation de notre
travail. Enfin, nous terminons par l’exécution d’une pile de tests pour l’un des paramétrages
ainsi que la validation des tâches réalisées de la part du client.

Après l’amélioration de la partie administrateur, il doit être capable de :
➢ Consulter une carte de répartition des résiliences dans les gouvernorats.

➢ Consulter un diagramme de répartition des résiliences dans les universités.
52
➢ Exporter les données en Excel

La figure 40 représente le diagramme de cas d’utilisation. La couleur bleue représente le
sprint 1, la couleur verte représente le sprint 2, La couleur rouge représente le sprint 3 et la
couleur jaune représente le sprint 4.
Le tableau 9 représente le scénario nominal de la partie administrateur.
53
Tableau 9: Scénario nominal de la partie administrateur
Titre du cas Visualiser les résultats

d’utilisation
Acteur Administrateur
Pré conditions Authentification

• S’authentifier
• Consulter le tableau des scores synthétique ou individuel
• Consulter le tableau de bord synthétique ou individuel
• Télécharger les résultats dans un fichier Excel
• Filtrer l’ensemble des indices calculés selon les données
personnelles de chaque catégorie
• Consulter une carte de répartition des résiliences dans les
gouvernorats
• Consulter un diagramme de répartition des résiliences dans
les universités
4.3.1. Backlog
Le tableau 10 représente le backlog du sprint 4.
Durée Ma
Cas d’utilisation Description
100%
Réunion début du sprint 2
0%
Modifier les filtres 12
Filtrer les indices
0%
Test et correction de bugs 10
Ajout d’un bouton qui permet de 50%
Exporter les télécharger les résultats sous forme de 32
scores filtrés en fichier excel.
Excel 50%
54
Mise en place d’une interface 100%
16
graphique d’une carte géographique.
Consulter la carte Colorier les gouvernorats par un code 100%
24
de résilience couleur selon les résultats.
50%
Consulter le Créer un diagramme de résilience avec 100%
24
diagramme de le même code couleur de la carte.
résilience des 50%
universités
50%
Test et validation Test et validation 40
100%
Réunion fin du sprint 2
50%
Déploiement Déploiement 8
100%
Réunion fin de l’application 4

Dans ce sprint, nous avons gardé la même conception que celui précédent.
4.3.2. Réalisation
Cette partie porte sur l’amélioration de l’interface « administrateur » de l’application.

En se connectant, l’administrateur se trouve sur un tableau de bord synthétique (figure 41)
Figure 41: Tableau de bord synthétique
calculant les indices selon des formules confidentielles et nécessaires aux statistiques, où il
55
peut filtrer ces indices selon les données du premier formulaire. Il peut, par ailleurs, télécharger
un fichier Excel récapitulatif de résultats afin de garder une trace. Ce tableau de bord permet
de comparer les résultats des deux consultations et l’évolution des citoyens au bout d’une
semaine.
La partie administrateur est munie d’une carte de résiliences selon les gouvernorats
illustrée dans la figure 42 et d’un diagramme de résilience des universités montré par la figure
43.
Figure 42: Carte de résiliences
Figure 43: Diagramme de résilience des universités
56
4.3.3. Déploiement et lancement de l’application
Nous avons compilé la partie front-end. Puis, nous avons généré le WAR de l’application.
Par la suite, nous avons exporté la base de données sur un serveur MySQL. Enfin, à l’aide d’un
accès FTP, nous avons déployé l’archive englobant l’application (*.war) sur un serveur tomcat,
le 20 mai 2020.
Après le déploiement en mode production, nous avons fait appel au tableau comparatif
élaboré dans la section étude de l’existant et nous avons positionné notre application avec. Le
tableau 11 illustre clairement les valeurs ajoutées de notre application par rapport à l’existant.
Tableau 11: Comparaison entre les solutions existantes et notre application
Application Fabulous Stop Corona Google Forms 9awiny
Coté citoyen
UI ✔ ✔ ✘ ✔
Recommandation lisible ✔ ✔ ✔ ✔
Recommandation audible ✘ ✘ ✘ ✔
Anonymat ✔ ✔ ✔ ✔
Suivi ✘ ✘ ✘ ✔
Coté administrateur
Confidentialité ✔ ✘ ✔
Jauge ✘ ✘ ✔
Histogramme ✔ ✔ ✔
Carte géographique ✔ ✘ ✔
Filtre sur les réponses ✔ ✔ ✔
Filtre sur les indices ✘ ✘ ✔
Authentification ✔ ✔ ✔
UI ✔ ✘ ✔
Convertir les données en Excel ✘ ✔ ✔
Après la validation du Prof. Slim MASMOUDI, le ministre de l'enseignement supérieur
57
et de la recherche scientifique, M. Slim CHOURA, a lancé l’application le 12 juin 2020 dans
une conférence de presse organisée spécialement à cette fin.
4.4. Conclusion
Au cours de ce chapitre, nous avons présenté les objectifs à atteindre, puis, nous avons
enchaîné par une analyse des besoins, suivi par la réalisation de la deuxième version et nous
avons fini par le déploiement de la deuxième version de l’application sur le serveur du client.
58
Conclusion générale
Le présent document est une présentation du travail réalisé durant notre projet de fin
d’études au sein de la filiale DK Soft de la société Digital-Click.
Notre mission consiste à développer une application web pour le diagnostic et le conseil
des citoyens, et pour fournir les statistiques nécessaires aux experts. Nous avons commencé
par la compréhension du contexte générale du projet et l’identification des différentes
exigences du système. Nous avons, ensuite, opté pour la méthodologie de travail agile Scrum
pour prioriser nos tâches et dessiner un plan de travail clair et détaillé.
Malgré les contraintes de temps et les difficultés techniques que nous avons rencontrées
qui se résument principalement dans la compréhension du sujet et dans la complexité de son
architecture, le travail réalisé était d’une importance considérable dans la mesure où nous avons
pu atteindre une partie importante de nos objectifs initialement identifiés.
Notre application offre plusieurs fonctionnalités pour faciliter le processus de statistiques
notamment dans le domaine de psychologie. En effet, elle permet au citoyen d’améliorer ses
habitudes pour maintenir sa santé psychologique et mentale à travers des recommandations
faites par des experts en psychologie. « 9AWINY » permet en plus de faire les études
statistiques pour s’assurer de la santé psychologique des citoyens.
Ce projet est ouvert à des extensions ultérieures en y ajoutant la compilation des codes
en ligne au cours du passage de test des réponses aux psycho-questions. Nous pouvons aussi
ajouter la possibilité de changer les questions ouvertes via une interface graphique.
59
Webographie
[1] Fabulous, https://www.thefabulous.co/ [Accès le 03-02-2020]

[2] Stop corona, https://www.stopcorona.gov.tn/ [Accès le 03-02-2020]
[3] google forms, https://docs.google.com/forms/u/0/ [Accès le 03-02-2020]
[4] Scrum, https://www.journaldunet.fr/web-tech/guide-de-l-entreprise-digitale/ [Accès le 06-
02-2020]
[5] Scrum, URL https://www.scrum.org/ [Accès le 04-04-2020]
[6] Eclips, https://www.eclipse.org/ [Accès le 09-04-2020]
[7] WebStorm, URL https://www.jetbrains.com/webstorm/ [Accès le 02-04-2020]
[8] Bitbucket URL https://bitbucket.org/product/guides/getting-started/overview/ [Accès le
30-03-2020]
[9] Jira, URL https://confluence.atlassian.com/jirasoftwareserver/jira-software-overview-
938845024.html [Accès le 30-03-2020]
[10] Slack, https://slack.com/ [Accès le 04-04-2020]
[11] MySQL, 2018, URL http://sql.sh/sgbd/mysql/ [Accès le 15-04-2020]
[12] Postman, URL https://www.postman.com/ [Accès le 30-04-2020]
[13] Xampp, URL https://www.apachefriends.org/fr/index.html [Accès le 02-05-2020]
[14] Java, https://www.oracle.com/java/ [Accès 09-04-2020]
[15] Jakarta EE, URL https://jakarta.ee/ [Accès le 09-04-2020]
[16] Spring Boot, URL https://spring.io/projects/spring-boot/ [Accès le 09-04-2020]
[17] Spring DATA, URL http://projects.spring.io/spring-data/ [Accès le 09-04-2020]
[18] Hibernate,URL http://hibernate.org/orm/ [Accès le 09-04-2020]
[19] Spring Security,URL https://spring.io/projects/spring-security/ [Accès 09-04-2020]
[20] Maven, 2018, URL https://maven.apache.org/ [Accès le 09-04-2020]
[21] HTML, URL https://www.w3schools.com/htmL/ [Accès le 10-05-2020]
[22] CSS, 2016, URL https://www.w3.org/Style/CSS/ [Accès le 10-05-2020]
[23] Bootstrap, URL https://getbootstrap.com/ [Accès le 10-05-2020]
[24] TypeScript, URL https://www.typescriptlang.org/ [Accès le 10-05-2020]
[25] Angular, URL https://angular.io/docs/ [Accès le 10-05-2020]
[26] ngx-charts, URL https://swimlane.github.io/ngx-charts [Accès le 10-05-2020]
[27] Angular Materials, URL https://material.angular.io/ [Accès le 10-05-2020]
[28] FileZilla Client, URL https://filezilla-project.org/ [Accès le 01-06-2020]
[29] UML, URL https://www.uml.org/ [Accès le 06-04-2020]
60
Conception et développement d’une
application de diagnostic, de conseil, et
d’adaptation face aux situations
difficiles
Ahmed LEHYANI
‫ إلى تصميم وتطوير وإعداد تطبيق ويب‬، DK Soft ‫ الذي تم تنفيذه في شركة‬،‫ يهدف مشروع نهاية الدراسة‬:‫مل ّخص‬
..)‫يسمى "قويني" الكتساب القوة النفسية وبناء المرونة (القدرة على التعامل مع المواقف الصعبة واالستجابة بشكل إيجابي‬
‫ لتطوير تطبيق يسمح للمواطنين بإجراء مسح عن بُعد وتلقي التوصيات‬Angular ‫ و‬Spring Boot ‫استخدمنا إطار عمل‬
Agile ‫ لقد اعتمدنا منهجية‬.‫(االستشارة عن بُعد) حتى يتمكن المشرفون (علماء النفس) من استشارة النتائج المحسوبة‬
.‫ في تحقيق هذا المشروع‬Scrum
Résumé : Ce projet de fin d’études, effectué au sein de la société DK Soft, a pour objectif
de concevoir, développer et mettre en place une application web intitulée «9AWINY» pour
prendre des forces psychologiques et renforcer sa résilience (capacité à faire face aux situations
difficiles et à rebondir positivement). Nous avons utilisé les frameworks Spring Boot et
Angular pour développer une application qui permet aux citoyens de passer une enquête à
distance et recevoir des recommandations (Consultation à distance) afin que les administrateurs
(des psychologues) puissent consulter les scores calculés. Nous avons adopté la méthodologie
agile Scrum dans la réalisation de ce projet.
Summary: This end of studies project, carried out within the company DK Soft, aims to
design, develop and implement a web application called "9AWINY" to gain psychological
strength and build resilience (ability to cope with difficult situations and to bounce back
positively). We used the Spring Boot and Angular frameworks to develop an application that
allows citizens to take a remote survey and receive recommendations (Remote consultation) so
that admins (psychologists) can consult the calculated scores. We adopted the Agile Scrum
methodology in the realization of this project.
‫ مقياس المرونة‬, ‫ الواب‬, ‫ سكروم‬, ‫ أنقالر‬, ‫ سبرينق‬, ‫ تطبيق الويب‬:‫مفاتيح‬

Mots clés : Application Web, Spring, Angular, Scrum, web, Baromètre de résilience.
Key-words: Web Application, Spring, Angular, Scrum, web, resilience barometer.

Langue

Rapport PFE AhmedLehyani-V10

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Rapport PFE AhmedLehyani-V10

Transféré par

Droits d'auteur :

République Tunisienne Cycle de Formation d’Ingénieurs

Ministère de l’Enseignement Supérieur dans la Discipline

Université de Sfax Projet de Fin d’Etudes

L’Ecole Nationale d’Ingénieurs de Sfax

Du Diplôme National d’Ingénieur en Génie Informatique

Conception et développement d’une

Soutenu le 08 Juillet 2020, devant la commission d'examen :

Mme. Fadoua DRIRA Président

Pour ceux qui ont cru en moi,

Ceux qui m’ont aimé et supporté,

Pour ceux qui ont fait de moi,

Ce que je suis aujourd’hui,

Ma sœur, Mon frère

Mes très chers amis,

Tous les membres de l’IEEE

Et spécialement ceux de l’ENIS Student branch

Je présente ce modeste travail

Grâce à vous et pour vous.

Introduction générale ...................................................................................................................... 1

Chapitre 1 : Cadre et méthodologie de travail .............................................................................. 3

1.1. Introduction ...................................................................................................................... 3

1.2. Présentation de l’organisme d’accueil.............................................................................. 3

1.3. Présentation du stage ........................................................................................................ 4

1.4. Présentation du projet ....................................................................................................... 4

1.4.1. Etude de l’existant..................................................................................................... 4

1.4.2. Objectifs .................................................................................................................... 7

1.4.3. Besoins du client ....................................................................................................... 8

1.4.4. Besoins non fonctionnels .......................................................................................... 9

1.5. Méthodologie de travail ................................................................................................... 9

1.5.1. Les méthodes agiles ................................................................................................ 10

1.5.2. Comparatif des principales méthodes agiles ........................................................... 10

1.5.3. Méthodologie de travail adoptée ............................................................................. 11

Chapitre 2 : Architectures et exigences ...................................................................................... 14

2.1. Introduction .................................................................................................................... 14

2.2. Architecture et environnement logiciels ........................................................................ 14

2.2.1. Environnement logiciel ........................................................................................... 14

2.2.2. Technologies utilisées ............................................................................................. 16

2.2.3. Architecture logicielle ............................................................................................. 21

2.3. Architecture physique .................................................................................................... 24

3.1. Introduction .................................................................................................................... 25

3.2. Sprint 1 : Conception et développement de la partie « citoyen » ................................... 25

3.2.1. Tâches sélectionnées ............................................................................................... 25

3.2.2. Analyse des besoins ................................................................................................ 26

3.2.3. Backlog ................................................................................................................... 28

3.2.4. Conception UML .................................................................................................... 29

3.3. Sprint 2 : Conception et le développement de la partie « administrateur » ................... 36

3.3.1. Tâches sélectionnées ............................................................................................... 36

3.3.2. Analyse des besoins ................................................................................................ 36

3.3.3. Backlog ................................................................................................................... 38

3.3.4. Conception UML .................................................................................................... 38

Chapitre 4 : Développement de la version 2 ............................................................................... 42

4.1. Introduction .................................................................................................................... 42

4.2. Sprint 3 : Amélioration de la partie « citoyen » ............................................................. 42

4.2.1. Tâches sélectionnées ............................................................................................... 42

4.2.2. Analyse des besoins ................................................................................................ 43

4.2.3. Backlog ................................................................................................................... 44

4.2.1. Conception UML .................................................................................................... 45

4.3. Sprint 4 : Amélioration de la partie « administrateur » .................................................. 52

4.3.1. Tâches sélectionnées ............................................................................................... 52

4.3.1. Backlog ................................................................................................................... 54

4.3.1. Conception UML .................................................................................................... 55

4.3.3. Déploiement et lancement de l’application............................................................. 57

Conclusion générale ...................................................................................................................... 59

Figure 1: Logo Digital Click ........................................................................................................... 3

1.2. Présentation de l’organisme d’accueil