République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Carthage
Institut Supérieur des Technologies de
l’Information et de la Communication

RAPPORT DE STAGE
LICENCE EN SCIENCES DE L’INFORMATIQUE
Parcours : Génie Logiciel et systèmes d’information

Par
Nour Jenhani

Développement d’une application web pour

la publication d’offres d’emplois

Réalisé au sein de IBH Web Consulting

Soutenu publiquement le 21 Octobre 2023 devant le jury composé de :

Président : Inés Bouzidi

Rapporteur : Imén Marsit

Année Universitaire : 2023 - 2024

 République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
Université de Carthage
Institut Supérieur des Technologies de
l’Information et de la Communication

Rapport de stage
Licence en Sciences de l’informatique
Parcours : Génie Logiciel et Systèmes d’Information

Par
Nour Jenhani

Développement d’une application web pour

la publication d’offres d’emplois

Réalisé au sein de IBH Web Consulting

Autorisation de dépôt du rapport de stage :

Signature (avec cachet) de l’encadrant professionnel :

Le :
Dédicaces

Je dédie ce projet de fin d’année

À mon cher père et mon adorable mére
Lotfi Jenhani et Leyla Galai
Qui ont été d’un soutien inconditionnel et qui m’ont encouragé
tout au long de ce parcours. C’est grâce à leur amour, leur
confiance et leur soutien indéfectible que j’ai pu réaliser ce
projet. J’espère pouvoir vous rendre fiers et heureux de mes
réalisations.
À toute ma famille et mes amis proches
Merci pour vos encouragements et votre soutien tout ce temps.

Nour Jenhani

i
Remerciement

Tout d’abord, je remercie dieu de m’avoir accordé la force de traverser cette période et
de surmonter les obstacles qui se sont présentés à moi.
Avant de commencer la présentation de ce rapport, je profite de l’occasion pour
remercier du fond du cœur toute personne ayant contribué de près ou de loin à la
réalisation de ce travail. Je tiens à remercier monsieur Ben Khélifa Raed qui m’a
guidée, critiquée, et a fait des suggestions. Son encouragement permanent et son
dynamisme organisateur m’ont énormément facilité la tâche. Il m’a conseillée tout au
cours de mon stage. Il m’a relu et critiqué mon manuscrit. Je remercie également toute
l’équipe pour son accueil, son esprit convivial et chaleureux.
Enfin, je tiens à remercier tous ceux qui m’ont aidé à élaborer ce rapport de stage.

ii
Table des matières

Introduction générale 1

1 Cadre général du projet 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Domaines d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.3 Cadre de stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Méthodologie de travail et planification . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Définition d’une méthodologie . . . . . . . . . . . . . . . . . . . . . 4
1.4.2 Choix de modèle en V . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Analyse des besoins et conception 5

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . 5
2.2.3 Identification des besoins non fonctionnels . . . . . . . . . . . . . . 6
2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Diagramme des cas d’utilisation de l’admin . . . . . . . . . . . . . . 7
2.3.3 Raffinement des cas d’utilisation de l’admin . . . . . . . . . . . . . 7
2.3.4 Détails des cas d’utilisation associés à l’admin . . . . . . . . . . . . 8
[Link] Raffinement du cas d’utilisation «Gérer admin» . . . . . . 8
[Link] Raffinement du cas d’utilisation « Gérer client » . . . . . . 9
[Link] Raffinement du cas d’utilisation «Gérer catégorie» . . . . 11
2.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Description du diagramme de classe . . . . . . . . . . . . . . . . . 12
2.4.2 Description de la base de données . . . . . . . . . . . . . . . . . . 13
2.5 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 Diagramme de séquence de «S’authentifier» . . . . . . . . . . . . . 15
2.5.2 Diagramme de séquence «Ajouter admin» . . . . . . . . . . . . . . 16
2.5.3 Diagramme de séquence «Modifier admin» . . . . . . . . . . . . . . 17

iii
Table des matières Table des matières

2.5.4 Diagramme de séquence «Supprimer admin» . . . . . . . . . . . . . 18

2.5.5 Diagramme de séquence «Ajouter catégorie» . . . . . . . . . . . . . 19
2.5.6 Diagrammes de séquence «Modifier catégorie» . . . . . . . . . . . . 19
2.5.7 Diagrammes de séquence «Supprimer catégorie» . . . . . . . . . . . 20
2.5.8 Diagrammes de séquence «Ajouter client» . . . . . . . . . . . . . . 21
2.5.9 Diagrammes de séquence «Modifier client» . . . . . . . . . . . . . . 21
2.5.10 Diagrammes de séquence « Supprimer client » . . . . . . . . . . . . 22
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Réalisation 24
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Technologies de développement . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Architecture de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.1 Présentation de l’application . . . . . . . . . . . . . . . . . . . . . . 27
[Link] Interface d’authentification . . . . . . . . . . . . . . . . . 27
[Link] Interface d’administrateur . . . . . . . . . . . . . . . . . . 28
[Link] Interface Des catégories . . . . . . . . . . . . . . . . . . . 29
[Link] Interface des clients . . . . . . . . . . . . . . . . . . . . . 30
[Link] Interface des contacts . . . . . . . . . . . . . . . . . . . . 31
[Link] Interface des entreprises . . . . . . . . . . . . . . . . . . . 31
[Link] Interface des offres d’emplois . . . . . . . . . . . . . . . . 32
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Conclusion Générale 34

Netographie 35

Netographie 36

iv
Table des figures

1.1 Logo de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Processus de développement en V . . . . . . . . . . . . . . . . . . . . 4
2.3 Diagramme de cas d’utilisation de l’admin . . . . . . . . . . . . . . 7
2.4 Diagramme de cas d’utilisation «Gérer admin» . . . . . . . . . . . 8
2.5 Diagramme de cas d’utilisation «Gérer client» . . . . . . . . . . . . 9
2.6 Diagramme de cas d’utilisation «Gérer catégorie» . . . . . . . . . 11
2.7 Diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8 Diagramme de séquence du cas d’utilisation «S’authentifier» . . . 16
2.9 Diagramme de séquence du cas d’utilisation «Ajouter admin» . . 17
2.10 Diagramme de séquence du cas d’utilisation «Modifier admin» . 18
2.11 Diagramme de séquence du cas d’utilisation «Supprimer admin» 18
2.12 Diagramme de séquence du cas d’utilisation «Ajouter catégorie» 19
2.13 Diagramme de séquence du cas d’utilisation «Modifier catégorie» 20
2.14 Diagramme de séquence du cas d’utilisation «Supprimer catégorie» 20
2.15 Diagramme de séquence de cas d’utilisation «Ajouter client» . . 21
2.16 Diagramme de séquence de cas d’utilisation «Modifier client» . . 22
2.17 Diagramme de séquence de cas d’utilisation «Supprimer client» . 22
3.18 Logo Vs code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.19 Logo XAMPP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.20 Logo StarUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.21 Model MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.22 Interface d’authentification (Connexion) . . . . . . . . . . . . . . . . 28
3.23 Affichage de la liste des admins . . . . . . . . . . . . . . . . . . . . . . 28
3.24 Interface de l’ajout d’un admin . . . . . . . . . . . . . . . . . . . . . . 29
3.25 Affichage de la liste des catégories . . . . . . . . . . . . . . . . . . . . 29
3.26 Interface de l’ajout d’une catégorie . . . . . . . . . . . . . . . . . . . 29
3.27 Affichage de la liste des clients . . . . . . . . . . . . . . . . . . . . . . 30
3.28 Interface de l’ajout d’un client . . . . . . . . . . . . . . . . . . . . . 30
3.29 Affichage de la liste des contacts . . . . . . . . . . . . . . . . . . . . . 31
3.30 Interface de l’ajout d’un contact . . . . . . . . . . . . . . . . . . . . . 31
3.31 Affichage de la liste des entreprises . . . . . . . . . . . . . . . . . . 31
3.32 Interface de l’ajout d’une entreprise . . . . . . . . . . . . . . . . . . 32
3.33 Affichage de la liste des offres d’emplois . . . . . . . . . . . . . . . . 32
3.34 Interface de l’ajout d’un offre d’emploi . . . . . . . . . . . . . . . . 33

v
Liste des tableaux

2.1 Description de cas d’utilisation «Ajouter admin» . . . . . . . . . . . . . . . 8

2.2 Description de cas d’utilisation «Modifier admin» . . . . . . . . . . . . . . 9
2.3 Description de cas d’utilisation «Ajouter client» . . . . . . . . . . . . . . . 10
2.4 Description de cas d’utilisation «Modifier client» . . . . . . . . . . . . . . . 10
2.5 Description de cas d’utilisation «Ajouter catégorie» . . . . . . . . . . . . . 11
2.6 Description de cas d’utilisation «Modifier client» . . . . . . . . . . . . . . . 12
2.7 Table Administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8 Table Catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9 Table Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.10 Table Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.11 Table Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.12 Table offre d’emploi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.13 Description de l’environnement matériel . . . . . . . . . . . . . . . . . . . 24

vi
Introduction générale

Dans un monde en constante évolution où les technologies numériques transforment tous

les aspects de notre vie, le marché du travail ne fait pas exception.

Aujourd’hui, la recherche d’emploi et le recrutement ont pris un tournant décisif avec

l’émergence des applications web dédiées à la publication d’offres d’emplois.

Dans ce contexte, que nous nous sommes lancés dans la création d’une application web
dédiée à la publication d’offres d’emplois, pour offrir une solution moderne, intuitive et
efficace à ce processus crucial.

Dans le cadre de ce rapport, je veux étudier la conception et le développement d’ une

application de publication d’offres d’emplois, en mettant l’accent sur les différentes
étapes nécessaires pour la création d’une plateforme efficace et fonctionnelle.

Je veux tout d’abord présenter les objectifs du projet, ainsi que les caractéristiques
principales de l’application. Je veux ensuite décrire les différentes étapes du
développement, de la conception à la mise en ligne et la validation du produit final. Je
veux également aborder les différentes fonctionnalités que devra offrir l’application, ainsi
que les critères de sécurité et de confidentialité qui devront être respectés.

L’objectif de ce rapport est donc de fournir une vision d’ensemble détaillée de la création
d’une application de publication d’offres d’emplois.

Ce rapport a été rédigé dans le cadre d’un stage de perfectionnement à l’Institut

Supérieur des technologies de l’information et de la communication de Borj Cedria
effectué au sein d’IBH Web Consulting situé à kélibia. Afin de répondre aux différentes
exigences posées par mon sujet, j’ai articulé mon rapport autour de trois chapitres :

-Dans le premier chapitre, intitulé "Cadre général du projet", j’ai introduit l’organisme
d’accueil IBH Web Consulting puis j’ai critiqué l’existant et j’ai proposé des solutions.
Enfin,j’aborderai la méthodologie de gestion des projets.

- Le deuxième chapitre sera réservé à analyse des besoins et conception de mon

plateforme qui comportera les besoins fonctionnels et non fonctionnels, le diagramme de
classe ainsi que les diagrammes de séquences. Cette étude décrit d’une manière précise
toutes les étapes de la conception.

-Dans le troisième chapitre, j’ai présenté l’environnement de la réalisation de ce projet

ainsi que les interfaces de l’application.

Enfin, j’ai synthétisé mon rapport par une conclusion générale.

1
Chapitre 1

Cadre général du projet

1.1 Introduction
Dans ce chapitre, je veux présenter en premier lieu la description de l’organisme
d’accueil IBH Web Consulting, là où ce projet de fin d’année a été réalisé. Dans un
deuxième volet, je veux présenter le cadre général de mon projet, une critique de
l’existant, la solution proposée, et finalement le choix de la méthodologie.

1.2 Présentation de l’organisme d’accueil

1.2.1 Organisme d’accueil
IBH Web Consulting est une boîte de développement et de services informatiques, une
société de développement informatique, de conseil, de développement web, mobile,
et d’ingénierie située à Kélibia. Elle a été fondée en 2015 et offre des stages pour les
étudiants de tous les niveaux, avec un encadrement et une formation inclus.

Figure 1.1 – Logo de la société

1.2.2 Domaines d’activités

IBH Web Consulting offre des services divers tels que :
* Site web vitrine, sur mesure et native ou avec frameworks.
* Développement web (HTML, PHP, Java, JavaScript, XML, web services, UML,
jQuery, AJAX, CSS, ...).
* Développement mobile.
* Réseaux informatiques, sécurité, Cloud, ethical hacking.

2
Chapitre 1 1.3. Étude de l’existant

* Programmation logicielle (ERP, C++, Java, Android, J2EE, PHP5, .NET, Zend,
Symfony, CMS : WordPress, Magento, PrestaShop, SQL Server, Oracle, Business
Intelligence, CRM).

1.2.3 Cadre de stage

*Chef du projet : Monsieur Ben Noureddine Walid est le chef du projet, responsable de
la gestion d’IBH Web Consulting.
*Développeuse PHP : Madame Hayat Trabelsi est une développeuse PHP et ingénieure
de spécialité.
*Développeuse Android : Madame Mouna Ben Mansour est une développeuse Android.
*[Link] : Monsieur Abdelmoumen Jabloun est un webdesigner à IBH Web
Consulting.

1.3 Étude de l’existant

1.3.1 Description de l’existant
L’étude de l’existant est la base de chaque projet. En effet elle nous permet d’analyser
l’environnement de travail et d’apprendre le mode de fonctionnement de l’organisme
d’accueil, ce qui nous offre la possibilité de créer une application adaptée aux exigences
du cadre professionnel.

1.3.2 Problématique
De nos jours la recherche d’emplois occupe une place très importante dans notre
environnement. Les méthodes traditionnelles telles que les journaux ne sont pas
utilisables grâce à la numérisation afin d’offrir une solution moderne, intuitive et
efficace, et réduire plusieurs problèmes tels que :
-Manque de pertinence : Les méthodes traditionnelles de recherche d’emplois, telles que
la consultation d’annonces dans les journaux ou sur les tableaux d’affichage, manquent
souvent de pertinence.
-Les chercheurs d’emploi sont submergés par des offres qui ne correspondent pas
toujours à leurs compétences et à leurs aspirations, ce qui rend la recherche fastidieuse
et décourageante.
-Limitations géographiques : Les méthodes traditionnelles limitent souvent les
opportunités aux entreprises locales, ce qui restreint les possibilités de mobilité et de
découverte de nouvelles options professionnelles. Pour finir, les lacunes des solutions
traditionnelles d’offres d’emplois, justifient la création de cette application qui surmonte
ces défis en offrant une expérience plus efficace, transparente et centrée sur l’utilisateur.

1.3.3 Solution proposée

Les solutions traditionnelles d’offres d’emplois présentent plusieurs limitations qui
entravent l’efficacité et l’expérience des chercheurs d’emploi ainsi que des employeurs.
Ces lacunes soulignent la nécessité d’innover et de développer une nouvelle application
pour offrir une expérience plus pertinente, transparente et moderne.

3
Chapitre 1 1.4. Méthodologie de travail et planification

1.4 Méthodologie de travail et planification

1.4.1 Définition d’une méthodologie
Pour s’assurer que le projet se déroule comme souhaité et dans les délais, une
organisation méthodologique est essentielle. Nous avons choisi d’utiliser le modèle en
forme de V pour ce projet.

Figure 1.2 – Processus de développement en V

Nous constatons également la présence de deux axes : le temps et le détail ; plus on

avance dans l’étude, plus le niveau de détail est précis. La mise en place de cet outil
permet de préparer en amont les phases de spécification des besoins, de proposer
diverses phases de test en relation avec la description des besoins initiaux, et de définir
clairement le périmètre des rôles et des étapes.

1.4.2 Choix de modèle en V

Nous avons choisi de travailler avec le modèle en V pour certaines raisons, notamment
une meilleure spécification, une prévention des erreurs, et une meilleure planification du
projet.

1.5 Conclusion
Dans ce chapitre, j’ai défini la société d’accueil où j’ai réalisé mon projet de fin d’année.
J’ai aussi présenté la problématique attaquée et la solution que nous envisageons pour la
résoudre. Le chapitre suivant sera consacré à l’étude conceptuelle.

4
chapitre 2

Analyse des besoins et conception

2.1 Introduction
Ce chapitre est consacré à l’analyse des besoins détaillées, l’objectif est de construire à
partir des spécifications des besoins un modèle simple et de fournir une description plus
détaillée des fonctions et des services à travers des diagrammes d’utilisation, de
séquences et de classe.

2.2 Analyse des besoins

Une méthode de conception est une démarche générale reflétant une philosophie de
présentation et de suivi du système. L’analyse des besoins est l’étape la plus importante
du cycle de développement d’une application. En fait, il peut mieux comprendre le
travail requis pour identifier les besoins des différents utilisateurs que l’application
effectue.

2.2.1 Identification des acteurs

Un acteur est une personne physique ou morale prenant part ou affectée par l’action ou
le projet en question. Il faut donc commencer par bien préciser par rapport à quelle
action ou suite d’actions on cherche à déterminer qui sont et ce que sont les acteurs.
Mon plate-forme contient un seul acteur qui agit directement avec le système et qui est
l’administrateur. Ce dernier est le superviseur qui possède toutes les permissions de
contrôle pour gérer les offres d’emplois. Il est le seul personne qui accède à la plateforme
dont il a la possibilité d’ajouter, modifier et supprimer des sous-admins, des clients, des
catégories, des contacts, des offres d’emplois et des entreprises sur le site et de les gérer.

2.2.2 Identification des besoins fonctionnels

Un besoin fonctionnel est un besoin direct exprimant une réponse à une action,
demande ou information système. J’introduit ci-dessous les différentes fonctionnalités
que mon application va offrir à ses utilisateurs en fonction de leurs rôles :
Administrateur : L’administrateur ne peut accéder à l’authentification que via l’interface
Login, et l’authentification lui permettra d’accéder à l’arrière-plan de la plateforme. Une
fois l’administrateur du site connecté, la liste suivante des fonctionnalités lui sera
disponible :

5
Chapitre 2 2.3. Conception

-Gérer les sous-admins : Un administrateur peut ajouter, supprimer ou modifier des

sous-admins.
-Gérer les catégories : Un administrateur peut ajouter, supprimer ou modifier des
catégories.
-Gérer les contacts : Un administrateur peut ajouter, supprimer ou modifier des contacts.
-Gérer les clients : Un administrateur peut ajouter, supprimer ou modifier des clients.
-Gérer les entreprises : Un administrateur peut ajouter, supprimer ou modifier les
entreprises.
-Gérer les offres d’emplois : Un administrateur peut ajouter, supprimer ou modifier les
offres d’emploi.

2.2.3 Identification des besoins non fonctionnels

Les besoins non fonctionnels sont des exigences qui ne décrivent pas directement les
fonctionnalités du produit ou du service, mais plutôt les caractéristiques qui doivent être
respectées pour satisfaire les attentes des utilisateurs et les contraintes du système. Ces
exigences sont également appelées "exigences de qualité" ou "exigences non techniques".

*Rapidité : Il est clairement établi que la vitesse d’affichage influence fortement

l’efficacité de l’application. C’est pour cette raison qu’il faut développer une application
fournissant des résultats efficaces et cohérents et dans un temps négligeable suite aux
multiples requêtes issues de plusieurs utilisateurs et de différents systèmes d’exploitation
ou différents terminaux.

*User-Expérience (UX) : L’application devra être facilement navigable (pas de bugs ni

de plantages) permettant une facilité et rapidité d’emploi avec des interfaces
ergonomiques et pertinentes.

*Fiabilité : Les résultats apportés par l’application doivent être fiables et reflètent
effectivement l’état de la base au moment de son interrogation, c’est-à-dire des données
mises à jour en temps réel.

*Sécurité : La sécurité des différents outils et organes de la plateforme ainsi que ses
bases de données et relais doit être soigneusement conçue et réalisée. Ce Besoin est
indispensable surtout en traitant des informations confidentielles et privées des différents
utilisateurs .

2.3 Conception
2.3.1 Langage de modélisation UML
Pour modéliser mon application, j’ai utilisé UML (Unified Modeling Language).
Il se définit comme un langage de modélisation et un puissant moyen de communication
qui facilite la compréhension des représentations et des solutions, en ce sens qu’UML
exprime les solutions d’objets intuitifs. Il facilite la comparaison et l’évaluation des
solutions, la spécification, la création et la documentation des logiciels Artefact d’un
système intensif qui cartographie l’architecture logicielle. Il concocte des solutions et
communique des informations commerciales.
Dans ce sens, j’ai choisi 3 diagrammes UML :

6
Chapitre 2 2.3. Conception

-Diagramme de cas d’utilisation pour donner une vision globale du comportement

fonctionnel de notre système.
-Diagramme de classe pour présenter les classes et les interfaces des systèmes ainsi que
les différentes relations entre elles.
-Diagramme de séquence pour montrer les interactions entre les objets.

2.3.2 Diagramme des cas d’utilisation de l’admin

Un diagramme de cas d’utilisation est une description d’un ensemble de séquences
d’actions. Le but d’un cas d’utilisation est de construire les exigences des acteurs et les
objectifs correspondants du système.

Figure 2.3 – Diagramme de cas d’utilisation de l’admin

2.3.3 Raffinement des cas d’utilisation de l’admin

Pour modéliser des systèmes informatiques, il est nécessaire de faire une description de
chaque cas d’utilisation. Cette dernière est un suppport qui sert à clarifier les exigences
et les fonctionnalités du système en offrant des scénarios détaillés et faciles à
comprendre. Ainsi, j’introduit dans la partie suivante une description approfondie des
différents cas d’utilisation.

7
Chapitre 2 2.3. Conception

2.3.4 Détails des cas d’utilisation associés à l’admin

[Link] Raffinement du cas d’utilisation «Gérer admin»
Dans cette étape, j’ai illustré le diagramme du cas d’utilisation «Gérer admin» présenté
dans la figure et suivi par des descriptions textuelles.

Figure 2.4 – Diagramme de cas d’utilisation «Gérer admin»

Table 2.1 – Description de cas d’utilisation «Ajouter admin»

Cas d’utilisation Ajouter admin
Acteur Admin
Précondition Admin est authentifié
Post-condition Admin ajouté à la base de données
Scénario principal *L’admin choisit l’option «Ajouter admin».
*L’admin remplit le formulaire d’ajout.
*L’admin clique sur le bouton «Ajouter».
*Le système ajoute l’admin.
*L’admin est affiché.

Affichage d’un message d’erreur si un champs du

formulaire n’est pas rempli, ou bien erreur dans
Scénario alternatif les données saisies ou bien aussi au cas où
l’admin existe déjà.

8
Chapitre 2 2.3. Conception

Table 2.2 – Description de cas d’utilisation «Modifier admin»

Cas d’utilisation Modifier admin
Acteur Admin
Précondition Admin est authentifié
Post-condition Admin modifié
Scénario principal * Le système affiche la liste des admins.
* L’admin choisit le sous-admin à modifier.
* Le système récupère les coordonnées de
cet sous-admin et l’affiche .
* L’admin modifie les coordonnées et valide
la modification.
* Le système affiche le sous-admin modifié.

Affichage d’un message d’erreur si un

Scénario alternatif
champs du formulaire n’est pas rempli.

[Link] Raffinement du cas d’utilisation « Gérer client »

Dans cette étape, je veux illustrer le diagramme du cas d’utilisation «Gérer client»
présenté dans la figure et suivi par des descriptions textuelles.

Figure 2.5 – Diagramme de cas d’utilisation «Gérer client»

9
Chapitre 2 2.3. Conception

Table 2.3 – Description de cas d’utilisation «Ajouter client»

Cas d’utilisation Ajouter client
Acteur Admin
Précondition Admin est authentifié
Post-condition Client ajouté a la base de données
Scénario principal * L’admin choisit l’option «Ajouter client».
* L’admin remplit le formulaire d’ajout.
* L’admin clique sur le bouton «Ajouter» .
* Le système ajoute le client .
* Le client est affiché.

Affichage d’un message d’erreur si un

Scénario alternatif champs du formulaire n’est pas rempli.

Table 2.4 – Description de cas d’utilisation «Modifier client»

Cas d’utilisation Modifier client
Acteur Admin
Précondition Admin est authentifié
Post-condition Client modifié
Scénario principal * Le système affiche la liste des clients.
* L’admin choisit le client à modifier.
* Le système récupère les coordonnées de ce
client et l’affiche .
* L’admin modifie les coordonnées et valide
la modification.
* Le système affiche le client modifié.

Affichage d’un message d’erreur si un

Scénario alternatif champs du formulaire n’est pas rempli.

10
Chapitre 2 2.3. Conception

[Link] Raffinement du cas d’utilisation «Gérer catégorie»

Dans cette étape, je veux illustrer le diagramme du cas d’utilisation «Gérer catégorie»
présenté dans la figure et suivi par des descriptions textuelles.

Figure 2.6 – Diagramme de cas d’utilisation «Gérer catégorie»

Table 2.5 – Description de cas d’utilisation «Ajouter catégorie»

Cas d’utilisation Ajouter catégorie
Acteur Admin
Précondition Admin est authentifié
Post-condition Catégorie ajouté à la base de données
* L’admin choisit l’option «Ajouter
Scénario principal
catégorie».
* L’admin remplit le formulaire d’ajout .
* L’admin clique sur le bouton «Ajouter» .
* Le système ajoute la catégorie .
* La catégorie est affichée.

Affichage d’un message d’erreur si un

Scénario alternatif champs du formulaire n’est pas rempli.

11
Chapitre 2 2.4. Diagramme de classe

Table 2.6 – Description de cas d’utilisation «Modifier client»

Cas d’utilisation Modifier catégorie
Acteur Admin
Précondition Admin est authentifié
Post-condition Catégorie modifiée
Scénario principal * Le système affiche la liste des catégories.
* L’admin choisit la catégorie à modifier.
* Le système récupère les détails de cette
catégorie et l’affiche .
* L’admin modifie les détails et valide la
modification.
* Le système affiche la catégorie modifié.

Affichage d’un message d’erreur si un

Scénario alternatif champs du formulaire n’est pas rempli.

2.4 Diagramme de classe

Cet outil de conception présente une structure statique d’un système logiciel. Il donne
une vue générale sur un groupe de classes, en précisons leurs attributs, leurs opérations
et les relations entre eux. Ce diagramme nous permet d’avoir une représentation
graphique claire des composants du système et de discuter des concepts et des
interactions de manière plus concrète.

2.4.1 Description du diagramme de classe

Ce diagramme comporte 6 classes : La classe administrateur contient les attributs et les
méthodes relatifs aux administrateurs. Ces derniers gèrent les clients et les entreprises
qui présentent des internautes qui vont postuler des offres d’emplois. L’admin peut
également gérer les offres d’emplois ainsi que les sous-admins et les contacter. La classe
administrateur gère les catégories des emplois et la liste de messages reçus à travers la
classe contact.
On trouve dans la figure 2.7, les différentes classes qui présentent notre base de données.

12
Chapitre 2 2.4. Diagramme de classe

Figure 2.7 – Diagramme de classe global

2.4.2 Description de la base de données

Je veux décrire maintenant les différentes classes de mon diagramme de classe qui peut
nous servir pour décrire notre base de données. Dans ce qui suit, je veux présenter les
différentes tables de notre BD associées à leurs propriétés respectives.

13
Chapitre 2 2.4. Diagramme de classe

Table 2.7 – Table Administrateur

Champs Signification
IdAdmin Identifie l’administrateur (clé primaire)
Nom Identifie le nom de l’administrateur
Email Adresse email unique pour l’authentification
Login Identifie l’utilisateur lors de la connexion
Mot de passe de l’administrateur
PSW

Table 2.8 – Table Catégorie

Champs Signification
IdCatégorie Identifie la catégorie (clé primaire)
Nom Identifie le nom de la catégorie(libellé)
Image Identifie la catégorie en description visuelle

Table 2.9 – Table Client

Champs Signification
IdClient Identifie le client (clé primaire)
Nom Identifie le nom du client
Email Adresse email unique pour l’authentification
Login Identifie l’utilisateur lors de la connexion
PSW Mot de passe du client
Tél Téléphone du client

14
Chapitre 2 2.5. Diagrammes de séquence

Table 2.10 – Table Contact

Champs Signification
IdContact Identifie le contact(clé primaire)
Email Adresse email unique pour l’authentification
Sujet Sujet du contact
Message Message pour le contact
Nombre de notifications(Message lus et non
Show
lus)

Table 2.11 – Table Entreprise

Champs Signification
IdEntreprise Identifie l’entreprise (clé primaire)
NomCEO Identifie le nom du fondateur de l’entreprise
RaisonSocial Identifie le nom de l’entreprise
Matricule Matricule de l’entreprise
Téléphone Téléphone de l’entreprise
Adresse Adresse de l’entreprise
Email Adresse email unique pour l’authentification
Login Identifie l’utilisateur lors de la connexion
PSW Mot de passe de l’entreprise

Table 2.12 – Table offre d’emploi

Champs Signification
IdOffre Identifie l’offre d’emploi (clé primaire)
Nom Identifie le nom de l’offre
Catégorie Identifie la catégorie de l’emploi
Description Une description sur l’offre d’emploi

2.5 Diagrammes de séquence

Le diagramme de séquence présente le processus exact de l’exécution des actions et la
définition des règles pour les exécuter par la modélisation de l’ensemble des interactions
entre les éléments de base de notre application.

2.5.1 Diagramme de séquence de «S’authentifier»

Les utilisateurs doivent s’authentifier à l’aide d’une adresse email et d’un mot de passe
pour pouvoir accéder à leur compte dans l’application. La figure ci-dessous illustre le
diagramme de séquence du cas d’utilisation «S’authentifier».

15
Chapitre 2 2.5. Diagrammes de séquence

Figure 2.8 – Diagramme de séquence du cas d’utilisation «S’authentifier»

2.5.2 Diagramme de séquence «Ajouter admin»

La figure ci-dessous illustre le diagramme de séquence du cas d’utilisation «Ajouter
admin».
Dans ce diagramme, l’admin doit accéder au formulaire d’ajout d’un sous-admin
en cliquant sur le bouton «Ajouter».

16
Chapitre 2 2.5. Diagrammes de séquence

Figure 2.9 – Diagramme de séquence du cas d’utilisation «Ajouter admin»

2.5.3 Diagramme de séquence «Modifier admin»

La figure ci-dessous illustre le diagramme de séquence du cas d’utilisation «Modifier
admin».
Dans ce diagramme, l’admin doit accéder au formulaire de modification d’un sous-admin
en cliquant sur le bouton «Modifier».

17
Chapitre 2 2.5. Diagrammes de séquence

Figure 2.10 – Diagramme de séquence du cas d’utilisation «Modifier admin»

2.5.4 Diagramme de séquence «Supprimer admin»

La figure ci-dessous illustre le diagramme de séquence du cas d’utilisation «Supprimer
admin». Dans ce diagramme, l’admin doit accéder au formulaire de supprission d’un
sous-admin en cliquant sur le bouton «Supprimer».

Figure 2.11 – Diagramme de séquence du cas d’utilisation «Supprimer admin»

18
Chapitre 2 2.5. Diagrammes de séquence

2.5.5 Diagramme de séquence «Ajouter catégorie»

La figure ci-dessous illustre le diagramme de séquence du cas d’utilisation «Ajouter
catégorie».
Dans ce diagramme, l’admin doit accéder au formulaire d’ajout d’une catégorie en
cliquant sur le bouton «Ajouter».

Figure 2.12 – Diagramme de séquence du cas d’utilisation «Ajouter catégorie»

2.5.6 Diagrammes de séquence «Modifier catégorie»

La figure ci-dessous illustre le diagramme de séquence du cas d’utilisation «Modifier
catégorie».
Dans ce diagramme, l’admin doit accéder au formulaire de modification d’une catégorie
en cliquant sur le bouton «Modifier».

19
Chapitre 2 2.5. Diagrammes de séquence

Figure 2.13 – Diagramme de séquence du cas d’utilisation «Modifier catégo-

rie»

2.5.7 Diagrammes de séquence «Supprimer catégorie»

La figure ci-dessous illustre le diagramme de séquence du cas d’utilisation «Supprimer
catégorie».
Dans ce diagramme, l’admin doit accéder au formulaire de supprission d’une catégorie
en cliquant sur le bouton «Supprimer».

Figure 2.14 – Diagramme de séquence du cas d’utilisation «Supprimer caté-

gorie»

20
Chapitre 2 2.5. Diagrammes de séquence

2.5.8 Diagrammes de séquence «Ajouter client»

La figure ci-dessous illustre le diagramme de séquence du cas d’utilisation «Ajouter
client». Dans ce diagramme, l’admin doit accéder au formulaire d’ajout d’un client en
cliquant sur le bouton «ajouter».

Figure 2.15 – Diagramme de séquence de cas d’utilisation «Ajouter client»

2.5.9 Diagrammes de séquence «Modifier client»

La figure ci-dessous illustre le diagramme de séquence du cas d’utilisation «Modifier
client». Dans ce diagramme, l’admin doit accéder au formulaire de modification d’un
client en cliquant sur le bouton «Modifier».

21
Chapitre 2 2.5. Diagrammes de séquence

Figure 2.16 – Diagramme de séquence de cas d’utilisation «Modifier client»

2.5.10 Diagrammes de séquence « Supprimer client »

La figure ci-dessous illustre le diagramme de séquence du cas d’utilisation «Supprimer
client» Dans ce diagramme, l’admin doit accéder au formulaire de Supprission d’un
client en cliquant sur le bouton «Supprimer ».

Figure 2.17 – Diagramme de séquence de cas d’utilisation «Supprimer client»

22
Chapitre 2 2.6. Conclusion

2.6 Conclusion
En résumé, l’identification des acteurs et leurs besoins nous a permis de réaliser la
modélisation de la solution qu’on a proposé et de la présenté dans des différents types de
diagrammes (classe, séquence ...).

23
chapitre 3

Réalisation
3.1 Introduction
Jusqu’à présent, j’ai donné un aperçu sur les différents aspects du projet : Allant du
cahier des charges jusqu’à la conception. Un autre aspect tout aussi important de ce
projet est de rassembler la pile des technologies qui m’a aidé à réaliser le travail
correctement. Dans ce chapitre, je veux exposer les détails techniques tels que les
technologies et langages de programmation choisies et le matériel utilisé. En outre, je
veux partager quelques captures d’écran de mon application pour montrer quelques-uns
des résultats et scénarios obtenus.

3.2 Environnement de travail

Lors de l’élaboration d’une application informatique, nous devons être conscients de
l’importance de l’environnement de développement, comme nous sommes censés être à
l’aise avec lui. Dans cette partie, je veux étudier les choix des outils matériels, des outils
logiciels et des technologies de développement adoptées.

3.2.1 Environnement matériel

Au cours de la phase de la réalisation de mon projet, j’ai utilisé un ordinateur ayant les
caractéristiques suivantes :

Table 3.13 – Description de l’environnement matériel

PC Asus
Mémoire 8,00 Go
Système d’exploitation 64 bits,Windows 11
Système d’exploitation processeur x64

Intel(R) Core(TM) i5-1135G7 Processor

Processeur
2.4GHz(8M Cache,up to [Link],4 cores)

3.2.2 Environnement logiciel

Dans mon projet, j’ai utilisé les logiciels suivants :

24
Chapitre 3 3.2. Environnement de travail

Visual Studio Code :

Visual Studio Code est un éditeur de code simplifié, qui est gratuit et développé en open
source par Microsoft. Il fonctionne sous Windows, mac OS et Linux. Il fournit aux
développeurs à la fois un environnement de développement intégré avec des outils
permettant de faire avancer les projets techniques, de l’édition, à la construction,
jusqu’au débogage.[1]

Figure 3.18 – Logo Vs code

XAMPP :
XAMPP est un ensemble de logiciels qui permet de mettre en place facilement un
serveur Web confidentiel, un serveur FTP et un serveur de messagerie électronique.
Simple d’utilisation, il est à la porté d’un grand nombre de personnes puisqu’il ne
demande aucune connaissance particulière.[2]

Figure 3.19 – Logo XAMPP server

StarUML :
J’ai exploité pour la modélisation UML (Unified Modeling Language) de l’application le
logiciel StarUML qui permet de modéliser les traitements informatiques et leurs bases de
données associées.

Figure 3.20 – Logo StarUML

25
Chapitre 3 3.3. Technologies de développement

3.3 Technologies de développement

Dans cette partie, j’ai présenté les différents langages de programmation, technologies et
Frameworks qui ont servis à l’implémentation de mon application.
HTML5 : Est l’abréviation de Hypertext Markup Language, est l’ensemble des
symboles de balisage ou des codes insérés dans un fichier destiné à être affiché sur une
page de navigateur World Wide Web. Le balisage cite au navigateur Web comment
afficher les mots et les images d’une page Web pour l’utilisateur. Chaque code individuel
est appelé un élément.[3]
CSS3 : Est l’acronyme de Cascading Style Sheets (feuilles de styles en cascade), servent
à gérer l’apparence de la page web (agencement, positionnement, décoration, couleurs,
taille du texte, etc). Le langage HTML est accompagné du CSS pour donner une page
web avec du style, c’est-à-dire la manière pour laquelle doit être affichée une page.[4]
Bootstrap : Est un framework développé par l’équipe du réseau social Twitter,
proposé en open source, ce framework utilisant les langages HTML, CSS et JavaScript
fournit aux développeurs des outils pour créer facilement un site. Il est pensé pour
développer des sites avec un design réactif, qui s’adapte à tout type d’écran. 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.[5]
Laravel : Est un framework web open-source écrit en PHP respectant le principe
modèle-vue-contrôleur et entièrement développé en programmation orientée objet. Cette
technologie permet de créer des applications web innovantes en offrant une large gamme
d’outils robustes et évolutif qui facilite le processus de développement et produit des
bases de codes bien structurés et facile à maintenir.[6]

3.4 Architecture de travail

Dans cette section, je veux définir l’architecture que j’ai choisie pour mon application.
Ce n’est autre que le modèle MVC ou Modèle-Vue-Contrôleur le plus populaire pour les
applications web. Ce motif d’architecture est composé de trois parties ayant trois rôles
différents qui sont :
Modèle :
Représente l’algorithmique de l’application, il a pour rôle de traiter les données et
interagir avec la base de données.
Vue :
Est tout simplement l’interface de l’application. C’est la partie responsable des
interactions avec l’utilisateur et elle a pour rôle de présenter les données.
Contrôleur :
Joue le rôle de chef d’orchestre, sa propriété est la réception et l’analyse des requêtes
surtout qu’il joue le rôle de lien entre le Modèle et le Vue.
L’objectif du modèle MVC est de bien séparer les données, les traitements et la
présentation de ces données. La règle est divisée pour mieux régner. Chaque couche est
spécialisée, et est donc dédiée aux tâches qu’elles savent faire le mieux ce qui donne plus
de souplesse pour la maintenabilité et l’évolutivité du système. De plus, ce modèle a
pour objectif le gain de temps de maintenance et d’évolution de l’application.

26
Chapitre 3 3.5. Réalisation

Figure 3.21 – Model MVC

3.5 Réalisation
L’objectif principal de ce projet est de fournir une application Web dynamique pour la
publication d’offres d’emplois en ligne.

3.5.1 Présentation de l’application

Le Back Office de mon application comporte spécialement un compte administrateur. La
page d’accueil de cette partie back-office est accessible moyennant une authentification
(login et mot de passe). Un message d’erreur est affiché au cas où les données sont
invalides ou bien s’il existe un champs vide.

[Link] Interface d’authentification

-La phase d’authentification est une étape importante dans toute application.
Elle permet de vérifier que seules les personnes autorisées ont l’accès aux fonctionnalités
de l’application.

27
Chapitre 3 3.5. Réalisation

Figure 3.22 – Interface d’authentification (Connexion)

[Link] Interface d’administrateur

-L’administrateur a tous les droits de suppression et de modification de tous les
sous-admins qui gérent l’application.

Figure 3.23 – Affichage de la liste des admins

28
Chapitre 3 3.5. Réalisation

-L’administrateur peut aussi ajouter des sous-admins.

Figure 3.24 – Interface de l’ajout d’un admin

[Link] Interface Des catégories

-L’administrateur peut modifier, ou supprimer des catégories d’offres d’emplois .

Figure 3.25 – Affichage de la liste des catégories

-L’administrateur peut aussi ajouter des catégories d’offres d’emplois.

Figure 3.26 – Interface de l’ajout d’une catégorie

29
Chapitre 3 3.5. Réalisation

[Link] Interface des clients

-L’administrateur peut modifier, ou supprimer des clients .

Figure 3.27 – Affichage de la liste des clients

-L’administrateur peut aussi ajouter des clients.

Figure 3.28 – Interface de l’ajout d’un client

30
Chapitre 3 3.5. Réalisation

[Link] Interface des contacts

-L’administrateur peut modifier, ou supprimer des contacts.

Figure 3.29 – Affichage de la liste des contacts

-L’administrateur peut ajouter des contacts.

Figure 3.30 – Interface de l’ajout d’un contact

[Link] Interface des entreprises

- L’administrateur peut modifier, ou supprimer des entreprises.

Figure 3.31 – Affichage de la liste des entreprises

31
Chapitre 3 3.5. Réalisation

-L’administrateur peut ajouter des entreprises .

Figure 3.32 – Interface de l’ajout d’une entreprise

[Link] Interface des offres d’emplois

- L’administrateur peut modifier, ou supprimer des offres d’emplois.

Figure 3.33 – Affichage de la liste des offres d’emplois

32
Chapitre 3 3.6. Conclusion

-L’administrateur peut ajouter des offres d’emplois .

Figure 3.34 – Interface de l’ajout d’un offre d’emploi

3.6 Conclusion
Ce chapitre a été consacré à la présentation de mon travail accompli. En fait, j’ai
présenté le plan de travail. Ensuite, j’ai décrit les environnements matériels et logiciels
utilisés pour son élaboration. Enfin, j’ai illustré mon application en présentant un
ensemble de captures d’écran des principales tâches effectuées.

33
Conclusion Générale

A la fin de ce rapport, je peux dire que le stage que je l’ai effectué m’ a donné une bonne
occasion pour mettre en pratique mes connaissances théoriques. Cela m’ offre une
certaine responsabilité et solidifie mes connaissances à la fois théoriques et pratiques.
C’est l’objet d’un tel stage, j’ai pu réaliser un projet dans toutes ses étapes.
J’ai commencé par identifier mes besoins et les modéliser sous la forme de diagrammes
de cas d’utilisation global. Puis, je l’ai raffiné en utilisant les descriptions textuelles, les
diagrammes de séquence et de classe. Au cours du processus de conception, j’ai utilisé
UML, un outil graphique pratique pour illustrer mon approche. J’ai entamé également
la mise en œuvre de ce projet ce qui a donné comme résultat une application web
dynamique pour la publication d’offres d’emplois en ligne.
Ce projet a été une expérience intéressante car il m’a permis de m’organiser,
d’apprendre le travail en équipe et d’améliorer mes connaissances et mes compétences
pour différents outils et langages de programmation. A la fin du stage, je peux dire que
j’ai atteint les objectifs que j’ai fixés. J’ai également pris soin d’ajouter quelques
fonctionnalités supplémentaires, notamment les suivantes :
*Faire une application sécurisée.
*Travailler sur le back office.
*Faciliter l’utilisation des interfaces pour tous les administrateurs.
Toutefois, il reste bien des perspectives pour améliorer l’expérience utilisateur et
l’efficacité de l’application notamment :
*Ajouter plus de fonctionnalités dans la partie Back Office.
*Rendre l’application plus sécurisée.

34
Netographie

[1] Visual Studio Code

"https ://[Link]/tools/visual-studio-code/"
[2] XAMPP
"http ://[Link]/[Link] ?logiciel44"
[3] HTML5
“https ://[Link]/web-tech/dictionnaire-du-webmastering”
[4] CSS3
“http ://[Link]/css/”
[5] Bootstrap
"https ://[Link]/web-tech/developpeur/1159810-bootstrap-definition-
tutorielsastuces-pratiques/"
[6] Laravel
"https ://[Link]/wiki/Laravel"

35
Bibliographie

36