Application Gestion Concours

MEMOIRE
DE STAGE DE FIN D’ETUDES

Pour l’obtention du
«Mastère professionnel en Nouvelles Technologies des

Télécommunications et Réseaux (N2TR)»
Présenté par :
Makram HDIDER
Titre
Développement d'une application web pour la gestion des concours
(mutation, intégration et inscription à une deuxième spécialité)à l'université de Gabès
Soutenu le : 08/12/2018
Devant le jury :
Président : Mme. BOUCETTA Hela
Encadreur : Mme. HOUISSA Houda
Rapporteur : Mme. BEN YOUNES Ahlem
Année Universitaire : 2017 / 2018

Dédicaces
A mes chers parents,

A ma chère épouse,
A mes adorables enfants,
A toute ma famille,
A mes chères amies,
Je dédie ce modeste travail,
Qu’ils y trouvent l’expression de ma gratitude et de ma
profonde affection.
Makram HDIDER
i
Remerciements
C’est avec une grande gratitude et reconnaissance que je réserve

ces lignes qui s’adressent à toutes les personnes qui ont contribué à
l’élaboration de ce projet de fin d’études et qui m'ont aidé lors de la
rédaction de ce rapport.
Je tiens en premier lieu à adresser ma reconnaissance et mes

remerciements à mon encadreur de mémoire, Madame Houda
REKAYA Ep HOUISSA, pour son encadrement et sa disponibilité, ainsi
que pour la richesse et la qualité de son enseignement.
Je remercie également mon encadreur de L’université de Gabès,

Monsieur Sadok FLAHI pour sa collaboration et ses conseils précieux
qui m’ont été d’une grande utilité lors de la réalisation des analyses
statistiques. Nous nous permettons de remercier également ceux qui
nous font l’honneur de participer et de siège dans ce jury et être les
rapporteurs de ce modeste travail.
ii
Sommaire
Introduction générale .............................................................................................................. 1
Chapitre 1 Etude préalable ..................................................................................................... 3
1.1 Introduction ............................................................................................................................... 3
1.2 Etude de l’existant :.................................................................................................................... 3
1.3 Critique de l’existant :................................................................................................................. 4
1.4 Solution proposée : ..................................................................................................................... 4
1.5 Spécifications : ........................................................................................................................... 5
1.5.1 Spécification des besoins fonctionnels : .......................................................................................... 5
1.5.2 Spécification des besoins non fonctionnels : .................................................................................... 6
1.5.3 Identification des acteurs: ................................................................................................................ 6
1.5.4 Les diagrammes des cas d’utilisation: .............................................................................................. 7
1.5.4.1 Cas d’utilisation préliminaire:.................................................................................................... 7
1.5.4.2 Cas d’utilisations détaillés: ........................................................................................................ 9
1.5.4.3 Cas d’utilisation «S’authentifier » ............................................................................................. 9
1.5.4.4 Cas d’utilisation «Gérer les comptes » .................................................................................... 10
1.5.4.5 Cas d’utilisation «Gérer les candidatures ».............................................................................. 12
1.5.4.6 Cas d’utilisation «Gérer les établissements » .......................................................................... 15
1.5.4.7 Cas d’utilisation «Gérer les filières»........................................................................................ 17
1.5.4.8 Cas d’utilisation «Gérer le calendrier du concours» ................................................................ 18
Chapitre 2 Conception ................................................................................................... 21
2.1 Introduction ............................................................................................................................. 21
2.2 Architecture de l’application .................................................................................................... 21
iii
2.2.1 Présentation de l'architecture client/serveur.................................................................................... 21
2.2.2 Les avantages de l’architecture client/seveur ............................................................................. 22
2.3 Conception détaillée : ............................................................................................................... 23
2.3.1 Vue statique : Diagramme de classes .......................................................................................... 23
2.3.2 Vue dynamique : les diagrammes de séquences ......................................................................... 24
2.3.2.1 Diagramme de séquence système du cas d’utilisation « S’authentifier » ................................ 24
2.3.2.2 Diagramme de séquence système du cas d’utilisation « consulter un compte » ...................... 24
2.3.2.3 Diagramme de séquence système du cas d’utilisation «créer un compte» .............................. 26
2.3.2.4 Diagramme de séquence système du cas d’utilisation « postuler une candidature» ................ 27
2.3.2.5 Diagramme de séquence système du cas d’utilisation « consulter les établissements » .......... 28
2.3.2.6 Diagramme de séquence système du cas d’utilisation « affecter un établissement à une filière»
....................................................................................................................................................... 29
Chapitre 3 Réalisation ............................................................................................................ 31
3.1 Introduction ............................................................................................................................. 31
3.2 Environnement de travail ......................................................................................................... 31
3.2.1 Environnement matériel .................................................................................................................. 31
3.2.2 Environnement logiciel ................................................................................................................... 31
3.3 Création de la base de données ................................................................................................. 33
3.4 Implémentation ........................................................................................................................ 35
3.5 Les interfaces de l'application .................................................................................................. 36
3.5.1 Interface d’accueil......................................................................................................................... 36
3.5.2 Interface d’authentification ......................................................................................................... 38
3.5.3 Interface d’inscription .................................................................................................................. 39
3.5.4 Interface « cursus » ....................................................................................................................... 40
3.5.5 Interface « postuler la candidature » .......................................................................................... 41
3.5.6 Interface « imprimer le formulaire » .......................................................................................... 42
3.5.7 Interface « valider la candidature » ............................................................................................ 43
iv
3.5.8 Interface « affecter score » ........................................................................................................... 44
Conclusion générale................................................................................................................ 45
Webographie ............................................................................................................................ 46
Annexes ...................................................................................................................................... 47
v
Table des figures
Figure ‎1.1 Cas d'utilisation global .................................................................................................................. 8
Figure ‎1.2 Cas d’utilisation «S’authentifier » ................................................................................................. 9
Figure ‎1.3 Cas d’utilisation «Gérer les comptes » ....................................................................................... 10
Figure ‎1.4 Cas d’utilisation «Gestion des candidatures » ............................................................................ 12
Figure ‎1.5 Cas d’utilisation «Gérer les établissements» .............................................................................. 15
Figure ‎1.6 Cas d’utilisation «Gérer les filières» ........................................................................................... 17
Figure ‎1.7 Cas d’utilisation «Gérer le calendrier du concours» ................................................................... 18
Figure ‎2.1 Architecture client/serveur......................................................................................................... 22
Figure ‎2.2 Diagramme de classes................................................................................................................. 23
Figure ‎2.3 Diagramme de séquence système du cas d’utilisation « S’authentifier » .................................. 24
Figure ‎2.4 Diagramme de séquence système du cas d’utilisation « Consulter un compte » ...................... 25
Figure ‎2.5 Diagramme de séquence système du cas d’utilisation «créer un compte» ............................... 26
Figure ‎2.6 Diagramme de séquence système du cas d’utilisation « postuler une candidature» ................ 27
Figure ‎2.7 Diagramme de séquence système du cas d’utilisation « consulter les établissements » .......... 28
Figure ‎2.8 Diagramme de séquence système du cas d’utilisation « affecter un établissement à une
filière» ................................................................................................................................................... 29
Figure ‎3.1 « Création de la base de données » ............................................................................................ 33
Figure ‎3.2 « Tables et dictionnaire de données » ........................................................................................ 34
Figure ‎3.3 Storyboard du site....................................................................................................................... 35
Figure ‎3.4 prototype de l’application .......................................................................................................... 36
Figure ‎3.5 interface d’accueil ....................................................................................................................... 37
Figure ‎3.6 interface d’authentification ........................................................................................................ 38
Figure ‎3.7 interface d’inscription ................................................................................................................. 39
Figure ‎3.8 interface « cursus » ..................................................................................................................... 40
Figure ‎3.9 Interface « postuler la candidature » ......................................................................................... 41
Figure ‎3.10 Interface « imprimer le formulaire » ....................................................................................... 42
Figure ‎3.11 Interface « valider la candidature » .......................................................................................... 43
Figure ‎3.12 Interface « affecter score »....................................................................................................... 44
vi
Liste des tableaux
Tableau ‎1-1 Description textuelle du cas d’utilisation «S’authentifier » ...................................................... 9
Tableau ‎1-2 Description textuelle du cas d’utilisation «Créer compte » .................................................... 10
Tableau ‎1-3 Description textuelle du cas d’utilisation «Modifier compte » ............................................... 11
Tableau ‎1-4 Description textuelle du cas d’utilisation «Supprimer compte » ............................................ 11
Tableau ‎1-5 Description textuelle du cas d’utilisation « postuler une candidature » ................................. 12
Tableau ‎1-6 Description textuelle du cas d’utilisation « Modifier une candidature » ................................ 13
Tableau ‎1-7 Description textuelle du cas d’utilisation « Valider une candidature » ................................... 13
Tableau ‎1-8 Description textuelle du cas d’utilisation « Consulter les candidatures » ............................... 14
Tableau ‎1-9 Description textuelle du cas d’utilisation « Affecter résultat » ............................................... 14
Tableau ‎1-10 Description textuelle du cas d’utilisation « ajouter un établissement » ............................... 15
Tableau ‎1-11 Description textuelle du cas d’utilisation « Modifier un établissement » ............................. 16
Tableau ‎1-12 Description textuelle du cas d’utilisation « Supprimer un établissement » .......................... 16
Tableau ‎1-13 Description textuelle du cas d’utilisation « Lister les établissements » ................................ 17
Tableau ‎1-14 Description textuelle du cas d’utilisation « Affecter un établissement à une filière ».......... 18
Tableau ‎1-15 Description textuelle du cas d’utilisation «Créer une période» ............................................ 19
Tableau ‎1-16 Description textuelle du cas d’utilisation « Modifier une période » ..................................... 19
Tableau ‎1-17 Description textuelle du cas d’utilisation « Supprimer une période» ................................... 20
vii
Introduction générale
Aujourd’hui l’internet devient une source majeure en termes de communication
et de services, l’Université doit en mesure de répondre et participer à ces nouveaux
enjeux. Le Web est devenu un outil média important dans le monde et un outil d’usage
indispensable dans le public universitaire (étudiants et enseignants), accessible du
monde entier, le Web devient la façade initiale à travers laquelle on jugera de la qualité
d’une université. Du contenu d’un site dépendra la qualité perçue de l’institution soit
de points de vue des plans d’études enseignés, du corps académique ou même de la
valeur des diplômes. Aujourd’hui l’université évolue vers une logique du marché
concurrentiel ce qui l’exige à bien tenir en compte du critère de perception extérieure
et induire une image attractive et promouvante de ses prestations,
C’est dans ce contexte se situe notre travail qui consiste à concevoir et

implémenter un nouveau service en ligne au sein du site web de l’université de Gabès,
il s’agit d’une application web de gestion des concours sur dossier pour la mutation,
l’intégration et l’inscription à une deuxième spécialité, au profit des étudiants désirant
étudier ou s’intégrer dans l’une des établissements relevant de l’université de Gabès,
Cette application devra être en mesure de résoudre les problèmes liés à la lenteur et à
l’ambigüité de traitement de tels tâches, redondantes pour chaque saison de l’année, au
niveau de ses services administratifs de l’université. En effet, le service des affaires
estudiantines de l’université de Gabès gère chaque été de l’année un très grand nombre
de candidatures pour la réorientation, la mutation et l’intégration…ect et l’absence
d’un mécanisme de gestion informatique de ce dossier rend la tâche de traitement très
difficile et ennuyeuse.
Mémoire de mastère professionnel 1 A.U 2017-2018

Le présent rapport a pour objectif de présenter d’une façon détaillée les étapes
d’élaboration de ce projet. Il s’articule autour de trois chapitres : Le premier chapitre
comprend l’étude préalable qui met en œuvre une étude de l’existant ainsi que la
solution proposée et la spécification des différents besoins de l’application
(fonctionnelles et non fonctionnelles). Le second chapitre sera consacré à la partie
conception du projet. Le dernier chapitre traite les étapes de la réalisation de
l’application dont on exposera les outils utilisés, la structure de la base de données
obtenu ainsi qu’un aperçu sur les différentes interfaces de l’application. Enfin nous
clôturons notre rapport par une conclusion générale qui résumera tout ce qui a été
précédemment évoqué et qui en dégagera des perspectives pour l’extension et la mise
à niveau.

Chapitre 1- Etude préalable
Chapitre 1
Etude préalable
1.1 Introduction
Il s'agit d'une étape déterminante dans la réalisation d'une application donnée. La

mise en place d’un nouvel outil logiciel dépend beaucoup de cette phase, elle nous
permet d'éviter le développement d'une application non satisfaisante. Dans ce chapitre
nous allons présenter une étude de l’existant (le domaine d'application, l'état actuel de
l'environnement du futur système, les ressources disponibles, les performances
attendues, etc.). Ensuite nous allons dégager la solution proposée à cet égard et enfin
nous terminons ce chapitre par la spécification des besoins fonctionnels et non
fonctionnels de l’application.
1.2 Etude de l’existant :
A la fin de chaque année universitaire, l’université de Gabès lance les avis des
concours d’été offrant la possibilité aux étudiants de muter dans l’une des institutions
relevant de l’université de Gabès, de rejoindre de nouveau les études après une
interruption ou une exclusion de l’une des écoles préparatoires aux études d’ingénieurs
et offrir également l’opportunité de s’inscrire dans une deuxième spécialité.
Pour ce faire, les candidats remplissent manuellement les formulaires conçus

pour chaque type de concours et les envoient par voie postale ou en les déposants
directement au bureau du service des affaires estudiantines de l’université. Après
l’expiration du dernier délai de dépôt fixé auparavant, démarre l’étape la plus
fastidieuse pour le personnel du service qui concerne le traitement des différents

dossiers. Les agents du service scolarité de l’université font souvent recours aux outils
bureautiques tels que Excel, Word pour stocker les informations concernant les
différents candidats, une fois terminée les dossiers seront classés par établissement et
envoyés aux différentes commissions pour la vérification et la prise de décision.
1.3 Critique de l’existant :

 Le stockage des données dans des fichiers Excel augmente le risque de perte
d’informations qui, à l’absence de moyens de sauvegarde et de sécurité, sont exposées
aux virus informatiques, fautes de frappes et à la suppression.
 L’information est décentralisée et dispersée sur plusieurs fichiers et qui cause
le problème de réplication et de redondance,
 Problème de redondance : le traitement des dossiers dans plusieurs machines et
par plusieurs utilisateurs cause le problème de réplication et de redondance, d’où on
remarque qu’un même dossier peut être ré-saisit plusieurs fois.
 Perte de temps : la ré-saisie des données provoque une perte de temps, et pour
garder l’intégrité de données, toute modification dans l’un des fichiers doit être établi
et contrôlé manuellement dans les autres.
 L’agent d’administration devra être en mesure de maîtriser l’outil Excel, sinon
il sera incapable de dégager les erreurs de redondance et d’exploiter les fonctionnalités
qui aident à mieux gérer les données.
 Problème de confidentialité : l’absence de mécanisme de sécurité expose les
données au risque de mal utilisation et nui à la confidentialité des informations
personnelles des candidats.
1.4 Solution proposée :
Suite aux inconvénients précédemment cités, nous proposons la mise en place

d'une application Web qui automatise les différentes activités de gestion de ce dossier.

La solution qu’on propose est de développer une application pour la gestion des
concours pour le service des affaires estudiantines de l’université de Gabès
garantissant:
 Le traitement de données à temps réduit

 La facilité et la simplification de la tâche de l’utilisateur
 Le stockage sécurisé des données.
 La Simplicité de la recherche et le suivi des informations
 La facilité d’accès aux différentes modalités de l’application.
 La Réduction des taux d’erreurs.
1.5 Spécifications :
Afin de concevoir un système qui répond aux besoins attendues du cadre

administratif chargé de ce dossier, Il a fallu discuter avec les différents intervenants et
faire la collecte des informations nécessaires
L'étude présentée dans ce chapitre est donc le fruit de ces discussions et de

l'analyse de besoins.
1.5.1 Spécification des besoins fonctionnels :
Ce projet doit satisfaire certains besoins et doit préparer l’application contenant

les modules nécessaires pour l’utilisateur final. Ces tâches à effectuer sont définies
comme suit :
 Authentification des utilisateurs à travers un login et un mot de passe introduit

au système.
 Gestion des comptes (Ajout, modification, recherche)
 Gestion des candidatures (Ajout, modification, recherche, validation, affectation
résultat, affectation score).
 Gestion des établissements universitaires (Ajout, modification, recherche)
 Gestion des Filières (Ajout, modification, recherche)
 Gestion du calendrier du concours (Ajout, modification)

1.5.2 Spécification des besoins non fonctionnels :

Les besoins non fonctionnels se sont les exigences qui caractérisent un système.
Ces besoins peuvent être énoncés suivant des plans de classifications :
 Ergonomie :
Les interfaces doivent être simples, conviviales, clairs et ne doivent pas nécessiter
de connaissances assez poussées des utilisateurs pour leurs permettre de se sentir alaise
et familiariser avec l’environnement.
 Robustesse :
L’application doit permettre le stockage des informations des utilisateurs inscrits,
en assurant une bonne gestion d’erreurs.
 Sécurité :
L’application doit garantir à l’utilisateur connecté l’intégrité et la confidentialité
de ses données.
L’accès à la partie administration doit être sécurisé et authentifié.
 Performance :
Un temps de réponse raisonnable au moment de l’identification et des traitements
des données.
Les utilisateurs non administrateur, ne doivent pas s’apercevoir des données
sécurisées.
1.5.3 Identification des acteurs:

Avant d’entamer la présentation des diagrammes, il faut identifier les acteurs qui
interagissent directement avec le système. Un acteur est une entité externe qui peut
être un utilisateur humain, un dispositif matériel ou un autre système.
Dans notre système on distingue trois acteurs principaux :
- L’administrateur: c’est l’utilisateur ayant tous les droits d’accès de
l’application, il est capable de gérer toutes les fonctionnalités proposées tels que : la
gestion des comptes, la gestion des candidatures et le paramétrage.
- L’agent: c’est celui responsable du traitement des dossiers du concours, cet
acteur est chargé de la vérification de la conformité des informations saisie avec celles

contenues dans le dossier papier de chaque candidat et peut corriger les erreurs de saisi
avant la validation du dossier.
- L’étudiant : C’est l’acteur autour duquel agissent les autres acteurs, l’étudiant
va introduire les informations demandées, imprimer le formulaire et envoyer son
dossier complet à l’université.
1.5.4 Les diagrammes des cas d’utilisation:
1.5.4.1 Cas d’utilisation préliminaire:

Le cas d’utilisations préliminaire ou global donné par la figure 1.1 constitue
l’ensemble des fonctionnalités offertes par notre application et permet d’exprimer les
différentes possibilités d’interaction entre les acteurs et le système.
Dans ce qui suit, nous allons se limiter à la description détaillée des cas
d’utilisation les plus importants.

Gérer‎les‎comptes <<include>>
<<include>>
Gérer‎les‎établissements
Administrateur <<include>>
Gérer‎les‎filières
<<include>>
Gérer‎la‎durée‎du‎concours
<<include>>
Gérer‎les‎candidatures
agent
Postuler une candidature
<<include>>
S'authentifier
S'inscrire
Etudiant
Figure ‎1.1 Cas d'utilisation global

1.5.4.2 Cas d’utilisations détaillés:

On s’intéresse aux cas d’utilisations les plus pertinents.
1.5.4.3 Cas d’utilisation «S’authentifier »
Administrateur
<<include>>
Contrôle‎du‎login‎et‎mot‎de‎passe
S'authentifier
agent
<<extend>>
Etudiant Récuperer‎privilèges
Figure ‎1.2 Cas d’utilisation «S’authentifier »
 Description textuelle du cas d’utilisation «S’authentifier »
Cas d’utilisation S’authentifier

Acteurs Administrateur, agent, Etudiant
Pré-condition Compte existant
Post-condition Autorisation d’accès accordée
1- L’utilisateur saisi le login et le mot de
passe
2- L’utilisateur clique sur Login.
3- Le système vérifie les données saisies.
Scénario nominal
4- Compte existe, redirection vers le menu
principal et chargement des privilèges.
5- Le système charge les privilèges et les
données du compte courant.
-Si le nom d’utilisateur ou le mot de passe erroné,
le système affiche un message d’erreur.
Scénario alternatif
-Le système le redirige au début du scenario
principal.
Tableau ‎1-1 Description textuelle du cas d’utilisation «S’authentifier »

1.5.4.4 Cas d’utilisation «Gérer les comptes »

<<extend>>
<<include>>
Créer‎compte
<<include>>
<<extend>> S'inscrire
Gérer‎les‎comptes Modifier compte
Administrateur
Etudiant
<<include>>
Supprimer compte
<<extend>>
Remplir formulaire
Gérer‎droits
<<extend>>
Figure ‎1.3 Cas d’utilisation «Gérer les comptes »
 Description textuelle du cas d’utilisation «Créer compte »
Cas d’utilisation Créer compte

Acteurs Administrateur, Etudiant
Pré-condition Une authentification préalable de l’administrateur
Post-condition Un nouveau compte est ajouté
1- L’utilisateur demande le formulaire d’ajout
2- Le système affiche le formulaire
3- L’utilisateur rempli les champs nécessaires
Scénario nominal et valide
4- Le système vérifie les données saisies
5- Le système enregistre le nouvel utilisateur
et affiche un message de succès de l’opération
4-a-L’utilisateur saisie des données manquantes
ou invalides
4-a-1-le système affiche un message d’erreur
4-a-2-reprise de l’étape 3 du scénario nominal
4-b- le compte existe déjà
4-b-1-le système demande à l’utilisateur de
modifier l’identifiant ou se connecter.
4-b-2-reprise de l’étape 3 du scénario nominal
Tableau ‎1-2 Description textuelle du cas d’utilisation «Créer compte »

 Description textuelle du cas d’utilisation «Modifier compte »
Cas d’utilisation Modifier compte

Acteurs Administrateur, Etudiant
Une authentification préalable
Pré-condition
compte existant
Post-condition Les informations du compte ont été mises à jour
1-L’utilisateur choisi le compte à modifier
2-Le système affiche le formulaire de modification
3-L’utilisateur modifie les informations et valide
Scénario nominal
4-le système vérifie les données saisies
5-Le système enregistre les données et affiche un
message de succès
4-a- L’utilisateur saisie des données manquantes ou

invalides
Tableau ‎1-3 Description textuelle du cas d’utilisation «Modifier compte »
 Description textuelle du cas d’utilisation «Supprimer compte »
Cas d’utilisation Supprimer compte

Acteurs Administrateur
Une authentification préalable
Pré-condition
Compte existant
Post-condition Le compte a été supprimé de la base
1-L’utilisateur choisi le compte à supprimer
2-le système affiche un message de confirmation
Scénario nominal 3-L’utilisateur valide son choix
4-le système supprime le compte et affiche un
message de succès
3-a-L’utilisateur annule son choix
3-a-1-le système annule la suppression
Tableau ‎1-4 Description textuelle du cas d’utilisation «Supprimer compte »

1.5.4.5 Cas d’utilisation «Gérer les candidatures »

<<extend>> <<include>>
Consulter candidatures
<<include>> Postuler une candidature

Gérer‎les‎candidatures <<extend>>
agent Modifier candidature
Etudiant
Valider candidature
<<extend>>
Affecter‎résultat
<<extend>>
Affecter score
<<extend>>
Figure ‎1.4 Cas d’utilisation «Gestion des candidatures »
 Description textuelle du cas d’utilisation « postuler une candidature »
Cas d’utilisation Postuler une candidature

Acteurs Etudiant
Pré-condition Authentification préalable
Post-condition Une nouvelle candidature ajoutée
1-l'étudiant demande le formulaire d’ajout
2-le système affiche le formulaire
3-l' étudiant rempli les champs nécessaires et valide
Scénario nominal
5-le système enregistre la candidature et affiche un
message de succès
4-a-l'étudiant saisie des données manquantes ou
incompatibles
Scénario alternatif 4-a-1-le système affiche un message d’erreur
Tableau ‎1-5 Description textuelle du cas d’utilisation « postuler une candidature »

 Description textuelle du cas d’utilisation « Modifier une candidature »
Cas d’utilisation Modifier une candidature

Acteurs Agent, Etudiant, Administrateur
Authentification préalable
Pré-condition
La candidature est existante et non validée
Post-condition Les informations ont bien été mises à jour
1-l'utilisateur choisi la candidature à modifier
2-le système affiche les détails de la candidature
3-l'utilisateur modifie les informations et enregistre
Scénario nominal les modifications.
5-le système enregistre les données et donne la main
à l’impression du formulaire.
4-a-l'utilisateur saisie des données manquantes
Scénario alternatif 4-a-1-le système affiche un message d’erreur
Tableau ‎1-6 Description textuelle du cas d’utilisation « Modifier une candidature »
 Description textuelle du cas d’utilisation « Valider une candidature »
Cas d’utilisation Valider une candidature

Acteurs Agent, Administrateur
Pré-condition
La candidature existe déjà
Post-condition La candidature a bien été validée
1-l'agent choisi la candidature, vérifie les données et
appuie sur valider
Scénario nominal
3-l'agent valide son choix
4-le système valide la candidature et affiche un
message de succès
3-a-l'agent annule son choix
3-a-1-le système annule la validation
Tableau ‎1-7 Description textuelle du cas d’utilisation « Valider une candidature »

 Description textuelle du cas d’utilisation « Consulter les candidatures »
Cas d’utilisation Consulter les candidatures

Acteurs Agent, Administrateur
Post-condition La liste des candidatures est affichée sur l’écran
1-l'agent demande l’affichage de la liste des
Scénario nominal candidatures
2-le système affiche la liste des candidatures
2-a-aucun résultat
Scénario alternatif 2-a-1-le système affiche un message de type « aucun
résultat trouvé »
Tableau ‎1-8 Description textuelle du cas d’utilisation « Consulter les candidatures »
 Description textuelle du cas d’utilisation « Affecter résultat »
Cas d’utilisation Affecter résultat

Pré-condition
La candidature existe déjà
Post-condition Le résultat a bien été validé
1-l’utilisateur choisi la candidature, et affecte le
résultat à la candidature
Scénario nominal
3-l’utilisateur valide son choix
4-le système affecte le résultat et affiche un message
de succès
3-a-l’utilisateur annule son choix

3-a-1-le système annule la l’affectation
Tableau ‎1-9 Description textuelle du cas d’utilisation « Affecter résultat »

1.5.4.6 Cas d’utilisation «Gérer les établissements »

Ajouter un
<<extend>> établissement
Gérer‎les‎ <<extend>> Modifier un

établissements établissement
Administrateur
Supprimer un
<<extend>> établissement
Lister les
établissements
<<extend>>
Figure ‎1.5 Cas d’utilisation «Gérer les établissements»
 Description textuelle du cas d’utilisation « ajouter un établissement »
Cas d’utilisation Ajouter un établissement

Post-condition Un nouvel établissement ajouté
1-l'utilisateur demande le formulaire d’ajout
3-l'utilisateur rempli les champs nécessaires et valide
Scénario nominal
5-le système enregistre le nouvel établissement et
affiche un message de succès
4-a-l'utilisateur saisie des données manquantes
Scénario alternatif 4-b- l’établissement existe déjà
4-b-1-le système demande à l’utilisateur de modifier
les données saisies
Tableau ‎1-10 Description textuelle du cas d’utilisation « ajouter un établissement »

 Description textuelle du cas d’utilisation « Modifier un établissement »
Cas d’utilisation Modifier un établissement

Pré-condition
L’établissement déjà existant
1-L'utilisateur choisi l’établissement à modifier
2-le système affiche le formulaire de modification
3-l'utilisateur modifie les informations et valide
Scénario nominal
5-le système enregistre les données et affiche un
message de succès
4-a-l' utilisateur saisie des données manquantes
4-b- le nom de l’établissement existe déjà
4-b-1-le système demande à l’utilisateur de modifier
les données saisies
Tableau ‎1-11 Description textuelle du cas d’utilisation « Modifier un établissement »
 Description textuelle du cas d’utilisation « Supprimer un établissement »
Cas d’utilisation Supprimer un établissement

Pré-condition
L’établissement déjà existant
Post-condition L’établissement a bien été supprimé
1-l'utilisateur choisi l’établissement à supprimer
Scénario nominal 3-l'utilisateur valide son choix
4-le système supprime l’établissement
5-le système affiche un message de succès
3-a-l'utilisateur annule son choix
Tableau ‎1-12 Description textuelle du cas d’utilisation « Supprimer un établissement »

 Description textuelle du cas d’utilisation « Lister les établissements »
Cas d’utilisation Lister les établissements

Post-condition La liste des établissements est affichée sur l’écran
1-l'administrateur demande l’affichage de la liste des
Scénario nominal établissements
2-le système affiche la liste des établissements
2-a-aucun résultat
Scénario alternatif 2-a-1-le système affiche un message de type « aucun
résultat trouvé »
Tableau ‎1-13 Description textuelle du cas d’utilisation « Lister les établissements »
1.5.4.7 Cas d’utilisation «Gérer les filières»
<<extend>> Ajouter‎une‎filière
<<extend>>
Gérer‎les‎filières Modifier‎une‎filière
Administrateur
Supprimer une
<<extend>> filière
Lister‎les‎filières
<<extend>>
Affecter un
établissement‎à‎
<<extend>> une‎filière
Figure ‎1.6 Cas d’utilisation «Gérer les filières»

 Description textuelle du cas d’utilisation « Affecter un établissement à une

filière »
Cas d’utilisation Affecter un établissement à une filière

Post-condition La filière est affectée à l’établissement
1-l’administrateur demande la liste des filières
2-le système affiche la liste des filières
3-l’administrateur choisit la filière
Scénario nominal 4-le système affiche la liste des établissements
5-l’administrateur choisi un établissement et valide
6-le système enregistre l’affectation et affiche un
message de succès
5-a-Aucun établissement sélectionné
5-a-2-retour à l’étape 4 du scénario nominal
Tableau ‎1-14 Description textuelle du cas d’utilisation « Affecter un établissement à une filière »
1.5.4.8 Cas d’utilisation «Gérer le calendrier du concours»
<<extend>> Créer‎une‎période
Gérer‎le‎calendrier‎ <<extend>> Modifier une

Administrateur
du concours période
Supprimer une
période
<<extend>>
Figure ‎1.7 Cas d’utilisation «Gérer le calendrier du concours»

 Description textuelle du cas d’utilisation «Créer une période»
Cas d’utilisation Créer une période

Post-condition Une nouvelle période ajoutée
1-l'utilisateur demande le formulaire d’ajout
3-l'utilisateur rempli les champs nécessaires et valide
Scénario nominal
5-le système enregistre la nouvelle période et affiche
un message de succès
4-a-l’administrateur saisie des données manquantes ou
une période invalide
Tableau ‎1-15 Description textuelle du cas d’utilisation «Créer une période»
 Description textuelle du cas d’utilisation « Modifier une période »
Cas d’utilisation Modifier une période

1-L'administrateur choisi la période à modifier
2-le système affiche le formulaire de modification
3-l'utilisateur modifie les informations et valide
Scénario nominal
5-le système enregistre les données et affiche un
message de succès
4-a-l’administrateur saisie des données manquantes ou
une période invalide
Tableau ‎1-16 Description textuelle du cas d’utilisation « Modifier une période »

 Description textuelle du cas d’utilisation « Supprimer une période»
Cas d’utilisation Supprimer une période

Pré-condition
La période est déjà existante
Post-condition La période a bien été supprimée
1-l'utilisateur choisi la période à supprimer
Scénario nominal 3-l'utilisateur valide son choix
4-le système supprime la période
5-le système affiche un message de succès
3-a-l'utilisateur annule son choix
Tableau ‎1-17 Description textuelle du cas d’utilisation « Supprimer une période»

Chapitre 2- Conception
Chapitre 2
Conception
2.1 Introduction
Après avoir fixé les besoins et les objectifs dans le chapitre précédent, nous nous
focalisons sur l’aspect architectural de l’application. Cette phase a pour but de
concevoir les schémas généraux qui permettent la modélisation et la description d’une
manière non ambiguë du fonctionnement désiré de l’application. Dans ce chapitre
deux vues conceptuelles seront décrite. La première donne une vue globale de
l’architecture tandis que la deuxième offre une vue détaillée en se basant sur le langage
UML (Unified Modeling Language).
2.2 Architecture de l’application

Dans les phases préliminaires du développement d’une application ou de la
refonte d’un système d’information, la définition de l’architecture technique consiste à
faire les choix de technologies et d’organisation de composants logiciels les plus
adaptés aux besoins et aux contraintes de l’organisation d’accueil.
Ces choix sont ensuite relayés au sein de notre projet, guidant la conception et
permettant la transformation d’un modèle fonctionnel en application performante et
robuste.
Afin de réussir l’étape de conception, il est nécessaire de suivre un contexte
conceptuel qui répond aux spécificités et aux besoins fondamentaux de l’application,
menant ainsi à la satisfaction de ses utilisateurs. L’architecture client/serveur est
l’architecture qui paraît le mieux adapté à notre application. Nous allons entamer cette
partie par la définition de cette architecture.
2.2.1 Présentation de l'architecture client/serveur

Cette architecture est basée sur l’utilisation de deux composantes logicielles, à
savoir un logiciel serveur et un logiciel client s’exécutant sur deux machines
différentes. On appelle logiciel serveur un programme qui offre un service sur le
réseau. Le serveur accepte des requêtes, les traite et renvoie le résultat au demandeur.

On appelle logiciel client un programme qui utilise le service offert par un serveur.
Le client envoie une requête et reçoit la réponse. La seule obligation de compromis
entre le client et le serveur est le respect du protocole qui assure la communication
inter-processus : HTTP pour le Web, POP/IMAP/SMTP pour le courrier électronique,
SNMP pour l’administration de réseau. La figure 2.1 illustre l’architecture
client/serveur adaptée pour cette application.
Figure ‎2.1 Architecture client/serveur
2.2.2 Les avantages de l’architecture client/seveur
Pour le développement de notre application nous avons opté pour l’architecture

client/serveur pour plusieurs raisons à savoir :
• Modèle adéquat pour la distribution des données.
• Prend avantage des fonctionnalités réseaux.
• Facile d’ajouter des serveurs supplémentaires ou de mettre à jour les serveurs
existants.
• intégrité : les données du serveur sont gérées sur le serveur de façon centralisée.
Les clients restent individuels et indépendants.
• Partage des ressources : un serveur traite plusieurs clients en même temps et
contrôle leurs accès aux ressources.

2.3 Conception détaillée :

Dans ce qui suit, nous détaillons la conception à l’aide de la méthodologie UML.
2.3.1 Vue statique : Diagramme de classes
Etablissement users
- IDetab : String - ID : Number
- Nometab : String - login : String
+ Ajouter‎un‎établissement‎() - password : String
+ modifier‎un‎établissement‎() - type : String
+ supprimer‎un‎établissement‎() + creer compte ()
+ lister‎les‎établissements‎() + modifier compte ()
+ supprimer compte ()
+ consulter un compte ()
1..1 Etudiant
- cin : String
1..* - prenom : String
<contient> - nom : String
filiere - date_naissance : Date
- lieu_naissance : String
- IDfil : int
- sexe : int
- Nomfil : String
- etat_civil : int
+ Ajouter‎une‎filière‎() - nationalite : int
<contient>
+ modifier‎une‎filière‎() - adresse : String
+ supprimer‎une‎filière‎() - ville : String
+ lister‎les‎filières‎() - codepostal : String
+ affecter‎‎un‎établissement‎à‎une‎filière - gouvernorat : int
() - email : String
- tel : String
- date_dossier : Date
<choisir> 1..* <depose> 1..1
1..1 0..1
candidature
- IDC : int
- nature_dem : int
- sanction : boolean cursus_bac cursus_univ
- etab_act : String - ID : int - ID : int
- section_act : String - annee_bac : int - annee_univ : String
- niveau_univ_dem : int - session_bac : String - etablissement_univ : String
- valide : int - section_bac : String - type_univ : String
- resultat : int - moyenne_bac : float - section_univ : String
- score : int - niveau_univ : String
+ ajouter un cursus ()
+ ajouter candidature () + modifier un cursus () - resultat_univ : String
+ modifier candidature () + supprimer un cursus () - moyenne_univ : float
+ supprimer candidature () + ajouter un cursus ()
+ lister candidature () + modifier un cursus ()
+ valider candidature () + supprimer un cursus ()
+ affecter resultat ()
+ affecter score ()
integration mutation
exclu_prep 2eme_spec
- ID : int - ID : int
- ID : int - cause : int - ID : int
- cause : int
Figure ‎2.2 Diagramme de classes

2.3.2 Vue dynamique : les diagrammes de séquences

Pour illustrer les diagrammes des cas d’utilisation, nous allons introduire dans ce
qui suit les diagrammes de séquences relatifs à notre application. Ces diagrammes
servent à représenter les successions particulières d’enchaînement d’un scénario en
utilisant des conventions graphiques.
Dans ce qui suit nous présentons les diagrammes les plus importants de notre
application.
2.3.2.1 Diagramme de séquence système du cas d’utilisation « S’authentifier »
S'authentifier
systeme
utilisateur
lancer le systeme
Demander le nom d'utilisateur et le mot de passe
Saisir les informations
verifier
alt login ou mot de passe incorrect

Message erreur
login et mot de passe corrects

Fournir l'espace de travail a l'utilisateur
Figure ‎2.3 Diagramme de séquence système du cas d’utilisation «

S’authentifier »
.
2.3.2.2 Diagramme de séquence système du cas d’utilisation « consulter un
compte »
Pour consulter son compte, l’administrateur doit s’authentifier dans un premier
lieu en utilisant son login et son mot de passe. Par la suite, il choisit les critères de
recherche correspondant à ces besoins.

Consulter un compte
systeme
Administrateur
ref
S'authentifier()
Demande le formulaire de recherche
Afficher le formulaire de recherche
Entrer un critere d'un candidat
Verifier
alt S'il n'existe pas

Afficher resultat vide
S'il existe
Afficher le profil du candidat
Figure ‎2.4 Diagramme de séquence système du cas d’utilisation « Consulter un compte »

2.3.2.3 Diagramme de séquence système du cas d’utilisation «créer un compte»
creer compte
systeme
utilisateur
ref
S'authentifier()
loop
demander le formulaire d'ajout
Afficher le formulaire d'ajout
Envoyer les donnees
Verifier informations
alt Donnees manquantes
Message erreur
Donnees completes
alt utilisateur existe

Message erreur
utilisateur inexistant
enregistrer nouvel utilisateur

Message succes
Figure ‎2.5 Diagramme de séquence système du cas d’utilisation «créer un compte»

2.3.2.4 Diagramme de séquence système du cas d’utilisation « postuler une

candidature»
postuler une candidature
systeme
Etudiant
ref
S'authentifier()
Demander le formulaire de candidature
Afficher le formulaire de candidature
Saisir les informations de candidature

Verifier
alt Informations manquantes

Message erreur
Informations completes
enregistrer la candidature
Imprimer le formulaire d'inscription
Figure ‎2.6 Diagramme de séquence système du cas d’utilisation « postuler une candidature»

2.3.2.5 Diagramme de séquence système du cas d’utilisation « consulter les

établissements »
Consulter les etablissements
systeme
Administrateur
ref
S'authentifier()
Demander‎le‎formulaire‎des‎établissements
Afficher le formulaire correspondant
Entrer le nom de l'etablissement
Verifier
alt S'il n'existe pas

Afficher un resultat vide
S'il existe
Afficher l'etablissement
Figure ‎2.7 Diagramme de séquence système du cas d’utilisation « consulter les établissements »

2.3.2.6 Diagramme de séquence système du cas d’utilisation « affecter un

établissement à une filière»
Affecter‎établissement‎filière
systeme
Administrateur
ref
S'authentifier()
ref
Conulter‎les‎filières()
loop [L'administrateur‎souhaite‎affecter‎‎un‎établissement‎à‎une‎filière]
Choisir‎la‎filière
recuperer‎la‎liste‎des‎filières
Afficher‎la‎liste‎des‎établissements
Choisir‎l'établissement
mise‎à‎jour‎de‎la‎filière
Message‎succès
Figure ‎2.8 Diagramme de séquence système du cas d’utilisation « affecter un établissement à une
filière»

Conclusion
A travers ce chapitre, on a présenté la conception proposée pour l’application. On
a fourni, dans un premier lieu, la conception globale. Par la suite, on a détaillé la
conception à travers les diagrammes UML qui nous ont permis de dégager la vue
statique ainsi que la vue dynamique de l’application. Afin de mieux concrétiser cette
conception, on va présenter dans le chapitre suivant la description et les différentes
interfaces réalisées par notre application.

Chapitre 3- Réalisation
Chapitre 3
Réalisation
3.1 Introduction
Cette partie contient le dernier volet de ce rapport. Elle a pour objectif d’exposer
le travail achevé. Dans un premier temps, nous présentons l’environnement matériel,
logiciel et les différents outils de développement utilisés. Dans un second temps, nous
illustrons la réalisation de notre travail par des imprimes d’écran des interfaces les plus
importantes de notre application.
3.2 Environnement de travail
3.2.1 Environnement matériel
L’environnement matériel sur lequel nous avons travaillé est constitué d’un
ordinateur portable DELL caractérisé par :
• Processeur: Intel Core I3 2.4GHz
•Mémoire: 4Go de RAM.
• Disque dur: 500 Go .
• Système d’exploitation: Windows 7.
3.2.2 Environnement logiciel
Pour élaborer ce travail nous avons fait recours à un certain nombre de logiciels:
- PowerAMC est un outil de création de modèles de processus métier et de modèles

de données conceptuels, logiques et physiques pour la conception de bases de données,
y compris des modèles relationnels et dimensionnels. PowerAMC peut coordonner le

modèle de processus métier avec la conception de la base de données, en veillant à ce

que les étapes de processus qui créent des données aient des représentations de
données dans le modèle logique. PowerAMC peut créer la base de données réelle à
partir du modèle physique et créer différentes implémentations physiques à partir d'un
seul modèle logique. PowerAMC peut également procéder à un reverse engineering de
bases de données existantes dans un diagramme de modèle. PowerAMC fonctionne
avec de nombreux systèmes de gestion de base de données (SGBD). Les principaux
résultats de l'outil incluent des diagrammes entité-relation (ER), des rapports d'analyse
d'impact sur les modifications de conception et des rapports standard ou personnalisés
sur tous les objets de la conception (tables, champs, relations).
- XAMPP est un ensemble de logiciels permettant de mettre en place facilement un

serveur Web et un serveur FTP. Il s’agit d’une distribution de logiciels libres (X
Apache MySQL Perl PHP) offrant une bonne souplesse d’utilisation, réputée pour son
installation simple et rapide. Ainsi, il est à la portée d’un grand nombre de personnes
puisqu’il ne requiert pas de connaissances particulières et fonctionne, de plus, sur les
systèmes d’exploitation les plus répandus.
-DREAMWEAVER est un éditeur de site web WYSIWYG pour Microsoft Windows,

et Mac OS X créé en 1997, commercialisé par Macromedia puis Adobe Systems sous
licence utilisateur final.
Dreamweaver fut l'un des premiers éditeurs HTML de type « tel affichage, tel résultat
», mais également l'un des premiers à intégrer un gestionnaire de site
(CyberStudioGoLive étant le premier). Ces innovations l'imposèrent rapidement
comme l'un des principaux éditeurs de site web, aussi bien utilisable par le néophyte
que par le professionnel.
Dreamweaver offre deux modes de conception par son menu affichage.
L'utilisateur peut choisir entre un mode création permettant d'effectuer la mise en page
directement à l'aide d'outils simples, comparables à un logiciel de traitement de texte
(insertion de tableau, d'image, etc.). Il est également possible d'afficher et de modifier
directement le code (HTML ou autre) qui compose la page. On peut passer très
facilement d'un mode d'affichage à l'autre, ou opter pour un affichage mixte. Cette

dernière option est particulièrement intéressante pour les débutants qui, à terme,
souhaitent se familiariser avec le langage HTML.
3.3 Création de la base de données

A partir du diagramme de classes nous pouvons maintenant créer notre base de
données.
Notre base de données doit contenir 12 tables respectant un schéma relationnel

bien déterminé et mettant en considération toutes les contraintes d’intégrité
fonctionnelles.
Figure ‎3.1 « Création de la base de données »

 Tables et dictionnaire de données :
Figure ‎3.2 « Tables et dictionnaire de données »

3.4 Implémentation
Il s’agit dans cette étape de traduire les fonctionnalités définies dans la phase de
conception en langage de programmation.
Pour l'implémentation, le choix s'est porté sur le langage de programmation PHP.
La base de données est implémentée avec MySQL qui est largement compatible avec
PHP.
Mais avant de démarrer l’étape de développement il faut réaliser un prototypage
qui consiste à accomplir un prototype du site web, ce qui signifie qu’il ne s’agit pas de
la version finale du site web mais bien d’une maquette de celui-ci.
Afin de prototyper notre site web, nous devons commencer par réaliser un
storyboard qui permet de définir la façon selon laquelle l’utilisateur va naviguer sur le
site web, autrement dit il définira les différents liens possibles entre les pages de notre
site. Ci-dessous, voici notre storyboard et notre maquette :
consulter/Editer consulter/Editer consulter/Editer

le profil le profil le profil
Consulter Consulter
Remplir/Editer
/Editer le /Editer le
le cursus
cursus cursus
Déposer/Editer consulter/Editer consulter/Editer

la candidature la candidature la candidature
Authentification
Imprimer le Imprimer le Imprimer le
formulaire formulaire formulaire
Accueil Accueil Authentification Accueil Authentification
valider/annuler
Consulter son valider la
validation de la
Etudiant résultat Agent candidature Administrateur
Inscription candidature
affecter le réglage des

Déconnecter
résultat paramètres
Déconnecter Déconnecter
Figure ‎3.3 Storyboard du site

Figure ‎3.4 prototype de l’application
3.5 Les interfaces de l'application

Nous consacrons cette partie pour exposer notre projet à travers des imprimes
d’écran des interfaces les plus importantes de notre application.
3.5.1 Interface d’accueil

Figure ‎3.5 interface d’accueil
L’interface d’accueil de l’application contient le menu principal du site Web.

Elle donne un accès visiteur au grand public (sans authentification) pour consulter ou
télécharger les différents avis du concours, une vidéo de démonstration est intégrée à
cette page pour guider les candidats à bien remplir les différents formulaires, ainsi
qu’un menu à droite donnant la possibilité à l’utilisateur de s’inscrire ou de se
connecter à son espace et un lien pour pouvoir revenir à la page d’accueil.

3.5.2 Interface d’authentification

Chaque utilisateur (administrateur, agent ou candidat), doit s’authentifier avant
d’accéder aux déférentes fonctionnalités. L’authentification est assurée par l’interface
illustrée par la figure 3.6.
Figure ‎3.6 interface d’authentification

3.5.3 Interface d’inscription

Chaque candidat désirant créer un compte, doit obligatoirement remplir le
formulaire présenté par la figure 3.7, tous les champs sont obligatoires, pour faciliter la
tâche on a choisi comme identifiant le numéro de carte d’identité nationale du
candidat, et comme mot de passe le numéro d’empreinte situé en face arrière de la
carte.
Figure ‎3.7 interface d’inscription

3.5.4 Interface « cursus »

Ce formulaire décrit le parcours de l’étudiant, allant de l’année d’obtention du diplôme
de baccalauréat jusqu’à l’état de l’année universitaire actuelle. Les moyennes
obtenues par l’étudiant sont un critère important pris en considération par les
différentes commissions du concours.
Figure ‎3.8 interface « cursus »

3.5.5 Interface « postuler la candidature »

Dans cette étape, le candidat doit sélectionner la nature du concours et la filière
adéquate avec sa formation. Le candidat n’est autorisé qu’à choisir une des licences
appartenant à l’université de Gabès. L’appui sur le bouton de validation présenté par la
figure 3.9 entraine simultanément l’enregistrement et l’aperçu avant impression du
formulaire.
Figure ‎3.9 Interface « postuler la candidature »

3.5.6 Interface « imprimer le formulaire »

La dernière étape qui reste est d’imprimer le formulaire de candidature (fichier
pdf) rempli par les informations précédemment saisi et de l’envoyer à l’université joint
avec les pièces demandées pour la vérification et la validation.
Figure ‎3.10 Interface « imprimer le formulaire »

3.5.7 Interface « valider la candidature »

Toutes les candidatures sont recueillies dans un tableau, le rôle de l’agent est de
vérifier la conformité des données saisis avec celles présentes sur le dossier physique
envoyé par l’étudiant, ensuite au moyen d’un bouton l’agent valide le dossier. Dans ce
cas la modification des informations sera impossible, seul l’administrateur de
l’application a le droit de modifier ou annuler la validation d’une candidature.
Figure ‎3.11 Interface « valider la candidature »

3.5.8 Interface « affecter score »

Après la clôture de la date des concours et la validation des différents dossiers,
l’administrateur appui sur le bouton « calculer score » pour affecter le score à chaque
candidature, le barème du score est fixé par les commissions du concours.
Figure ‎3.12 Interface « affecter score »

Conclusion générale
Dans ce projet nous avons mis en œuvre une application web permettant la
gestion des différents concours d’été pour l’université de Gabès. L’objectif est
de simplifier et automatiser la démarche de traitement de ce dossier qui était
auparavant fastidieuse.
Pour aboutir à ce résultat, nous avons tout d’abord débuté par une étude de
l’art émanant à une étude de l’existant. Ensuite, nous avons établi une analyse et
une spécification des besoins qui nous a permis de dégager les fonctionnalités
principales que l’application doit fournir ainsi que les fonctionnalités
secondaires qui répondent aux besoins non fonctionnels qu’elle doit satisfaire.
Par la suite, dans l’étape de conception, nous avons commencé par présenter
l’architecture choisie pour aboutir après à une conception détaillée qui met
l’accent sur l’aspect statique et dynamique de l’application. Enfin, nous avons
présenté les environnements matériels et logiciels utilisés ainsi qu’une
illustration des différentes interfaces graphiques de notre application.
Cette application sera capable non seulement de gérer les concours sujet de
ce mémoire, mais aussi les différents autres concours tels que : concours de
réorientation, inscription aux mastères, recrutement des assistants contractuels,
candidatures pour les bourses d’alternance..etc.
Ce projet nous a permis de s’adapter, de s’améliorer dans le développement

des applications web, d’enrichir et d’approfondir nos connaissances techniques.
En outre, il nous a été bénéfique dans la familiarisation avec la conduite de
projet informatique de façon méthodique et organisée.
45
Webographie
[1] https://helpx.adobe.com/fr/dreamweaver/how-to/publish-manage-websites.html
[2] https://www.sap.com/products/powerdesigner-data-modeling-tools.html
[3] https://www.mysql.com/
[4] https://www.youtube.com/
[5] https://laurent-audibert.developpez.com/Cours-UML/?page=introduction-modelisation-objet
[6] https://www.commentcamarche.com/contents/221-reseaux-architecture-client-serveur-a-3-niveaux
[7] http://www.wampserver.com/
[8] https://help.sap.com/viewer/p/SAP_POWERDESIGNER
[9] https://www.adobe.com/fr/products/photoshop.html
[10] http://www.uml-sysml.org/documentation
[11] https://www.dataone.org/software-tools/powerdesigner
[12] http://freecartoononline.blogspot.com/2011/08/architecture-clientsserveur-internet.html
[13] https://www.wikipedia.org/
[14] https://www.itechempires.com/2016/05/export-data-from-mysql-to-csv-using-php/
46
Annexes
47
Template AdminLTE
SYSTÈME D’ADMINISTRATION FAIT SOUS BOOTSTRAP 3
48
49
50
51
52
53
54
55
Résumé
Le travail réalisé dans ce présent mémoire s’articule autour du concept de
l’implémentation des services en ligne au sein des sites web universitaires.
Suite à l’étude du système existant, nous avons opté à une solution informatique qui
facilite la tâche de gestion des concours lancés par l’université de Gabès à la fin de
chaque année universitaires.
Afin d’éviter la saisi des milliers de dossiers et l’utilisation des moyens classiques
pour la classification et l’évaluation, le développement d’une application web était la
solution la plus adaptée à ce besoin.
Mots clés : Concours en ligne, mutation, intégration, deuxième licence, service en

ligne, site web universitaire
Abstract
This project is about the concept of the implementation of online services within
university web sites.
Following the study of the existing system, we opted for a computer solution that
facilitates the task of managing the competitions launched by the University of Gabes
at the end of each academic year.
In order to avoid the typing of thousands of files and the use of traditional means for
classification and evaluation, the development of a web application was the most
appropriate solution to this need.
Keywords : Online competition, transfer, integration, second License, online service,

university website

Application Gestion Concours

Transféré par

Droits d'auteur :

Formats disponibles

Application Gestion Concours

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Application Gestion Concours

Transféré par

Droits d'auteur :

Formats disponibles

MEMOIRE

DE STAGE DE FIN D’ETUDES

«Mastère professionnel en Nouvelles Technologies des

Président : Mme. BOUCETTA Hela

Encadreur : Mme. HOUISSA Houda

Rapporteur : Mme. BEN YOUNES Ahlem

Année Universitaire : 2017 / 2018

A mes chers parents,

C’est avec une grande gratitude et reconnaissance que je réserve

Je tiens en premier lieu à adresser ma reconnaissance et mes

Je remercie également mon encadreur de L’université de Gabès,

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

Chapitre 1 Etude préalable ..................................................................................................... 3

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

1.2 Etude de l’existant :.................................................................................................................... 3

1.3 Critique de l’existant :................................................................................................................. 4

1.4 Solution proposée : ..................................................................................................................... 4

1.5 Spécifications : ........................................................................................................................... 5

1.5.1 Spécification des besoins fonctionnels : .......................................................................................... 5

1.5.2 Spécification des besoins non fonctionnels : .................................................................................... 6

1.5.3 Identification des acteurs: ................................................................................................................ 6

1.5.4 Les diagrammes des cas d’utilisation: .............................................................................................. 7

1.5.4.1 Cas d’utilisation préliminaire:.................................................................................................... 7

1.5.4.2 Cas d’utilisations détaillés: ........................................................................................................ 9

1.5.4.3 Cas d’utilisation «S’authentifier » ............................................................................................. 9

1.5.4.4 Cas d’utilisation «Gérer les comptes » .................................................................................... 10

1.5.4.5 Cas d’utilisation «Gérer les candidatures ».............................................................................. 12

1.5.4.6 Cas d’utilisation «Gérer les établissements » .......................................................................... 15

1.5.4.7 Cas d’utilisation «Gérer les filières»........................................................................................ 17

1.5.4.8 Cas d’utilisation «Gérer le calendrier du concours» ................................................................ 18

Chapitre 2 Conception ................................................................................................... 21

2.1 Introduction ............................................................................................................................. 21

2.2 Architecture de l’application .................................................................................................... 21

2.2.2 Les avantages de l’architecture client/seveur ............................................................................. 22

2.3 Conception détaillée : ............................................................................................................... 23

2.3.1 Vue statique : Diagramme de classes .......................................................................................... 23

2.3.2 Vue dynamique : les diagrammes de séquences ......................................................................... 24

2.3.2.1 Diagramme de séquence système du cas d’utilisation « S’authentifier » ................................ 24

2.3.2.2 Diagramme de séquence système du cas d’utilisation « consulter un compte » ...................... 24

2.3.2.3 Diagramme de séquence système du cas d’utilisation «créer un compte» .............................. 26

Chapitre 3 Réalisation ............................................................................................................ 31

3.1 Introduction ............................................................................................................................. 31

3.2 Environnement de travail ......................................................................................................... 31

3.2.1 Environnement matériel .................................................................................................................. 31

3.2.2 Environnement logiciel ................................................................................................................... 31

3.3 Création de la base de données ................................................................................................. 33

3.4 Implémentation ........................................................................................................................ 35

3.5 Les interfaces de l'application .................................................................................................. 36

3.5.1 Interface d’accueil......................................................................................................................... 36

3.5.2 Interface d’authentification ......................................................................................................... 38

3.5.3 Interface d’inscription .................................................................................................................. 39

3.5.4 Interface « cursus » ....................................................................................................................... 40

3.5.5 Interface « postuler la candidature » .......................................................................................... 41

3.5.6 Interface « imprimer le formulaire » .......................................................................................... 42

3.5.7 Interface « valider la candidature » ............................................................................................ 43

Tableau ‎1-1 Description textuelle du cas d’utilisation «S’authentifier » ...................................................... 9

Tableau ‎1-2 Description textuelle du cas d’utilisation «Créer compte » .................................................... 10

Tableau ‎1-3 Description textuelle du cas d’utilisation «Modifier compte » ............................................... 11

Tableau ‎1-4 Description textuelle du cas d’utilisation «Supprimer compte » ............................................ 11