rapportv3

Ministère de l’Enseignement Supérieur et de la Recherche
Scientifique
Université de Manouba
Institut supérieur des Arts Multimédias
Projet de Fin d’Études

Préparé en vue de l’obtention de la
Licence Nationale en Sciences de l’Informatique
Spécialité : Informatique Et Multimédia
CODE PFE : 103-2024
Conception et dévlopppement d’une

application web de gestion des contrats
Élaboré par
Manel Hmoudi
Yosra Sallemi
Encadré par
Mr. Marouene Kachroudi - ISAMM
Mr. Dhia Snoussi - IJENI
Année universitaire : 2023/2024
1
Dédicaces
Je dédie ce projet à ma famille

Pour mon père, son enthousiasme et son humanité m’ont permis de vivre
cette journée.Tu n’as jamais cessé de formuler des prières à mon égard et
de m’épauler pour que je puisse atteindre mes objectifs.
Pour ma chère mère, rien ne peut exprimer mon admiration.Tu m’as

appris le vrai sens de la responsabilité .Tu représentes pour moi une source
de tendresse.Que Dieu te bénisse la sante et la tranquilité de l’esprit.
Pour ma grande soeur et mon petit frère, je vous aime fort et je vous
souhaite tout le bonheur du monde.
Pour mon binome, pour sa sympathie et son soutien durant ce projet.
Pour mes amis, qui ont illuminé mon chemin avec leurs conseils précieux
et leurs encouragements.je suis tellement fière et ravie d’avoir votre amitié.
Pour tous mes professeurs, j’espère avoir exaucé vos souhaits et ma pro-
fonde appréciation.
Manel Hmoudi
i
Dédicaces
Je dédie ce projet à ma famille :
À mes chers parents , votre soutien illimité et votre amour inconditionnel

ont été la base qui m’a permis d’atteindre ce stade de ma carrière univer-
sitaire et votre désir d’être toujours à l’avant-garde.
Merci pour votre soutien , pour tous vos sacrificeset et vos encouragements
constants. C’est à vous que je dois offrir cette réussite .
À mon frère,pour ton soutien et tes conseils précieux , je te souhaite un

avenir plein de joie et de réussite . Merci tout simplement.
À mon binôme de ce projet,travailler à tes côtés a été une source de

motivation et un privilège .
Merci pour cette expérience, pour avoir partagé ce long parcours avec moi
et Merci pour ton amitié.
À mes amis,je tiens à vous remercier un par un, je suis très fière de notre
amitié et votre présence dans ma vie. Merci du fond du mon cœur.
Yosra Sallemi
ii
Remerciements
Avant tout développement de cette expérience professionnelle, nous vou-

drons exprimer notre gratitude à ceux qui ont contribué beaucoup de
connaissances dans ce projet.
Tout d’abord, nous tenons à remercier les membres du jury d’avoir ac-
cepté leurs jugements sur ce travail. Qu’ils trouvent ici le témoignage de
notre grand respect.
Egalament,il est notre désir d’exprimer nos profondes gratitudes à notre

encadrant académique à l’ISAMM, Mr Marouen Kachroudi qui n’a cessé
de fournir des conseils et des explications. Nous lui sommes tellements re-
connaissantes pour sa disponibilité et surtout l’autonomie offerte de sa part.
Nous remercions vivement notre encadrant dans l’entreprise Ijeni, Mr

Dhia Snoussi,pour avoir accepter de superviser notre travail et qui a cru
en notre potentiel. Nous lui sommes très reconnaissantes pour tout ses
connaissances partagées avec nous et pour toute aide offerte durant tout
la période de stage de fin d’études.
Nous remercions tout le personnel de Ijeni pour son accueil chaleureux

et son ambiance amicale pour la réussite de ce stage.
MERCI
iii
Liste Des Abréviations
CRM : Customer Relationship Management

ID :Identifiant
SQL : Structured Query Language
AWS : Amazon Web Services
ERP : Enterprise resource planning
API : application programming interface
CMS :Contract Management System
MVC :Model-View-Controller
JWT :JSON Web Token
Core DB : Core Database
HTTP :Hypertext Transfer Protocol
CSS :Cascading Style Sheets HTML : HyperText Markup Language
REST :REpresentational State Transfer
Client App : application client
CRUD : Create Read Update Delete
URL : Uniform Resource Locator
DTO : Data Transfer Object
AWS : Amazon Web Services
PAAS :Platform as a service
SAAS :Software as a service
IAAS :Infrastructure as a service
iv
Table des matières
Introduction générale 1
1 Présentation globale du cadre du projet 3

1.1 Intoduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organisme d’accueil :Ijeni . . . . . . . . 3
1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 PandaDoc . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2.1 Introduction . . . . . . . . . . . . . . . . 4
1.3.2.2 Analyse graphique . . . . . . . . . . . . . 4
1.3.2.3 Analyse technique . . . . . . . . . . . . . 5
1.3.2.4 Analyse fonctionnelle . . . . . . . . . . . . 6
1.3.3 NGSIGN . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3.1 Introduction . . . . . . . . . . . . . . . . 6
1.3.4 OneFlow . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.4.1 Introduction . . . . . . . . . . . . . . . . 8
1.3.5 DocuSign . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.5.1 Introduction . . . . . . . . . . . . . . . . 11
1.3.6 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
v
Table des matières Table des matières
2 Planification et Cadre technique du projet 15

2.1 Intoduction . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Spécifications des besoins . . . . . . . . . . . . . . . . . . . 15
2.2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . 15
2.2.2 Les besoins non-fonctionnels . . . . . . . . . . . . . 17
2.3 Identification des acteurs . . . . . . . . . . . . . . . . . . . 17
2.4 Planification . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Formalisme adopté . . . . . . . . . . . . . . . . . . 18
2.4.1.1 Choix retenu : Esprit Agile . . . . . . . . 18
2.4.1.2 Scrum . . . . . . . . . . . . . . . . . . . 18
2.4.2 User Stories . . . . . . . . . . . . . . . . . . . . . . 19
2.4.3 Backlog du produit . . . . . . . . . . . . . . . . . . 22
2.4.4 Philosophie DevOps . . . . . . . . . . . . . . . . . 23
2.5 Choix technique . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1 BackEnd . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2 Front-End . . . . . . . . . . . . . . . . . . . . . . 24
2.5.3 Stockage des données . . . . . . . . . . . . . . . . . 25
2.5.4 Architecture logique . . . . . . . . . . . . . . . . . 26
2.5.5 Architecture physique . . . . . . . . . . . . . . . . 27
2.5.6 Architecture matérielle . . . . . . . . . . . . . . . 28
2.6 Environnement de travail . . . . . . . . . . . . . . . . . . . 32
2.6.1 Notion . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6.2 Draw.io . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.3 OverLeaf . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.4 Ocelot . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.7 Etude globale du projet . . . . . . . . . . . . . . . . . . . 34
2.7.1 Diagramme de cas d’utilisation global . . . . . . . . 34
2.7.2 Diagramme de classe global . . . . . . . . . . . . . 36
2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3 Mise en œuvre du sprint1 37

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Sprint1 : Initialisation de l’application . . . . . . . . . . . 37
3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . 38
3.2.3 Diagramme de cas d’utilisation du Sprint1 . . . . . 40
3.2.4 Diagramme de classe du Sprint1 . . . . . . . . . . 42
3.2.5 Diagramme de séquence du Sprint1 . . . . . . . . . 44
3.2.6 Réalisation du sprint1 . . . . . . . . . . . . . . . . 47
vi
Table des matières Table des matières
3.2.7 Test fonctionnel du sprint1 . . . . . . . . . . . . . 48

3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Sprint 2 :Système de gestion global . . . . . . . . . . . . . 51
4.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . 51
4.2.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . 52
4.2.3 Diagramme de cas d’utilisation du Sprint2 . . . . . 54
4.2.4 Diagramme de classe du Sprint2 . . . . . . . . . . 57
4.2.5 Diagramme de séquence d’objet . . . . . . . . . . . 59
4.2.7 Test fonctionnel du sprint 2 . . . . . . . . . . . . . 62
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 Sprint3 : Optimisation de l’Expérience Utilisateur . . . . . 66
5.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . 66
5.2.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . 66
5.2.3 Diagramme de cas d’utilisation du sprint3 . . . . . 68
5.2.4 Diagramme de classe du sprint3 . . . . . . . . . . 70
5.2.5 Diagramme de séquence du sprint3 . . . . . . . . . 72
5.2.6 Recherche Avancée . . . . . . . . . . . . . . . . . . 73
5.2.6.1 Introduction . . . . . . . . . . . . . . . . 73
5.2.6.2 Problématique . . . . . . . . . . . . . . . 74
5.2.6.3 La Valeur Ajoutée . . . . . . . . . . . . . 74
5.2.6.4 Les processus existants . . . . . . . . . . . 74
5.2.6.5 les algorithmes utilisés . . . . . . . . . . . 75
5.2.6.6 les méthodes utilisées . . . . . . . . . . . . 77
5.2.6.7 Conclusion . . . . . . . . . . . . . . . . . 77
5.2.8 Test fonctionnel du sprint3 . . . . . . . . . . . . . 79
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Conclusion Générale et Perspectives 82
Webographie 84
Annexe 85
vii
Table des figures
1.1 Page d’accueil de PandaDoc . . . . . . . . . . . . . . . . . 4

1.2 Page d’accueil de NGSIGN . . . . . . . . . . . . . . . . . . 6
1.3 Page d’accueil de OneFlow . . . . . . . . . . . . . . . . . . 8
1.4 Page d’accueil de DocuSign . . . . . . . . . . . . . . . . . 11
2.5 Schéma des acteurs . . . . . . . . . . . . . . . . . . . . . 17
2.6 Schéma explicatif de Scrum . . . . . . . . . . . . . . . . . 19
2.7 Logo de .NET . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8 Logo d’Angular . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . 26
2.10 Architecture microservices . . . . . . . . . . . . . . . . . . 28
2.11 Représentation de Cloud . . . . . . . . . . . . . . . . . . . 29
2.12 Cloud publique . . . . . . . . . . . . . . . . . . . . . . . . 30
2.13 Cloud privé . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.14 Cloud hybride . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.15 Notion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.16 Draw.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.17 OverLeaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.18 Ocelot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.19 Diagramme de cas d’utilisation global . . . . . . . . . . . 35
2.20 Diagramme de classe global . . . . . . . . . . . . . . . . . 36
3.21 Diagramme de cas d’utilisation du sprint1 . . . . . . . . . 40
3.22 Diagramme de classe du sprint1 . . . . . . . . . . . . . . . 42
3.23 Diagramme de séquence du sprint1 . . . . . . . . . . . . . 44
3.24 Interface "Page d’accueil" . . . . . . . . . . . . . . . . . . . 47
3.25 Interface "Login" . . . . . . . . . . . . . . . . . . . . . . . 47
3.26 Interface "Ajouter un manager" . . . . . . . . . . . . . . . 48
4.29 Diagramme de séquence du sprint2 . . . . . . . . . . . . . 59
4.30 Interface "Ajouter un contrat " . . . . . . . . . . . . . . . . 61
4.31 Interface "Détails du certificat" . . . . . . . . . . . . . . . . 61
viii
Table des figures Table des figures
4.32 Interface "Ajouter une singature" . . . . . . . . . . . . . . 62

5.36 Interface "Tableau de bord " . . . . . . . . . . . . . . . . . 78
5.37 Interface "Les notifications " . . . . . . . . . . . . . . . . . 78
5.38 Interface "Barre de recherche avancée " . . . . . . . . . . . 79
ix
Liste des tableaux
1.1 Analyse graphique de PandaDoc . . . . . . . . . . . . . . . 5

1.2 Analyse graphique de NGSIGN . . . . . . . . . . . . . . . 7
1.3 Analyse graphique de Oneflow . . . . . . . . . . . . . . . . 9
1.4 Analyse graphique de DocuSign . . . . . . . . . . . . . . . 12
1.5 Avantages et Inconvénients de chaque plateforme . . . . . 14
2.6 Les user stories de notre projet . . . . . . . . . . . . . . . 22
2.7 Le backlog du produit . . . . . . . . . . . . . . . . . . . . 22
2.8 Comparaison des modèles Cloud . . . . . . . . . . . . . . 31
3.9 Estimation globale du BackLog du Sprint1 . . . . . . . . . 38
3.10 BackLog du Sprint1 . . . . . . . . . . . . . . . . . . . . . . 39
3.11 Description des classes . . . . . . . . . . . . . . . . . . . . 43
3.12 Test du Sprint1 . . . . . . . . . . . . . . . . . . . . . . . . 49
4.13 Estimation globale du BackLog du Sprint2 . . . . . . . . . 52
4.14 BackLog du Sprint2 . . . . . . . . . . . . . . . . . . . . . 53
4.16 Test du Sprint2 . . . . . . . . . . . . . . . . . . . . . . . . 65
5.17 BackLog du Sprint3 . . . . . . . . . . . . . . . . . . . . . . 68
x
Introduction générale
De nos jours avec les avancées technologiques vécues, nous remarquons

que certaines entreprises ont tendance à développer leurs propres solutions,
sans un grand intérêt aux solutions existantes sur le marché. Cette tendance
est nourrie par un besoin à avoir une solution sur mesure qui s’adapte au
contexte et au secteur d’activité de l’entreprise.
Les entreprises de toutes tailles ainsi que les Start-ups exigent la ges-
tion de leurs contrats dans leur quotidien opérationnel dans l’intention de
la traçabilité et la transparence.
Dans le cadre de la gestion des contrats et pour la garantie de la cohé-

rence et la réduction des risques de perte des documets , la gestion des
contrats est un aspect indispensable de toute organisation. Pour abor-
der efficacement ce domaine il est nécessaire de définir les besoins dans
le contexte de gestion de contrats tels que la réduction des risques finan-
ciers et juridiques.
Cette idée d’organisation des documents est une valeur ajoutée pour
chaque entreprise . La gestion des documents refélte positivement sur "IJENI
", puisque cette solution va diminuer plusieurs risques non seulement juri-
dique et d’organisation , aussi elle facilite l’interaction avec les documents
d’une manière plus claire et simple.
L’amélioration des pratiques de gestion des contrats dans le domaine

des entreprises et des startups est largement influencée par notre projet
de fin d’études. Nous sommes persuadés que notre application offrirait un
véritable avantage à ses utilisateurs en améliorant leurs procédures et effi-
cacité opérationnelle..
En vue de l’obtention de la licence nationale en Informatique et Mul-

timédia, nous avons achevé au sein de la startup Ijeni un projet de fin
1
Introduction générale
d’études qui consiste à concevoir et développer une application web pour

la gestion des contrats.
Le présent rapport comporte cinque chapitres répartis comme suit :

Un premier chapitre intitulé “Présentation globale du cadre du projet” est
consacré à la présentation du contexte et de l’organisme d’accueil ainsi que
l’analyse de l’existant .
Un deuxième chapitre intitulé “ Planification et Cadre technique du

projet” dans lequel nous identifions une explication des différentes fonc-
tionnalités de notre système , la méthodologie suivie pour le construire , le
choix technique déployé. Egalement nous avons mentionné l’environnement
de travail utilisé et on cloture ce chapitre par une étude globale du projet .
Un troisième chapitre intitulé “ Mise en œuvre du sprint1 ” constitue le

corps de notre rapport et présente le premier Sprint appelé « Initialisation
de l’application »et le déroulement en détails de ce sprint.
Un quatrième chapitre intitulé “ Mise en œuvre du sprint2 ” qui vise

à optimiser l’organisation des docuemnts de tout utilisateur et pour l’ac-
cessibilité facile à l’information.Durant ce chapitre nous allons explorer les
différentes étapes impliquées pour la gestion des documents.
On clôture notre projet par un dernier chapitre nommé “ Mise en œuvre

du sprint3” où on va poser une problématique de recherche et les algo-
rithmes utilisés pour la résoudre ainsi que la mise en oeuvre du tableau de
bord et la gestion des systèmes de notifications et du mailing.
Nous terminons notre présent rapport par une conclusion et quelques

perspectives envisagés.
2
Chapitre 1
Présentation globale du cadre du projet
1.1 Intoduction
Dans ce premier chapitre, nous allons aborder la présentation globale du
cadre du projet. En premier lieu, nous allons présenter l’organisme d’accueil
Ijeni.Par la suite, nous exposerons l’étude de l’existant des applications de
gestion de contrats.
1.2 Présentation de l’organisme d’accueil :Ijeni

Ijeni a été fondée en 2021 qui permet de mettre en relation des presta-
taires de services locaux avec des particuliers et des entreprises ayant des
besoins spécifiques.
Elle offre une variété de services allant des services de nettoyage et de

jardinage aux services de beauté et de bien-être tout en passant par les
services de santé et de travaux.
L’objectif d’Ijeni est de simplifier l’accès aux services locaux de qualité

pour les particuliers et les entreprises en Tunisie tout en offrant aux pres-
tataires des services une opportunité de développer leur activité et d’élargir
leur portée grâce à une plateforme en ligne.
3
Chapitre 1 1.3. Etude de l’existant
1.3 Etude de l’existant

1.3.1 Introduction
Cette section concerne l’étude de l’existant et identifie un élément inté-
ressant qui se présente par la gestion des contrats dans les entreprises.
En général, l’objectif de la création d’un nouveau système est d’améliorer
les fonctionnalités d’un système existant. Cette analyse nous donnerait une
meilleure idée pour trouver des solutions aux problèmes. Par conséquent,
nous approfondissons l’analyse fonctionnelle, technique et graphique.
Et finalement, nous extrayons les avantages et les inconvénients de

chaque produit en fonction des avis des utilisateurs.
1.3.2 PandaDoc
1.3.2.1 Introduction
Figure 1.1 – Page d’accueil de PandaDoc
PandaDoc est une plateforme logicielle qui combine la gestion des do-
cuments, l’automatisation et les signatures électroniques.
Elle permet de créer, envoyer, signer et archiver des contrats et des docu-
ments en ligne.
1.3.2.2 Analyse graphique
Dans cette partie, nous analyserons les éléments graphiques de Panda-

Doc comme le montre ce tableau ci-dessous :
4
Elements Description
Le logo de PandaDoc
représente une palette de
Logo couleurs vert et blanc. Il
est associé à la simplicité,
la sagesse et la fiabilité.
PandaDoc est entièrement Il est reconnaissable par sa

composée principalement par des forme éprouvée et son
formes géométriques simples design moderne, reflétant
Composition
telles que des cercles et des l’approche intuitive et
lignes. professionnelle de la
plateforme.
PandaDoc a une structure

simple avec un en-tête
contenant la barre de
Structure
navigation, une barre
latérale et un corps
affichant le contenu.
L’interface de PandaDoc
est conçue pour la
Couleurs
simplification de
l’utilisation.
Table 1.1 – Analyse graphique de PandaDoc
1.3.2.3 Analyse technique
Pour le développement front-end, JavaScript est le principal langage

utilisé, La technologie utilisée pour la création des interfaces est ReactJS.
Pour le backend, PandaDoc s’appuie sur Python et Django.
De plus, PandaDoc exploite des langages et des technologies tels que HTML
et CSS pour la présentation des documents, et SQL pour gérer les bases
de données relationnelles.
PandoDoc est compatible avec une multitude d’outils en ligne tels que ,
Dropbox, Google Drive, HubSpot, Salesforce, Zoho CRM.
C’est un outil parfait qui peut être intégré à d’autres plateformes, comme
Salesforce et HubSpot. De plus, il fonctionne sur iOS et Android .
5
1.3.2.4 Analyse fonctionnelle
Cette plateforme offre des fonctionnalités solides, telles que la création

de documents, la signature électronique, la gestion des contrats, l’envoi des
factures par email ainsi que la personnalisation des factures. . .
Voici une analyse fonctionnelle des principales caractéristiques et fonction-
nalités de PandaDoc :
•Signature Électronique.
•CRM (Customer Relationship Management).
•Création et Synchronisation de documents.
•Assistance en ligne (forum, tutoriels ...).
•Analyse des performances.
•Facturation et Modèle personnalisable.
1.3.3 NGSIGN
Figure 1.2 – Page d’accueil de NGSIGN
En 2016, la plateforme NGSign a été créée en Tunisie. C’est une solution

de signature électronique qui permet de simplifier le processus de signature
électronique et vise à perfectionner l’expérience utilisateur dans la gestion
des contrats.
6
Nous effectuerons une analyse graphique étudiée comme indiquer dans

le tableau ci-dessous :
Éléments Description
Logo NGSign utilise une com-

binaison typographique des-
lettres majuscules. Il est
composé de deux couleurs :
le jaune et le gris .
Composition l’utilisation des rectangles Les formes géométriques

est primordiale dans NG- sont continuellement asso-
Sign, qui se repose principa- ciées à des concepts de sim-
lement sur des formes géo- plicité.
métriques.
Structure Le site NGSign à une struc-

ture simple : un contenu
principal et une barre laté-
rale, sans utiliser une en-
tête et une pied de page.
Couleurs L’interface du site NGSign

est claire et lisibile , puisque
il utilise des couleurs cohé-
rentes. Ils est composé de
trois couleurs principales :
jaune, blanc et gris.
Table 1.2 – Analyse graphique de NGSIGN
NGSIGN propose une flexibilité avec une signature électronique sécuri-

sée via un Cloud privé, pour protéger les données.
Un serveur local est disponible aussi pour ceux qui préfèrent un contrôle
absolu. NGSIGN utilise WordPress, PHP, et MySQL pour son site, hébergé
sur OVHcloud et optimisé avec Autoptimize et LazySizes.
7
Ce site permet aux utilisateurs de signer leurs contrats d’une façon ra-
pide.
Alors dans cette parties, nous présentons les fonctionnalités clés de NG-
Sign :
• Assure la signature électronique.

• Suivi en temps réel des documents avec un tableau de bord.
• Intègre des workflows.
• Notifications en temps réel.
• Filtrer les transactions.
• Envoi les documents signé par mail.
• Envoi de code de sécurité par SMS .
• Sauvegarde automatique et archivage des documents.
1.3.4 OneFlow
Figure 1.3 – Page d’accueil de OneFlow
En 2012, OneFlow est fondée pour gérer les contrats, pour accélérer
le processus contractuels en utilisant des solutions numériques différentes.
Elle propose des fonctionnalités comme la création et la négociation des
contrats.
8
Dans ce cadre nous analyserons les éléments graphiques de OneFlow

comme le montre le tableau ci-dessous :
Logo OneFlow utilise une combi-

naison typographique avec
une police « Extraset Re-
bond Grotesque » en bleu
sobre.
Composition L’utilisation des rectangles Les formes géométriques

est primordiale dans One- sont continuellement asso-
Flow, qui repose principale- ciées à des concepts de sim-
ment sur des formes géomé- plicité en offrant une esthé-
triques. tique équilibrée.
Structure OneFlow a deux structures

de site web différentes. Une
page d’accueil avec un en-
tête, un contenu principal
et la deuxième structure se
concentre sur une barre la-
térale, contenu central. Éli-
minant également l’utilisa-
tion d’un bas de page.
Couleurs OneFlow se caractérise par

une interface lisible, avec
des couleurs cohérentes :
bleu, rose et jaune mou-
tarde.
Table 1.3 – Analyse graphique de Oneflow
9
OneFlow repose sur une infrastructure technologique moderne, utilise

WordPress et intègre PHP et MySQL pour la gestion des données.
Le développement frontend est réalisé par React.
L’infrastructure, soutenue par Kinsta et AWS en PaaS, assure disponibilité
et scalabilité.
OneFlow perfectionne la performance de son site en utilisant WP Rocket,
un plugin de mise en cache.
Ce site permet aux utilisateurs de signer d’une façon rapide en éliminant

les méthodes traditionnelles basées sur le papier.
Alors dans cette partie, on met l’accent sur les fonctionnalités clés de One-
Flow :
• Assurer la Signature Électronique .
• Suivi des étapes du contrat .
• Créer des modèles de contrats personnalisés .
• Analyse et rapports.
• Gestion des notifications et des rappels.
• Partage de documents.
• Guide d’utilisation et assistance.
10
1.3.5 DocuSign
Figure 1.4 – Page d’accueil de DocuSign
C’est une plateforme qui offre une gamme variée de fonctionnalités des-
tinées à la signature électronique, à la gestion de documents, à la sécurité,
ainsi que d’autres activités diverses. Cette solution permet de gérer élec-
troniquement les documents, incluant la signature électronique, la person-
nalisation des flux de travail, les notifications et l’archivage sécurisé.
Cette partie imlique l’analyse des éléments graphiques de DocuSign

comme le montre ce tableau :
Logo Il se concentre principale-
ment sur des éléments typo-
graphiques, mettant le nom
« DocuSign » avec une po-
lice de caractère claire.
Composition DocuSign est entièrement La composition du logo Do-

formé par des formes géo- cuSign reflète en approche
métriques . équilibrée lisible.
11
Structure DocuSign a une simple

structure un en-tête conte-
nant la barre de navigation,
un coté barre latérale et un
corps affichant le contenu.
Couleurs DocuSign propose une

interface visuellement at-
trayante et personnalisable.
Table 1.4 – Analyse graphique de DocuSign
DocuSign est un logiciel de signature électronique multiplateforme com-

patible avec plus de 350 intégrations.
Il offre des niveaux d’e-signature variés, une sécurité de haut niveau et une
API de référence pour la connectivité.
Simple Cloud Solutions utilise DocuSign comme un outil indépendant pour
des accords électroniques sans papier, ainsi qu’une partie intégrante de sys-
tèmes plus larges d’ERP (Entreprise Resource Planning).
Elle est décrite en RESTful API, compatible avec plusieurs langages de
programmation tels que Node.js, Python.
La plateforme est multilingue et offre une interface utilisateur intuitive et
personnalisable.
DocuSign est une plateforme de signature électronique qui permet aux

entreprises et aux utilisateurs de signer, envoyer et gérer des contrats d’une
manière efficace.
Voici une analyse fonctionnelle des principales caractéristiques et fonction-
nalités de DocuSign :
12
•Signature Électronique.
•Notifications et Alertes.
•Archivage et Stockage.
•Intégration avec d’autres applications (Fourniture d’API et de kits de
développement logiciel pour l’intégration avec d’autres applications d’en-
treprise).
•Suivi des documents.
•Envoi et réception des documents.
1.3.6 Synthèse
Dans cette section nous allons présenter les avantages et les inconvé-
nients de chaque plateforme :
Plateforme Avantages et Inconvénients
PandaDoc Avantages :
— Réduction des coûts.
— Stockage et Synchronisation des documents en temps
réel.
— Rapide et facile à apprendre et à former le personnel.
Inconvénients :
— La sélection de bloc ou texte est difficile.
— La version payante est dispendieuse.
NGSIGN Avantages :
— Des tarifs abordables.
— La disponibilité d’une version mobile.
— Une variété de méthodes de signatures électroniques.
Inconvénients :
— L’absence de modèles de contrats prédéfinis et person-
nalisables selon les besoins des utilisateurs .
— L’absence d’un guide ou de ressources d’aide pour as-
sister l’utilisateur.
OneFlow Avantages :
— Une variété de méthodes de signatures électroniques.
— L’interface du logiciel permet une navigation facile
grâce à des éléments visuels clairs, des menus intui-
tifs.
— Des modèles de contrats prédéfinis et personnalisables.
13
Chapitre 1 1.4. Conclusion
Plateforme Avantages et Inconvénients
OneFlow Inconvénients :
— Le site présente des problèmes de conception adapta-
tive, entraînant des difficultés d’affichage lors de l’uti-
lisation sur des appareils mobiles.
— Une tarification plus élevée.
— l’utilisateur est incapable de formuler ses propres ques-
tions.
DocuSign Avantages :
— Sécurité et facilité d’utilisation optimale pour les do-
cuments légaux.
— Facilité d’utilisation :il offre la possibilité de signer élec-
troniquement des documents de manière simple et ra-
pide avec une Interface conviviale avec des guides et
tutoriels.
Inconvénients :
— Problèmes de mise en page et de formatage.
— Système coûteux.
— Le support technique est lent.
Table 1.5 – Avantages et Inconvénients de chaque plateforme
Pour cela, et après avoir évalué l’analyse de quelques plateformes de

gestion de contrats , nous avons opté l’implémentation d’un tableau de
bord conviviale offrant un aperçu clair des informations, ensuite le mailing
et la reception des documents soit par email soit sur la plateforme afin de
renforcer la sécurité et la garde des documents. Et Finalement, la recherche
avancée et le système de filtrage se positionnent au sommet de nos priorités.
1.4 Conclusion
Ce chapitre avait pour but de présenter l’organisme d’accueil, de définir
la nature du projet ainsi que ses attirances .
Après avoir étudié l’existant, il est important d’envisager les différentes so-
lutions disponibles pour la gestion des contrats. PandaDoc, NgSign, One-
flow et DocuSign sont quatre des solutions le plus populaires et les plus
employées. Chacune de ses solutions a ces propres avantages et inconvé-
nients.
14
Chapitre 2
Planification et Cadre technique du projet
2.1 Intoduction
Dans ce chapitre, nous nous s’intéressons sur la planification dans le
développement de projets informatiques. Tout d’abord, on commence par
la spécification des besoins à l’identification des acteurs. Ultérieurement,
nous aborderons notre méthodologie de travail appliquée ainsi que la si-
gnification de DevOps et son importance et comment Azure DevOps peut
être une solution pour notre projet.
Par la suite, nous allons étudier le choix technique, puis l’architecture et
infrastructure et finalement notre étude globale.
2.2 Spécifications des besoins

La spécification des besoins est l’un parmi les processus clés pour la
bonne compréhension des attentes de l’utilisateur et pour bien définir les
fonctionnalités du système et son contexte.
2.2.1 Les besoins fonctionnels

En fait, notre système se structure selon les besoins fonctionnels listés
par acteur :
Pour l’Employée :
— S’authentifier.
— Se déconnecter.
— Signer les documents.
— Suivre les documents.
15
Chapitre 2 2.2. Spécifications des besoins
— Vérifier les notifications.

— Rechercher les documents.
— Consulter le tableau de bord.
— Utiliser une barre de recherche avancée .
Pour le Manager :
— S’authentifier
— Utiliser une barre de recherche avancée.
— Superviser le tableau de bord.
— Gérer les comptes de son département.
— Gérer les contrats de son département.
— Gérer les certificats de son département.
— Recevoir les demandes des certificats de son département.
Pour le Super Manager :
— S’authentifier .
— Utiliser une barre de recherche.
— Superviser le tableau de bord.
— Gérer tous les types des contrats.
— Gérer tous les types des certificats.
— Gérer tous les certificats.
— Gérer tous les contrats.
— Gérer tous les comptes.
— Gérer tous les départements.
— Gérer toutes les demandes de certificats.
Pour le système de notifications :
— Envoyer les notifications .

— Envoyer les emails.
16
Chapitre 2 2.3. Identification des acteurs
2.2.2 Les besoins non-fonctionnels

Notre système se structure aussi en fonction des besoins non fonctionnels
suivants :
• Disponibilité : S’assurer que notre système soit disponible à tout moment
pour répondre aux besoins de l’acteur.
• Passage à l’échelle : Permettre une croissance graduelle pour répondre à
l’augmentation des demandes.
• Sécurité : Notre outil est sécurisé et contrôlé par les droits d’accès des
utilisateurs.
• Facilité d’utilisation : Simplifier l’utilisation pour les utilisateurs avec
des interfaces visible.
• Performance : Garantir une réponse rapide aux exigences demandées et
une bonne expérience utilisateur.
• Fiabilité : S’assurer que notre système fonctionne correctement.
2.3 Identification des acteurs

L’acteur est une entité qui opère dans un système avec un rôle défini.
Notre système se décompose de trois acteurs principaux et un acteur se-
condaire :
• Employé : Initie le processus du contrat en fournissant les informations

nécessaires pour les créer.
•Manager : Responsable spécifique dans un domaine particulier, comme
un département ou un document, supervisant les contrats relatifs à ce do-
maine.
• Super Manager : Supervise l’ensemble du processus de gestion des do-
cuments.
• Système de notification : Responsable d’envoie des notifications et des
emails au utilisateur .
Figure 2.5 – Schéma des acteurs
17
Chapitre 2 2.4. Planification
2.4 Planification
La partie planification résume notre formalisme adopté , notre backlog
du produit. Cette partie sera cloturé par la méthodolgie du travail qu’on a
utilisé dans notre projet.
2.4.1 Formalisme adopté

2.4.1.1 Choix retenu : Esprit Agile
Chaque projet doit mettre en place des méthodes de travail. Certai-

nement, il peut assurer la livraison attendue tout en respectant les couts
alloués au début du projet. Après avoir mené une étude comparative ap-
profondie de la méthodologie agile, nous l’avons choisie.
En effet, cette méthode est un groupe de pratique pour les projets de déve-
loppement informatique. Cette méthode est plus efficace que les méthodes
traditionnelles.
L’esprit agile est basé sur un cycle de développement universel : itératif,
incrémental et adaptatif.
2.4.1.2 Scrum
Le framework Scrum nous permet de mettre en œuvre l’esprit agile, dont

le nom est un terme emprunté au rugby qui signifie «la mêlée». Scrum est
basé sur le processus de division du projet en plusieurs itérations nommées
« Sprints ». Chaque Sprint dure généralement entre deux semaines et un
mois et demi. Evidemment, la méthode Scrum appartient aux principes
des méthodologies agiles. Cette approche garantie l’évolution des fonctions
exercées et contribue à une réflexion commune sur les opportunités du
développement.
Les rôles de Scrum :
Scrum présente trois rôles dans un projet : Product Owner, Scrum Mas-
ter et l’équipe de développement. Ces rôles décrivent les principales res-
ponsabilités de ces membres.
• Le product Owner (Dhia Snoussi) C’est le représentant officiel du client

dans le projet Scrum. C ‘est le point principal de contact entre le Scrum
Master et les membres de l’équipe. Il assure que les équipes Agile offrent
la meilleure valeur possible.
18
Figure 2.6 – Schéma explicatif de Scrum
Le product Owner défini les exigences. Il peut aider les responsables fonc-
tionnels pour rédigier le cahier de charge.
• Le Scrum Master (Marouen Kachroudi) Son rôle est d’assurer la par-

ticipation de chaque membre de l’équipe et de les aider à surmonter les
différents obstacles rencontrés.
Le Scrum Master assure la cohérence et la garantie du fonctionnement cor-
recte.
Il peut être considérer comme un « leadeur » qui aide son équipe à trou-
ver des solutions. Bien évidemment, le Scrum Master se concentre sur les
points suivants : La transparence, l’auto-organisation et les valeurs.
• L’équipe de développement (Yosra Sallemi et Manel Hmoudi) Il s’agit

de deux personnes chargées du développement de cette application web.
Cette équipe possède des compétences requises pour effectuer un travail
qui satisfait les exigences du product owner sous le contrôle du Scrum
Master.
2.4.2 User Stories

Pour réaliser les user stories convenablement on a appliqué la technique
de Moscow : cette technique vise à l’établissement des priorités des besoins
des utilisateurs.
19
En tant
Id Je souhaite Pour Priorité
que
accéder à
1 Employé m’authentifier. l’application M
se déconnecter de
2 Employé me déconnecter l’application M
l’organisation et la
3 Employé suivre mes documents gestion du travail M
confirmer mon
4 Employé signer mes documents accord M
une recherche
efficace,
5 Employé filtrer l’application organisation des S
documents
rester informé des

6 Employé vérifier les notifications actions requises. M
trouver
pouvoir utiliser une barre rapidement les
7 Employé résultats associés à M
de recherche avancée
un mot-clé
suivre les
8 Employé consulter le tableau de bord performances de la M
startup
faire tout ce que l’employé une meilleure

9 Manager gestion des taches M
fait
20
En tant
que
recevoir les demandes des surveiller les

10 Manager certificats de son demandes de C
département mes employém
garantir le
gérer les contrats de mon respect des
11 Manager M
département délais
garantir le
gérer les certificats de mon respect des
12 Manager M
département délais
gérer les comptes de mon la gestion des

13 Manager comptes clients M
département
prendre une
décision et
Super faire tout ce que toute prendre la
14 M
Manager l’équipe peut faire responsabilité
globale
Super gérer tous les contrats et le classement

15 des contrats M
Manager leurs types
Super gérer tous les certificats et le classement

16 des certificats M
Manager leurs types
la meilleure
organisation des
Super responsabilités
17 gérer tous les départements M
Manager de chaque
employé
Super la gestion de
18 gérer tous les comptes tous les comptes M
Manager
Super recevoir toutes les la gestion

19 administrative M
Manager demandes de certificats
21
En tant
que
Système assurer une

20 de notifi- notifier les employés supervision S
cation efficace
Système notifier les

21 de notifi- envoyer des emails utilisateurs S
cation
Table 2.6 – Les user stories de notre projet
2.4.3 Backlog du produit

Le tableau suivant présente notre backlog du projet qui illustre les dif-
férents sprints avec les épics à réaliser dedans et leurs durées :
Sprint Titre Epics Durée
— Gérer les comptes des uti-

lisateurs
Initialisation de
Sprint1 — Authentification et autori- 3 semaines
l’application
sation
— Gérer les départements
— Gérer les certificats

— Gérer les types des certifi-
cats
— Gérer les contrats
Sprint2 Système de base 3 semaines
— Gérer les types des
contrats
— Gérer les signatures élec-
troniques
— Gérer les email

Optimisation de — Gérer les notifications
Sprint3 l’Expérience — Gérer la recherche à l’aide 3 semaines
Utilisateur d’une barre avancée
— Gérer le Tableau de Bord
Table 2.7 – Le backlog du produit
22
Chapitre 2 2.5. Choix technique
2.4.4 Philosophie DevOps

Pour atteindre l’intégration travail-vie personnelle après la fin du projet
d’étude, on doit prendre en considération certains points, tels que l’in-
fluence de la méthodologie de travail adéquate sur notre acheminement de
travail.
De ce fait, nous nécessitons une méthode qui puisse s’adapter aux change-
ments du marché.
La méthodologie DevOps est une extension des approches Agile. Elle est
capable à nous aider pour lamélioration de la qualité de notre code vue
que le temps consacré est optimisé ainsi que la réduction des couts. Pour
ces raisons, on a choisi DevOps comme une méthodologie de travail qui
combine entre le développement et les Opérations informatiques dont l’ob-
jectif est de favoriser le meilleur moyen de communication entre les deux
équipes.
C’est pour cela on a choisi DevOps comme une stratégie pour accélérer le
cycle de développement et pour améliorer l’efficacité et la sécurité.
2.5 Choix technique

Il existe plusieurs technologies qu’on peut utiliser pour le développe-
ment de notre projet, cela peut rendre notre choix plus difficile car chaque
technologie a ses avantages et ses limites.
Dans cette partie, nous présenterons les choix techniques dans notre projet
et les discuter selon leurs performances et d’autres facteurs qui garantissent
le succès du projet :
2.5.1 BackEnd
Le backEnd est appelé aussi coté serveur, il est bien évidemment invi-
sible et inaccessible pour les utilisateurs de l’application.
C’est littéralement l’épine dorsale de toute application, et pour faire le bon
choix de notre environnement il faut se baser sur ces trois facteurs princi-
paux :
• La Performance
• La productivité
• La sécurité
23
.Net aide à développer une application performante dont l’un des meilleurs
temps de réponse.
Figure 2.7 – Logo de .NET
Parmi les avantages de .Net, la sécurité de l’environnement d’exécution,

il évite les problèmes critiques tels que les tentatives malveillantes du chan-
gement du code ou la mauvaise manipulation. Lorsqu’il ya des mauvaises
menaces découvertes, .net fait l’action de la publication rapide des mises à
jour.
Pour faciliter et simplifier la gestion des problèmes des développeurs et pour
impliquer moins de codage, .Net est basé sur la programmation orientée
objet-un modèle selon lequel le logiciel est divisé en plusieurs morceaux [1].
D’une autre part, parmi les raisons qui font de .Net l’un des meilleurs choix
pour le développement de notre système CMS (Contract Management Sys-
tem) est son offert d’un large vaste de fonctionnalités et de bibliothèques
du gestionnaire de packages NuGet et de Visual Studio Marketplace.
Toutes ces raisons-là, nous aide à choisir .Net comme notre plateforme de
développement BackEnd. Pour l’envoi des emails avec la possibilité de tes-
ter et controler l’infrastructure de messagerie en un seul endroit, Mailtrap
a été notre choix comme une plateforme de livraion des emails pour faire
ces fonctionnalités.
2.5.2 Front-End
Le frontend est le côté client, c’est la partie qui s’affiche sur les écrans
des utilisateurs et qui facilite l’interaction fluide avec eux. Pour réaliser
cette expérience, on a décidé de choisir :
24
Angular17 :
Figure 2.8 – Logo d’Angular
Angular est un Framework de développement d’applications web open-

source basé sur TypeScript. Il est connu par la création facile des applica-
tions web complexes en offrant une structure solide et des fonctionnalités
avancées pour la gestion des données [2].
Bien évidemment, l’utilisation de TypeScript nous aide à la vérification
statique du code pour éviter les erreurs courantes.
Cette version apporte au développeurs Un développement 87 % plus rapide
pour le rendu hybride et un développement jusqu’à 67% plus rapide pour
le rendu côté client [3].
En parlant de ses nouvelles fonctionnalités, Angular17 offre ce qui suit :
• Flux de contrôle intégré : une nouvelle syntaxe pour le flux de contrôle.

• Vues différées : un nouveau moyen simple déclaratif pour utiliser les
composants dans Angular.
En résumé, Angular17 nous offre une performance améliorée et la réutili-
sabilité qui font un choix attirant pour les développeurs.
2.5.3 Stockage des données

Dans notre projet courant, il existe 2 types de base de données :
• Core db(Core DataBase) :

on peut héberger cette base de données Core sur SQL Server : c’est une
base de données qui stocke les données structurées.
25
• File Storage(Stockage Blob) :

Cette base de données est de type BlobStorage : Le stockage Blob est
un type de stockage dans le cloud pour les données non structurées. Ce
stockage est utile pour sauvegarder les fichiers volumineux et stocker les
médias..
2.5.4 Architecture logique

Dans notre projet on a décidé d’appliquer l’architecture MVC : (Model,
Vue, Controller).
Cette architecture nous permet de séparer les aspects présentation, don-
nées(base de données) et la logique métier.
De plus, elle est la plus communément utilisée dans les applications web.
Il devient de plus en plus plus facile pour les développeurs back-end et
front-end de travailler sur le même projet car les fichiers sont séparés.
Voici une figure qui donne un aperçu clair et bien défini de l’architecture
MVC :
Figure 2.9 – Architecture MVC
26
— Le modèle : Il gère les données de notre site Web. Son rôle principal
consiste à la récupération des informations « brutes » dans la base de
données, les organiser et finalement les combiner pour que le contrô-
leur puisse les traiter.
— Le contrôleur : Cette partie est responsable de la gestion de la logique

du code, elle gère la prise des décisions.
— La vue : Elle définit l’affichage des informations sur l’écran. C’est

l’interface de l’utilisateur..
2.5.5 Architecture physique

L’architecture dans une application web est cruciale, puisqu’elle per-
met de piloter le développement et qui assure la solidité de l’application
web. Elle permet de définir la structure, l’organisation et l’action de l’ap-
plication. L’architecture est une sert de feuille de route pour avoir une
application efficace.
Pour nous l’architecture Microservices est la plus adaptable pour notre
projet.Cette architecture consiste à décomposer l’application à des petits
services indépendants.
Chaque ’un a son modèle et fait le traitement de fonctionnalité spécifique
de manière autonome. Les développeurs travaillent sur ces microservices
qui communiquent entre eux à l’aide de l’API.
L’architecture Microservices est caractérisée par :
• L’autonomie : chaque service est individuel et développer indépendam-

ment sans affecter les autres services.
• La communication à l’aide de l’API :la communication entre les micro-
services est à l’aide des APIs
Parmi les avantages de l’architecture microservices : l’agilité, la flexibi-

lité et la rapidité du développement.
En résumé, cette architecture offre des avantages en termes de réactivité
et adaptation aux changements et de capacité à l’évolution pour répondre
aux besoins des utilisateurs.
27
Figure 2.10 – Architecture microservices
— Client App : il correspond à un terminal demandeur de ressource,équipé

d’une interface utilisateur chargée de la présentation.
— Api Gateway : c’est un composant qui se comporte comme une

passerelle entre le serveur d’application et le client.
— Server-side : il est composé par le File storage(stockage de fichiers)qui

est une méthode de stockage de données numériques et le Core DB
qui désigne la principale base de données utilisée dans notre système.
2.5.6 Architecture matérielle

De nos jours, le stockage et la sécurité des données sont devenus une
priorité absolue dans toute industrie, c’est pour cela il faut investir pour
la flexibilité et l’évolutivité des ressources.
Pour commencer, L’Informatique de Nuage ou connu par le Cloud Compu-
ting est une technologie qui permet l’utilisation des serveurs informatiques
à distance, c’est le fait de stocker les données ou d’accéder à des services
via Internet.
La connexion entre l’utilisateur et le fournisseur de services est l’une des
bases du fonctionnement du Cloud Computing.
Au lieu de stocker les données sur notre propre ordinateur, on a choisi de les
stocker sur les serveurs du Data Center d’un fournisseur de Cloud.Après,
l’utilisateur a la possibilité d’accéder à ces ressources via internet.
28
Figure 2.11 – Représentation de Cloud
Grace à cloud, les entreprises n’ont plus besoin de se soucier de la sécu-

rité ou de la maintenance de leur infrastructure, ils peuvent tout simple-
ment adopter un modèle économique basé sur un système d’abonnement.
Voici quelques avantages spécifiques pour la migration des ressources

vers le Cloud Computing :
• Gain de performance :Les logiciels sont mis à jour instantanément

par le fournisseur.
• Capacité de stockage énorme : Le Cloud Computing augmente la
capacité de stockage d’un façon illimitée grâce à la construction des nou-
veaux Data Centers.
• Evolutivité et flexibilité : Il permet d’évoluer les ressources rapide-
ment pour répondre aux besoins des clients sans avoir la nécessité d’investir
dans une infrastructure physique.
• Sécurité : Grâce à la couverture de la maintenance et des fonctionna-
lités de sécurité, le Cloud Computing renforce notre stratégie de sécurité.
De plus, Cloud nous fournit trois principales catégories de services :
• Un service IaaS(Infrastructure as a Service) : Le client gère l’ins-
tallation des systèmes sur les serveurs lui-même .
• Un service PaaS(platform as a Service) : Le fournisseur de Cloud
administre le système et ses outils et le client a la possibilité d’installer ses
applications selon son besoin.
• Un service SaaS(Software as a Service) : Il fournit l’accès aux
29
logiciels gérés par le fournisseur de Cloud.
Maintenant, on va citer les différents types de clouds :
• Le Cloud Publique : Le fournisseur gère le hardware, le logiciel et l’in-

frastructure, le Data Center contient les serveurs et les utilisateurs peuvent
accéder à ces ressources là pour obtenir leurs données.
Figure 2.12 – Cloud publique
• Le Cloud Privé : Il est déployé pour une entreprise. Elle gère l’in-
frastructure et l’hébergement.
Figure 2.13 – Cloud privé
• Le Cloud Hybride : C’est la combinaison des deux Cloud Privé

et publique :Il permet aux applications de s’éxecuter entre les deux Cloud
30
Figure 2.14 – Cloud hybride
Comparaison des modèles du Cloud :
Cloud publique Cloud privé Cloud hybride
— Évolutivité — Flexibilité — Évolutivité

— Rapport coût effica- — Haute sécurité — Rapport coût effica-
cité — Entièrement person- cité
— Facturation à l’usage nalisable — Stockage illimité
”Pay as you GO” — Locataire unique — Flexibilité
— Stockage illimité ”Single Tenant” — Haute sécurité
Table 2.8 – Comparaison des modèles Cloud
Selon les contraintes académiques et financières qu’on a, nous n’avons

qu’un seul choix qui peut répondre à nos besoins et nos objectifs : C’est le
Cloud Publique.
Pour tout ces aspects, nous décidons de migrer vers le cloud pour garantir
que notre projet sera livré sans aucun problème.
Parmi les fournisseurs Cloud et pour appliquer DevOps de la bonne ma-
nière, Microsoft Azure nous a offert Azure DevOps qui est l’un des meilleurs
outils qui peut améliorer le cycle de vie du développement, pour le déploie-
ment, le testet pour la gestion des applications et des services via des
centres de données gérés par Microsoft.
Azure DevOps se caractérise par une gamme de services différents pour

assurer une collaboration et une automatisation efficace au cours de pro-
cessus de développement :
31
Chapitre 2 2.6. Environnement de travail
• Azure Boards qui permet de gérer les projets d’Agile, leurs planifica-
tions, le suivi des éléments de travail et la visualisation.
• Azure Pipelines pour l’intégration et le déploiement.
• Azure Repos qui fournit des dépôts git privés dans le cloud.
• Azure test Plans qui est nécessaire pour fournir la solution planifiée de
test.
En conséquence, nous optons pour Azure DevOps puisqu’il a plusieurs

caractéristiques telles que la fiabilité et la sécurité et surtout il n’y ait pas
de perte de temps à apprendre toutes ses astuces.
2.6 Environnement de travail

Pour réaliser toutes les fonctionnalités de notre système , on a besoin
de plusieurs outils logiciels :
2.6.1 Notion
Figure 2.15 – Notion
Notion est une plateforme des outils no-code productifs. Il est conçu
pour le pilotage des connaissances, pour la facilité du travail pour ses uti-
lisateurs. Cette plateforme peut être indispensable pour toute personne en
tant que travailleur, professionnel en entreprise. Cet espace de travail aide
à la gestion des notes, taches, tableaux, idées, bases de données etc.
Son objectif principal est la centralisation du travail en équipe en gardant
32
Chapitre 2 2.6. Environnement de travail
toutes les modifications faites. Cet outil illustre la capacité à trouver facile-
ment et rapidement les informations rangées. En somme, cette application
nous a aidé pour mieux organiser nos idées et nos réflexions.
2.6.2 Draw.io
Aussi, Pour la conception des diagrammes uml et le dessin graphique
on a utilisé Draw.ia. C’est un logiciel de dessin graphique multiplateforme
gratuit développé en HTML5 et JavaScript, facile à utiliser en proposant
une interface lisible.
Figure 2.16 – Draw.io
2.6.3 OverLeaf
Pour créer et collaborer sur des documents de qualité professionnelle,
on a utilisé Overleaf qui est une plateforme en ligne gratuite, elle propose
des variétés de modèles et une interface accueillante pour la création de
documents LaTeX sans avoir besoin de l’installer.
Ce langage de balisage peut composer des documents tel que des présen-
tations, des rapports et des articles.
Figure 2.17 – OverLeaf
33
Chapitre 2 2.7. Etude globale du projet
2.6.4 Ocelot
Ocelot est une API Gateway pour .NET.Il décrit le routage d’une re-
quete HTTP vers une autre.
Figure 2.18 – Ocelot
2.7 Etude globale du projet

Dans cette partie, nous avons présenté l’étude globale de notre projet
autrement dit les conceptions graphiques, c’est une étape très importante
pour assurer le succès de notre projet.
2.7.1 Diagramme de cas d’utilisation global

Le diagramme de cas d’utilisation présente les fonctionnalités offertes
par le système d’un point de vue d’acteur.
D’ailleurs cette représentation nous montre comment le système et ses ac-
teurs interagissent . Elle est utile pour la présentation du projet et aux
acteurs clé.
34
Chapitre 2 2.7. Etude globale du projet
Figure 2.19 – Diagramme de cas d’utilisation global
35
2.7.2 Diagramme de classe global

Les diagrammes de classes dont des diagrammes utilisés en génie logiciel
pour présenter les classes et les interfaces du système et les différentes
relations entre elles.
Figure 2.20 – Diagramme de classe global
2.8 Conclusion
Durant ce chapitre, nous avons présenté une vue globale sur l’application
à développer en formalisant la divergence des technologies et outils utilisés.
Dans le chapitre suivant, nous allons passer à la mise en œuvre des sprint
1 et 2. En respectant l’enchainement des étapes du framework SCRUM
adopté , on passe à la partie conception où on a déterminé les acteurs, les
besoins fonctionnels et non-fonctionnels de notre système.Cette partie est
la plus importante pour tout système puisqu’elle facilite la compréhension
de celui-ci. Ce chapitre sera cloturé par une présentation du cadre global du
projet à travers le diagramme de cas d’utilisation global et un diagramme
de classe.
36
Chapitre 3
Mise en œuvre du sprint1
3.1 Introduction
Durant ce chapitre, nous allons présenter les détails de la mise en œuvre
du sprint1 de notre projet.
Notre but principal est la gestion des bonnes pratiques pour assurer le bon
déroulement de l’application telles que la communication avec toutes les
parties prenantes ainsi que la gestion des risques.
Notre premier sprint comporte l’authentification, la gestion des comptes
des utilisateurs et la gestion des départements.
Toutes ces fonctionnalités sont accompagnées par des captures d’écrans des
interfaces réalisées.
3.2 Sprint1 : Initialisation de l’application

3.2.1 Introduction
Ce sprint consiste à mentionner les différentes fonctionnalités réalisées.
On commence par l’authentification qui est bien évidemment la clé pour
accéder à l’application, ultérieurement on a la gestion des comptes des
utilisateurs et finalement la gestion des départements de notre Start-Up.
Durée
Epics Description
estimée
Ce service est responsable de l’identification de

Authentification l’utilisateur et de la gestion du token 1 semaine
37
Chapitre 3 3.2. Sprint1 : Initialisation de l’application
Durée
Epics Description
estimée
Ce service a la responsabilité de la gestion des

Gestion des comptes des utilisateurs où il ya l’implementation 1 semaine
comptes des méthodes et des attributs
Ce service est responsable de la gestion des

Gestion des départements ainsi que leurs relations avec les 1 semaine
départements employés
Table 3.9 – Estimation globale du BackLog du Sprint1
3.2.2 Sprint Backlog

Ce premier sprint est la première étape du processus du développement
de notre plateforme.
Le sprint backlog comprend les épics, les features et l’estimation.
Epic Feature Estimation
Se connecter 10 heures
Authentification
Mot de passe oublié 10 heures
Réinitialiser mot de passe oublié 10 heures
Se déconnecter 5 heures
38
Afficher la liste de tous les comptes 8 heures
Gestion les comptes

des utilisateurs Afficher le compte de chaque utilisateur 9 heures
Modifier le compte d’un utilisateur 10 heures
Ajouter un utilisateur 8 heures
Désactiver le compte d’un utilisateur 8 heures
Afficher la liste de tous les départements 7 heures
Gestion des
départements Afficher chaque département 10 heures
Supprimer le département 10 heures
Modifier le département 8 heures
Créer un département 7 heures
Table 3.10 – BackLog du Sprint1
39
3.2.3 Diagramme de cas d’utilisation du Sprint1
Figure 3.21 – Diagramme de cas d’utilisation du sprint1
40
Description de cas d’utilisation :

Un diagramme de cas d’utilisation doit contenir des acteurs avec leurs cas
d’utilisation. Ce diagramme est relatif au premier sprint :
Titre :Authentification
•Acteurs :
L’Employée, Le Manager et le SuperManager
•Pré-condition :
l’Employée doit être ajouté soit par le SuperManager soit par le manager
de son département
•Scénario nominal :
1.L’utilisateur tape l’URL dans le navigateur
2.Le système affiche la page d’accueil
3.L’utilsateur clique sur se connecter pour se diriger vers l’authentification
4.L’utilisateur saisie son e-mail et son mot de passe
5.Le système vérifie les données saisies
6.le système dirige l’utilisateur vers la page DashBord
•Scénario alternatif :
1.les coordonnées sont incorrectes.
2.Un message d’erreur s’affiche si le compte n’existe pas ou si les coordon-
nées sont incorrectes ou si le status du compte ne vérifie pas les conditions
Titre :Déconnexion
•Acteurs :
•Pré-condition :
Tout utilisateur a le droit de se déconnecter
1.Dans la barre à coté à droite l’utilisateur trouve une drop-down list.
2.Il clique sur sa photo de profile et il va trouver le bouton de déconnexion
Il n’ya pas de scénario alternatif.
Titre :Gestion des comptes

•Acteurs :
Le Manager et le SuperManager
•Pré-condition : Le SuperManager a le droit de gérer tous les comptes
et le Manager a le droit de gérer que pour son département
41
1.Apres l’authentification, A gauche , le manager trouve la liste des comptes

des employés de son département où il peut ajouter un employé, faire des
modifications pour son compte ou le désactiver .
2.Le SuperManager a l’accès pour la gestion de tous les comptes
1.Les informations ne conviennent pas (par exemple un compte qui existe
déjà)
2.Un message d’erreur s’affiche
Titre :Gestion des départements

•Acteurs : le SuperManager
•Pré-condition : le Super Manager a le droit de tout gérer
Apres l’authentification, A gauche , le SuperManager trouve la liste de tous
les départements où il peut ajouter un département, le supprime, ou faire
les modifications nécessaires.
1.Les informations ne conviennent pas (par exemple un département qui
existe déjà)
2.Un message d’erreur s’affiche
3.2.4 Diagramme de classe du Sprint1
Figure 3.22 – Diagramme de classe du sprint1
42
Description de classes :
Une classe est un modèle pour créer des objets. Cette classe se constitue
par un nom et des attributs. Les classes relatives au premier sprint sont
décrites dans ce tableau :
Classe Description
La classe Employee est définie par un Identifiant,

le nom et le prénom , l’email, le mot de passe ,
l’etat du status de son compte , les dates de
Employee création, des mises à jour, le poste , education ,
les langues parlées , numéro du téléphone ,
biographie , adresse et finalement la photo.
Manager Cette classe hérite de classe Employee
SuperManager Cette classe hérite de classe Manager
Cette classe contient son Identifiiant(Id), le

EmployeeFor- token,la date de création et d’utilisation,la
getPassword période de l’expiration et une variable booléenne
qui indique si elle est utilisée ou non(IsUsed).
Elle a un identifiant(id), le nom du département

Department et finalement la date de création.
Cette classe est une classe enum qui contient les

Account Status valeurs possibles du statuts d’un compte
Table 3.11 – Description des classes
43
3.2.5 Diagramme de séquence du Sprint1

La figure suivante représente le scénario de réinitialisation d’un mot de
passe oublié :
Figure 3.23 – Diagramme de séquence du sprint1
44
Description du diagramme :
1.Interaction avec le client

Etape 1-3 :
Le client clique sur le bouton "mot de passe oublié" dans l’interface de
l’application client(Client App).Il va être navigué à la page de saisie de
l’email où il va écrire l’adresse email de son compte et puis il clique sur
envoyer. Cette étape est faite pour la réinitialisation du mot de passe tout
en vérifiant l’adresse email.
2.Client app vers API Gateway

Eptape 4
L’application client(client app) envoie une requête vers l’API Gateway.
Cette requête inclus l’email fournie par l’utilisateur et demande le lien de
réinitialisation de mot de passe ce lien va être généré et envoyé à cet e-mail.
3.Api Gateway et Core service

Etape 5-7 :
L’API Gateway va transférer l’email de l’utilisateur vers le Core Service.
Ce service est responsable du traitement de la demande en commençant
par la validation de l’email dans la base de données (Core Db).
4.Core service et Client

Etape 8-9 :
Si l’utilisateur n’existe pas une réponse http va être généré par le Core ser-
vice et un message va être affiché pour le client disant "l’utilisateur n’existe
pas avec cet email".
5.Gestion du Core service

Etape 8-11 :
Si l’utilisateur existe (l’email est valide), le core service va générer un token
unique, cette etape est cruciale car l’accès à la page mot de passe oublié né-
cessite cette étape. Les informations vont être stockées dans la Core Db(la
base de données) associé avec l’adresse email de l’utilisateur, token et le
lien.
Etape12-14 :
Le lien de réinitialisation est envoyé au service de notification qui va former
et envoyer un email qui contient le lien de réinitialisation de mot de passe
à l’utilisateur.
45
6.Utilisateur recoit L’email

Etape 15-16 : l’utilisateur vérifie son email et clique sur le lien envoyé par
le service de notification.
7.CLient app vers API Gateway vers CoreService

Etape 17-20 : l’application client va envoyer une requete http token de vé-
rification vers L’API Gateway et cette dernière rédigera cette demande
vers le Core service. La base de données va obtenir les informations token
à partir du service.
8.Vérification du Token
Etape 21-22 :
Le core service va vérifier la validité du token utilisé : si le token est utilisé
ou null ou expiré un message d’erreur va etre affiché pour l’utilisateur et il
doit envoyer une autre demande.
Etape 21-25 :
Si le token est utilisé avec succès , les informations seront enregistrées avec
succès et une réponse Http va etre envoyé vers le client qui va etre naviguer
victorieusement vers la page où il va saisir un nouveau mot de passe.
Etape 26-32 :
Le client doit écrire son nouveau mot de passe et sa confirmation avec le
bouton donné. Une requete http va etre rédigée et traitée vers la core db
où les information svont etres stockées. Finalament le client peut naviguer
vers la page de connexion où il va écrire son e-mail et son nouveau mot de
passe correctement et il peut accéder à l’application.
46
3.2.6 Réalisation du sprint1

Dans cette partie, nous montrons la réalisation de nos interfaces finales
crées tout au long du sprint1 :
Interface "Page d’accueil" : Cette page présente la première page de notre

application
Figure 3.24 – Interface "Page d’accueil"
Interface "Se connecter" : Cette page fournie l’accès à notre système
Figure 3.25 – Interface "Login"
47
Interface "Ajouter un manager" : Cette page présente la page d’ajout

d’un manager
Figure 3.26 – Interface "Ajouter un manager"
3.2.7 Test fonctionnel du sprint1

Dans cette partie , nous faisons un test de chaque epic réalisée dans le
sprint 1 comme représente ce tableau.
Tâche Entrée sortie validation
Login+ mot de passe

Correct Réalisée avec succès ✓
Login ou mot de passe

Incorrect Connexion échouée ✓
Authentification
Envoyer un mail qui

Mot de passe oublié contient un nouveau mot ✓
de passe
Aucune donnée saisie Connexion échouée ✓
Se déconnecter Réalisée avec succès ✓
48
Accéder à la liste des em- Affichage de la liste de dé-

ployés tails des employés ✓
Suivre les
comptes
Accéder aux données dé- Affichage des informations
taillées de chaque employé plus détaillées ✓
Create, Read ,Update des

Réalisé avec succès ✓
employés
Problème d’une opération Opération de Create, Read

de Create, Read ,Update ,Update échouée ✓
Filtrer l’applica- Faire un filtre selon un dé-

Filtrage réussie ✓
tion partement
Accéder à la liste des dépar-

Affichage de la liste de dé- ✓
tements
tails des département
Accéder aux données dé-

Affichage des informations
Suivre les taillées de chaque départe- ✓
plus détaillés
départements ments
CRUD du département Réalisée avec succès ✓
Problème d’une opération Opération de CRUD

de CRUD échouée ✓
Affecter un employé à un Affectation réalisée

✓
département
Affectation d’un employé à

un département non valide Affectation échouée ✓
Table 3.12 – Test du Sprint1
49
3.3 Conclusion
Le chapitre de mise en oeuvre du Sprint 1 de notre projet de gestion des
contrats a été achevé avec succès. Durant ce chapitre nous avons présenté
notre sprint backlog , les diagrammes utilisés pour ce sprint, nous avons
exposé nos réalisations achevées et on cloture ce chapitre par un tests
fonctionnel.
50
Chapitre 4
4.1 Introduction
Dans ce chapitre nous allons identifier la gestion des documents des
utilisateurs et de leurs signatures électroniques.
Pour la création des documents et la bonne gestion de l’entreprise , la
gestion des contrats et des certificats est une discipline essentielle qui est
efficace opérationnellement.
Toutes ces fonctionnalités sont accompagnées par des captures d’écrans des
interfaces réalisées.
4.2 Sprint 2 :Système de gestion global

4.2.1 Introduction
Ce sprint implémente beaucoup de fonctionnalités telles que : la gestion
des documents : les contrats et leurs types, les certificats et leurs types et
les signatures électroniques.
Ce sprint est considéré comme un des pus importants sprints dans notre
application car il gère la supervision et le controle de nos documents.
Durée
Epics Description
estimée
Elle est responsable de la gestion des certificats

Gestion des des utilisateurs où il ya l’implementation des 7 jours
certificats méthodes et des attributs
51
Chapitre 4 4.2. Sprint 2 :Système de gestion global
Durée
Epics Description
estimée
Gestion des Elle est responsable de la gestion des types des

types des certificats des utilisateurs où il ya 5 jours
certificats l’implementation des méthodes et des attributs
a la responsabilité de la gestion des contrats des

Gestion des utilisateurs où il ya l’implementation des 7 jours
contrats méthodes et des attributs
Gestion des Elle est responsable de la gestion des contrats

types des des utilisateurs où il ya l’implementation des 5 jours
contrats méthodes et des attributs
Gestion des Elle est responsable de la gestion des signatures

signatures électroniques et les documents signés 6 jours
électroniques
Table 4.13 – Estimation globale du BackLog du Sprint2

Ce sprint est la deuxième étape du processus de développement de notre
logiciel.
Le sprint backlog comprend les épics, les features et l’estimation de la
durée.
Afficher la liste de tous les certificats 10 heures
Gestion des certificats

Ajouter un certificat 8 heures
Afficher les détails du certificat 6 heures
Modifier le certificat 6 heures
52
Afficher la liste de tous les types des certifi-

5 heures
cats
Gestion des types des
certificats
Ajouter un type de certificat 5 heures
Afficher les détails du type certificat 5 heures
Modifier le type du certificat 5 heures
Afficher la liste de tous les contrats 4 heures
Gestion des contrats

Ajouter un contrat 5 heures
Afficher les détails du contrat 5 heures
Modifier le contrat 5 heures
Afficher la liste de tous les types des contrats 5 heures
Gestion des types des

contrats Ajouter un type de contrat 5 heures
Afficher les détails du type contrat 5 heures
Modifier le type du contrat 5 heures
Afficher la liste de documents signés par moi 10 heures

Gestion des
signatures
Ajouter les détails de la signature 10 heures
électroniques
Ajouter une signature 3 heures
Supprimer une signature 3 heures
Modifier une signature 5 heures

53
4.2.3 Diagramme de cas d’utilisation du Sprint2

Un diagramme de cas d’utilisation doit contenir des acteurs avec leurs cas
d’utilisation. Ce diagramme est relatif au deuxième sprint :
Titre :Demander des nouveaux certificats

• Acteurs :
L’Employée, Le Manage,Super manager
•Pré-condition :
Tout utilisateur a le droit de demander des nouveaux certificats.
Dès l’accès à l’application, l’utilisateur trouve en haut une drop-down list
54
ou il trouve ses documents et dans cette liste il trouve un bouton où il a le

droit de demander un certificat.
Il n’ya pas de scénario alternatif
Titre :Signer les documents

•Acteurs :
•Pré-condition : tout utilisateur a le droit d’ajouter sa signature.
Après son accès à l’application , l’utilisateur trouve tous ses documents qui
existent signés.
1.L’utilisateur n’a pas de signature dans l’application
Titre :Suivre les documents

•Acteurs :
•Pré-condition :
Tout utilisateur a le droit de suivre ses documents et le manager a le droit
du suivi des documents de son département et le superManager a le droit
de tout suivre.
Apres l’authentification, en haut l’utilisateur trouve tous ses documents :cer-
tificats et contrats
Pas de scénario alternatif
Titre :Gérer les documents

•Acteurs : Le Manager et le SuperManager
•Pré-condition :
Le manager a le droit de gérer les documents de son département et le
SuperManager a le droit de tout gérer.
Dès l’accès à l’application, l’utilisateur trouve en haut ses documents, le
manager trouve à gauche aussi les documents de son département et le
SuperManager trouve tous les documents.
55
Titre :Gérer les types des documents

•Acteurs :
le SuperManager
•Pré-condition :
Seul le SuperManager a le droit de gérer les types documents.
Dès l’accès à l’application, le SuperManager trouve à gauche les types des
certificats et des contrats.
Titre :Demander des certificats

•Acteurs :
Tout utilisateur
•Pré-condition :
Tout utilisateur a le droit de demander des certificats.
Quand l’utilisateur accéde à l’application , il trouve à droite son profile ,
où il va trouver une drop down liste qui contienne la possibilité d’ajouter
une demande de certificat.
56
4.2.4 Diagramme de classe du Sprint2
57
Les classes relatives au deuxième sprint sont décrites dans ce tableau :
Classe Description

Elle a un identifiant(id), la date de création , la

Signature date de mise à jour et finalement une photo du
signature .
Cette classe a un identifiant(id), nom , statut ,

Certificate référence , date de création , date de mise à jour ,
date de début et fin du certificat .
Cette classe a un identifiant(id), nom , statut ,

Contract référence , date de création , date de mise à jour ,
date de début et fin du contrat .
Cette classe a un identifiant(id), nom et

TypeCertificate description.
Cette classe a un identifiant(id), une date de

DemandeCertificate création, de mise à jour et un status.

TypeContract description.
Cette classe a un identifiant(id), titre , langue et

TemplateCertificate description.
Cette classe a un identifiant(id), titre , langue et

TemplateContract description.
58
Classe Description

DocumentStatus valeurs possibles du statuts d’un document

DemandeCertifStatus valeurs possibles du statuts de demande d’un
certificat
4.2.5 Diagramme de séquence d’objet

La figure suivante représente le scénario du changement de l’état du
statut d’un contrat :
Figure 4.29 – Diagramme de séquence du sprint2
59

Etape 1-3 :
Le manager ou le SuperManager clique sur un contrat dans l’interface de
l’application client (ClientApp).Il va être naviguer aux détails du contrat
où il peut changer l’état de son statuts.
2.Client app vers API Gateway

Eptape 4
L’application client(client app) envoie une requête vers l’API Gateway.
3.Api Gateway et Core service

Etape 5
L’API Gateway va rédiger la demande de l’utilisateur vers l’end point cible
qui va traiter cette requête.
4.Core Service et Core DB :

Etape6-9
:Le service va tester l’existence du contrat dans la base de données et une
réponse HTTP va etre générée par la base de données vers le service : Si le
contrat n’existe pas : la réponse HTTP contiendra un problème de retour
Sinon le core service obtiendra les informations du contrat à partir de la
CoreDB.
5.Status du contrat :
Etape10-19 :
Si le contrat est archivé : Un message d’erreur sera affiché : il ne peut pas
le changer
Si contrat est validé : Un message d’erreur sera affiché : :il ne peut le chan-
ger que archivé
Si le contrat est annulé : Un message d’erreur sera affiché : :il ne peut pas
le modifier
Si son status est brouillon : : Un message d’erreur sera affiché :il ne peut
que changer que validé ou annulé
Sinon (si il n’ya pas de problème de statut du contrat : le service partage
les informations de l’email et de la notification et ils seront envoyés par le
service de notification vers l’utilisateur
60
6.Core Service et ClientApp :

Etape 15-16 : Etape20-22 : le core service va rediger les données vers le
dto puis il génére une réponse HTTP qui va etre affiché sous la forme de
notification et un email pour l’utilisateur.

crées tout au long du sprint :
Interface "Ajouter un contrat" : Cette page présente la page d’ajout d’un

contrat par le super manager .
Figure 4.30 – Interface "Ajouter un contrat "
Interface "Détails du certificat" : Cette page présente la page du détails

d’un certificat .
Figure 4.31 – Interface "Détails du certificat"
61
Interface "Ajouter une singature" : Cette page présente la page d’ajout

une siganture .
Figure 4.32 – Interface "Ajouter une singature"
4.2.7 Test fonctionnel du sprint 2

sprint 2 comme le représente ce tableau :
Tâche Entrée Sortie Validation
Accéder à la liste des Affichage de la liste de dé-

contrats des employés tails contrat ✓
Gérer les
Contract Accéder aux données dé- Affichage des informations
taillées de chaque contrat d’un contrat plus détaillées ✓
Create, Read, Update du

contrat
Problème d’une opération

Opération de Create ou
de Create ou Read ou Up- ✓
Readou Update échouée
date
62
Accéder à la liste des certi- Affichage de la liste des dé-

ficat des employés tails des employés ✓
Gérer les
Certificat
Accéder aux données dé- Affichage des informations
taillées de chaque certificat d’un certificat plus détaillé ✓
Create, Read, Update d’un

certificat
Problème d’une opération

Opération de Create ou
de Create ou Read ou Up- ✓
Read ou Update échouée
date
Faire un filtre d’un contrat

ou d’un certificat selon le Filtrage réussie ✓
département
Faire un filtre pour un

Faire un filtrage type de certificat ou type
du contrat selon un dépar-
tement
Faire un filtre d’un contrat

ou d’un certificat selon un
date de début et une date
de fin
Accéder à la liste des types Affichage de la liste de dé-

des contrats des employés tails de type contrat ✓
Gérer les types Affichage des informations

de contrat d’un type de contrat plus ✓
taillées de chaque type
détaillé
Affecter un type de contrat

Affectation réussite ✓
une Template
CRUD du type contrat Réalisé avec succès ✓
63

Accéder à la liste des types Affichage de la liste des dé-

des certificats des employés tails de type certificat ✓
Gérer les types Affichage des informa-

de certificat tions d’un certificat plus dé- ✓
taillées de chaque type
taillées
Affecter un type de certifi-

Affectation réussite ✓
cat une Template
CRUD du type certificat Réalisée avec succès ✓

Accéder à la liste des Em- Affichage de la liste des em-

ployés qui ont une signature ployés ✓

Affichage des informations
taillées de chaque signature
d’une signature plus dé- ✓
Gérer les lorsque on click sur l’em-
taillés
Signatures ployée
CRUD de signature Réalisé avec succès ✓

Le contrat est signé par le

Signer un contrat ✓
manger et l’employé
64
Le certificat est signé par le

Signer un certificat ✓
manager
Afficher une liste qui

Accéder aux documents
contienne tous les docu- ✓
que l’utilisateur a signé
ments signés
Table 4.16 – Test du Sprint2
4.3 Conclusion
Tout au long de ce chapitre , nous avons mis en oeuvre l’importance de
la création et la gestion des documents électroniques tout en utilisant des
technologies modernes.Initialement , nous avons présenter notre backlog du
sprint plus détaillé. Par la suite, on a intégré nos diagrammes du sprint qui
sont accompagnés par leurs descriptions textuelles.Pour cloturer ce chapitre
on a exposé quelques réalisations de l’application et un test fonctionnel
pour vérifier les fonctionnalités.
65
Chapitre 5
5.1 Introduction
Après avoir achevé les deux premiers sprint nous allons cloturer notre
projet par un dernier sprint intitulé optimisation de l’expérience utilisateur.
Ce chapitre a pour but de présenter le dashbord appliqué, les tâches de
notification et du mailing et finalement nous avons souhaité d’améliorer
notre projet en impliquant une recherche avancée.
5.2 Sprint3 : Optimisation de l’Expérience Utilisa-

teur
5.2.1 Introduction
Ce chapitre ce concentre sur les traveaux réalisés lors du dernier sprint.On
décompose ce sprint en sprint backlog , les diagrammes nécessaires. Nous
allons également passer en revue les meilleures pratiques pour assurer le
succès de notre application de gestion des contrats , nottammment la re-
cherche avancée appliquée. Ce chapitre sera cloturé par une réalisation et
un test fonctionnel.

Ce troisième sprint est la dernière étape de l’avancement de notre projet.
Le Sprint backlog comporte les épics, les features et leurs estimations.
66
Chapitre 5 5.2. Sprint3 : Optimisation de l’Expérience Utilisateur
Gérer le tableau de Personnalisation du tableau de bord 10 heures

bord
Lister les points clés à suivre 7 heures
Envoyer un email pour la validation d’un

5 heures
contrat
Envoyer un email pour la validation d’un

5 heures
certificat
Envoyer un email pour l’affectation d’un ma-

5 heures
nager dans un département
Gestion du mailing
Envoyer un email pour l’ajout d’un employé 5 heures
Envoyer un email pour la désactivation du

4 heures
compte
Envoyer un email pour l’ajout d’un manager 4 heures
Envoyer un email pour la réinitialisation 10 heures
Notifier l’employé de la validation d’un

11 heures
contrat
Gestion du système
de notification
Notifier l’employé de la validation d’un cer-
4 heures
tificat
Notifier l’employé de l’affectation d’un ma-

4 heures
nager à un département
67
Recherche des focntionnalités de l’applica-

10 heures
tion
Recherche des certificats et des types certi-

10 heures
Gestion de la ficats
recherche avancée
Recherche des départements 12 heures
Recherche des contrats et des types contrats 12 heures
Recherche des employés 8 heures
5.2.3 Diagramme de cas d’utilisation du sprint3
68

Ce diagramme est relatif au troisième sprint :
Titre :Vérifier les notifications

• Acteurs :
L’Employée.
•Pré-condition :
Tout utilisateur a le droit de vérifier ses notifications .
Dès l’accès à l’application , l’utilisateur trouve son profil où il ya une drop-
down list où il peut accéder à la liste de ses notifications et aux détails de
chaque notification .
Il ne reçoit pas des notifications .
Titre :Chercher des fonctionnalités ou des documents

• Acteurs :
L’Employée.
•Pré-condition :
Tout utilisateur a le droit de chercher des fonctionnalités ou des documents.
Aprés l’authentification, l’utilisateur trouve tout ce dont il a besoin.
Titre :Superviser le tableau de bord

• Acteurs :
L’Employée.
•Pré-condition :
Tout utilisateur a le droit de superviser le tableau de bord .
Dès l’accès à l’application , l’utilisateur trouve un tableau de bord pour
naviguer et suivre toutes les statistiques .
69
Titre :Envoyer les notifications

• Acteurs :
Système de notification (Acteur secondaire)
•Pré-condition :
un Système envoi les notifications .
le Système de notification envoi des notification à chaque utilisateur pour
lui informer d’un changement .
Titre :Envoyer les emails

• Acteurs :
Système de notification (Acteur secondaire)
•Pré-condition :
Un système envoi les emails .
le système de notification envoi des emails à chaque utilisateur pour lui
informer d’un changement .
5.2.4 Diagramme de classe du sprint3
70
Les classes relatives au troisième sprint sont décrites dans ce tableau :
Classe Description

La classe Notification est définie par un

Identifiant (ID), une date de
création(CreatedDate), OpenedDate,date de mise
Notification à jour, le contenu de la notifcation ,l’id de
redirection , une variable boolénne isRead et la
date de lecture.
La classe Search History est définie par un

Search History Identifiant (ID) , le texte et la date de recherche .
Cette classe contient son Identifiiant(Id), le sujet

Received Mail ,la date de création , l’expéditeur et le
destinataire.
Elle a un identifiant(id), le nom , la date de

AppFeatures création , date de mise à jour et la route .
Notification Cette classe est une classe enum qui contienne

Account les valeurs possibles du contenu d’une notification
Cette classe est une classe enum qui contienne

AccessedBy les valeurs possibles d’accès à une fonctionnalité
71
5.2.5 Diagramme de séquence du sprint3

Ce diagramme de séquence montre le flux de données et les vérifications
appliquées pour effectuer le processus de la recherche :

Etape 1 :
Dans la barre de recherche le client tape les mots clés qu’il souhaite les
trouver.
2.Client App vers API Gateway

Etape2
L’application client(client app) envoie une requête http vers l’API Gateway.
3.API Gateway vers Core service

Etape3 :
L’API Getway redirige la demande du client vers le micro service du ba-
72
ckend.
4.Gestion du Core Service

Etape4 :
Pour valider l’accès aux fonctionnalités, le service doit vérifier le token de
ces fonctionnalités.
Etape5-6 :
Si le token est n’est pas validé un message d’erreur sera dirigé du core
service vers le client. Sinon, le service vérifie les fonctionnalités accessibles
par cet utilisateur. Après, le service va récupérer les données à partir de la
base de données (Core DB).
5.Core DB
Etape7 : une réponse HTTP va être fournie par la base de données vers le
Core Service
6.Core Service
Etape8-9 : En appliquant un algorithme parmi les algorithmes avancés
qu’on a exploités, le service doit filtrer les données et les mots clés se-
ront enregistrés dans l’historique de recherche.
Etape10-11 : Une réponse http est reçue de la base de données par le Core
Service qui va caster un liste des données dans un DTO.
7.Core service vers Client App

Etape 12-13 : Le service redigera une réponse http vers le client App et
l’information recherchée est affichée à l’utilisateur.
5.2.6 Recherche Avancée

Durant cette section nous allons présenter la problématique que nous
avons identifiée , la valeur ajoutée de cette recherche , les algorithmes
avancées et les algorithmes développés.
De nos jours, la capacité à trouver les informations d’une manière rapide

et claire nécessite une recherche. Cependant, il existe une diversité des
formats et des manières dont l’utilisateur peut exprimer ses besoins sans
une complexité. Donc notre idée se concentre sur la recherche intelligente
73
qui aide les utilisateurs de la plateforme à extraire rapidement et facilement

les informations dont ils ont a besoin. Les données saisies manuellement
par l’utilisateur ne sont pas toujours écrites correctement et grâce à ce type
de recherche il peut trouver les documents cherchés promptement. Dans la
recherche avancée on applique la recherche phonétique ayant pour objectif
la correspondance exacte de deux chaines.
5.2.6.2 Problématique
Comment on va concevoir un système de recherche avancée dans notre

projet qui permet de faciliter la recherche de l’utilisateur même si elle est
exprimée incorrectement ?
5.2.6.3 La Valeur Ajoutée
Parmi les avantages principaux de la recherche intelligente on peut citer :

— Le gain de temps.
— la réduction des risques de saisies incorrectes : l’employé peut saisir les
informations incorrectement donc cette recherche anticipe ses risques
et résout les problèmes.
— L’accès instantané aux informations pertinentes.
5.2.6.4 Les processus existants
•Le processus de la normalisation :la normalisation est un ensemble

global des normes et des règles appliquées sur des chaines. Ses règles dé-
pendent du besoin de l’activité qui va être appliquée sur deux chaines où
on va employer notre test et calcul. Le but de cette pratique est d’optimiser
le résultat réduire le risque de ne pas obtenir les documents cherchés. C’est
le fait de standardiser les données en identifiants les ponts de similarité et
de différence.
•le processus de comparaison : Le processus de comparaison dans la

recherche avancée implique la comparaison de deux chaines ( une de ces
chaines est saisie incorrecte et l’autre qui est correcte) : Cette comparai-
son engage l’utilisation des méthodes et des algorithmes de comparaison à
distance spécifiques pour tester la similarité entre eux.
Dans la partie suivante nous allons entamer les détails des algorithmes et
des méthodes appliqués.
74
5.2.6.5 les algorithmes utilisés
Algorithmes Avantages
Cet algorithme est utilisé pour la vérification

orthographique et la correspondance
approximative des chaines. On utilise souvent cet
Levenshtein Distance algorithme quand les deux chaines sont de
[4] longueurs différentes. Il capture le nombre
minimum de modifications possibles pour un seul
caractère(insertion , substitution ou suppression)
pour transformer la chaine en une autre.
Cet algorithme est connu par la vérification

orthographique c’est à dire il est similaire à
Damerau-Levenshtein l’algorithme précédent mais il prend en compte la
Distance : transposition des caractères adjacents. Il est utile
pour les fautes de frappe de saisie de données.
On applique cet algorithme dans les longues

paragraphes. C’est-à-dire la mesure de la
NGram Distance similarité entre deux chaines en fonction de leurs
sous-séquences en commun et de même longueur.
On emploie cet algorithme généralement pour la

correspondance de nom. C’est à dire, il se
Smith-Waterman [5] concentre sur la similarité phonétique des mots
courts qui se ressemblent mais qui peuvent être
orthographiés différemment.

Editex description.
Il est plus précis que Editex puisqu’il peut

encoder des noms multilingues. Cet algorithme a
Extended Editex pour but l’amélioration de Editex en prenant en
charge l’amélioration des fonctionnalités
phonétiques supplémentaires.
75
Algorithme Avantages
Le principe de cet algorithme est le

regroupement des documents. Il est basé sur la
Jaccard Distance [6] mesure de l’intersection de deux ensembles sur
leur union. Il est généralement utile pour les
taches d’ordre non important.
Cet algorithme a le même principe que Jaccard

Distance mais il est plus flexible et amélioré
Extended Jaccard puisqu’il prend en compte l’amélioration des
Distance fonctionnalités supplémentaires telles que la
normalisation de la longueur des documents pour
bien préciser le résultat.
Cet algorithme est renommé par la liaison des

enregistrements. Il mesure la similarité entre les
chaînes, en tenant compte à la fois du nombre de
Jaro-Winkler caractères correspondants et des positions des
Distance correspondances. On peut l’utiliser pour la
comparaison des chaines courtes ou des
Id(identifiant)
Cet algorithme s’appuie sur la comparaison entre

les éléments de deux ensembles ce qui le rend
Monge-Elkan utile pour la correspondance des enregistrements
avec une variété d’éléments.
Cet algorithme est caractérisé par la recherche de

Longest Common la plus longue sous-séquence entre deux chaines.
Subsequence : Il détecte les similitudes entre eux même lorsqu’il
y a des supresssions dans les chaines.
On identifie cet algorithme par sa mesure de la

similarité entre deux ensembles tout en
considérant la taille de leur intersection par
Dice Coefficient [7] rapport à la taille des ensembles. Il est utile
souvent pour les ensembles d’éléments où il n’ya
pas d’importance pour l’ordre.
76
5.2.6.6 les méthodes utilisées
Méthodes Description
Cette méthode définit une Méthode nommée

City Comparer qui compare la similarité entre
deux noms de villes. On implémente deux noms
City Comparer de villes et on renvoie le score de similarité. Cette
méthode est basée sur l’algorithme de la distance
de Damerau-Levenshtein.
Cette méthode détermine une méthode nommée

CompanyComparer qui compare les deux noms
de deux sociétés. Dans cette méthode normalise
CompanyComparer les noms en retirant les accents et les caractères
spéciaux et convertir tous les mots en minuscule.
Cette méthode s’appuie sur l’algorithme de la
distance de Damerau-Levenshtein.
Cette méthode se qualifie par la comapraison de

deux noms.On normalise les noms en retirant les
accents et les caractères spéciaux tout en
NameComparer convertissant les caractères majuscule en
minuscule. De meme, cette méthode est fondée
sur l’algorithme de la distance de
Damerau-Levenshtein.
5.2.6.7 Conclusion
En synthèse, dans la recherche avancée, le processus de comparaison de

deux chaines s’appuie sur l’importance de l’utilisation des algorithmes à
distance et des méthodes bien définies pour évaluer la similarité entre les
chaines et pour améliorer l’expérience de la recherche pour l’utilisateur.
77

crées tout au long du sprint :
Interface "Tableau de bord" : Cette page présente la page du Tableau

de bord pour notre application .
Figure 5.36 – Interface "Tableau de bord "
Interface " Les notifications" : Cette page présente les notifications reçu
pour chaque utilisateur .
Figure 5.37 – Interface "Les notifications "
78
Interface " Barre de recherche avancée " : Cette page présente un

exemple de la recherche avancé comme indique les flèches .
Figure 5.38 – Interface "Barre de recherche avancée "
5.2.8 Test fonctionnel du sprint3

sprint 3 comme représente ce tableau.
Affecter un employé à un
Recevoir une notification ✓
département
Gérer
les notifications Valider un contrat Recevoir une notification ✓
Valider un certificat Recevoir une notification ✓
Afficherauxdétails de cette
Accéder à une notification ✓
notification
79
Afficher la liste des certifi-

Rechercher des certificats
cats et la liste des types de ✓
et des types certificats
Gérer la certificats
recherche
avancée
Afficher la liste des em-
Rechercher des employés ✓
ployés
Rechercher des départe- Afficher la liste des dépar-

ments tements ✓
Afficher la liste des contrats

Rechercher des contrats et
et la liste des types de ✓
des types contrats
contrats
Rechercher des focntionnali- Afficher la fonctionnalité

tés de l’application cherchée ✓
Gérer le Tableau Accéder au tableau de bord Afficher tous les

pour le superviser statistiques ✓
de Bord
Recevoir un mail de valida-

Valider un contrat ✓
tion du contrat
Contrat non validé Aucun mail envoyé ✓
Recevoir un mail de valida-

Valider un certificat ✓
tion du certificat
Gérer les emails Ajouter un employé Recevoir un mail d’ajout ✓
80
Recevoir um mail qui

informe l’utilisateur de
Désactiver un compte ✓
la désactivation de son
compte.
Envoyer un mail qui

Réinitialisation d’un mot contient les nouvelles infor-
de passe mations de réinitialisation ✓
du compte
5.3 Conclusion
Dans ce chapitre la mise en oeuvre du Sprint 3 de notre projet gestion
des contrats a été achevé avec succès.
Durant ce chapitre nous avons présenté notre sprints backlog , les dia-
grammes utilisés de ce sprint,nous avons expliqué les algorithmes utilisée
dans la partie de recherche.
Aussi , nous avons exposé les réalisations achevées et on cloture ce chapitre
par des tests fonctionnels de ce sprint.
81
Conclusion Générale et Perspectives
Tout au long de ce rapport , qu’on espère satisfaisant , nous avons pré-

senté le travail qu’on a realisé et les phases que nous avons passées dans
le cadre du projet de fin d’études de notre licence fondamentale en infor-
matique et multimédia à l’Institut supérieur des Arts Multimédia de la
Manouba .
Ce travail représente le fruit de notre stage au sein de l’entreprise "Ijeni"

durant trois mois qui a été supervisé par Mr. Marouen Kachroudi et Mr.
Dhia Snoussi.
Afin d’assurer que la communication entre l’application client(client

app) et le côté serveur (server side) soit bien sécurisée, après la phase
d’authentification, le service principal va générer un JWT que l’applica-
tion client utiliserait dans sa requête http comme identifiant pour vérifier
l’identité de l’utilisateur via le middleware d’autorisation.
En conclusion , notre projet est une application web interne développée
par Angular en tant que framework front-end et .Net en tant que frame-
work backend. Cette application web consiste à gérer les documents et les
signatures électroniques.L’analyse approfondie exploitée sur les sites déja
existants qui fournient des services similaires et en se basant sur ces sites
nous avons intégré notre empreinte dans ce travail en ajoutant des fonction-
nalités telles que le tableau de bord. Les filtres de dates nous permettent
de personaliser l’expérience de gestion de contrat.
Le service de mailing et de notification ont favorisé la collaboration en

permettant de suivre les nouveautés et de recevoir les mises à jour en temps
réel.
Nous avons opté pour une barre de recherche avancée. La mise en place
de cette barre présente des avantages bien précis. Elle nous a permis de
filtrer les recherches d’une manière rapide et plus efficace ce qui conduit au
82
Chapitre 4 Conclusion Générale et Perspectives
gain de temps car l’utilisateur a la possibilité de trouver ce qu’il est entrain

de chercher même s’il a mal orthographié.
Sur le plan professionnel , cette expérience a été une excellente oppor-

tunité pour nous pour pratiquer et apprendre des nouvelles technologies et
méthodologies comme DevOps.Etant donné l’importance de la sécurité de
notre travail nous avons opté pour le stockage des données dans un serveur
Cloud.
En ce qui concerne les perspectives d’avenir , notre vision est de dé-

velopper d’autres fonctionnalités de l’historique des recherches faites par
l’utilisateurs , l’implémentation d’autres algorithmes avancées pour la re-
cherche et la traduction des documents et finalement la création de signa-
ture personnalisée.
83
Webographie
Webographie
[1 ] https://www.zucisystems.com/be/blog/quand-choisir-
net-comme-plateforme/ [consulté le 29/01/2024]
[2 ] https://angular.fr/ [consulté le 05/02/2024]
[3 ] https://appmaster.io/fr/news/angulaire-17devoile-des-
puissantes-qui-revolutionnent-ledeveloppement-web [consulté
le 05/02/2024]
[4 ] https://www.baeldung.com/cs/levenshtein-distance-computation
[consulté le 22/04/2024]
[5 ] https://fr.wikipedia.org/wiki/Algorithme_de_Smith-Waterman
[3 ] https://pyshark.com/jaccard-similarity-and-jaccard-distance-
in-python/ [consulté le 26/04/2024]
[7 ] https://radiopaedia.org/articles/dice-similarity-coefficient
84
Annexe
Annexe
Algorithmes Calcul de la distance
"kfahim" et "allrl" : Insérer un ’l’ au début :

"lkfahim" → 1 édition Remplacer ’k’ par ’l’ :
"lfahim" → 1 édition Supprimer ’f’ : "lahim" → 1
Levenshtein Distance édition Remplacer ’a’ par ’r’ : "lrhim" → 1 édition
Insérer ’l’ à la fin : "lrhiml" → 1 édition Distance
de Levenshtein = 4
"garden" et "gardner" :
Damerau-Levenshtein Insérer ’e’ après ’r’ : "gardener" → 1 changement
Distance : Remplacer ’d’ et ’e’ : "gardener" → 1 changement
distance de Damerau-Levenshtein = 2
"night" et "sight" :
"night" : "ni", "ig", "gh", "ht"
"sight" : "si", "ig", "gh", "ht"
NGram Distance En commun"ig", "gh", "ht"
distance NGram = (3 en communs 2-grams) / (8
total 2-grams) = 0.375
"ACCTGAGCTCACCTGAGTTA" et
"ACCTTAGGCTCACCTTAGGTA" :
Smith-Waterman ACCTGAGCTCACCTGAGTTA ||| |||||
ACCT–TAGGCTCACCT–TAGGTA
le meilleur alignement local est : 16
"John" et "Jon" :
codage phonétique :”jn” pour les deux noms
Editex Distance de Editex : 0(les noms sont
phonétiquement similaires)
85
Annexe
Algorithme Calcul de la distance
"Sara" et "Sarah" :
codage phonétique : "SR" pour les deux noms
Extended Editex distance Extended Editex = 0(les noms sont
phonétiquement similaires)
4, 8, 9 et 4, 8, 1 :
Éléments communs : 4,8 - Union : 4,8,9,1 -
Jaccard Distance Distance Jaccard = (2 éléments communs) / (4
éléments totaux) = 0,5
4, 8, 9 et 4, 8, 1 :
Extended Jaccard avec pondération TF-IDF : - Distance Jaccard
Distance étendue = 0,21 (en tenant compte de la fréquence
des termes et de la longueur du document)
"MARTHA" et "MARHTA" :
Jaro-Winkler Distance de Jaro-Winkler = 0,944 (forte
Distance similarité à cause au faible nombre de
transpositions).
« John » et « Jonathan » et entre « Doe » et «

Monge-Elkan Doherty »
Monge-Elkan = 0,83 (similitude moyenne ).
Longest Common "ABCBDAB" et "BCBDAC" :

Subsequence : La séquence la plus longue : BCBD
7, 8, 5 et 7, 8, 1 :
Dice Coefficient Coefficient de dice= 0,67 (2 éléments communs
sur 5 éléments totaux).
86
Annexe
Résumé
Dans le cadre de projet de fin d’étude de notre licence fondamentale

en informatique et multimédia , nous avons achevé au sein de la startup "
Ijeni " dans l’objectif de trouver des solutions pour la gestion des contrats
et des signatures électroniques .
Pour bien réaliser notre projet qui contient une variété de fonctionnali-
tés comme le tableau de bord , la gestion des dépatements , des contrats ,
des certificats et la recherche avancée .
Nous avons commencé par une analyse approfondie sur les sites exis-
tants et on a dégagé nos besoins pour cette applictation web , par la suite
nous avons choisi d’adopter l’esprit Agile avec le framework scrum pour
bien gestiobner le travail collaboratif , le gain du temps et l’amélioration
de la qualité du développement avec Azure DevOps.
Mot clés : Application web, API Rest, gestion des documents, scrum,
recherche avancée.
Abstract
As part of our final project for our fundamental degree in computer

science and multimedia, we completed our work within the startup "Ijeni"
with the goal of finding solutions for contract management and electronic
signatures.
To successfully carry out our project, which includes a variety of fea-

tures such as the dashboard, department management, contracts, certifi-
cates, and intelligent search.
We started with a thorough analysis of existing sites and identified our

needs for our web application Then, we chose to adopt the Agile soft-
ware development method, along with the Scrum framework, to effectively
manage collaborative work, and improve development quality with Azure
DevOps.
Key Words :Web application, Rest API, document management, scrum,

intelligent search.
87

rapportv3

Transféré par

Droits d'auteur :

Formats disponibles

rapportv3

Transféré par

Informations du document

Copyright

Formats disponibles

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 :

Formats disponibles

rapportv3

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement Supérieur et de la Recherche

Projet de Fin d’Études

CODE PFE : 103-2024

Conception et dévlopppement d’une

Année universitaire : 2023/2024

Je dédie ce projet à ma famille

Pour ma chère mère, rien ne peut exprimer mon admiration.Tu m’as

Pour mon binome, pour sa sympathie et son soutien durant ce projet.

Je dédie ce projet à ma famille :

À mes chers parents , votre soutien illimité et votre amour inconditionnel

À mon frère,pour ton soutien et tes conseils précieux , je te souhaite un

À mon binôme de ce projet,travailler à tes côtés a été une source de

Avant tout développement de cette expérience professionnelle, nous vou-

Egalament,il est notre désir d’exprimer nos profondes gratitudes à notre

Nous remercions vivement notre encadrant dans l’entreprise Ijeni, Mr

Nous remercions tout le personnel de Ijeni pour son accueil chaleureux

CRM : Customer Relationship Management

1 Présentation globale du cadre du projet 3

2 Planification et Cadre technique du projet 15

3 Mise en œuvre du sprint1 37

3.2.7 Test fonctionnel du sprint1 . . . . . . . . . . . . . 48

4 Mise en œuvre du sprint2 51

5 Mise en œuvre du sprint3 66

Conclusion Générale et Perspectives 82

1.1 Page d’accueil de PandaDoc . . . . . . . . . . . . . . . . . 4

4.32 Interface "Ajouter une singature" . . . . . . . . . . . . . . 62

1.1 Analyse graphique de PandaDoc . . . . . . . . . . . . . . . 5

De nos jours avec les avancées technologiques vécues, nous remarquons

Dans le cadre de la gestion des contrats et pour la garantie de la cohé-

L’amélioration des pratiques de gestion des contrats dans le domaine

En vue de l’obtention de la licence nationale en Informatique et Mul-

d’études qui consiste à concevoir et développer une application web pour

Le présent rapport comporte cinque chapitres répartis comme suit :

Un deuxième chapitre intitulé “ Planification et Cadre technique du

Un troisième chapitre intitulé “ Mise en œuvre du sprint1 ” constitue le

Un quatrième chapitre intitulé “ Mise en œuvre du sprint2 ” qui vise

On clôture notre projet par un dernier chapitre nommé “ Mise en œuvre

Nous terminons notre présent rapport par une conclusion et quelques

Présentation globale du cadre du projet

1.2 Présentation de l’organisme d’accueil :Ijeni

Elle offre une variété de services allant des services de nettoyage et de

L’objectif d’Ijeni est de simplifier l’accès aux services locaux de qualité

1.3 Etude de l’existant

Et finalement, nous extrayons les avantages et les inconvénients de

Figure 1.1 – Page d’accueil de PandaDoc

1.3.2.2 Analyse graphique

Dans cette partie, nous analyserons les éléments graphiques de Panda-

PandaDoc est entièrement Il est reconnaissable par sa

PandaDoc a une structure

Table 1.1 – Analyse graphique de PandaDoc

1.3.2.3 Analyse technique

Pour le développement front-end, JavaScript est le principal langage

1.3.2.4 Analyse fonctionnelle

Cette plateforme offre des fonctionnalités solides, telles que la création

Figure 1.2 – Page d’accueil de NGSIGN

En 2016, la plateforme NGSign a été créée en Tunisie. C’est une solution

1.3.3.2 Analyse graphique

Nous effectuerons une analyse graphique étudiée comme indiquer dans

Logo NGSign utilise une com-

Composition l’utilisation des rectangles Les formes géométriques