MEMOIRE ADJE FREJUS LEONEL - Compressed

RÉPUBLIQUE DU BÉNIN
¤¤¤¤¤¤¤¤¤¤
UNIVERSITÉ D’ABOMEY - CALAVI

¤¤¤¤¤¤¤¤¤¤
ECOLE POLYTECHNIQUE D’ABOMEY-CALAVI

¤¤¤¤¤¤¤¤¤¤¤¤¤
DEPARTEMENT DE GENIE INFORMATIQUE ET

TELECOMMUNICATIONS (GIT)
Option : Réseaux Informatiques et Internet (RII)
MÉMOIRE DE FIN DE FORMATION

EN VUE DE L’OBTENTION DU
DIPLÔME D’INGENIEUR DE CONCEPTION
CONCEPTION ET DEVELOPPEMENT D’UNE PLATEFORME

WEB DE GESTION DE DOSSIER D’ETUDIANT : Cas de l’Ecole
Polytechnique d’Abomey-Calavi
Réalisé et soutenu par : Fréjus Léonel Oyédélé ADJE

Le lundi 26 décembre 2016 devant le jury composé de :
Président : Dr. SOGBOHOSSOU Médésu Enseignant à l’EPAC

Membres : Dr. EDOH Thierry Oscar Enseignant UATM/Allemagne
(Maître de mémoire)
M. ANAGO Didier Enseignant à l’EPAC
M. KONNON Appolinaire Ingénieur Réseaux et Systèmes
Année Académique : 2015 – 2016

9ème Promotion
SOMMAIRE
SOMMAIRE ............................................................................................ i
DEDICACES .......................................................................................... iii
REMERCIEMENTS............................................................................... iv
LISTE DES SIGLES ET ABREVIATIONS ............................................. vi
LISTE DES TABLEAUX ......................................................................... x
LISTE DES FIGURES ........................................................................... xii
RESUME.............................................................................................. xiv
ABSTRACT .......................................................................................... xv
INTRODUCTION GENERALE............................................................... 1
PARTIE I SYNTHESE BIBLIOGRAPHIQUE ..................................... 5

Chapitre 1 : Le dossier académique de l’étudiant .............................................................................. 6
Chapitre 2 : Quelques systèmes de gestion des données académiques de l’étudiant......................... 9
PARTIE II MATERIELS ET METHODES ........................................ 17

Chapitre 3 : Méthodologie de conception ........................................................................................ 18
Chapitre 4 : Architecture du système ............................................................................................... 31
Chapitre 5 : Détermination des outils et technologies de développement ....................................... 60
PARTIE III RESULTATS .................................................................. 65

Chapitre 6 : Implémentation et tests ................................................................................................ 66
CONCLUSION ET PERSPECTIVES .................................................... 77
RÉFÉRENCES BIBLIOGRAPHIQUES................................................. 79
ANNEXES ............................................................................................. 82
ANNEXE A | Laravel5.0 : Architecture MVC et Programmation Orientée Objet (POO) .............. 83
ANNEXE B | Les Protocoles de communication ............................................................................. 84
Réalisé par Fréjus Léonel O. ADJE i

ANNEXE C | Présentation du projet dans PhpStorm ...................................................................... 91
ENGLISH VERSION............................................................................. 99
TABLE DES MATIÈRES .................................................................... 113
Réalisé par Fréjus Léonel O. ADJE ii

DEDICACES
Je dédie ce travail,
A toi Seigneur pour tout ce que tu as fait pour moi tout au long de ma vie. Merci
de m’avoir mené jusqu’ici car sans toi je n’y serais pas arrivé. Gloire à Dieu pour
l’éternité.
A mon père Abioyé ADJE et ma mère Bernadette CHABI pour leurs nombreuses
marques d’affection, leurs sacrifices, et leurs précieux conseils qui m’ont permis
de réussir tout au long de mes études ; à mon frère Thierry ; à mes sœurs Edwige,
Urielle et Loéticia ; à mes amis pour leurs soutiens et à Samson ASSOGBA.
Que le Saint Père leur procure la réussite, une bonne santé, une longue et
heureuse vie.
Fréjus Léonel O. ADJE
Réalisé par Fréjus Léonel O. ADJE iii

REMERCIEMENTS
Je m'en voudrais de commencer ce rapport sans présenter mes sincères
remerciements à tous ceux qui, de près ou de loin, ont contribué à l'élaboration de
ce document. Je pense particulièrement :
 Au Professeur Mohamed SOUMANOU, Directeur de l'École

Polytechnique d'Abomey-Calavi (EPAC) et à son adjoint le Professeur
Clément AHOUANNOU ;
 Au Docteur Léopold DJOGBE, Chef du département de Génie
Informatique et Télécommunications (GIT) de l'EPAC ;
 À mon maître de mémoire, le Docteur Thierry Oscar EDOH, qui a accepté
m'encadrer pour le présent travail ainsi que pour ses précieux apports, sa
disponibilité et ses conseils judicieux ;
 Au Professeur Marc Kokou ASSOGBA, Directeur du Laboratoire
d'Electrotechnique de Télécommunications et d'informatique Appliquée
pour m'avoir accueilli dans son laboratoire pour mon stage ;
 Au Docteur Michel DOSSOU, pour son soutien, son aide et ses conseils ;
 Aux Ingénieurs Alahassa BIDOSSESSI, Cédric AMONLE et aux
Messieurs Salimane Adjao MOUSTAPHA, Emmanuel Marie PODANHO,
pour tous leurs conseils, apports, disponibilités et soutiens ;
 À tous les enseignants du département de GIT pour la qualité de leurs
enseignements ;
 À tout le personnel de TEKXL, pour leur accueil chaleureux pendant toute
la durée de mon stage et pour leur aide ;
 Aux aînés pour leur aides et conseils ;
 À toute ma famille pour leur soutien indéfectible ;
 À tous mes camarades de la 9ème promotion du Secteur Industriel de
l'EPAC en particulier Laurenda, Aubrey, Bebert, Éric, Dichoso,
Réalisé par Fréjus Léonel O. ADJE iv

Sébastiano, Prosper, Brunel, Rodolphe, Francine et Rodrigue, pour tous les
bons moments passés ensemble ;
 À tous les membres du CERADEI-GIT (Cercle d'Echange, de Réflexion et
d'Action des Élèves Ingénieurs en Génie Informatique et
Télécommunications) au sein duquel j'ai eu l'honneur de travailler en tant
que Secrétaire Général puis Président du Bureau Exécutif ;
 À mes amis et à tous ceux que je ne pourrais citer ici.
Réalisé par Fréjus Léonel O. ADJE v

LISTE DES SIGLES ET ABREVIATIONS
AJAX Asynchronous JAvascript and Xml

AMUE Agence de Modernisation des Universités et Etablissements
Application POur la Gestion des Etudiants et des
APOGEE
Enseignements
ASP.Net Active Server Pages distributed with .NET framework
CMS Content Management System

CRUD Create Read Update Delete
CSS Cascading Style Sheet
CV Curriculum Vitae
EDI Environnement de Développement Intégré

EPAC Ecole Polytechnique d’Abomey-Calavi
EPFL Ecole Polytechnique Fédérale de Lausanne
FTP File Transfer Protocol
GSM Global System for Mobile Communications
Réalisé par Fréjus Léonel O. ADJE vi

H
HTML HyperText Markup Language

HTTP HyperText Transfer Protocol
ICMP Internet Control Message Protocol

IDE Integrated Development Environment
IETF Internet Engineering Task Force
IGMP Internet Group Management Protocol
IHM Interface Homme-Machine
IP Internet Protocol
JSON JavaScript Object Notation

JSP JavaServer Pages
LAN Local Area Network
MVC Modèle-Vue-Contrôleur (Model-View-Controller)
Réalisé par Fréjus Léonel O. ADJE vii

O
ORM Object Relational Mapping
PC Personal Computer
PGI Progiciel de Gestion Intégré
PHP Hypertext Preprocessor
POO Programmation Orienté Objet
RAID Redundant Arrays of Inexpensive Disks
Sass Syntactically Awesome Style Sheets

SGBD Système de Gestion de Base de Données
SI Système d’Information
SMTP Simple Mail Transfer Protocol
SQL Structured Query Language
SSL Secure Socket Layer
TCP Transmission Control Protocol

Telnet Terminal network – Teletype network
TIC Technologies de l’Information et de la Communication
TLS Transport Layer Security
Réalisé par Fréjus Léonel O. ADJE viii

U
UAC Université d’Abomey-Calavi

UDP User Datagram Protocol
UML Unified Modeling Language
UMTS Universal Mobile Telecommunication System
URL Uniform Resource Locator
UTS University of Technology Sydney
WWW World Wide Web
XML EXtensible Markup Language
Réalisé par Fréjus Léonel O. ADJE ix

LISTE DES TABLEAUX
Tableau 1 : Les acteurs du système et leurs rôles ......................................... 35
Tableau 2 : Authentification de tous les utilisateurs ..................................... 39
Tableau 3 : Gérer les rôles ........................................................................ 40
Tableau 4 : Gérer les droits/permissions ..................................................... 40
Tableau 5 : Gérer les affections de permissions ........................................... 40
Tableau 6 : Créer un compte d’utilisateur ................................................... 41
Tableau 7 : Modifier les informations d’un compte ...................................... 42
Tableau 8 : Activer/Désactiver un compte .................................................. 42
Tableau 9 : Afficher le profil d’un utilisateur .............................................. 42
Tableau 10 : Gérer les thématiques (sujets de discussion) ............................. 43
Tableau 11 : Gérer les commentaires.......................................................... 44
Tableau 12 : Créer et supprimer une université ........................................... 45
Tableau 13 : Modifier les informations d’une université ............................... 45
Tableau 14 : Créer et supprimer une entité .................................................. 45
Tableau 15 : Modifier les informations d’une entité ..................................... 46
Tableau 16 : Gérer les requêtes administratives ........................................... 46
Tableau 17 : Gérer les catégories de requêtes .............................................. 46
Tableau 18 : Gérer les départements .......................................................... 47
Tableau 19 : Mise à jour d’un chef de département ...................................... 47
Tableau 20 : Gérer les options ................................................................... 47
Tableau 21 : Gérer les modules de cours ..................................................... 49
Tableau 22 : Assigner un cours à un enseignant ........................................... 50
Tableau 23 : Gérer les notes des étudiants – Partie 1 .................................... 50
Tableau 24 : Gérer les notes des étudiants – Partie 2 .................................... 50
Tableau 25 : Gérer les projets académiques ................................................. 51
Tableau 26 : Gérer les catégories de projets académiques ............................. 51
Réalisé par Fréjus Léonel O. ADJE x

Tableau 27 : Gérer les calendriers académiques ........................................... 51
Tableau 28 : Gérer les notifications ............................................................ 52
Tableau 29 : Gérer les modèles de notifications ........................................... 52
Tableau 30 : Gérer l’historique .................................................................. 52
Tableau 31 : Gérer des médias................................................................... 53
Table : Actors of our system and theirs roles ............................................ 103
Réalisé par Fréjus Léonel O. ADJE xi

LISTE DES FIGURES
Figure 2.1 : Couverture fonctionnelle du logiciel IS-Academia (Source : [3]).. 12
Figure 3.1 : Schéma de la méthode du Cycle en V ....................................... 18
Figure 3.2 : Architecture « Client-serveur » ................................................ 28
Figure 3.3 : Architecture « 4-tiers » ........................................................... 29
Figure 4.1 : Diagramme global des cas d’utilisation de système .................... 37
Figure 4.2 : Diagramme de cas d’utilisation du paquetage « Gestion des rôles et
permission » ........................................................................................... 39
Figure 4.3 : Diagramme de cas d’utilisation du paquetage « Gestion des comptes
utilisateurs » ........................................................................................... 41
Figure 4.4 : Diagramme de cas d’utilisation du paquetage « Gestion de forums »
.............................................................................................................. 43
Figure 4.5 : Diagramme de cas d’utilisation du paquetage « Gestion des entités
universitaires » ........................................................................................ 44
Figure 4.6 : Diagramme de cas d’utilisation du paquetage « Gestion des unités
d’enseignements » ................................................................................... 48
Figure 4.7 : Diagramme de cas d’utilisation du paquetage « Gestion des projets
académiques » ......................................................................................... 49
Figure 4.8 : Diagramme de séquence du scénario « S’authentifier » ............... 55
Figure 4.9 : Diagramme de séquence du scénario « Valider un compte étudiant »
.............................................................................................................. 56
Figure 4.10 : Diagramme de séquence du scénario « Modifier les informations
d’un département » .................................................................................. 57
Figure 4.11 : Diagramme de séquence du scénario « Ajouter une pièce au
dossier académique » ............................................................................... 57
Figure 4.12 : Diagramme de classes ........................................................... 59
Figure 6.1 : Page de connexion de la plateforme .......................................... 67
Réalisé par Fréjus Léonel O. ADJE xii

Figure 6.2 : Page de validation d’un compte étudiant ................................... 68
Figure 6.3 : Page d’accueil du module de gestion des utilisateurs .................. 69
Figure 6.4 : Profil de l’étudiant .................................................................. 69
Figure 6.5 : Page d’accueil du module de gestion des dossiers académiques ... 70
Figure 6.6 : Interface d’authentification de PHPMyAdmin ........................... 72
Figure B-1 : Transfert de données à travers la pile de protocoles d‘Internet
(Source : [11]) ......................................................................................... 84
Figure B-2 : Relations entre l’architecture du système et les couches de
protocoles ............................................................................................... 85
Figure C-1 : Architecture du projet Laravel dans PhpStorm .......................... 92
Figure C-2 : Contenu du dossier « app » ..................................................... 93
Figure C-3 : Contenu du dossier « config » ................................................. 95
Figure C-4 : Contenu du dossier « database » .............................................. 95
Figure C-5 : Contenu du dossier « public » ................................................. 96
Figure C-6 : Contenu du dossier « resources »............................................. 97
Figure C-7 : Contenu du fichier « .env » ..................................................... 98
Figure 1 : Adopted architecture ............................................................... 102
Figure 2 : Global use cases diagram ......................................................... 105
Figure 3 : Sequence diagram of the authentication scenario ........................ 106
Figure 4 : Class diagram ......................................................................... 107
Figure 5 : Authentification page .............................................................. 109
Figure 6 : User profile ............................................................................ 110
Figure 7 : Home of Users management module ......................................... 110
Figure 8 : Home Page of academic record module ..................................... 111
Réalisé par Fréjus Léonel O. ADJE xiii

RESUME
Le parcours estudiantin d’un étudiant est souvent documenté dans le dossier
académique de l’étudiant. L’Université d’Abomey-Calavi dispose pour chaque
étudiant d’un dossier académique. Ce dernier est l’un des outils indispensables
dans la gestion des données académiques des étudiants en milieu universitaire, en
ce sens qu’il permet de suivre et de contrôler les informations de son cursus. Une
mise à jour régulière du dossier est indispensable pour assurer l’authenticité des
données du dossier ainsi que sa distribution et son accessibilité.
Dans le cadre de notre projet de mémoire, nous avons mis en place une
plateforme de gestion de dossiers académiques des étudiants de l’Ecole
Polytechnique d’Abomey-Calavi. Grâce aux fonctionnalités de notre plateforme
web, nous avons pu automatiser la gestion de ces dossiers ce qui permet de
disposer des dossiers distribués, à jour et accessibles à tous. Parmi les modules
qu’elle intègre, notre plateforme dispose d’une part d’un module de gestion des
utilisateurs, et d’autre part d’un module de gestion des informations académiques
permettant la mise à jour régulière des dossiers.
Mots-clés : Conception, plateforme web, dossier d’étudiant, dossier académique,

dossier universitaire.
Réalisé par Fréjus Léonel O. ADJE xiv

ABSTRACT
The student's background is often documented in an academic record of

student. The University of Abomey-Calavi has this academic record for each
student. This transcript is one of the indispensable tools in managing of student’s
academic data in university environment. This record helps enormously in
processing student's academic data in order to monitor and control the courses of
study details. Regular updating of the record is essential to ensure the authenticity
of the transcript's data as well as its distribution and accessibility.
In our dissertation, we developed a platform for management of student

academic records of Polytechnic of Abomey-Calavi. The functionalities of our
web platform allow us to automate the management of student records, enabling
us to have up-to-date distributed transcripts and accessible to all. Among the
modules it integrates, our platform has two main modules : first, a users
management module, and second a processing of academic data module thus
allowing the regular updating of student records.
Keywords : Design, platform, web application, academic transcript, academic

record, student record.
Réalisé par Fréjus Léonel O. ADJE xv

INTRODUCTION GENERALE
Face aux nombreux défis auxquels sont confrontées les universités (gestion
administrative et financière, suivi des cursus des étudiants, promotion des
meilleurs étudiants, etc.), il est important de souligner le rôle qu’occupe les
technologies de l’information et de la communication (TIC) dans la recherche de
solutions informatiques adéquates. En effet, l’utilisation de dossier académique –
ensemble d’informations relatives à un étudiant ainsi que l’historique du cursus
universitaire de ce dernier – dans les universités est un élément primordial dans le
suivi d’un étudiant et la gestion administrative et financière de son dossier. Ce
dossier qui, dans la majorité des pays en Afrique, se présente communément sous
le format « papier » pose un certain nombre des problèmes dont la non-
distribution, l’absence de mise à jour effective, la perte de certains dossiers, etc.
Afin de palier un tant soit peu à certains de ces problèmes, nous utiliserons les
services de l’Internet (le World Wide Web, le transfert de fichiers, …) pour mettre
sur pied une plateforme web de gestion des données académiques des étudiants
d’une université dans le but de disposer d’un dossier d’étudiant consultable en
ligne.
Par cette étude, nous commencerons d’abord par présenter les différents
éléments qui interviendront dans la conception et la réalisation de la plateforme.
Ensuite nous mettrons en place l’architecture générale de la plateforme puis nous
passerons à l’implémentation du système.
CONTEXTE, JUSTIFICATION ET PROBLEMATIQUE
Dans le cadre du suivi et de la gestion des universités, ces dernières

disposent des informations relatives à chacun de ses étudiants. Ces informations
qui varient d’un étudiant à un autre ainsi que d’une université à un autre, sont dans
Réalisé par Fréjus Léonel O. ADJE 1

certains cas regroupées dans un dossier appelé dossier d’étudiant. Ces dossiers
d’étudiants qui sont pour la majorité en format papier ne sont qu’accessible à un
nombre restreint de personnes. Il faut aussi noter qu’hormis le problème
d’archivage de ces dossiers, ces dernières manquent de mise à jour régulière dans
le temps ce qui diminuent leur valeur et leur authenticité.
Face à ces différents problèmes auxquels il est nécessaire de trouver des

solutions, il est indispensable de mettre à contribution les progrès de
l’informatique. Ainsi, il s’agira de mettre en place un système de gestion des
données académiques des étudiants dans nos universités afin de disposer d’un
dossier académique par étudiant à jour et consultable en ligne.
OBJECTIFS
L’objectif principal qui nous amène à l’exploration de notre sujet est de

mettre en place un système informatique permettant de gérer plus efficacement
les données des étudiants afin de disposer d’un dossier d’étudiant consultable en
ligne.
Plus précisément, il s’agira dans un premier temps de faire une brève étude
de l’existant, suivi d’une analyse des données recueillies lors de l’étude, ensuite
concevoir l’architecture complète du système informatif à mettre en place et enfin
procéder à l’implémentation de la plateforme web.
STRUCTURE DU DOCUMENT
Le présent document expose l’ensemble des recherches et travaux effectués,

ainsi que les résultats obtenus, dans le cadre de notre projet de mémoire qui
s’intitule comme suit : « Conception et développement d’une plateforme web de
gestion de dossier d’étudiant : Cas de l’Ecole Polytechnique d’Abomey-
Calavi ». Cette section nous permet de passer en revue les différentes tâches
effectuées dans le cadre de notre mémoire afin d’atteindre les objectifs que nous

nous sommes fixés. Le présent document comporte (05) cinq chapitres et est
subdivisé en trois parties.
La première partie composée des deux premiers chapitres dont le premier

chapitre nous permet d’avoir une vue d’ensemble sur le concept de dossier
académique de l’étudiant. Nous faisons un bref exposé sur la notion de dossier
académique de l’étudiant. Pour cela nous avons répondu aux questions comme
« Qu’est-ce que le dossier académique de l’étudiant ? », « De quoi est constitué
le dossier académique d’un étudiant ? ». Dans le second chapitre, nous avons
procédé à une étude de quelques systèmes de gestion de données académiques
afin d’avoir une vue d’ensemble des différentes fonctionnalités nécessaires pour
mettre en œuvre une plateforme de gestion de dossier d’étudiant pour l’Ecole
Polytechnique d’Abomey-Calavi.
Les trois prochains chapitres de notre document constituent la deuxième partie.

A travers le troisième chapitre, nous avons présenté notre méthodologie de
conception. Plus précisément, nous avons défini dans un premier temps la
méthode pour la conception de notre solution, ensuite nous avons présenté les
spécifications fonctionnelles des besoins pour le système à mettre en place et enfin
nous avons fait part de l’architecture et du fonctionnement global de la solution
proposée. La modélisation du système est présentée dans le quatrième chapitre.
Nous avons présenté les acteurs et rôles du système et une description détaillée de
chacune des fonctionnalités du nouveau système, en précisant pour chacune
d’elles un ensemble de caractéristiques afin de mieux appréhender le concept et
de faciliter la mise en œuvre. Afin de mieux comprendre comment le système est
modélisé, nous avons utilisé les diagrammes suivants :
 Les diagrammes de cas d’utilisation : Ils permettent de recueillir,

d'analyser et d'organiser les besoins, et de recenser les grandes
fonctionnalités d'un système ;

 Les diagrammes de séquences : Ce sont la représentation graphique des

interactions entre les acteurs et le système selon un ordre chronologique
dans la formulation Unified Modeling Language (UML) ;
 Le diagramme de classes : C’est un schéma utilisé en génie logiciel pour
présenter les classes et les interfaces des systèmes ainsi que les différentes
relations entre celles-ci.
En dernier dans le cinquième chapitre, nous avons parlé des outils et technologies
utilisés pour l’implémentation de notre système.
La dernière partie, c’est-à-dire la troisième partie que représente le dernier

chapitre (chapitre 6), nous a permis de présenter les résultats de nos travaux. Ainsi,
nous avons parlé de l’implémentation de la plateforme ainsi que de son
ergonomie, de ses interfaces et surtout de l’aspect sécuritaire. De plus nous avons
eu à mettre un accent particulier sur les limites du système et à présenter des tests
effectués ainsi que des résultats obtenus.

Première Partie
PARTIE I SYNTHESE BIBLIOGRAPHIQUE

PARTIE I | Chapitre 1 : Le dossier académique de l’étudiant
Chapitre 1 : Le dossier académique de

l’étudiant
Dans le but de mieux cerner l’utilité des Systèmes d’Information des

Ressources Humaines (SIRH), tout au long du présent chapitre nous avons exposé
les généralités sur leur conception et leur architecture.
1.1. Notion de dossier académique de l’étudiant
Pour mieux comprendre l’importance du dossier académique de l’étudiant

dans le processus de gestion des universités, une appréhension initiale de ce qu’est
le dossier académique nécessaire.
Le terme « dossier académique de l’étudiant » représente de manière

littérale un ensemble d’informations relevant du domaine académique
(universitaire plus précisément) d’un étudiant.
Selon le site officiel de l’université de Monash [1], un dossier académique

est une transcription formelle de l’historique académique à l’université. Il contient
toutes les unités d’enseignants étudiées ainsi que le niveau d’évolution dans
chacune d’elles. Il s’agit alors d’un ensemble d’informations recueillies
permettant d’analyser et d’évaluer l’évolution d’un étudiant au sein d’une
université. Il doit alors transcrire fidèlement l’historique académique de l’étudiant
dans l’université dans laquelle ce dernier se trouve. On peut ainsi dire que le
dossier académique de l’étudiant est un outil parmi tant d’autres qui permet aux
universités de suivre et de contrôler le cursus universitaire d’un étudiant.
1.2. Contenu d’un dossier académique
Après avoir défini ce qu’est un dossier académique, nous présenterons dans

cette section son contenu.

En considérant les définitions précédentes d’un dossier académique, nous

pouvons dire que le dossier académique se compose en générale d’un certain
nombre d’éléments :
 Les informations concernant l’identité de l’étudiant ;

 Une liste complète et détaillée de toutes les formations suivies et validées.
Pour chacun d’elles et selon le système en place dans l’université nous
pouvons avoir d’autres informations comme :
o Les offres de formation (Intitulé, numéro d’identification, crédits,
etc.) ;
o Les crédits validés ou non pour tous cours ;
o Les notes et/ou moyennes de chaque cours ainsi que les observations
faites par les encadreurs (enseignants) ;
o Les informations relatives à la période où ces cours ont été suivi
(année académique, semestres) ;
o Les attestations, les diplômes, les prix (si possible) ainsi que les dates
d’obtentions de ces derniers.
 Les informations relatives aux projets et stages académiques effectués ;
 etc.
Selon chaque université, il faut noter que le dossier académique d’un étudiant
peut contenir plus ou moins d’informations ou d’éléments que ceux cités plus
haut.
1.3. Différentes utilisations du dossier académique
Considérant que le dossier académique est un document qui suit le parcours de

l’étudiant, ou lorsque la formation est complète, confirme la qualification finale
de ce dernier, il peut être utilisé pour postuler à des emplois ou pour des demandes
de soutien pour des bourses d’études [1]. Vu l’importance des informations qu’il
renferme il s’avère indispensable lors de l’admission ou du transfert d’un étudiant
d’une université à un autre. En effet, pour passer d’une université ou d’une entité

universitaire à une autre, plusieurs pièces ou/et informations relatives à l’étudiant

ainsi qu’à son cursus lui sont demandées. Dans le cas de l’université d’Abomey-
Calavi par exemple, nous pouvons distinguer entre autres :
 Une fiche de préinscription renfermant des informations sur l’identité

(nom, prénom, sexe, nationalité, …) de l’étudiant ainsi que sur son
inscription (filière, Spécialité, statut, …) ;
 Une copie officielle du (des) diplôme(s) requis pour la formation ;
 Des documents officiels justifiants son identité (Acte de naissance,
Certificat de nationalité, Carte d’identité nationale, etc.) ;
 Etc.
Les éléments cités ci-dessus font partie intégrante du dossier académique d’un
étudiant. Compte tenu des informations qu’il renferme, le dossier académique de
l’étudiant est d’une importance capitale dans la gestion académique des étudiants
d’une université.

PARTIE I | Chapitre 2 : Quelques systèmes de gestion de données académiques de l’étudiant
Chapitre 2 : Quelques systèmes de gestion

des données académiques de l’étudiant
A travers ce chapitre, nous avons procédé à la présentation de trois systèmes

de gestion de données académiques afin d’avoir une vue un peu globale des
différentes fonctionnalités qui y sont implémentées. Les trois systèmes
d’informations (SI) étudiés sont :
 Cocktail-ScolariX : Application open source édité par le consortium

Cocktail ;
 IsAcademia : Système de gestion académique mis en œuvre
parl’Ecole Polytechnique Fédérale de Lausanne (EPFL) en
partenariat avec Equinoxe MIS development ;
 APOGEE (Application pour l’organisation et la gestion des
enseignements et des étudiants) : Progiciel de gestion intégrée (PGI)
développé par l’Agence de mutualisation des universités et
établissements (AMUE).
Cette étude des systèmes existant nous permet de cibler les fonctionnalités
indispensables à mettre en place pour le système de gestion de dossiers
académique de l’étudiant dans le cadre de notre projet.
2.1. Etude du module SCOLARIX du PGI Cocktail
Tout au long de cette section, nous avons présenté le module SCOLARIX

du PGI Cocktail afin de déduire les différentes fonctionnalités de l’application,
ses atouts ainsi que ses insuffisances dans le domaine dans lequel il s’inscrit.

2.1.1. Généralités
ScolariX est une application Open Source de gestion globale de la scolarité

conçue pour tout type d’établissement d’enseignement supérieur et permettant de
gérer les inscriptions administratives des étudiants d’un établissement. En
constante évolution, ScolariX propose une architecture 3-tiers, Java, HTML et
Ajax. Il s’adapte aux établissements possédant des caractéristiques territoriales
des TOM, aux particularités des écoles d’ingénieurs et a été aussi déployé en
Afrique francophone. ScolariX et ses modules offrent liberté, souplesse et
autonomie dans le respect des normes et des procédures d’interopérabilité [2].
2.1.2. Fonctionnalités
Cocktail-ScolariX permet de disposer d’un Système d'Information d’un

référentiel éprouvé, évolutif et Open Source capable de supporter tous les
besoins du plus petit au plus grand des établissements, et ce grâce à l’ensemble
de ces modules à savoir [2] :
 Référentiel des formations

 Gestion des droits et privilèges
 Inscriptions, ré-inscriptions, pré-inscriptions avec paiement en ligne
 Gestion des examens, des notes, résultats et bilans
 Gestion des inscriptions pédagogiques en ligne
 Gestion des groupes pédagogiques : Cours, TD, TP, Projets, ...
 Trombinoscope étudiant
 Gestion des emplois du temps pédagogique 
 Infocentre Scolarité  
 Gestion prévisionnelle des charges d'enseignement 
 Coût de la maquette, liquidation des heures complémentaires
 Edition carte étudiant : solution partenaire 

Et en option nous avons : 
 Gestion et suivi des anciens 

 Affichage web de l'Offre de formation cdm-fr/xml
 Gestion des admissions/candidatures en ligne  
 Business Intelligence 
 Gestion des prises de Rendez-vous
2.2. Etude du SI Is-Academia
Compte tenu du manque de documentations publiques sur ce système

d’information, nous avons tiré la grande majorité des informations de cette section
d’un document [3] de l’EPFL présentant la couverture fonctionnelle de IS-
Academia.
2.2.1. Généralités
Dans le but de mieux gérer ses activités, l’EPFL en collaboration avec la

structure « Equinoxe MIS development » a conçu un logiciel appelé IS-Academia.
IS-Academia est un système d’information complet permettant à tous les
utilisateurs d’avoir accès, chaque fois que cela est souhaité, à l’ensemble des
informations qui leur est nécessaire.
Pour couvrir tous les types d’enseignement présents dans une institution, IS-
Academia est conçu comme un seul système d’information pour assurer aussi bien
la gestion administrative que la gestion académique. Il est multi-écoles ; multi-
langues ; adaptable à toutes les spécificités, qu’elles soient fonctionnelles ou
visuelles. Il est accessible par Internet, utilisant indifféremment les
environnements bureautiques MS-Office ou OpenOffice ; dédié à vos
collaborateurs administratifs et à votre corps enseignant, mais également à vos
étudiants ou prospects et enfin, il ne nécessite aucune installation particulière au
niveau des postes de travail, autre qu’un navigateur Internet.

La figure 2.1 ci-dessous présente une vue d’ensemble de la couverture

fonctionnelle du SI, sous la forme d’une structure d’Ecole et de ses différentes
unités organisationnelles (en bleu).
 Les piliers latéraux (en rouge), présentent les applications dites
transversales. Ces applications sont utilisées ou accessibles par l’ensemble
des autres modules.
 Les principales fonctionnalités proposées aux étudiants sont représentées
dans les blocs inférieurs (en bleu-gris).
Figure 2.1 : Couverture fonctionnelle du logiciel IS-Academia (Source : [3])
2.2.2. Fonctionnalités
Le système d’information de l’EPFL est composé d’un ensemble de

fonctionnalités ou de modules qui lui permettent d’assurer efficacement son rôle.

Les principaux modules et principes conceptuels de ce logiciel se distinguent

comme suit :
 La gestion des personnes

 La gestion des inscriptions
 La gestion de l’enseignement
 La définition des cursus de formation
 Les plans d’études et les inscriptions aux cours
 Le contrôle des études
 Les plans d’examen et le suivi des épreuves
 La gestion de la charge des enseignants : Ce module permet de gérer
l’allocation de la charge des enseignants :
o Attribution des matières enseignées aux enseignants ;
o Prise en compte des activités externes à l’enseignement (recherche,
mandats, etc.) pour un suivi de la répartition du temps dû et une prise
en compte dans une comptabilité analytique.
 Les horaires des cours et les réservations ponctuelles
 La gestion des horaires des examens : il s’agit des fonctionnalités
suivantes :
o Gestion des horaires des examens en tenant compte de l’occupation
des enseignants, des experts, des étudiants et des salles. Les
occupations définies au travers des horaires des cours et des
réservations ponctuelles sont prises en compte dans le calcul des
collisions ;
o Gestion assistée des listes de passage aux épreuves orales par les
délégués de classe ;
o Diffusion de l’horaire des examens par support papier et au travers
du Web. Les horaires peuvent être produits pour un étudiant (en

fonction des inscriptions aux examens et des listes de passage aux

oraux), par classe d’étudiant, par enseignant, par expert et par salle.
 La facturation et le suivi financier
 La gestion des contacts
 La bourse aux stages : ce module gère toutes les étapes liées à la définition
et au suivi des stages d’études.
 L’envoi de courriels
 L’extracteur de données : comme son nom l’indique, ce module permet de
sélectionner une partie de la population de la base de données de IS-
Academia et d’y appliquer une série de filtre afin d’affiner la sélection. Le
résultat issu de l’extracteur constitue la donnée d’entrée pour un certain
nombre de fonctionnalités telles que :
o Génération et envoi d’e-mail avec le module Emailing ;
o Facturation en masse (création de lots de factures) ;
o Impression de bulletins ;
o Inscriptions aux plans d’études et d’examens.
 L’interface avec l’environnement statistique R : il s’agit d’une interface
permettant la communication entre le logiciel R et IS-Academia.
Ce logiciel, grâce à son interface web et son portail sécurisé, peut être ouvert
à l’ensemble des catégories de personnes directement ou indirectement
concernées par la gestion académique de l’Ecole ; il s’agit :
 Des futurs étudiants, des étudiants et des diplômés de l’école ;

 Des enseignants ;
 Des administrateurs des facultés, des sections et des filières
d’enseignement ;
 Des personnes en charge de la gestion centralisée des étudiants ;
 De la direction des écoles et facultés ;
 Des partenaires externes.

2.3. Etude du PGI APOGEE
Cette section présente l’ensemble des informations que nous avons pu

recueillies concernant le Progiciel de Gestion Intégré APOGEE, Application
POur la Gestion des Etudiants et des Enseignements, et permettant d’avoir une
vue d’ensemble des fonctionnalités du logiciel. Les documentations trouvées sur
le logiciel n’étant disponibles que pour les utilisateurs de l’application, nous avons
basé notre étude sur les données du document intitulé « Introduction à la
consultation du dossier étudiant » [4], réalisé pour une formation sur comment
utiliser le logiciel APOGEE.
APOGEE est un logiciel national élaboré par l'AMUE (Agence de

Modernisation des Universités et Etablissements) qui est installé dans environ 90
universités ou établissements.
Son objectif principal est d'assurer la gestion du dossier étudiant qui va de

l'inscription administrative jusqu'aux notes en passant par les stages et les thèses.
Le produit est constitué de domaines (ou modules) qui peuvent être mis en place
progressivement selon les besoins de chaque établissement. Ses principaux
domaines sont :
 IA : Inscription Administrative – DE : Dossier Etudiant

Ces deux domaines permettent d'assurer les inscriptions administratives à
l'Université. Les principaux traitements sont :
o Gestion du dossier administratif (Etat-Civil, historique, …) ;
o Edition de la carte d'étudiant ;
o Calcul des droits universitaires ;
o Transmission des informations aux organismes extérieurs (MEN,
Sécu, Mutuelles, etc.) ;
o Gestion des paiements et remboursements.

 IP : Inscription pédagogique – SE : Structure des Enseignements –

GRP : groupes
Ces 3 domaines permettent d'assurer une partie de la gestion pédagogique.
Les principaux traitements sont :
o Définition des éléments pédagogiques capitalisables ou non ;
o Inscription pédagogique des étudiants (choix, options, etc.) ;
o Constitution de groupes pour usage divers.
 MCC : Modalités de contrôle des connaissances – RE : gestion des
résultats et des notes
Ces 2 domaines permettent d'assurer la gestion des épreuves et le calcul des
notes. Les principaux traitements sont :
o Définition des épreuves d'examen
o Définition des paramètres liés aux sessions
o Définition des règles de calcul de moyennes et des résultats.
o Edition des P.V. et relevés de notes.
 EPR : Epreuves
Le planning des examens, la gestion des calendriers, les convocations des
étudiants et des surveillants, les listes d’émargement et les PV d’examens
sont gérés dans ce module.

Deuxième Partie
PARTIE II MATERIELS ET METHODES

PARTIE II | Chapitre 3 : Méthodologie de conception
Chapitre 3 : Méthodologie de conception
A travers ce chapitre, nous avons exposé la méthodologie qui nous a permis

de mettre en œuvre notre plateforme. Le travail effectué dans cette section nous a
permis d’organiser par ordre de priorité et d’exécution les différentes étapes de la
conception de la plateforme de gestion de dossier d’étudiant. Après avoir exposé
la méthodologie globale de conception adoptée et les besoins du système, nous
avons présenté l’architecture globale choisie pour l’implémentation de notre
plateforme.
3.1. Présentation de la méthodologie de conception adoptée
Dans l’optique d’atteindre l’objectif principal du présent travail, une

méthodologie de conception appropriée a été adoptée et suivie : il s’agit de la
méthode du Cycle en V (processus en cascade). Ce processus de développement
d’applications est illustré par la figure 3.1.
Figure 3.1 : Schéma de la méthode du Cycle en V
Le Cycle en V est un paradigme du développement informatique, qui décrit

les étapes essentielles du développement d’un logiciel, le cycle de vie du projet.

Il est représenté par un V dont la branche descendante contient toutes les étapes
de la conception du projet, et la branche montante toutes les étapes de tests du
projet. La pointe du V, quant à elle, représente la réalisation concrète du projet :
le codage. Aussi les étapes de la branche montante doivent renvoyer de
l’information sur les phases vis-à-vis lorsque des défauts sont détectés, afin
d’améliorer le logiciel.
Chacune des étapes de cette méthode a été caractérisée par des activités
précises menées en vue d’aboutir à notre plateforme finale :
 L’analyse des besoins : au cours de cette étape, nous avons conduit des
entretiens avec le registraire et le Directeur Adjoint de l’EPAC qui nous a
permis d’avoir une idée des besoins réels des futurs utilisateurs de la
plateforme ;
 La spécification : à travers cette étape, nous avons procédé à une analyse
fonctionnelle des besoins retenus pour le système à mettre en œuvre afin
d’identifier et de valider les fonctionnalités essentielles pour la plateforme ;
 La conception préliminaire et détaillée : cette étape a consisté à la
modélisation1 des différentes fonctionnalités et interactions du notre
plateforme ;
 Le codage : au cours de cette étape, nous avons conçu, grâce aux outils de
développement d’applications, la plateforme web pour la gestion de dossier
d’étudiant ;
 Les tests : ont permis de nous assurer que chaque module fonctionnel de la
plate-forme répond aux spécifications fonctionnelles prédéfinies.
1
La modélisation de plate-forme est détaillée en profondeur dans le chapitre 4.

3.2. Définition des besoins du système
Après la présentation de la méthodologie de conception adoptée pour la

mise en œuvre de notre plateforme, il est temps à présent de se focaliser sur une
analyse des besoins de notre application de gestion de dossier d’étudiant. Il sera
question de définir les besoins fonctionnels et non fonctionnels auxquels doit
répondre la plateforme à mettre en œuvre.
3.2.1. Besoins fonctionnels du système
Les besoins fonctionnels expriment une action que doit effectuer le système en
réponse à une demande [5]. Ils sont donc liés aux différentes tâches à réaliser et
doivent être le plus transparent possible pour les utilisateurs.
Suite aux entretiens menés avec quelques membres de l’administration de

l’EPAC et du rectorat annexe de l’UAC, nous sommes arrivés à identifier leurs
principaux besoins en ce qui concerne la gestion des dossiers académique des
étudiants. La liste suivante récapitule les différents points indispensables à
prendre en compte afin de proposer une solution technique adéquate :
● Disposer d’un répertoire à jour des données académiques des étudiants ;

● Alléger la procédure d’obtention des pièces académiques à travers un
système de traitement des requêtes administratives ;
● Mettre en place un module pour la gestion des offres de formations et des
notes des étudiants au niveau de chaque département afin de disposer de
données académiques pour assurer une mise à jour régulière des dossiers ;
● Suivre de façon continue, à travers les modules du système, les
mouvements et modifications effectués sur les dossiers des étudiants afin
d’assurer sa traçabilité ;
● Permettre, grâce aux configurations du système, l’accès au dossier
d’étudiant à d’autres utilisateurs tels que les enseignants, les étudiants eux-
mêmes (en lecture seule) ;

● Mettre en place un système de gestion des archives afin de résoudre le

problème de perte (au fil des années) des documents académiques des
étudiants ;
● Disposer d’un canal permettant l’échange et le partage d’informations au
sein de l’université.
A ces points vient s’ajouter l’interopérabilité du système de gestion des
dossiers académiques avec d’autres systèmes tiers tels que le système de gestion
de la bibliothèque, le système de gestion des identités, etc.
3.2.2. Besoins non fonctionnels
Les besoins non fonctionnels sont des exigences qui ne concernent pas
spécifiquement le comportement du système mais plutôt identifient des
contraintes internes et externes du système. Ce sont des contraintes à prendre en
compte lors de la mise en œuvre de la solution proposée à la problématique de
base. Il en existe de différentes sortes [5] :
 Les besoins d’utilisabilité

Il s’agit des aspects généraux de l’interface utilisateur. Ainsi on peut parler de
l’apprenabilité, la flexibilité et la robustesse. L’apprenabilité, c’est la facilité avec
laquelle l’utilisateur peut prendre en main le logiciel et découvrir ses
fonctionnalités. La flexibilité consiste en la capacité du système à offrir des modes
d’interactions multiples pour répondre aux besoins, préférences et expérience de
l’utilisation et s’adapter au contexte (adaptabilité). La robustesse, quant à elle, est
le niveau de satisfaction dans la réalisation des tâches permises par le système [6].
 Les besoins de performance

Ces besoins décrivent les performances (possibilités optimales) d’exécutions du
système, généralement en terme de temps de réponse.
 Les besoins de disponibilités ou de fiabilité

Il s’agit des critères à prendre en compte afin de définir le niveau de disponibilité

de l’application. Pour les applications critiques, l’expression de ces besoins est
d’une importance capitale et doit alors être explicitement définie. Par exemple
nous pouvons dire qu’une application web est disponible tous les jours de la
semaine sauf les dimanches pour cause de maintenance du système.
 Les besoins de sécurité

Les besoins de sécurité peuvent entre autres définir les niveaux d’accès possibles
pour les utilisateurs du système et les systèmes externes. Ils permettent au client
de spécifier si possible les différents moyens et méthodes sécuritaires
(cryptographie, algorithmes ou systèmes divers) à utiliser pour l’application.
 Les besoins matériels

Ces besoins définissent les configurations matérielles minimales nécessaires au
fonctionnement du système.
 Les besoins de déploiement

Il s’agit ici de la façon dont l’application sera livrée à l’utilisateur final.
L’application peut être sous forme d’un exécutable que l’on pourrait télécharger
et installer ou directement accessible en ligne donc hébergée sur un serveur distant
etc. Ces besoins décrivent la forme ou l’état sous lequel doit se présenter
l’application finale (la solution).
Notre application doit nécessairement assurer un certain nombre de ces besoins :
o L’extensibilité : l’application qui sera mise en place doit être

extensible, autrement dit doit permettre dans le futur d’ajouter ou de
modifier certaines fonctionnalités.
o Les interfaces : l’application doit respecter les principes des Interfaces
Homme-Machine (IHM) tels que l’ergonomie et la fiabilité [6].

o La convivialité : il faudra mettre un accent particulier sur la facilité dans

l’utilisation même par des profanes.
o La performance : le temps d’exécution de toute requête doit être
minimisé le plus possible afin d’assurer une certaine rapidité dans
l’affichage des résultats des requêtes.
o La disponibilité : le système doit pouvoir être disponible tout le temps
sauf pendant les heures de maintenances.
o La sécurité : la protection des informations personnelles étant un point
important nous devons doter notre système de sécurité solide. Ainsi il
sera mis en place un système de protection d’URL, et de gestion de rôles
et de permissions, en plus du système de sécurité du réseau l’application
sera disponible.
o L’environnement matériel : lors de la mise en production de notre
application, nous aurons besoin de matériels tels qu’un serveur web
(avec serveur de base de données intégré) remplissant les critères de
l’environnement de développement, d’un espace de stockage ainsi que
d’un réseaux intranet et une connexion internet fiable.
3.3. Solution d’amélioration du présent dossier
Suite aux besoins précédemment énoncés, nous avons analysé et proposé

une solution basée sur les caractéristiques et les fonctionnalités générales des
systèmes d’informations des établissements d’enseignements supérieurs et plus
précisément celles des plateformes de gestion de dossier d’étudiant.
3.3.1. Vue globale
Pour une meilleure gestion des dossiers académiques des étudiants, nous
proposons de mettre en place un système de gestion centralisé des informations
des étudiants. Ainsi, toutes les données des étudiants seront stockées sur un
serveur principal. Ce dernier aura pour objectif d’échanger ses données pour être

traitées, à travers un réseau de communication constitué de nombreux sites de

niveaux inférieurs que représentent les universités et entités. Afin de permettre le
traitement de ces données par les utilisateurs sur système, une plateforme web
sera mise en place. Elle disposera de nombreuses fonctionnalités basées sur les
besoins formulés précédemment afin d’améliorer la gestion académique d’une
université tout en mettant à la disposition de tous une version numérique et à jour
du dossier académique de l’étudiant.
3.3.2. Spécifications fonctionnelles des besoins
Notre projet consiste en la mise en œuvre d’une plateforme de gestion des

dossiers académiques des étudiants qui aura pour objectif principal de les rendre
plus accessibles. Cette plateforme permettra aux étudiants de consulter et de
suivre leur dossier en temps réel partout où ils se trouvent et aux autorités
d’automatiser certaines tâches en vue de la gestion académique et de l’archivage
des données académiques des étudiants.
Une analyse fonctionnelle des besoins de notre système nous permet de

dégager un certain nombre de fonctionnalités que nous avons pu regrouper en
modules.
 Le module de gestion des données académiques

Ce module constitue l'élément central de notre système car il permettra de traiter
les données de l’étudiant afin d’assurer une mise à jour régulière des dossiers
académiques et leur archivage. Pour cela nous allons implémenter les
fonctionnalités telles que :
o la gestion des offres de formations et de notes ;

o la gestion des projets académiques ;
o la gestion des médias (diplôme, attestation, bulletin, fiche de
préinscription, ...) ;

o la gestion des données de la bibliothèque et d’autres services

disponibles au sein de l’université.
L’ensemble de ces fonctionnalités interagissent entre elles pour permettre
d’atteindre l’objectif visé par ce module.
 Le module concernant la gestion d’entité

Le module de gestion d’entité est un ensemble de fonctionnalités permettant
d’automatiser certaines tâches au sein d’une entité. Il s’agit des requêtes d’ordre
académique dont les demandes de retrait de certains pièces académiques comme
le bulletin, les attestations ainsi que des fonctionnalités permettant de gérer les
départements et options. Les fonctionnalités regroupées dans ce module sont :
o la gestion d’une université à savoir la création d’un compte

universitaire, la modification des informations de l’université, la
suppression ou l’archivage des informations de l’université. Aussi
nous pouvons noter l’affichage du profil d’une université ainsi que
la liste de l’ensemble des universités de la plateforme.
o la gestion d’une entité : Il s’agit ici des mêmes fonctionnalités que la
gestion d’une université. Dans certains cas (universités privées) les
deux (gestion d’une université et d’une entité) module de gestion
peuvent être confondus.
o la gestion des départements (filières) et options d’une universités
(entités).
o la gestion des requêtes administratives au sein d’une université.
 Le module de gestion des utilisateurs
Il s’agit ici d’un ensemble de fonctionnalités permettant de gérer les différentes
actions propres aux utilisateurs de notre système. En effet, nous pouvons
distinguer la gestion des comptes utilisateurs ainsi que la gestion de l’accès au
système.

La gestion des comptes nous permet d’avoir des statistiques sur l’ensemble des
utilisateurs du système. Nous pourrons ainsi gérer la création, l’activation d’un
compte ainsi que le traitement des informations basiques du compte. Ainsi, nous
pouvons énumérer les actions suivantes :
o la création d’un compte utilisateur (étudiant, enseignant,

administrateur) ;
o la validation d’un compte étudiant ;
o la désactivation ou non de la visibilité d’un compte;
o la mise à jour des informations d’un compte (mot de passe,
identifiant, email,...) ;
o la consultation du profil d’un utilisateur ;
o la recherche d’un utilisateur grâce à des outils de recherches ;
o l’affichage des statistiques (Nombre de comptes actifs, visibles,
d’étudiants, etc.).
La gestion de l’accès à la plateforme permet de définir les différents niveaux
d’accès du système. En effet, ce module permettra de créer des rôles pour les
utilisateurs du système et de leurs donner des permissions. Ainsi chaque
utilisateur pourra, selon les droits ou permissions de son rôle, accéder à certaines
interfaces et bénéficier de certaines fonctionnalités
 Le module de gestion des forums

Dans le souci de faciliter l’échange et le partage d’informations (résolution de
problèmes, partage de connaissance, aide) entre les utilisateurs du système et plus
particulièrement entre les étudiants de la plateforme, nous avons décidé de mettre
en place un espace de discussion publique tel qu’un système de gestion de forums.
A tous ces modules vient s’ajouter d’autres fonctionnalités qui apportent un plus
à notre plateforme et permettent d’accroître le niveau de convivialité et de
performance du système. Il s’agit donc :

o d’un système de notifications afin de prévenir chaque utilisateur des

dernières modifications ou activités sur la plateforme ;
o d’un module de gestion des historiques pour retracer les actions ou
opérations successives réalisées au cours d’une session, ceci afin d’en
assurer la traçabilité à toutes fins utiles.
Pour notre projet de mémoire actuel, la plateforme se limitera aux fonctionnalités

permettant la gestion interne d’une entité. Les opérations concernant la gestion de
plusieurs universités (ou d’entités) ainsi que les modules additionnels à savoir la
gestion des notifications et de l’historique ne seront pas pris en compte.
3.3.3. Conception architecturale de notre solution
Afin de réussir la phase d’implémentation de notre solution, nous avons choisi

une architecture de conception parmi les deux architectures suivantes :
● L’architecture “client-serveur”
● L’architecture “n-tiers”
L’architecture “client-serveur”, illustrée par la figure 3.2, fait appel à un mode de
communication à travers un réseau entre plusieurs clients et serveurs. Les
applications accèdent aux données à travers les réseaux sur des machines serveurs
de données disposant d’un Système de Gestion des Bases de Données (SGBD).
Le dialogue entre le client et le serveur se résume à l’envoi de requêtes et aux
données en réponses. On distingue donc deux parties :
1. Le client
2. Le serveur qui se contente de répondre aux requêtes du client.

Figure 3.2 : Architecture « Client-serveur »
Sur la base de l’architecture « client-serveur », l’architecture « 4-tiers », illustrée

par la figure 3.3, permet de séparer la couche de présentation de la couche
applicative (métier). On a ainsi :
1. La couche présentation ou encore interface utilisateur (PC client). Il s’agit

de la partie de l’application visible, qui interagit avec les utilisateurs : on
parle d’Interface Homme-Machine (IHM).
2. La couche applicative ou métier (Serveur d’application Web) correspond à
la partie fonctionnelle de l’application. Elle implémente la “logique” et
décrit les opérations que l’application opère sur les données en fonction des
requêtes des utilisateurs, effectuées au travers de la couche présentation.
3. Cette couche fait partie intégrante du framework Laravel, présenté à la
section 3.4, que nous avons utilisé. Il s’agit d’un composant web composé
d’un créateur de requêtes SQL (Query Builder) et d’un ORM (Eloquent
ORM). Cette couche est une passerelle entre le serveur d’application et le
serveur de base de données. Son rôle consiste à générer des requêtes SQL
selon la fonction appelée par le serveur d’application et d’établir une
connexion avec le serveur de données. En réponse, elle lui renvoie les
données récupérées du serveur de base de données.

4. La couche données (serveur de base de données) s’occupe de l’accès aux

données, des données persistantes au sein d’un SGBD, propres au système
ou gérées par un autre système.
Figure 3.3 : Architecture « 4-tiers »
L’architecture « 4-tiers » ci-dessus présentée, dérive de l’architecture « 3-tiers »

et qualifie la distribution d’applications entre de multiples services et non la
multiplication des niveaux de service : les trois niveaux d’abstractions d’une
application sont toujours pris en compte.
L’architecture “client-serveur” oblige l’installation de l’application sur tous les

postes clients. Ainsi les clients sont fortement sollicités et supportent donc tous
les traitements applicatifs ; ce qui rend complexe et contraignant les mises à jour
qui devront être régulières. Cependant, avec l’architecture « 4-tiers » l’installation
de l’application se fera une seule fois, ce qui rendrait plus facile les mises à jour
de notre solution. Les clients sont donc plus légers et la sécurité des données est
améliorée en ce sens que les liens entre le client, l’application et les données sont
supprimés. Ainsi, compte tenu de ses avantages nous avons donc opté pour
l’architecture « 4-tiers » pour l’implémentation de notre solution.
3.3.4. Fonctionnement globale
Dans cette section, nous avons parlé du fonctionnement global de notre

solution. Le fonctionnement de notre plateforme ressemble au fonctionnement de
base des applications web.

Les utilisateurs se connectent au serveur d’application par le biais d’internet

ou d’un réseau intranet. Notre solution fonctionne de manière que même à défaut
d’une connexion internet, l’on puisse se connecter à notre serveur d’application
afin que les différents services de notre système soient toujours accessibles.
L’application devra être déployée sur un serveur local (propre à l’entité
universitaire) ce qui permettra à tout individu connecté à l’intranet (réseau local)
et ayant les droits requis d’accéder à notre plateforme. Le serveur sur lequel sera
déployé notre solution sera configuré de sorte qu’il puisse aussi être accessible
depuis Internet.
L’échange entre les deux entités (client et application) se fait grâce à des
requêtes HTTP que le client envoie. Ces requêtes sont reçues et traitées par notre
serveur d’application qui à son tour envoie une réponse au client, auteur des
requêtes. Par ailleurs, lors du traitement des requêtes du client, le serveur
d’application transforme au besoin ces requêtes en requêtes SQL qui parviennent
au serveur de données. Ce dernier les exécute et envoie les résultats au serveur
d’application afin que celui-ci puisse transmettre une réponse au format adéquat
(HTML, CSS, JavaScript, JSON, XML, etc.) pour le client. Il est aussi à noter
qu’à chaque connexion à l’application, l’utilisateur doit toujours passer par un
service d’authentification afin de déterminer si ce dernier dispose des droits requis
pour accéder à la plateforme.

PARTIE II | Chapitre 4 : Architecture du système
Chapitre 4 : Architecture du système

Dans ce chapitre nous présentons la méthode de conception choisie
ainsi que la modélisation de la plateforme réalisée à travers les diagrammes
de cas d’utilisation, de séquence et de classe.
4.1. Méthode de conception
Plusieurs approches existent dans le cadre du développement des systèmes

logiciels. Nous pouvons distinguer entre autre l’approche objet et celle
fonctionnelle. Cette dernière consiste à définir les fonctions des composantes d’un
système et leurs relations fonctionnelles. Plus précisément, elle permet une
conception plus détaillée en partant d’un niveau haut vers les niveaux les plus bas.
Par ailleurs, l’approche objet est incontournable dans le cadre du développement
de systèmes logiciels complexes, capables de suivre les évolutions incessantes des
technologies et des besoins applicatifs. Cette démarche se fonde sur des langages
de modélisation, qui permettent de s’affranchir des contraintes des langages
d’implémentation [7]. Afin de visualiser le système et d’identifier les entités de
notre système ainsi que les dépendances logiques entre elles, nous allons passer
dans la section suivante à la modélisation des données de notre solution en
utilisant l’approche objet.
Le langage choisi pour cette méthode est le langage UML. UML est devenu
le langage standard de modélisation des systèmes d’informations. C’est un moyen
d'exprimer des modèles objet en faisant abstraction de leur implémentation, c'est-
à-dire que le modèle fourni par UML est valable pour n'importe quel langage de
programmation. UML est un langage qui s'appuie sur un méta modèle, un modèle
de plus haut niveau qui définit les éléments d'UML (les concepts utilisables) et
leur sémantique (leur signification et leur mode d'utilisation).

Le méta modèle permet de se placer à un niveau d'abstraction supérieur car

il est étudié pour être plus générique que le modèle qu'il permet de construire. Le
méta-modèle d'UML en fait un langage formel possédant les caractéristiques
suivantes :
 Un langage sans ambigüités

 Un langage universel pouvant servir de support pour tout langage orienté
objet
 Un moyen de définir la structure d'un programme
 Une représentation visuelle permettant la communication entre les acteurs
d'un même projet
 Une notation graphique simple, compréhensible même par des non
informaticiens
Le méta modèle permet de donner des bases solides et rigoureuses à ce langage
graphique, dont les représentations graphiques ne sont là que pour véhiculer des
concepts de réalisation. UML offre une manière élégante de représenter le système
selon différentes vues complémentaires grâce aux diagrammes.
4.2. Modélisation du système
Le méta modèle UML fournit une panoplie d'outils permettant de représenter

l'ensemble des éléments du monde objet (classes, objets, ...) ainsi que les liens qui
les relient. Toutefois, étant donné qu'une seule représentation est trop subjective,
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. On distingue deux types
de vues :
● Les vues statiques, c'est-à-dire représentant le système physiquement à

travers certains diagrammes dont :
○ Les diagrammes d'objets

○ Les diagrammes de classes

○ Les diagrammes de cas d'utilisation
○ Les diagrammes de composants
○ Les diagrammes de déploiement
● Les vues dynamiques, montrant le fonctionnement du système. Nous
pouvons distinguer entre autres :
○ Les diagrammes de séquence
○ Les diagrammes de collaboration
○ Les diagrammes d'états-transitions
○ Les diagrammes d'activités
Pour le compte de notre projet, nous allons travailler avec :
 Le diagramme des cas d’utilisation

 Les diagrammes de séquences
 Le diagramme des classes
Le logiciel Visual Paradigm (version 13.1) nous a permis de réaliser les différents
diagrammes cités plus haut.
4.2.1. Les diagrammes de cas d’utilisations
Après analyse du cahier des charges, nous allons présenter de manière

détaillée comment les exigences fonctionnelles seront implémentées, et donc
permettre le développement de notre solution. Dans un premier temps nous allons
identifier les acteurs qui interagissent avec le système, ensuite nous présenterons
à travers des diagrammes les principaux cas d'utilisations du système et enfin nous
exposerons les détails des fonctionnalités du système.
4.2.1.1. Acteurs du système

Cette section nous permettra d’identifier les différents acteurs du notre
système. Par définition, un acteur représente un rôle joué par une entité externe
(utilisateur humain, dispositif matériel ou autre système) qui interagit directement

avec le système étudié. Un acteur peut consulter et/ou modifier directement l’état
du système, en émettant et/ou en recevant des messages susceptibles d’être
porteurs de données [7].
Ainsi, pour le compte de notre application, nous pouvons distinguer les acteurs
humains suivants :
 L’étudiant
 L’enseignant
 Le chef de département : C’est le responsable du fonctionnement
pédagogique et administratif du département.
 L’administrateur (membre du personnel de l’université) : il s’agit d’un
utilisateur possédant des droits ou permissions lui permettant de faire un
certain nombre d’actions sur le système qu’un simple utilisateur ne pourrait
faire.
 Le super-utilisateur : c’est celui qui est à la charge de tout le système. Il
dispose de tous les droits.
Outre ces acteurs humains, il faudra également prendre en compte les systèmes
tiers qui sont connectés à notre plateforme. Il faut noter le système de gestion de
la bibliothèque qui interagit avec la plateforme afin d’échanger des données en
rapport avec l’identité des étudiants du système, le site internet de l’EPAC par
lequel on peut se connecter directement à notre système lorsque certaines
conditions sont remplies. Le tableau 1 présente les rôles des différents acteurs
(utilisateurs) du système.

Tableau 1 : Les acteurs du système et leurs rôles

Acteurs Rôles
Etudiant Le rôle de l’étudiant dans l’application
est de pouvoir consulter les
informations de son dossier,
d’effectuer des requêtes
administratives de tout genre et aussi
de participer au forum de discussions.
Enseignant Comme l’étudiant, l’enseignant a la
possibilité de participer au forum de
discussions. Outre ce rôle il s’occupe
principalement des actions en rapport
avec la gestion des notes des étudiants
et des projets académiques.
Chef de département Dans l'application, le chef de
département se charge de toutes les
tâches relatives à l'administration d'un
département. Administrer un
département passe entre autres par la
gestion des options de ce département,
la gestion des offres de formations, le
contrôle et le suivi des notes.
Administrateur Le rôle de l'administrateur dans notre
système est de gérer toutes les actions
dédiées à la gestion d'une université
et/ou d'une entité. Autrement dit
l'administrateur s'occupe de la gestion
des comptes des utilisateurs du
système, du traitement des requêtes
administratives, de la création des
départements.

Super-utilisateur Le super-utilisateur du système est

chargé de la création des universités
ainsi que des comptes de certains
administrateurs. De plus il a la charge
de la gestion complète des rôles et
permissions du système, ainsi que de la
mise à jour de différentes
fonctionnalités de l’application.
Systèmes externes Les systèmes externes ont pour rôle de
récupérer (suivant leur niveau d’accès)
certaines données du système pour leur
propre fonctionnement. Aussi ils
peuvent transmettre à notre application
des informations spécifiques
permettant la mise à jour de nos
ressources.
Afin de représenter les besoins des utilisateurs du système, on utilisera les

diagrammes de cas d’utilisations ci-dessous. Les cas d’utilisations permettent de
modéliser et de structurer les interactions entre les utilisateurs et le système.
Un cas d’utilisation représente un ensemble de séquences d’actions qui sont

réalisées par le système et qui produisent un résultat observable intéressant pour
un acteur particulier. Il modélise un service rendu par le système. Il exprime les
interactions acteurs/système et apporte une valeur ajoutée « notable » à l’acteur
concerné [7].
L'objectif poursuivi par les cas d'utilisation est de permettre de décrire, dans
des documents lisibles par tous, la finalité des interactions du système et de ses
utilisateurs. La figure 4.1 ci-dessous présente une vue d’ensemble des cas
d’utilisations du système.

Figure 4.1 : Diagramme global des cas d’utilisation de système
A travers l’illustration ci-dessus nous avons présenté les cas d’utilisations

généraux du système. Afin de mieux appréhender le fonctionnement de notre
plateforme, il nous faut détailler ces cas d’utilisations. Ainsi, dans la suite de notre
document, nous allons étudier plus en détails que certains de ces cas d’utilisations.
4.2.1.2. Description détaillée des cas d’utilisations du système

Cette partie consistera en une description détaillée des cas d’utilisations du
système, en précisant pour chacune d'elles :
● Les auteurs
● L’objectif

● Les préconditions : Il s'agit de faire la liste, s'il y a lieu, des conditions à

vérifier avant de débuter le cas d'utilisation.
● Le scénario nominal : Il s'agit de lister les différentes étapes qui
conduisent à la réalisation de la fonctionnalité dans l'idéal des cas c'est à
dire quand tout se passe correctement et qu'il n'y a pas d'imprévus.
● Les exceptions : Il s'agit ici d'étudier pour chaque étape les imprévus qu'il
peut y avoir et comment ces imprévus seront gérés.
En considérant les modules de notre système on distingue les paquetages de cas
d’utilisations suivants :
❖ Gestion des droits d’accès et l’authentification

Ce paquetage est composé des deux grands cas d’utilisations suivants :
● S’authentifier
● Gestion des droits d’accès
Ces deux cas d’utilisations interviennent dans la réglementation de l’accès à la
plateforme. Comme l’illustre la figure 4.2, seul le super-utilisateur intervient dans
le cas d’utilisation “Gestion des droits d’accès” contrairement au cas
d’utilisation “S’authentifier” où interviennent tous les utilisateurs du système.

Figure 4.2 : Diagramme de cas d’utilisation du paquetage « Gestion des rôles

et permission »
Afin de mieux comprendre ces cas d’utilisations, nous allons les étudier à travers
les tableaux ci-dessous.
Tableau 2 : Authentification de tous les utilisateurs

Acteurs Tous les acteurs humains du système
Objectif Permettre aux différents utilisateurs d'avoir accès à leur
compte respectif
Préconditions Avoir d’abord un compte utilisateur
Scénario 1. Renseigner les paramètres de connexion (pseudo,
nominal mot de passe)
2. Valider
Exceptions En cas d’erreur de la combinaison pseudo/mot de passe :
demander de saisir à nouveau les informations

Tableau 3 : Gérer les rôles

Acteurs Super-utilisateur
Objectif Permet de regrouper les utilisateurs du système et ainsi de
leur affecter des droits.
Préconditions Authentification réussie
Scénario 1. Indiquer l’intitulé de la catégorie (type d’utilisateur)
nominal puis créer.
2. Modifier ou supprimer un rôle.
Exceptions 1. Si l’intitulé demandé n’est pas renseigné ou valide :
demander de saisir à nouveau.
2. Empêcher la suppression si le rôle est utilisé.
Tableau 4 : Gérer les droits/permissions

Objectif Permet aux utilisateurs du système d’effectuer des tâches
spécifiques ou d’accéder à des fonctionnalités précises.
Scénario Créer, modifier ou supprimer une permission
nominal
Exceptions Empêcher la modification ou la suppression d’une
permission déjà affectée à un rôle.
Tableau 5 : Gérer les affections de permissions

Objectif Permet de donner des permissions à un rôle précis.
Scénario Ajouter ou retirer une permission
nominal
Exceptions Néant

❖ Gestion des comptes utilisateurs

A travers le diagramme de la figure 4.3 et les tableaux ci-dessous, nous allons
présenter les détails concernant cet ensemble de cas d’utilisations.
Figure 4.3 : Diagramme de cas d’utilisation du paquetage « Gestion des

comptes utilisateurs »
Tableau 6 : Créer un compte d’utilisateur

Acteurs Super-utilisateur et administrateur
Objectif Donne la possibilité de pouvoir utiliser les différentes
fonctionnalités du système
Scénario Saisir les informations requises puis valider
nominal
Exceptions Demander de renseigner à nouveau les informations
incorrectes

Tableau 7 : Modifier les informations d’un compte

Acteurs Tous les utilisateurs
Objectif Permettre la mise à jour des informations du compte
Préconditions 1. Authentification réussie
2. Être un super-utilisateur ou un administrateur pour
certaines modifications.
Scénario Modifier les informations désirées puis enregistrer
nominal
Exceptions Aucun changement n’est effectué si les informations
modifiées sont incorrectes
Tableau 8 : Activer/Désactiver un compte

Acteurs Super-utilisateur ou administrateur
Objectif Activer ou désactiver un compte.
Scénario Cliquer sur un bouton et confirmer l’action.
nominal
Exceptions L’activation/la désactivation sera annulée si le compte est
toujours actif.
Tableau 9 : Afficher le profil d’un utilisateur

Objectif Donne la possibilité de consulter ses informations ou
celles d’autres utilisateurs si possible.
Scénario Cliquer et afficher le profil
nominal
Exceptions Néant

❖ Gestion de forums
La figure 4.4 illustre le diagramme de cas d’utilisations de ce même paquetage.
Figure 4.4 : Diagramme de cas d’utilisation du paquetage « Gestion de

forums »
Comme pour les précédents, les tableaux ci-dessous présentent les détails
fonctionnels du module de gestion de forums.
Tableau 10 : Gérer les thématiques (sujets de discussion)

Acteurs Administrateur, enseignant, étudiant
Objectif Permettre de partager des idées, de discuter ou encore
d’essayer de trouver une solution à un problème
(académique ou divers)
2. Sélectionner un sujet dont on est l’auteur.
Scénario Rechercher, créer un sujet
nominal Publier, masquer, modifier un sujet dont ils sont l’auteur.
L’administrateur peut masquer ou supprimer n’importe
quel sujet.
Exceptions Néant

Tableau 11 : Gérer les commentaires

Acteurs Administrateur, enseignant, étudiant
Objectif Permettre de partager des idées, de discuter ou encore
d’essayer de trouver une solution à un problème
2. Sélectionner un commentaire dont on est l’auteur.
Scénario Créer un commentaire
nominal Publier, masquer, modifier ou supprimer un commentaire
dont ils sont l’auteur
L’administrateur peut masquer n’importe quel
commentaire
Exceptions Néant
❖ Gestion des entités universitaires

Pour mieux comprendre le diagramme de la figure 4.5, nous allons procéder à une
étude détaillée des cas d’utilisations qui le composent.

entités universitaires »

Tableau 12 : Créer et supprimer une université

Objectif Ajout d’une université ou archivage de ses données
Scénario 1. Ajouter une université et créer un compte
nominal administrateur associé
2. Supprimer l’université et le compte associé
Exceptions Interdire l’archivage des données de l’université si elle est
active.
Tableau 13 : Modifier les informations d’une université

Acteurs Administrateur
Objectif Permettre la mise à jour des informations d’une université
Scénario Modifier les informations d’une université
nominal
Exceptions Néant
Tableau 14 : Créer et supprimer une entité

Objectif Ajout d’une entité ou archivage de ses données
Scénario 1. Ajouter une entité et créer un compte
nominal administrateur associé
2. Supprimer l’entité et le compte associé
Exceptions Interdire l’archivage des données de l’entité si elle est
active.

Tableau 15 : Modifier les informations d’une entité

Objectif Permettre la mise à jour des informations d’une entité
Scénario Modifier les informations d’une entité
nominal
Exceptions Néant
Tableau 16 : Gérer les requêtes administratives

Acteurs Tous les utilisateurs sauf le super-utilisateur
Objectif Accélère et automatise le processus
2. Être un administrateur ou un chef de département
Scénario 1. Envoyer une requête
nominal 2. Valider, traiter et répondre à une requête
Exceptions Néant
Tableau 17 : Gérer les catégories de requêtes

Objectif Permettre la gestion efficace des requêtes
Scénario Créer, modifier, supprimer une catégorie de requête
nominal
Exceptions Interdire la suppression ou la modification d’une catégorie
déjà utilisé.

Tableau 18 : Gérer les départements

Acteurs 1. Administrateur
2. Chef de département
Objectif Facilite la gestion des données académiques d’une entité
Scénario 1. Créer d’un département
nominal 2. Modifier, archiver les informations d’un
département
Exceptions Néant
Tableau 19 : Mise à jour d’un chef de département

Objectif Définir un chef pour un département
Scénario Sélectionner un enseignant puis valider
nominal
Exceptions Néant
Tableau 20 : Gérer les options

Acteurs Chef de département
Objectif Permettre de prendre en compte les spécialisations pour
les divers formations
Scénario Créer, modifier ou archiver une option
nominal
Exceptions Néant
❖ Gestion des informations académiques

Pour ce paquetage, nous allons présenter à travers les figures 4.6 et 4.7 des
diagrammes illustrant le fonctionnement des cas d’utilisations “gestion des cours”
et “gestion des projets académiques”. Dans la suite nous allons étudier plus en
détails l’ensemble des cas d’utilisation du paquetage.

Figure 4.6 : Diagramme de cas d’utilisation du paquetage « Gestion des unités

d’enseignements »


projets académiques »
Tableau 21 : Gérer les modules de cours

Objectif Facilite la gestion des différents modules de cours
Scénario Créer, modifier ou archiver un cours
nominal
Exceptions Néant

Tableau 22 : Assigner un cours à un enseignant

Objectif Connaître les enseignants qui dispensent les différents
cours
Scénario Sélectionner un enseignant et un cours puis valider
nominal
Exceptions Demander de reprendre les sélections si une information
est manquante
Tableau 23 : Gérer les notes des étudiants – Partie 1

Acteurs Enseignant
Objectif Disposer des données pour la gestion des décision
académiques finales
Scénario 1- Créer, modifier ou supprimer une note ;
nominal 2- Répondre à une réclamation, faire des observation
Exceptions Néant
Tableau 24 : Gérer les notes des étudiants – Partie 2

Acteurs Etudiant
Objectif Faciliter les réclamations et publier dans son dossier ses
copies.
Sélectionner une note
Scénario 1. Faire une réclamation ;
nominal 2. Ajouter une copie
Exceptions 1. Néant
2. Si rien n’est envoyé demander à nouveau
d’importer une copie

Tableau 25 : Gérer les projets académiques

Acteurs 1. Enseignant
2. Etudiant
3. Enseignant et étudiant
Objectif Facilite la gestion des projets académique
Scénario 1. Créer, modifier, archiver/supprimer, valider un
nominal projet
2. Soumettre un projet
3. Consulter une soumission
Exceptions 1. Interdire la suppression d’un projet ayant des
soumissions
2. Reprendre la soumission si erreur
Tableau 26 : Gérer les catégories de projets académiques

Objectif Facilite la gestion des projets académique
Scénario Créer, modifier, archiver une catégorie
nominal
Exceptions Empêcher la modification ou la suppression d’une
catégorie si elle est utilisée déjà.
Tableau 27 : Gérer les calendriers académiques

Objectif Facilite le suivi des activités académiques
Scénario Programmer le calendrier académique
nominal
Exceptions Néant

❖ Gestion des notifications et de l’historique
Tableau 28 : Gérer les notifications

Objectif Permettre aux utilisateurs d’être informés en temps réel
des mises à jours effectuées.
Scénario Choisir un modèle, créer et envoyer une notification
nominal
Exceptions Néant
Tableau 29 : Gérer les modèles de notifications

Objectif Facilite la création des notifications
Scénario Créer, modifier, ou supprimer un modèle
nominal
Exceptions Néant
Tableau 30 : Gérer l’historique

Acteurs 1. Le système
2. Tous les utilisateurs
Objectif Permettre aux utilisateurs de revoir toutes leurs
précédentes activités sur la plateforme.
Scénario 1. Créer une entrée
nominal 2. Afficher, supprimer l’historique
Exceptions Néant

❖ Gestion des médias
Tableau 31 : Gérer des médias

Objectif Permettre aux utilisateurs de gérer leurs médias.
Scénario Télécharger (exporter), voir l’aperçu, imprimer, importer
nominal (chacune de ces actions dépendent des privilèges des
utilisateurs)
Exceptions Si erreur reprendre le processus
4.2.2. Les diagrammes de séquences
Dans le but de comprendre plus en profondeur le fonctionnement interne de

notre plateforme, nous allons procéder dans cette section à l’étude de chaque
scénario de cas d’utilisation. Pour ce faire, le formalisme UML propose un certain
nombre de diagrammes parmi lesquels nous avons choisi le diagramme de
séquence. Le diagramme de séquence est en effet une représentation intuitive des
interactions entre deux entités d’un système. Il permet d’exprimer et de détailler
le déroulement des étapes successives permettant d’aboutir à la réalisation de
chaque cas d’utilisation.
Pour raison de simplicité, nous allons présenter quatre diagrammes de

séquences. Chaque diagramme correspond à un scénario pris parmi l’ensemble
des scénarios de cas d’utilisation exposés plus haut. Il s’agit des scénarios
suivants :
● Authentification des utilisateurs, qui est un scénario commun à plusieurs

cas d’utilisation de notre système. Le diagramme de séquence de ce
scénario fait intervenir des entités telles que :

o L’acteur principal de ce scénario qu’est représenté par

bonhomme. Il s’agit de tous les utilisateurs du système ;
o Deux interfaces utilisateurs à savoir l’interface de connexion
et le profil de l’utilisateur ;
o Un contrôleur qui s’occupe des traitements en rapport à
l’authentification d’un utilisateur ;
o La base de données du système ;
o La session
● Validation d’un compte étudiant, un scénario du paquetage gestion des

comptes mettant en jeu des entités comme :
o L’acteur principal : l’étudiant ;

o Les interfaces de validation et d’authentification ;
o Le contrôleur qui s’occupe de la validation d’un compte ;
o La base de données
● Modification des informations d’un département, un scénario du paquetage

gestion d’une entité universitaire. Elle met en jeu :
o L’acteur principal qui est le chef de département ;

o Le profil d’un département et l’interface de modification des
informations du département ;
o Les contrôleurs d’authentification et de traitements des tâches
en rapport aux département ;
● Consultation du dossier académique, un scénario du paquetage gestion des

données académique. Nous distinguons pour ce diagramme les entités
suivantes :
o L’acteur principal : l’étudiant ;

o Les pages index et mesFichiers du dossier de l’étudiant ;

o Les contrôleurs d’authentification et de traitements des

actions du dossier de l’étudiant ;
4.2.2.1. Diagramme de séquence du scénario « S’authentifier »

Le diagramme de séquence du scénario « S’authentifier » est présenté dans
la figure 4.8.
Figure 4.8 : Diagramme de séquence du scénario « S’authentifier »
Le diagramme de séquence ci-dessus présente les étapes des processus de

connexion et de déconnexion. Lorsqu’un utilisateur arrive sur la page de
connexion de la plateforme, il entre les informations d’authentifications. Après
vérification de ces informations une nouvelle session est créée et ne prend fin que
quand l’utilisateur décide de se déconnecter.
Passons à présent aux diagrammes de séquence des trois autres cas

d’utilisation énumérés plus haut. Pour chacun des diagrammes, nous supposons
que l’utilisateur s’est déjà authentifié.

4.2.2.2. Diagramme de séquence du scénario « Valider un compte étudiant »

Le diagramme de séquence du scénario « Valider un compte étudiant » est
présenté dans la figure 4.9.
Figure 4.9 : Diagramme de séquence du scénario « Valider un compte

étudiant »
4.2.2.3. Diagramme de séquence du scénario « Modifier les informations

d’un département »
Le diagramme de séquence du scénario « Modifier les informations d’un
département » est présenté dans la figure 4.10.

Figure 4.10 : Diagramme de séquence du scénario « Modifier les informations

d’un département »
4.2.2.4. Diagramme de séquence du scénario « Ajouter une pièce au dossier

académique »
Le diagramme de séquence du scénario « Ajouter une pièce au dossier
académique » est présenté dans la figure 4.11.
Figure 4.11 : Diagramme de séquence du scénario « Ajouter une pièce au

dossier académique »

4.2.3. Diagramme de classes et d’interfaces
Toujours dans l’objectif de modéliser notre système, nous allons présenter

l’un des diagrammes le plus important de la modélisation orientée objet : le
diagramme de classes. Le diagramme de classes, comme son nom l’indique, est
un diagramme qui montre les interactions entre les classes de notre système, il
présente sa structure interne. Il peut également décrire les regroupements de
classes en paquetages, les interfaces et les objets, les classes qui participent à une
collaboration ou qui réalisent un cas d’utilisation, etc. [8]
La figure 4.12 présente les relations qui existent entre l’ensemble des
classes de notre système.

Figure 4.12 : Diagramme de classes

PARTIE II | Chapitre 5 : Détermination des outils et technologies de développement
Chapitre 5 : Détermination des outils

et technologies de développement
Pour la mise en œuvre de notre plateforme, nous avons choisi parmi un

ensemble de technologies web et d’outils, ceux qui nous permettront de concevoir
et d’implémenter notre solution. Comme pour la plupart des plateformes web,
nous avons utilisé des technologies web telles que :
● HTML (HyperText Markup Language), pour le langage de structuration
des pages web. Il s’agit d’un langage de balisage des pages web. Il permet
aussi de définir leur présentation visuelle contrairement au XHTML qui lui
est destiné uniquement à la représentation de la structure d’une page.
● CSS pour celui de présentation des pages web. Le code CSS (Cascade Style
Sheets, ou feuilles de styles en cascade) permet de modifier le style des
éléments X/HTML. Ainsi, nous pouvons changer la couleur, la taille, la
police des caractères, mais aussi l’alignement des textes, des blocs, leur
largeur, hauteur et pleins d’autres propriétés.
● JavaScript qui est un langage de programmation coté client. C’est un
langage qui est interprété par le navigateur (le client) et qui permet de créer
des réactions suite à des évènements sur la page ou à des actions de
l’utilisateur.
● PHP, un langage de programmation coté serveur. Il s’agit d’un langage de
script qui est lu et exécuté sur le serveur où se trouve la page X/HTML
avant que cette dernière ne soit envoyée au navigateur (le client). Il existe
de nombreux autres langages coté serveur dont ASP.NET, Ruby, JSP,
Python, etc. Notre choix s’est porté sur PHP car c’est l’un des langages les
plus utilisés pour la programmation web et offre une multitude d’outils
facilitant le développement ainsi que la maintenance des plateformes web.

De plus, avec ce langage, nous avons la possibilité de choisir notre système

d’exploitation car il est utilisable sur la majorité des systèmes
d’exploitation, comme Linux, de nombreuses variantes Unix, Microsoft
Windows, Mac OS X, RISC OS et d’autres encore. De même, PHP
supporte aussi la plupart des serveurs web dont Apache, IIS, etc. Par
ailleurs, côté serveur de données, il supporte énormément de bases de
données à savoir MySQL, PostgreSQL, CouchDB, etc. [9]
● MySQL, un système de gestion de base de données. Souvent couplé avec
PHP, ce système utilise le langage SQL pour interroger, alimenter ou mettre
à jour les bases de données. Par ailleurs, il existe d’autres systèmes de bases
de données comme Oracle ou Microsoft SQL Server. Le choix de MySQL
est justifié par le fait que nous avons choisi PHP comme langage de
programmation côté serveur et compte tenu de la quantité de données, que
nous aurons à manipuler dans le cas de notre projet, qui n’est pas trop
importante. Néanmoins, nous conseillerons l’utilisation d’un SGBD
comme Oracle lorsqu’on voudra implémenter ce système pour la gestion
de plusieurs universités, autrement dit sur le plan national, parce que la
quantité de données qu’il y aura à manipuler cette fois-ci serait assez
considérable.
5.1. Présentation des frameworks utilisés
En vue de l’implémentation de notre solution, nous avons décidé d’utiliser

un certain nombre de frameworks2 afin de bénéficier d’une structure logicielle
préétablie nous permettant de nous concentrer sur l’essentiel du travail qui est le
développement de notre application. Nous allons présenter dans la suite les
frameworks utilisés : Laravel, Bootstrap, jQuery.
2
Framework : Ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les
grandes lignes de tout ou d’une partie d’un logiciel.

5.1.1. Laravel
Laravel3 est un framework web open-source écrit en PHP. Son concepteur

Taylor Otwel, au lieu de réinventer la roue il a utilisé ce qui existe de mieux pour
chaque fonctionnalité et les a regroupés en ajoutant d’autres fonctionnalités pour
créer son propre framework. Ce dernier est alors constitué d’un mélange de
plusieurs bibliothèques dont Symfony, SwiftMailer, etc. Parmi ces nombreuses
fonctionnalités, nous pouvons noter [10]:
 un système de routage perfectionné (RESTFul et ressources),
 un créateur de requêtes SQL et un ORM performants,
 un moteur de template efficace,
 un système d’authentification pour les connexions,
 un système de validation,
 un système de pagination,
 un système de migration pour les bases de données,
 un système d’envoi d’emails,
 un systèmes de cache,
 une gestion de session…
Comme certains autres frameworks, Laravel a adopté l’architecture MVC4 et la
Programmation Orientée Objet (POO) (Cf. Annexe A).
5.1.2. Bootstrap
Bootstrap5 est l’un des plus populaire framework HTML, CSS at JavaScript
pour le développement de site web responsive, mobile. C’est une collection
d’outils utile à la création de design6 de sites et d’applications web. Ce framework
d’interface est un ensemble d’outils permettant de réaliser aisément des interfaces
3
https://laravel.com
4
MVC : Modèle-Vue-Contrôleur
5
http://getbootstrap.com
6
graphisme, animation et interactions avec la page dans le navigateur...

graphiques grâce à des codes HTML et CSS, des formulaires, boutons, outils de
navigation et autres éléments interactifs qu’il contient, ainsi que des extensions
JavaScript en option.
5.1.3. JQuery
Le framework jQuery7 est une bibliothèque conçue pour simplifier

l’écriture de codes JavaScript et AJAX8. Cette bibliothèque permet de manipuler
les éléments mis en place en HTML pour structurer une page web et mis en forme
en CSS en utilisant des instructions simples qui donnent accès aux immenses
possibilités de JavaScript et AJAX. Il est un élément indispensable dans le
fonctionnement des extensions JavaScript du framework Bootstrap. Dans le
fichier d’une page web, son invocation se fait toujours avant celui de Bootstrap.
5.2. Autres outils de développement
5.2.1. PhpStorm 8.0.1
L’EDI9 PhpStorm10 est un outil complet de développement pour la

conception d’applications web, de Web Services, spécialisé en PHP et qui
supporte un grand nombre de frameworks et CMS11 parmi lesquels nous pouvons
citer Symfony, Drupal, WordPress, Zend Framework, Laravel, Magento, Joomla,
CakePHP, Yii, etc. Il supporte aussi toutes les fonctionnalités du langage PHP
facilitant ainsi la programmation et inclut des technologies de front-end telles que
le HTML5, CSS, Sass, Moins Stylus, CoffeeScript et pleins d’autres. Grâce au
Live Edit, il permet de voir les changements instantanément dans le navigateur.
PhpStorm intègre aussi les systèmes de contrôle de version, les bases de données
7
https://jquery.com
8
AJAX : C’est ...
9
EDI : Environnement de Développement Intégré
10
https://www.jetbrains.com/phpstorm Consulté le 25-11-2016
11
CMS : Content Management Systems qui veut dire en français Système de Gestion de Contenu

(le langage SQL12), les outils en ligne de commande, Vagrant, Composer et bien
d’autres encore.
5.2.2. WampServer 2.5
WampServer est une plateforme de développement Web sous Windows

pour des applications Web dynamiques à l’aide du serveur Apache2, du langage
de scripts PHP et d’une base de données MySQL13. Il intègre également
PHPMyAdmin pour assurer une gestion plus facile des bases de données.
Apache14 est le plus populaire des serveurs HTTP. Il est produit par la “Apache
Software Foundation”15.
5.2.3. Visual Paradigm 13.1
Visual Paradigm est en général un éditeur de diagrammes qui propose une

suite logicielle composée de plusieurs outils. Pour la modélisation de notre
plateforme, nous avons uniquement employé Visual Paradigm for UML dans sa
version communautaire 13.1.
5.2.4. Git
Git16 est un gestionnaire de version libre et décentralisé. Il constitue un

support pour le déploiement de projets de développement. Git permet d’avoir
plusieurs branches locales qui peuvent être toutes indépendantes les unes des
autres. En effet, il permet de disposer de plusieurs instances de nos projets et de
pouvoir les gérer de manière indépendante. Nous pouvons alors sauvegarder les
changements intervenus dans un fichier, les suppressions de fichiers dans le
projet, les fusions de plusieurs branches de travail et pleins d’autres choses encore.
12
SQL : Structured Query Language
13
http://www.wampserver.com
14
Site officiel Projets Apache : http://apache.org
15
https://doc.ubuntu-fr.org/apache2 Consulté le 26-11-2016
16
https://git-scm.com

Troisième Partie
PARTIE III RESULTATS

PARTIE III | Chapitre 6 : Implémentation et tests
Chapitre 6 : Implémentation et tests

Après conception et modélisation de notre solution, nous allons présenter
dans ce paragraphe les grands points de l’implémentation de notre plateforme.
Dans la suite de cette section, nous avons fait une présentation des interfaces de
notre plateforme et parlé de l’ergonomie, ensuite nous sommes passé à un exposé
sur la sécurisation du système et enfin nous avons présenté les résultats de nos
tests.
6.1. Ergonomie et interfaces
Il ait dit plus haut que notre plateforme devrait tenir compte de certains
besoins non fonctionnels afin de rendre notre application simple et facile
d’utilisation. Ainsi, grâce au design de notre plateforme, nous pouvons y accéder
avec n’importe quel support car il s’adapte à tous les médias. De plus nous avons
essayé d’utiliser une palette de couleur qui n’est pas trop agressif afin d’éviter des
problèmes aux utilisateurs qui sont photosensibles. L'organisation des menus
permet de vite accéder aux fonctionnalités de la plateforme. Il faut aussi noter que
la plateforme est compatible avec les navigateurs les plus courants : Internet
Explorer, Mozilla, Firefox, Safari…
6.1.1. La page d’authentification
La page d’authentification constitue la première interface de notre

plateforme, autrement dit c’est le point d’entrée de notre application. Chaque
utilisateur du système doit s’authentifier afin d’accéder à son compte. Comme
l’illustre la figure 6.1, le processus d’authentification nécessite que l’utilisateur
ait un matricule ou un email et un mot de passe. Nous pouvons aussi constater un
lien permettant d’envoyer un message à l’administrateur du système pour lui
notifier l’oubli et donc la volonté de changer son mot de passe. De plus il existe

un second lien en bas de la page permettant aux étudiants de valider, dans le cas
où cela n’a pas été fait, leur compte.
Figure 6.1 : Page de connexion de la plateforme
6.1.2. La page de validation d’un compte étudiant
La page de validation du compte de l’étudiant, illustré par la figure 6.2,

permet à tous les étudiants de notre plateforme de valider leur compte, après
création de ce dernier par les administrateurs du système. Le processus de
validation nécessite que chaque étudiant dispose de l’ensemble constitué de son
matricule et d’un code d’identification unique. Etant donné que le matricule d’un
étudiant est une information publique, nous avons décidé de le coupler avec un
code d’identification unique afin de permettre au système de vérifier avec une
marge de sécurité qu’il s’agit effectivement de l’étudiant qui dispose d’un compte

enregistré avec le dit matricule. Hormis ces deux informations, l’étudiant doit
ajouter un mot de passe ainsi que son identifiant (pseudonyme) et son email.
Figure 6.2 : Page de validation d’un compte étudiant
6.1.3. Le module de gestion des utilisateurs
Le module de gestion des utilisateurs est l’un des principaux modules de

notre plateforme. Ce module nous propose des fonctionnalités telles que la
création, l’activation ou la suppression d’un compte. Outre ces fonctionnalités,
nous avons quelques données statistiques telles que le nombre d’utilisateurs, le
nombre de compte actifs ou visibles, le nombre de comptes étudiant, etc. La figure
6.3 présente l’interface par défaut de ce module.

Figure 6.3 : Page d’accueil du module de gestion des utilisateurs
6.1.4. Le profil de l’étudiant
La figure 6.4 présente l’interface graphique représentant le profil de

l’étudiant. Le profil de l’étudiant est l’interface sur laquelle nous avons présenté
les informations générales de l’étudiant. Nous distinguons entre autres sur
l’interface le domaine d’étude de l’étudiant, son année d’étude, un lien vers son
dossier académique, des informations personnelles et surtout des formulaires lui
permettant de modifier ses données personnelles (image du compte, mot de passe,
nom, prénoms, …).
Figure 6.4 : Profil de l’étudiant

6.1.5. Le module de gestion des dossiers académiques
Figure 6.5 : Page d’accueil du module de gestion des dossiers académiques
Le module de notre plateforme consacré au dossier académique de l’étudiant est

composé d’un ensemble d’interfaces présentant chacune une catégorie
d’informations propres à l’étudiant. Afin de faciliter la navigation entre ces
interfaces, nous avons mis en place à gauche de toutes les interfaces du module,
un mini menu constitué de l’ensemble des liens de navigation. Ainsi, nous avons
consacré une page pour chacune des rubriques du dossier académique :
● l’identité de l’étudiant, illustré par la figure 6.5, il s’agit de la page d’accueil

du module ;
● le cursus universitaire de l’étudiant ;
● les diplômes et attestations de l’étudiant ;
● l’ensemble des stages que l’étudiant a effectué, avec leurs rapports
respectifs ;
● ses documents (cv, pièces académiques, copies, …) ;
● la liste des emprunts de livres à la bibliothèque, ainsi qu’un ensemble
d’informations relatives à ces emprunts.

Outre ce mini menu, nous avons une partie centrale sur les interfaces qui nous
permet de présenter les informations relatives à chacune de ces rubriques.
6.2. Sécurisation du système
L’une des étapes essentielles du développement d’une application est la

gestion de la sécurité. Pour notre plateforme, nous avons mis un accent particulier
sur la mise en place d’une politique de sécurité afin de garantir la sécurité et
l’intégrité des données. Cette politique de sécurité s’articule sur deux points
essentiels :
 la sécurité des données ;

 la sécurité au niveau de l’application.
Dans la suite, nous allons expliquer plus en détails en quoi consiste ces deux
niveaux de sécurités.
6.2.1. Sécurité des données
Le fonctionnement de toute application (dynamique) passe nécessairement par

une bonne gestion des données. Ainsi, il est important de garantir la disponibilité
et l’intégrité des données de notre plateforme. Dans cette logique, deux éléments
sont mis en jeu :
● l’accès aux données gérées par notre SGBD ;

● la perte des données.
Deux méthodes d’accès nous permettent d’atteindre et de manipuler les données
de notre système. Il s’agit des accès direct et indirect. L’accès direct consiste en
une authentification via une interface de connexion de notre SGBD, illustrée par
la figure 6.6 ci-dessous. Cette méthode d’authentification est liée au compte
d’utilisateur avec lequel nous avons déployé notre application. De cette manière,
aucun accès à la base de données ne sera autorisé à part ceux des personnes
disposant du couple identifiant et mot de passe dudit compte.

Figure 6.6 : Interface d’authentification de PHPMyAdmin
L’accès indirect à notre base de données est la méthode utilisée par notre
plateforme afin de manipuler les données de notre système. Avec cet accès, nous
sommes capables à travers notre plateforme d’ajouter, de lire, de modifier ou de
supprimer des informations dans la base de données. Cette méthode de connexion
utilise les informations de connexion (nom de l’hôte, celui de la base données,
l’identifiant de l’utilisateur, son mot de passe, le port de connexion, etc.) qui sont
inscrites dans notre fichier de configuration .env présenté à l’annexe C. La sécurité
et l’intégrité des informations contenues dans la base de données pourraient être
menacées si un intrus entrait en possession des informations sensibles contenues
ce fichier. Ainsi l’accès au contenu de notre projet sur le serveur d’application est

protégé par une interface de connexion afin que seules les personnes autorisées
puissent y accéder.
En dehors de l’accès au SGBD MySQL, il a été pris en compte le risque de

perte de données qui s’avère très souvent fatal au système, suite au
dysfonctionnement des disques de stockage du serveur qui héberge notre base de
données. Pour limiter ce type de risque nous préconisons les systèmes de
stockages RAID (Redundant Array of Independent Disks) dans sa version17 RAID
6. Cette technologie permet de répartir les données sur plusieurs disques durs afin
d’améliorer la sécurité et la tolérance aux pannes que peut subir l’ensemble du
système de stockage de données. Pour plus de sécurité, nous préconisons aussi de
mettre en place un système de sauvegarde de notre base de données centrale
(serveur principal) sur un serveur secondaire dit serveur de sauvegarde. Cette
méthode nous permet de palier aux problèmes liés aux disfonctionnements des
disques de stockage ou à la disponibilité du serveur principal et redirige ainsi
toutes les requêtes sur le serveur de sauvegarde.
6.2.2. Sécurité au niveau de l’application
A part la sécurité des données du système, nous devons prendre aussi en

compte les risques liés aux fonctionnement de notre plateforme. Ainsi d’autres
sources de menaces peuvent provenir des interfaces de notre application. Deux
points ont essentiellement été considérés et pris en compte à savoir :
● les risques liés aux privilèges accordés aux utilisateurs du système ;

● les risques liés aux entrées des données que traitre la plateforme.
Les privilèges accordés aux utilisateurs peuvent constituer des menaces pour notre
plateforme dans le cas où le compte utilisateur est utilisé à des fins nuisible ou a
été piraté. Afin de palier un tant soit peu à ce problème, nous avons mis en place
17
Pour plus d’information sur les versions du RAID : http://www.prepressure.com/library/technology/raid

un système d’authentification couplé au module de gestions des rôles18 pour

limiter l’accès et définir les niveaux d’accès sur la plateforme. En effet, après
authentification de l’utilisateur et selon son rôle certaines fonctionnalités sont
disponibles ou pas.
En ce qui concerne les données externes traitées par l’application, nous

distinguons deux aspects à savoir :
● les données entrées par les utilisateurs à travers la saisie des informations
envoyées par les formulaires de l’application ;
● les données qui ne sont pas issues des formulaires telles que les cookies, les
paramètres présentes dans les URL, etc.
Ces types de risques ont été prises en compte dans l’implémentation de notre
plateforme à travers le système de validation du framework utilisé.
6.3. Tests et résultats
A l’issue de l’implémentation de notre plateforme, nous sommes passés à la

phase de tests qui consiste à évaluer les différentes fonctionnalités de notre
plateforme. Au terme cette phase de tests, nous devons être capable de répondre
à une importante question qui est de savoir si les résultats de nos travaux sont
conformes aux spécifications fonctionnelles établies au début de nos travaux.
Rappelons que les objectifs que nous nous sommes initialement fixés sont :
 (a) concevoir un module de gestion des étudiants qui permet de disposer

des données personnelles des étudiants pour alimenter leurs dossiers
académiques ;
 (b) concevoir un module de gestion des données académiques (cursus,
pièces académiques, …) des étudiants ;
18
Les rôles des utilisateurs de notre plateforme ont été présentés dans la section 4.2.1.1.

 (c) mettre en place une version numérique des dossiers des étudiants en
utilisant les données des deux précédents modules ;
 (d) concevoir un système de gestion des requêtes administratives qui
permet de faciliter les procédures administratives ;
 (e) implémenter un système de régulation des droits d’accès à la
plateforme ;
 (f) intégrer à la plateforme un espace de discussion privé permettant aux
étudiants de pouvoir obtenir de l’aide que cela soit du point de vue
académique qu’administratif.
Les objectifs (a) et (b) ont quasiment été atteints en ce sens que seules quelques
fonctionnalités de ces modules n’ont pas pu être implémentées. Néanmoins, celles
qui ont été implémentées nous permettent de disposer d’assez de données pour
alimenter les dossiers des étudiants, ce qui nous a permis d’atteindre l’objectif (c).
L’objectif (f) a aussi été atteint ce qui nous permet d’intégrer à la plateforme un
espace de discussion privé. Par contre, les objectifs (d) et (e) ont partiellement été
atteints parce que pour l’un nous n’avons pas pu tenir compte de tous les types de
requêtes ou demandes administratifs et pour l’autre il faudra encore mettre un
accent particulier sur les droits d’accès pour les différents types d’administrateurs
du système.
Pendant la période de tests, les fonctionnalités de l’application ont été

toutes testées pour voir comment elles réagissent face à diverses actions des
utilisateurs. Cela nous a aussi permis d’avoir des commentaires, qui pour la
plupart vont en faveur des exigences non fonctionnelles initialement exprimées.
Cependant, en tenant compte de certains commentaires, il faudra procéder à
quelques améliorations du point de vue de l’utilisabilité de la plateforme.

6.4. Limites du système
Suite aux recherches effectuées dans la première partie de notre document

et aux résultats de nos travaux, il est à noter que notre système de gestion des
dossiers académiques des étudiants ne dispose pas encore de toutes les
fonctionnalités possibles pour une telle application.
Notre plateforme actuelle peut être donc améliorée afin d’automatiser plus
de tâches et de rendre plus dynamique le fonctionnement interne d’une université
et plus particulièrement la gestion des dossiers académiques des étudiants.

CONCLUSION ET
PERSPECTIVES

CONCLUSION ET PERSPECTIVES
Les travaux effectués pour le compte de notre projet de mémoire ont

essentiellement pour objectif la conception d’une solution capable de résoudre les
problèmes d'accessibilité, de distribution et de gestion des dossiers académiques
des étudiants de l’EPAC. Sur la base des problèmes et besoins relevés lors de nos
entretiens avec quelques personnes chargées des affaires académiques aussi bien
à l’EPAC qu’au niveau du rectorat de l’UAC, nous avons pu passer à la
modélisation et à la conception des différentes fonctionnalités de notre solution,
suivant une architecture bien définie. Suite aux choix des technologies et outils de
réalisation de notre solution, nous avons pu l’implémenter et ainsi obtenu une
plateforme web intégrant les modules suivants :
● un module de gestion des données académiques des étudiants permettant

alors d’avoir une version numérique du dossier de l’étudiant ;
● un module de gestion des utilisateurs de la plateforme ainsi que leurs droits
d’accès ;
● un espace de discussion privé principalement pour les étudiants.
En considérant les résultats de nos travaux et les limites de notre système, nous
sommes convaincus que notre plateforme doit subir des améliorations afin qu’elle
puisse accomplir de mieux en mieux son rôle. Pour ce faire, d’autres travaux
auront pour objectifs d’améliorer la plateforme actuelle et d’y intégrer d’autres
modules fonctionnels tels qu’un module de gestion du personnel, un module de
gestion complète des inscriptions. Hormis ces travaux d’améliorations du système
actuel, il s’agira aussi pour de futurs travaux d’étendre ce système de gestion des
dossiers des étudiants à d’autres entités et universités du Bénin.

RÉFÉRENCES
BIBLIOGRAPHIQUES

REFERENCES BIBLIOGRAPHIQUES
[1] Monash University, «Academic record (transcript) - Monash Connect,» [En

ligne]. Available: https://www.monash.edu/connect/official-
documents/academic-transcripts. [Accès le 20 Octobre 2016].
[2] Consortium Cocktail, «PGI Cocktail ScolariX - Cocktail-Office,» [En

ligne]. Available: http://gs2.cocktail-
office.com/Local/cocktailtest/files/51/triptyqueScolarix.pdf. [Accès le 10
Janvier 2017].
[3] EPFL, «Application de gestion académique - IS-Academia - EPFL,» [En

ligne]. Available: http://is-
academia.epfl.ch/files/content/sites/isacademia/files/IS-
Academia_Fonctions.pdf. [Accès le 10 Janvier 2017].
[4] UNIVERSITE PARIS 1 PANTHEON SORBONNE, «Introduction à la

consultation du dossier étudiant - Université Paris 1,» 23 Septembre 2008.
[En ligne]. Available: www.univ-
paris1.fr/fileadmin/sigpedag/apogee/fic_miapo/dossier_etudiant.pdf. [Accès
le 10 Janvier 2017].
[5] Université de Quebec à Montréal, «Les spécifications des besoins,» [En

ligne]. Available:
http://www.grosmax.uqam.ca/nguyen_tho/INF7215/PDF/La%20sp%C3%A
9cification%20des%20besoins.pdf. [Accès le 31 Octobre 2016].
[6] Jean-Yves Antoine, «Enseignement ergonomie IHM : Jean-Yves Antoine,»

[En ligne]. Available: http://www.info.univ-
tours.fr/~antoine/documents_enseignement/IHM_CM_chapII.pdf. [Accès le
31 Octobre 2016].

REFERENCES BIBLIOGRAPHIQUES
[7] B. CHARROUX, A. OSMANI et Y. THIERRY-MIEG, UML 2 Pratique de

la modélisation, Pearson Education France, 2009.
[8] Pascal Roques, UML 2 Modéliser une application web, Eyrolles, 2008.
[9] PHP Documentation Group, «PHP : Que peut faire PHP ? - Manual,» PHP
Documentation Group, [En ligne]. Available:
https://php.net/manual/fr/intro-whatcando.php. [Accès le 25 Novembre
20016].
[10] Maurice Chavelli, «Découvrez le framework PHP Laravel (ancienne

version),» [En ligne]. Available:
http://openclassrooms.com/courses/decouvrez-le-framework-php-laravel.
[Accès le 25 Novembre 2016].
[11] R. R. L. Shklar, Web Application Architecture: Principles, Protocols and

Practices., John Wiley & Sons Ltd, 2003.
[12] «3-Ethernet,» [En ligne]. Available:

http://alois.aubel.online.fr/form/lang/network/3-Ethernet.pdf. [Accès le 6
Décembre 2016].
[13] University of Technology Sydney, «Academic record | University of

Technology Sydney,» University of Technology Sydney, [En ligne].
Available: http://www.uts.edu.au/current-students/managing-your-
course/your-student-info/student-records/academic-record. [Accès le 20
Octobre 2016].

ANNEXES

ANNEXES | Annexe A : Laravel5.0 - Architecture MVC et POO
ANNEXE A | Laravel5.0 : Architecture MVC et Programmation Orientée

Objet (POO)
MVC est un modèle d’organisation du code destiné à répondre aux besoins des
applications interactives en séparant les problématiques liées aux différents
composants au sein de leur architecture respective. Ce paradigme regroupe les
fonctions nécessaires en trois catégories :
1. un modèle (Modèle de données), chargé de gérer les données ;
2. une vue (Présentation, interface utilisateur), chargée de la mise en forme
pour l’utilisateur ;
3. un contrôleur (logique de contrôle, gestion des évènements,
synchronisation), chargé de gérer l’ensemble.
Dans Laravel [10]:
● le modèle est une classe qui étend la classe Model qui permet de gérer de
manière simple et efficace des manipulations des données et
l’établissement automatisé de relations entre tables. Cette classe correspond
à une table d’une base de données.
● le contrôleur peut être un contrôleur classique, un contrôleur RESTFul ou
un contrôleur de ressource.
● la vue est soit un simple fichier avec du code HTML, soit un fichier utilisant
le système de template Blade de Laravel.
La POO est un design pattern qui totalement différent de la programmation
procédurale. Ce type de programmation est basé sur le concept de classe, c’est-à-
dire sur la manipulation des objets. En effet, tout le code est placé dans des classes
qui découlent d’interfaces qui établissent des contrats de fonctionnement.

ANNEXES | Annexe B : Les protocoles de communication
ANNEXE B | Les Protocoles de communication
Dans cette section, nous allons présenter les protocoles qui interviennent dans la
communication entre les éléments de notre système. Comme tous les réseaux
informatiques, le réseau Internet qui est le support du web, repose sur des couches
de protocoles de communication. Ainsi d’après leur conception des couches de
protocoles pour Internet dont le couple TCP/IP est le fondement, L. Shklar et R.
Rosen [11] pensent que le transfert de données sur Internet, illustré par la figure
B-1, se fait à travers (04) quatre couches de protocoles : Réseau, Internet,
Transport, Application.
Figure B-1 : Transfert de données à travers la pile de protocoles d‘Internet

(Source : [11])
Pour chacune des couches, il existe plusieurs protocoles que l’on pourrait utiliser.
La figure B-2 montre les protocoles des différentes couches et nous permet de
comprendre comment ces dernières s’intègrent à l’architecture adoptée à la
section 3.2 de notre document.

Figure B-2 : Relations entre l’architecture du système et les couches de

protocoles
1) A la couche Présentation de notre architecture ne correspond que la couche

Application de la pile des couches de protocoles. Comme nous l’avons
souligné un peu plus haut la couche Présentation de notre architecture est
constitué du client web (navigateur web par exemple). Ce dernier s’occupe
uniquement que de l’affichage de nos pages web. Mais pour cela le client a
besoin d’envoyer des requêtes au serveur d’application (ou serveur web)
qui lui renvoie, sous un format donné, le document (ou la ressource)
demandé. Toutes ces échanges avec le serveur ne sont possibles que grâce
aux protocoles HTTP, FTP, SMTP, ...
2) Ici les couches de protocoles Transport, Internet et Réseau interviennent
dans notre architecture au niveau l’ensemble composé de couche
applicative et de la couche de données. Nous pouvons distinguer les
protocoles TCP, UDP, IP, ICMP, Ethernet, ...
Passons maintenant à la présentation de quelques-uns des protocoles
précédemment cités.
 Le protocole HTTP
HTTP (HyperText Transfer Protocol) est un protocole de communication entre un
client et un serveur web. Conçu pour le World Wide Web (WWW), il est à
l’origine constitué de pages statiques liées entre-elles par des liens hypertextes.

Une variante de ce protocole existe et est sécurisée par l’usage des protocoles SSL
ou TLS : c’est le HTTPS. Afin d‘alimenter les pages web, le client envoie des
requêtes HTTP au serveur web qui lui répond en lui retournant la ressource
demandée. Cet échange d’informations se fait grâce aux différentes méthodes
HTTP19 suivantes :
o OPTIONS : pour obtenir les capacités du serveur HTTP ;

o GET : pour récupérer une ressource, méthode la plus employée ;
o HEAD : pour obtenir les en-têtes d'une ressource, pas le corps ;
o POST : pour envoyer des données vers une ressource ;
o PUT : pour enregistrer une ressource sur le serveur ;
o DELETE : pour supprimer une ressource du serveur ;
o TRACE : requête de diagnostic pour connaître le cheminement à travers les
proxys ;
o CONNECT : pour ouvrir un tunnel afin d'envoyer des données brutes ;
Une requête vers un serveur HTTP est composé de plusieurs lignes
d’informations :
o 1ère ligne : METHODE /chemin/vers/la/ressource HTTP/v \r\n

o Lignes suivantes d'en-têtes avec paires de clé/valeur : clé: valeur \r\n
o Ligne vide de séparation en-tête/corps
o Corps (facultatif) de la requête
Chacune des réponses du serveur correspond à un code de résultat donné et se
présente sous la forme suivante :
19
http://igm.univ-mlv.fr/~chilowi/teaching/subjects/java/net/web/http.html Consulté le 06/12/2016

-------------------------------------------------------
HTTP/1.1 200 OK \r\n
Server: monBeauServeur v3 \r\n
Date: Thu, 09 Oct 2013 09:30:24 GMT \r\n
...autres en-têtes...
Content-Type: text/html \r\n
Content-Length: 2037 \r\n
\r\n
<html>
...
</html>
-------------------------------------------------------
Pour notre plateforme nous avons utilisé ce protocole afin de d’assurer la

communication entre notre serveur d’application web et le client. Ainsi le client,
à travers une URL, questionne le serveur qui traite la requête http et renvoie une
réponse. Le module qui s’occupe du traitement des requêtes du client est un
composant intégré dans le framework Laravel que nous avons utilisé. Ce
composant filtre toutes les requêtes dirigées vers notre système afin de minimiser
les risques d’intrusions et attaques externes. De plus le protocole http a été utilisé
pour la gestion des mails dans notre système.
 Le protocole SMTP
Le Simple Mail Transfer Protocol, généralement abrégé SMTP, est un protocole
de communication utilisé pour gérer le processus d'échange des emails et leur
livraison vers les serveurs de messagerie électronique. Au cours de ce processus,
les machines "parlent" SMTP : le protocole fournit un ensemble standard et fiable
de lignes directrices pour que les serveurs s'identifient et communiquent, en
comprenant qui est l'expéditeur, qui le destinataire, où le contenu doit aller etc.
Nous avons utilisé pour la gestion des mails au sein de notre système le protocole
SMTP. Il s’agit comme pour le protocole SMTP, d’un composant du framework
Laravel. Ce composant est implémenté afin d’utiliser comme protocole de gestion
des mails le protocole SMTP. Néanmoins, Laravel permet aussi l’utilisation

d’autres systèmes de gestions de mails n’utilisant pas forcément le protocole

SMTP.
 Le protocole TCP
Transmission Control Protocol (littéralement, « protocole de contrôle de
transmissions »), abrégé TCP, est un protocole de transport fiable, en mode
connecté, documenté dans la RFC 793 de l'IETF. Dans le modèle Internet, aussi
appelé modèle TCP/IP, TCP est situé au-dessus de IP. Il permet, au niveau des
applications, de gérer les données en provenance (ou à destination) de la couche
inférieure du modèle (c'est-à-dire le protocole IP). Lorsque les données sont
fournies au protocole IP, celui-ci les encapsule dans des datagrammes IP, en fixant
le champ protocole à 6 (Pour savoir que le protocole en amont est TCP...). TCP
est un protocole orienté connexion, c'est-à-dire qu'il permet à deux machines qui
communiquent de contrôler l'état de la transmission. Les caractéristiques
principales du protocole TCP sont les suivantes 20 :
o TCP permet de remettre en ordre les datagrammes en provenance du

protocole IP ;
o TCP permet de vérifier le flot de données afin d'éviter une saturation du
réseau ;
o TCP permet de formater les données en segments de longueur variable
afin de les "remettre" au protocole IP ;
o TCP permet de multiplexer les données, c'est-à-dire de faire circuler
simultanément des informations provenant de sources (applications par
exemple) distinctes sur une même ligne ;
o TCP permet enfin l'initialisation et la fin d'une communication de
manière courtoise ;
20
http://www.commentcamarche.net/contents/538-le-protocole-tcp#les-caracteristiques-du-protocole-tcp
Consulté le 06/12/2016

 Le protocole IP
Internet Protocol (protocole internet, abrégé en IP) est une famille de protocoles
de communication de réseaux informatiques conçus pour être utilisés sur Internet.
Le protocole IP fait partie de la couche Internet de la suite de protocoles TCP/IP.
C'est un des protocoles les plus importants d'Internet car il permet l'élaboration et
le transport des datagrammes IP (les paquets de données), sans toutefois en assurer
la « livraison ». En réalité, le protocole IP traite les datagrammes IP
indépendamment les uns des autres en définissant leur représentation, leur
routage21 et leur expédition.
Le protocole IP détermine le destinataire du message grâce à 3 champs22 :
o Le champ adresse IP : adresse de la machine

o Le champ masque de sous-réseau : un masque de sous-réseau permet au
protocole IP de déterminer la partie de l'adresse IP qui concerne le réseau
o Le champ passerelle par défaut : Permet au protocole Internet de savoir
à quelle machine remettre le datagramme si jamais la machine de
destination n'est pas sur le réseau local
 Le protocole Ethernet
Le protocole Ethernet est le protocole des couches « Réseau » le plus répandu
dans les réseaux locaux (LAN). Ethernet définit principalement :
o Le support d’interconnexion des machines (média) ainsi que la topologie

du réseau ;
o Le signal sur le support : codage, débit, caractéristiques électriques ;
21
Le routage consiste à assurer l'acheminement d'un datagramme IP à travers un réseau en empruntant le chemin
le plus court. http://www.commentcamarche.net/contents/530-le-protocole-ip#le-routage-ip Consulté le
06/12/2016
22
http://www.commentcamarche.net/contents/530-le-protocole-ip#le-role-du-protocole-ip Consulté le
06/12/2016

o La manière d’accéder au support, c’est-à-dire comment pouvoir émettre sur

la ligne ;
o Les trames : celles qui circulent sur le support d’interconnexion des
machines.
A l’émission, Ethernet reçoit les paquets à émettre de la couche Réseau et doit les
transmettre sur le support physique de connexion des machines et à la réception,
Ethernet doit transmettre le paquet reçu à la couche réseau [12].

ANNEXES | Annexe C : Présentation du projet dans PhpStorm
ANNEXE C | Présentation du projet dans PhpStorm
Lors de l’implémentation de notre solution, nous avons utilisé l’Environnement

de Développement Intégré PhpStorm afin de mettre en place les différentes
fonctionnalités de notre plateforme. La figure C-1 nous montre l’architecture du
projet Laravel qui constitue la base du développement de notre solution. A travers
cette figure nous pouvons distinguer les dossiers de notre projet tels que les
dossiers app, bootstrap, config, database, public, ressources, storage, tests et
vendor. Par ailleurs, il faut aussi noter l’existence du fichier .env à la racine du
dossier du projet, qui nous permet de spécifier les paramètres définissant
l’environnement d’exécution de notre application. Parmi les dossiers ci-dessus
cités :
● le dossier bootstrap contient des scripts d’initialisation de Laravel pour le

chargement automatique des classes, la fixation de l’environnement et des
chemins, et pour le démarrage de l’application ;
● le dossier storage qui contient des données temporaires de l’application :
vues compilées, caches, clés de sessions…;
● le dossier tests qui traite des fichiers de tests unitaires ;
● le dossier vendor qui constitue le noyau même de l’architecture d’un projet
Laravel car il comprend tous les composants de Laravel et ses dépendances.
Le contenu des autres dossiers est présenté plus en détails dans la suite de cette
section.

Figure C-1 : Architecture du projet Laravel dans PhpStorm
 Dossier app
Le dossier app, illustré par la figure C-2, constitue la base même de notre
application.

Figure C-2 : Contenu du dossier « app »
Présentons quelques-uns des sous-dossiers du dossier app en donnant pour chacun

une petite description de ce qu’il contient :
● Events et Listeners regroupent les évènements et écouteurs de notre

application ;

● Http contient tout ce qui concerne la communication : les contrôleurs,

routes, middlewares et requêtes ;
● Models est composé de tous les classes utilisées par notre application ;
● Providers : il s’agit de tous les fournisseurs de services de notre application.
Ils servent à initialiser les composants ;
● Repositories : ce dossier contient tous les fichiers permettant de manipuler
nos classes. Il s’agit de fichiers contenant des fonctions qui jouent le rôle
de passerelles entre les contrôleurs et la base données de notre application.
Ils s’occupent du traitement des données provenant des contrôleurs et de la
base de données ainsi que des requêtes SQL.
En effet, ce dossier app contient les éléments essentiels de notre application tels
que les contrôleurs, les services, les modèles, etc.
 Dossier config
Illustré par la figure C-3, il s’agit ici du dossier contenant les fichiers de
configuration de notre système. On peut distinguer les configurations de
l’application, l’authentification, le cache, la base de données, les espaces de noms,
les emails, le système de fichiers, les sessions, ...

Figure C-3 : Contenu du dossier « config »
 Dossier database
Présenté à travers la figure C-4, le dossier database est essentiellement constitué

des fichiers de migrations (structures des tables de la base de données) et de
populations (données) de la base de données.
Figure C-4 : Contenu du dossier « database »

 Dossier public
Le dossier public comporte tout ce qui doit être apparaître dans le dossier public
de tout application web à savoir les images, les scripts, les styles, etc. La figure
C-5 montre le contenu du dossier public de notre plateforme.
Figure C-5 : Contenu du dossier « public »
 Dossier ressources
Le dossier ressources constitue la partie présentation de notre architecture MVC.

Il contient les éléments indispensables des interfaces utilisateurs, il s’agit en
générale du graphisme de notre plateforme : les vues, les fichiers de langues, les
assets (Ex: les fichiers LESS ou Sass). La figure C-6 ci-dessous nous montre
l’architecture de ce dossier.

Figure C-6 : Contenu du dossier « resources »
 Fichier .env
Le fichier .env dont le contenu est présenté à travers la figure C-7, est le fichier
qui permet de spécifier les informations de l’environnement d’exécution de notre
application. Nous pouvons distinguer quatre principaux blocs :
 le premier bloc renseigne sur les informations spécifiques à l’application.

Il s’agit par exemple de l’environnement dans lequel nous nous trouvons
(production ou développement), de la clé de notre application, l’URL de
base de notre plateforme.
 le second bloc renseigne sur les paramètres de connexion à la base de
données tels que le type de base de données (MySQL); l’adresse du serveur
et le port de communication avec la base de données; le nom, l’identifiant
et le mot de passe de la base de données.
 le troisième bloc traite de la nature des gestionnaires de cache, de session,...
 un autre bloc correspond aux informations nécessaires pour le bon
fonctionnement du système de mails.

Figure C-7 : Contenu du fichier « .env »

ENGLISH VERSION

ENGLISH VERSION
Introduction
At university, each student has data that is documented in a record. This is the
student's record. This record is one of the essential elements in the academic
management of a university. In some countries, this academic record is only
available in hard copy. This state of affairs makes tedious the processing of the
data, which does not allow the monitoring and the control of the courses of the
student. This situation also makes it difficult to update the record and does not
guarantee the authenticity of the data and their accessibility.
Our work of memory will consist in proposing, modeling and implementing a
solution to solve the problems related to the system in place.
1. Academic record
Student academic record is a concept whose definition varies according to the
education system or university. So according to the official website of University
of Technology Sydney (UTS) [13], an academic record, also known as an
academic transcript, is an official statement which displays all of your final
subject results achieved through study at UTS as at the date of printing. With
Monash university [1], an academic record is a formal transcript of your academic
history at the University. This definition allows us to understand that in an
academic record we can have all informations which can retrace the student’s
academic background. In this order of idea, we can say that the academic record
represents an academic tool among many others which allows the follow-up and
the management of the university course of a student. Thus, our academic record
confirms our progress or, when your'e complete, our final qualification. You can
use it to :
● apply for jobs

● support applications for scholarships or further study
● register with government or private bodies.

ENGLISH VERSION
Several features make up the academic record of which :
● student name and ID number ;

● date of issue ;
● course and unit titles of:
○ units you have completed ;
○ units in which you're currently enrolled ;
○ units with a fail grade ;
● years of study and teaching periods ;
● marks and grades ;
● qualification and graduation dates ;
● areas of study ;
● access to the library of university ;
● publications ;
● academic projects and internships ;
● and so on.
2. Adopted Solution
2.1. Business architecture of our solution
To implement our platform, we have decided to choose as business architecture,
the « 4-layers » architecture. This is one instance of « n-layers » architecture. This
architecture has been the best choice for us because it is flexible and is more
maintainable than other existing architectures. The figure 1 shows how that
architecture is structured.

ENGLISH VERSION
Figure 1 : Adopted architecture
2.2. Global running

Users connect to the application server through the Internet or an intranet. Indeed,
our solution works even if there is no internet connection, we can connect to our
application server in order that the various services of our system are always
accessible. Thus each user accesses our platform and enjoys full of services
according to his role in the system. The exchange between these two entities
(client and application) is done through HTTP requests that the client sends. These
requests are received and processed by our application server which returns a
response to the client. In addition, when processing client requests, the application
server, if necessary, transforms these queries into SQL queries that reach the data
server. This data server executes them and sends the results to the application
server which can transmit a response to the client in the appropriate format

ENGLISH VERSION
(HTML, CSS, JavaScript, JSON, XML, etc.). It should also be noted that at each
connection to the application, the user must always go through an authentication
service to determine if the user has the rights required to access the platform.
3. Modeling
3.1. Actors identification
By definition, an actor represents an abstraction of a role assumed by an external
entity which can interacts with the studied system. The table below presents the
roles of identified actors of our system.
Table : Actors of our system and theirs roles
Actors Roles
Student In our application, the student role

consist in consulting of informations
of his record, making administrative
requests of any kind and also
participating of the discussion forums.
Teacher Like student, the teacher has the

possibility to participe at the
discussion forums. In addition to this
role, he mainly deals with actions
related to the management of courses
and projects.
Department Head In our application, the department

head is responsible for all tasks
relating to the administration of a
department. Administering a
department includes, among other
things, managing the options of this
department, managing the courses,
control and monitoring the notes.

ENGLISH VERSION
Administrator The administrator role in our system

is to manage all the actions dedicated
to the management of a university and
/ or an entity. In other words, the
administrator takes care of the
management of the accounts of the
users of the system, the handling of
administrative requests, the creation
of the departments.
Super-User The superuser of the system is

responsible for the creation of
universities as well as the accounts of
some administrators. In addition, it is
responsible for the complete
management of the roles and
permissions of the system, as well as
the updating of various functionalities
of the application.
External systems The purpose of external systems is to

recover (depending on their level of
access) certain data from the system
for their own operation. Also, they
can transmit to our application
specific information allowing the
updating of our resources.
3.2. Use cases diagram

A use case is a set of action sequences performed by the system and which
produces an observable result to the benefit of a particular actor. Thus, it models
a service provided by the system. The objective pursued by the use cases is to
describe, in documents that can be read by all, the purpose of the interactions of
the system and its users. The diagram in figure 2 shows a summary of the major
use cases that we have identified in our system.

ENGLISH VERSION
Figure 2 : Global use cases diagram
3.3. Sequences diagram

In order to understand and deepen the internal functioning of our platform, we
will study each scenario of use cases. To do this, the UML formalism proposes
some schemes from which we have chosen the sequence diagram. The sequence
diagram is indeed an intuitive representation of the interactions between two
entities of a system. This allow us to express and detail the successive steps in
realization of each use case. As a result of our work, the figure 3 presents for
example the sequence diagram for authenticating a user who want to access
restricted functionality on our platform.

ENGLISH VERSION
Figure 3 : Sequence diagram of the authentication scenario
3.4. Class diagram

In the interest of continuing with the modeling of our system, we will present one
of the most important diagrams of object-oriented modeling : the class diagram.
The class diagram, as its name indicates, is a diagram that shows the interactions
between the classes of our system, it presents internal structure of our system.
Figure 4 shows the relationships between all the classes in our system.

ENGLISH VERSION
Figure 4 : Class diagram
4. Platform implementation
4.1. Technologies and tools for implementation
For the implementation of our platform, we chose among a set of Web
technologies and tools those that will allow us to design and implement our
solution. Thus, we have mainly use the following features :
● PhpStorm 8.0.1 : an Integrated Development Environment (IDE) ;
● Laravel 5.0 : one most popular PHP framework based on MVC Model ;
● MySQL 5.6.17 : a database manager ;
● Apache Server (version 2.4.9) : a web application server.
Others tools had been also used to make some tasks in the process of developing
our solution. Among them, we have used Visual Paradigm 13.1 to design UML
2.0 diagrams and Git which is a distributed version control system. To design the

ENGLISH VERSION
graphical user interfaces, we use some languages as :

● X/HTML and CSS for making static content of our platform ;
● JavaScript and Ajax for building the dynamic elements and features.
4.2. Presentation of the main user interfaces

We said earlier that our platform should take into account some non-functional
needs in order to make our application simple and easy to use. Thus, the design
of our platform allows us to access with any support because it adapts to all media.
In addition we tried to use a color palette that is not too aggressive to avoid
problems for users who are photosensitive. The organization of the menus makes
it possible to quickly access the functionalities of the platform. It should also be
noted that the platform is compatible with the most common browsers: Internet
Explorer, Mozilla, Firefox, Safari ...
4.2.1. Authentication page

The authentication page is the first interface of our platform, in other words it is
the entry point of our application. To connect to their account, each user in the
system must be authenticated. As shown in the figure 5, the authentication process
requires that user had a number ID (for all student) or email and a password. We
can also see a link to send a message to the system administrator to notify him of
the forgetfulness and therefore the will to change his password. In addition, there
is a second link at the bottom of the page allowing students to validate their
account if this has not been done.

ENGLISH VERSION
Figure 5 : Authentification page
4.2.2. User profile

Figure 6 shows the graphical interface representing the student's profile. The
profile of the student is the interface on which we presented the general
information of the student. We distinguish among other things on the interface the
student's field of study, his year of study, a link to his academic record, personal
information and especially forms allowing him to modify his personal data (image
of the account, password, lastname, firstname, ...).

ENGLISH VERSION
Figure 6 : User profile
4.2.3. Users Management Module Interface

The user management module is one of the main modules of our platform. This
module provides us with features such as creating, enabling or deleting an
account. In addition to these features, we have some statistical data such as the
number of users, the number of active or visible accounts, the number of student
accounts, etc. Figure 7 shows the default interface for this module.
Figure 7 : Home of Users management module

ENGLISH VERSION
4.2.4. Academic record home page

The module of our platform devoted to the academic record of the student is
composed of a set of interfaces each presenting a category of information specific
to the student. In order to facilitate navigation between these interfaces, we have
placed on the left of all the interfaces of the module, a small sidebar consisting of
all navigation links. Thus, we have devoted a page for each of the headings of the
academic record:
● the identity of the student, illustrated in figure 8, is the home page of this
module;
● the university curriculum of the student;
● the diplomas and attestations of the student;
● all the internships that the student has completed, with their respective
reports;
● all its documents (cv, academic files, copies, ...);
● the list of borrowed books from libraries, as well as a collection of
information relating to these loans.
Besides this small sidebar, we have a central part on the interfaces which allows
us to present the information relating to each of these headings.
Figure 8 : Home Page of academic record module

ENGLISH VERSION
Conclusion
The work of our memory project has mainly as objective the design of a solution
able to overcome problems of accessibility, distribution and management of
EPAC students' academic records. On the basis of the problems and needs
identified during our interviews with a few academic staff at both the EPAC and
the UAC rectorate, we were able to move on to the modeling and design of the
different functionalities of our solution, following a well-defined architecture.
Following the choice of technologies and tools to realize our solution, we were
able to implement it and thus obtained a web platform integrating the following
modules :
● A module for managing students' academic data, enabling students to
obtain a digital version of the student's record ;
● A module for managing the users of the platform as well as their rights of
access ;
● A private discussion space mainly for students.
Considering the results of our work and the limitations of our system, we are
convinced that our platform must be improved so that it can perform its role better
and better. To do this, others works will aim to improve the current platform and
integrate other functional modules such as an E-learning module, a module for
complete registration management. Apart from these improvements to the current
system, it will also be for future work to extend this system of managing student
records to other entities and universities in Benin.

TABLE DES MATIÈRES

TABLE DES MATIERES
SOMMAIRE ............................................................................................ i
DEDICACES .......................................................................................... iii
REMERCIEMENTS............................................................................... iv
LISTE DES SIGLES ET ABREVIATIONS ............................................. vi
LISTE DES TABLEAUX ......................................................................... x
LISTE DES FIGURES ........................................................................... xii
RESUME.............................................................................................. xiv
ABSTRACT .......................................................................................... xv
INTRODUCTION GENERALE............................................................... 1
PARTIE I SYNTHESE BIBLIOGRAPHIQUE ..................................... 5

Chapitre 1 : Le dossier académique de l’étudiant .............................................................................. 6
1.1. Notion de dossier académique de l’étudiant ...................................................................... 6
1.2. Contenu d’un dossier académique ...................................................................................... 6
1.3. Différentes utilisations du dossier académique .................................................................. 7
Chapitre 2 : Quelques systèmes de gestion des données académiques de l’étudiant......................... 9
2.1. Etude du module SCOLARIX du PGI Cocktail ....................................................................... 9
2.1.1. Généralités ................................................................................................................ 10
2.1.2. Fonctionnalités .......................................................................................................... 10
2.2. Etude du SI Is-Academia .................................................................................................... 11
2.2.1. Généralités ................................................................................................................ 11
2.2.2. Fonctionnalités .......................................................................................................... 12
2.3. Etude du PGI APOGEE........................................................................................................ 15
PARTIE II MATERIELS ET METHODES ........................................ 17

Chapitre 3 : Méthodologie de conception ........................................................................................ 18
3.1. Présentation de la méthodologie de conception adoptée................................................ 18
3.2. Définition des besoins du système .................................................................................... 20

TABLE DES MATIERES
3.2.1. Besoins fonctionnels.................................................................................................. 20
3.2.2. Besoins non fonctionnels .......................................................................................... 21
3.3. Solution d’amélioration du présent dossier ...................................................................... 23
3.3.1. Vue globale ................................................................................................................ 23
3.3.2. Spécifications fonctionnelles des besoins ................................................................. 24
3.3.3. Conception architecturale de notre solution ............................................................ 27
3.3.4. Fonctionnement globale ........................................................................................... 29
Chapitre 4 : Architecture du système ............................................................................................... 31
4.1. Méthode de conception .................................................................................................... 31
4.2. Modélisation du système .................................................................................................. 32
4.2.1. Les diagrammes de cas d’utilisations ........................................................................ 33
4.2.1.1. Acteurs du système ................................................................................................ 33
4.2.1.2. Description détaillée des cas d’utilisations du système ......................................... 37
4.2.2. Les diagrammes de séquences .................................................................................. 53
4.2.2.1. Diagramme de séquence du scénario « S’authentifier » ........................................ 55
4.2.2.2. Diagramme de séquence du scénario « Valider un compte étudiant » ................ 56
4.2.2.3. Diagramme de séquence du scénario « Modifier les informations d’un département

» 56
4.2.2.4. Diagramme de séquence du scénario « Ajouter une pièce au dossier académique »

57
4.2.3. Diagramme de classes et d’interfaces ....................................................................... 58
Chapitre 5 : Détermination des outils et technologies de développement ....................................... 60
5.1. Présentation des frameworks utilisés ............................................................................... 61
5.1.1. Laravel ....................................................................................................................... 62
5.1.2. Bootstrap ................................................................................................................... 62
5.1.3. JQuery ........................................................................................................................ 63
5.2. Autres outils de développement ....................................................................................... 63
5.2.1. PhpStorm 8.0.1 .......................................................................................................... 63

TABLE DES MATIERES
5.2.2. WampServer 2.5 ........................................................................................................ 64
5.2.3. Visual Paradigm 13.1 ................................................................................................. 64
5.2.4. Git .............................................................................................................................. 64
PARTIE III RESULTATS .................................................................. 65

Chapitre 6 : Implémentation et tests ................................................................................................ 66
5.1. Ergonomie et interfaces .................................................................................................... 66
5.1.1. La page d’authentification ......................................................................................... 66
5.1.2. La page de validation d’un compte étudiant............................................................. 67
5.1.3. Le module de gestion des utilisateurs ....................................................................... 68
5.1.4. Le profil de l’étudiant ................................................................................................ 69
5.1.5. Le module de gestion des dossiers académiques ..................................................... 70
5.2. Sécurisation du système .................................................................................................... 71
5.2.1. Sécurité des données ................................................................................................ 71
5.2.2. Sécurité au niveau de l’application ........................................................................... 73
5.3. Tests et résultats ............................................................................................................... 74
5.4. Limites du système ............................................................................................................ 76
CONCLUSION ET PERSPECTIVES .................................................... 77
RÉFÉRENCES BIBLIOGRAPHIQUES................................................. 79
ANNEXES ............................................................................................. 82
ANNEXE A | Laravel5.0 : Architecture MVC et Programmation Orientée Objet (POO) .............. 83
ANNEXE B | Les Protocoles de communication ............................................................................. 84
ANNEXE C | Présentation du projet dans PhpStorm ...................................................................... 91
ENGLISH VERSION............................................................................. 99
TABLE DES MATIÈRES .................................................................... 113

MEMOIRE ADJE FREJUS LEONEL - Compressed

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

MEMOIRE ADJE FREJUS LEONEL - Compressed

Transféré par

Droits d'auteur :

Formats disponibles

RÉPUBLIQUE DU BÉNIN

UNIVERSITÉ D’ABOMEY - CALAVI

ECOLE POLYTECHNIQUE D’ABOMEY-CALAVI

DEPARTEMENT DE GENIE INFORMATIQUE ET

MÉMOIRE DE FIN DE FORMATION

DIPLÔME D’INGENIEUR DE CONCEPTION

CONCEPTION ET DEVELOPPEMENT D’UNE PLATEFORME

Réalisé et soutenu par : Fréjus Léonel Oyédélé ADJE

Président : Dr. SOGBOHOSSOU Médésu Enseignant à l’EPAC

Année Académique : 2015 – 2016

DEDICACES .......................................................................................... iii

LISTE DES SIGLES ET ABREVIATIONS ............................................. vi

LISTE DES TABLEAUX ......................................................................... x

LISTE DES FIGURES ........................................................................... xii

PARTIE I SYNTHESE BIBLIOGRAPHIQUE ..................................... 5

Chapitre 2 : Quelques systèmes de gestion des données académiques de l’étudiant......................... 9

PARTIE II MATERIELS ET METHODES ........................................ 17

Chapitre 4 : Architecture du système ............................................................................................... 31

Chapitre 5 : Détermination des outils et technologies de développement ....................................... 60

PARTIE III RESULTATS .................................................................. 65

CONCLUSION ET PERSPECTIVES .................................................... 77

ANNEXE B | Les Protocoles de communication ............................................................................. 84

Réalisé par Fréjus Léonel O. ADJE i

TABLE DES MATIÈRES .................................................................... 113

Réalisé par Fréjus Léonel O. ADJE ii

Fréjus Léonel O. ADJE

Réalisé par Fréjus Léonel O. ADJE iii

 Au Professeur Mohamed SOUMANOU, Directeur de l'École

Réalisé par Fréjus Léonel O. ADJE iv

Réalisé par Fréjus Léonel O. ADJE v

AJAX Asynchronous JAvascript and Xml

CMS Content Management System

EDI Environnement de Développement Intégré

FTP File Transfer Protocol

GSM Global System for Mobile Communications

Réalisé par Fréjus Léonel O. ADJE vi

HTML HyperText Markup Language

ICMP Internet Control Message Protocol

JSON JavaScript Object Notation

LAN Local Area Network

MVC Modèle-Vue-Contrôleur (Model-View-Controller)

Réalisé par Fréjus Léonel O. ADJE vii

ORM Object Relational Mapping

RAID Redundant Arrays of Inexpensive Disks

Sass Syntactically Awesome Style Sheets

TCP Transmission Control Protocol

Réalisé par Fréjus Léonel O. ADJE viii

UAC Université d’Abomey-Calavi

WWW World Wide Web

XML EXtensible Markup Language

Réalisé par Fréjus Léonel O. ADJE ix

Réalisé par Fréjus Léonel O. ADJE x

Réalisé par Fréjus Léonel O. ADJE xi

Réalisé par Fréjus Léonel O. ADJE xii

Réalisé par Fréjus Léonel O. ADJE xiii

Mots-clés : Conception, plateforme web, dossier d’étudiant, dossier académique,

Réalisé par Fréjus Léonel O. ADJE xiv

The student's background is often documented in an academic record of

In our dissertation, we developed a platform for management of student

Keywords : Design, platform, web application, academic transcript, academic

Réalisé par Fréjus Léonel O. ADJE xv

CONTEXTE, JUSTIFICATION ET PROBLEMATIQUE

Dans le cadre du suivi et de la gestion des universités, ces dernières

Et en option nous avons : 

 Gestion et suivi des anciens 