REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROUN

******** ******* **************

PAIX-TRAVAIL-PATRIE PEACE-WORK-FATHERLAND
**************
******** ****** UNIVERSITY OF DSCHANG
UNIVERSITE DE DSCHANG *************
******** ******* FACULTY OF SCIENCE
FACULTE DES SCIENCES **************
******** ******* DEPARTMENT OF MATHS-INFO
DEPARTEMENT DE MATHS-INFO

Projet de genie logiciel : Contrôle

d’acces en salle d’examen

Rédigé et présenté par :

NOMS & PRENOMS MATRICULES
KENMEUGNE DJOUKO HERCULE SOCRATE CM-UDS-20SCI0383
TEDOM KAMDEM GILLES WILLIAMS CM-UDS-19SCI1276
NGUEDEM NDASSI ELVIE LAURANE
NDAMINI TCHAPGANG OLIVIER CM-UDS-20SCI0063

Option : Réseaux et Services Distribués

Classe LMD : Master 1 (INF4)

Sous l’encadrement de :
Dr SOH MATHURIN

Année Académique 2023-2024

Table des matières
.................................................................................................................................................... 4
CHAPITRE I : INTRODUCTION A LA GESTION DE LA DISCIPLINE EN MILIEU
SCOLAIRE ................................................................................................................................ 4
I. CONTEXTE ..................................................................................................................... 4
II. PROBLEMATIQUE ..................................................................................................... 4
III. OBJECTIF ................................................................................................................... 5
IV. OUTILS A UTILISES ................................................................................................... 5
1. Langage de modélisation ......................................................................................... 5
2. Langage utilisé : Django .......................................................................................... 5
3. Choix du SGBD : Sqlite ........................................................................................... 5
4. Architecture du système ........................................................................................... 6
5. Processus de développement.................................................................................... 6
V. PLAN DE TRAVAIL .................................................................................................. 8
CHAPITRE II : ANALYSE, ALGORITHMES ET .................................................................. 9
STRUCTURES DE DONNEES ................................................................................................ 9
ETUDE DE L’EXISTANT .................................................................................................... 9
II. CRITIQUE DE L’EXISTANT ET SOLUTION PROPOSEE .................................... 9
1. Critique .................................................................................................................... 9
2. Solutions proposées ................................................................................................. 9
III. EXPRESSION DES BESOINS ................................................................................. 10
1. Descriptions des besoins fonctionnels ................................................................... 10
2. Descriptions des besoins opérationnels ................................................................. 10
IV. CONCEPTION DE LA NOUVELLE SOLUTION ..................................................... 11
Utilisation du langage et outils de modélisations ................................................................ 11
a. Présentation d’UML............................................................................................... 11
b. Vue fonctionnelle : Diagramme des cas D’utilisation ........................................... 11
Modélisation conceptuelle des données ............................................................................... 12
Vue structurale : Diagramme de Classe .......................................................................... 12
a. Vue comportementale : Diagramme de Séquence ................................................. 13
b. Diagramme d’état transition .................................................................................. 17
c. Diagramme de déploiement ................................................................................... 18
CHAPITRE III : IMPLEMENTATION DE LA ...................................................................... 19
NOUVELLE SOLUTION........................................................................................................ 19

2
RAPPORT UV PROJET IN III
 3
RAPPORT UV PROJET IN III
 CHAPITRE I : INTRODUCTION A LA GESTION DE LA
DISCIPLINE EN MILIEU SCOLAIRE

Le contrôle d'accès dans une salle d'examen est un élément essentiel pour assurer
l'intégrité du processus d'évaluation et maintenir des conditions équitables pour tous les
candidats. Il vise à prévenir la fraude, à garantir la confidentialité des examens et à
maintenir un environnement propice à la concentration.

I. CONTEXTE

Au cours des dernières années, de nombreuses études ont introduit l’exploitation de

l’information et de la communication Technologies à des fins éducatives, c’est-à-dire pour
améliorer les activités d’enseignement et d’apprentissage. Les systèmes d’examen
électronique simplifient le processus d’évaluation en contrôle assisté par ordinateur et
marquage automatisé. Le nombre d’étudiants dans les universités et les établissements
d’enseignement a considérablement augmenté, et leur évaluation est devenue un processus
très long, les enseignants passant beaucoup de temps à organiser les examens, ce qui peut être
considéré comme un gaspillage des efforts de l’enseignant, surtout s’il existe d’autres
méthodes de contrôles d’accès lors d’un examen. L’exploitation de la technologie devient
indispensable pour résoudre ce problème.

II. PROBLEMATIQUE

Le présent rapport est le résultat de la prise en compte des observations fréquentes des
acteurs du système d’évaluation et de leurs principaux partenaires. En effet, Plusieurs voix
s’élèvent pour dire que « le relâchement général de la surveillance est un des problèmes les plus
graves du système d’évaluation moderne ». Cette affirmation quasi-dramatique qui a trouvé un
écho chez les enseignants, les surveillants et autres personnalités inscrits en formation continue
nous a conduits à approfondir la question du contrôle d’accès en salle d’examen. De ce fait, une
question soulève notre interrogation qui est celle de savoir comment pallier à l’aide de l’outil
informatique au problème du contrôle d’accès en salle d’examen ?

4
RAPPORT UV PROJET IN III
 III. OBJECTIF

L’objectif principal de notre projet est de gérer le contrôle d’accès en salle d’examen
afin de pallier aux insuffisances rencontrées. Ceci en:
▪ Identifiant les candidats en salle d’examen
▪ Enregistrant les présences
▪ Générant les statistiques
Ce projet permettra aux éducateurs, surveillants et autres de se rassurer que tout candidat en
salle d’examen a le droit d’être présent.

IV. OUTILS A UTILISES

Pour pouvoir mettre sur pieds notre plateforme, nous avons choisi des technologies qui
permettent de respecter non seulement la méthode choisie mais également de pouvoir
développer plus facilement et de pouvoir garantir la sécurité de la plateforme grâce à leur
structure, nous avons ainsi :

1. Langage de modélisation

Dans la cadre de notre projet, nous avons opté pour le langage UML (Unified Modeling
Language) qui est un langage formel et normalisé en termes de modélisation objet.

2. Langage utilisé : Django

Technologie utilisée dans le cadre de notre projet, django est un framework python
puissant et convivial qui facilite le développement d’applications web robustes, évolutives et
surtout sécurisées. Dans le cadre de notre projet, djano a été utilisé comme back-end et front-
end car du côté front-end, il apporte une facilite dans la réalisation des vues de notre
application et de la gestion cote administratif de celui-ci, ainsi que du cote back-end, il facilite
la sécurisation de notre application et l’intégration rapide de la fonctionnalité de
reconnaissance faciale utilisée pour identifier les candidats en salle d’examen.

3. Choix du SGBD : Sqlite

Dans le cadre de notre étude, nous avons opté pour le SGBD Sqlite qui est un système de
gestion de base de données relationnelle sans serveur, open source très populaire. Il est conçu
pour être robuste, fiable, portable et largement utilisé pour répondre des applications à

5
RAPPORT UV PROJET IN III
 conception et exécution rapide. Sqlite prend en charge plusieurs langages de programmation,
est utilisé sur différentes systèmes d’exploitation tels que Windows, linux et est également très
extensible.

4. Architecture du système

Notre application est basée sur le MVC (Modèle-Vue-Contrôleur) qui est un pattern
architectural qui sépare les données (le modèle), l'interface homme machine (la vue) et la
logique de contrôle (le contrôleur). Ce modèle de conception impose donc une séparation en
3 couches :
• Le modèle : Il représente les données de l'application. Il définit aussi l'interaction avec la base
de données et le traitement de ces données.
• La vue : Elle représente l'interface utilisateur, ce avec quoi il interagit. Elle n'effectue aucun
traitement, elle se contente simplement d'afficher les données que lui fournit le modèle. Il peut
tout à fait y avoir plusieurs vues qui présentent les données d'un même modèle.
• Le contrôleur : Il gère l'interface entre le modèle et le client. Il va interpréter la requête de ce
dernier pour lui envoyer la vue correspondante. Il effectue la synchronisation entre le modèle
et les vues.
Il permet de générer des événements lors d'une modification du modèle et d'indiquer à
la vue qu'il faut se mettre à jour.

5. Processus de développement
Pour distinguer les besoins techniques et fonctionnels de l’application nous avons
adopté le processus en Y. Le processus en Y ou Two Track Unified Process (2TUP) est une
variante de l’Unified Process qui s’articule plus sur les aspects techniques. En effet ce
processus permet de gérer la complexité technologique, en lui réservant toute une branche de
son cycle, dissociée de l’aspect fonctionnel. Il permet donc en plus, de réduire le risque
technologique. Y est de nature itérative et incrémentale et permet, de ce fait, de faire des
itérations dans ses différentes phases.

6. Création, Environnement et Evolution du Travail

Pour parvenir à la réalisation de notre plateforme, nous avons durant une certaine période
organisée des phases d’analyse, de conceptions et enfin d’implémentation. Durant ces phases,
nous avons appris et usé d’un workflow tout en étant aidé de certains logiciels le tableau ci-
après décrit nos activités répertoriées :

Tableau 1 : Description de l’évolution du travail

DATE TACHES LOGICIELS

6
RAPPORT UV PROJET IN III
 - 23 Etude de l’existant, choix du thème, - Modelio pour la
NOVEMBRE conception, début de modélisation des modélisation des
2023 différents diagrammes, début de diagrammes
(12h-17h) rédaction du cahier de charge - Ms Word
Jusqu’au
- 07
DECEMBRE
2023
(10h15-13h30)
- 08 - Création du projet - Git Hub
DECEMBRE - Initiation au workflow
2023 - Initiation aux commandes git
(8h30- 13h) pour toujours être à jour
commente son travail et
l’envoyer en ligne sans conflits
- 09 - Création des taches - Git Hub
DECEMBRE Avec des issues de git et plus tard - Jira
(xh- xh) avec Jira pour travailler de manière
synchrone et comprendre la notion
de ticket
COMMANDES GIT - git checkout nombranche (pour
migrer d'une branche à l'autre)
- git checkout -b nombranche
(pour créer sa branche)
- git fetch origin main:main (pour
mettre à jour le work en local qui
est sur le main)
- git rebase -i main
- ESC + : Wq pour sortir du rebase
- (Crtl +s ,CTRL+x) pour sortir de
la cmd ( pour les systèmes linux)
- Pour insérer les commit
- 3-git add .
- 4-git commit -m "message a
envoyer"
- git log ( pour voir ses commit)
- Pour regrouper les commits/
squatcher si tu en fais
- git rebase -i main
- 5-1ajouter f et supprimer PICK
sur tous les autres commits sauf

7
RAPPORT UV PROJET IN III
 le premier celui qui gardera le
seul Pick
- Pour cmd Bash :
- ESC + : W pour enregistrer les
modifications du 5-1 commit sur
cmd
- i pour éditer le contenu du cmd
- git push origin francinelle pour
mettre en ligne son tavail

V. PLAN DE TRAVAIL

Dans la suite de notre travail, il sera question pour nous de faire :

▪ Une collecte de donnée sur le contrôle d’accès en salle d’examen
▪ Une expression des besoins
▪ La proposition d’une nouvelle solution
▪ La conception de la solution au travers des différents diagrammes
▪ L’implémentation répondant à notre conception

8
RAPPORT UV PROJET IN III
 CHAPITRE II : ANALYSE, ALGORITHMES ET
STRUCTURES DE DONNEES

ETUDE DE L’EXISTANT
I. ETUDE DE L’EXISTANT

Avant chaque examen, un contrôle d’accès en salle d’examen se fais de manière

traditionnelle, utilisant plusieurs moyens ou méthodes différentes pour valider l’accès
d’un candidat en salle d’examen. Soit en vérifiant si la carte nationale d’identité du
concerne lui correspond ou que tout autre document comme la carte d’étudiant, un
passeport, un reçu de paiement et autre moyen. C’est à partir de cette vérification
individuelle de chaque candidat que les surveillant parvienne à vérifier si effectivement
celui qui se place en face de lui doit entrer dans cette salle d’examen.

II. CRITIQUE DE L’EXISTANT ET SOLUTION PROPOSEE

1. Critique

Ces méthodes utilisées possèdent plusieurs faiblesses, dont il n’est pas vraiment possible
de savoir si une personne est de la classe car l’utilisation de la carte d’identité nationale prouve
juste qu’il est du pays et les utilisations des autres moyens fournissent juste des informations
sur eux mais n’informent en rien s’ils doivent être vraiment là ou non. L’utilisation de ces
méthodes aussi est très lente à appliquer surtout si les candidats sont des centaines voire des
milliers.

2. Solutions proposées

Nous proposons de rendre numérique tout ce qui concerne le contrôle d’acces en salle
d’examen et pour ce fait, nous allons :
▪ Identifier chaque candidat en utilisant la reconnaissance faciale
▪ Marquer les présences en salle d’examen
▪ Générer les statistiques

9
RAPPORT UV PROJET IN III
 III. EXPRESSION DES BESOINS

1. Descriptions des besoins fonctionnels

Les besoins fonctionnels sont l’expression de ce qui le produit ou le service délivré par
le projet devrait être ou faire dans le cadre du contrôle d’accès en salle d’examen. Comme
besoins fonctionnels nous avons :
▪ Préinscription
▪ Connexion
▪ Identification des candidats avec la reconnaissance faciale
▪ Générer les statistiques
▪ Marquer les présences des candidats

2. Descriptions des besoins opérationnels

Les besoins opérationnels concernent les aspects liés à l’exploitation du système, mais
indépendant des fonctions. Comme besoins opérationnels nous avons:
▪ Authentification par login et mot de passe
▪ Système disponible 24h/24
▪ L’administrateur est la seule personne autorisée à définir et modifier les mots de passe
▪ Le personnel administratif fournit les informations en termes des sanctions.
▪ La fiabilité
▪ Le rendement et l’efficacité
▪ L’ergonomie

10
RAPPORT UV PROJET IN III
 IV. CONCEPTION DE LA NOUVELLE SOLUTION

Le Modèle conceptuel de données est une représentation statique du système

d’information. Il a comme objectif de constituer une représentation claire et cohérente des
données manipulées dans le système d’information.
Cette section, sera présentée comme suit : nous commencerons par le choix de la
méthodologie de conception et justification. Ensuite nous identifierons les acteurs et les
diagrammes des cas d’utilisation, puis la présentation du diagramme de classe, diagramme de
séquence le diagramme d’état transition, et enfin le diagramme de déploiement.

Utilisation du langage et outils de modélisations

Dans la cadre de notre projet, nous avons opté pour le langage UML (Unified Modeling
Language) comme une approche de conception. Ci-dessous, nous présentons ce langage puis
nous justifions ce choix.

a. Présentation d’UML
UML (Unified Modeling Language) est un langage formel et normalisé en termes de
modélisation objet. Son indépendance par rapport aux langages de programmation, aux
domaines de l’application et aux processus, son caractère polyvalent et sa souplesse ont fait
de lui un langage universel. En plus UML fournit un moyen astucieux permettant de
représenter diverses projections d'une même représentation grâce aux vues. Une vue est
constituée d'un ou plusieurs diagrammes. A savoir :

b. Vue fonctionnelle : Diagramme des cas D’utilisation

Les cas d’utilisation décrivent un ensemble d’actions réalisées par le système, en réponse
à une action d’un acteur. Ce diagramme représente une unité discrète d’interaction entre un
utilisateur (homme ou machine) et un système. Dans un diagramme de cas d'utilisation, les
utilisateurs sont appelés acteurs (actors), ils interagissent avec les cas d'utilisation (use cases).

Pour simplifier le diagramme de cas d'utilisation, nous allons avoir le diagramme suivant:

11
RAPPORT UV PROJET IN III
Figure 1: Diagramme de cas d’utilisation

Modélisation conceptuelle des données

La modélisation conceptuelle des données permet de dégager l'ensemble des données
manipulées en vue d’élaborer le diagramme de classes. En effet, ce dernier donne une vue
statique du système. Il décrit les types et les objets du système.
Il s’agit donc d’une représentation des données du champ de l’étude ainsi que le lien
sémantique entre ces données, facilement compréhensible, permettant de décrire le système
d’information à l’aide des concepts proposés par le modèle UML.

Vue structurale : Diagramme de Classe

La figure ci-dessous récapitule les tableaux précédents dans un diagramme de classes qui
contient toutes les informations telles que les classes, les méthodes, les associations et les
propriétés.

12
RAPPORT UV PROJET IN III
Figure 2 : Diagramme de classe

a. Vue comportementale : Diagramme de Séquence

Suite aux descriptions textuelles des cas d’utilisation, les scénarios peuvent être
représentés en utilisant des diagrammes de séquences. Le diagramme de séquences permet de
visualiser l’aspect temporel des interactions et de connaître le sens de ces interactions (acteur
vers système ou contraire).

13
RAPPORT UV PROJET IN III
 14
RAPPORT UV PROJET IN III
 Candidat

15
RAPPORT UV PROJET IN III
 16
RAPPORT UV PROJET IN III
 b. Diagramme d’état transition
Le diagramme d’état transition permet de spécifier les réactions d’une partie du système
à des évènements discrets. Dans ce diagramme, lorsqu’un évènement est reçu, une transition
peut être déclenchée et faire basculer l’objet dans un nouvel état.

17
RAPPORT UV PROJET IN III
 c. Diagramme de déploiement

Le diagramme de déploiement permet de montrer la répartition physique des composants

logiciels sur les différentes machines ou nœuds du système. Il permet de visualiser comment
les différents éléments logiciels interagissent avec l'infrastructure matérielle.

18
RAPPORT UV PROJET IN III
 d. Diagramme de Package

19
RAPPORT UV PROJET IN III
 e. Diagramme d’activité

CANDIDAT

20
RAPPORT UV PROJET IN III
 candidat

candidat

21
RAPPORT UV PROJET IN III
 22
RAPPORT UV PROJET IN III
 f. Diagramme de collaboration

candidat

23
RAPPORT UV PROJET IN III
 g. Diagramme d’etat

candidat

24
RAPPORT UV PROJET IN III
 CHAPITRE III : IMPLEMENTATION DE LA
NOUVELLE SOLUTION

Voici en somme les images des prototypes de la solution réalisée pour ce projet :

25
RAPPORT UV PROJET IN III
 26
RAPPORT UV PROJET IN III
 CONCLUSION

L’objectif de ce projet est de concevoir et de développer une application web de contrôle

d’accès en salle d’examen dans le but de faciliter l’identification des candidats en salle
d’examen dans le but de palier a la lente et la fraude en salle d’examen. Notre projet effectué
au sein de l’UNIVERSITE DE DSCHANG dans le cadre
du projet de génie logiciel a été très bénéfique, car il nous a permis de nous familiariser avec
un nouvel environnement de développement et nous a permis aussi d’exploiter ce que nous
avons acquis durant notre cursus scolaire depuis le niveau 1 jusqu’au niveau 4. En plus, ce
projet était une opportunité pour travailler en température professionnel qui exige une
responsabilité, une assiduité et un esprit d’équipe.

27
RAPPORT UV PROJET IN III
BIBLIOGRAPHIE:

- Bibliotheque d’icons : https://heroicons.com

- Stack Over Flow : www.stackoverflow.com
- Support de genie logiciel in4

28
RAPPORT UV PROJET IN III