Université Assane Seck De Ziguinchor

UFR Des Sciences et Technologies

Mémoire de fin d’études

Pour l’obtention du diplôme de Master

Mention : Informatique

Spécialité : Génie Logiciel

Sujet :

Conception et implémentation du module de gestion des

recrutements à l’Université Assane Seck de Ziguinchor

Soutenu le : 19 /04/2025

Présenté par : Sous la direction de :

M. Moustapha DRAME Pr Ibrahima DIOP

Maître de stage :

Mme Ana BAKHOUM DIANGAR

Membres du jury
Pr Youssou DIENG Professeur assimilé Président UASZ
M. Camir A. N. MALACK Doctorant Rapporteur UASZ
Dr Papa Alioune CISSE Maître de conférences titulaire Examinateur UASZ
Pr Ibrahima DIOP Professeur assimilé Encadrant UASZ
Mme Ana BAKHOUM Ingénieur à la DISI Invitée UASZ
DIANGAR

Année scolaire 2023-2024

Dédicaces

Dédicaces

Par la grâce d'Allah, le Tout-Puissant, je dédie ce travail :

À la mémoire de mon père,

dont l'amour et les enseignements continuent de guider mes pas. Vous avez été un modèle de
courage et de dévouement, et je vous suis éternellement reconnaissant pour tout ce que vous
m'avez transmis. Que ce mémoire soit un hommage à votre amour et à votre sacrifice.

À ma très chère maman,

pilier de ma vie, dont la force et la bienveillance m'ont toujours soutenu. Vous êtes une mère
exemplaire, et je vous dédie ce travail avec toute ma gratitude et mon amour filial. Que vous
soyez fière de moi, et que Dieu vous comble de bonheur, de santé et d'une longue vie.

À ma famille,

source de joie et de soutien, et plus particulièrement à mon grand frère, Mr. Khadim
DRAME, pour sa présence rassurante et ses conseils précieux. Que notre union et notre
solidarité perdurent, fidèles aux valeurs transmises par nos parents.

À mes amis,

pour leurs encouragements et leur amitié sincère, qui ont été une source de motivation
constante.

M. Moustapha DRAME Mémoire Master II Génie logiciel

I
Remerciements

Remerciements

Tout d'abord, je rends grâce à Allah (SWT), le Tout-Puissant, pour m'avoir accordé la force et
la persévérance nécessaires pour réussir ce travail. Que la paix et la bénédiction soient sur Son
noble Prophète Seydina Mouhamed (PSL).

Je tiens à exprimer ma sincère reconnaissance envers mon encadrant, Pr Ibrahima DIOP, pour
sa guidance experte, sa patience et son soutien inébranlable. Son dévouement et son humanité
ont été une source d'inspiration constante pour moi.

Je tiens à exprimer ma reconnaissance à mon maître de stage, Mme Anna BAKHOUM, pour
son précieux encadrement, ses conseils avisés et son soutien constant. Je remercie également
l’ensemble des membres de la DISI (M. Makane MBAYE, M. Serigne NDOUR, M. Dame
BA et Mme Diariatou MANGA SANE) pour leur contribution et leurs conseils.

Mes vifs remerciements vont aussi aux membres du jury, Pr Youssou DIENG, Président du
jury, pour l'honneur que vous me faites en présidant cette soutenance et pour l’attention portée
à mon mémoire, M. Camir A. N. MALACK, rapporteur, pour votre lecture attentive, Dr Papa
Alioune CISSE, examinateur, sa lecture assidue.

Un merci spécial à M. Diambar SENE, ingénieur informaticien et développeur senior chez

Yaatout SARL, pour son expertise technique et son soutien précieux tout au long de ce projet.

Mes plus sincères remerciements vont à mes parents, mon défunt père Mame Kandji DRAME
et ma mère Rokhy CISSE, pour leur amour inconditionnel, leur soutien constant et les valeurs
qu'ils m'ont transmises, sans lesquels je n'aurais pu atteindre ce niveau.

À mes frères et sœurs, dont le soutien et l’affection ont été une source de force intarissable, je
tiens à exprimer toute ma gratitude.

Je remercie également mes camarades de promotion pour leur esprit de collaboration et leur
amitié tout au long de notre parcours universitaire.

M. Moustapha DRAME Mémoire Master II Génie logiciel

II
Résumé

Résumé

Dans le cadre du Projet de Gestion Intégrée (PGI) de la Direction de l'Informatique et des

Systèmes d'Information (DISI) de l'Université Assane Seck de Ziguinchor (UASZ), nous
avons développé une application de gestion des recrutements pour moderniser un processus
auparavant géré manuellement avec des dossiers papier. Ce système traditionnel posait
plusieurs problèmes, notamment la difficulté de conservation des données, la perte
d'informations et l'incapacité à générer des statistiques fiables. Notre objectif était de
digitaliser ce processus pour le rendre plus efficace et fiable.

Pour réaliser ce projet, nous avons opté pour une approche AGILE, en mettant
particulièrement l'accent sur la méthode SCRUM. Cette méthode nous a aidés à favoriser le
travail en commun avec les parties concernées et à procéder de manière itérative, en ajustant
rapidement nos actions selon les exigences et les retours d'information. La première phase a
consisté à déterminer les exigences, durant laquelle nous avons identifié les utilisateurs
principaux et fractionné le module en sous-modules, avant d'élaborer les scénarios d'usage
correspondants.

Lors de la phase de conception, nous avons adopté une stratégie « contract-first », utilisant
OpenAPI et Swagger pour établir les contrats d'API dès le début du processus. Nous avons
également utilisé des schémas UML (cas d'utilisation, séquences, classes) et l'application
StarUML pour représenter visuellement l'architecture du système.

Sur le plan technique, nous avons choisi React pour le développement du Front-end, dans une
architecture microservices, permettant de garantir une meilleure modularité et la scalabilité.
Pour le Back-end, nous avons utilisé Spring Boot, suivant une architecture en couches, et
PostgreSQL comme système de gestion de base de données afin d'assurer une gestion fiable et
performante des données. Les API REST ont été développées pour faciliter la communication
entre les différents services, documentées avec OpenAPI et rigoureusement testées avec
Postman. Pour le design de l'interface, nous avons exploité un template React fourni par la
DISI, créant ainsi une interface utilisateur moderne et cohérente. Enfin, afin de garantir une
collaboration fluide et une gestion efficace des versions, nous avons utilisé Git.

M. Moustapha DRAME Mémoire Master II Génie logiciel

III
Abstract

Abstract

As part of the Integrated Management Project (PGI) of the IT and Information Systems
Department (DISI) of the Assane Seck University of Ziguinchor (UASZ), we developed a
recruitment management application to modernize a process previously managed manually
with paper files. This traditional system posed several problems, including difficulties in data
preservation, loss of information, and the inability to generate reliable statistics. Our goal was
to digitize this process to make it more efficient and reliable.

To carry out this project, we opted for an AGILE approach, placing particular emphasis on the
SCRUM method. This method helped us foster collaboration with stakeholders and proceed
iteratively, quickly adjusting our actions according to requirements and feedback. The first
phase involved determining the requirements, during which we identified the main users and
broke down the module into sub-modules, before developing the corresponding use scenarios.

During the design phase, we adopted a "contract-first" strategy, using OpenAPI and Swagger
to establish API contracts from the early stages of the process. We also employed UML
diagrams (use cases, sequences, classes) and the StarUML application to visually represent
the system architecture.

Technically, we chose React for Front-end development, in a microservices architecture,

allowing for better modularity and scalability. For the back-end, we used Spring Boot,
following a layered architecture, and PostgreSQL as the database management system to
ensure reliable and efficient data management. REST APIs were developed to facilitate
communication between the various services,documented with OpenAPI, and rigorously
tested with Postman. For the interface design, we leveraged a React template provided by
DISI, thus creating a modern and cohesive user interface. Finally, to ensure smooth
collaboration and effective version management, we used Git.

M. Moustapha DRAME Mémoire Master II Génie logiciel

IV
Table des matières

Table des matières

Dédicaces ................................................................................................................ I

Remerciements ..................................................................................................... II

Résumé ................................................................................................................ III

Abstract................................................................................................................ IV

Table des matières ................................................................................................ V

Liste des Figures .................................................................................................. IX

Liste des Tableaux ............................................................................................. XII
Liste des Acronymes ........................................................................................ XIII

Introduction Générale .......................................................................................... 14

Chapitre I : Contexte du stage ............................................................................. 15

Introduction ...................................................................................................... 15

I. La Direction de l'Informatique et des Systèmes d'Information (DISI) .. 15

1 Missions .................................................................................................. 15

2 Organisation ............................................................................................ 16

II. Projet PGI ............................................................................................... 18

III. Problématique ......................................................................................... 19

IV. Objectifs .................................................................................................. 19

Conclusion ........................................................................................................ 20

Chapitre II : Architectures logicielles et méthodologiques ................................. 21

Introduction ...................................................................................................... 21

M. Moustapha DRAME Mémoire Master II Génie logiciel

V
Table des matières

I. Types d'architectures logicielles ............................................................. 21

1 Architectures monolithiques ................................................................... 21

2 Architectures orientées services (SOA en anglais) ................................ 24

3 Architecture microservices ..................................................................... 27

II. Comparaison entre l’architecture monolithique et les microservices .... 30

III. Méthodologies de développement .......................................................... 31

1 Méthodes classiques ............................................................................... 31

2 Méthodes agiles ...................................................................................... 34

IV. DevOps, CI /CD...................................................................................... 39

1 Culture DevOps ...................................................................................... 39

2 Intégration continue/livraison continue (CI/CD).................................... 40

3 Contract-first avec OpenApi et SwaggerHub ......................................... 40

V. Choix de la méthode et justification ....................................................... 42

Chapitre III : Spécification, analyse des besoins et conception des APIs .......... 44

I. Spécification et analyse des besoins ....................................................... 44

1 Spécification et analyse des besoins de l’API Authenfication-service .. 44

2 Spécification et analyse des besoins de l’api UsersDétails-service ....... 49

3 Spécification et analyse des besoins de l’API AppelCandidature-api ... 57

4 Spécification et analyse des besoins de l’api Candidature-service ........ 62

M. Moustapha DRAME Mémoire Master II Génie logiciel

VI
Table des matières

5 La spécification et analyse des besoins de l’api Selection-api ............... 67

II. Conception des APIs............................................................................... 71

1 Éléments de notre architecture ............................................................... 72

2 Architecture générale de la solution ....................................................... 74

III. Conception détaillée des APIs ................................................................ 75

1 Conception de l’API Authentification-service ....................................... 75

2 Conception de l’API UsersDétails-service ............................................. 76

3 Conception de l’api AppelCandidature-api ............................................ 78

4 Conception de l’api Candidature-service ............................................... 80

5 La conception de l’api selection-api ....................................................... 81

Conclusion ........................................................................................................ 82

Chapitre IV : Implémentation et présentation de l’application ........................... 83

INTRODUCTION............................................................................................ 83

I. Présentation des outils de modélisation et de développement ............... 83

1 StarUML ................................................................................................. 83

2 IntelliJ IDEA ........................................................................................... 83

3 SwaggerHub............................................................................................ 83

4 Postman ................................................................................................... 84

5 Git ........................................................................................................... 84

M. Moustapha DRAME Mémoire Master II Génie logiciel

VII
Table des matières

II. Implémentation du Back-end.................................................................. 85

1 Apache Tomcat ....................................................................................... 85

2 Java ......................................................................................................... 85

3 Spring ...................................................................................................... 86

4 Spring Boot ............................................................................................. 86

5 API REST ............................................................................................... 87

6 PostgreSQL ............................................................................................. 87

III. Implémentation du Front-End ................................................................ 87

1 React.js .................................................................................................... 87

2 Bootstrap ................................................................................................. 88

IV. Présentation de l’application................................................................... 88

1 Graphe de navigation de l’application .................................................... 89

2 Présentations des pages........................................................................... 90

Conclusion ........................................................................................................ 92

Conclusion Générale ........................................................................................... 93

Bibliographie ....................................................................................................... 94

M. Moustapha DRAME Mémoire Master II Génie logiciel

VIII
Liste des Figures

Liste des Figures

Figure 1: Organisation de la DISI ............................................................................................ 16

Figure 2: Architecture monolithique [1] .................................................................................. 22

Figure 3: Architectures orientées services ............................................................................... 25

Figure 4 : Architecture microservice ........................................................................................ 27

Figure 5 : Méthode en cascade ................................................................................................. 32

Figure 6 : Méthode du cycle en V ............................................................................................ 33

Figure 7 : Méthodes agiles ....................................................................................................... 35

Figure 8 : Scrum [6] ................................................................................................................. 36

Figure 9 : Exemple Kanban [6] ................................................................................................ 37

Figure 10 : Méthode Lean [6] .................................................................................................. 39

Figure 11 : Extrait 1 de la spécification de l’api authentification ............................................ 45

Figure 12 : Extrait 2 de la spécification de l’api authentification ............................................ 45

Figure 13 : Quelsques endpoints de l’API authentification ..................................................... 46

Figure 14 : Diagramme de cas d’utilisation de l’api Authentification-service ........................ 47

Figure 15 : Diagramme de séquence du cas d’utilisation « s’authentifier » ............................ 49

Figure 16 : Extrait 1 de la spécification de l’api userDetails-service ....................................... 50

Figure 17 : Extrait 2 de la spécification de l’api userDetails-service ....................................... 50

Figure 18 : Extrait 3 de la spécification de l’api userDetails-service ....................................... 50

Figure 19 : Quelques Endpoints de l’API UserDetails-service ................................................ 53

M. Moustapha DRAME Mémoire Master II Génie logiciel

IX
Liste des Figures

Figure 20 : Diagramme de cas d’utilisation de l’api UserDetails-service ................................ 54

Figure 21 : Diagramme de séquence du cas « modifier ses informations » ............................. 57

Figure 22 : Extrait 1 de la spécification de l’api AppelCandidature-api .................................. 58

Figure 23 : Extrait 2 de la spécification de l’api AppelCandidature-api .................................. 58

Figure 24 : Quelques Endpoints de l’API AppelCandidature-api ............................................ 59

Figure 25 : Diagramme de cas d’utilisation de l’api AppelCandidature-api ............................ 60

Figure 26 : Diagramme de séquence du cas d’utilisation « créer un appel » ........................... 62

Figure 27 : Extrait 1 de la spécification de l’api candidature-service ...................................... 63

Figure 28 : Extrait 2 de la spécification de l’api candidature-service ...................................... 63

Figure 29 : Quelques endpoints de l’api candidature-service .................................................. 64

Figure 30 : Diagramme du cas d’utilisation de l’api candidature-service................................ 65

Figure 31 : Diagramme de séquence du cas d’utilisation « soumettre une candidature » ...... 67

Figure 32 : Extrait 1 de la spécification de l’api Selection-api ................................................ 67

Figure 33 : Extrait 2 de la spécification l’api Selection-api ..................................................... 68

Figure 34 : Quelques Endpoints de l’api Selection-api ............................................................ 69

Figure 35 : Diagramme de cas d’utilisation de l’api Selection-api .......................................... 69

Figure 36 : Diagramme de séquence du cas d’utilisation « évaluer les candidatures » ........... 71

Figure 37 : Architecture globale du système ............................................................................ 74

Figure 38 : Diagramme de classe de l’api Authentification ..................................................... 75

Figure 39 : Schéma de données de l’api authentification ......................................................... 76

Figure 40: Diagramme de classes du service UserDetails-service ........................................... 77

M. Moustapha DRAME Mémoire Master II Génie logiciel

X
Liste des Tableaux

Figure 41: schéma de données de l’api UserDetails-service .................................................... 78

Figure 42: Diagramme de classes de l’api AppelCandidature-api ........................................... 79

Figure 43 : Le schéma de donné de l’api AppelCandidature-api ............................................. 80

Figure 44 : diagramme de classe de l’api candidature-service................................................. 80

Figure 45 : Schéma de données de l’api candidature-service .................................................. 81

Figure 46 : diagramme de classe de l’api selection-api............................................................ 81

Figure 47 : schéma de données de l’api selection-api .............................................................. 82

Figure 48 : Graphe de navigation de l’application ................................................................... 89

Figure 49 : Page d'accueil Principale ....................................................................................... 90

Figure 50 : page d’accueil de l’administrateur ......................................................................... 91

Figure 51 : Page d’accueil du candidat .................................................................................... 92

M. Moustapha DRAME Mémoire Master II Génie logiciel

XI
Liste des Tableaux

Liste des Tableaux

Tableau 1 : Comparaison des architectures monolithique, orientée services et microservice . 30

Tableau 2 : Description du cas d’utilisation « s’authentifier » ................................................ 47

Tableau 3 : les acteurs intervenants dans l’api UserDetails-service ........................................ 52

Tableau 4 : Description du cas d’utilisation « modifier ses informations » ............................. 55

Tableau 5 : Les différents acteurs intervenant dans l’api AppelCandidature-api .................... 58

Tableau 6 : Description du cas d’utilisation « créer un appel » ............................................... 60

Tableau 7 : Les différents acteurs intervenants dans l’api candidature .................................... 63

Tableau 8 : Description du cas d’utilisation « soumettre une candidature » ............................ 65

Tableau 9 : Les différents acteurs de l’api Sélection-api ......................................................... 68

Tableau 10 : Description du cas d’utilisation « évaluer les candidatures » ............................. 70

M. Moustapha DRAME Mémoire Master II Génie logiciel

XII
Liste des Acronymes

Liste des Acronymes

API : Application Programming Interface

CI/CD: Continuous Integration / Continuous Delivery & Deployment

DRH : Direction des Ressources Humaines

HTTP: HyperText Transfer Protocol

IDE: Integrated Development Environment

PATS : Personnel Administratif Technique et Service

PER : Personnel Enseignant et de Recherche

PGI : Projet de Gestion Intégrée

REST: REpresentational State Transfer

RH: Ressources Humaines

SOA : Architectures Orientées Services

SCS : Service de Calculs et Simulations

SRP : Service des Ressources Pédagogiques

SST : Service de Support et Technique

UI : Interface utilisateur

UML : Unified Modeling Language

M. Moustapha DRAME Mémoire Master II Génie logiciel

XIII
Introduction Générale

Introduction Générale

Dans un environnement universitaire en constante évolution, le recrutement représente un

défi majeur. À l’Université Assane Seck de Ziguinchor (UASZ), les processus traditionnels
encore en place ralentissent la sélection des candidats et augmentent la charge de travail des
ressources humaines. Face à cette situation, une modernisation s’impose pour garantir un
traitement plus rapide et efficace des candidatures.

Imaginez un responsable des ressources humaines submergé par des dossiers papier, jonglant
entre différentes étapes de validation, avec un risque élevé d’erreurs et une perte de temps
considérable. De l’autre côté, des candidats impatients, parfois sans retour sur leur
candidature, faute de suivi clair et transparent. Ces difficultés soulignent le besoin urgent d’un
système de gestion des recrutements moderne, automatisé et efficace.

C’est dans cette optique que nous avons entrepris ce projet : concevoir et implémenter un
module de gestion des recrutements qui digitalise et fluidifie l’ensemble du processus, depuis
la soumission des candidatures jusqu’à la sélection finale. Pour garantir modularité,
évolutivité et performance, nous avons fait le choix d’une architecture basée sur les
microservices, une approche qui permet une gestion flexible et évolutive des différentes
fonctionnalités du système.

Ce mémoire est structuré en 4 chapitres. Le chapitre I présente le contexte et les

problématiques spécifiques au recrutement à l’UASZ. Dans le chapitre II, nous explorons les
architectures logicielles et les différentes méthodologies de développement logiciel. Le
chapitre III détaille la spécification, l’analyse des besoins et la conception des API essentielles
du module. Enfin, dans le chapitre IV, nous décrivons les technologies utilisées pour
l’implémentation avant de terminer par une présentation de l’application.

M. Moustapha DRAME Mémoire Master II Génie logiciel

14
 Chapitre I : Contexte du stage

Chapitre I : Contexte du stage

Introduction
Le développement rapide des technologies numériques transforme profondément les
processus de gestion, notamment dans les institutions académiques. L’Université Assane Seck
de Ziguinchor (UASZ) ne fait pas exception, et la nécessité de moderniser ses systèmes de
gestion se fait de plus en plus pressante. Face à une augmentation des candidatures pour des
postes académiques et administratifs, il devient essentiel de disposer d'outils informatiques
capables de gérer efficacement ces processus de recrutement.
Dans ce chapitre, nous présenterons d’abord l’environnement dans lequel s’est déroulé notre
stage, en commençant par une présentation de la Direction de l’Informatique et des Systèmes
d’Information (DISI) de l’UASZ. Nous exposerons ensuite la problématique à laquelle nous
avons été confrontés et les objectifs spécifiques de notre travail.

I. La Direction de l'Informatique et des Systèmes d'Information (DISI)

Créée en 2021 pour remplacer l'ancien Centre des Ressources Informatiques (CRI), la DISI a
pour mission de piloter la transformation numérique de l’Université Assane Seck de
Ziguinchor. Elle assure l’implémentation et le suivi des projets liés aux systèmes
d’information, notamment dans les domaines de la gestion des ressources humaines, de
l’enseignement et de la recherche. La DISI est structurée en trois principaux services : le
Service des Ressources Pédagogiques (SRP), le Service de Support et Technique (SST), et le
Service de Calcul et Simulations (SCS).

1 Missions

Sous l’autorité du Recteur, la DISI est chargée de définir et de mettre en œuvre la politique
numérique de l’Université. Les missions principales de la DISI sont de :
✓ Élaborer et suivre les plans directeurs de l’informatique de l’Université ;
✓ Participer à la réalisation des tableaux de bord et au pilotage de l’institution et de ses
différentes composantes ;
✓ Stimuler, structurer, accompagner et soutenir les projets dans le domaine du calcul
scientifique et de la simulation ;
✓ Développer un système informatique intégré et cohérent ;

M. Moustapha DRAME Mémoire Master II Génie logiciel

15
Chapitre I : Contexte du stage

✓ Assurer une veille technologique pour anticiper les évolutions numériques.

2 Organisation
✓ La DISI est structurée en trois services : le Service des Ressources Pédagogiques
(SRP), le Service de Support et Technique (SST) et le Service de Calculs et
Simulations (SCS). Chaque service est constitué de divisions à sa tête un chef de
division. Les services sont tous sous l’autorité du directeur de la DISI. La figure 1 ci-
dessous représente l’organigramme de la DISI.

Figure 1: Organisation de la DISI

a. Le Service des Ressources Pédagogiques (SRP)

Ce service est chargé de :

✓ Participer à la professionnalisation des étudiants inscrits dans les formations classiques
à l'Université ;
✓ Former et de renforcer les capacités en Technologies de l'Information et de la
communication (TIC) du Personnel Administratif, Techniques et de Service (PATS) ;
✓ Contribuer à la promotion et au développement de la formation en informatique et
télécommunication et leurs applications ;

M. Moustapha DRAME Mémoire Master II Génie logiciel

16
Chapitre I : Contexte du stage

✓ Contribuer à la promotion de l'utilisation des logiciels libres en particulier sur le plan

pédagogique.

b. Le Service de Support et Technique (SST)

Ce service est chargé de :

✓ Assurer la disponibilité des infrastructures réseaux, systèmes et des services ;
✓ Développer un système d'information intégré et cohérent ;
✓ Gérer le portail internet de l'Université en collaboration avec la direction de la
communication et du marketing de l'Université ;
✓ Développer, déployer et maintenir un Environnement Numérique de Travail (ENT) ;
✓ Dématérialiser les procédures administratives de l'Université de concert avec le SRP ;
✓ Contribuer au respect de la charte graphique de l'institution en relation avec les
directions centrales et les différentes composantes de l'Université ;
✓ Assurer le respect des directives institutionnelles liées à la politique informatique
d’achat de matériels, de logiciels et de gestion du parc informatique ;
✓ Gérer l’activité d’assistance de proximité en assurant la remontée des besoins liés au
système d’information et une assistance technique auprès des utilisateurs ;
✓ Administrer le parc informatique en assurant la maintenance et le renouvellement ;
✓ Mettre à la disposition des structures de formation et de recherche les infrastructures
informatiques et les outils nécessaires au bon déroulement de leurs activités.

c. Le Service de Calculs et Simulations (SCS)

Il est chargé de :
✓ Mettre à la disposition de la communauté des plateformes de test, de simulation, de
stockage et de calcul (grilles, cloud, …) ;
✓ Assister la communauté scientifique dans le déploiement d’outils ;
✓ Assurer la prise en charge des besoins en calcul numérique de la communauté
scientifique ;
✓ Assurer le renforcement de capacité des chercheurs sur les outils de recherche
scientifique ;
✓ Accompagner la mise en place de formations par les structures habilitées dans les
domaines du calcul scientifique et du calcul haute performance ;

M. Moustapha DRAME Mémoire Master II Génie logiciel

17
 Chapitre I : Contexte du stage

✓ Mettre en place les outils nécessaires et accompagner les enseignants-chercheurs et les

étudiants dans l’utilisation des plateformes distantes (clusters).

II. Projet PGI

Le projet de gestion intégrée (PGI) est initié par la DISI en collaboration avec la DRH et les
UFRs. Ce projet d'automatisation des tâches administratives dans la gestion du personnel vise
à moderniser et à simplifier les processus administratifs au sein de l'université. Cette initiative
est motivée par le besoin d'optimiser l'efficacité opérationnelle, de réduire les erreurs
humaines et d'accélérer les délais dans le traitement des données liées au personnel. Ce projet
a été lancé à la fin de l'année 2022 et a débuté avec cinq (5) modules :
✓ Le module de gestion des évaluations des enseignements ;
✓ Le module de gestion des emplois du temps : ce module gère la gestion des emplois
du temps des UFRs ;
✓ Le module de gestion de la répartition des enseignements : ce module gère la
répartition des enseignements (cours) pour toutes les formations ;
✓ Le module de gestion de dossier médical : ce module est conçu pour stocker,
organiser et gérer les informations médicales des patients de la Direction de la
Médecine du Travail (DMT) de manière digitale ;
✓ Le module de gestion des ressources humaines : ce module gère certaines
fonctionnalités comme le suivi des dossiers des employés, notamment la gestion des
candidatures au recrutement du PER et du PATS, la gestion des contrats, la gestion
des affectations, la gestion de la promotion, etc.

Actuellement, ce projet est en cours de migration vers une architecture en microservices

depuis septembre 2024. Dans ce cadre, un nouveau module pour la gestion des maquettes
ainsi que des inscriptions administratives et pédagogiques est intégré. Par ailleurs, la gestion
des candidatures, auparavant un sous-module des ressources humaines, devient désormais un
module à part entière, prenant en charge aussi bien les recrutements du personnel enseignant
et de recherche (PER) et du personnel administratif, technique et de service (PATS) que les
sélections en ligne pour les candidatures en master et doctorat.

Notre projet s’inscrit pleinement dans cette évolution en simplifiant et en optimisant les
processus de recrutement et de sélection. L’objectif est de rendre ces démarches plus

M. Moustapha DRAME Mémoire Master II Génie logiciel

18
 Chapitre I : Contexte du stage

accessibles, plus fluides et mieux intégrées aux autres modules du système. Grâce à cette
transformation, nous améliorons non seulement la performance, la maintenance et la sécurité
des services, mais nous offrons aussi une expérience utilisateur plus naturelle, intuitive et
harmonieuse.

III. Problématique

L’Université Assane Seck de Ziguinchor (UASZ) note une augmentation régulière du nombre
de candidatures pour ses postes académiques et administratifs. Cependant, la gestion de ces
candidatures s’appuie encore sur des méthodes traditionnelles, principalement manuelles, ce
qui soulève plusieurs difficultés majeures :
✓ Un processus de recrutement ralenti : Le traitement manuel des dossiers entraîne des
délais importants dans la sélection des candidats, ce qui retarde l’ensemble du
processus et affecte la réactivité de l’université.
✓ Les équipes des ressources humaines, déjà bien occupées, se retrouvent submergées par
le flot constant de candidatures. Cette surcharge de travail pèse lourdement sur leurs
épaules et réduit leur capacité à accorder à chaque candidat l'attention qu'il mérite.
✓ Des risques d’erreurs accrues : La gestion manuelle des dossiers augmente la
probabilité d’erreurs, que ce soit dans la saisie des informations, le classement des
candidatures ou l’évaluation des profils. Ces erreurs peuvent compromettre la qualité
du recrutement.
✓ La non transparence et le manque de clarté : Sans un système numérique structuré,
suivre l’évolution des candidatures devient compliqué. Les recruteurs ont du mal à
savoir où en est chaque dossier, tandis que les candidats restent dans l’attente, sans
réelle visibilité sur le processus. Ce manque de clarté peut créer de l’incertitude et de la
frustration, nuisant à l’équité, l’image de l’institution et à l’efficacité du processus de
recrutement.
✓ Un accès et un suivi compliqués : Sans outils numériques, consulter les informations et
suivre l’évolution des candidatures devient une tâche fastidieuse, ralentissant les prises
de décision et créant des frustrations pour les candidats.

IV. Objectifs

Le projet de gestion des recrutements a pour objectifs de :

M. Moustapha DRAME Mémoire Master II Génie logiciel

19
Chapitre I : Contexte du stage

✓ Automatiser le processus de soumission des candidatures ;

✓ Réduire les délais de traitement des dossiers de candidature ;
✓ Améliorer la transparence et la traçabilité des décisions prises par les commissions de
recrutement ;
✓ Assurer la sécurité des données personnelles des candidats ;
✓ Faciliter la collaboration entre les différents acteurs impliqués dans le processus de
recrutement.

Conclusion

La mise en place d'un logiciel de gestion des recrutements à l'Université Assane Seck de
Ziguinchor contribue à la modernisation des processus administratifs. Après avoir présenté la
structure d’accueil (DISI) et exposé la problématique et les objectifs de notre travail, nous
allons décrire les architectures et choix méthodologiques dans le prochain chapitre (Chapitre
II).

M. Moustapha DRAME Mémoire Master II Génie logiciel

20
 Chapitre II : Architectures logicielles et méthodologiques

Chapitre II : Architectures logicielles et méthodologiques

Introduction

Dans ce chapitre, nous explorerons les architectures logicielles et les méthodologies de

développement logiciel essentielles à la conception et à la modélisation d’une application
efficace. Nous distinguerons trois (3) types d’architectures :
✓ L’architecture monolithique, largement utilisée dans les systèmes traditionnels, avec
ses atouts mais aussi ses limites en termes de flexibilité et d’évolutivité.
✓ L’architecture microservices, qui repose sur des composants indépendants favorisant
la modularité et une gestion plus agile des applications complexes.
✓ L’Architecture Orientée Service (SOA), convient aux environnements d'entreprise
nécessitant une intégration de systèmes hétérogènes et une réutilisabilité des services,
mais peut être complexe à gérer à grande échelle.

Cependant, le choix d’une architecture adaptée ne suffit pas à garantir le succès d’un projet. Il
est tout aussi crucial d’adopter des pratiques modernes pour optimiser le cycle de
développement et de déploiement des applications. Parmi ces pratiques, nous pouvons citer :
✓ DevOps : Une philosophie qui encourage la collaboration entre les équipes,
l’automatisation des processus et une mise en production plus fluide et rapide.
✓ CI/CD : une pratique de génie logiciel qui gère l’intégration et le déploiement
continus.
✓ Contrat-at-first avec OpenApi et swaggerHub, qui facililite la rédaction et le partage
du contrat.

I. Types d'architectures logicielles

1 Architectures monolithiques

Avec les architectures monolithiques, tous les processus sont étroitement couplés et
s'exécutent comme un système unique. Cela signifie que si l'un des processus de l'application
enregistre un pic de demande, toute l'architecture doit être mise à l'échelle. L'ajout ou
l'amélioration de fonctionnalités d'une application monolithique devient plus complexe à

M. Moustapha DRAME Mémoire Master II Génie logiciel

21
Chapitre II : Architectures logicielles et méthodologiques

mesure de la croissance de la base de code. Cette complexité limite les expérimentations et

rend l'implémentation de nouvelles idées difficile. Les architectures monolithiques
augmentent les risques en matière de disponibilité des applications, car de nombreux
processus dépendants et étroitement couplés renforcent l'impact d'un seul échec de
processus[1].

Figure 2: Architecture monolithique [1]

Une application monolithique classique utilise une conception en couches, avec des couches
distinctes [1] :
✓ Interface utilisateur (UI) : c'est la couche qui interagit avec les utilisateurs par le biais
d'écrans, de formulaires, etc. ;
✓ Logique application (Business layer) : elle gère les requêtes http, récupère et met à
jour les données dans les référentiels, remplisse les vues HTML et les envoie au
navigateur :
✓ Couche accès aux données (Data Interface).

a. Structure d’une architecture monolithique

L'architecture monolithique se caractérise par une structure intégrée et cohérente, où toutes les
composantes d'une application fonctionnent ensemble comme une unité unique. Cette
organisation présente plusieurs aspects clés :
✓ Unité unique : une seule application regroupe toutes les fonctionnalités.
✓ Couche unique de base de données : une base de données commune pour tous les
modules.

M. Moustapha DRAME Mémoire Master II Génie logiciel

22
Chapitre II : Architectures logicielles et méthodologiques

✓ Communication interne : tous les modules communiquent directement à l’intérieur de

l'application sans passer par des services externes.

b. Caractéristiques d’une architecture monolithique

Les architectures monolithiques possèdent des caractéristiques distinctes qui définissent leur
fonctionnement et leur structure, impactant ainsi la manière dont les applications sont
conçues, déployées et maintenues. Ces caractéristiques se regroupent ainsi :
✓ Centralisation : Toute la logique métier et la gestion des données sont centralisées.
✓ Monolithisme : L'application dans son ensemble est déployée et mis à jour
simultanément.
✓ Faible modularité : Les composants sont interconnectés et dépendent fortement les uns
des autres.

c. Avantages et limites d’une architecture monolithique

Les organisations peuvent profiter d'une architecture monolithique ou de microservices, en

fonction de différents facteurs. Ainsi nous allons dégager quelques avantages et limites d’une
architecture monolithique [2] :

✓ Avantages d’une architecture monolithique

• Déploiement facile : un seul fichier exécutable ou répertoire facilite le
déploiement ;
• Développement : lorsqu'une application est conçue avec une seule base de code,
elle est plus facile à développer ;
• Performances : dans une base de code et un dépôt centralisé, une API peut
souvent remplir la même fonction que celles assurées par de nombreuses API avec
les microservices ;
• Débogage facile : comme l'ensemble du code est centralisé, il est plus facile de
suivre une demande et de trouver un ticket ;
• Tests simplifiés : étant donné qu'une application monolithique est une unité
centralisée, les tests de bout en bout peuvent être effectués plus rapidement qu'avec
une application distribuée.

✓ Limites d’une architecture monolithique :

M. Moustapha DRAME Mémoire Master II Génie logiciel

23
Chapitre II : Architectures logicielles et méthodologiques

• Vitesse de développement plus lente : une application monolithique

volumineuse complexifie et ralentit le développement ;
• Évolutivité : vous ne pouvez pas mettre à l'échelle des composants individuels ;
• Fiabilité : si une erreur survient dans un module, elle peut affecter la
disponibilité de l'ensemble de l'application ;
• Obstacle à l'adoption de la technologie : les changements apportés au
framework ou au langage affectent l'ensemble de l'application, ce qui les rend
souvent coûteux et chronophages ;
• Manque de flexibilité : un monolithe est limité par les technologies déjà
utilisées en son sein ;
• Déploiement : un changement mineur apporté à une application monolithique
nécessite le redéploiement de l'ensemble du monolithique.

2 Architectures orientées services (SOA en anglais)

L'architecture orientée services (SOA) est un modèle architectural permettant de développer

des systèmes logiciels en créant des services interopérables et faiblement couplés qui
fonctionnent ensemble pour automatiser les processus métier. Un service est une partie d'une
application logicielle qui exécute une tâche spécifique, fournissant des fonctionnalités à
d'autres parties de la même application logicielle ou à d'autres applications logicielles.
Quelques exemples de consommateurs de services incluent les applications Web, les
applications mobiles, les applications de bureau et d'autres services.

Chaque service d'une SOA encapsule un certain élément de logique. Cette logique peut être
responsable d'une tâche très spécifique, d'un processus métier ou d'un sous-processus. Les
services peuvent varier en taille et un service peut être composé de plusieurs autres services
pour accomplir sa tâche[3], [4].

M. Moustapha DRAME Mémoire Master II Génie logiciel

24
Chapitre II : Architectures logicielles et méthodologiques

Figure 3: Architectures orientées services

a. Structure d’une architecture orientée service

La SOA est basée sur une architecture modulaire où les services sont les composants
principaux. Ces services sont autonomes, interopérables et communiquent via des protocoles
standardisés (comme HTTP, SOAP, REST, etc.). La structure typique d'une SOA comprend
[3], [4] :

✓ Services : Unités fonctionnelles indépendantes qui exposent des fonctionnalités via

des interfaces bien définies ;

✓ Bus de services (ESB) : Un middleware qui facilite la communication entre les

services en gérant le routage, la transformation des messages et l'orchestration ;

✓ Registre de services : Un annuaire où les services sont enregistrés et peuvent être

découverts par d'autres composants ;

✓ Consommateurs de services : Applications ou autres services qui utilisent les

fonctionnalités exposées par les services ;

M. Moustapha DRAME Mémoire Master II Génie logiciel

25
Chapitre II : Architectures logicielles et méthodologiques

b. Caractéristiques d’une SOA

Les principales caractéristiques de la SOA sont :

✓ Interopérabilité : Les services peuvent communiquer entre eux, indépendamment des

plateformes ou des langages de programmation ;

✓ Couplage faible : Les services sont indépendants les uns des autres, ce qui permet une
plus grande flexibilité et évolutivité ;

✓ Réutilisabilité : Les services sont conçus pour être réutilisés dans différents contextes
ou applications ;

✓ Granularité : Les services peuvent varier en taille et en complexité, allant de petites

tâches spécifiques à des processus métier complexes ;

✓ Découverte dynamique : Les services peuvent être découverts et invoqués à

l'exécution via un registre de services ;

c. Avantages d’une SOA :

✓ Flexibilité : Permet une adaptation rapide aux changements métier grâce au couplage
faible.
✓ Réutilisabilité : Réduit les coûts de développement en réutilisant les services
existants.
✓ Interopérabilité : Facilite l'intégration de systèmes hétérogènes.
✓ Évolutivité : Permet d'ajouter ou de modifier des services sans impacter l'ensemble du
système.

d. Limites d’une SOA :

✓ Complexité : La mise en œuvre d'une SOA peut être complexe, notamment en raison
de la gestion des services et de l'ESB.

✓ Performance : La communication entre services peut introduire une latence, surtout si

les services sont distribués.

M. Moustapha DRAME Mémoire Master II Génie logiciel

26
Chapitre II : Architectures logicielles et méthodologiques

✓ Sécurité : La gestion des accès et des données sensibles entre services peut poser des
défis.

✓ Coûts initiaux : La conception et la mise en place d'une SOA nécessitent des

investissements importants en temps et en ressources.

3 Architecture microservices

Avec une architecture microservices, une application est développée à l'aide de composants
indépendants, qui exécutent chaque processus de l'application sous forme de service. Ces
services communiquent par le biais d'une interface bien définie et à l'aide d'APIs légères. Les
services sont développés pour des capacités métier, et chaque service exécute une seule
fonction. Étant donné qu'ils sont exécutés de manière indépendante, chaque service peut être
mis à jour, déployé ou mis à l'échelle pour répondre aux demandes des fonctions spécifiques
d'une application.

Figure 4 : Architecture microservice

Les microservices constituent une approche architecturale et organisationnelle du

développement logiciel, dans laquelle le logiciel se compose de petits services indépendants
qui communiquent via des APIs bien définies. Ces services sont détenus par de petites
équipes auto-contenues. Les architectures de microservices simplifient la mise à l'échelle et

M. Moustapha DRAME Mémoire Master II Génie logiciel

27
Chapitre II : Architectures logicielles et méthodologiques

accélèrent le développement des applications, pour des innovations et des délais de mise sur
le marché optimisé [1].

a. Caractéristiques des microservices

Les caractéristiques des microservices sont essentiellement [1] :

✓ Autonomie : tous les services des composants d'une architecture microservices
peuvent être développés, déployés, gérés et mis à l'échelle sans affecter le
fonctionnement des autres services. Les services n'ont pas besoin de partager leur code
ou leur implémentation avec d'autres services. Les composants individuels
communiquent par le biais d'API bien définies ;
✓ Spécialisation : chaque service est conçu pour un ensemble de fonctionnalités et se
concentre sur la résolution d'un problème spécifique. Si les développeurs apportent
plus de code à un service au fil du temps, et que le service devient complexe, ce dernier
peut être fragmenté en services plus petits.

b. Avantages des microservices

Les microservices présentent plusieurs avantages [2] :

✓ Agilité : les microservices favorisent l'organisation de petites équipes indépendantes,
qui s'approprient leurs services. Les équipes agissent au sein d'un contexte de petite
taille et bien compris, et peuvent travailler de manière plus indépendante et rapide.
Cela réduit la durée des cycles de développement. Vous tirez ainsi le meilleur parti des
niveaux de débit cumulés de l'organisation ;
✓ Dimensionnement flexible : les microservices permettent à chaque service d'être mis à
l'échelle de manière indépendante, pour répondre à la demande des fonctionnalités de
l'application prises en charge. Cela permet aux équipes de dimensionner correctement
les besoins de l'infrastructure, de mesurer de manière plus précise les coûts d'une
fonctionnalité, et d'assurer la disponibilité lorsqu'un service enregistre un pic de
demande ;
✓ Déploiement facile : les microservices assurent une intégration et une livraison
continues, facilitant la mise en place de nouvelles idées et la restauration des
modifications si un problème se produit. Le coût réduit des défaillances favorise

M. Moustapha DRAME Mémoire Master II Génie logiciel

28
Chapitre II : Architectures logicielles et méthodologiques

l'expérimentation, facilite la mise à jour du code et accélère les délais de

commercialisation des nouvelles fonctionnalités ;
✓ Liberté technologique : les architectures microservices ne suivent pas une approche
« universelle ». Les équipes peuvent choisir le meilleur outil pour résoudre des
problèmes spécifiques. Ainsi, les équipes qui développent les microservices peuvent
choisir l'outil le mieux adapté à chaque tâche ;
✓ Code réutilisable : la fragmentation de logiciels en petits modules bien définis permet
aux équipes d'utiliser les fonctions à des fins diverses. Un service écrit pour une
fonction spécifique peut être utilisé comme composant pour une autre fonctionnalité.
Une application peut ainsi s'amorcer elle-même, comme les développeurs peuvent créer
de nouvelles fonctionnalités sans écrire du code de zéro ;
✓ Résilience : l'indépendance du service augmente la résistance de l'application face aux
défaillances. Dans une architecture monolithique, la défaillance d'un seul composant
peut entraîner la défaillance de l'application toute entière. Avec l'architecture
microservices, les applications gèrent entièrement les échecs des services en dégradant
la fonctionnalité, mais sans interrompre l'ensemble de l'application.

c. Limites des microservices

De part de ces nombreux avantages, les microservices présentent aussi des limites que nous
allons citer ci-dessous [2] :
✓ Développement tentaculaire : les microservices ajoutent de la complexité par rapport
à une architecture monolithique, étant donné que vous avez plus de services dans un
plus grand nombre d'emplacements créés par plusieurs équipes. Si cette multiplication
n'est pas bien gérée, elle freine le développement et dégrade les performances
opérationnelles ;
✓ Coûts d'infrastructure élevés : chaque nouveau microservice peut impliquer ses
propres coûts pour la suite de tests, les playbooks de déploiement, l'infrastructure
d'hébergement, les outils de surveillance, et bien plus encore ;
✓ Frais organisationnels supplémentaires : les équipes doivent ajouter un autre niveau
de communication et de collaboration pour coordonner les mises à jour et les
interfaces ;

M. Moustapha DRAME Mémoire Master II Génie logiciel

29
 Chapitre II : Architectures logicielles et méthodologiques

✓ Défis de débogage : chaque microservice possède son propre ensemble de journaux, ce

qui complique le débogage. De plus, un seul processus métier peut s'exécuter sur
plusieurs machines, ce qui complique encore le processus ;
✓ Manque de standardisation : l'absence de plateforme commune peut entraîner une
prolifération des langages, des normes de journalisation et de la surveillance ;
✓ Manque de responsabilité claire : lorsque de nouveaux services sont lancés, le
nombre d'équipes les exécutant augmente lui aussi. Au fil du temps, il devient difficile
de connaître les services disponibles et de savoir qui contacter pour obtenir de l'aide.

II. Comparaison entre l’architecture monolithique et les microservices

Les applications monolithiques se composent généralement d'une interface utilisateur côté

client, d'une base de données et d'une application côté serveur. Les développeurs construisent
tous ces modules sur une base de code unique.

D'autre part, dans une architecture distribuée, chaque microservice fonctionne pour exécuter
une fonctionnalité ou une logique métier unique. Au lieu d'échanger des données au sein de la
même base de code, les microservices communiquent via une API [5].

Un résumé comparatif entre ces trois architectures est présenté dans le tableau ci-dessous :

Tableau 1 : Comparaison des architectures monolithique, orientée services et microservice

Aspect Architecture Architecture Orientée Architecture en

Monolithique Services (SOA) Microservices

Structure Application unique Multiples services Nombreux petits

fortement couplée. interagissent. services indépendants.

Communication Appels de Communication Communication inter-

méthode/fonction inter-services via des services via des APIs
directs au sein de APIs. ou des événements.
l'application.

Scalabilité Mise à l'échelle de Mise à l'échelle en Mise à l'échelle en

l'application dans son ajoutant des instances ajoutant des instances
ensemble. de services de services
spécifiques. individuels.

Flexibilité Choix technologique Certaine diversité Grande diversité

limité. technologique entre technologique dans

M. Moustapha DRAME Mémoire Master II Génie logiciel

30
 Chapitre II : Architectures logicielles et méthodologiques

les services distincts. des services isolés.

Déploiement Unité de déploiement Déploiement Déploiement

unique. indépendant des indépendant des
services. microservices.

Maintenance Les modifications Les modifications Les modifications

peuvent impacter dans les services ont dans les microservices
l'ensemble de des effets isolés. ont des effets isolés.
l'application.

Collaboration L'ensemble de l'équipe Les équipes Les équipes

d’équipe travaille sur une seule collaborent sur des collaborent sur des
base de code. services distincts. microservices
individuels.

Isolation des Une seule défaillance Les défaillances sont Les défaillances sont
erreurs peut affecter contenues dans des contenues dans des
l'ensemble du système. services spécifiques. microservices
individuels.

Gestion de la Complexité plus Complexité modérée Complexité moindre

complexité élevée en raison de avec des services avec des microservices
composants fortement découplés. fortement découplés.
couplés.

Développement Nécessite moins de Nécessite une Nécessite davantage

planification au planification modérée de planification et
départ, mais devient pour définir les d'infrastructure, mais
complexe à maintenir. services et leurs plus facile à gérer à
interactions. long terme.

III. Méthodologies de développement

Nous présenterons dans cette section les deux grandes catégories de méthodes de gestion de
projet et détaillerons les plus connues. Les méthodes classiques et agiles sont des méthodes
de gestion de projet bien connues des entreprises de développement de solutions logicielles.
La première repose sur une planification détaillée quand l’autre se base sur un système
itératif.

1 Méthodes classiques

Les méthodes classiques se caractérisent par leur approche séquentielle des phases de gestion
d'un projet. Quelques méthodes de cette catégorie sont présentées dans les sections suivantes :

M. Moustapha DRAME Mémoire Master II Génie logiciel

31
Chapitre II : Architectures logicielles et méthodologiques

a. Le modèle Waterfall (en cascade)

Le modèle de gestion waterfall (cascade) est telle une chute d’eau, où les besoins sont
entièrement définis au sommet de la cascade, et les différentes phases se succèdent de façon
séquentielle (voir Figure 5).

Figure 5 : Méthode en cascade

Il n’y a pas de chevauchement entre les phases, car le résultat d’une phase sert d’entrée à la
phase suivante. C’est-à-dire qu’une fois que les parties prenantes et les clients se sont mis
d'accord sur les exigences du projet et les ont documentées, le projet est exécuté étape par
étape jusqu'à ce qu'il soit terminé. Ensuite, le client examine le projet pour s'assurer qu'il
réponde bien aux exigences. Si ce n’est pas le cas, le client le signale, et parfois demande de
nouvelles fonctionnalités auxquelles il n’avait pas pensé. La prise en compte de ces nouvelles
fonctionnalités ou la modification de certaines de ces fonctionnalités coûtent cher. C’est en
cela qu’on dit que la méthode de gestion de projet Waterfall manque de flexibilité.

Si votre projet n’est pas complexe et vous arrivez à obtenir des exigences bien définies, bien
complètes, validées, partagées, claires, et qu’il nécessite une structure de travail stricte pour
assurer le succès du projet, alors vous pouvez opter pour la méthode waterfall [6].

M. Moustapha DRAME Mémoire Master II Génie logiciel

32
Chapitre II : Architectures logicielles et méthodologiques

b. Le cycle en V

Le cycle en V est une méthode de gestion de projet réputé pour son organisation des activités
en deux flux parallèles :
✓ Un flux descendant : qui détaille le produit depuis le cadrage jusqu’à son
implémentation en passant par le recueil des expressions et les spécifications ;
✓ Et un flux ascendant : qui vérifie la qualité du produit à chacune des phases du projet
en partant de l’implémentation pour remonter jusqu’au cadrage.

Sa similarité avec le modèle Waterfall est dans son approche de gestion séquentielle linéaire.

L’avantage de cette méthode est son caractère anticipatif des problèmes qui peuvent avoir lieu
à chacune des phases linéaires de gestion de projet. Et ce, en mettant en œuvre un ensemble
de tests en face de chaque phase [6]. La figure 6 montre une méthode en Cycle V.

Figure 6 : Méthode du cycle en V

c. Méthode Prince2

La méthode de gestion de projet Prince2 dont l’acronyme signifie PRojects IN Controlled

Environments, est organisée par processus autour de 7 thèmes :
✓ Business Case
✓ Qualité
✓ Planification

M. Moustapha DRAME Mémoire Master II Génie logiciel

33
Chapitre II : Architectures logicielles et méthodologiques

✓ Gestion des risques

✓ Gestion du changement
✓ Progression
✓ Organisation

Et 4 grandes étapes, à savoir :

✓ Pré-projet
✓ Initialisation
✓ Séquences de livraison successives
✓ Dernière séquence de livraison

Chaque étape possède ses propres plans et processus à suivre.

L’objectif de cette méthode est de donner aux équipes un meilleur contrôle des ressources et
de la capacité, d’atténuer efficacement les risques, tout en mettant l’accent sur une bonne
analyse de rentabilité et la gestion du changement.

Si vous avez des projets informatiques complexes et disposez des éléments nécessaires pour
une bonne analyse claire des exigences afin de vérifier la valeur ajoutée du projet pour client,
alors Prince2 est un bon choix pour vous [6].

2 Méthodes agiles

Les méthodes agiles offrent une meilleure façon de développer les logiciels. Elles s’appuient
sur plusieurs Frameworks disponibles tels que Scrum, Kanban, Srumban, Lean, XP, etc. pour
fournir une structure claire et mesurable (voir Figure 7).

M. Moustapha DRAME Mémoire Master II Génie logiciel

34
Chapitre II : Architectures logicielles et méthodologiques

Figure 7 : Méthodes agiles

Cette structure favorise le développement itératif, la collaboration entre les équipes et la prise
en compte rapide de l’évolution des besoins tout au long du processus de développement. En
effet, les demandes et les solutions évoluent grâce à la collaboration d'équipes organisées et
interfonctionnelles, mais aussi grâce à l’implication des clients.

La satisfaction de ces derniers est assurée grâce à des livraisons précoces et continues des
parties logicielles. Il est ainsi plus facile de soutenir et de motiver vos équipes.

Les méthodes agiles permettent de détecter et de corriger rapidement les problèmes inattendus
et d’introduire des changements à n'importe quel stade du projet.

En utilisant ces méthodes dans la gestion de votre projet, vous prônez :

✓ Les individus et les interactions plutôt que les processus et les outils,
✓ Les logiciels de travail plutôt qu'une documentation complète,
✓ La collaboration avec les clients plutôt que la négociation d'un contrat,
✓ La réaction au changement plutôt que le suivi d’un plan [6].

Dans la suite, nous détaillons les méthodes agiles les plus utilisées aujourd’hui.

M. Moustapha DRAME Mémoire Master II Génie logiciel

35
Chapitre II : Architectures logicielles et méthodologiques

a. Scrum

Scrum est un Framework issu de la méthodologie de gestion de projet agile. Son utilisation
permet de développer, de livrer et de maintenir des produits complexes. Scrum se base sur la
collaboration, la responsabilité et le progrès itératif. La spécificité de Scrum se trouve dans la
façon dont elle fonctionne en utilisant :
✓ des rôles: Product Owner, Scrum master, Scrum team,
✓ des événements : les Sprints à durée bien définie, les Daly Scrum de 15 min par jour,
le Sprint Planning meeting, la Sprint review et la Sprint retrospective,
✓ des artefacts : Product backlog, sprint backlog, livrables.

Figure 8 : Scrum [6]

Avec Scrum, le travail est organisé en cycle court de généralement 1 à 2 semaines, appelés «
sprints ». À chaque Sprint, l’équipe choisi l’item du backlog qui sera traité dans le sprint et à
la fin de chaque sprint, l'équipe de projet publie un produit amélioré, validé et potentiellement
livrable. Scrum permet ainsi une livraison plus rapide et une meilleure fréquence de sortie des
parties logiciels [6]. Cependant, il est important de garder un œil sur la dette technique qui
pourrait s'accumuler.

M. Moustapha DRAME Mémoire Master II Génie logiciel

36
Chapitre II : Architectures logicielles et méthodologiques

b. Kanban

Kanban est une approche agile qui permet d’identifier très rapidement les goulets
d'étranglement et d’examiner l’étape concernée. L’utilisation d’un tableau kanban permet de :
✓ Visualiser un aperçu immédiat de l'état d'avancement de chaque projet à un moment
donné
✓ Limiter les travaux en cours
✓ Et d'optimiser ainsi la productivité et l’efficacité de vos équipes.

Figure 9 : Exemple Kanban [6]

Avec la méthode Kanban, le travail est extrait progressivement du backlog, en fonction de la

capacité de l'équipe, et déplacé dans les colonnes du tableau en fonction de l’état
d’avancement. Chaque colonne représente une étape du processus.

À la différence du Scrum, l'approche Kanban ne prescrit pas de délais, ni ne fixe d'autres

échéances.

Si votre projet est tel que vous recevez de nombreuses demandes dont la priorité et la taille
varient, alors la méthodologie de gestion de projet Kanban est la plus adaptée [6].

M. Moustapha DRAME Mémoire Master II Génie logiciel

37
Chapitre II : Architectures logicielles et méthodologiques

c. Scrumban

Srumban est un mixte de Scrum et de Kanban. La différence essentielle entre Scrumban et la

méthodologie Scrum classique réside dans le choix des items du backlog pour chaque Sprint.
Au lieu de décider sur quelle tâche du backlog travailler dans chaque sprint, comme dans un
Scrum, avec scrumban vos choix d’items de backlog se feront en fonction de la capacité à
produire de vos équipes, comme dans un kanban.

L’utilisation de cette méthode de gestion de projet vous permet de profiter des avantages du
Kanban dans une gestion de projet basée sur la méthodologie Scrum [6].

d. Le Lean agile

La méthode Lean, aujourd’hui considérée comme partie intégrante de l'approche agile, permet
d’améliorer l'efficacité, de maximiser la valeur et d’éliminer le gaspillage. Elle s'efforce,
comme toute méthode agile, à réduire toutes les tâches et activités qui n'apportent pas de
valeur réelle et d’augmenter l’efficacité des parties prenantes.

L’utilisation du Lean permet d’appliquer le principe des 3M (Muda, Mura et Muri) dans le
processus de gestion de projet, pour éviter toute sorte de gaspillage :
✓ Muda (gaspillage) : lorsque vous utilisez des ressources sans que ces dernières
n’apportent de valeur ajoutée au client ;
✓ Mura (irrégularité) : lorsque l’avancement plus prononcé d’une partie déséquilibre
toutes les autres parties. Cela conduit à une inefficacité des processus et de l’équipe
(gaspillage !) ;
✓ Muri (surcharge) : lorsqu'il y a trop de pression sur les ressources. Cela conduit à des
inefficacités - tant au niveau des machines que des personnes [6].
✓ La figure 10 présente la méthode Learn.

M. Moustapha DRAME Mémoire Master II Génie logiciel

38
 Chapitre II : Architectures logicielles et méthodologiques

Figure 10 : Méthode Lean [6]

En tant que précurseur de DevOps, et donc de l'intégration, la livraison et le déploiement

continus (CI/CD), la méthode agile est étroitement liée à ces approches. Comprendre la
philosophie de la méthode agile peut vous aider à mieux exploiter le CI/CD tout en
implémentant un pipeline CI/CD mettant en pratique la méthode agile [6].

IV. DevOps, CI /CD

1 Culture DevOps

La culture DevOps, c’est avant tout une nouvelle façon de travailler ensemble. Elle
transforme notre manière de collaborer en cassant les barrières entre le développement et les
opérations. Ici, plus de silos : chacun a son rôle, mais tout le monde avance dans la même
direction, avec plus d’autonomie, une communication fluide et des processus optimisés grâce
à l’automatisation.

Adopter DevOps, ce n’est pas juste ajouter des outils ou des nouvelles pratiques techniques.
C’est surtout un état d’esprit : comprendre les enjeux des autres, partager les responsabilités et
apprendre ensemble. Cette approche permet d’accélérer les livraisons, d’améliorer la qualité
des logiciels et de rendre les systèmes plus robustes [7].

M. Moustapha DRAME Mémoire Master II Génie logiciel

39
Chapitre II : Architectures logicielles et méthodologiques

2 Intégration continue/livraison continue (CI/CD)

La gestion de la configuration fait référence à la gestion de l'état des ressources d'un système,
ce qui englobe les serveurs, machines virtuelles et bases de données. Moyennant des outils de
gestion de la configuration, les équipes peuvent déployer les modifications de façon
systématique et contrôlée, réduisant ainsi les risques de modification de la configuration
système. Les équipes utilisent des outils de gestion de la configuration pour suivre l’état du
système et éviter toute dérive de configuration, à savoir toute dérive de configuration d’une
ressource système par rapport à son état souhaité au fil du temps [7].

3 Contract-first avec OpenApi et SwaggerHub

L’approche contract-first signifie fondamentalement que tout effort d'API, qu'il s'agisse d'une
ou de plusieurs dans un programme, commence par un processus de conception. Dans ce
modèle, les API sont définies de manière itérative que les humains et les ordinateurs peuvent
comprendre, avant même qu'aucun code ne soit écrit. L'objectif est que chaque équipe parle le
même langage et que chaque outil utilisé exploite la même conception d'API. La différence
cruciale ici par rapport à une approche API-first est que, bien que l'API soit extrêmement
importante, le processus de conception est ce qui garantit que toutes les parties prenantes sont
impliquées et que leurs besoins sont satisfaits lors de la création.

Design-First commence avec des individus techniques et non techniques de chacune des
fonctions impliquées participant au processus de rédaction d'un contrat qui définit l'objectif et
la fonction de l'API (ou de l'ensemble d'API). De toute évidence, cette approche nécessite un
certain temps initial consacré à la planification. Cette phase vise à s'assurer que lorsque vient
le temps de commencer à coder, les développeurs écrivent du code qui n'aura pas besoin d'être
supprimé et réécrit plus tard. Cela permet de créer des API itératives et utiles qui, à leur tour,
conduisent à un meilleur programme d'API plus évolutif dans son ensemble [8].

L’approche contract-first a de nombreux avantages :

✓ Il favorise l’expérience développeur et la collaboration avec les autres équipes (front,
QA, ops, etc) ;
✓ Il facilite l’expression du besoin avec les responsables métier et minimise le risque
d’incompréhensions au cours de développement ;

M. Moustapha DRAME Mémoire Master II Génie logiciel

40
Chapitre II : Architectures logicielles et méthodologiques

✓ Il permet aux équipes de développement de travailler en parallèle en utilisant un

serveur de mock ;
✓ Il permet l’utilisation d’outils de génération de code pour générer des serveurs et des
clients dans divers langages de programmation ;
✓ Il permet l’utilisation d’outils de génération de documentation pour écrire une
documentation ;
✓ Il permet l’utilisation de nombreux outils [9] ;
✓ Modularité : Les API sont conçues pour être utilisées et réutilisées facilement dans
différents contextes ;
✓ Clarté des responsabilités : Chaque équipe se concentre sur son domaine sans interférer
avec les autres.
✓ Indépendance des équipes : Les développeurs avancent en parallèle sans dépendances
bloquantes ;
✓ Échange efficace : Une documentation structurée assure une compréhension rapide
entre les équipes ;
✓ Uniformité des API : Des standards bien définis garantissent une expérience homogène
et intuitive.

SwaggerHub est une solution en ligne qui facilite la conception et la gestion des API REST,
qu'elles soient publiques, privées ou dédiées aux microservices. Son approche "Design First,
Code Later" permet de structurer l'API avant d'implémenter la logique métier.

Avec SwaggerHub, vous pouvez :

✓ Concevoir vos API en suivant le standard OpenAPI ;
✓ Centraliser et organiser toutes vos définitions d'API en un seul espace ;
✓ Réutiliser des composants communs (modèles de données, réponses) pour plus de
cohérence ;
✓ Collaborer efficacement avec votre équipe sur la conception des API ;
✓ Générer automatiquement du code serveur et client, puis l'exporter vers GitHub,
GitLab, Bitbucket ou Azure DevOps ;
✓ Partager vos API en mode privé ou public selon vos besoins ;
✓ Faire évoluer vos API en gérant plusieurs versions et en affinant leur conception au fil
du temps.

M. Moustapha DRAME Mémoire Master II Génie logiciel

41
 Chapitre II : Architectures logicielles et méthodologiques

OpenAPI Spécification (anciennement Swagger Spécification) est un format de description

d'API pour les API REST. Un fichier OpenAPI vous permet de décrire l'intégralité de votre
API, notamment :
✓ Points de terminaison disponibles (/users) et opérations sur chaque point de
terminaison (GET /users, POST /users) ;
✓ Paramètres de fonctionnement Entrée et sortie pour chaque opération.
✓ Méthodes d'authentification ;
✓ Coordonnées, licence, conditions d'utilisation et autres informations.

Les spécifications de l'API peuvent être écrites en YAML ou JSON. Le format est facile à
apprendre et lisible à la fois pour les humains et les machines. La spécification OpenAPI
complète est disponible sur GitHub : Spécification OpenAPI 3.0.

V. Choix de la méthode et justification

Pour ce projet, nous avons choisi Scrum, une méthode agile qui nous a offert la flexibilité et
la réactivité. Grâce à des sprints courts, nous avons pu livrer régulièrement des versions
testables de l’application et les améliorer en intégrant rapidement les retours des utilisateurs.
Cette approche a également renforcé la collaboration et la transparence, en facilitant la
communication entre toutes les parties prenantes. En détectant rapidement les problèmes,
nous avons pu réduire les risques et garantir une solution adaptée aux besoins réels.

Pour structurer notre travail, nous avons défini les rôles clés :
✓ Product Owner : Mme Anna BAKHOUM, responsable de la vision et des priorités du
projet ;
✓ Scrum Master : Pr Ibrahima DIOP, garant du bon déroulement de la méthode agile ;
✓ Scrum Team : M. Moustapha DRAMÉ, chargé du développement technique.

Ce choix repose sur la nécessité d’une approche flexible et réactive pour s’adapter aux
évolutions du projet. Scrum s’est imposé comme le meilleur choix grâce à :
✓ Son adaptabilité, permettant d’intégrer rapidement les retours des utilisateurs ;
✓ Ses cycles courts (sprints), assurant des livraisons fréquentes et une amélioration
continue ;

M. Moustapha DRAME Mémoire Master II Génie logiciel

42
Chapitre II : Architectures logicielles et méthodologiques

✓ Une communication optimisée, favorisant la coordination et la prise de décision

rapide ;
✓ Une réduction des risques, grâce à l’identification et la correction progressive des
problèmes ;
✓ Un engagement renforcé, impliquant activement chaque membre de l’équipe.

Conclusion

Dans ce chapitre, nous avons exploré les architectures logicielles et les méthodologies de
conception et de développement logiciels. À l’issue de cette analyse, nous avons sélectionné
l’architecture et l’approche méthodologique les mieux adaptées aux besoins de notre projet.

Ces choix seront déterminants pour développer une solution efficace et adaptée aux besoins
de l’UASZ. L’adoption des microservices permet de concevoir un système flexible et évolutif,
capable de s’adapter aux changements et de gérer efficacement les recrutements. Sur le plan
méthodologique, l’approche agile et DevOps favorise une collaboration fluide et une
amélioration continue du système. L’intégration des pratiques CI/CD et de l’approche
contract-first avec OpenAPI et SwaggerHub renforce la qualité et la fiabilité de notre solution.

Ces choix permettront de concevoir une plateforme robuste, intuitive et performante,

répondant aux attentes des utilisateurs tout en garantissant une gestion optimisée des
candidatures.

Dans le prochain chapitre, nous allons présenter la spécification, l’analyse des besoins et la
conception des APIs.

M. Moustapha DRAME Mémoire Master II Génie logiciel

43
 Chapitre III : Spécification, analyse des besoins et conception des APIs

Chapitre III : Spécification, analyse des besoins et conception des

APIs

INTRODUCTION

La spécification et l’analyse des besoins fonctionnels sont des étapes clés dans tout projet de
développement logiciel. Elles permettent d’identifier les acteurs du système et de définir
précisément les fonctionnalités à mettre en œuvre pour répondre aux attentes des utilisateurs.
Ce chapitre présente la spécification fonctionnelle des APIs, qui servira de fondation pour la
conception technique et le développement du système de gestion des recrutements à l'UASZ.
L'API doit être robuste, sécurisée et facile à maintenir, tout en garantissant une interaction
fluide entre les utilisateurs et le système. Nous utilisons Swagger et OpenAPI pour spécifier
les services de l'API, ce qui facilite la collaboration entre les développeurs et les parties
prenantes, et garantit une documentation claire et accessible pour les futures itérations.
Dans les prochaines sections, nous allons identifier, pour chaque API, les acteurs impliqués
ainsi que ses fonctionnalités. Ensuite l’architecture générale ainsi que la conception détaillée
de notre application seront décrites.

I. Spécification et analyse des besoins

La spécification est un élément crucial du processus de développement de l’API, car elle

définit les fonctionnalités de base qui doivent être incluses dans cette dernière pour répondre
aux besoins de l’utilisateur. La spécification nous permet également de travailler de manière
collaborative avec les parties prenantes pour nous assurer que nous avons une compréhension
claire des exigences fonctionnelles avant de passer à la phase de conception.

1 Spécification et analyse des besoins de l’API Authenfication-service

a. Spécification des besoins de l’API Authenfication-service

La spécification des besoins de l’API Authentication-service est un document nécessaire pour

cerner les fonctionnalités, les acteurs et interfaces du système. Voici un récapitulatif organisé
des informations fournies en se basant sur les figures (Figures 11 et 12) citées ci-dessus.

M. Moustapha DRAME Mémoire Master II Génie logiciel

44
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 11 : Extrait 1 de la spécification de l’api authentification

Figure 12 : Extrait 2 de la spécification de l’api authentification

➢ Identifications des acteurs

Un acteur représente un rôle d'un utilisateur qui interagit avec le système que vous modélisez.
L'utilisateur peut être un utilisateur humain, une organisation, une machine ou un autre
système externe. Dans un diagramme de cas d’utilisation, on distingue deux catégories
d'acteurs : les acteurs principaux qui bénéficient directement des fonctionnalités du système et
les acteurs secondaires qui fournissent des ressources ou informations complémentaires au
système.

M. Moustapha DRAME Mémoire Master II Génie logiciel

45
Chapitre III : Spécification, analyse des besoins et conception des APIs

Dans le contexte de notre projet, les acteurs identifiés sont les suivants :

✓ Administrateur : qui gère le système ;

✓ Personnel (responsable DRH, responsable de formation) : qui gère les appels à
candidatures ;
✓ Candidat : qui soumet et suit ses candidatures ;
✓ Membre de commission : qui participe aux commissions d’appel à candidature.

➢ Identification des fonctionnalités

Ce microservice expose ses fonctionnalités via des endpoints API, documentés de manière
détaillée dans Swagger. La figure 13 illustre quelques-uns de ces endpoints, mettant en
évidence leur structure et leur utilisation.

Figure 13 : Quelsques endpoints de l’API authentification

➢ Diagramme de cas d’utilisation de l’api authentification-service

M. Moustapha DRAME Mémoire Master II Génie logiciel

46
Chapitre III : Spécification, analyse des besoins et conception des APIs

La figure 14 représente les fonctionnalités pour l’administrateur de notre système. Les

différentes fonctionnalités sont représentées sous forme de cas d’utilisation, qui décrivent une
action ou une tâche que l’utilisateur peut effectuer dans le système.

Figure 14 : Diagramme de cas d’utilisation de l’api Authentification-service

➢ Description du cas d’utilisation « s’authentifier »

La description d’un cas d’utilisation détaille une interaction spécifique entre un utilisateur et
le système. Dans le cadre du cas d’utilisation « S’authentifier », il s’agit de la fonctionnalité
permettant à un utilisateur de se connecter au système en fournissant des informations
d’identification, telles que son adresse e-mail et son mot de passe. Cette description est
présentée sous forme de tableau pour en faciliter la compréhension et la visualisation. Le
tableau 2 ci-dessous illustre en détail le processus d’authentification.

Tableau 2 : Description du cas d’utilisation « s’authentifier »

M. Moustapha DRAME Mémoire Master II Génie logiciel

47
Chapitre III : Spécification, analyse des besoins et conception des APIs

Elément Description

Nom du cas d'utilisation « s’authentifier »

Acteurs Administrateur, responsable (DRH, formation), candidat,

membre commission

Description Permet à l'utilisateur de se connecter au système.

Préconditions L'utilisateur doit lancer l’application d’abord.

Scénario principal 1. L'utilisateur lance l’application.

2. L'utilisateur accède au menu lui permettant de se

connecter.

3. L'utilisateur donne l’email et le mot de passe.

4. L'utilisateur clique sur le bouton login.

b. Analyse des besoins fonctionnels de l’API

L’analyse des besoins fonctionnels est une étape clé du développement d’un système. Elle
permet d’identifier les interactions entre les utilisateurs et le système ainsi que les
comportements attendus en réponse à une action donnée. Dans cette section, nous nous
concentrons sur le cas d’utilisation « s’authentifier ». Cette fonctionnalité permet à un
utilisateur de s’authentifier.

➢ Diagramme de séquence du cas d’utilisation « s’authentifier »

Le diagramme ci-dessous décrit le scénario normal mentionné précédemment (voir Tableau 2)

pour l’authentification des utilisateurs du système. Ce processus concerne différents profils
d’utilisateurs, tels que :

• L’administrateur du système,

• Le responsable de formation,

M. Moustapha DRAME Mémoire Master II Génie logiciel

48
Chapitre III : Spécification, analyse des besoins et conception des APIs

• Le responsable de direction des ressources humaines (DRH),

• Le candidat,

• Le membre de commission.

La figure 15 présente le diagramme de séquence associé à ce processus d’authentification,

illustrant les interactions entre les acteurs et le système.

Figure 15 : Diagramme de séquence du cas d’utilisation « s’authentifier »

2 Spécification et analyse des besoins de l’api UsersDétails-service

a. Spécification des besoins de l’api UsersDétails-service

L'API usersDetails-service est un microservice conçu pour gérer les informations

complémentaires des utilisateurs. Son rôle principal est de centraliser et de stocker des
données supplémentaires associées aux profils des utilisateurs, permettant ainsi une
consultation et une mise à jour simplifiées au sein d'une architecture de microservices.

Les figures 16, 17 et 18 ci-dessous présentent la spécification technique de ce microservice,

détaillant ses fonctionnalités, ses endpoints et ses interactions avec d'autres composants du
système.

M. Moustapha DRAME Mémoire Master II Génie logiciel

49
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 16 : Extrait 1 de la spécification de l’api userDetails-service

Figure 17 : Extrait 2 de la spécification de l’api userDetails-service

Figure 18 : Extrait 3 de la spécification de l’api userDetails-service

M. Moustapha DRAME Mémoire Master II Génie logiciel

50
Chapitre III : Spécification, analyse des besoins et conception des APIs

Cette spécification est au format YAML pour décrire une API RESTful. Elle commence par
spécifier la version d'OpenAPI utilisée (3.0.3), suivie d'informations générales sur l'API,
notamment son titre, sa description et sa version. Ensuite, elle spécifie un serveur sur lequel
l'API est déployée (http://localhost:8083/api/emails). Le bloc suivant définit les différentes
routes de l'API, chacune avec des opérations HTTP telles que GET, POST, PUT et DELETE.
Chaque opération est décrite avec un résumé, une description, un ID d'opération et une liste
de paramètres de requête. Par exemple, la première route /email définit une opération POST
pour créer un nouveau mail avec les détails fournis dans le corps de la requête. Elle spécifie
également une opération PUT pour mettre à jour les détails d'un budget existant et une
opération GET pour récupérer tous les mails dans un tableau JSON.

Les autres routes sont similaires, avec des opérations GET, POST, PUT et DELETE pour
gérer les mails, les téléphones, les adresses, les départements, etc. Chaque opération spécifie
les paramètres requis et les réponses possibles, y compris les codes HTTP et les descriptions.

Enfin, la spécification contient une section components qui définit les schémas de données
utilisés dans l'API, tels qu’Email, Téléphone, Département, etc. Ces schémas décrivent les
champs de données nécessaires pour créer ou mettre à jour des emails, des numéros de
téléphone, des départements, etc.

Afin de garantir une parfaite adéquation avec les exigences du cahier des charges et d’assurer
une compréhension approfondie des fonctionnalités de notre API, nous commençons par
identifier précisément les besoins des utilisateurs. Cette analyse se concrétise notamment par
la production de diagrammes de cas d'utilisation, qui permettent de visualiser les interactions
entre les acteurs et l’API.

➢ Identification des acteurs

Un acteur est l’archétype de l’utilisateur (personne, processus externe, ...) qui interagit avec le
système. Par défaut, c’est un acteur principal, c’est-à-dire qu’il agit directement sur le système
et en attend des résultats ou bien, il peut être un acteur secondaire qui est souvent sollicité
pour des informations supplémentaires.

Dans notre cas, le tableau ci-dessous détaille l’ensemble de nos acteurs intervenant dans l’API
UserDétails-service.

M. Moustapha DRAME Mémoire Master II Génie logiciel

51
Chapitre III : Spécification, analyse des besoins et conception des APIs

Tableau 3 : les acteurs intervenants dans l’api UserDetails-service

Acteurs Actions

Administrateur Gérer les utilisateurs, les rôles, les comptes, les appels à
candidatures et les candidatures

Personnel Participer à la commission d’un appel à candidature

Responsable DRH Créer et suivre les appels à candidatures Per et Pats

Responsable de formation Gérer les appels à candidatures de la formarion

Candidats Gérer ses candidatures en ligne

Membre de Commission Participer à la commission d’un appel à candidature

➢ Identification des fonctionnalités

Les fonctionnalités d'un système sont les services ou actions qu'il propose, qu'ils soient
visibles pour l'utilisateur ou qu'ils fonctionnent en arrière-plan automatiquement.

Lorsqu'on développe une API, il est crucial d'organiser clairement les données échangées.
L'outil Swagger facilite cette tâche en décrivant précisément les opérations disponibles. La
figure 19 montre l’ensemble des méthodes de l’API userDetails-service.

M. Moustapha DRAME Mémoire Master II Génie logiciel

52
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 19 : Quelques Endpoints de l’API UserDetails-service

M. Moustapha DRAME Mémoire Master II Génie logiciel

53
Chapitre III : Spécification, analyse des besoins et conception des APIs

Cette figure présente quelques méthodes permettant d'interagir avec l'API utilisateur, rendues
clairement accessibles grâce à la documentation fournie par Swagger.

➢ Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation de l’API usersDetails-service explique comment les

utilisateurs et les systèmes travaillent ensemble. Il montre les actions principales, comme
consulter ou mettre à jour les informations des utilisateurs, et aide à visualiser les processus
métier de manière simple et efficace.

Figure 20 : Diagramme de cas d’utilisation de l’api UserDetails-service

Dans le diagramme ci-dessus (figure 20), nous pouvons voir que l’utilisateur doit
s’authentifier pour pouvoir utiliser les fonctionnalités attribuées par le système.

➢ Description du cas d’utilisation « modifier ses informations »

Le cas d'utilisation « modifier ses informations » décrit l'interaction entre l'utilisateur et le

système pour lui permettre de mettre à jour ses informations personnelles, telles que sa date
de naissance, ses numéros de téléphone, son adresse, etc. Cette fonctionnalité assure que
l'utilisateur peut modifier ces données de manière fluide et sécurisée.

La description du cas d’utilisation est présentée dans le tableau 4.

M. Moustapha DRAME Mémoire Master II Génie logiciel

54
Chapitre III : Spécification, analyse des besoins et conception des APIs

Tableau 4 : Description du cas d’utilisation « modifier ses informations »

Élément Description

Nom du cas d'utilisation Modifier ses informations

Acteur Utilisateur (administrateur, candidat, responsable de la DRH,

responsable de formation, membre de commission)

Description Permet à l'utilisateur de mettre à jour ses informations

personnelles, telles que la date de naissance, les numéros de
téléphone, l'adresse, etc.

Préconditions L'utilisateur doit être authentifié et connecté au système.

Scénario principal 1. L’utilisateur s’authentifie auprès du système.

2. L'utilisateur accède à son profil.

3. L'utilisateur modifie les informations souhaitées.

4. L'utilisateur enregistre les modifications.

Scénarios alternatifs 1. L'utilisateur entre des données incorrectes ou invalides.

2. Une erreur se produit lors de l'enregistrement des

modifications

Post conditions Les informations de l'utilisateur sont mises à jour dans la base
de données.

Exceptions L'utilisateur n'a pas l'autorisation de modifier certaines

informations (par exemple, des données administratives).

M. Moustapha DRAME Mémoire Master II Génie logiciel

55
Chapitre III : Spécification, analyse des besoins et conception des APIs

Fréquence d'utilisation Fréquent, chaque fois que l'utilisateur souhaite mettre à jour
ses informations.

b. Analyse des besoins fonctionnels de l’API UserDetails-service

Dans cette section, nous nous concentrons sur le cas d’utilisation « modifier ses
informations ». Cette fonctionnalité permet à un utilisateur authentifié de mettre à jour ses
données personnelles, telles que son adresse, son numéro de téléphone ou sa date de
naissance.

➢ Diagramme de séquence du cas « modifier ses informations »

Ce diagramme illustre les échanges entre l’utilisateur et le système, mettant en évidence les
étapes clés du processus de modification. Il permet de visualiser la manière dont le système
valide, enregistre et met à jour les informations en garantissant leur cohérence et leur sécurité.
La figure 21 ci-dessous décrit le diagramme de séquence du cas d’utilisation « modifier ses
informations ».

M. Moustapha DRAME Mémoire Master II Génie logiciel

56
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 21 : Diagramme de séquence du cas « modifier ses informations »

3 Spécification et analyse des besoins de l’API AppelCandidature-api

a. Spécification des besoins de l’API AppelCandidature-api

L’API AppelCandidature-api simplifie la gestion des appels à candidature, permettant de

créer, consulter, mettre à jour et supprimer des appels. Grâce à OpenAPI et Swagger, sa
documentation est claire, interactive et facile à tester. Les figures 22 et 23 détaillent ses
endpoints, paramètres et réponses, pour une compréhension rapide et intuitive.

M. Moustapha DRAME Mémoire Master II Génie logiciel

57
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 22 : Extrait 1 de la spécification de l’api AppelCandidature-api

Figure 23 : Extrait 2 de la spécification de l’api AppelCandidature-api

➢ Identification des acteurs

Dans ce microservice, nous avons identifiés quelques utilisateurs qui sont présentés dans le
tableau 5 ci-dessous.

Tableau 5 : Les différents acteurs intervenant dans l’api AppelCandidature-api

Acteurs Actions

Responsable DRH Gérer les appels à candidatures PER et

PATS

Responsable de Formation Gérer les offres de formations

M. Moustapha DRAME Mémoire Master II Génie logiciel

58
 Chapitre III : Spécification, analyse des besoins et conception des APIs

Administrateur Maintenir le système de gestion des appels à

candidatures

➢ Identification des fonctionnalités

Les différentes méthodes sont définies dans un contrat openApi dont la figure 24 ci-dessous
illustre quelques-unes.

Figure 24 : Quelques Endpoints de l’API AppelCandidature-api

M. Moustapha DRAME Mémoire Master II Génie logiciel

59
Chapitre III : Spécification, analyse des besoins et conception des APIs

➢ Diagramme des cas d’utilisation de l’API AppelCandidature-api

Le diagramme montre les principales fonctionnalités de l’API AppelCandidature-api,

utilisées par les responsables DRH et formation. Il explique comment ils interagissent avec le
système pour créer, consulter, mettre à jour et gérer les appels à candidatures.

Figure 25 : Diagramme de cas d’utilisation de l’api AppelCandidature-api

➢ Description du cas d’utilisation « créer un appel »

Le cas d'utilisation « créer un appel » décrit l'interaction entre l'utilisateur (Responsable) et le

système pour permettre à l'utilisateur d’ajouter un appel à candidatures. La description du cas
d’utilisation est présentée dans le tableau 6.

Tableau 6 : Description du cas d’utilisation « créer un appel »

M. Moustapha DRAME Mémoire Master II Génie logiciel

60
Chapitre III : Spécification, analyse des besoins et conception des APIs

Elément Description

Nom du cas d’utilisation créer un appel

Acteur Utilisateur (responsable de DRH, responsable de formation)

Description Permet à l’utilisateur d’ajouter un appel

Préconditions L'utilisateur doit être authentifié auprès du système.

Scénario principal 1. L'utilisateur s’authentifie auprès du système.

2. L'utilisateur accède à son page d’acceuil.

3. L'utilisateur clique sur rubrique appels sur l’ajout des appels et

remplit le formulaire et enfin valide l’ajout.

Scénarios alternatifs 1. L'utilisateur entre des données incorrectes ou invalides.

2. Une erreur se produit lors de l’ajout

Postconditions Les informations de l'appel sont enregistrées dans la base de

données.

b. Analyse des besoins fonctionnels de l’API AppelCandidature-api

Dans cette section, nous nous concentrons sur le cas d’utilisation « créer un appel ». Cette
fonctionnalité permet à un utilisateur authentifié de créer des appels à candidature.

➢ Diagramme de séquence du cas « créer un appel »

La figure 26 ci-dessous illustre le diagramme de séquence correspondant au cas d’utilisation «

Créer un appel ». Ce diagramme détaille les étapes et les interactions entre les différents
acteurs et composants du système lors la création d’un appel à candidatures.

M. Moustapha DRAME Mémoire Master II Génie logiciel

61
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 26 : Diagramme de séquence du cas d’utilisation « créer un appel »

4 Spécification et analyse des besoins de l’api Candidature-service

a. Spécification des besoins de l’api Candidature-service

L’API Candidature-service gère les candidatures, permettant leur soumission, consultation

et suivi. Les figures 27 et 28 détaillent sa spécification technique, incluant endpoints,
paramètres et réponses.

M. Moustapha DRAME Mémoire Master II Génie logiciel

62
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 27 : Extrait 1 de la spécification de l’api candidature-service

Figure 28 : Extrait 2 de la spécification de l’api candidature-service

➢ Identification des acteurs

Dans ce microservice, nous avons identifiés quelques utilisateurs qui sont présentés dans le
tableau 7 ci-dessous.

Tableau 7 : Les différents acteurs intervenants dans l’api candidature

Acteurs Actions

Candidat Il dépose et suit sa candidature

M. Moustapha DRAME Mémoire Master II Génie logiciel

63
Chapitre III : Spécification, analyse des besoins et conception des APIs

Responsable de Formation Il suit les candidatures de l’appel à candidature dont il a

créé

Responsable DRH Il suit les candidatures de l’appel à candidature dont il a

créé

➢ Identification des fonctionnalités

Les caractéristiques d'un système sont les opérations ou services qu'il offre, qu'ils soient
perceptibles par l'utilisateur ou qu'ils s'exécutent automatiquement en coulisses.Les
différentes méthodes sont définies dans un contrat openApi dont la figure 29 ci-dessous
illustre quelques-unes.

Figure 29 : Quelques endpoints de l’api candidature-service

➢ Diagramme des cas d’utilisation

La figure 30 ci-dessous présente le diagramme de cas d’utilisation de l’API Candidature-

service. Ce diagramme met en évidence les interactions entre les acteurs et les
fonctionnalités principales de ce microservice.

M. Moustapha DRAME Mémoire Master II Génie logiciel

64
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 30 : Diagramme du cas d’utilisation de l’api candidature-service

➢ Description du cas d’utilisation « soumettre une candidature »

Le tableau 8 montre la description du cas d’utilisation « soumettre une candidature ».

Tableau 8 : Description du cas d’utilisation « soumettre une candidature »

Élément Description

Nom du cas d’utilisation soumettre une candidature

Acteur Candidat

Description permet au candidat de déposer sa

candidature

Préconditions le candidat doit être authentifié et connecté

au système.

M. Moustapha DRAME Mémoire Master II Génie logiciel

65
Chapitre III : Spécification, analyse des besoins et conception des APIs

Scénario principal 1 . le candidat se connecte au système.

2 . il accède à son page d’accueil.

3 . il choisit l’appel à candidature.

4 . il dépose sa candidature en remplit

les informations demandées.

Scénarios alternatifs 1. le candidat entre des données incorrectes

ou invalides.

2. une erreur se produit lors de l’ajout

Postconditions les informations de la candidature sont

enregistrées dans la base de données.

b. Analyse des besoins fonctionnels de l’API Candidature-service

➢ Diagramme de séquence du cas d’utilisation « soumettre une candidature »

Ce diagramme illustre les échanges entre le candidat et le système, mettant en évidence les
étapes clés du processus de soumission des candidatures.

La figure 31 ci-dessous montre le diagramme de séquence du cas d’utilisation « soumettre

une candidature ».

M. Moustapha DRAME Mémoire Master II Génie logiciel

66
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 31 : Diagramme de séquence du cas d’utilisation « soumettre une candidature »

5 La spécification et analyse des besoins de l’api Selection-api

a. La spécification des besoins de l’api Selection-api

Le contract-at-first fournit une spécification précise de l'API. Les figures 40 et 41 suivantes

illustrent une section de la spécification de l’API Selection-api.

Figure 32 : Extrait 1 de la spécification de l’api Selection-api

M. Moustapha DRAME Mémoire Master II Génie logiciel

67
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 33 : Extrait 2 de la spécification l’api Selection-api

➢ Identification des acteurs

L’API Selection-api est utilisée par plusieurs acteurs impliqués dans le processus de
recrutement. Le tableau 9 ci-dessous présente les différents acteurs intervenant dans le
processus.

Tableau 9 : Les différents acteurs de l’api Sélection-api

Acteurs Actions principales

Responsable (DRH ou Configurer les critères de sélection et valider les

formation) résultats

Membre Commission Évaluer les candidatures

Administrateur Superviser le processus et gérer les accès

Candidat Consulter son statut de sélection

➢ Fonctionnalités

L’API fournit plusieurs fonctionnalités essentielles pour la gestion du processus de sélection.

Les différentes méthodes sont définies dans un contrat openApi dont la figure 34 ci-dessous
illustre quelques-unes.

M. Moustapha DRAME Mémoire Master II Génie logiciel

68
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 34 : Quelques Endpoints de l’api Selection-api

➢ Diagramme des cas d’utilisation

La figure 35 ci-dessous présente le diagramme de cas d’utilisation de l’API Selection-service.

Ce diagramme met en évidence les interactions entre les acteurs et ses fonctionnalités
principales.

Figure 35 : Diagramme de cas d’utilisation de l’api Selection-api

M. Moustapha DRAME Mémoire Master II Génie logiciel

69
Chapitre III : Spécification, analyse des besoins et conception des APIs

➢ Description du cas d’utilisation « évaluer les candidatures »

Une description du cas d’utilisation « évaluer les candidatures » est faite dans le tableau 10.

Tableau 10 : Description du cas d’utilisation « évaluer les candidatures »

Elément description

Nom du cas d’utilisation évaluer les candidatures

Acteur membre de commission

Description permet au Membre de commission d’évaluer les candidatures

Préconditions le Membre de commission doit être authentifié et connecté au

système.

Scénario principal 1 . il s’authentifie auprès du système.

2 . Il accède à son page d’accueil.

3 . Il clique sue évaluations

4 . Il choisit l’appel à candidature.

5 . Il clique sur le bouton évaluer pour évaluer la candidature

correspondante.

Scénarios alternatifs Le membre de commission entre des données incorrectes ou

invalides.

b. Analyse des besoins fonctionnels de l’API Selection-api

➢ Diagramme de séquence du cas d’utilisation « évaluer les candidatures »

M. Moustapha DRAME Mémoire Master II Génie logiciel

70
 Chapitre III : Spécification, analyse des besoins et conception des APIs

Ce diagramme illustre les échanges entre le membre de commission et le système, mettant en

évidence les étapes clés du processus d’évaluation. Il permet de visualiser la manière dont le
système valide comme le montre la figure 36 ci-dessous, enregistre et met à jour les
évaluations en garantissant leur cohérence et leur sécurité.

Figure 36 : Diagramme de séquence du cas d’utilisation « évaluer les candidatures »

II. Conception des APIs

La conception d’une API est une étape essentielle du développement logiciel. Pour structurer
et documenter efficacement une API, des outils comme OpenAPI et Swagger sont
recommandés. OpenAPI offre une description normalisée des fonctionnalités, des opérations
et des réponses de l’API, facilitant ainsi la collaboration entre les équipes.

Swagger, quant à lui, propose une interface interactive pour documenter, tester et générer du
code client. Il permet aux développeurs et aux parties prenantes de mieux comprendre l’API
et d’interagir avec elle de manière intuitive, optimisant ainsi le travail en équipe.

M. Moustapha DRAME Mémoire Master II Génie logiciel

71
Chapitre III : Spécification, analyse des besoins et conception des APIs

En adoptant OpenAPI et Swagger, on améliore la clarté, la collaboration et la qualité des

APIs. Grâce aux tests automatisés et au respect des standards, ces outils garantissent des
services robustes, bien documentés et facilement exploitables.

1 Éléments de notre architecture

L’architecture microservices nous permet de décomposer notre application en plusieurs

modules indépendants, chacun ayant des responsabilités bien définies. Cette approche
améliore la modularité, la scalabilité et la maintenance du système. Notre solution repose sur
huit (8) microservices, répartis en cinq (5) modules métiers et trois (3) modules
techniques.

a. Modules métiers

Ces modules gèrent les fonctionnalités principales de l’application :

✓ AUTHENTIFICATION-SERVICE (Spring Security) : ce service est responsable de

la gestion des utilisateurs, de l’authentification et de l’autorisation des accès. Il utilise
Spring Security pour sécuriser l’application et fournir les fonctionnalités suivantes : la
gestion des identifiants (création et validation des comptes utilisateurs), le chiffrement
et le stockage sécurisé des mots de passe, l’attribution des rôles et des permissions et la
gestion des tokens d’authentification (JWT ou OAuth2).

✓ APPELCANDIDATURE-API (Spring Boot) : ce service gère les appels à

candidatures de l’université. Il permet la création et la publication des appels à
candidatures, leur mise à jour et leur suppression ainsi que la consultation des offres
disponibles par les utilisateurs.
✓ USERDETAILS-SERVICE (Spring Boot) : ce service complète le service
AUTHENTIFICATION-SERVICE en gérant les informations complémentaires des
utilisateurs (pays, région, adresse, nationalité, etc.). Ses fonctionnalités incluent le
stockage et la mise à jour des données personnelles et la consultation des informations
des utilisateurs par les autres services.
✓ CANDIDATURE-SERVICE : ce module permet aux candidats de déposer leurs
candidatures pour répondre aux appels ouverts. Il assure la soumission des candidatures

M. Moustapha DRAME Mémoire Master II Génie logiciel

72
Chapitre III : Spécification, analyse des besoins et conception des APIs

en ligne, la mise à jour et le suivi des dossiers soumis ainsi que la récupération des
informations des candidatures pour leur analyse.
✓ SELECTION (Spring Boot) : ce service est en charge du processus de sélection des
candidats. Il offre la création de grilles d’évaluation et de critères de sélection,
l’évaluation automatique et manuelle des candidatures et la gestion des convocations
aux entretiens et des résultats.

b. Modules techniques

Ces services assurent le bon fonctionnement et l’intégration des microservices :

✓ CONFIG SERVICE (Spring Cloud Config) : ce module permet de centraliser et de
gérer les fichiers de configuration de tous les microservices. Il offre plusieurs
avantages :
• éviter les interruptions lors des mises à jour de configuration,
• stocker les configurations dans un dépôt Git pour assurer le versioning et la
traçabilité,
• mettre à jour dynamiquement les services sans redémarrage.
✓ DISCOVERY SERVICE (Spring Cloud - Eureka): ce service assure la découverte
dynamique des microservices. Son rôle est d’enregistrer automatiquement les
microservices dès leur démarrage, de permettre aux services de se trouver et
communiquer entre eux sans connaître leurs adresses exactes et d’assurer une haute
disponibilité et une meilleure résilience du système.
✓ GATEWAY (Spring Cloud Gateway) : ce module sert de point d’entrée unique pour
toutes les requêtes utilisateur. Il redirige automatiquement les requêtes vers le bon
microservice, applique des règles de sécurité (authentification, filtrage des requêtes,
limitation du débit) et simplifie la communication entre le Front-End et les
microservices sous-jacents.

Pour assurer une communication fluide et efficace, les microservices utilisent HttpClient,
une bibliothèque Java permettant d’envoyer et de recevoir des requêtes HTTP. Ses principales
fonctionnalités sont :
• Envoi de requêtes GET, POST, PUT, DELETE aux différents services ;
• Gestion des réponses et des erreurs de communication ;

M. Moustapha DRAME Mémoire Master II Génie logiciel

73
Chapitre III : Spécification, analyse des besoins et conception des APIs

• Optimisation des échanges réseau pour garantir de bonnes performances.

2 Architecture générale de la solution

Notre système repose sur une architecture microservices conçue pour assurer flexibilité et
évolutivité. Il est composé de huit microservices : authentification-service, appelcandidature-
api, usersdetails-service, candidature-service, selection, ainsi que trois services techniques
proxy, registry et config (voir Figure 37).

Dès leur démarrage, les microservices métiers récupèrent leur configuration via Config,
assurant une gestion centralisée des paramètres grâce à Git. Ensuite, ils s'enregistrent auprès
du Registry, qui garde une trace de leur localisation et de leur disponibilité. Le Proxy, quant
à lui, utilise ces informations pour rediriger les requêtes des utilisateurs vers le service
approprié, garantissant une navigation fluide et efficace.

En résumé, cette architecture optimise la communication entre les services et assure une
gestion dynamique des requêtes des utilisateurs. Grâce à Config, Registry et Proxy, les
microservices sont bien organisés, sécurisés et facilement accessibles, offrant ainsi une
expérience utilisateur optimale.

Figure 37 : Architecture globale du système

M. Moustapha DRAME Mémoire Master II Génie logiciel

74
 Chapitre III : Spécification, analyse des besoins et conception des APIs

Pour une bonne gestion de ce projet, nous avons utilisé une méthodologie de développement
logiciel approprié, Scrum.

III. Conception détaillée des APIs

1 Conception de l’API Authentification-service

a. Diagramme de classe

Le diagramme de classe est l’un des diagrammes les plus utilisés en UML, car il permet de
représenter visuellement les classes d’un système ainsi que leurs relations. Il facilite la
compréhension de la structure du projet et des interactions entre les différentes entités.

Figure 38 : Diagramme de classe de l’api Authentification

b. Schéma de données

En se basant sur la documentation Swagger, les développeurs peuvent ainsi visualiser le

schéma de données de leur API utilisateur. Ce schéma décrit l'ensemble des données qui sont
disponibles via l'API, ainsi que leur structure et leur format. Grâce à cette représentation, les
développeurs peuvent mieux comprendre les relations entre les différentes données et
identifier les erreurs éventuelles dans la structure des données.

La figure 39 ci-dessous montre le schéma de données de l’API Authentification.

M. Moustapha DRAME Mémoire Master II Génie logiciel

75
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 39 : Schéma de données de l’api authentification

2 Conception de l’API UsersDétails-service

a. Diagramme de classe

Le diagramme de la figure 40 montre les différentes classes participant à la réalisation

complète de l’API UserDetails-service.

M. Moustapha DRAME Mémoire Master II Génie logiciel

76
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 40: Diagramme de classes du service UserDetails-service

La classe Individu ne persiste pas dans la base de données de cette Api, elle provient du
microservice Authentification-service.

b. Schéma de données

La figure 41 montre le schéma de données de l’API UserDetails-service, spécifié

avec OpenAPI. Grâce à Swagger, la documentation interactive permet d’explorer facilement
la structure des données et leurs relations.

M. Moustapha DRAME Mémoire Master II Génie logiciel

77
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 41: schéma de données de l’api UserDetails-service

Tous les autres schémas se comportent comme celui d’Email.

3 Conception de l’api AppelCandidature-api

a. Diagramme de classe

La figure 24 ci-dessous illustre le diagramme de classe de l’API AppelCandidature-api. Ce

diagramme présente la structure des classes, leurs attributs, méthodes et relations, offrant une
vue d’ensemble claire de la conception technique du microservice.

M. Moustapha DRAME Mémoire Master II Génie logiciel

78
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 42: Diagramme de classes de l’api AppelCandidature-api

b. Schéma de données

La Figure 43 ci-dessous montre le schéma de données de l’api Appelcandidature-api,

détaillant la structure des tables, des relations et des champs essentiels pour gérer les appels à
candidature.

M. Moustapha DRAME Mémoire Master II Génie logiciel

79
Chapitre III : Spécification, analyse des besoins et conception des APIs

Figure 43 : Le schéma de donné de l’api AppelCandidature-api

4 Conception de l’api Candidature-service

a. Diagramme de classe

La figure 44 montre le diagramme de classes de l’API Candidature-service, détaillant la

structure des classes, leurs attributs, méthodes et relations pour une compréhension claire de
son architecture.

Figure 44 : diagramme de classe de l’api candidature-service

M. Moustapha DRAME Mémoire Master II Génie logiciel

80
Chapitre III : Spécification, analyse des besoins et conception des APIs

b. Schéma de données

La figure ci-dessous montre le schéma de données de l’api candidature-service, décrivant la

structure des tables, des relations et des champs essentiels pour gérer les candidatures.

Figure 45 : Schéma de données de l’api candidature-service

5 La conception de l’api selection-api

a. Diagramme de classe

La figure 46 ci-dessous présente le diagramme de classe de l’api selection-api, détaillant la

structure des classes, leurs attributs, méthodes et relations.

Figure 46 : diagramme de classe de l’api selection-api

M. Moustapha DRAME Mémoire Master II Génie logiciel

81
Chapitre III : Spécification, analyse des besoins et conception des APIs

b. Schéma de données

La figure 47 ci-dessous montre le schéma de données de l’api selection-api. Il decrit

l’ensembles des tables avec leurs relations pour ce microservice.

Figure 47 : schéma de données de l’api selection-api

Conclusion

En résumé, l’utilisation d’OpenAPI et Swagger a grandement facilité la spécification et la

conception des API. Cette approche contract-first a assuré une grande cohérence et
compatibilité tout au long du développement, tout en simplifiant la génération de
documentation et de code. Elle a également renforcé la collaboration entre les équipes,
réduisant ainsi les erreurs et améliorant la qualité globale. Grâce à cette rigueur, les besoins
des utilisateurs ont été parfaitement intégrés, garantissant une interface conforme et fiable. Ce
succès dans la mise en œuvre prépare le terrain pour le chapitre suivant, où nous exposerons
l’implémentation des différentes APIs du projet.

M. Moustapha DRAME Mémoire Master II Génie logiciel

82
 Chapitre IV : Implémentation et présentation de l’application

Chapitre IV : Implémentation et présentation de l’application

INTRODUCTION

Ce chapitre est consacré à la réalisation de notre application. Dans un premier temps, nous
allons présenter les outils de modélisation et de développement utilisés pour la mise en œuvre
de l’application. Les technologies utilisées pour l’implémentation du Back-End seront ensuite
exposées. Ensuite, nous aborderons les choix de technologies pour l'implémentation du Front-
End. Enfin, nous terminerons avec la présentation de quelques interfaces de l’application.

I. Présentation des outils de modélisation et de développement

1 StarUML

StarUML est un logiciel de modélisation open-source qui prend en charge le cadre du langage
de modélisation unifié (UML). Il fournit plusieurs types de diagrammes et permet aux
utilisateurs de générer du code dans plusieurs langages de programmation. Avec son aide, les
développeurs peuvent créer des conceptions, des concepts et des solutions codées [10].

2 IntelliJ IDEA

IntelliJ IDEA est un environnement de développement intégré (IDE) pour Java et Kotlin
conçu pour optimiser la productivité des développeurs. Il effectue les tâches routinières et
répétitives à votre place en fournissant une saisie semi-automatique intelligente du code, une
analyse statique du code et des refactorisations. Il vous permet de vous concentrer sur le côté
positif du développement logiciel, ce qui le rend non seulement productif mais aussi agréable
[11].

3 SwaggerHub

SwaggerHub est une plateforme collaborative qui permet de définir des APIs à l'aide des
spécifications OpenAPI ou AsyncAPI et de gérer les APIs tout au long de leur cycle de
vie. SwaggerHub vous proposé par les mêmes personnes qui sont à l'origine des outils open
source Swagger. Il intègre les principaux outils Swagger (UI, Editor, Codegen, Validator)

M. Moustapha DRAME Mémoire Master II Génie logiciel

83
Chapitre IV : Implémentation et présentation de l’application

dans une plateforme unique pour vous aider à coordonner l'ensemble du flux de travail du
cycle de vie d'une API.

Avec SwaggerHub, vous pouvez [12] :

✓ Définir vos APIs au format OpenAPI ou AsyncAPI ;
✓ Héberger toutes vos définitions d'API en un seul endroit ;
✓ Stocker vos composants API courants (tels que les modèles de données et les réponses)
dans des domaines et les référencez à partir de définitions d'API ;
✓ Collaborer sur les définitions d'APIs avec votre équipe ;
✓ Pour OpenAPI : générez du code serveur et client et l’envoyer vers GitHub ;
GitLab, Bitbucket ou Azure DevOps Services ;
✓ Partager vos API publiquement et en privé ;
✓ Itérer la conception de votre API et gérez plusieurs versions de l’API.

4 Postman

Postman est une plateforme qui simplifie la création, le test et la gestion des APIs. Elle permet
de définir facilement les endpoints, paramètres et réponses attendues, tout en générant
automatiquement la documentation. L'outil permet de tester des requêtes HTTP (GET, POST,
PUT, DELETE) et d'analyser les réponses. Il offre aussi la possibilité d'automatiser des tests
via des scripts pré-exécutés avant ou après les requêtes. En somme, Postman accélère le
développement d'APIs tout en facilitant la collaboration et la gestion des workflows1.

5 Git

Git est un système de contrôle de version distribué qui est utilisé pour stocker le code source
dans le développement de logiciels afin de suivre ses modifications. Il permet aux
développeurs de travailler en collaboration avec des équipes sur des référentiels pour gérer les
versions de base de code, c'est-à-dire conserver l'historique des modifications du projet. En
utilisant git, les développeurs peuvent se déplacer de manière transparente dans les différents

1
Un workflow, c'est un enchaînement logique de requêtes API qui simule un scénario réel.

M. Moustapha DRAME Mémoire Master II Génie logiciel

84
 Chapitre IV : Implémentation et présentation de l’application

états du projet et fusionner les modifications de manière efficace, garantissant ainsi une
approche rationalisée et organisée du développement de logiciels [13].

II. Implémentation du Back-end

Pour l’implémentation du Back-end de notre application, plusieurs outils et technologies sont

utilisés. Ces technologies sont présentées dans les sections suivantes.

1 Apache Tomcat

Apache Tomcat est un serveur d’applications web open source conçu pour la programmation
en Java et développé et maintenu par Jakarta, le groupe de projets open source Java de la
fondation Apache. L’objectif initial du logiciel Apache Tomcat est d’héberger et de déployer
les servlets Java. Les servlets sont des programmes Java exécutés côté serveur. Ils reçoivent
les requêtes des clients, les interprètent et génèrent les réponses demandées. L’envoi des
résultats peut se faire de façon directe ou via un protocole comme http.

Apache Tomcat fournit les fonctionnalités de base du traitement du serveur web pour les
servlets Java. Il couvre tout le cycle de vie des servlets, qui se compose de 3 méthodes :

✓ init(): qui se charge d’initier la servlet. Cette méthode est exécutée une seule fois, soit
lors du démarrage du serveur, soit lorsqu’elle est déclenchée par le client ;
✓ service(): qui se charge de traiter les requêtes clients et de générer les réponses
adéquates ;
✓ destroy() : cette méthode est invoquée par Tomcat à la fin de l’exécution de la servlet
pour nettoyer les traces des activités et libérer les ressources.

Tomcat est un des serveurs web préférés par les développeurs Java. Il permet donc aux
développeurs d’exécuter leurs applications web Java.

2 Java

Java est un langage de programmation orienté objet, conçu pour avoir le moins de
dépendances d'implémentation possible. Il est destiné à permettre aux développeurs
d'applications d'écrire une fois et d'exécuter n'importe où (WORA), ce qui signifie que le code
Java compilé peut s'exécuter sur toutes les plates-formes qui prennent en charge Java sans

M. Moustapha DRAME Mémoire Master II Génie logiciel

85
Chapitre IV : Implémentation et présentation de l’application

avoir besoin de recompilation. Java a été développé par James Gosling chez Sun
Microsystems en mai 1995, puis acquis par Oracle en 2019. Il est largement utilisé pour
développer des applications pour les ordinateurs de bureau, le Web et les appareils mobiles.
Java est connu pour sa simplicité, sa robustesse et ses fonctionnalités de sécurité, ce qui en
fait un choix populaire pour les applications de niveau entreprise. Les applications Java sont
compilées en code octet qui peut s'exécuter sur n'importe quelle machine virtuelle Java. La
syntaxe de Java est similaire à celle de C/C++. Java facilite l'écriture, la compilation et le
débogage de programmes. Il permet de créer du code réutilisable et des programmes
modulaires [14].

3 Spring

Le Framework Spring peut être considéré comme un ensemble de sous-Frameworks,

également appelés couches, tels que Spring Aspect-Oriented Programming (AOP), Spring
Object-Relational Mapping (Spring ORM), Spring Web Flow et Spring Web MVC. Il s'agit
d'un Framework d'applications léger, utilisé pour développer des applications d'entreprise.
Vous pouvez utiliser n'importe lequel de ces modules séparément lors de la construction d'une
application Web. Les modules peuvent également être regroupés pour offrir de meilleures
fonctionnalités dans une application Web. Le Framework Spring est faiblement couplé en
raison de l'injection de dépendances [15].

Spring propose plusieurs modules : AOP pour la gestion des aspects transversaux, ORM pour
l’intégration avec Hibernate, Web Flow pour les parcours utilisateur et Web MVC pour
structurer les applications web. Son grand atout, l’injection de dépendances (DI), garantit un
code flexible et maintenable.

4 Spring Boot

Spring Boot, développé par Pivotal Software, est un Framework Java open source utilisé pour
le développement d'applications utilisant Java ou Kotlin. Ce Framework est conçu pour
simplifier le processus de création d'applications de qualité industrielle avec facilité de
développement en réduisant le code standard et en facilitant la configuration via Spring
Starters. Spring Boot est également livré avec un serveur HTTP intégré, pour permettre aux
applications d'être déployées en tant qu'applications autonomes [16].

M. Moustapha DRAME Mémoire Master II Génie logiciel

86
 Chapitre IV : Implémentation et présentation de l’application

5 API REST

REpresentational State Transfer (REST) est un style architectural qui définit un ensemble de
contraintes à utiliser pour la création de services Web. L'API REST est un moyen d'accéder
aux services Web de manière simple et flexible sans aucun traitement.

La technologie REST est généralement préférée à la technologie SOAP (Simple Object

Access Protocol), plus robuste, car REST utilise moins de bande passante, est simple et
flexible, ce qui la rend plus adaptée à l'utilisation d'Internet. Elle est utilisée pour récupérer ou
donner des informations à partir d'un service Web. Toutes les communications effectuées via
l'API REST utilisent uniquement des requêtes HTTP [17].

6 PostgreSQL

PostgreSQL est l'un des systèmes de gestion de bases de données relationnelles à usage
général les plus avancés. En tant que logiciel open source, son code source est disponible sous
licence PostgreSQL, une licence open source libérale. Toute personne possédant les
compétences nécessaires est libre d'utiliser, de modifier et de distribuer PostgreSQL sous
n'importe quelle forme. Comme il est très stable, très peu d'efforts sont nécessaires pour
maintenir ce SGBD [17].

III. Implémentation du Front-End

1 React.js

React, souvent appelé React.js ou ReactJS, est une bibliothèque JavaScript reconnue pour sa
flexibilité et son efficacité dans la création d'interfaces utilisateur interactives (IU) pour les
applications web et natives. Grâce à son architecture basée sur des composants, les
développeurs peuvent créer des éléments d'IU tels que des boutons ou des barres de
recherche, réutilisables dans toute l'application. Cela simplifie non seulement le processus de
développement, mais améliore également la maintenabilité.

L'une des fonctionnalités distinctives de React est JSX (JavaScript XML). JSX ressemble à
HTML et permet aux développeurs d'écrire du balisage directement dans leur code JavaScript.

M. Moustapha DRAME Mémoire Master II Génie logiciel

87
 Chapitre IV : Implémentation et présentation de l’application

Cette fonctionnalité unique simplifie le codage en offrant une manière plus intuitive de
structurer les composants [18].

2 Bootstrap

Bootstrap a été développé en 2011 par l'équipe du réseau social Twitter. Bootstrap est un
Framework front end (HTML5, CSS et JavaScript) spécialement conçu pour le
développement d'application web "responsive", c'est-à-dire qui s'adaptent automatiquement à
différents dispositifs et tailles d'écran (tablettes, smartphones, desktop...etc.). Il fournit des
outils avec des styles déjà en place pour des typographies, des boutons, des interfaces de
navigation et bien d'autres encore. Il peut être utilisé pour créer par exemple, des pages de site
de présentation, pour une interface graphique d'une application web ou être intégré à un thème
d'un CMS, Bootstrap est de plus en plus utilisé, il est devenu « le plus populaire des
Framework FrontOffice pour développer des projets responsive et mobile-first sur le web
[19].

IV. Présentation de l’application

Après avoir détaillé l’implémentation des API et du Front-end, il est essentiel de se pencher
sur l’interface utilisateur de l’application, véritable point de contact entre l’utilisateur et le
système. Cette section vous propose une immersion au cœur de l’application, où chaque
élément a été conçu pour offrir une expérience fluide, intuitive et agréable.

L’objectif principal de cette présentation est de mettre en avant la manière dont l’utilisateur
interagit avec l’application, depuis son arrivée sur la page d’accueil jusqu’à la navigation
entre les différentes fonctionnalités. Nous mettrons en lumière la logique de conception de
l’interface, les choix ergonomiques adoptés ainsi que les éléments visuels qui favorisent une
utilisation optimisée et accessible à tous.

Nous commencerons par examiner le graphe de navigation de l’application, qui donne une
vision globale de l’architecture et des interactions entre les différentes pages. Ensuite, nous
explorerons en détail les interfaces clés, telles que la page de démarrage, la page de
connexion, ainsi que les espaces dédiés aux profils des utilisateurs.

M. Moustapha DRAME Mémoire Master II Génie logiciel

88
Chapitre IV : Implémentation et présentation de l’application

1 Graphe de navigation de l’application

Le graphe de navigation est un élément essentiel pour comprendre l’architecture de

l’application. Il s’agit d’une représentation visuelle qui illustre les différentes pages et les
liens qui les relient, permettant ainsi d’appréhender le parcours utilisateur de manière claire et
structurée. Grâce à ce schéma, il est possible d’identifier les principaux points d’accès de
l’application et la façon dont l’utilisateur peut naviguer d’une section à une autre. Ce graphe
met également en évidence les interactions entre les modules, montrant comment les
informations circulent à travers l’application pour garantir une expérience fluide et cohérente.
En résumé, ce graphe sert de carte de navigation, permettant aux utilisateurs et aux
concepteurs de visualiser l’organisation des interfaces et d’assurer une cohérence dans
l’ergonomie et le parcours utilisateur. La figure 48 montre le graphe de navigation de notre
application.

Figure 48 : Graphe de navigation de l’application

M. Moustapha DRAME Mémoire Master II Génie logiciel

89
Chapitre IV : Implémentation et présentation de l’application

2 Présentations des pages

a. Page d’accueil principale

La page d’accueil principale est le premier point de contact de l’utilisateur avec

l’application. Elle présente l’ensemble des appels à candidatures disponibles, offrant ainsi une
vue d’ensemble des opportunités accessibles. En haut de la page, plusieurs boutons facilitent
la navigation :

• "Se connecter" permet d’accéder à la page de connexion pour s’identifier et profiter

des services personnalisés ;

• "S’inscrire" offre la possibilité de créer un nouveau compte afin d’accéder aux

fonctionnalités réservées aux utilisateurs enregistrés ;

• "Accueil" permet de revenir à la page de démarrage à tout moment, notamment

lorsque l’utilisateur se trouve sur les pages de connexion ou d’inscription.

La figure 49 présente la page d’accueil de notre application.

Figure 49 : Page d'accueil Principale

M. Moustapha DRAME Mémoire Master II Génie logiciel

90
Chapitre IV : Implémentation et présentation de l’application

b. Page d’accueil de l’administrateur

Cette page constitue le cœur de la gestion des appels à candidatures et des candidatures. Elle
regroupe l’ensemble des fonctionnalités essentielles, notamment :
• la création et la gestion des appels à candidatures,
• le suivi et le traitement des candidatures,
• la gestion des utilisateurs, incluant les candidats et les membres externes,
• la sélection des candidatures finales,
• un tableau de bord interactif permettant de visualiser des statistiques clés sur les appels
et les candidatures.

La figure 50 présente la page d’accueil d’un administrateur de notre application.

Figure 50 : page d’accueil de l’administrateur

c. Page d’accueil du responsable (de formation, DRH)

Cette page reprend la plupart des fonctionnalités de l’espace administrateur, avec quelques
spécificités :
• l’absence de gestion des utilisateurs,
• labsence de gestion des types d’appels à candidatures.

M. Moustapha DRAME Mémoire Master II Génie logiciel

91
Chapitre IV : Implémentation et présentation de l’application

Le responsable dispose ainsi d’un espace dédié à la gestion et au suivi des candidatures en
lien avec ses attributions.

d. Page d’accueil du candidat

Une fois sur la plateforme, le candidat se connecte et accède à une interface claire qui lui offre
toutes les opportunités. Cette page offre un aperçu global des appels à candidatures en cours
et facilite l’accès aux différentes actions:
• "Acceuil" : pour le dépôt d’une nouvelle candidature en toute simplicité ;
• "Mes candidatures" : pour le suivi et gestion des candidatures soumises ;
• "Info complémentaires" : pour la mise à jour et la complémentation des informations
et la gestion des données du candidat.
• La figure 51 ci-dessous présente la page d’accueil du candidat de notre application.

Figure 51 : Page d’accueil du candidat

Conclusion

Dans ce chapitre, nous avons présenté les technologies utilisées pour implémenter notre
application. Cette dernière est conçue pour répondre aux exigences spécifiques des utilisateurs
du système. Chaque utilisateur bénéficie d'une interface conviviale et intuitive lui facilitant sa
tâche. Que vous souhaitiez gérer vos candidatures, suivre leur progression ou explorer de
nouvelles opportunités, tout a été conçu pour garantir une expérience agréable et sans
complication, dans un cadre bien organisé et efficace.

M. Moustapha DRAME Mémoire Master II Génie logiciel

92
Conclusion Générale

Conclusion Générale

Pour l'obtention de notre diplôme de Master en Génie logiciel, nous avons eu l'opportunité de
réaliser un stage au sein de la Direction de l'Informatique et des Systèmes d’Information
(DISI) de l'Université Assane Seck de Ziguinchor (UASZ) dans le cadre du Projet de Gestion
Intégrée (PGI). Au cours de notre stage, nous avons travaillé sur la conception et
l’implémentation du module de gestion des recrutements au sein de l'UASZ. Nous avons ainsi
développé une application web divisée en deux parties : le Back-end et le Front-end.

Pour l’implémentation du Back-end, nous avons adopté une architecture microservices et

avons utilisé les technologies Spring Boot et Spring Cloud. Ce qui nous a permis de
développer une application efficace, fiable, sécurisée et facile à maintenir. Concernant le
Front-end, nous avons opté pour React afin de concevoir une interface utilisateur intuitive
pour faciliter la gestion des recrutements en ligne à l'UASZ.

Cette application permet désormais aux gestionnaires tels que les responsables de la DRH de
publier des offres d'emploi de façon et offre aux candidats la possibilité de soumettre leurs
candidatures aisément et de faire le suivi. En mettant en place cette automatisation, notre
objectif est de fournir aux membres des équipes de recrutement un instrument performant
pour gérer les candidatures de façon plus aisée et conviviale, tout en économisant du temps.

L'architecture microservices de cette application en constitue la grande force. Cette méthode

procure une vaste souplesse et plusieurs possibilités d'amélioration de l'application, la rendant
plus bénéfique pour l'UASZ et ses employés. On peut mentionner les améliorations suivantes
comme étant envisageables :

✓ L'amélioration des APIs actuelles en considérant les retours d'expérience des

utilisateurs ;
✓ L'intégration de nouvelles fonctionnalités ou APIs.

L'application est intégrée avec divers outils de gestion des employés par la DHR et des
formations.

M. Moustapha DRAME Mémoire Master II Génie logiciel

93
Bibliographie

Bibliographie

[1] « Que sont les microservices ? | AWS ». Consulté le: 4 février 2025. [En ligne].
Disponible sur: https://aws.amazon.com/fr/microservices/

[2] Atlassian, « Microservices et architecture monolithique », Atlassian. Consulté le: 4

février 2025. [En ligne]. Disponible sur:
https://www.atlassian.com/fr/microservices/microservices-architecture/microservices-vs-
monolith

[3] « Rapide, facile et évolutif : les principaux avantages de l’architecture orientée service ».
Consulté le: 17 mars 2025. [En ligne]. Disponible sur:
https://www.oracle.com/sn/service-oriented-architecture-soa/

[4] « What is Service-Oriented Architecture (SOA)? | IBM ». Consulté le: 17 mars 2025.
[En ligne]. Disponible sur: https://www.ibm.com/think/topics/soa

[5] « Monolithique et microservices : différence entre les architectures de développement

logiciel- AWS », Amazon Web Services, Inc. Consulté le: 4 février 2025. [En ligne].
Disponible sur: https://aws.amazon.com/fr/compare/the-difference-between-monolithic-
and-microservices-architecture/

[6] « Les 7 Méthodes de gestion de projet les plus utilisées ». Consulté le: 5 février 2025.
[En ligne]. Disponible sur: https://blog-gestion-de-projet.com/gestion-de-projet/outils-
methodes-gestion-projet/

[7] « Qu’est-ce que DevOps ? DevOps expliqué | Microsoft Azure ». Consulté le: 6 février
2025. [En ligne]. Disponible sur: https://azure.microsoft.com/fr-fr/resources/cloud-
computing-dictionary/what-is-devops

[8] « Approche Design-First Du Développement D’API : Comment L’implémenter Et

Pourquoi Cela Fonctionne », InfoQ. Consulté le: 5 février 2025. [En ligne]. Disponible
sur: https://www.infoq.com/fr/articles/design-first-api-development/

[9] « Flow de développement API Contract-first ». Consulté le: 5 février 2025. [En ligne].
Disponible sur: https://blog.yousign.io/posts/contract-first-api-development-flow

[10] « StarUML », Softonic. Consulté le: 12 février 2025. [En ligne]. Disponible sur:
https://staruml.fr.softonic.com

[11] « Getting started | IntelliJ IDEA », IntelliJ IDEA Help. Consulté le: 12 février 2025. [En
ligne]. Disponible sur: https://www.jetbrains.com/help/idea/getting-started.html

[12] « À propos | Documentation SwaggerHub ». Consulté le: 15 février 2025. [En ligne].
Disponible sur: https://support.smartbear.com/swaggerhub/docs/en/about.html

[13] « What Is a GIT Repository? », GeeksforGeeks. Consulté le: 15 février 2025. [En ligne].
Disponible sur: https://www.geeksforgeeks.org/what-is-a-git-repository/

M. Moustapha DRAME Mémoire Master II Génie logiciel

94
Bibliographie

[14] « Introduction to Java », GeeksforGeeks. Consulté le: 15 février 2025. [En ligne].
Disponible sur: https://www.geeksforgeeks.org/introduction-to-java/

[15] « Introduction to Spring Framework », GeeksforGeeks. Consulté le: 15 février 2025. [En
ligne]. Disponible sur: https://www.geeksforgeeks.org/introduction-to-spring-
framework/

[16] « Spring Boot Tutorial - Learn Spring Boot », GeeksforGeeks. Consulté le: 12 février
2025. [En ligne]. Disponible sur: https://www.geeksforgeeks.org/spring-boot/

[17] « PostgreSQL Tutorial », GeeksforGeeks. Consulté le: 17 mars 2025. [En ligne].
Disponible sur: https://www.geeksforgeeks.org/postgresql-tutorial/

[18] « What is React.js? Overview of the JavaScript Library for UI Development -

Glossary », Sanity.io. Consulté le: 19 mars 2025. [En ligne]. Disponible sur:
https://www.sanity.io/glossary/react-js

[19] H. J. J. Séraphin, « CONCEPTION D’UNE PLATEFORME DE VENTE EN LIGNE

ASSOCIÉE À UN SYSTEME DE GÉOLOCALISATION ».

M. Moustapha DRAME Mémoire Master II Génie logiciel

95