Institut Supérieur des Etudes Technologiques de ………..

Département Technologies de

l’informatiqueRapport de Projet

de Fin d’Etudes :

Conception et réalisation d'un

………………………
………..
Elaboré par :
Barhoumi Achref

Encadré par :
Mr. ……………..

Société d’accueil : . ………………….

Année Universitaire : 2023-2024

 Dédicace

Je dédie ce travail en témoignage de nos profonds respects, nos grands amours et toute
nosgratitudes à :

Mes chers parents,

Tous les membres mes

familles,

Et tous mes amis,

Et tous ceux qui de près ou de loin, j’ai contribué d’une manière ou d’une autre à la réalisation
de ce rapport.
 Remerciement

On remercie dieu le tout puissant de nous avoir donné la santé et la volonté d’entamer et de
terminer ce projet de fin d’année.

Mes remerciements s’adressent également à tous les membres de ……..(fac)

Tout d’abord, Veuillez bien recevoir notre remerciement pour le grand honneur que vous
nous avez fait d'accepter de nous encadrer, ce travail ne serait pas aussi riche et n’aurait pas
pu avoir lejour sans l’aide et l’encadrement de

Mr Kamel Garrouch
Vous avez bien voulu nous guider à chaque étape de ce travail riche d’intérêt durant toute sa
réalisation. Vous nous avez toujours réservé le meilleur accueil, malgré vos obligations
professionnelles. Nous saisissons cette occasion pour vous exprimer notre profonde gratitude
touten vous témoignant notre respect.

Mr Maher Amara
Votre compétence, votre encadrement ont toujours suscité notre profond respect. Nous vous
remercions pour votre accueille et vos conseils, malgré vos obligations professionnelles.
Veuilleztrouver ici, l’expression de nos gratitudes et de notre grande estime.

Aux membres du jury

Messieurs les jurys, vous nous faites un grand honneur en acceptant de juger ce travail.

Je tiens à remercier chaleureusement, tous nos proches et tous ceux qui, de près
ou de

loin, nous ont apportés leurs sollicitudes pour accomplir ce Travail.

 Table des matières
Contents
INTRODUCTION GÉNÉRALE ............................................................................. 1

CHAPITRE 1 : CADRE GÉNÉRAL DU PROJET............................................ 3

1. Introduction ............................................................................................................................................... 3
2. Contexte académique ............................................................................................................................ 3
3. Présentation de l’organisme d’accueil ................................................................................................ 3

3.1. Services..................................................................................................................................4
4. Étude de l’existant ................................................................................................................................ 4
5. Critiques de l’existant ........................................................................................................................... 5
6. Solution proposée .................................................................................................................................... 5
7. Choix méthodologique .......................................................................................................................... 6

7.1. Principe de la méthodologie agile Scrum.............................................................................6

7.2. Justification de choix ............................................................................................................7

8. Conclusion ................................................................................................................................................ 7

Chapitre 2 : Planification et spécification des besoins............................................................. 8

1. Introduction .............................................................................................................................................. 8
2. Identification des acteurs ...................................................................................................................... 8
3. Besoins fonctionnels ................................................................................................................................ 9
4. Besoins non fonctionnels ....................................................................................................................... 10
5. Diagramme de cas d’utilisation général ................................................................................................ 11
6. Pilotage du projet avec Scrum ............................................................................................................ 11

6.1. Présentation de la méthode Scrum .....................................................................................11

6.2. Équipe de travail .................................................................................................................13

6.3. Backlog du produit..............................................................................................................14

6.4. Découpage du projet avec SCRUM ....................................................................................17

7. Conclusion .............................................................................................................................................. 18

Chapitre 3 : Lancement du projet & Environnement du travail ............................................... 20

1. Introduction ............................................................................................................................................ 20
2. Choix technologique ............................................................................................................................ 20
3. Environnement Matériel ...................................................................................................................... 25
Tableau 3: : environnement matérie .................................................................................................................. 25
4. Diagramme de déploiement .................................................................................................................... 26
5. Diagramme de déploiement docker .................................................................................................. 27
6. Diagramme de séquence de pipeline ................................................................................................ 29
7. Conclusion .............................................................................................................................................. 30

Chapitre 4 : Sprint 1 ...................................................................................................... 31

1. Introduction ............................................................................................................................................ 31
2. Backlog sprint 1..................................................................................................................................... 31
3. Planification de Sprint ............................................................................................................................ 35
4. Objectif de Sprint .................................................................................................................................... 35
5. Diagramme de cas d’utilisation .............................................................................................................. 36
6. Diagramme de classe sprint1 .................................................................................................................. 36
7. Conclusion .............................................................................................................................................. 37

Chapitre 5 : Sprint 2 ...................................................................................................... 38

1. Introduction ............................................................................................................................................ 38
2. Backlog sprint 2..................................................................................................................................... 38
3. Planification de sprint ........................................................................................................................... 41
4. Objectif de Sprint .................................................................................................................................. 41
5. Réalisation............................................................................................................................................... 41
6. Conclusion............................................................................................................................................... 46

Chapitre 6 : Sprint 3 ...................................................................................................... 47

1. Introduction ............................................................................................................................................ 47
2. Planification de sprint ........................................................................................................................... 47
3. Objectif de sprint ................................................................................................................................... 47
4. Choix technologiques ............................................................................................................................ 48
5. Réalisation............................................................................................................................................... 48
6. Conclusion............................................................................................................................................... 53

Chapitre 7 : Sprint 4 ...................................................................................................... 54

1. Introduction ............................................................................................................................................ 54
2. Planification de Sprint .......................................................................................................................... 54
3. Objectif de sprint ................................................................................................................................... 54
4. Réalisation............................................................................................................................................... 54
5. Conclusion ............................................................................................................................................... 58

CONCLUSION Générale ......................................................................................... 59

PERSPECTIVE ........................................................................................................... 61

ANNEXE ........................................................................................................................ 62

NETOGRAPHIE ......................................................................................................... 75

BIBLIOGRAPHIE ...................................................................................................... 75
 Liste des figures
Figure 1:logo ............................................................................................................................................3
Figure 2: la méthodologie agile Scrum.....................................................................................................6
Figure 3: diagramme de cas d'utilisation général ...................................................................................11
Figure 4: méthodologie scrum ................................................................................................................13
Figure 5: planification des sprint ...........................................................................................................18
Figure 6: diagramme de gantt .................................................................................................................18
Figure 7: logo DevOps ...........................................................................................................................22
Figure 8: Scalabilité................................................................................................................................23
Figure 9: La conteneurisation .................................................................................................................24
Figure 10: Une pipeline CI/CD ..............................................................................................................25
Figure 11: diagramme de déploiement ...................................................................................................26
Figure 12: Le Diagramme De Deployment Du Docker Swarm .............................................................28
Figure 13: Diagramme de séquence de pipeline .....................................................................................29
Figure 14:Le Diagramme De Case d'utilisation du système d'authentification ......................................36
Figure 15: Diagramme de classe sprint1 ................................................................................................37
Figure 16: Le Code Base de l'Intégration de NextJS ..............................................................................43
Figure 17:Dashboard de Login ...............................................................................................................44
Figure 18: Dashboard Principale (PWA)................................................................................................44
Figure 19: Dashboard Principale (WEB)................................................................................................45
Figure 20:Contrôle De Saisie de Create Account interface ....................................................................46
Figure 21:Contrôle De Saisie de Mot De Passe Oublié Interface ..........................................................46
Figure 22: Le Création Des Conteneurs Docker ....................................................................................52
Figure 23: La Dockerization de l’application .........................................................................................52
Figure 24: Le Code de fichier Jenkinsfile du pipeline............................................................................57
Figure 25: Les Analyse du Code avec Sonarqube ..................................................................................58
Figure 26: Le Résultat de l'exécution du Jenkins Pipeline .....................................................................58
Figure 27: Le Dashboard de B2C ..........................................................................................................62
Figure 28:Le Dashboard des Prospects ..................................................................................................63
Figure 29: Le Dashboard des listes noirs................................................................................................63
Figure 30 :Le Dashboard des extracteurs des téléphones .......................................................................64
Figure 31:Le Dashboard des Business (B2B).........................................................................................64
Figure 32: Le Dashboard des lqualif ......................................................................................................65
Figure 33: Le Dashboard des Clients .....................................................................................................65
Figure 34: Le Dashboard des Campaigns ..............................................................................................66
Figure 35: Aspect de Sécurité utilisant les tokens ..................................................................................67
Figure 36: Le Contrôle de Saisie pour l’interface de Login ...................................................................68
Figure 37: Suite de l‘interface principale de Sonarqube ........................................................................69
Figure 38: . Des détections d’anomalies du code du Dashboard Sonarqube ..........................................70
Figure 39: Des recommandations de correction du Dashboard Sonarqube ............................................70
Figure 40: Des statistiques du Dashboard SonarQube pour le Projet .....................................................71
Figure 41: Des statistiques du Dashboard SonarQube pour le code base...............................................72
Figure 42: Les différents stage du pipeline Jenkins ...............................................................................72
Figure 43: Les Configurations pour le pipeline Jenkins .........................................................................73
Figure 44: Les logs de stage Unit Tests ..................................................................................................73
Figure 45: Les logs des stages Sonarqube et test de Qualité ..................................................................74
Figure 46: Les logs de stage Build ........................................................................................................74
Figure 47: Les logs des stages Cleaning, Deploy et envoi d’Email .......................................................75
 Liste des tableaux
Tableau 1: membres de l'équipe scrum ..................................................................................................14
Tableau 2 backlog du produit .................................................................................................................17
Tableau 3: : environnement matérie ......................................................................................................25
Tableau 4: Authentification ....................................................................................................................33
Tableau 5:Réinitialisation du Mot de Passe ...........................................................................................34
Tableau 6:Backlog Du Sprint 1 ..............................................................................................................35
Tableau 7: Backlog sprint 2 ....................................................................................................................41
 Liste des Abréviation

API = Application Programming Interface

CD = Continuous Deployment

CI = Continuous Integration

CLI = Command Line Interface

DEV = Developer

ERP = Enterprise Resource Planning

HA = High Availability

IP = Internet Protocol

JS = JavaScript

SCM = Source Code Management

UML = Unified Modeling Language

UX = User Experience

PWA = Progressiv Web App

YAML = YAML Ain't Markup Language

 L'informatisation a profondément marqué notre vie quotidienne en simplifiant
nos tâches et en améliorant notre efficacité. Cette révolution technologique, amorcée dès
l'ère moderne, a apporté des innovations majeures qui ont remodelé la manière dont les
êtres humains pensent et vivent. Son objectif principal est d'améliorer le bien-être et le
confort de l'individu dans tous les domaines.

Le secteur de la technologie de l'information occupe une place prépondérante dans

cetterévolution, avec des évolutions constantes au fil du temps. Il est difficile d'ignorer
l'impact profond qu'il a eu sur notre société et notre économie. Le développement web,
les pratiques DevOps, et les méthodologies agiles sont parmi les pierres angulaires de
cette transformation continue.

Les méthodologies agiles, en particulier, ont radicalement changé la manière dont

les projets informatiques sont gérés. Elles mettent l'accent sur la flexibilité, la
collaboration et la livraison continue, permettant ainsi aux équipes de mieux s'adapter aux
changements constants de l'environnement technologique. Cette approche agile se
répercute sur tous les aspects de l'industrie informatique, de la conception à la mise en
production, en passant par le développement et les opérations.

Dans ce contexte en constante évolution, nous présentons notre projet de fin

d'études. Il vise à explorer les défis et les opportunités offerts par l'industrie IT tout en
adoptant les principes de l'agilité. Notre projet représente une occasion unique de
contribuer aux avancées technologiques et de répondre à des besoins concrets, tout en
mettant en pratique les méthodesagiles pour garantir la réussite du projet.
C’est dans ce cadre que s’inscrit mon projet de fin d’année qui prend place dans le monde en
perpétuelle mutation de l'informatique. Il est hébergé au sein de la société MaherDEV, sous le
nom de CallCenter. Dansles chapitres à venir, nous détaillerons son importance, ses objectifs,
et les solutions que nous avons mises en œuvre pour relever ses défis spécifiques. Nous avons
joué un rôle central dansla réalisation de ce projet, répondant ainsi aux besoins de l'entreprise
ACHREF BARHOUMI 1
et de ses clients.

Par le biais de ce rapport, j’ai détaillé les différentes étapes par lesquelles nous avons
passées pour réaliser ce projet. Le présent rapport s’articule autour de quatre parties :

 La première partie présente le cadre général du projet, à savoir l’organisme

d’accueil, l’étudede l’existant, notre solution proposée et la méthodologie de
réalisation suivie.
 La deuxième partie est consacrée pour les spécifications générales, la
modélisation desbesoins et la présentation de la méthodologie de pilotage de
mon projet.
 La troisième partie présente l’architecture de l’application ainsi que les
différentestechnologies et outils utilisés pour le développement du projet.

 La dernière partie détaille les phases séquentielles de développement de

mon projet,présentées sous forme de Sprint.

Je clôture ce rapport par une conclusion qui établit le bilan du travail et nous
donnonsquelques perspectives envisageables au présent projet.

ACHREF BARHOUMI 2
1. Introduction

Ce chapitre introductif sera réservé pour présenter le contexte général de notre projet.
Il comporte en premier lieu une étude de l’existant afin d’identifier les lacunes de la
procédure actuelle. Nous proposons par la suite une solution tout en présentant la
méthodologie de travail adoptée lors de la réalisation du projet tout en argumentant
notre choix.

2. Contexte académique

Mon stage de PFE vise à ma transition vers le monde professionnel en me permettant

de mettre en pratique les connaissances théoriques acquises au cours de ma
formation en tant qu'ingénieur en Génie Logiciel à l'École Polytechnique de Sousse
(EPS). Au sein de la société "MaherDEV," j'ai été chargé de concevoir une
application web dockerisée basée sur leFramework Django pour la partie backend et
le Framework NextJS pour la partie frontend, avec l'objectif ultime d'automatiser son
déploiement via un pipeline Jenkins. Mon stage, d'une durée de 4 mois, s'est
principalement concentré sur la conceptualisation de l'application, l'acquisition de
compétences en matière d'outils et le développement de la solution.

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

MaherDEV occupe une place prééminente en tant qu'entreprise

innovante et visionnaire, spécialisée dans le développement de
solutions numériques qui sont non seulement adaptées aux besoins
présents de ses clients, mais qui vont au-delà en anticipant les
opportunités et les évolutions futures du paysage technologique.
Figure 1:logo

ACHREF BARHOUMI 3
 3.1. Services
MaherDEV a sept grands domaines d’activité :
● Développement logiciel : Experts en applications de bureau, mobiles,
web, ERP, etsécurité logicielle.
● Développement web : Création de sites web, optimisation pour les
moteurs derecherche, hébergement, e-commerce, et sécurité web.
● Développement mobile : Conception d'applications mobiles, UI/UX
attrayante, etsécurité mobile.
● Analyse de données : Intelligence d'affaires pour des décisions éclairées.
● Cloud : Hébergement web sécurisé.
● Sécurité : Protégez vos logiciels, sites web, applications mobiles et
données dans lecloud.
● Marketing numérique : Stratégies digitales, SEO, médias sociaux, contenu
et marketingvidéo.

4. Étude de l’existant

L'étude de l'existant constitue la première étape cruciale de notre projet visant à développer
la solution ERP pour centre d'appels, CallCenter ERP. Cette phase a permis de dresser un
état des lieux complet des processus, des systèmes en place, des défis rencontrés et des
opportunités d'amélioration au sein de notre centre d'appels existant.
Actuellement, notre centre d'appels fonctionne avec divers systèmes et outils dispersés,
entraînant des inefficacités opérationnelles et une complexité accrue dans la gestion des
données clients et des prospects.
Les agents utilisent plusieurs plates-formes pour gérer les appels, les informations clients,
et les commandes, ce qui entraîne des retards et des erreurs potentielles.
De plus, l'authentification et la sécurité des données sont devenues des préoccupations
majeures à mesure que notre centre d'appels a évolué.
L'étude de l'existant a révélé des lacunes en matière de gestion des rôles et des autorisations,
ainsi qu'un besoin pressant de renforcer la sécurité des données pour protéger la

ACHREF BARHOUMI 4
 confidentialité des informations clients.
En outre, l'analyse de l'existant a mis en évidence des opportunités significatives pour
améliorer la gestion des prospects, notamment la validation des données, la gestion des
"numéros à ne pas appeler",
et la géolocalisation des prospects pour une prospection plus ciblée.
Dans cette phase, nous avons également examiné les processus de gestion des commandes
et identifié des domaines où une optimisation est nécessaire pour accélérer le traitement
des commandes client et améliorer l'expérience globale du client.
En somme, l'étude de l'existant a permis de mettre en lumière les défis et les lacunes actuels
de notre centre d'appels, ce qui nous a conduit à entreprendre ce projet de développement
de la solution CallCenter ERP. Notre objectif est de répondre à ces défis, d'améliorer
l'efficacité opérationnelle, et de fournir une plateforme unifiée pour gérer l'ensemble de
nos processus métier essentiels.

5. Critiques de l’existant

L'évaluation de l'existant révèle une infrastructure fragmentée et complexe, caractérisée

par une multitude d'outils disparates entraînant des retards dans les processus, des
vulnérabilités en matière de sécurité, un manque de suivi analytique, et une sous-
exploitation des opportunités de gestion des prospects et des commandes.
Ces limitations compromettent notre efficacité opérationnelle et la qualité de l'expérience
client, justifiant ainsi la mise en œuvre du projet CallCenter ERP pour remédier à ces
problèmes et offrir une plateforme
intégrée et sécurisée pour la gestion de nos activités de centre d'appels.

6. Solution proposée

Nous nous plongerons dans l'exploration détaillée des besoins, tant fonctionnels que non
fonctionnels, de notre projet. Nous entreprendrons une analyse approfondie des
fonctionnalités essentielles que notre solution doit offrir, tout en examinant attentivement
les aspects de performance, de sécurité et d'évolutivité. Parallèlement à cette étude, nous
concentrerons nos efforts sur l'établissement de diagrammes de conception
préliminaires, illustrant la structure et les interrelations des composants clés de notre

ACHREF BARHOUMI 5
 solution.
Ces diagrammes serviront de boussole pour la suite de notre travail, guidant notre équipe
dans
la création d'une solution qui répondra de manière optimale aux besoins de notre projet,
tout
en assurant la cohérence et la clarté de notre vision.

7. Choix méthodologique

Une méthodologie est un système de pratiques, de techniques, de procédures et de

règles utilisées dans une discipline afin de contrôler et planifier un projet visant à avoir
un produit final d’une bonnequalité et dans un délai de livraison satisfaisant. Choisir
une méthodologie parmi plusieurs qui convient le mieux à notre projet est important
parce qu’elle détermine notre façon de travailler et elle nous fournit les structures qui
peuvent nous guider vers la réussite ou l’échec de notre projet, cequi nous mène au
méthode de développement agile qui est orientée projet informatique dont ses
ressources sont régulièrement actualisées et plus précisément la méthode Scrum qui
vise à satisfaireau mieux les besoins du client en raison de sa flexibilité apparente qui
permet de faire pivoter le projet, ce qui leur donne plus d’occasions de changer d’avis
continuellement.

7.1. Principe de la méthodologie agile Scrum

Figure 2: la méthodologie agile Scrum

La méthode agile est une méthodologie de gestion de projet qui repose sur un cycle
ACHREF BARHOUMI 6
 de développement itératif, incrémental et adaptif qui a pour but d’améliorer le process
et de réduire letaux d’échec en mettant en place le client au cœur du projet. Étant
donné que la méthode Scrum estconsidérée comme méthode agile, elle suppose donc
que le développement d’un logiciel n'est pas prévisible et ne peut donc pas suivre le
processus défini traditionnelle, afin d’améliorer la productivité des équipes tout en
permettant une optimisation du projet grâce à des feedbacks réguliers avec le client
ou les utilisateurs finaux.

7.2. Justification de choix

Mon choix de Scrum comme méthodologie de pilotage et de gestion de mon projet se

base sur lesavantages et les atouts de ce dernier qui se résument comme suit :

 La capacité de contrôle qu’offre le Scrum sur le produit final grâce à la manière

incrémentale et itératif rapide du travail ce qui permet au produit d’être
modifié et pivoté selon le besoin du client.
 La compréhension des tâches à accomplir en subdivisant le projet en plusieurs
parties réalisable ce qui facilite l’optimisation en continu des étapes et des
tâches qui nous mènent à notre objectif final.
 La rapidité de développement et d’avancement du projet qui est due aux
échéances intégréeschaque jour pour évaluer l’avancement ce qui implique
que tout le monde prenne ses responsabilités.

8. Conclusion

Dans ce premier chapitre, j’ai présenté le cadre général du projet à savoir l’organisme
d’accueil MaherDEV au sein de laquelle j’ai passé mon stage. J’ai aussi étudié
l’existant afin de relever ses défaillances et proposer des solutions d’optimisation.
Finalement nous avons dévoilé la méthodologie de travail utilisé durant mon projet.

Dans le chapitre qui suit j’ai mis l’accent sur la phase de planification et
spécificationdes besoins.

ACHREF BARHOUMI 7
1. Introduction

Avant de développer notre application, nous proposons de commencer par la phase de

spécification pour bien organiser et clarifier les tâches de mon projet. Ce chapitre
consiste donc à identifier les acteurs de mon système ainsi que les besoins
fonctionnelles et non fonctionnelles. J’ai détaillée mon travail avec la méthodologie
choisie dans le chapitre précédent. Enfin, je produis le backlog initial ainsi qu’une
première planification des sprints.

2. Identification des acteurs

Pour préparer les besoins fonctionnels et non fonctionnels de mon application, je

procède icià l’identification des acteurs de mon système tout en détailler le rôle de
chacun. Un acteur est uneentité externe au système, il présente une personne ou un
autre système informatique qui attend unou plusieurs services offerts par une interface
d’accès qui interagit avec le système par envoi ou parréception des messages. En se
basant sur cette définition, nous avons dégagé la liste des acteurs de notre système
présentée ci-dessous :

 Utilisateurs du Centre d'Appels : Ce sont les agents, les superviseurs et les

gestionnaires travaillant dans le centre d'appels. Ils utilisent le système pour
gérer les appels, les prospects, les commandes et d'autres tâches liées au centre
d'appels.

 Clients : Les clients qui interagissent avec le centre d'appels pour poser des
questions,

passer des commandes ou demander des informations font partie des acteurs
du système.
ACHREF BARHOUMI 8
  Prospects : Les prospects, qui sont les personnes ou les entreprises
potentielles à contacter pour des opportunités commerciales, sont également
des acteurs importants du système.

Responsables de Campagnes : Les personnes responsables de la gestion des campagnes de marketing

ou d'appels sortants utilisent le système pour configurer et suivre les campagne
3. Besoins fonctionnels

 Description : Le système doit permettre aux utilisateurs du centre d'appels de gérer

efficacement les prospects, de les importer, de les gérer et de les qualifier en vue de
campagnes de marketing ultérieures.
 Critères de Satisfaction :
 Importation de Données Prospect : Les utilisateurs doivent pouvoir importer des
données prospect depuis des fichiers aux formats variés, tels qu'Adhoc, Iqualif, Phone
Extractor, etc.
 Nettoyage et Validation Automatiques : Le système doit être capable de nettoyer et
de valider automatiquement les données prospect pour éliminer les doublons, corriger
les incohérences et garantir l'intégrité des données.
 Identification des "Numéros à Ne Pas Appeler" : Le système doit permettre la
gestion et l'identification des "numéros à ne pas appeler" conformément aux
réglementations en vigueur.
 Identification du Type de Numéro et du Fournisseur de Services : Les utilisateurs
doivent pouvoir identifier le type de numéro de téléphone (fixe, mobile, etc.) ainsi que
le fournisseur de services pour une segmentation plus précise des prospects.
 Géolocalisation des Prospects : Le système doit utiliser l'API Google Maps
Geocoding pour géolocaliser les prospects et aider les utilisateurs à cibler des zones
géographiques spécifiques pour leurs campagnes.
 Recyclage Automatique des Prospects : Les prospects inactifs ou non convertis
doivent être automatiquement recyclés pour de futures campagnes, en optimisant ainsi
l'utilisation des données.
 Recherche Avancée de Prospects : Les utilisateurs doivent avoir la possibilité
d'effectuer des recherches avancées dans la base de données des prospects en fonction
de divers critères, tels que la localisation, le statut, etc.

ACHREF BARHOUMI 9
 Ce besoin fonctionnel vise à améliorer la gestion des prospects, à optimiser les données
disponibles,
et à faciliter le ciblage efficace pour les campagnes de marketing du centre d'appels.

4. Besoins non fonctionnels

Un besoin non fonctionnel se réfère à une exigence spécifique concernant les

caractéristiques du système,

y compris les contraintes relatives à son environnement et à sa mise en œuvre, les

performances requises, les dépendances à des plateformes particulières, la facilité de
maintenance, l'extensibilité et la fiabilité.

Contrairement aux besoins fonctionnels qui se concentrent sur ce que le système doit faire
pour les utilisateurs, les besoins non fonctionnels décrivent plutôt les conditions essentielles
pour garantir la qualité et le bon fonctionnement du système, et ils sont souvent considérés
comme des contraintes incontournables plutôt que des fonctionnalités directes pour les
utilisateurs :

Temps de Réponse : Le système doit répondre aux requêtes des utilisateurs dans un
délai maximal de 2 secondes, même lorsqu'il y a une charge élevée.

Optimisation des Requêtes : Les requêtes SQL doivent être optimisées pour
minimiser la charge sur la base de données et réduire les temps de réponse.

Disponibilité : Le système doit être disponible 24 heures sur 24, 7 jours sur 7, avec
un temps d'arrêt planifié minimal pour la maintenance.

Sécurité des Données : Les données doivent être protégées en transit et au repos
pour assurer la confidentialité et l'intégrité des informations.

Évolutivité : Le système doit être évolutif pour prendre en charge de nouvelles

fonctionnalités et s'adapter aux évolutions technologiques.

Conformité aux Règlements : Le système doit être en conformité avec les

réglementations de protection des données, Notamment les lois de l'Union
européenne telles que le RGPD (Règlement général sur la protection des données).

ACHREF BARHOUMI 10
 Ce besoin non fonctionnel garantit que le système CallCenter ERP sera performant, évolutif,

sécurisé et disponible pour répondre aux besoins des utilisateurs, même en cas de charges
de travail importantes.

5. Diagramme de cas d’utilisation général

Le diagramme de cas d’utilisation est un moyen de communiquer avec les utilisateurs

et d’autres parties prenantes ce que le système est destiné à faire. Il montre
l’interaction entre le système et lesentités externes au système. Il est représenté par
une ellipse contenant le nom du cas d’utilisation etoptionnellement un stéréotype au-
dessus du nom.

Figure 3: diagramme de cas d'utilisation général

6. Pilotage du projet avec Scrum

6.1. Présentation de la méthode Scrum

Le Scrum est considéré comme un cadre ou « Framework » de gestion de projet
Agile, il décrit un ensemble de réunions, d’outils et de rôles qui interagissent de
concert pour aider les équipes à structurer leur travail et à le gérer.

Il existe des événements Scrum qui sont décrits comme des boîtes de temps

ACHREF BARHOUMI 11
(timeboxes). Ilsservent à organiser le travail de l’équipe et cadrer le temps
passé en réunion :

 Planification de sprint (Sprint planning) : La durée maximale de cette

réunion est de 8 heures pour des sprints de 4 semaines. Au cours de laquelle
tout l’équipe du Scrum à savoirle Product Owner, l’équipe de développement
et le Scrum master si nécessaire, pour répondre à trois principales questions
qui consistent d’identifier l’objectif spécifique du sprint, les éléments
prioritaires du Product Backlog qui peuvent être convertis en unincrément
potentiellement livrable au cours du sprint et la façon de convertir ces
éléments sélectionnés en un incrément potentiellement utilisable à la fin du
sprint.
 Mêlée quotidienne (Daily Scrum) : Comme son nom l’indique, elle a lieu
tous les jours. Cette réunion a une durée maximale de 15 minutes. Elle permet
à l’équipe de développementde se synchroniser, de mesurer son avancement
au quotidien et d’ajuster son plan d’action en conséquence.
 Revue de sprint (Sprint Review) : Elle se déroule à la fin du sprint, elle
consiste à inspecterl’incrément et adapter le Product Backlog si nécessaire. Sa
durée maximale est de 4 heures pour un sprint de 4 semaines. Le Product
Owner y invite les parties prenantes clefs. L’intention est de recueillir auprès
d’eux des feedbacks et renforcer la collaboration.
 Rétrospective de sprint (Sprint Retrospective) : Lors de cette réunion qui
a lieu entre la revue de sprint et la planification du suivant, l’équipe Scrum
s’inspecte elle-même afin de tirer les leçons de l’expérience acquise sur le
sprint écoulé pour les mettre au profit du sprintsuivant, à travers l’élaboration
d’un plan d’actions d’amélioration.

ACHREF BARHOUMI 12
 Figure 4: méthodologie scrum
6.2. Équipe de travail
Les équipes Scrum sont autoorganisées et pluridisciplinaires. Elles choisissent la
meilleure façon d’accomplir leur travail, au lieu d’être dirigées par des personnes
externes à l’équipe, ce qui favorisela flexibilité, la créativité et la productivité. Ces
derniers sont principalement composés de :

 Product Owner : C’est généralement un expert du domaine métier. Il porte

la vision du produit à réaliser et travaille en interaction avec l’équipe de
développement pour assurer la bonne exécution du projet. Il est ainsi en étroite
relation avec l’équipe de marketing et les clients pour assurer que le
développement du produit est en harmonie avec l’utilisateur et ses besoins.
 Scrum master : C’est le chef de projet. Il s’assure que le principe Scrum se
déroule commeil se doit, il fixe les rôles, les timings et les objectifs. Il a donc
un rôle de coach à la fois auprès du Product Owner et auprès de l’équipe de
développement. Il doit donc faire preuvede pédagogie.
 L’équipe de développement : Elle est pluridisciplinaire qui est chargée de
transformer les besoins exprimés par le Product Owner en fonctionnalités
utilisables. Cela inclut la planification, conception, développement (codage),
tests et les paramétrages.

Rôle Membre

ACHREF BARHOUMI 13
 Product Owner Mr. Maher Amara

Scrum Master Mr. Kamel Garrouch

L’équipe de développement Achref Barhoumi

Tableau 1: membres de l'équipe scrum

6.3. Backlog du produit

Le backlog du produit est l’artefact le plus important de Scrum. Il représente l’ensemble

des caractéristiques fonctionnelles ou techniques qui constituent le produit souhaité. Les
caractéristiques fonctionnelles sont appelées des histoires utilisateur (User Story) et les
caractéristiques techniques sont appelées des histoires techniques (Technical Story).

Id Fonctionnalité Id User story Estimation

US
1 Authentification 1.1 En tant qu’utilisateur non authentifié, 5
jepeux m’authentifier afin d’accéder à
mon
interface.
2 Gestion des 2.1 En tant qu’administrateur, je peux 8
activer
utilisateurs ou désactiver un compte utilisateur afin

dese connecter.

3 Gestion 3.1 En tant que système, je peux créer le 5

des dossiers
dossier automatique lors de création du
automatiques compte client.

4 Gestion des 4.1 En tant que système, je peux créer le 5

contrats contrat automatique lors de la création
automatiques du
compte client.
5 Gestion des 5.1 En tant qu’administrateur, je 13
peux

ACHREF BARHOUMI 14
 ajouter une demande de service,
demandes de
service consulter,modifier et supprimer ses

attributs.

5.2 En tant qu’administrateur, je 14

peuxconsulter la liste des demandes
de service
ajoutées par le client.
5.3 En tant qu’administrateur, je peux 16
affecterun technicien à une demande
de service
créée par le client.

5.4 En tant qu’administrateur je 21

peuxsupprimer ou consulter les
fiches affectées
à une ticket.
5.5 En tant qu’administrateur je peux ajouter 7
une ticket à une demande de service.
5.6 En tant que client, je peux ajouter, 9
modifier, consulter et supprimer
une
demande de service.
5.7 En tant que client, je peux valider mes 8
demandes de service.
5.8 En tant que technicien, je peux consulter 13
les demandes de service qui m’ont été
confiées.
5.9 En tant que technicien, je peux ajouter 7
un ticket à mes demandes de service et
le

ACHREF BARHOUMI 15
 valider.

5.10 En tant que technicien, je peux supprimer 7

ou consulter les fiches affectées à une
ticket.
6 Gestion des 6.1 En tant que commercial, je peux 3
«Part Order» ajouterdes fichiers à chaque phase et
attribuer à
chaque employé la tâche correspondante.
7 Dashboard 7.1 En tant qu’administrateur, je 5
peux
consulter les nombres des

utilisateursactifs et inactifs.

7.2 En tant qu’administrateur, je peux 8

consulter les nombres des demandes de
service en cours, validées, fermées, en
retard et non traitées.

7.3 En tant qu’administrateur, je peux 9

consulter les statistiques d’un dossier de
client (nombre de demande de service
totale, nombre de demandes de service
créés par le client et d’autre statistique
corresponde à ce dossier de client).
7.4 En tant que client, je peux voir le nombre 7
de mes demandes de serviceen cours,
terminées, validées, expirées et
non-traitées.
7.5 En tant que technicien, je peux voir le 13
nombre de mes demandes de service

ACHREF BARHOUMI 16
 encours, terminées, validées et expirées.

8 Gestion des 8.1 En tant que système, je peux changer 10

«Follow ups» l’état d’une demande de service qui
dépasse la durée du SLA de contrat à
"Expiré"pour la première fois et lancer
un rappel
automatique.
8.2 En tant qu’administrateur, je 8
peuxconsulter et créer un "Follow-
up" pour
effectuer un rappel.
9 Recherche 9.1 En tant qu’un utilisateur, je peux faire la 5
recherche dans tous les tableaux.

Tableau 2 backlog du produit

6.4. Découpage du projet avec SCRUM

Comme nous l’avons déjà mentionné, nous choisirons la méthodologie agile

SCRUM,car elle permet un développement rapide et favorise la réutilisation des
fonctionnalités de manière indépendante de la plateforme.
Avant d’entrer dans les détails, il est essentiel de souligner l’importance d’une

planification et d’une structuration du projet, qui sont des piliers des méthodes
agiles.La figure ci-dessus présente la planification des sprints de notre projet :

ACHREF BARHOUMI 17
 Figure 5: planification des sprint

Diagramme de Gantt
7. Conclusion

Figure 6: diagramme de gantt

Durant ce chapitre, nous avons spécifié en premier lieu les besoins fonctionnels et non
fonctionnelset présenté le diagramme de cas d’utilisations générale du projet. Ensuite,
nous avons détaillé la première étape de la méthodologie adoptée à savoir le pilotage
du projet avec Scrum tout en élaborant le backlog du produit ainsi que la planification
des sprints.

ACHREF BARHOUMI 18
Dans le chapitre suivant, nous allons mettre en évidence l’environnement et l’architecture
du projet.

ACHREF BARHOUMI 19
1. Introduction

Après avoir spécifié les besoin fonctionnels et non fonctionnels ainsi que la
méthodologie de pilotage choisie pour la réalisation du projet. Il nous reste que
d’entamer ce chapitre afin de décrire l’architecture de l’application, le choix des
technologies, l’environnement de travail et les outils utilisés qui nous mèneront vers
une application complète qui satisfait les besoins de l’utilisateur.

2. Choix technologique

Le choix des technologies est l’une des étapes les plus importantes du développement
d’un produitréussi. La création d’un produit ne se limite pas à la conception d’une
interface utilisateur agréableet d’une interface utilisateur pratique, il s’agit également
de concevoir un produit stable, sécurisé etfacile à entretenir.

OpenProject : Nous avons choisi OpenProject comme outil de gestion de projet.

UML : Nous avons choisi UML comme langage de modélisation pour nos diagrammes.

GitHub : Nous avons choisi GitHub comme plateforme de gestion de code source.

VS code : Nous avons choisi VS Code comme notre environnement de développement

intégré (IDE) et éditeur de code.

Next.js : Nous avons utilisé Next.js comme Framework pour le

développement Front-End en raison de sa capacité à offrir des performances
améliorées et une réactivité accrue grâce à son approche basée sur les
composants.
Django Rest Framework : Nous avons utilisé Django Rest Framework pour
les API, afin de garantir une communication fluide entre le Front-End et le
backend.

ACHREF BARHOUMI 20
GitHub : Nous avons utilisé GitHub pour la gestion du code source, facilitant ainsi la
collaboration au sein de l'équipe, permettant un développement continu et une gestion efficace
des versions.
JavaScript : Nous avons utilisé JavaScript pour la logique de programmation, assurantainsi le
bon fonctionnement des fonctionnalités Front-End.
Google Chrome : Nous avons utilisé Google Chrome pour tester l'interface utilisateur,
garantissant sa compatibilité et sa convivialité sur différentes plates-formes.
Front-End : Le Front-End, également appelé "interface utilisateur" ou "partie visible", désigne
la partie d'une application ou d'un site web avec laquelle les utilisateurs interagissent
directement. Il englobe la conception graphique, l'ergonomie, et la fonctionnalité visuelle de
l'application,assurant ainsi une expérience utilisateur optimale.
API : Une API, ou Interface de Programmation Applicative, est un ensemble des règles et de
protocoles qui permettent à différents logiciels et systèmes informatiques de communiquer
entre eux. Elle définit les méthodes et les données auxquelles les développeurs peuvent
accéderpour interagir avec un service ou une application particulière. Les API jouent un rôle
essentiel dans l'intégration de systèmes, la création d'applications interconnectées et la
facilitation de l'échange d'informations entre différentes plates-formes logicielles. En
simplifiant la manière dont les logiciels interagissent, les API favorisent l'efficacité du
développement logiciel et l'interopérabilité des systèmes.
DevOps : DevOps (Fig.8) est une approche de développement logiciel qui favorise la
collaboration étroite entre les équipes de développement (Dev) et d'exploitation (Ops).
L'objectif principal de DevOps est d'automatiser et d'optimiser le processus de déploiement
logiciel, de manière à accélérer le cycle de développement, améliorer la qualité du code, et
garantir une livraison continue et fiable des logiciels. Cette approche repose sur
l'automatisation, l'intégrationcontinue, le déploiement continu, la surveillance et la rétroaction
continue, tout en encourageant la collaboration entre les équipes pour une gestion plus efficace

ACHREF BARHOUMI 21
de l'infrastructureet des applications.

=> Les avantages de pratiques DevOps :

La stratégie DevOps apporte plusieurs avantages:

Rapidité : En adoptant la méthodologie DevOps, l'entreprise élimine tous les problèmes

Figure 7: logo DevOps

de retard au niveau de sa production, de retards dans la livraison des produits et de

livraison de produits qui ne correspondent pas aux demandes des clients. L'approche
DevOps rationalise les processus, automatise la plupart de ses activités et livrera les
produits beaucoupplus rapidement.
Économie : En mettant en œuvre la stratégie DevOps, les entreprises peuvent déployer
de nouveaux processus, systèmes et applications beaucoup plus rapidement. Le
déploiement de DevOps rendra les opérations commerciales plus efficaces. Avec le
temps de cycle réduit, le coût de création du produit est également réduit.
Sécurité : L'avancement rapide avec l'approche DevOps ne compromet pas la sécurité,
grâce à des politiques de conformité automatisées, des contrôles plus rigoureux et des
techniques de gestion de configuration. Par exemple, avec l'infrastructure en tant que
code et la politique en tant que code, nous pouvons définir et suivre la conformité à
n'importe quelle échelle. Fiabilité : DevOps contribue à garantir la qualité des mises à
jour de l'application et à modifier l'infrastructure pour livrer en toute confiance des
produits à un rythme accéléré tout en continuant à offrir une expérience positive aux
utilisateurs finaux.
Scalabilité : L'automatisation et la cohérence nous aident à gérer efficacement des
systèmes complexes ou en évolution, de manière moins risquée.

ACHREF BARHOUMI 22
 Figure 8: Scalabilité
Containerisation : La conteneurisation (Fig.10) est une technique de virtualisation légère qui
permet d'emballer une application, ainsi que ses dépendances et ses bibliothèques, dans un
conteneur isolé et auto-suffisant. Ces conteneurs sont conçus pour fonctionner de manière
cohérente et fiable, quel que soit l'environnement de déploiement, que ce soit sur un ordinateur
local, un serveur distant ou dans le cloud. Les conteneurs offrent plusieurs avantages,
notamment la portabilité, l'efficacité desressources, la rapidité de déploiement et la facilité de
gestion. Ils sont devenus essentiels dans le domaine de la gestion de l'infrastructure et du
déploiement d'applications, en permettant aux développeurs de créer des environnements de
développement cohérents et en simplifiant le déploiement et la mise à l'échelle des applications.
Les solutions de containerisation les plus populaires incluent Docker et Kubernetes.

ACHREF BARHOUMI 23
 Figure 9: La conteneurisation

Pipeline CI/CD : Une pipeline CI/CD (Fig.11) est un ensemble automatisé de processus et
d'étapes conçues pour la Continuité de l'Intégration (CI) et le Déploiement Continu (CD) des
applications logicielles. Elle vise à automatiser la construction, les tests, l'intégration, la
livraison, et le déploiement d'une application, garantissant ainsi une livraison rapide, cohérente
et de haute qualité des logiciels.

La CI se concentre sur l'intégration fréquente du code source dans un référentiel

centralisé, suivi de la compilation, des tests automatisés et de la génération de
rapports sur la qualité du code. L'objectif est de détecter rapidement les erreurs et les
conflits de code.

La CD étend la CI en automatisant le déploiement des applications, de manière à

ce qu'ellessoient prêtes à être mises en production à tout moment. Cela inclut des
tests supplémentaires, comme les tests d'acceptation automatisés, et la possibilité de
déployer automatiquement les nouvelles versions lorsque les tests sont réussis.

En utilisant une pipeline CI/CD, les équipes de développement peuvent garantir

une meilleure qualité du code, une mise en production plus rapide, une réduction des
erreurs humaines et une plus grande agilité dans le développement et le déploiement
d'applications.

ACHREF BARHOUMI 24
 Figure 10: Une pipeline CI/CD

3. Environnement Matériel

Notre projet a été réalisé sur un ordinateur portable dont la configuration est la suivante :

Ordinateur Portable MSI GF63 Thin 11SC

Système Windows 10 (64 bits)

d’exploitation

Processeur Intel® Core™ i7-11800H CPU@ 2.30

GHz

Mémoire vive 24 Go

Disque dur 512 Go

Tableau 3: : environnement matérie

ACHREF BARHOUMI 25
4. Diagramme de déploiement

Le diagramme de déploiement modélise l’architecture physique du système. Il affiche

les relationsentre les composants logiciels et matériels du système, d’une part, et la
distribution physique du traitement, d’autre part.

Figure 11: diagramme de déploiement

Description :

Ce diagramme de déploiement représente une architecture basée sur Docker

ACHREF BARHOUMI 26
 Swarm, conçue pour le déploiement d'applications conteneurisées. L'ensemble du
système estorganisé en plusieurs nœuds, notamment un nœud de gestion (Manager
Node) et trois nœuds de travail (Worker Nodes). Chaque nœud de travail héberge
plusieurs conteneurs, notammentdes applications (App), des instances Redis (Redis),
des bases de données MySQL (MySQL),et des serveurs Nginx (Nginx). Le nœud de
gestion assure la coordination et la gestion des conteneurs sur les nœuds de travail.
Cette architecture offre une mise en cluster efficace et uneextensibilité pour garantir la
disponibilité et la scalabilité des applications déployées à l'aide deDocker Swarm.

5. Diagramme de déploiement docker

ACHREF BARHOUMI 27
 Figure 12: Le Diagramme De Deployment Du Docker Swarm

Description :

Ce diagramme de déploiement représente une architecture basée sur Docker

Swarm, conçue pour le déploiement d'applications conteneurisées. L'ensemble du
système est organisé en plusieurs nœuds, notamment un nœud de gestion (Manager
Node) et trois nœuds de travail (Worker Nodes). Chaque nœud de travail héberge

ACHREF BARHOUMI 28
 plusieurs conteneurs, notammentdes applications (App), des instances Redis (Redis), des
bases de données MySQL (MySQL),et des serveurs Nginx (Nginx). Le nœud de gestion
assure la coordination et la gestion des conteneurs sur les nœuds de travail. Cette
architecture offre une mise en cluster efficace et une extensibilité pour garantir la
disponibilité et la scalabilité des applications déployées à l'aide deDocker Swarm.

6. Diagramme de séquence de pipeline

Figure 13: Diagramme de séquence de pipeline

Description :

Ce diagramme représente le pipeline Jenkins utilisé dans le processus de

développement logiciel. Le processus démarre par la récupération du code source depuis
un système de gestion de code source (SCM). Ensuite, des tests unitaires sont exécutés,
suivis d'une analyse avec SonarQube pour évaluer la qualité du code. Si la porte de

ACHREF BARHOUMI 29
 qualité échoue, une notification par e-mail est envoyée pour informer les développeurs.
En cas de succès, le code est utilisé pour construire une image Docker, qui est ensuite
poussée vers DockerHub. Enfin, l'application est déployée sur un cluster Swarm, et une
autre notification par e-mail est envoyée pour signaler la réussite du déploiement. Ce
pipeline assure un processus de développement fluide et garantit la qualité du code tout
au long du processus.

7. Conclusion

Dans ce chapitre nous avons énoncé en premier lieu, l’architecture de notre projet
ainsi que les technologies choisies. Ensuite, nous avons présenté l’environnement de
travail à savoir les environnements matériels et logiciels. Dans le chapitre qui suit,
nous traiterons le premier sprint.

ACHREF BARHOUMI 30
1. Introduction

Après avoir spécifié l’environnement logiciel et matériel dans le chapitre précédent,

il nous reste que d’entamer ce chapitre afin de décrire les différentes fonctionnalités
et les principaux objectifsde notre futur système.

Ce chapitre contiendra la première partie mentionnée dans le backlog du sprint.

Nous ne passons par une partie d’analyse, une phase de conception et une phase de
réalisations où nous présentons quelques interfaces réalisées au cours de chaque
User Story.

2. Backlog sprint 1

Dans la méthodologie Scrum, tous les sprints ont une durée constante et ne se
chevauchent jamais, c’est-à-dire qu’un sprint ne peut pas démarrer tant que le
précédent n’est pas encore terminé.
Avant de se lancer dans un sprint, l’équipe Scrum doit obligatoirement définir le but
de ce dernier.Ce but doit être défini en termes métiers et non pas en termes techniques
pour qu’il soit compréhensible par les membres en dehors de l’équipe. Il s’agit de
répondre à une question fondamentale « pourquoi faisons-nous ce sprint ? ». Une fois
que le but de notre sprint soit défini, on choisit les histoires qui seront incluses dans
le backlog du sprint.

Authentification :

ACHREF BARHOUMI 31
Id User story Id User Tâche
story

1 1.1 Analyse de cas

En tant qu'utilisateur, je souhaite d’authentification détaillé.
pouvoir saisir mon nom
d'utilisateur et mon mot de passe
afin de me connecter à
l'application.
1.2 créer la classe « utilisateur ».
1.3 créer les composants dans front-end
pour la classe « Authentification ».

1.4 créer interface « Authentication ».

1.5 créer la partie traitement de la page
« Inscription ».

1.6 Tester les Méthodes « inscription et

login ».

2 2.1
En tant qu'utilisateur, je souhaite
voir un message d'erreur si mes
informations d'identification sont Création du formulaire de connexion
incorrectes, afin de savoir que la
connexion a échoué.
2.2 Validation des données côté client

2.3 Authentification côté serveur

2.4 Gestion des erreurs d'authentification

3 En tant qu'utilisateur, je souhaite 3.1 Génération et envoi d'un lien de

avoir la possibilité de réinitialisation

réinitialiser mon mot de passe si

je l'oubli, afin de récupérer
3.2 Page de réinitialisation du mot de
l'accès à mon compte. passe

ACHREF BARHOUMI 32
 3.3 Validation du lien de réinitialisation

3.4 Mise à jour du mot de passe

4 En tant qu'administrateur, je 4.1 Création de comptes utilisateur

souhaite avoir la capacité de
gérer les comptes d'utilisateur,
y compris la création, la
4.2 Modification des comptes utilisateur
modification et la suppression
de comptes, afin de gérer 4.3 Suppression de comptes utilisateur

l'accès des utilisateurs à

l'application. 4.4 Gestion des autorisations

Tableau 4: Authentification

Réinitialisation du Mot de Passe :

1 En tant qu'utilisateur, je souhaite 1.1 Création du formulaire de
réinitialisation de mot de passe
pouvoir demander une
réinitialisation de mon mot de
passe en fournissant mon
adresse e-mail, afin de récupérer
1.2 Validation de l'adresse e-mail
l'accès à mon compte.
1.3 Génération du jeton de réinitialisation

1.4 Envoi de l'e-mail de réinitialisation

1.5 Gestion des e-mails non reçus

ACHREF BARHOUMI 33
 1.6 Page de réinitialisation du mot de
passe et Validation du jeton de
réinitialisation
2 2.1 Génération du jeton de réinitialisation
En tant qu'utilisateur, je souhaite
recevoir un lien de réinitialisation
de mot de passe par e-mail, afin
de créer un nouveau mot de passe.

2.2 Envoi de l'e-mail de réinitialisation

2.3 Gestion des e-mails non reçus

2.4 Expiration du lien de réinitialisation

3 En tant qu'utilisateur, je souhaite 3.1 Page de réinitialisation du mot de

passe
avoir la possibilité de
réinitialiser mon mot de passe si
je l'oubli, afin de récupérer
3.2 Validation du jeton de réinitialisation
l'accès à mon compte.

Tableau 5:Réinitialisation du Mot de Passe

Système d'Autorisation :

1 En tant qu'administrateur, je 1.1 Conception des rôles et des

permissions
souhaite pouvoir définir et gérer
les rôles et les permissions des
utilisateurs de manière
granulaire, afin de garantir que
1.2 Interface d'administration des rôles
chaque utilisateur ait un accès
1.3 Création des rôles par défaut
approprié aux fonctionnalités et
aux données de l'application.
1.4 Attribution des rôles aux utilisateurs

ACHREF BARHOUMI 34
 1.5 Interface de gestion des utilisateurs

1.6 Validation des permissions

2.2 Journalisation des actions des

administrateurs
2.3 Tests unitaires et de régression

2.4 Documentation de l'administration des

rôles et des permissions
3.2 Sécurité

Tableau 6:Backlog Du Sprint 1

3. Planification de Sprint

Au cœur de ce premier sprint, nous nous plongerons dans l'exploration détaillée des
besoins, tant fonctionnels que non fonctionnels, de notre projet. Nous entreprendrons une
analyse approfondie des fonctionnalités essentielles que notre solution doit offrir, tout en
examinant attentivement les aspects de performance, de sécurité et d'évolutivité.
Parallèlement à cette étude, nous concentrerons nos efforts sur l'établissement de
diagrammes de conception préliminaires, illustrant la structure et les interrelations des
composants clés de notre solution.Ces diagrammes serviront de boussole pour la suite de
notre travail, guidant notre équipe dans

la création d'une solution qui répondra de manière optimale aux besoins de notre projet,
touten assurant la cohérence et la clarté de notre vision.

4. Objectif de Sprint

L'objectif de ce sprint initial est d'explorer en profondeur les besoins fonctionnels et non
fonctionnels du projet, tout en établissant des diagrammes de conception préliminaires pour guider

ACHREF BARHOUMI 35
le développement ultérieur de la socrm

5. Diagramme de cas d’utilisation

Figure 14:Le Diagramme De Case d'utilisation du système d'authentification

Description :
Ce diagramme de cas d'utilisation illustre les interactions entre l'acteur "Utilisateur" et le
système d'authentification. L'acteur "User" initie deux actions principales : "Authenticate"et
"Forgot Password." Lorsque l'utilisateur sélectionne "Authenticate," le système passe d'abord
par "Validate Form" pour vérifier les identifiants saisis. Si les données sont valides,
l'utilisateur accède au tableau de bord ("Access Dashboard") ; sinon, il reçoit un message
d'erreur ("Return Credentials Error"). En revanche, en choisissant "Forgot Password,"
l'utilisateur est dirigé vers l'étape "Enter Email," où il fournit son adresse e-mail. Ensuite, le
système passe à "Send Reset Email," déclenchant ainsi le processus d'envoi d'un e-mail de
réinitialisation du mot de passe. Ce diagramme de cas d'utilisation offre une représentation
visuelle claire des principales interactions dans les processus d'authentification de l'utilisateur
et de réinitialisation du mot de passe.

6. Diagramme de classe sprint1

ACHREF BARHOUMI 36
 Figure 15: Diagramme de classe sprint1

7. Conclusion

Ce premier sprint a marqué un point de départ crucial dans notre initiative de développement. En
explorant en profondeur les besoins fonctionnels et non fonctionnels de notre projet, nous avons
jeté les bases d'une solution solide. La conception préliminaire de notresolution, illustrée à travers
des diagrammes, nous guide dans notre parcours vers le succès. Cette phase initiale nous a permis
de comprendre l'essence de notre projet et de définir une vision claire pour la suite de notre travail.

ACHREF BARHOUMI 37
1. Introduction

Dans ce deuxième sprint, notre objectif principal était d'améliorer le Front-End de

l'application en utilisant le Framework moderne Next.js, remplaçant ainsi le JavaScript vanilla
précédemment utilisé. Nous avons également travaillé sur le développement de nouvelles
fonctionnalités essentielles pour l'expérience utilisateur.

2. Backlog sprint 2
Id User story Id User Tâche
story

1 1.1 Création du formulaire d'ajout de

En tant qu'utilisateur, je souhaite prospect
pouvoir ajouter de nouveaux
prospects à la base de données, y
compris leurs informations de
contact, afin de les suivre.
1.2 Validation des données du formulaire
1.3 Accès à la base de données

1.4 Enregistrement des données

1.5 Modification et suppression des
prospects

1.6 Journalisation des actions

ACHREF BARHOUMI 38
2 En tant qu'utilisateur, je souhaite 2.1 Conception de l'interface de recherche
pouvoir rechercher et filtrer les et de filtrage
prospects en fonction de
différents critères, tels que le
statut, la source, etc., afin de les
organiser efficacement.
3 3.1 Identification des critères de filtrage

3.2 Développement des fonctionnalités de

recherche et de filtrage

1 En tant qu'utilisateur, je souhaite 1.1 Traitement des fichiers

pouvoir importer et exporter des
listes de prospects au format
CSV ou Excel, afin de faciliter
la gestion des données.
1.2 Validation des données
1.3 Mapping des colonnes

1.4 Importation des données

1.5 Exportation des données

1.6 Tests unitaires et de régression

2.2 Documentation utilisateur

2.3 Optimisation des performances

2.4 Gestion des erreurs

3.2 Sécurité

ACHREF BARHOUMI 39
1 En tant qu'utilisateur, je souhaite 1.1 Conception de l'interface utilisateur
avoir la possibilité de marquer
les prospects comme "Ne pas
appeler" pour respecter les
réglementations.

1.2 Ajout d'un champ "Ne pas appeler"

1.3 Affichage de l'état "Ne pas appeler"

1.4 Possibilité de marquage

1.5 Sécurité et conformité aux
réglementations

1 En tant qu'utilisateur, je souhaite 1.1 Base de données des produits

créer et gérer des commandes
clients, y compris la saisie des
produits, la gestion des stocks,
etc.

1.2 Sélection des produits

1.3 Gestion des quantités

1.4 Calcul du total

1.5 Validation de la commande

1.6
Création de la commande , Mise à jour
des stocks , Historique des
commandes, Gestion des taxes et des
frais de livraison, Tests unitaires et de
régression, Documentation utilisateur

ACHREF BARHOUMI 40
 2 En tant qu'utilisateur, je souhaite 2.1
générer des factures pour les
Modèle de facture , Sélection de la
commandes clients.
commande, Remplissage automatique
des détails, Possibilité de
personnalisation, Stockage des
factures, Envoi des factures,
Documentation utilisateur

Tableau 7: Backlog sprint 2

3. Planification de sprint

Durant ce deuxième sprint, notre objectif principal est de moderniser le Front-End de

l'application en adoptant le Framework Next.js. Pour ce faire, nous entamerons la transition de
JavaScript vanilla vers Next.js, ce qui permettra d'améliorer considérablement les performances et
la réactivité de l'interface utilisateur. De plus, nous concentrerons nos efforts sur le développement
de fonctionnalités essentielles telles que l'inscription, la connexion, la déconnexion, la
réinitialisation de mot de passe, ainsi que la validation des formulaires de la page de connexion.
Cette phase sera marquée par une collaboration étroite au sein de l'équipe pour garantir le succès
de notre démarche.

4. Objectif de Sprint

L'objectif de ce sprint est d’optimiser le Front-End avec Next.js et développer des

fonctionnalités essentielles.

5. Réalisation
ACHREF BARHOUMI 41
 La réalisation de ce deuxième sprint, a constitué une étape cruciale dans l'évolution de notre
projet. L'objectif principal était d'améliorer considérablement le Front-End de l'application en
utilisant le Framework moderne Next.js. Cette transition vers Next.js était motivée par la volonté
d'offrir aux utilisateurs une expérience optimale en termes de performances et de réactivité.
L'équipe a travaillé de manière méthodique et collaborative pourmettre en œuvre ce changement
technologique.
L'implémentation de Next.js s'est avérée être un succès majeur, car elle a considérablement
amélioré les performances de l'application. Les utilisateurs ont désormais accès à une interface
fluide et réactive qui répond rapidement à leurs actions, ce qui contribue grandement à leur
satisfaction et à leur engagement. La transition vers Next.js a également ouvert la porte à une

évolution plus fluide de l'application, permettant une intégration plus efficace de nouvelles
fonctionnalités à l'avenir.
De plus, au cours de ce sprint, l'équipe a développé plusieurs fonctionnalités Front-End
essentielles. Cela comprenait la mise en place des fonctionnalités d'inscription, de connexion, de
déconnexion, de réinitialisation de mot de passe, ainsi que la validation des formulaires de la page
de connexion. Chacune de ces fonctionnalités a été soigneusement conçue pour répondre aux
besoins des utilisateurs et améliorer leur expérience globale.

ACHREF BARHOUMI 42
 Ce sprint a également été marqué par une collaboration étroite entre les membres de l'équipe,
favorisant un partage continu d'idées et de solutions pour garantir le succès de cette phase du projet.
La communication transparente et l'engagement collectif ont été les piliers denotre réussite.

Figure 16: Le Code Base de l'Intégration de NextJS

ACHREF BARHOUMI 43
 Figure 17:Dashboard de Login

Figure 18: Dashboard Principale (PWA)

ACHREF BARHOUMI 44
Figure 19: Dashboard Principale (WEB)

ACHREF BARHOUMI 45
 Figure 20:Contrôle De Saisie de Create Account interface

Figure 21:Contrôle De Saisie de Mot De Passe Oublié Interface

6. Conclusion
Le déroulement de ce sprint a été un succès, avec des progrès significatifs réalisés dans
l'amélioration du Front-End et le développement de nouvelles fonctionnalités essentielles. Nous
nous tournons désormais vers le prochain sprint, où nous allons empaqueter cette application pour
la préparer au déploiement en production. Les améliorations apportées au Front-End renforceront
l'expérience utilisateur globale, offrant ainsi une interface plus fluide et réactive, tout en continuant
à garantir la qualité et la convivialité de l'application.

ACHREF BARHOUMI 46
1. Introduction

Après avoir terminé les différentes fonctionnalités et mises à jour côté interface utilisateur,
notre application est désormais prête à être emballée et livrée. C'est pourquoi, au cours de ce
sprint, notre objectif principal a été d'isoler notre application dans son propre environnement, la
rendant ainsi plus légère et compatible avec n'importe quel appareil et système d'exploitation.

2. Planification de sprint

Au cours de ce sprint, notre objectif principal consiste à dockeriser les différentes entités et
services de notre application. Cela implique la création de Dockerfiles pour l'application, Redis,
Nginx et MySQL, ainsi que la configuration d'un fichier docker-compose.yml pour simplifier le
déploiement. Des scripts shell seront développés pour gérer l'initialisation et les migrations,tandis
que des tests seront effectués pour garantir le bon fonctionnement de l'application dans
l'environnement Dockerisé. L'optimisation des conteneurs et la documentation complète du
processus de Dockerisation seront également incluses dans cette phase.

3. Objectif de sprint

L'objectif de ce sprint est de dockeriser l'ensemble des entités et services de l'application pour
faciliter le déploiement et améliorer la compatibilité multiplateforme.

ACHREF BARHOUMI 47
4. Choix technologiques

Docker : Nous avons utilisé Docker comme technologie de packaging.

Dockerfiles : Nous avons utilisé Dockerfiles pour créer des images Docker afind'exécuter
nos conteneurs.
Docker-compose : Nous avons utilisé Docker-compose pour construire et exécuter nos
conteneurs afin de tester leur fonctionnalité.
Shell-scripts : Nous avons utilisé des scripts shell pour effectuer certainesinitialisations
de conteneurs et des migrations de bases de données.

5. Réalisation

Au cours de cette phase cruciale, nous avons concrétisé notre objectif en dockerisant avec
succès toutes les composantes essentielles de notre application. Cela a aboutià la création de quatre
conteneurs distincts, à savoir MySQL, Redis, l'application elle-même et Nginx-proxy, chacun
d'entre eux étant soigneusement configuré pour fonctionner de manière harmonieuse. Pour
atteindre cet objectif, nous avons mis en place trois Dockerfiles distincts, un pour chaque
composant (Nginx, MySQL et l'application principale), garantissant ainsi uneisolation efficace et
une gestion optimale des dépendances.
Après avoir consolidé ces conteneurs individuels, nous les avons intégrés de manière
transparente en utilisant Docker-compose. Cette configuration a permis une gestion aisée de
l'ensemble de l'application, garantissant que chaque service fonctionne en tandem sans heurts. Nos

ACHREF BARHOUMI 48
tests rigoureux ont confirmé que l'ensemble de l'application fonctionnait sans aucun problème
majeur, ce qui témoigne de l'efficacité de notre approche de dockerisation.

ACHREF BARHOUMI 49
 De plus, nous avons pris conscience de
l'importance cruciale de la documentation. Par
conséquent, nous avons méthodiquement
documenté les aspects essentiels de la configuration
Docker, y compris les étapes de déploiement, les
commandes de lancement et les configurations
spécifiques à chaque conteneur. Cette
documentation constitue une précieuse ressource
pour notre équipe actuelle ainsi que pour les équipes
de développement futures, garantissant une
maintenance fluide et une compréhension
approfondie de notre environnementDockerisé.

Concernant les scripts shell, ils ont joué un rôle

clé dans notre processus de dockerisation.Le script
entrypoint.sh a été utilisé pour gérer les privilèges
élevés de la base de données, exécuter les
migrations, puis passer à des privilèges moins
élevés pour charger les données initiales, collecter
les fichiers statiques et lancer l'application avec
uwsgi. Quant au script test.sh, il a permis
d'automatiser les tests unitaires et de couverture en
installant Coverage, exécutant les tests et générant
des rapports pour évaluer la qualité du code de notre
application. Ces scripts ont considérablement
simplifié notre flux de travail et ont contribué à
l'efficacité globale de notre processus de
dockerisation.

ACHREF BARHOUMI 50
ACHREF BARHOUMI 51
 Figure 23: La Dockerization de l’application

Figure 22: Le Création Des Conteneurs Docker

ACHREF BARHOUMI 52
6. Conclusion

Le Sprint 3, axé sur le packaging de l’application, a été mené à bien avec succès. Nous avons atteint
notre objectif de dockeriser toutes les composantes essentielles de notre application, ce qui a abouti
à la création de quatre conteneurs bien configurés. De plus, une documentation approfondie a été
créée pour assurer une maintenance fluide et faciliter le développement futur. En regardant vers
l'avenir, notre prochain sprint se concentrera sur l'établissement d'un pipeline de
développement pour l'automatisation des flux de travail, améliorant ainsi davantage notre
processus de développement du projet CallCenter ERP.

ACHREF BARHOUMI 53
1. Introduction

Cette étape marque la conclusion de notre projet et revêt une importance capitale. Au coursde
ce dernier sprint, nous mettrons l'accent sur l'automatisation du processus de développement de
l'application, intégrant des pratiques de test et d'assurance qualité. Cette phase est essentiellepour
garantir une gestion efficace de notre projet, avec une attention particulière portée à
l'automatisation et l'optimisation de nos flux de travail.

2. Planification de Sprint

Au cœur de ce dernier sprint, nous nous consacrerons à l'automatisation totale du processusde

développement de l'application. Cela englobe l'automatisation des tests unitaires, lesassurances
de qualité, la gestion des phases de build, et de déploiement. De plus, nous mettronsen place un
système de notifications pour nos développeurs, assurant ainsi une communicationefficace et une
réactivité accrue au sein de l'équipe.

3. Objectif de sprint

Automatiser le processus de développement, incluant tests, qualité, build, déploiement et

notifications de l’équipe.

4. Réalisation

ACHREF BARHOUMI 54
 Notre pipeline Jenkins débute avec la première étape, où nous récupérons le code source le
plus récent depuis le dépôt (SCM - Gestion de Code Source), nous assurant ainsi de travailler avec
la version la plus à jour de notre code.

Dans la deuxième étape, nous réalisons une analyse complète du code à l'aide de SonarQube,
couvrant des aspects tels que la qualité du code, la sécurité et la maintenabilité, intégrée de manière
transparente dans notre flux de travail.

Passant à la troisième étape, nous évaluons les résultats de l'analyse du code par rapport à des
critères de qualité prédéfinis, garantissant que notre code respecte les critères de qualité spécifiés
avant de poursuivre.

Dans la quatrième étape, nous déclenchons la construction parallèle d'images Docker en

utilisant un fichier Docker Compose, assurant ainsi la cohérence et la fiabilité de notre application
conteneurisée.

Par la suite, dans la cinquième étape, nous envoyons de manière sécurisée l'image Dockervers
DockerHub, mettant en œuvre une gestion sécurisée des informations d'identification.
Dans la sixième étape, nous déployons notre application avec Docker Swarm, orchestrant et
adaptant efficacement notre application.

Enfin, dans la dernière étape, nous envoyons des notifications par courrier électronique aux
destinataires désignés, fournissant des informations essentielles sur l'état de la construction,
permettant une revue rapide et des actions lorsque nécessaire. Ces étapes forment collectivement
notre flux de travail automatisé, améliorant les processus de développement, de test et de
déploiement, tout en maintenant un haut niveau de qualité et de fiabilité du code.

ACHREF BARHOUMI 55
ACHREF BARHOUMI 56
Figure 24: Le Code de fichier Jenkinsfile du pipeline

ACHREF BARHOUMI 57
 Figure 25: Les Analyse du Code avec Sonarqube

Figure 26: Le Résultat de l'exécution du Jenkins Pipeline

5. Conclusion

Cette étape marque la conclusion de notre projet et revêt une importance capitale. Au coursde ce dernier
sprint, nous avons réussi à automatiser le processus de développement de l'application, intégrant des
pratiques de test et d'assurance qualité. Cette phase est essentielle pour garantir une gestion efficace de
notre projet, avec une attention particulière portée à l'automatisation et l'optimisation de nos flux de
travail. Grâce à notre pipeline Jenkins bien orchestré et à l'utilisation judicieuse de technologies telles que
SonarQube, Docker Swarm et Python pour les tests unitaires, nous avons achevé cette phase avec succès.
Nous avons ainsi clôturé notre projet en atteignant nos objectifs d'automatisation tout en maintenant un
haut niveau de qualité et de fiabilité du code.

ACHREF BARHOUMI 58
 Le Projet de Fin d'Études (PFE) auquel j'ai participé s'est concentré sur l'innovation et
l'amélioration des tableaux de bord ainsi que de l'expérience utilisateur. D'une durée totale de 4
mois, ce projet a été divisé en 4 sprints, chacun couvrant un mois de travail intensif.

Au cours du premier sprint, nous avons mené une étude approfondie de l'existant, analysé
les besoins et les problématiques, et élaboré une solution adaptée. Cette phase initiale a posé les
bases conceptuelles du projet.

Le deuxième sprint a été axé sur l'amélioration des performances et de l'ergonomie de

l'application. Nous avons mis en œuvre le Framework Next.js pour optimiser le Front-End, offrant
ainsi une expérience utilisateur plus fluide et réactive.

Au troisième sprint, nous avons concentré nos efforts sur la mise en place d'un
environnement conteneurisé pour notre application CallCenter. Cela a permis une meilleure
isolation et une gestion plus efficace de l'infrastructure, garantissant une disponibilité élevée grâce
à Docker Swarm.

Le dernier sprint a été consacré à l'automatisation des workflows. Nous avons mis en place
un pipeline CI/CD pour assurer une mise à jour automatique et continue de notre application. Cela
a considérablement réduit le temps de déploiement et de mise sur le marché.

Ces améliorations ont apporté des avantages significatifs à notre projet. Grâce au pipeline,

ACHREF BARHOUMI 59
nous avons minimisé le temps de déploiement et de mise sur le marché, permettant ainsi une
réactivité accrue aux demandes du marché. Docker a assuré une isolation efficace, garantissant la
sécurité de l'environnement conteneurisé. L'utilisation de Docker Swarm a amélioré la
disponibilité de l'application. Enfin, l'implémentation de Next.js a considérablement amélioré les
performances de l'application, offrant aux utilisateurs une expérience fluide et ergonomique.

Au cours de ma participation à ce projet, j'ai acquis des connaissances précieuses et

développé des compétences essentielles. La collaboration et la communication efficace ont été des
leçons clés alors que je travaillais activement avec les équipes pour assurer une intégration
harmonieuse et un déploiement réussi. De plus, j'ai renforcé mon sens de l'organisation, de la
discipline et de l'adaptabilité, ce qui m'a permis de naviguer avec aisance dans l'environnement
professionnel tout en maintenant une approche structurée pour atteindre les jalons et les livrables
du projet.

ACHREF BARHOUMI 60
 Bien que le projet ait été couronné de succès, il existe des opportunités d'amélioration dans
divers aspects pour en renforcer l'efficacité et la valeur.
Ces améliorations potentielles incluent :
● Ajouter davantage d'appels à l'action et améliorer les éléments et le CSS dans la partie
Front-End.
● Optimiser l'exécution et les étapes du pipeline.

● Mettre en œuvre Kubernetes au lieu de Docker Swarm pour une infrastructure plus
robuste et moderne.
● Mettre en œuvre davantage de bonnes pratiques en matière de sécurité et de
surveillance.
● Affiner les tests unitaires et les tests de couverture pour une meilleure qualité du code.

● Renforcer la gestion des versions et le suivi des modifications.

● Étendre l'intégration avec des outils de gestion de projet pour une collaboration plus
transparente.
● Améliorer la documentation technique pour faciliter la maintenance continue.

● Étendre les fonctionnalités de l'application pour répondre aux besoins changeants des
utilisateurs.
● Introduire des mécanismes de rétroaction des utilisateurs pour une amélioration
continue.
● Évaluer régulièrement les performances de l'application et effectuer des ajustements en
conséquence.

ACHREF BARHOUMI 61
 ● Mettre en place des plans de secours et de reprise après sinistre pour garantir la
continuité opérationnelle en cas d'incidents.
Ces améliorations potentielles visent à renforcer davantage la qualité, la sécurité, la réactivité et
l'adaptabilité du projet, offrant ainsi une expérience utilisateur encore meilleure et une gestion plus
efficace de l'infrastructure

Galerie de L’application :

Figure 27: Le Dashboard de B2C

ACHREF BARHOUMI 62
Figure 28:Le Dashboard des Prospects

Figure 29: Le Dashboard des listes noirs

ACHREF BARHOUMI 63
Figure 30 :Le Dashboard des extracteurs des téléphones

Figure 31:Le Dashboard des Business (B2B)

ACHREF BARHOUMI 64
Figure 32: Le Dashboard des lqualif

Figure 33: Le Dashboard des Clients

ACHREF BARHOUMI 65
Figure 34: Le Dashboard des Campaigns

ACHREF BARHOUMI 66
Figure 35: Aspect de Sécurité utilisant les tokens

ACHREF BARHOUMI 67
Figure 36: Le Contrôle de Saisie pour l’interface de Login

ACHREF BARHOUMI 68
Galerie de SonarQube

Figure 37: Suite de l‘interface principale de Sonarqube

ACHREF BARHOUMI 69
Figure 38: . Des détections d’anomalies du code du Dashboard Sonarqube

Figure 39: Des recommandations de correction du Dashboard Sonarqube

ACHREF BARHOUMI 70
Figure 40: Des statistiques du Dashboard SonarQube pour le Projet

ACHREF BARHOUMI 71
 Figure 41: Des statistiques du Dashboard SonarQube pour le code base

Galerie de Jenkins

Figure 42: Les différents stage du pipeline Jenkins

ACHREF BARHOUMI 72
Figure 43: Les Configurations pour le pipeline Jenkins

Figure 44: Les logs de stage Unit Tests

ACHREF BARHOUMI 73
Figure 45: Les logs des stages Sonarqube et test de Qualité

Figure 46: Les logs de stage Build

ACHREF BARHOUMI 74
Figure 47: Les logs des stages Cleaning, Deploy et envoi d’Email

ACHREF BARHOUMI 75
ACHREF BARHOUMI 76
[1] MaherDEV Company, [Online]. Available: https://www.maherdev.com/page/about.
[Accessed 10 02 2023].
[2] The CI/CD Approach, [Online]. Available: https://www.proofhub.com/articles/traditional- vs-
agile-project-
management#:~:text=Agile%20follows%20an%20iterative%20process,in%20changes%
20and%20specifications%20developments.. [Accessed 15 06 2023].
[3] Scrum VS Kanban methods, [Online]. Available: chrome-
extension://efaidnbmnnnibpcajpcglclefindmkaj/https://iopscience.iop.org/article/10.1088/ 1757-
899X/1218/1/012037/pdf. [Accessed 16 06 2023].
[4] Cycle of the Scrum Methodology, [Online]. Available: https://slidebazaar.com/items/scrum-
process-powerpoint-template/. [Accessed 07 06
2023].
[5] The CI/CD Approach, [Online]. Available: https://www.clouddefense.ai/blog/how-to-
implement-effective-ci-cd-pipeline. [Accessed 13 06 2023].
[6] Virtualization vs containerization , [Online]. Available: https://wpengine.com/blog/a-high-level-
guide-to-containerization/. [Accessed 12 06 2023].
[7] Sonarqube, [Online]. Available: https://www.sonarsource.com/products/sonarqube.
[Accessed 19 04 2023].

ACHREF BARHOUMI 77